http://elinux.org/api.php?action=feedcontributions&user=Const&feedformat=atomeLinux.org - User contributions [en]2013-06-18T22:32:38ZUser contributionsMediaWiki 1.22alphahttp://elinux.org/PandaBoardPandaBoard2012-11-24T18:14:09Z<p>Const: /* Community */</p>
<hr />
<div>The [http://www.pandaboard.org PandaBoard] is an [[OMAP4430]] ([[Cortex]]-A9) based low cost development platform.<br />
<br />
= Hardware =<br />
<br />
* OMAP4 (Cortex-A9) CPU based open development platform.<br />
** OMAP4430 Application processor<br />
** 1GB low-power DDR2<br />
** Display HDMI v1.3 Connector (Type A) to drive HD displays, DVI-D Connector (can drive a 2nd display, simultaneous display; requires HDMI to DVI-D adapter), LCD expansion header<br />
** 3.5" audio in/out and HDMI Audio out<br />
** Full size SD/MMC card<br />
** Built in 802.11 & Bluetooth v2.1+EDR<br />
** Onboard 10/100 Ethernet<br />
** Expansion: 1xUSB OTG, 2xUSB HS host ports, General purpose expansion header (I2C, GPMC, USB, MMC, DSS, ETM)<br />
** JTAG, UART/RS-232, 2 status LEDs, 1GPIO button<br />
<br />
More details can be found [http://pandaboard.org/content/platform here]<br />
<br />
* PandaBoard EA1 Front<br />
[[File:PandaBoard_front.png|320px]]<br />
<br />
A hi resolution picture of the PandaBoard EA1 front is available here: http://elinux.org/images/d/d4/Panda_front.jpg<br />
<br />
* PandaBoard EA1 Back<br />
[[File:Panda_back.jpg|240px]]<br />
<br />
= Availability =<br />
PandaBoard are in production and can be ordered from [http://pandaboard.org/content/buy Worldwide distributors]. You can also easily identify the board you have using [http://omappedia.org/wiki/PandaBoard_Revisions Board revision id]<br />
<br />
== Rev A3 ==<br />
Latest version of the board.<br />
<br />
== Rev A1/A2 ==<br />
[http://omappedia.org/wiki/PandaBoard_Revisions#Rev_A2 Details]<br />
<br />
== Rev EA1/EA2 ==<br />
These were limited number of 'Early Adopter' boards that built prior to production versions. [http://omappedia.org/wiki/PandaBoard_Revisions#Rev_EA1 more details]<br />
<br />
== Rev ES ==<br />
<br />
There is now a PandaBoare-ES http://pandaboard.org/content/pandaboard-es which includes an OMAP 4460 at up to 1.2GHz. Several important differences make it important (at the present time) that the MLO/u-boot/kernel be specifically crafted for the 4460. The thermal management is not in the mainline 4430 code as yet and could cause unwanted thermal problems. So BEWARE of running any code built for the non -ES PandaBoard on the -ES model.<br />
<br />
<br />
= Accessories =<br />
<br />
* [[Panda_Bamboo|Bamboo Board]]<br />
* [[BeagleBoard_Trainer|Trainer Board]]<br />
* [https://specialcomp.com/pandaboard/order.htm Acrylic case]<br />
* [http://bb-lvds.blogspot.com 10" LCD LVDS plug-and-play bundle with capacitance touchscreen and ambient light sensor]<br />
*[[File:Beadaframe.jpg|200px|thumb|BeadaFrame]][http://www.nxelec.com/products/hmi/beadaframe-pandaboard BeadaFrame] 7" LCD display kit<br />
** 7" 800x480 TFT LCD screen<br />
** PWM Backlight control<br />
** Resistive touch panel<br />
** RTC time keeper <br />
** Plastic frame<br />
<br/><br />
<br />
= Recommended Reading Material =<br />
<br />
* [[Embedded_Linux_System_Design_and_Development]]<br />
* [[Embedded_linux_primer]]<br />
* [[Building_Embedded_Linux_Systems]]<br />
* [[Essential_Linux_Device_Drivers]]<br />
* [[Linux_Device_Drivers]]<br />
<br />
= How To's =<br />
* [[Panda_How_to_build_SDR|Build SDR for Pandaboard]]<br />
* [[PandaBoard_Button|Add a GPIO Button]]<br />
* [[Panda_How_to_MLO_&_u-boot|How to build MLO and u-boot]] for the PandaBoard '''-->> Updated 7/23/2011'''<br />
* [[Panda_How_to_Barebox|How to build Barebox]] for the PandaBoard '''-->> Updated 11/12/2011'''<br />
* [[PandaBoard_ES_uboot_howto|How to build u-boot and SPL]] for PandaBoard and PandaBoard ES '''-->> Updated 12/27/2011'''<br />
* [[Panda_How_to_kernel_3_2_rel|How to build 3.2 kernel]] for the PandaBoard '''-->> Updated 2/18/2012'''<br />
* [[Panda_How_to_kernel_3_3_rcx|How to build 3.3-rcx kernel]] for the PandaBoard '''-->> Updated 2/18/2012'''<br />
* [[Panda_How_to_kernel_3_3_rel|How to build 3.3 kernel]] for the PandaBoard '''-->> Updated 3/19/2012'''<br />
* [[Panda_How_to_kernel_3_4_rel|How to build 3.4 kernel]] for the PandaBoard '''-->> NEW 6/3/2012'''<br />
* [[Panda_How_to_kernel_3_5_rcx|How to build 3.5-rcx kernel]] for the PandaBoard '''-->> Updated 7/16/2012'''<br />
* [[Panda_How_to_add_2_USBs|How to add two additional USB connections]] to the PandaBoard<br />
* [[Panda_How_to_add_Power_Switch|How to add a power switch]] to the PandaBoard '''-->> WIP'''<br />
* [[PandaBoard Power Measurements]]<br />
<br />
== Older How To's ==<br />
<br />
* [[Panda_How_to_buildroot|How to build a minimal file system using buildroot]] for the PandaBoard<br />
* [[Panda_How_to_kernel|How to build a kernel using the buildroot toolchain from above]] for the PandaBoard<br />
* [[Panda_How_to_kernel_new|How to build 2.6.38-rcx kernels]] for the PandaBoard '''-->> Updated 3/15/2011'''<br />
* [[Panda_How_to_kernel_2_6_38|How to build 2.6.38 kernel]] for the PandaBoard '''-->> Updated 3/16/2011'''<br />
* [[Panda_How_to_kernel_2_6_39|How to build 2.6.39-rcx kernel]] for the PandaBoard '''-->> Updated 5/12/2011'''<br />
* [[Panda_How_to_kernel_2_6_39rel|How to build 2.6.39 kernel]] for the PandaBoard '''-->> Updated 5/27/2011'''<br />
* [[Panda_How_to_kernel_3_0_rel|How to build 3.0 kernel]] for the PandaBoard '''-->> Updated 7/29/2011'''<br />
* [[Panda_How_to_kernel_3_0_rcx|How to build 3.0-rcx kernel]] for the PandaBoard '''-->> Updated 7/11/2011'''<br />
* [[Panda_How_to_kernel_3_1_rcx|How to build 3.1-rcx kernel]] for the PandaBoard '''-->> Updated 10/5/2011'''<br />
* [[Panda_How_to_kernel_3_1_rel|How to build 3.1 kernel]] for the PandaBoard '''-->> Updated 10/31/2011'''<br />
* [[Panda_How_to_kernel_3_2_rcx|How to build 3.2-rcx kernel]] for the PandaBoard '''-->> Updated 2/18/2012'''<br />
<br />
= Community =<br />
<br />
* Website: [http://pandaboard.org http://pandaboard.org]<br />
* IRC: #pandaboard @irc.freenode.net<br />
* Mailing List: [http://groups.google.com/group/pandaboard pandaboard@googlegroups.com]<br />
* [http://www.mail-archive.com/search?a=1&l=linux-omap%40vger.kernel.org&haswords=panda&date=&order=datenewest&search=Search panda on linux-omap@vger.kernel.org]<br />
<br />
[[category:OMAP]]<br />
[[category:omap4430]]<br />
[[category:PandaBoard]]<br />
[[category:Development Boards]]</div>Consthttp://elinux.org/PandaBoardPandaBoard2012-11-24T18:11:10Z<p>Const: /* Community */ + panda on linux-omap@vger.kernel.org</p>
<hr />
<div>The [http://www.pandaboard.org PandaBoard] is an [[OMAP4430]] ([[Cortex]]-A9) based low cost development platform.<br />
<br />
= Hardware =<br />
<br />
* OMAP4 (Cortex-A9) CPU based open development platform.<br />
** OMAP4430 Application processor<br />
** 1GB low-power DDR2<br />
** Display HDMI v1.3 Connector (Type A) to drive HD displays, DVI-D Connector (can drive a 2nd display, simultaneous display; requires HDMI to DVI-D adapter), LCD expansion header<br />
** 3.5" audio in/out and HDMI Audio out<br />
** Full size SD/MMC card<br />
** Built in 802.11 & Bluetooth v2.1+EDR<br />
** Onboard 10/100 Ethernet<br />
** Expansion: 1xUSB OTG, 2xUSB HS host ports, General purpose expansion header (I2C, GPMC, USB, MMC, DSS, ETM)<br />
** JTAG, UART/RS-232, 2 status LEDs, 1GPIO button<br />
<br />
More details can be found [http://pandaboard.org/content/platform here]<br />
<br />
* PandaBoard EA1 Front<br />
[[File:PandaBoard_front.png|320px]]<br />
<br />
A hi resolution picture of the PandaBoard EA1 front is available here: http://elinux.org/images/d/d4/Panda_front.jpg<br />
<br />
* PandaBoard EA1 Back<br />
[[File:Panda_back.jpg|240px]]<br />
<br />
= Availability =<br />
PandaBoard are in production and can be ordered from [http://pandaboard.org/content/buy Worldwide distributors]. You can also easily identify the board you have using [http://omappedia.org/wiki/PandaBoard_Revisions Board revision id]<br />
<br />
== Rev A3 ==<br />
Latest version of the board.<br />
<br />
== Rev A1/A2 ==<br />
[http://omappedia.org/wiki/PandaBoard_Revisions#Rev_A2 Details]<br />
<br />
== Rev EA1/EA2 ==<br />
These were limited number of 'Early Adopter' boards that built prior to production versions. [http://omappedia.org/wiki/PandaBoard_Revisions#Rev_EA1 more details]<br />
<br />
== Rev ES ==<br />
<br />
There is now a PandaBoare-ES http://pandaboard.org/content/pandaboard-es which includes an OMAP 4460 at up to 1.2GHz. Several important differences make it important (at the present time) that the MLO/u-boot/kernel be specifically crafted for the 4460. The thermal management is not in the mainline 4430 code as yet and could cause unwanted thermal problems. So BEWARE of running any code built for the non -ES PandaBoard on the -ES model.<br />
<br />
<br />
= Accessories =<br />
<br />
* [[Panda_Bamboo|Bamboo Board]]<br />
* [[BeagleBoard_Trainer|Trainer Board]]<br />
* [https://specialcomp.com/pandaboard/order.htm Acrylic case]<br />
* [http://bb-lvds.blogspot.com 10" LCD LVDS plug-and-play bundle with capacitance touchscreen and ambient light sensor]<br />
*[[File:Beadaframe.jpg|200px|thumb|BeadaFrame]][http://www.nxelec.com/products/hmi/beadaframe-pandaboard BeadaFrame] 7" LCD display kit<br />
** 7" 800x480 TFT LCD screen<br />
** PWM Backlight control<br />
** Resistive touch panel<br />
** RTC time keeper <br />
** Plastic frame<br />
<br/><br />
<br />
= Recommended Reading Material =<br />
<br />
* [[Embedded_Linux_System_Design_and_Development]]<br />
* [[Embedded_linux_primer]]<br />
* [[Building_Embedded_Linux_Systems]]<br />
* [[Essential_Linux_Device_Drivers]]<br />
* [[Linux_Device_Drivers]]<br />
<br />
= How To's =<br />
* [[Panda_How_to_build_SDR|Build SDR for Pandaboard]]<br />
* [[PandaBoard_Button|Add a GPIO Button]]<br />
* [[Panda_How_to_MLO_&_u-boot|How to build MLO and u-boot]] for the PandaBoard '''-->> Updated 7/23/2011'''<br />
* [[Panda_How_to_Barebox|How to build Barebox]] for the PandaBoard '''-->> Updated 11/12/2011'''<br />
* [[PandaBoard_ES_uboot_howto|How to build u-boot and SPL]] for PandaBoard and PandaBoard ES '''-->> Updated 12/27/2011'''<br />
* [[Panda_How_to_kernel_3_2_rel|How to build 3.2 kernel]] for the PandaBoard '''-->> Updated 2/18/2012'''<br />
* [[Panda_How_to_kernel_3_3_rcx|How to build 3.3-rcx kernel]] for the PandaBoard '''-->> Updated 2/18/2012'''<br />
* [[Panda_How_to_kernel_3_3_rel|How to build 3.3 kernel]] for the PandaBoard '''-->> Updated 3/19/2012'''<br />
* [[Panda_How_to_kernel_3_4_rel|How to build 3.4 kernel]] for the PandaBoard '''-->> NEW 6/3/2012'''<br />
* [[Panda_How_to_kernel_3_5_rcx|How to build 3.5-rcx kernel]] for the PandaBoard '''-->> Updated 7/16/2012'''<br />
* [[Panda_How_to_add_2_USBs|How to add two additional USB connections]] to the PandaBoard<br />
* [[Panda_How_to_add_Power_Switch|How to add a power switch]] to the PandaBoard '''-->> WIP'''<br />
* [[PandaBoard Power Measurements]]<br />
<br />
== Older How To's ==<br />
<br />
* [[Panda_How_to_buildroot|How to build a minimal file system using buildroot]] for the PandaBoard<br />
* [[Panda_How_to_kernel|How to build a kernel using the buildroot toolchain from above]] for the PandaBoard<br />
* [[Panda_How_to_kernel_new|How to build 2.6.38-rcx kernels]] for the PandaBoard '''-->> Updated 3/15/2011'''<br />
* [[Panda_How_to_kernel_2_6_38|How to build 2.6.38 kernel]] for the PandaBoard '''-->> Updated 3/16/2011'''<br />
* [[Panda_How_to_kernel_2_6_39|How to build 2.6.39-rcx kernel]] for the PandaBoard '''-->> Updated 5/12/2011'''<br />
* [[Panda_How_to_kernel_2_6_39rel|How to build 2.6.39 kernel]] for the PandaBoard '''-->> Updated 5/27/2011'''<br />
* [[Panda_How_to_kernel_3_0_rel|How to build 3.0 kernel]] for the PandaBoard '''-->> Updated 7/29/2011'''<br />
* [[Panda_How_to_kernel_3_0_rcx|How to build 3.0-rcx kernel]] for the PandaBoard '''-->> Updated 7/11/2011'''<br />
* [[Panda_How_to_kernel_3_1_rcx|How to build 3.1-rcx kernel]] for the PandaBoard '''-->> Updated 10/5/2011'''<br />
* [[Panda_How_to_kernel_3_1_rel|How to build 3.1 kernel]] for the PandaBoard '''-->> Updated 10/31/2011'''<br />
* [[Panda_How_to_kernel_3_2_rcx|How to build 3.2-rcx kernel]] for the PandaBoard '''-->> Updated 2/18/2012'''<br />
<br />
= Community =<br />
<br />
* Website: [http://pandaboard.org http://pandaboard.org]<br />
* IRC: #pandaboard @irc.freenode.net<br />
* Mailing List: [http://groups.google.com/group/pandaboard pandaboard@googlegroups.com]<br />
* [http://www.mail-archive.com/search?l=linux-omap@vger.kernel.org&a=1&from=&subject=&haswords=panda&notwords=&datewithin=1d&date=&order=datenewest&start=10<br />
* [http://www.mail-archive.com/search?a=1&l=linux-omap%40vger.kernel.org&haswords=panda&date=&order=datenewest&search=Search panda on linux-omap@vger.kernel.org]<br />
<br />
[[category:OMAP]]<br />
[[category:omap4430]]<br />
[[category:PandaBoard]]<br />
[[category:Development Boards]]</div>Consthttp://elinux.org/Panda_How_to_kernelPanda How to kernel2012-10-20T16:11:35Z<p>Const: google search lkml.org panda</p>
<hr />
<div>-Kernel building-<br />
<br />
But if you want to try building your own kernel.... ;>))<br />
<br />
Make sure the [[Panda_How_to_buildroot|above]] all works first, then try the following:<br />
<br />
git clone git://gitorious.org/pandaboard/kernel-omap4.git<br />
<br />
then cd to the /kernel-omap4 dir and do:<br />
<br />
git checkout -b experimental remotes/origin/L24.9<br />
<br />
make ARCH=arm omap4_panda_defconfig<br />
<br />
make ARCH=arm menuconfig<br />
<br />
Import an alternate config from [[Media:config.kernel|config.kernel]] as it has somewhat different parameters that the panda defconfig which you will need.<br />
<br />
edit a file so as to have some uncomitted changes ie. the git archive needs to be "dirty"<br />
This is because the sdio.ko and tiwlan_drv.ko were compiled with a kernel with <br />
"version magic" of '2.6.35-g6d019da-dirty SMP preempt mod_unload ARMv7' and if that ain't it the modules won't load.<br />
<br />
make -j10 ARCH=arm CROSS_COMPILE=/path_to_your/buildroot-2010.11/output/staging/usr/bin/arm-linux- uImage<br />
<br />
You might want to change the -j10 to suite your CPU's capability.<br />
<br />
Put the uImage on your vfat partion in place of the kernel from the validation image<br />
<br />
boot up and login in as root with no password.<br />
<br />
try out wlan-test.sh again it should work as it did with the validation image kernel.<br />
<br />
Links<br />
<br />
* https://www.google.com/search?sitesearch=lkml.org&q=panda<br />
<br />
[[Category:PandaBoard]]</div>Consthttp://elinux.org/ExpertsExperts2012-10-20T11:06:16Z<p>Const: /* The List */</p>
<hr />
<div>== '''Embedded Linux Expert List''' ==<br />
<br />
* [[Rusty_Russell_Quotes]] This page is here in honor of Rusty Russell, one of the funniest Linux kernel developers EVER<br />
<br />
=== Instructions for Experts ===<br />
This page is intended to provide a place for Embedded Linux Experts to advertise their availability, and describe their expertise, to companies interested in paying them for services. This could include contract work or fulltime employment.<br />
<br />
Linux experts are encouraged to provide their information in the table below so that companies may contact them for their areas of interest. Please put an expiration date for the information, so we can remove information when it<br />
gets stale. Or even better, when you have obtained work, please remove your entry from this table.<br />
<br />
See the [[Jobs]] page for jobs already posted to this site.<br />
<br />
=== Instructions for Employers ===<br />
Please contact the person below, if you have a position or contract work you would like to hire<br />
someone to do. This list is not intended to be used to ask for free support.<br />
<br />
You can also list your job on the [[Jobs]] page.<br />
<br />
== '''The List''' ==<br />
{| border="1" cellspacing="0" cellpadding="5"<br />
|- style="background:#CCCCCC"<br />
! style="width:200px" | Name (Link)<br />
! style="width:400px" | Expertise areas<br />
! style="width:200px" | Contact Info<br />
! style="width:100px" | Expires date<br />
|- align="center"<br />
| Andrew Murray<br>Embedded Bits Limited<br>UK<br />
| Embedded Linux Boot Time Reduction<br />
| [mailto:amurray@embedded-bits.co.uk amurray@embedded-bits.co.uk]<br />
| 2013<br />
|- align="center"<br />
| Constantine Shulyupin<br>Israel, Worldwide<br />
| TI DaVinci, drivers, boot loaders, fast boot<br />
| http://www.makelinux.com <br> mailto://const@makelinux.com<br />
| 2015<br />
|- align="center"<br />
| Sasha Sirotkin<br>FemtoLinux<br>Tel-Aviv (Israel)<br />
| Porting from VxWorks, ThreadX, Nucleus and other RTOS to Linux, device drivers, BSP<br />
| http://www.femtolinux.com <br> demiurg AT femtolinux DOT com<br />
| 2011<br />
|- align="center"<br />
| Dave Lynch<br>DLA Systems<br>Lancaster, PA(USA)<br />
| Embedded Software development, bootloaders, board bring-up, BSP, drivers, toolchains, rootfs, applications - Linux and other embedded RTOS's<br />
| http://www.dlasys.net<br>dhlii@dlasys.net<br />
| 2011<br />
|- align="center"<br />
| Leon Woestenberg, MSc. EE, Eindhoven, The Netherlands, EU<br />
| Embedded Linux, Real-time, OpenEmbedded, System and Hardware Design, Device Drivers, Training, Video Broadcast, FPGA's, PCI Express<br />
| [http://www.sidebranch.com/ www.sidebranch.com]<br />
| 2015<br />
|- align="center"<br />
| Ithamar Adema,<br>[[User:Markv|Mark Vels]],<br> Netherlands, EU<br />
| Embedded Linux, BSP ports & support, OpenWrt support, Device Drivers, Training, <br />
| [http://www.team-embedded.com/ www.team-embedded.com]<br>[mailto:info@team-embedded.nl info@team-embedded.nl]<br />
| 2013<br />
|- align="center"<br />
| [[User:Arnout Vandecappelle|Arnout Vandecappelle]],<br>Leuven (Belgium)<br />
| Consultancy and Services in the field of Embedded Linux, Feasibility studies, BSP ports & support, Device drivers, Multimedia & networking, Debugging, Training<br />
| [mailto:contact@mind.be contact@mind.be]<br>[http://www.mind.be http://www.mind.be]<br />
| 2011<br />
|- align="center"<br />
| Chris Simmonds, Hampshire (UK), EU<br />
| Freelance consultant experienced in embedded and real-time Linux, U-Boot and board support packages<br />
| http://www.2net.co.uk, http://www.embedded-linux.co.uk/<br />
| 2011<br />
|- align="center"<br />
| Robert Berger - Reliable Embedded Systems, Embedded Software Specialist, Athens (Greece)/Mitterdorf (Austria), EU<br />
| Consulting and Training for: Embedded Linux (Systems Architecture, Device Drivers), Real-time, Debugging, U-boot, ... <br />
| elinux@reliableembeddedsystems.com [http://www.reliableembeddedsystems.com/ http://www.reliableembeddedsystems.com]<br />
| 2043<br />
|- align="center"<br />
| Roberto A. Foglietta, Genoa (Italy), EU<br />
| Embedded Linux for Telecommunication and Automotive <br />
| [http://www.roberto.foglietta/work/who_am_I www.roberto.foglietta/work]<br />
| 2010<br />
|- align="center"<br />
| Marco Cavallini, Bergamo (Italy), EU<br />
| Embedded Linux, Device Drivers, Real-time, OpenEmbedded, BSP Design, u-boot, training<br />
| [http://www.koansoftware.com KOAN sas]<br />
| 2015<br />
|- align="center"<br />
| Matthias Kaehlcke, Barcelona (Spain)<br />
| Embedded Linux and device drivers<br />
| matthias_AT_kaehlcke.net<br />
| 2010<br />
|- align="center"<br />
| David Anders<br>RAD Tech Labs<br>Dallas/Ft.worth, Texas<br />
| Embedded hardware and software development, board bringups, support packages, and drivers<br />
| http://www.rad-tech-labs.com<br>danders@rad-tech-labs.com<br />
| 2011<br />
|- align="center"<br />
| Sebastien Ronsse, MSc. EE, Seattle (WA), USA<br />
| Embedded Linux, Real-time, BSP ports & Support, Arm Architecture, System Design, Device Drivers, Training<br />
| sales@adeneo-embedded.com<br />
| 2010<br />
|- align="center"<br />
| Hunyue Yau, California (USA)<br />
| Embedded Linux, device drivers, board bring-up, ports, userland integration, training, prototyping, OMAP3<br />
| [http://www.hy-research.com/ www.hy-research.com]<br />
| 2010<br />
|- align="center"<br />
| Richard B. Johnson, Massachusetts (USA)<br />
| Embedded Linux, device drivers, ports, complete integration, tiny 'C' runtime library<br />
| [http://www.route495software.com/ www.Route495Software.com]<br />
| 2010<br />
|- align="center"<br />
| Young-Ho Song, Seoul (Korea)<br />
| Embedded Linux, Device drivers, Multimedia Communication & System, IPTV, Network Security<br />
| yhsongATnds.com <br />
whois [http://elinux.org/User:Young-Ho_Song Young-Ho Song]<br />
| 2017<br />
<br />
|- align="center"<br />
| Benjamin Zores, Strasbourg (France)<br />
| Embedded Linux, Device drivers, BSP Integration, Board Bring-Up, U-Boot, Multimedia Playback, Video Acceleration and Media Center applications<br />
| http://www.geexbox.org/<br>ben AT geexbox DOT org <br />
| 2011<br />
|- align="center"<br />
| Ivan Kuten, Minsk (Belarus), Europe<br />
| Embedded Linux, board bring-up, test suites for mass-production, experience in TI OMAP, Sitara, DaVinci; ST STi71xx/ST52xx; Atmel SAM9, Marvell ARMADA, Samsung S3C24xx/6410/S5PC100/S5PC110, Analog Devices Blackfin DSP, Fujitsu GDCs <br />
| http://www.ivankuten.com/<br>vano AT ivankuten DOT com <br />
| 2012<br />
|}<br />
<br />
[[Category:Categories]]</div>Consthttp://elinux.org/Android_Mainlining_ProjectAndroid Mainlining Project2012-10-13T09:43:20Z<p>Const: /* Meetings */ + KS2012: Status of Android upstreaming</p>
<hr />
<div>This page is for organizing the Android Mainlining Project. It has information and resources associated with this<br />
project.<br />
<br />
== Goal ==<br />
The goal of this project is to ultimately mainline all patches required to run the current released<br />
version of Android. The purpose of mainlining these patches is 3-fold:<br />
# to allow a developer to use the latest released version of the Linux kernel to run an Android system, without requiring patches to their kernel<br />
# to make it possible to develop drivers and board support features against either an Android kernel release or a kernel.org kernel release, with little or no modifications or conditional code<br />
# to reduce or eliminate the burden of maintaining independent patches from release to release for Android kernel developers<br />
<br />
To "mainline" a patch means to have it included in Linus Torvalds kernel.org kernel, in a released (non-rc) version.<br />
<br />
== Process ==<br />
[This is a draft section, up for discussion]<br />
<br />
Overall:<br />
* identify all patches/features, and categorize into core or non/core<br />
** core = feature is required or strongly desired for Android operation on a platform<br />
** non-core = Most of the Android system can run without the feature<br />
<br />
Per feature or patch:<br />
* research any previous submission feedback<br />
* incorporate feedback, as appropriate<br />
* negotiate any interface changes with Google Android team<br />
* submit updated patches to mainline<br />
* repeat until accepted<br />
<br />
== Resources ==<br />
* Mailing list: https://lists.linuxfoundation.org/mailman/listinfo/ce-android-mainline<br />
* Linaro blueprint for project: https://blueprints.launchpad.net/linux-linaro/+spec/linaro-kernel-android-upstreaming<br />
<br />
== Updates ==<br />
* [https://lwn.net/Articles/514901/ KS2012: Status of Android upstreaming]<br />
* Meeting: [[Android mainlining interest group meeting 2012]]<br />
** Summary: 9:30- 12:00 February 10, 2012 at the Sofitel Hotel in Redwood Shores, California.<br />
<br />
== People ==<br />
People who have expressed interest in this project are:<br />
<br />
* Tim Bird<br />
* John Stultz<br />
* Paul McKenney<br />
* Deepak Saxena<br />
* Arnd Bergmann<br />
* Thomas Gleixner<br />
* Arjan Van de Ven<br />
* Brian Swetland<br />
* Tetsuyuki Kobayashi<br />
* Andy Green<br />
* Victor M. Jaquez<br />
* Jesse Barker<br />
* Anton Vorontsov<br />
* Greg Kroah-Hartman<br />
* Shuah Khan<br />
<br />
=== roles/expertise ===<br />
This section has miscellaneous notes on roles, capabilities and expertise of group's members<br />
<br />
John Stultz is the owner of the Linaro blueprint for mainlining Android features.<br />
Tim Bird is the owner of the CE Workgroup project for mainlining Android features.<br />
Deepak and Jesse can help make arrangements for a meeting at Linaro Connect.<br />
Tim can help make arrangements for a meeting at Android Builders Summit.<br />
<br />
* John Stultz has worked on POSIX Alarm timers<br />
* Jesse is working on shared memory buffers related to pmem/CMA/parts of ion<br />
* Anton Vorontsov is looking at the lowmemory killer<br />
* Greg has put some Android patches into mainline (under drivers/staging/android) previously<br />
** Greg put some Android patches in mainline under drivers/staging/android in Dec. 2011<br />
* Paul McKenney - kicking around ideas for dealing with wakelocks single global lock (dec. 2011)<br />
<br />
== Plans ==<br />
* Update this site with information on latest patch status - ongoing, by anyone<br />
** [FIXTHIS - add sections needing a status or status update]<br />
<br />
== Patch/Feature Status Chart ==<br />
{| border="1" cellspacing="0" cellpadding="5"<br />
|-bgcolor="#80c0d0"<br />
!Feature/Patch<br />
!Description<br />
!Status<br />
!Part of core?<br />
!Owner/Interested parties<br />
|Notes<br />
|-<br />
|[[Android_logger|logger]]<br />
|kernel support for Android system logging<br />
|in drivers/staging/android, in kernel version 3.3 2012.03.19<br />
|yes<br />
|Tim Bird<br />
|See [[Mainline Android logger project]] for a list of ideas, issues and a project plan for this feature<br />
Also see [http://lkml.indiana.edu/hypermail/linux/kernel/1112.2/index.html#02419 this LKML discussion thread]<br />
Some cleanup patches in linux-next, with some changes to avoid hardcoding logging channels (see Linus' tree commit: 10b241991fc)<br />
Tim was planning on doing channel allocation from user-space next, but Arnd may have talked him into doing a fs-based solution at LinuxCon Japan. (6/18/2012).<br />
|-<br />
|wakelocks<br />
|Power management locking mechanism to prevent opportunistic suspend<br />
|parts mainlined, as of 2012.06.18, work in progress<br />
|yes<br />
|Rafael Wysocki<br />
|Is important due to impact on board support and drivers by 3rd parties. Last effort was around "autosleep and wakelocks".<br />
See http://lwn.net/Articles/479841/ and this thread: http://thread.gmane.org/gmane.linux.kernel/1249726. This code apparently made it into 3.4, with more code to appear in 3.5?<br />
|-<br />
|Android alarm timers<br />
|Timers that count down during suspended operation, and can wake from suspend<br />
|Partial: Posix alarm timers were mainlined in kernel version 2.6.38 - see https://lwn.net/Articles/429925/ <br />
|yes<br />
|John Stultz<br />
|Mending patches to convert Android Alarm Timers to utilize the upstreamed alarm timer work are still pending.<br />
|-<br />
|ashmem<br />
|Shared memory implementation that allows unpinned pages to be marked, which can be dropped by the kernel under memory pressure<br />
|in drivers/staging/android, in kernel version 3.3 2012.03.19<br />
|yes<br />
|John Stultz<br />
|Working on fadvise volatile alternative implementation that handles part of the ashmem functionality. However, there are additional aspects of ashmem design that need to be addressed (no tmpfs mounts, atomic create/unlink behavior,etc).<br />
|-<br />
|network security<br />
|special permission checks for secure access to network operations<br />
|not mainlined<br />
|? (can run without it, but network security won't be enforced)<br />
|no one<br />
|May be very difficult to mainline, as the code is extremely Android-specific with hardcoded GIDs and capabilities.<br />
|-<br />
|[[Android_Binder|binder]]<br />
|Android inter-process communication mechanism<br />
|in drivers/staging/android, in kernel version 3.3 2012.03.19<br />
|yes<br />
|no one<br />
|Generated a fair amount of discussion on last submission. See http://elinux.org/Android_Binder#obstacles_to_mainlining<br />
See also this thread: http://lists.linuxfoundation.org/pipermail/ce-android-mainline/2012-January/thread.html#42<br />
|-<br />
|Android pmem driver<br />
|manages large (1-16+MB) contiguous physical memory regions to be shared between userspace and kernel drivers (dsp, gpu etc.)<br />
|Removed - no longer in use<br />
|yes<br />
|Shuah Khan<br />
|Investigating existing alternatives. Can CMA (Contiguous Memory Allocator) fill the need? Based on recent lkml discussion, pmem.c is no longer used and will be removed from Android release. Reference: https://lkml.org/lkml/2012/1/23/183 - Patch to remove pmem.c from 3.3-rc1 staging area has been accepted.<br />
|-<br />
|Android USB gadget driver<br />
|Support for Android as gadget device from host<br />
|unknown<br />
|? (not sure if needed for basic bringup or not, but would be really painful if missing)<br />
|no one?<br />
|[[#USB|USB]]<br />
|-<br />
|timed gpio<br />
|perform gpio operations as a result of specified timeouts - mainly used to support vibrate feature.<br />
|in drivers/staging/android, in kernel version 3.3 2012.03.19<br />
|no? (is this needed for basic bringup?)<br />
|Shuah Khan<br />
|A new transient trigger added to led triggers in Linux 3.4 to address the need for one shot timer activation. This driver could be removed once the legacy libraries are changed to use the new transient trigger. https://lkml.org/lkml/2012/4/30/288<br />
|-<br />
|timed output<br />
|seems to just be a class for timed gpio items<br />
|in drivers/staging/android, in kernel version 3.3 2012.03.19<br />
|no? (required by timed_gpio)<br />
|Shuah Khan<br />
|A new transient trigger added to led triggers in Linux 3.4 to address the need for one shot timer activation. This driver could be removed once the legacy libraries are changed to use the new transient trigger. https://lkml.org/lkml/2012/4/30/288<br />
|-<br />
|low memory killer<br />
|feature to manage application lifecycle in low memory conditions<br />
|in drivers/staging/android, in kernel version 3.3 2012.03.19<br />
|yes (but system might work without it)<br />
|Anton Vorontsov<br />
|See https://lkml.org/lkml/2011/12/18/173 for discussion about these patches<br />
|-<br />
|ram console<br />
|ability to save console output to a reserved ram area for diagnostics on a subsequent boot<br />
|in drivers/staging/android, in kernel version 3.3 2012.03.19<br />
|no<br />
|Shuah Khan<br />
|No lkml submission attempt history found so far. pstore fs interface solves the same problem and is in mainline 3.1.5. fs/pstore Reference - http://lwn.net/Articles/421297/ After investigating and discussing ram console use cases, it is clear that the proposal to use ram-oops and pstore will not be a complete solution to cover all the cases. Hence, the going forward plan is to pursue ram console inclusion in the mainline. ram console is going through re-write splitting it into twp drivers. Waiting for these changes to get into the 3.3 staging area. For now working with the unofficial patches.<br />
<br />
Anton Vortontsov moved some functionality from the ram_console into the new "persistent_ram" feature, in fs/pstore/ram_core.c (May 17, 2012 - see commit cddb8751c)<br />
|-<br />
|ion graphics memory driver<br />
|graphics memory drivers thingie<br />
|not mainlined<br />
|yes (for 4.0 and later?)<br />
|Jesse Barker<br />
|<br />
|}<br />
<br />
== USB==<br />
* [http://thread.gmane.org/gmane.linux.usb.general/56244 Android Composite Gadget driver discussion]<br />
* http://lxr.free-electrons.com/source/drivers/staging/ccg/ - Configurable Composite Gadget - reincarnation of Android Composite Gdaget<br />
== Progress Chart ==<br />
This section is intended to show our progress, by showing the patch set size over time. With any luck, as<br />
we get features into mainline, the difference between the Android kernel and the mainline Linux kernel will shrink.<br />
<br />
<div style="margin:0; margin-top:10px; margin-right:10px; border:1px solid #dfdfdf; padding:0 1em 1em 1em; background-color:#ffffcc; align:right; "><br />
''Note: This table is not up-to-date and is hard to measure anyway. The inclusion of a lot of material into 3.3 obsoletes the need for a per-patch tracking mechanism (maybe?). Also, there will always be some difference, due to board support packages and new development areas (like ion), so the goal is not really 0 differences, but just a reduction overall. I'm not sure if we'll maintain this table or not, but I'm leaving it for now as a placeholder.''<br />
</div><br />
<br />
<br />
* diff of 2.6.29 kernel.org tree versus kernel<br />
{| border="1" cellspacing="0" cellpadding="5"<br />
|-bgcolor="#80c0d0"<br />
!Kernel Version<br />
!Files changed<br />
!insertions<br />
!deletions<br />
!hunks<br />
!bytes in diff<br />
|-<br />
|2.6.29 || 187 || 123506 || 0 || 187 || 3291827<br />
|-<br />
|}<br />
<br />
<br />
<br />
[[Category:Android]]</div>Consthttp://elinux.org/Android_Mainlining_ProjectAndroid Mainlining Project2012-10-13T09:40:04Z<p>Const: + USB, ccg</p>
<hr />
<div>This page is for organizing the Android Mainlining Project. It has information and resources associated with this<br />
project.<br />
<br />
== Goal ==<br />
The goal of this project is to ultimately mainline all patches required to run the current released<br />
version of Android. The purpose of mainlining these patches is 3-fold:<br />
# to allow a developer to use the latest released version of the Linux kernel to run an Android system, without requiring patches to their kernel<br />
# to make it possible to develop drivers and board support features against either an Android kernel release or a kernel.org kernel release, with little or no modifications or conditional code<br />
# to reduce or eliminate the burden of maintaining independent patches from release to release for Android kernel developers<br />
<br />
To "mainline" a patch means to have it included in Linus Torvalds kernel.org kernel, in a released (non-rc) version.<br />
<br />
== Process ==<br />
[This is a draft section, up for discussion]<br />
<br />
Overall:<br />
* identify all patches/features, and categorize into core or non/core<br />
** core = feature is required or strongly desired for Android operation on a platform<br />
** non-core = Most of the Android system can run without the feature<br />
<br />
Per feature or patch:<br />
* research any previous submission feedback<br />
* incorporate feedback, as appropriate<br />
* negotiate any interface changes with Google Android team<br />
* submit updated patches to mainline<br />
* repeat until accepted<br />
<br />
== Resources ==<br />
* Mailing list: https://lists.linuxfoundation.org/mailman/listinfo/ce-android-mainline<br />
* Linaro blueprint for project: https://blueprints.launchpad.net/linux-linaro/+spec/linaro-kernel-android-upstreaming<br />
<br />
== Meetings ==<br />
* Meeting: [[Android mainlining interest group meeting 2012]]<br />
** Summary: 9:30- 12:00 February 10, 2012 at the Sofitel Hotel in Redwood Shores, California.<br />
<br />
== People ==<br />
People who have expressed interest in this project are:<br />
<br />
* Tim Bird<br />
* John Stultz<br />
* Paul McKenney<br />
* Deepak Saxena<br />
* Arnd Bergmann<br />
* Thomas Gleixner<br />
* Arjan Van de Ven<br />
* Brian Swetland<br />
* Tetsuyuki Kobayashi<br />
* Andy Green<br />
* Victor M. Jaquez<br />
* Jesse Barker<br />
* Anton Vorontsov<br />
* Greg Kroah-Hartman<br />
* Shuah Khan<br />
<br />
=== roles/expertise ===<br />
This section has miscellaneous notes on roles, capabilities and expertise of group's members<br />
<br />
John Stultz is the owner of the Linaro blueprint for mainlining Android features.<br />
Tim Bird is the owner of the CE Workgroup project for mainlining Android features.<br />
Deepak and Jesse can help make arrangements for a meeting at Linaro Connect.<br />
Tim can help make arrangements for a meeting at Android Builders Summit.<br />
<br />
* John Stultz has worked on POSIX Alarm timers<br />
* Jesse is working on shared memory buffers related to pmem/CMA/parts of ion<br />
* Anton Vorontsov is looking at the lowmemory killer<br />
* Greg has put some Android patches into mainline (under drivers/staging/android) previously<br />
** Greg put some Android patches in mainline under drivers/staging/android in Dec. 2011<br />
* Paul McKenney - kicking around ideas for dealing with wakelocks single global lock (dec. 2011)<br />
<br />
== Plans ==<br />
* Update this site with information on latest patch status - ongoing, by anyone<br />
** [FIXTHIS - add sections needing a status or status update]<br />
<br />
== Patch/Feature Status Chart ==<br />
{| border="1" cellspacing="0" cellpadding="5"<br />
|-bgcolor="#80c0d0"<br />
!Feature/Patch<br />
!Description<br />
!Status<br />
!Part of core?<br />
!Owner/Interested parties<br />
|Notes<br />
|-<br />
|[[Android_logger|logger]]<br />
|kernel support for Android system logging<br />
|in drivers/staging/android, in kernel version 3.3 2012.03.19<br />
|yes<br />
|Tim Bird<br />
|See [[Mainline Android logger project]] for a list of ideas, issues and a project plan for this feature<br />
Also see [http://lkml.indiana.edu/hypermail/linux/kernel/1112.2/index.html#02419 this LKML discussion thread]<br />
Some cleanup patches in linux-next, with some changes to avoid hardcoding logging channels (see Linus' tree commit: 10b241991fc)<br />
Tim was planning on doing channel allocation from user-space next, but Arnd may have talked him into doing a fs-based solution at LinuxCon Japan. (6/18/2012).<br />
|-<br />
|wakelocks<br />
|Power management locking mechanism to prevent opportunistic suspend<br />
|parts mainlined, as of 2012.06.18, work in progress<br />
|yes<br />
|Rafael Wysocki<br />
|Is important due to impact on board support and drivers by 3rd parties. Last effort was around "autosleep and wakelocks".<br />
See http://lwn.net/Articles/479841/ and this thread: http://thread.gmane.org/gmane.linux.kernel/1249726. This code apparently made it into 3.4, with more code to appear in 3.5?<br />
|-<br />
|Android alarm timers<br />
|Timers that count down during suspended operation, and can wake from suspend<br />
|Partial: Posix alarm timers were mainlined in kernel version 2.6.38 - see https://lwn.net/Articles/429925/ <br />
|yes<br />
|John Stultz<br />
|Mending patches to convert Android Alarm Timers to utilize the upstreamed alarm timer work are still pending.<br />
|-<br />
|ashmem<br />
|Shared memory implementation that allows unpinned pages to be marked, which can be dropped by the kernel under memory pressure<br />
|in drivers/staging/android, in kernel version 3.3 2012.03.19<br />
|yes<br />
|John Stultz<br />
|Working on fadvise volatile alternative implementation that handles part of the ashmem functionality. However, there are additional aspects of ashmem design that need to be addressed (no tmpfs mounts, atomic create/unlink behavior,etc).<br />
|-<br />
|network security<br />
|special permission checks for secure access to network operations<br />
|not mainlined<br />
|? (can run without it, but network security won't be enforced)<br />
|no one<br />
|May be very difficult to mainline, as the code is extremely Android-specific with hardcoded GIDs and capabilities.<br />
|-<br />
|[[Android_Binder|binder]]<br />
|Android inter-process communication mechanism<br />
|in drivers/staging/android, in kernel version 3.3 2012.03.19<br />
|yes<br />
|no one<br />
|Generated a fair amount of discussion on last submission. See http://elinux.org/Android_Binder#obstacles_to_mainlining<br />
See also this thread: http://lists.linuxfoundation.org/pipermail/ce-android-mainline/2012-January/thread.html#42<br />
|-<br />
|Android pmem driver<br />
|manages large (1-16+MB) contiguous physical memory regions to be shared between userspace and kernel drivers (dsp, gpu etc.)<br />
|Removed - no longer in use<br />
|yes<br />
|Shuah Khan<br />
|Investigating existing alternatives. Can CMA (Contiguous Memory Allocator) fill the need? Based on recent lkml discussion, pmem.c is no longer used and will be removed from Android release. Reference: https://lkml.org/lkml/2012/1/23/183 - Patch to remove pmem.c from 3.3-rc1 staging area has been accepted.<br />
|-<br />
|Android USB gadget driver<br />
|Support for Android as gadget device from host<br />
|unknown<br />
|? (not sure if needed for basic bringup or not, but would be really painful if missing)<br />
|no one?<br />
|[[#USB|USB]]<br />
|-<br />
|timed gpio<br />
|perform gpio operations as a result of specified timeouts - mainly used to support vibrate feature.<br />
|in drivers/staging/android, in kernel version 3.3 2012.03.19<br />
|no? (is this needed for basic bringup?)<br />
|Shuah Khan<br />
|A new transient trigger added to led triggers in Linux 3.4 to address the need for one shot timer activation. This driver could be removed once the legacy libraries are changed to use the new transient trigger. https://lkml.org/lkml/2012/4/30/288<br />
|-<br />
|timed output<br />
|seems to just be a class for timed gpio items<br />
|in drivers/staging/android, in kernel version 3.3 2012.03.19<br />
|no? (required by timed_gpio)<br />
|Shuah Khan<br />
|A new transient trigger added to led triggers in Linux 3.4 to address the need for one shot timer activation. This driver could be removed once the legacy libraries are changed to use the new transient trigger. https://lkml.org/lkml/2012/4/30/288<br />
|-<br />
|low memory killer<br />
|feature to manage application lifecycle in low memory conditions<br />
|in drivers/staging/android, in kernel version 3.3 2012.03.19<br />
|yes (but system might work without it)<br />
|Anton Vorontsov<br />
|See https://lkml.org/lkml/2011/12/18/173 for discussion about these patches<br />
|-<br />
|ram console<br />
|ability to save console output to a reserved ram area for diagnostics on a subsequent boot<br />
|in drivers/staging/android, in kernel version 3.3 2012.03.19<br />
|no<br />
|Shuah Khan<br />
|No lkml submission attempt history found so far. pstore fs interface solves the same problem and is in mainline 3.1.5. fs/pstore Reference - http://lwn.net/Articles/421297/ After investigating and discussing ram console use cases, it is clear that the proposal to use ram-oops and pstore will not be a complete solution to cover all the cases. Hence, the going forward plan is to pursue ram console inclusion in the mainline. ram console is going through re-write splitting it into twp drivers. Waiting for these changes to get into the 3.3 staging area. For now working with the unofficial patches.<br />
<br />
Anton Vortontsov moved some functionality from the ram_console into the new "persistent_ram" feature, in fs/pstore/ram_core.c (May 17, 2012 - see commit cddb8751c)<br />
|-<br />
|ion graphics memory driver<br />
|graphics memory drivers thingie<br />
|not mainlined<br />
|yes (for 4.0 and later?)<br />
|Jesse Barker<br />
|<br />
|}<br />
<br />
== USB==<br />
* [http://thread.gmane.org/gmane.linux.usb.general/56244 Android Composite Gadget driver discussion]<br />
* http://lxr.free-electrons.com/source/drivers/staging/ccg/ - Configurable Composite Gadget - reincarnation of Android Composite Gdaget<br />
== Progress Chart ==<br />
This section is intended to show our progress, by showing the patch set size over time. With any luck, as<br />
we get features into mainline, the difference between the Android kernel and the mainline Linux kernel will shrink.<br />
<br />
<div style="margin:0; margin-top:10px; margin-right:10px; border:1px solid #dfdfdf; padding:0 1em 1em 1em; background-color:#ffffcc; align:right; "><br />
''Note: This table is not up-to-date and is hard to measure anyway. The inclusion of a lot of material into 3.3 obsoletes the need for a per-patch tracking mechanism (maybe?). Also, there will always be some difference, due to board support packages and new development areas (like ion), so the goal is not really 0 differences, but just a reduction overall. I'm not sure if we'll maintain this table or not, but I'm leaving it for now as a placeholder.''<br />
</div><br />
<br />
<br />
* diff of 2.6.29 kernel.org tree versus kernel<br />
{| border="1" cellspacing="0" cellpadding="5"<br />
|-bgcolor="#80c0d0"<br />
!Kernel Version<br />
!Files changed<br />
!insertions<br />
!deletions<br />
!hunks<br />
!bytes in diff<br />
|-<br />
|2.6.29 || 187 || 123506 || 0 || 187 || 3291827<br />
|-<br />
|}<br />
<br />
<br />
<br />
[[Category:Android]]</div>Consthttp://elinux.org/Device_driversDevice drivers2012-10-12T23:51:23Z<p>Const: exploring ldd3</p>
<hr />
<div>Sample drivers:<br />
* [https://github.com/makelinux/ldt/ LDT - Linux Driver Template] - sample template of Linux device driver for learning and starting source for a custom driver. Implements UART char device driver for example. Uses following Linux facilities: module, platform driver, file operations (read/write, mmap, ioctl, blocking and nonblocking mode, polling), kfifo, completion, interrupt, tasklet, work, kthread, timer, misc device, proc fs, UART 0x3f8, HW loopback, SW loopback, ftracer. The code is in working condition and runs with test script.<br />
* [https://github.com/martinezjavier/ldd3/ LDD3 - Samples for boot Linux Device Driver, 3rd edition, updated], compiled with kernel 3.2.0<br />
** [https://github.com/martinezjavier/ldd3/blob/master/pci/pci_skel.c pci_skel.c] - PCI skeleton <br />
** [https://github.com/martinezjavier/ldd3/blob/master/sbull/sbull.c sbull.c] - simple block device<br />
** [https://github.com/martinezjavier/ldd3/tree/master/scull scull] - simple char device<br />
** [https://github.com/martinezjavier/ldd3/blob/master/snull/snull.c snull.c] - simple network device<br />
* [http://lxr.free-electrons.com/source/drivers/media/video/vivi.c vivi.c - Virtual Video driver, uses V4L2] - works<br />
* [http://lxr.free-electrons.com/source/drivers/media/video/mem2mem_testdev.c mem2mem_testdev.c - virtual v4l2-mem2mem example device driver]<br />
* [http://lxr.free-electrons.com/source/drivers/usb/usb-skeleton.c usb-skeleton.c - USB driver skeleton] (can be compiled with trivial fix)<br />
* [http://lxr.free-electrons.com/source/drivers/video/skeletonfb.c skeletonfb.c - Frame Buffer device skeleton] (can't be compiled)<br />
* [http://lxr.free-electrons.com/source/drivers/pci/hotplug/pcihp_skeleton.c pcihp_skeleton.c - PCI Hot Plug Controller Skeleton Driver]<br />
* [http://lxr.free-electrons.com/source/drivers/net/loopback.c loopback.c - simple net_device implementing ifconfig lo]<br />
Manuals:<br />
* [http://en.wikibooks.org/wiki/The_Linux_Kernel Linux kernel internals reference, wikibook] - under construction<br />
* [http://www.makelinux.net/ldd3/ Linux Device Drivers, 3rd Edition]<br />
<br />
PS:<br />
*[[Firmware]] could be merged with this page</div>Consthttp://elinux.org/OMAP4430OMAP44302012-10-09T11:36:31Z<p>Const: /* Links */ OMAP4430 TRM online</p>
<hr />
<div>= OMAP™ 4 Key Benefits =<br />
<br />
* Designed to drive smart phones and Mobile Internet Devices (MIDs)<br />
* IVA 3 hardware accelerators enable full HD 1080p, multi-standard video encode/decode<br />
* Faster, higher-quality image and video capture with digital SLR-like imaging up to 20 megapixels<br />
* Dual-core ARM® Cortex™-A9 MPCore™ with Symmetric Multiprocessing (SMP)<br />
* Integrated POWERVR™ SGX540 graphics accelerator drives 3D gaming and 3D user interfaces<br />
* Highly optimized mobile applications platform<br />
* OMAP4430 operates at up to 1 GHz<br />
* OMAP4440 operates at 1+ GHz<br />
* Composite TV output<br />
* HDMI v1.3 output to drive HD displays<br />
* Larger, color rich display support up to WUXGA (1920 x 1200)<br />
* MIPI serial camera and serial display interfaces<br />
* MIPI® SLIMbusSM<br />
* MMC/SD<br />
* USB 2.0 On-The-Go High Speed<br />
* Comprehensive software suite supporting all major mobile OSes that is fully integrated and tested for real-world use cases to reduce development time and costs<br />
* OMAP Developer Network provides programs and media components for manufacturers to create distinctive products delivered to market quickly<br />
<br />
= Links =<br />
<br />
* [http://focus.ti.com/lit/ml/swpt034/swpt034.pdf Overview]<br />
* [http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=12843&contentId=53243 Product Page]<br />
* [http://makelinux.net/lib/ti/OMAP4430/ OMAP4430 TRM online]<br />
* [http://focus.ti.com/pdfs/wtbu/OMAP4430_ES2.x_Public_TRM_vK.zip Technical Reference Manual(TRM) pdf]<br />
<br />
= Platforms =<br />
<br />
* [http://omapedia.org/wiki/OMAP4_Blaze Omapedia Blaze Pages]<br />
* [http://omapedia.org/wiki/PandaBoard Omapedia PandaBoard Pages]<br />
* [[PandaBoard|elinux.org PandaBoard Pages]]<br />
<br />
<br />
<br />
[[category:omap4430]]<br />
[[category:PandaBoard]]</div>Consthttp://elinux.org/Device_driversDevice drivers2012-10-06T19:05:54Z<p>Const: </p>
<hr />
<div>Sample drivers:<br />
* [https://github.com/makelinux/ldt/ LDT - Linux Driver Template] - sample template of Linux device driver for learning and starting source for a custom driver. Implements UART char device driver for example. Uses following Linux facilities: module, platform driver, file operations (read/write, mmap, ioctl, blocking and nonblocking mode, polling), kfifo, completion, interrupt, tasklet, work, kthread, timer, misc device, proc fs, UART 0x3f8, HW loopback, SW loopback, ftracer. The code is in working condition and runs with test script.<br />
* [https://github.com/martinezjavier/ldd3/ LDD3 - Samples for boot Linux Device Driver, 3rd edition, updated], compiled with kernel 3.2.0<br />
* [http://lxr.free-electrons.com/source/drivers/media/video/vivi.c vivi.c - Virtual Video driver, uses V4L2] - works<br />
* [http://lxr.free-electrons.com/source/drivers/media/video/mem2mem_testdev.c mem2mem_testdev.c - virtual v4l2-mem2mem example device driver]<br />
* [http://lxr.free-electrons.com/source/drivers/usb/usb-skeleton.c usb-skeleton.c - USB driver skeleton] (can be compiled with trivial fix)<br />
* [http://lxr.free-electrons.com/source/drivers/video/skeletonfb.c skeletonfb.c - Frame Buffer device skeleton] (can't be compiled)<br />
* [http://lxr.free-electrons.com/source/drivers/pci/hotplug/pcihp_skeleton.c pcihp_skeleton.c - PCI Hot Plug Controller Skeleton Driver]<br />
* [http://lxr.free-electrons.com/source/drivers/net/loopback.c loopback.c - simple net_device implementing ifconfig lo]<br />
Manuals:<br />
* [http://en.wikibooks.org/wiki/The_Linux_Kernel Linux kernel internals reference, wikibook] - under construction<br />
* [http://www.makelinux.net/ldd3/ Linux Device Drivers, 3rd Edition]<br />
<br />
PS:<br />
*[[Firmware]] could be merged with this page</div>Consthttp://elinux.org/Device_driversDevice drivers2012-10-06T19:05:20Z<p>Const: </p>
<hr />
<div>Sample drivers:<br />
* [https://github.com/makelinux/ldt/ LDT - Linux Driver Template] - sample template of Linux device driver for learning and starting source for a custom driver. Implements UART char device driver for example. Uses following Linux facilities: module, platform driver, file operations (read/write, mmap, ioctl, blocking and nonblocking mode, polling), kfifo, completion, interrupt, tasklet, work, kthread, timer, misc device, proc fs, UART 0x3f8, HW loopback, SW loopback, ftracer. The code is in working condition and runs with test script.<br />
* [https://github.com/martinezjavier/ldd3/ LDD3 - Samples for boot Linux Device Driver, 3rd edition, updated], compiled with kernel 3.2.0<br />
* [http://lxr.free-electrons.com/source/drivers/media/video/vivi.c vivi.c - Virtual Video driver, uses V4L2] - works<br />
* [http://lxr.free-electrons.com/source/drivers/media/video/mem2mem_testdev.c mem2mem_testdev.c - virtual v4l2-mem2mem example device driver]<br />
* [http://lxr.free-electrons.com/source/drivers/usb/usb-skeleton.c usb-skeleton.c - USB driver skeleton] (can be compiled with trivial fix)<br />
* [http://lxr.free-electrons.com/source/drivers/video/skeletonfb.c skeletonfb.c - Frame Buffer device skeleton] (can't be compiled)<br />
* [http://lxr.free-electrons.com/source/drivers/pci/hotplug/pcihp_skeleton.c pcihp_skeleton.c - PCI Hot Plug Controller Skeleton Driver]<br />
* [http://lxr.free-electrons.com/source/drivers/net/loopback.c loopback.c - simple net_device implementing ifconfig lo]<br />
Manuals:<br />
* [http://en.wikibooks.org/wiki/The_Linux_Kernel Linux kernel internals reference, wikibook]<br />
* [http://www.makelinux.net/ldd3/ Linux Device Drivers, 3rd Edition]<br />
<br />
PS:<br />
*[[Firmware]] could be merged with this page</div>Consthttp://elinux.org/Device_driversDevice drivers2012-10-04T22:09:54Z<p>Const: </p>
<hr />
<div>Sample drivers:<br />
* [https://github.com/makelinux/ldt/ LDT - Linux Driver Template] - sample template of Linux device driver for learning and starting source for a custom driver. Implements UART char device driver for example. Uses following Linux facilities: module, platform driver, file operations (read/write, mmap, ioctl, blocking and nonblocking mode, polling), kfifo, completion, interrupt, tasklet, work, kthread, timer, misc device, proc fs, UART 0x3f8, HW loopback, SW loopback, ftracer. The code is in working condition and runs with test script.<br />
* [https://github.com/martinezjavier/ldd3/ LDD3 - Samples for boot Linux Device Driver, 3rd edition, updated], compiled with kernel 3.2.0<br />
* [http://lxr.free-electrons.com/source/drivers/media/video/vivi.c vivi.c - Virtual Video driver, uses V4L2]<br />
* [http://lxr.free-electrons.com/source/drivers/media/video/mem2mem_testdev.c mem2mem_testdev.c - virtual v4l2-mem2mem example device driver]<br />
* [http://lxr.free-electrons.com/source/drivers/usb/usb-skeleton.c usb-skeleton.c - USB driver skeleton] (can be compiled with trivial fix)<br />
* [http://lxr.free-electrons.com/source/drivers/video/skeletonfb.c skeletonfb.c - Frame Buffer device skeleton] (can't be compiled)<br />
* [http://lxr.free-electrons.com/source/drivers/pci/hotplug/pcihp_skeleton.c pcihp_skeleton.c - PCI Hot Plug Controller Skeleton Driver]<br />
* [http://lxr.free-electrons.com/source/drivers/net/loopback.c loopback.c - simple net_device implementing ifconfig lo]<br />
Manuals:<br />
* [http://en.wikibooks.org/wiki/The_Linux_Kernel Linux kernel internals reference, wikibook]<br />
* [http://www.makelinux.net/ldd3/ Linux Device Drivers, 3rd Edition]<br />
<br />
PS:<br />
*[[Firmware]] could be merged with this page</div>Consthttp://elinux.org/Device_driversDevice drivers2012-10-04T22:09:33Z<p>Const: Firmware</p>
<hr />
<div>Sample drivers:<br />
* [https://github.com/makelinux/ldt/ LDT - Linux Driver Template] - sample template of Linux device driver for learning and starting source for a custom driver. Implements UART char device driver for example. Uses following Linux facilities: module, platform driver, file operations (read/write, mmap, ioctl, blocking and nonblocking mode, polling), kfifo, completion, interrupt, tasklet, work, kthread, timer, misc device, proc fs, UART 0x3f8, HW loopback, SW loopback, ftracer. The code is in working condition and runs with test script.<br />
* [https://github.com/martinezjavier/ldd3/ LDD3 - Samples for boot Linux Device Driver, 3rd edition, updated], compiled with kernel 3.2.0<br />
* [http://lxr.free-electrons.com/source/drivers/media/video/vivi.c vivi.c - Virtual Video driver, uses V4L2]<br />
* [http://lxr.free-electrons.com/source/drivers/media/video/mem2mem_testdev.c mem2mem_testdev.c - virtual v4l2-mem2mem example device driver]<br />
* [http://lxr.free-electrons.com/source/drivers/usb/usb-skeleton.c usb-skeleton.c - USB driver skeleton] (can be compiled with trivial fix)<br />
* [http://lxr.free-electrons.com/source/drivers/video/skeletonfb.c skeletonfb.c - Frame Buffer device skeleton] (can't be compiled)<br />
* [http://lxr.free-electrons.com/source/drivers/pci/hotplug/pcihp_skeleton.c pcihp_skeleton.c - PCI Hot Plug Controller Skeleton Driver]<br />
* [http://lxr.free-electrons.com/source/drivers/net/loopback.c loopback.c - simple net_device implementing ifconfig lo]<br />
Manuals:<br />
* [http://en.wikibooks.org/wiki/The_Linux_Kernel Linux kernel internals reference, wikibook]<br />
* [http://www.makelinux.net/ldd3/ Linux Device Drivers, 3rd Edition]<br />
<br />
PS:<br />
*[Firmware] could be merged with this page</div>Consthttp://elinux.org/Device_driversDevice drivers2012-10-04T21:58:17Z<p>Const: + loopback.c</p>
<hr />
<div>Sample drivers:<br />
* [https://github.com/makelinux/ldt/ LDT - Linux Driver Template] - sample template of Linux device driver for learning and starting source for a custom driver. Implements UART char device driver for example. Uses following Linux facilities: module, platform driver, file operations (read/write, mmap, ioctl, blocking and nonblocking mode, polling), kfifo, completion, interrupt, tasklet, work, kthread, timer, misc device, proc fs, UART 0x3f8, HW loopback, SW loopback, ftracer. The code is in working condition and runs with test script.<br />
* [https://github.com/martinezjavier/ldd3/ LDD3 - Samples for boot Linux Device Driver, 3rd edition, updated], compiled with kernel 3.2.0<br />
* [http://lxr.free-electrons.com/source/drivers/media/video/vivi.c vivi.c - Virtual Video driver, uses V4L2]<br />
* [http://lxr.free-electrons.com/source/drivers/media/video/mem2mem_testdev.c mem2mem_testdev.c - virtual v4l2-mem2mem example device driver]<br />
* [http://lxr.free-electrons.com/source/drivers/usb/usb-skeleton.c usb-skeleton.c - USB driver skeleton] (can be compiled with trivial fix)<br />
* [http://lxr.free-electrons.com/source/drivers/video/skeletonfb.c skeletonfb.c - Frame Buffer device skeleton] (can't be compiled)<br />
* [http://lxr.free-electrons.com/source/drivers/pci/hotplug/pcihp_skeleton.c pcihp_skeleton.c - PCI Hot Plug Controller Skeleton Driver]<br />
* [http://lxr.free-electrons.com/source/drivers/net/loopback.c loopback.c - simple net_device implementing ifconfig lo]<br />
Manuals:<br />
* [http://en.wikibooks.org/wiki/The_Linux_Kernel Linux kernel internals reference, wikibook]<br />
* [http://www.makelinux.net/ldd3/ Linux Device Drivers, 3rd Edition]</div>Consthttp://elinux.org/Device_driversDevice drivers2012-10-04T21:57:15Z<p>Const: loopback.c</p>
<hr />
<div>Sample drivers:<br />
* [https://github.com/makelinux/ldt/ LDT - Linux Driver Template] - sample template of Linux device driver for learning and starting source for a custom driver. Implements UART char device driver for example. Uses following Linux facilities: module, platform driver, file operations (read/write, mmap, ioctl, blocking and nonblocking mode, polling), kfifo, completion, interrupt, tasklet, work, kthread, timer, misc device, proc fs, UART 0x3f8, HW loopback, SW loopback, ftracer. The code is in working condition and runs with test script.<br />
* [https://github.com/martinezjavier/ldd3/ LDD3 - Samples for boot Linux Device Driver, 3rd edition, updated], compiled with kernel 3.2.0<br />
* [http://lxr.free-electrons.com/source/drivers/media/video/vivi.c vivi.c - Virtual Video driver, uses V4L2]<br />
* [http://lxr.free-electrons.com/source/drivers/media/video/mem2mem_testdev.c mem2mem_testdev.c - virtual v4l2-mem2mem example device driver]<br />
* [http://lxr.free-electrons.com/source/drivers/usb/usb-skeleton.c usb-skeleton.c - USB driver skeleton] (can be compiled with trivial fix)<br />
* [http://lxr.free-electrons.com/source/drivers/video/skeletonfb.c skeletonfb.c - Frame Buffer device skeleton] (can't be compiled)<br />
* [http://lxr.free-electrons.com/source/drivers/pci/hotplug/pcihp_skeleton.c pcihp_skeleton.c - PCI Hot Plug Controller Skeleton Driver]<br />
* [./drivers/net/loopback.c loopback.c - simple net_device implementing ifconfig lo]<br />
Manuals:<br />
* [http://en.wikibooks.org/wiki/The_Linux_Kernel Linux kernel internals reference, wikibook]<br />
* [http://www.makelinux.net/ldd3/ Linux Device Drivers, 3rd Edition]</div>Consthttp://elinux.org/ToolboxToolbox2012-10-04T21:34:05Z<p>Const: </p>
<hr />
<div>This page has information about developing Embedded Linux, including links to toolchains, debuggers and other development tools. Also, it has links to pages with debugging tips.<br />
<br />
<div style="width=100%; background:#FFF;"><br />
{| width="100%" cellspacing="5" cellpadding="0" valign="top" style="background:inherit;"<br />
| valign="top" style="margin: 0 0 0.5em 1em; border:1px solid #aaa; text-align:left; width: 33%;" cellpadding="5" |<br />
<div style="background: #eeeeee; border: 1px solid #2C547A; padding: 5px; margin: 3px; font-weight:bold;text-align:center;font-size:120%;">Development Tools</div><br />
<div style="margin: 0 0 0 1em;"><br />
;[[Logic_Analyzers]]<br />
;[[Toolchains]]<br />
;[[Build Systems]]<br />
;[[Embedded Linux Distributions]]<br />
;[[Debuggers]]<br />
;[[Memory Debuggers]]<br />
;[[Tools]]<br />
;[[Integrated Development Environments]]<br />
;[[Emulators]]<br />
;[[Tracers and Profilers]]<br />
;[[Benchmark Programs | Benchmarks]]<br />
;[[Source Management Tools]]<br />
;[[Test Systems]]<br />
<br />
</div><br />
| valign="top" style="margin: 0 0 0.5em 1em; border:1px solid #aaa; text-align:left; width: 33%;" cellpadding="5"|<br />
<div style="background: #eeeeee; border: 1px solid #2C547A; padding: 5px; margin: 3px; font-weight:bold;text-align:center;font-size:120%;">Developer Resources </div><br />
<div style="margin: 0 0 0 1em;"><br />
;[[Linux Kernel Resources]]<br />
;Kernel Subsystems<br />
*[http://www.linusakesson.net/programming/tty/index.php The TTY Demystified] - excellent explanation of kernel tty system<br />
* [[Device Trees]] - a structure used to describe system hardware at startup - can be passed or modified by firmware, or built into kernel<br />
;Online Documentation <br />
* [http://kernel.org/doc/ols/ Papers from the Ottawa Linux Symposium]<br />
* [http://free-electrons.com/training/devtools Free Software tools for embedded systems]<br />
* [http://free-electrons.com/articles/realtime/ Real time in embedded Linux systems]<br />
* [http://free-electrons.com/articles/optimizations Embedded Linux optimizations]<br />
* [http://free-electrons.com/training/audio Audio in embedded Linux systems]<br />
* [http://free-electrons.com/training/multimedia Multimedia in embedded Linux systems] <br />
* [http://free-electrons.com/articles/elfs/ Embedded Linux From Scratch... in 40 minutes!] <br />
* [http://www.makelinux.net/reference Linux technology reference]<br />
;[[:Category:Books| Books]]<br />
;[[Reference Material]]<br />
;[[Podcasts]]<br />
;[[Device drivers]]<br />
</div><br />
|-<br />
| valign="top" style="margin: 0 0 0.5em 1em; border:1px solid #aaa; text-align:left; width: 33%;" cellpadding="5"|<br />
<div style="background: #eeeeee; border: 1px solid #2C547A; padding: 5px; margin: 3px; font-weight:bold;text-align:center;font-size:120%;">Tips and Tricks</div><br />
<div style="margin: 0 0 0 1em;"><br />
;[[Chip_Identification|How to Identify IC Markings]]<br />
;[[Code Styling Tips]]<br />
;[[Debugging Tips]]<br />
;[[GDB Tips]]<br />
;[[GCC Tips]]<br />
;[[:Category:Tips and Tricks]]<br />
</div><br />
<br />
| valign="top" style="margin: 0 0 0.5em 1em; border:1px solid #aaa; text-align:left; width: 33%;" cellpadding="5"|<br />
<div style="background: #eeeeee; border: 1px solid #2C547A; padding: 5px; margin: 3px; font-weight:bold;text-align:center;font-size:120%;">Misc & Wishlist</div><br />
<div style="margin: 0 0 0 1em;"><br />
;[[Bluetooth Network| Setting up a Bluetooth Network]]<br />
;[[Continuous Logging for Watchdog Timer Expiration]]<br />
;[[Crash Diagnostics]]<br />
<br />
</div><br />
|}<br />
</div><br />
[[Category:Development Tools]]<br />
[[Category:Tips and Tricks]]</div>Consthttp://elinux.org/Device_driversDevice drivers2012-10-04T21:30:30Z<p>Const: + video drivers</p>
<hr />
<div>Sample drivers:<br />
* [https://github.com/makelinux/ldt/ LDT - Linux Driver Template] - sample template of Linux device driver for learning and starting source for a custom driver. Implements UART char device driver for example. Uses following Linux facilities: module, platform driver, file operations (read/write, mmap, ioctl, blocking and nonblocking mode, polling), kfifo, completion, interrupt, tasklet, work, kthread, timer, misc device, proc fs, UART 0x3f8, HW loopback, SW loopback, ftracer. The code is in working condition and runs with test script.<br />
* [https://github.com/martinezjavier/ldd3/ LDD3 - Samples for boot Linux Device Driver, 3rd edition, updated], compiled with kernel 3.2.0<br />
* [http://lxr.free-electrons.com/source/drivers/media/video/vivi.c vivi.c - Virtual Video driver, uses V4L2]<br />
* [http://lxr.free-electrons.com/source/drivers/media/video/mem2mem_testdev.c mem2mem_testdev.c - virtual v4l2-mem2mem example device driver]<br />
* [http://lxr.free-electrons.com/source/drivers/usb/usb-skeleton.c usb-skeleton.c - USB driver skeleton] (can be compiled with trivial fix)<br />
* [http://lxr.free-electrons.com/source/drivers/video/skeletonfb.c skeletonfb.c - Frame Buffer device skeleton] (can't be compiled)<br />
* [http://lxr.free-electrons.com/source/drivers/pci/hotplug/pcihp_skeleton.c pcihp_skeleton.c - PCI Hot Plug Controller Skeleton Driver]<br />
Manuals:<br />
* [http://en.wikibooks.org/wiki/The_Linux_Kernel Linux kernel internals reference, wikibook]<br />
* [http://www.makelinux.net/ldd3/ Linux Device Drivers, 3rd Edition]</div>Consthttp://elinux.org/Device_driversDevice drivers2012-10-04T20:44:43Z<p>Const: + kernel skeletons, ldd3 samples</p>
<hr />
<div>External links:<br />
* [https://github.com/makelinux/ldt/ LDT - Linux Driver Template] - sample template of Linux device driver for learning and starting source for a custom driver. Implements UART char device driver for example. Uses following Linux facilities: module, platform driver, file operations (read/write, mmap, ioctl, blocking and nonblocking mode, polling), kfifo, completion, interrupt, tasklet, work, kthread, timer, misc device, proc fs, UART 0x3f8, HW loopback, SW loopback, ftracer. The code is in working condition and runs with test script.<br />
* [https://github.com/martinezjavier/ldd3/ Samples for boot Linux Device Driver, 3rd edition, updated], compiled with kernel 3.2.0<br />
* [http://lxr.free-electrons.com/source/drivers/usb/usb-skeleton.c USB driver skeleton] (can be compiled with trivial fix)<br />
* [http://lxr.free-electrons.com/source/drivers/video/skeletonfb.c Frame Buffer device skeleton] (can't be compiled)<br />
* [http://lxr.free-electrons.com/source/drivers/pci/hotplug/pcihp_skeleton.c PCI Hot Plug Controller Skeleton Driver]<br />
* [http://en.wikibooks.org/wiki/The_Linux_Kernel Linux kernel internals reference, wikibook]<br />
* [http://www.makelinux.net/ldd3/ Linux Device Drivers, 3rd Edition]</div>Consthttp://elinux.org/Device_driversDevice drivers2012-10-02T13:20:52Z<p>Const: </p>
<hr />
<div>External links:<br />
* [https://github.com/makelinux/ldt/ LDT - Linux Driver Template] - sample template of Linux device driver for learning and starting source for a custom driver.<br />
* [http://en.wikibooks.org/wiki/The_Linux_Kernel Linux kernel internals reference, wikibook]<br />
* [http://www.makelinux.net/ldd3/ Linux Device Drivers, 3rd Edition]</div>Consthttp://elinux.org/Device_driversDevice drivers2012-10-02T13:19:32Z<p>Const: </p>
<hr />
<div>External links:<br />
* [https://github.com/makelinux/ldt/ LDT - Linux Driver Template] - sample template of Linux device driver for learning and could be start point for a custom driver.<br />
* [http://en.wikibooks.org/wiki/The_Linux_Kernel Linux kernel internals reference, wikibook]<br />
* [http://www.makelinux.net/ldd3/ Linux Device Drivers, 3rd Edition]</div>Consthttp://elinux.org/Device_driversDevice drivers2012-10-02T11:58:24Z<p>Const: </p>
<hr />
<div>Link for [[Main Page]]: [[image:steering wheel.svg|link=Device drivers]] [[Device drivers]]<br />
<br />
External links:<br />
* https://github.com/makelinux/ldt/<br />
* http://en.wikibooks.org/wiki/The_Linux_Kernel<br />
* http://www.makelinux.net/ldd3/</div>Consthttp://elinux.org/File:Steering_wheel.svgFile:Steering wheel.svg2012-10-02T11:53:36Z<p>Const: uploaded a new version of &quot;File:Steering wheel.svg&quot;</p>
<hr />
<div></div>Consthttp://elinux.org/Device_driversDevice drivers2012-10-02T11:50:23Z<p>Const: </p>
<hr />
<div>Link for [[Main Page]]: [[image:steering wheel.svg|link=Device drivers]] [[Device drivers]]<br />
<br />
External links:<br />
* https://github.com/makelinux/ldt/<br />
* http://www.makelinux.net/ldd3/</div>Consthttp://elinux.org/File:Steering_wheel.svgFile:Steering wheel.svg2012-10-02T11:43:48Z<p>Const: </p>
<hr />
<div></div>Consthttp://elinux.org/Device_driversDevice drivers2012-10-02T11:42:47Z<p>Const: Created page with "External links: * https://github.com/makelinux/ldt/ * http://www.makelinux.net/ldd3/"</p>
<hr />
<div>External links:<br />
* https://github.com/makelinux/ldt/<br />
* http://www.makelinux.net/ldd3/</div>Consthttp://elinux.org/Android_Kernel_DownloadAndroid Kernel Download2012-09-27T08:12:30Z<p>Const: link to google</p>
<hr />
<div>See http://source.android.com/source/building-kernels.html<br />
<br />
Most of following information is outdated. <br />
<br />
== Main Google Android Kernels ==<br />
The main Google repository with Android source code is at: http://android.git.kernel.org/<br />
<br />
There are (as of September 2009) 4 main separate kernel repositories at that site:<br />
* common<br />
* experimental<br />
* msm<br />
* omap<br />
<br />
To download one of these and use it directly, you can use git.<br />
For example:<br />
git clone git://android.git.kernel.org/kernel/common.git kernel<br />
<br />
To preserve your sanity, it's probably worth downloading this into a 'kernel' directory<br />
in your overall Android source directory scheme<br />
<br />
You can use<br />
repo, following the instructions at http://source.android.com/download, to pull down<br />
the entire Android source. However, when you download the rest of the Android source code, using the 'repo'<br />
command, you do NOT automatically get a kernel tree included. That is, a kernel<br />
git tree is not referenced in the default Android manifest file, <br />
<br />
To add projects, such as the kernel, to your overall Android repository scheme, you add the appropriate kernel repository<br />
to your local manifest.xml file. This file is located in the .repo directory.<br />
<br />
To include the kernel/common tree, include a line like this in .repo/manifest.xml:<br />
<br />
<project path="kernel/common" name="kernel/common" /><br />
<br />
The complete list of projects (including other kernel options besides kernel/common)<br />
is listed on http://android.git.kernel.org/. <br />
<br />
Note that the default revision for <br />
git repositories is specified in the <default> tag in manifest.xml as "revision=master"<br />
but the kernel/common repository may not have a head called "master". In that case<br />
if you just type "repo sync kernel/common" you may see the message:<br />
<br />
<pre><br />
error: revision master in kernel/common not found<br />
</pre><br />
<br />
Typically the heads in the kernel/common repository will be called<br />
android-2.6.x (where x is the kernel number); specifying this number in the manifest<br />
should allow repo to sync properly, i.e.:<br />
<br />
<project path="kernel/common" name="kernel/common" revision="android-2.6.27"/><br />
<br />
You can view the heads by clicking on the project link from http://android.git.kernel.org/. <br />
<br />
For more about repo, see http://source.android.com/download/using-repo<br />
<br />
== Other Repositories with Android-specific changes ==<br />
* Linux kernel for omap and beagle-board, by Embinux: http://labs.embinux.org/git/cgit.cgi/repo/kernel.git<br />
** clone with: git clone git://labs.embinux.org/repo/kernel.git kernel<br />
<br />
== 'Raw' Android kernel patches ==<br />
I do not know of any freely available patches for the Linux kernel with the Android<br />
fixes, as of November 2009. I have, however, heard of multiple efforts to extract<br />
the patches to make it easier to port the Android kernel features onto newer Linux<br />
kernels.<br />
<br />
Here is a way of extracting raw Android patches at a certain point in time, though<br />
this may be dated:<br />
<br />
<pre><br />
git clone git://android.git.kernel.org/kernel/common.git android-kernel<br />
cd android-kernel<br />
git checkout --track -b android-2.6.32 origin/android-2.6.32<br />
git fetch --tags git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.32.y.git<br />
git shortlog v2.6.32.9..HEAD<br />
git format-patch v2.6.32.9..HEAD<br />
</pre><br />
<br />
Sum total 173 patches for the 2.6.32.9 kernel as of writing.<br />
<br />
If anyone knows where raw android kernel patches are available, please add a link<br />
here. See also the [[Android Kernel Features]] page for more information about<br />
individual kernel features.<br />
<br />
[[Category:Android]]</div>Consthttp://elinux.org/GrabserialGrabserial2011-09-24T20:03:30Z<p>Const: /* Download and Installation */ + time delta</p>
<hr />
<div>grabserial - grab serial port output<br />
<br />
== Introduction ==<br />
grabserial is a small program which reads a serial port and writes the<br />
data to standard output. The main purpose of this tool is to collect<br />
messages written to the serial console from a target board running<br />
Linux, and save the messages on a host machine.<br />
<br />
== Download and Installation ==<br />
Download latest grabserial with time delta here: http://makelinux.com/emb/grabserial<br />
<br />
Previous version is [[Media:grabserial]]<br />
<br />
''Note: Due to MediaWiki stupidity, this file downloads with a leading upper-case letter. Please rename to lowercase on download (e.g. "mv Grabserial grabserial")''<br />
<br />
To install, merely place 'grabserial' on the path. This would work:<br />
su root ; mv grabserial /usr/local/bin<br />
<br />
grabserial requires the python "serial" module. This module is not shipped with<br />
most distributions of python by default. On some recent distributions of Linux<br />
pyserial is available as a package. For example, to install it on Fedora 12,<br />
do this (as root): 'yum -y install pyserial'<br />
<br />
Here's a copy you can install<br />
if you don't have it. (You can check if you already have it by typing:<br />
'python', then "import serial" in the interactive python interpreter.<br />
<br />
<br />
[[Media:pyserial-2.2.zip]]<br />
<br />
To install this, download the archive, unzip it, and following the installation<br />
instructions in pyserial-2.2/README.txt.<br />
<br />
The latest Pyserial can be obtained from: [http://pypi.python.org/pypi/pyserial]<br />
The current version as of November 2008 is 2.4, which is newer than what I've<br />
got here.<br />
<br />
== Usage ==<br />
The grabserial program is very simple, but it provides some useful<br />
extra features that make it more than a mere 'cat' program.<br />
<br />
Use 'grabserial -h' to see online usage for the program.<br />
<br />
You can specify the serial configuration options, including the Linux<br />
device node to use, and the port speed settings on the grabserial<br />
command line. If no options are specified, grabserial uses serial port<br />
/dev/ttyS0, at 115200 baud with "8, None and 1" (8N1)<br />
settings.<br />
<br />
Normally, the program runs in an infinite loop,<br />
reading from the serial port and writing to standard out until it is<br />
interrupted by the user (usually by typing control-C). However, you<br />
can tell the program to stop after a certain amount of time. This is<br />
useful for including the script in automated test scenarios.<br />
<br />
Also, you can tell the program to provide timing information for each<br />
line received. This is useful to measure the time it takes for events<br />
to happen on the target. A common thing to measure on<br />
a target running embedded Linux is bootup time.<br />
With grabserial, you can specify a pattern<br />
to match against the lines read from the serial port. When this<br />
pattern is seen, it sets a "base time", and all subsequent time values<br />
printed out will be relative to this base. Thus, you can customize<br />
the start time for the time measurements, to make it easier to see the<br />
duration of events in the system.<br />
<br />
== Usage Examples ==<br />
Here are some examples of use:<br />
<br />
grabserial<br />
<br />
This will echo data seen on device /dev/ttyS0, until the user pressed ctrl-C.<br />
<br />
grabserial -v -d "/dev/ttyUSB0" -b 115200 -w 8 -p N -s 1 -e 30 -t -m "Starting kernel.*" <br />
<br />
This opens /dev/ttyUSB0, at baud rate 115200, and 8-bit chars, No parity and 1 stop bit.<br />
This will capture and display data for 30 seconds, putting a timestamp on each line<br />
received, and restarting the timestamp at 0 when a line containing "Kernel start" is seen.<br />
The '-v' makes grabserial verbose (printing some extra messages before starting.<br />
<br />
If you want to use grabserial with minicom on the same serial port without conflict, for example to temporarily set a boot parameter or specify a different kernel image without changing the parameters in flash, you could follow this procedure:<br />
* Prepare the grabserial command in one window but don't hit enter.<br />
* Open minicom and set the bootloader environment, bootargs, etc. and tftp the kernel.<br />
* Use one bootloader command to delay a few seconds and boot. For u-boot this is done with something like: "sleep 5; bootm 0x80000000".<br />
* Immediately exit minicom and run grabserial. After the delay expires, grabserial measures boot output.<br />
<br />
== Sample Output ==<br />
Here is sample output from grabserial. This shows the reboot of an ARM-based system (OMAP Starter Kit).<br />
Note that the U-Boot prompt appears at time 1.084614. The grabserial command specifies to restart the<br />
timestamps when "Starting kernel.*" is seen. This happens at time 11.557150 after grabserial was started.<br />
<br />
Note that the first kernel message appears 3.14 seconds later. Actually, the kernel starts well before this,<br />
but it takes this long before the kernel to initialize the serial port and start emitting messages. You will<br />
notice that a bunch of messages come out in rapid succession. These are messages that were queued up during<br />
the boot, before the serial console was initialized.<br />
<br />
<pre><br />
[tbird@timdesk grabserial]$ ./grabserial -v -e 60 -t -m "Starting kernel.*" <br />
Opening serial port /dev/ttyS0<br />
115200:8N1:xonxoff=0:rtcdtc=0<br />
Program will end in 60 seconds<br />
Printing timing information for each line<br />
Matching pattern 'Starting kernel.*' to set base time<br />
Use Control-C to stop...<br />
[ 0.000004] Killed<br />
[ 0.080060] <br />
[ 0.080268] <br />
[ 0.080329] BusyBox v1.01 (2006.05.09-03:34+0000) Built-in shell (ash)<br />
[ 0.088362] Enter 'help' for a list of built-in commands.<br />
[ 0.093054] <br />
[ 0.093136] ash: can't access tty; job control turned off<br />
[ 0.096457] / # Restarting system.<br />
[ 1.004806] .<br />
[ 1.084345] <br />
[ 1.084553] <br />
[ 1.084614] U-Boot 1.1.4 (Sep 5 2006 - 17:59:15)<br />
[ 1.089194] <br />
[ 1.089263] CPU: OMAP1611b at 96.0 MHz (DPLL1=96.0 MHz)<br />
[ 1.093231] Board: OSK5912<br />
[ 1.096895] DRAM: 32 MB<br />
[ 1.099982] Flash: 32 MB<br />
[ 1.200071] In: serial<br />
[ 1.200677] Out: serial<br />
[ 1.201184] Err: serial<br />
[ 1.428094] Hit any key to stop autoboot: 4 ��� 3 ��� 2 ��� 1 ��� 0 <br />
[ 5.428690] Using MAC Address 00:0E:99:02:06:83<br />
[ 5.432732] BOOTP broadcast 1<br />
[ 5.588358] DHCP client bound to address 192.168.2.74<br />
[ 5.593211] TFTP from server 192.168.2.1; our IP address is 192.168.2.74<br />
[ 5.600801] Filename 'osk4/boot/uImage.osk4'.<br />
[ 5.602047] Load address: 0x10000000<br />
[ 5.605179] Loading: *�#################################################################<br />
[ 6.520688] #################################################################<br />
[ 7.420636] #################################################################<br />
[ 8.309524] #################################################################<br />
[ 9.205599] #############################<br />
[ 9.608708] done<br />
[ 9.613735] Bytes transferred = 1477696 (168c40 hex)<br />
[ 10.144643] ## Booting image at 10000000 ...<br />
[ 10.145944] Image Name: Linux-2.6.16.24-alp<br />
[ 10.149553] Image Type: ARM Linux Kernel Image (uncompressed)<br />
[ 10.153733] Data Size: 1477632 Bytes = 1.4 MB<br />
[ 10.158305] Load Address: 10008000<br />
[ 10.161113] Entry Point: 10008000<br />
[ 10.162053] Verifying Checksum ... OK<br />
[ 11.556790] OK<br />
[ 11.557086] <br />
[ 11.557150] Starting kernel ...<br />
[ 0.004158] <br />
[ 0.015515] Uncompressing Linux................................................................................................. done, booting the kernel.<br />
[ 3.143765] Linux version 2.6.16.24-alp (tbird@timdesk.am.sony.com) (gcc version 3.4.4) #1 PREEMPT Wed Sep 6 14:16:46 PDT 2006<br />
[ 3.153071] CPU: ARM926EJ-Sid(wt) [41069263] revision 3 (ARMv5TEJ)<br />
[ 3.159875] Machine: TI-OSK<br />
[ 3.160508] Memory policy: ECC disabled, Data cache writethrough<br />
[ 3.164693] OMAP1611b revision 2 handled as 16xx id: eb058f7948920b0d<br />
[ 3.178089] SRAM: Mapped pa 0x20000000 to va 0xd0000000 size: 0x3f000<br />
[ 3.180327] CPU0: D VIVT write-back cache<br />
[ 3.181426] CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets<br />
[ 3.184500] CPU0: D cache: 8192 bytes, associativity 4, 32 byte lines, 64 sets<br />
[ 3.189360] Built 1 zonelists<br />
[ 3.200389] Kernel command line: mem=32M console=ttyS0,115200n8 noinitrd ip=bootp root=/dev/nfs<br />
[ 3.203340] Clocks: ARM_SYSST: 0x1000 DPLL_CTL: 0x2833 ARM_CKCTL: 0x2000<br />
[ 3.209108] Clocking rate (xtal/DPLL1/MPU): 12.0/192.0/192.0 MHz<br />
[ 3.211017] Total of 128 interrupts in 4 interrupt banks<br />
[ 3.213020] OMAP GPIO hardware version 1.0<br />
[ 3.216794] MUX: initialized M7_1610_GPIO62<br />
[ 3.220452] MUX: Setting register M7_1610_GPIO62<br />
[ 3.224991] FUNC_MUX_CTRL_10 (0xfffe1098) = 0x00018000 -> 0x00018000<br />
[ 3.228452] PULL_DWN_CTRL_4 (0xfffe10ac) = 0x00000000 -> 0x01000000<br />
[ 3.232948] PID hash table entries: 256 (order: 8, 4096 bytes)<br />
[ 3.237881] OMAP MPU timers initialized<br />
[ 3.241442] Console: colour dummy device 80x30<br />
[ 3.252541] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)<br />
[ 3.254785] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)<br />
[ 3.260600] Memory: 32MB = 32MB total<br />
[ 3.261561] Memory: 29268KB available (2465K code, 534K data, 108K init)<br />
[ 3.263737] Mount-cache hash table entries: 512<br />
[ 3.265025] CPU: Testing write buffer coherency: ok<br />
[ 3.273364] NET: Registered protocol family 16<br />
[ 3.274672] MUX: Setting register N15_1610_MPUIO2<br />
[ 3.280363] FUNC_MUX_CTRL_7 (0xfffe1020) = 0x00000000 -> 0x00000000<br />
[ 3.282539] PU_PD_SEL_1 (0xfffe10b8) = 0x00000000 -> 0x00000000<br />
[ 3.287859] PULL_DWN_CTRL_1 (0xfffe1044) = 0x00000000 -> 0x00000000<br />
[ 3.292311] OMAP DMA hardware version 1<br />
[ 3.296097] DMA capabilities: 000c0000:00000000:01ff:003f:007f<br />
[ 3.301143] Initializing OMAP McBSP system<br />
[ 3.302266] omap_dsp_init() done<br />
[ 3.304250] USB: hmc 16, usb0 2 wires<br />
[ 3.307814] i2c_omap i2c_omap.1: bus 0 rev2.2 at 100 kHz<br />
[ 3.309446] tps65010: version 2 May 2005<br />
[ 3.321770] MUX: initialized N14_1610_UWIRE_CS0<br />
[ 3.323110] MUX: Setting register N14_1610_UWIRE_CS0<br />
[ 3.328448] FUNC_MUX_CTRL_8 (0xfffe1024) = 0x00001200 -> 0x00001200<br />
[ 3.330625] PULL_DWN_CTRL_1 (0xfffe1044) = 0x00000000 -> 0x00200000<br />
[ 3.336881] MUX: initialized P15_1610_UWIRE_CS3<br />
[ 3.338189] MUX: Setting register P15_1610_UWIRE_CS3<br />
[ 3.339625] FUNC_MUX_CTRL_8 (0xfffe1024) = 0x00001200 -> 0x00001200<br />
[ 3.346287] PULL_DWN_CTRL_1 (0xfffe1044) = 0x00200000 -> 0x00600000<br />
[ 3.357323] SCSI subsystem initialized<br />
[ 3.358316] usbcore: registered new driver usbfs<br />
[ 3.359668] usbcore: registered new driver hub<br />
[ 3.360912] MUX: initialized P18_1610_GPIO3<br />
[ 3.362060] MUX: Setting register P18_1610_GPIO3<br />
[ 3.364527] FUNC_MUX_CTRL_7 (0xfffe1020) = 0x00000000 -> 0x00000000<br />
[ 3.369310] PULL_DWN_CTRL_1 (0xfffe1044) = 0x00600000 -> 0x00600100<br />
[ 3.376092] MUX: Setting register MPUIO4<br />
[ 3.377174] FUNC_MUX_CTRL_7 (0xfffe1020) = 0x00000000 -> 0x00000000<br />
[ 3.385256] PULL_DWN_CTRL_1 (0xfffe1044) = 0x00600100 -> 0x00600100<br />
[ 3.389801] NetWinder Floating Point Emulator V0.97 (double precision)<br />
[ 3.393302] OMAP OCPI interconnect driver loaded<br />
[ 3.396960] squashfs: version 3.0 (2006/03/15) Phillip Lougher<br />
[ 3.402174] Initializing Cryptographic API<br />
[ 3.404791] io scheduler noop registered<br />
[ 3.408466] io scheduler anticipatory registered (default)<br />
[ 3.412313] io scheduler deadline registered<br />
[ 3.413490] io scheduler cfq registered<br />
[ 3.417385] omapfb: configured for panel osk<br />
[ 3.420454] omapfb-lcdc: init<br />
[ 3.421153] omapfb-lcdc: Pixel clock divider value is obsolete.<br />
[ 3.425363] omapfb-lcdc: Try to set pixel_clock to 8000 and pcd to 0 in drivers/video/omap/lcd_osk.c and submit a patch.<br />
[ 3.436613] MUX: initialized PWL<br />
[ 3.437431] MUX: Setting register PWL<br />
[ 3.440454] FUNC_MUX_CTRL_6 (0xfffe101c) = 0x00000001 -> 0x00000009<br />
[ 3.445116] PULL_DWN_CTRL_0 (0xfffe1040) = 0x00000000 -> 0x00000000<br />
[ 3.452227] Console: switching to colour frame buffer device 30x40<br />
[ 3.456534] omapfb: initialized vram=1048576 pixclock 8000 kHz hfreq 20.1 kHz vfreq 63.3 Hz<br />
[ 3.465909] OMAP RTC Driver<br />
[ 3.466547] omap_rtc: RTC already running.<br />
[ 3.468086] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled<br />
[ 3.473121] serial8250.0: ttyS0 at MMIO map 0xfffb0000 mem 0xfefb0000 (irq = 46) is a ST16654<br />
[ 3.503986] loop: loaded (max 8 devices)<br />
[ 3.507833] PPP generic driver version 2.4.2<br />
[ 3.515766] smc91x.c: v1.1, sep 22 2004 by Nicolas Pitre <nico@cam.org><br />
[ 3.523720] eth0: SMC91C94 (rev 9) at c280d300 IRQ 160 [nowait]<br />
[ 3.528740] eth0: Ethernet addr: 00:0e:99:02:06:83<br />
[ 3.541218] i2c /dev entries driver<br />
[ 3.542120] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2<br />
[ 3.547861] ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx<br />
[ 3.566463] omapflash.0: Found 1 x16 devices at 0x0 in 16-bit bank<br />
[ 3.571704] omapflash.0: Found 1 x16 devices at 0x1000000 in 16-bit bank<br />
[ 3.576652] Intel/Sharp Extended Query Table at 0x0031<br />
[ 3.585172] Using buffer write method<br />
[ 3.586158] cfi_cmdset_0001: Erase suspend on write enabled<br />
[ 3.593080] Creating 4 MTD partitions on "omapflash.0":<br />
[ 3.594590] 0x00000000-0x00020000 : "bootloader"<br />
[ 3.599836] 0x00020000-0x00040000 : "params"<br />
[ 3.612855] 0x00040000-0x00240000 : "kernel"<br />
[ 3.619818] 0x00240000-0x02000000 : "filesystem"<br />
[ 3.628784] MUX: initialized W11_1610_CF_CD1<br />
[ 3.637042] MUX: Setting register W11_1610_CF_CD1<br />
[ 3.638432] FUNC_MUX_CTRL_10 (0xfffe1098) = 0x00018000 -> 0x00018000<br />
[ 3.645838] PU_PD_SEL_3 (0xfffe10c0) = 0x00000000 -> 0x00000100<br />
[ 3.649130] PULL_DWN_CTRL_3 (0xfffe104c) = 0x00000000 -> 0x00000000<br />
[ 3.653084] MUX: initialized P11_1610_CF_CD2<br />
[ 3.656692] MUX: Setting register P11_1610_CF_CD2<br />
[ 3.661153] FUNC_MUX_CTRL_A (0xfffe102c) = 0x00000000 -> 0x18000000<br />
[ 3.667831] PU_PD_SEL_2 (0xfffe10bc) = 0x0001f000 -> 0x0001f000<br />
[ 3.681167] PULL_DWN_CTRL_2 (0xfffe1048) = 0x00800000 -> 0x00800000<br />
[ 3.683450] MUX: initialized R11_1610_CF_IOIS16<br />
[ 3.688351] MUX: Setting register R11_1610_CF_IOIS16<br />
[ 3.689816] FUNC_MUX_CTRL_B (0xfffe1030) = 0x00000000 -> 0x00000003<br />
[ 3.692108] PU_PD_SEL_2 (0xfffe10bc) = 0x0001f000 -> 0x0001f000<br />
[ 3.700708] PULL_DWN_CTRL_2 (0xfffe1048) = 0x00800000 -> 0x00800000<br />
[ 3.702937] MUX: initialized V10_1610_CF_IREQ<br />
[ 3.709578] MUX: Setting register V10_1610_CF_IREQ<br />
[ 3.710966] FUNC_MUX_CTRL_A (0xfffe102c) = 0x18000000 -> 0x1b000000<br />
[ 3.717225] PULL_DWN_CTRL_2 (0xfffe1048) = 0x00800000 -> 0x00804000<br />
[ 3.720915] MUX: initialized W10_1610_CF_RESET<br />
[ 3.728021] MUX: Setting register W10_1610_CF_RESET<br />
[ 3.729576] FUNC_MUX_CTRL_A (0xfffe102c) = 0x1b000000 -> 0x1b0c0000<br />
[ 3.737714] PU_PD_SEL_2 (0xfffe10bc) = 0x0001f000 -> 0x0001f000<br />
[ 3.742789] PULL_DWN_CTRL_2 (0xfffe1048) = 0x00804000 -> 0x00804000<br />
[ 3.746022] omap_cf: cs2 on irq 222<br />
[ 4.003884] usbmon: debugfs is not available<br />
[ 4.011731] MUX: Setting register W8_1610_GPIO9<br />
[ 4.013045] FUNC_MUX_CTRL_B (0xfffe1030) = 0x00000003 -> 0x00000003<br />
[ 4.020215] PULL_DWN_CTRL_2 (0xfffe1048) = 0x00804000 -> 0x00804000<br />
[ 4.025198] MUX: initialized W4_USB_HIGHZ<br />
[ 4.037645] MUX: Setting register W4_USB_HIGHZ<br />
[ 4.038937] FUNC_MUX_CTRL_D (0xfffe1038) = 0x00000020 -> 0x00000020<br />
[ 4.045310] PULL_DWN_CTRL_3 (0xfffe104c) = 0x00000000 -> 0x00000020<br />
[ 4.047503] ohci ohci: OMAP OHCI<br />
[ 4.048314] ohci ohci: new USB bus registered, assigned bus number 1<br />
[ 4.054055] ohci ohci: irq 38, io mem 0xfffba000<br />
[ 4.139829] usb usb1: configuration #1 chosen from 1 choice<br />
[ 4.144109] hub 1-0:1.0: USB hub found<br />
[ 4.148634] hub 1-0:1.0: 3 ports detected<br />
[ 4.259850] Initializing USB Mass Storage driver...<br />
[ 4.263752] usbcore: registered new driver usb-storage<br />
[ 4.268446] USB Mass Storage support registered.<br />
[ 4.275962] usbcore: registered new driver usbserial<br />
[ 4.279808] /a/home/tbird/work/test/osk4/alp-linux/drivers/usb/serial/usb-serial.c: USB Serial support registered for generic<br />
[ 4.295544] usbcore: registered new driver usbserial_generic<br />
[ 4.300066] /a/home/tbird/work/test/osk4/alp-linux/drivers/usb/serial/usb-serial.c: USB Serial Driver core<br />
[ 4.312019] /a/home/tbird/work/test/osk4/alp-linux/drivers/usb/serial/usb-serial.c: USB Serial support registered for pl2303<br />
[ 4.321894] usbcore: registered new driver pl2303<br />
[ 4.325398] /a/home/tbird/work/test/osk4/alp-linux/drivers/usb/serial/pl2303.c: Prolific PL2303 USB to serial adaptor driver<br />
[ 4.337308] mice: PS/2 mouse device common for all mice<br />
[ 4.340313] OMAP Keypad Driver<br />
[ 4.343845] input: omap-keypad as /class/input/input0<br />
[ 4.356754] MUX: initialized P20_1610_GPIO4<br />
[ 4.368114] MUX: Setting register P20_1610_GPIO4<br />
[ 4.369580] FUNC_MUX_CTRL_6 (0xfffe101c) = 0x00000009 -> 0x00000009<br />
[ 4.374978] PULL_DWN_CTRL_1 (0xfffe1044) = 0x00600100 -> 0x00600180<br />
[ 4.377525] input: omap_ts as /class/input/input1<br />
[ 4.388732] OMAP touchscreen driver initialized<br />
[ 4.390103] NET: Registered protocol family 2<br />
[ 4.487861] IP route cache hash table entries: 512 (order: -1, 2048 bytes)<br />
[ 4.495774] TCP established hash table entries: 2048 (order: 1, 8192 bytes)<br />
[ 4.503956] TCP bind hash table entries: 2048 (order: 1, 8192 bytes)<br />
[ 4.508188] TCP: Hash tables configured (established 2048 bind 2048)<br />
[ 4.521022] TCP reno registered<br />
[ 4.521809] TCP bic registered<br />
[ 4.522481] NET: Registered protocol family 1<br />
[ 4.523629] NET: Registered protocol family 17<br />
[ 5.039895] eth0: link up<br />
[ 6.043939] Sending BOOTP requests . OK<br />
[ 6.083956] IP-Config: Got BOOTP answer from 192.168.2.1, my address is 192.168.2.74<br />
[ 6.096524] IP-Config: Complete:<br />
[ 6.097370] device=eth0, addr=192.168.2.74, mask=255.255.255.0, gw=192.168.2.1,<br />
[ 6.105211] host=192.168.2.74, domain=, nis-domain=(none),<br />
[ 6.121294] bootserver=192.168.2.1, rootserver=192.168.2.1, rootpath=/target/osk4<br />
[ 6.123966] Looking up port of RPC 100003/2 on 192.168.2.1<br />
[ 6.148034] Looking up port of RPC 100005/1 on 192.168.2.1<br />
[ 6.192996] VFS: Mounted root (nfs filesystem).<br />
[ 6.196374] Freeing init memory: 108K<br />
[ 8.968141] Mounting devpts...<br />
[ 9.100123] Starting syslogd...<br />
[ 9.748191] Starting telnetd...<br />
[ 10.000351] <br />
[ 10.000530] <br />
[ 10.000592] BusyBox v1.01 (2006.05.09-03:34+0000) Built-in shell (ash)<br />
[ 10.008174] Enter 'help' for a list of built-in commands.<br />
[ 10.012713] <br />
[ 10.012893] ash: can't access tty; job control turned off<br />
[ 10.044208] / #<br />
</pre><br />
<br />
== Showing relative times ==<br />
You can use the script 'show_delta' from the kernel 'scripts' directory to show relative times between<br />
lines. Just save the data to a file and then process with show_delta, like so:<br />
<br />
grabserial -e 20 >/tmp/bootlog.txt ; linux_src/scripts/show_delta /tmp/bootlog.txt</div>Consthttp://elinux.org/Android_ArchitectureAndroid Architecture2011-06-13T15:15:45Z<p>Const: + Android internals</p>
<hr />
<div>See Google's<br />
[http://developer.android.com/guide/basics/what-is-android.html What is Android? page]<br />
for an overview of Android components, and a diagram of the architecture.<br />
<br />
The diagram on that page appears in every presentation I have ever seen<br />
about Android technical topics (with the exception of my own).<br />
<br />
== Architecture Diagram ==<br />
Here is the Android Architecture Diagram, obtained from [http://developer.android.com/images/system-architecture.jpg here].<br />
<br />
[[image:Android-system-architecture.jpg]]<br />
<br />
See also [http://www.makelinux.net/android/internals/ Android internals diagram]<br />
<br />
Basically Android has the following layers:<br />
<br />
* applications (written in java, executing in Dalvik)<br />
* framework services and libraries (written mostly in java)<br />
** applications and most framework code executes in a virtual machine<br />
* native libraries, daemons and services (written in C or C++)<br />
* the Linux kernel, which includes<br />
** drivers for hardware, networking, file system access and inter-process-communication<br />
<br />
== Overview presentations ==<br />
* [http://kobablog.wordpress.com/2011/05/22/android-is-not-just-java-on-linux/ Android is not just Java on Linux]<br />
** Great presentation by Tetsuyuki Kobayashi overview of Android<br />
* See this Android Internals presentation by Karim Yaghmour<br />
** http://www.opersys.com/blog/android-internals-101103<br />
** You'll find both the video and the slides there<br />
* [[Media:Mythbusters_Android.pdf|Mythbusters_Android.pdf]] Presentation by Matt Porter at ELC Europe<br />
** Has bits and pieces showing problematic Android code and policies<br />
<br />
== Breakdown of running Android system ==<br />
A quick look at Android contents and programs running when Android starts is at:<br />
* http://benno.id.au/blog/2007/11/13/android-under-the-hood<br />
<br />
== Relation to the Linux kernel ==<br />
Here is [http://github.com/gregkh/android-presentation/downloads Greg Kroah-Hartmans presentation on Android] from the CELF conference 2010, discussing how Google/Android work (or don't work) with the Linux community.<br />
<br />
== Java ==<br />
Java is used as a language for application programming, but it is converted into a non-java byte code for runtime interpretation by a custom interpreter (Dalvik).<br />
<br />
=== Java/Object Oriented Philosophy ===<br />
Practicality is more important than purity in implementing the Android system.<br />
<br />
Dianne Hackborn, one of the principal engineers working on Android, wrote:<br />
<div style="margin:0; margin-top:10px; margin-right:10px; border:1px solid #CCCC00; padding:0 1em 1em 1em; background-color:#ffffcc; align:right;"><br />
<br />
It's not like I am a C programmer who doesn't like object oriented design. In fact prior to Android my primary language was C++... and honestly, Java really annoys me in the way it introduces so much more overhead to do things that I could express in very nice OO concepts in C++ with a much lighter-weight result.<br />
<br />
Though Java has a lot of other nice attributes that make it good for Android, it also has its share of design flaws and misfeatures that mean we can't be totally beautifully OO as you would like.<br />
<br />
Finally, going forward, our API conventions were defined in a way that allowed us to ship a well performing system on the hardware we had the time. As the situation changes (and it slowly is, but not enough yet) that could change... however, I will probably lean towards keeping those API conventions in place just for the sake of consistency with everything that currently exists. Of course if Android is successful and in 10 years from now we are designing a whole new next generation Android framework... well, then the world is a different place.<br />
</div><br/><br />
<br />
[[Category:Android]]</div>Consthttp://elinux.org/Android_ApplicationsAndroid Applications2011-06-09T17:22:39Z<p>Const: /* DLNA */ rm unavailable http://www.appbrain.com/app/vplayer-beta/me.abitno.vplayer</p>
<hr />
<div>This page has some miscellaneous applications and services which may be of interest to developers:<br />
<br />
== DLNA ==<br />
<br />
A fast growing open-source stack for Android is<br />
* Cling - http://www.teleal.org/projects/cling/<br />
<br />
Alternatively you might want to look at<br />
* http://www.cybergarage.org/twiki/bin/view/Main/CyberLinkForJava<br />
<br />
[[Category:Android]]</div>Consthttp://elinux.org/Android_BootingAndroid Booting2011-06-09T10:25:12Z<p>Const: /* user space */ + link to SystemServer.java</p>
<hr />
<div>The bootup of an Android system consists of several phases, which are outlined here.<br />
<br />
== Key bootup components ==<br />
=== Bootloader ===<br />
The first program which runs on any Android system is the bootloader. Technically, the<br />
bootloader is outside the realm of Android itself, and is used to do very low-level system<br />
initialization, before loading the Linux kernel. The kernel then does the bulk of hardware,<br />
driver and file system initialization, before starting up the user-space programs and applications<br />
that make up Android.<br />
<br />
Often, the first-stage bootloader will provide support for loading recovery images to the<br />
system flash, or performing other recovery, update, or debugging tasks.<br />
<br />
The bootloader on the ADP1 detects certain keypresses, which can be used to make it <br />
load a 'recovery' image (second instance of the kernel and system), or put the phone into<br />
a mode where the developer can perform development tasks ('fastboot' mode), such as<br />
re-writing flash images, directly downloading and executing an alternate kernel image, etc.<br />
<br />
=== 'init' ===<br />
A key component of the Android bootup sequence is the program 'init', which is a specialized program for<br />
initializing elements of the Android system. Unlike other Linux systems (embedded or otherwise), Android<br />
uses its own initialization program. (Linux desktop systems have historically used some combination of<br />
/etc/inittab and sysV init levels - e.g. /etc/rc.d/init.d with symlinks in /etc/rc.d/rc.[2345]). Some<br />
embedded Linux systems use simplified forms of these -- such as the init program included in busybox, which<br />
processes a limited form of /etc/inittab, or a direct invocation of a shell script or small program to<br />
do fixed initialization steps.<br />
<br />
The Android 'init' program processes two files, executing the commands it finds in them, called<br />
'init.rc' and 'init.<machine_name>.rc', where <machine_name> is the name of the hardware<br />
that Android is running on. (Usually, this is a code word. The name of the HTC1 hardware<br />
for the ADP1 is 'trout', and the name of the emulator is 'goldfish'.<br />
<br />
The 'init.rc' file is intended to provide the generic initialization<br />
instructions, while the 'init.<machine_name>.rc' file is intended to provide the<br />
machine-specific initialization instructions.<br />
<br />
==== 'init' resources ====<br />
The syntax for these .rc files is documented in a readme file in the source tree.<br />
See the [http://android.git.kernel.org/?p=platform/system/core.git;a=blob;f=init/readme.txt;hb=HEAD Android init language reference]<br />
<br />
Or, see also: http://www.kandroid.org/android_pdk/bring_up.html<br />
<br />
See also http://www.androidenea.com/2009/08/init-process-and-initrc.html<br />
<br />
== Sequence of boot steps on ADP1 ==<br />
=== firmware ===<br />
* first-stage bootloader runs<br />
** it detects if a special key is held, and can launch the recovery image, or the 'fastboot' bootloader<br />
* eventually, a kernel is loaded into RAM (usually with an initrd)<br />
** normally, this will be the kernel from the 'boot' flash partition.<br />
<br />
=== kernel ===<br />
* the kernel boots<br />
** core kernel initialization<br />
*** memory and I/O areas are initialized<br />
*** interrupts are started, and the process table is initialized<br />
** driver initialization<br />
** kernel daemons (threads) are started<br />
** root file system is mounted<br />
** the first user-space process is started<br />
*** usually /init (note that other Linux systems usually start /sbin/init)<br />
<br />
=== user space ===<br />
* the kernel runs /init<br />
** /init processes /init.rc and /init.<machine_name>.rc<br />
** dalvik VM is started (zygote). See [[Android Zygote Startup]]<br />
** several daemons are started:<br />
*** rild - radio interface link daemon<br />
*** vold - volume daemon (media volumes, as in file systems - nothing to do with audio volume)<br />
* the system_server starts, and initializes several core services<br />
** See http://www.androidenea.com/2009/07/system-server-in-android.html<br />
** initalization is done in 2 steps:<br />
*** 1) a library is loaded to initialize interfaces to native services, then <br />
*** 2) java-based core services are initialized in ServerThread::run() in [http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=services/java/com/android/server/SystemServer.java SystemServer.java]<br />
* the activity manager starts core applications (which are themselves dalvik applications)<br />
** com.android.phone - phone application<br />
** android.process.acore - home (desktop) and a few core apps.<br />
* other processes are also started by /init, somewhere in there:<br />
** adb<br />
** mediaserver<br />
** dbus-daemon<br />
** akmd<br />
<br />
== Tools for analyzing Android Bootup ==<br />
* Bootchart - see [[Using Bootchart on Android]]<br />
<br />
== Notes on the Android startup procedure ==<br />
=== Overview ===<br />
<br />
See "Android Initialization Process" at: http://blog.chinaunix.net/u2/85805/showart_1421736.html<br />
<br />
=== strace ===<br />
http://benno.id.au/blog/2007/11/18/android-runtime-strace<br />
<br />
=== Interaction of different processes on application initialization ===<br />
Talking about Android Process - http://blog.csdn.net/mawl2002/archive/2009/06/24/4295905.aspx<br />
<br />
=== Improving Bootup Time presentation ===<br />
See [[Improving Android Boot Time]] - notes and material for a talk at LinuxCon North America, 2010 by Tim Bird<br />
<br />
== News ==<br />
=== 1-second boot of Android ===<br />
Ubiquitous Corporation has announced boot of ARM-based Android system in 1 second.<br />
Actually, it's more like a suspend and resume than a boot.<br />
See http://www.linuxfordevices.com/c/a/News/Ubiquitous-QuickBoot/?kc=LNXDEVNL032410<br />
[March, 2010]<br />
<br />
[[Category:Android]]</div>Consthttp://elinux.org/Android_PortalAndroid Portal2011-05-25T15:12:58Z<p>Const: + http://en.wikipedia.org/wiki/Rooting_(Android_OS)</p>
<hr />
<div>__NOTOC__<br />
<br />
Android ([http://en.wikipedia.org/wiki/Google_Android wikipedia entry]) is a software platform and operating system written by Google and the Open Handset Alliance, designed for use in small form factor devices and smartphones.<br />
<br />
<div style="width=100%; background:#FFF;"><br />
{| width="100%" cellspacing="5" cellpadding="0" valign="top" style="background:inherit;"<br />
| valign="top" style="margin: 0 0 0.5em 1em; border:1px solid #aaa; text-align:left; width: 33%;" cellpadding="5" |<br />
<div style="background: #eeeeee; border: 1px solid #2C547A; padding: 5px; margin: 3px; font-weight:bold;text-align:center;font-size:120%;">Getting Started</div><br />
<div style="margin: 0 0 0 1em;"><br />
;[[Android Intro|Introduction to Android]]<br />
;[[Android Architecture|Design and Architecture]]<br />
;[[Android Tools|Necessary tools]]<br />
;[[Android Glossary|Glossary]]<br />
;[[Android Tutorials|Tutorials]]<br />
;[[Android History]]<br />
;[[Android Versions|Versions]]<br />
* and notes on fragmentation<br />
</div><br />
| valign="top" style="margin: 0 0 0.5em 1em; border:1px solid #aaa; text-align:left; width: 33%;" cellpadding="5"|<br />
<div style="background: #eeeeee; border: 1px solid #2C547A; padding: 5px; margin: 3px; font-weight:bold;text-align:center;font-size:120%;">Android Linux Kernel</div><br />
<div style="margin: 0 0 0 1em;"><br />
;[[Android Kernel Download|Where to obtain]]<br />
;[[Android Kernel Build|How to build]]<br />
;[[Android Kernel Installation|How to install (on phone, on emulator, etc.)]]<br />
;[[Android Kernel Versions|What version to use]]<br />
;[[Android Kernel Features|Kernel features]]<br />
* (binder, wakelocks, etc.)<br />
;[[Android Board Support|Board Support highlights]]<br />
</div><br />
| valign="top" style="margin: 0 0 0.5em 1em; border:1px solid #aaa; text-align:left; width: 33%;" cellpadding="5"|<br />
<div style="background: #eeeeee; border: 1px solid #2C547A; padding: 5px; margin: 3px; font-weight:bold;text-align:center;font-size:120%;">Android System Information</div><br />
<div style="margin: 0 0 0 1em;"><br />
;[[Android Booting|Booting]]<br />
;[[Android Power Management|Power Management]]<br />
;[[Android Security|Security]]<br />
;[[Android Memory Usage|Memory Usage]]<br />
;[[Android Dalvik VM|Dalvik Virtual Machine]]<br />
;[[Android Packages|Packages, Assets and Resources]]<br />
;[[Android Networking|Networking]]<br />
;[[Android File Systems|File Systems]]<br />
;[[Android Logging System]]<br />
</div><br />
|-<br />
| valign="top" style="margin: 0 0 0.5em 1em; border:1px solid #aaa; text-align:left; width: 33%;" cellpadding="5"|<br />
<div style="background: #eeeeee; border: 1px solid #2C547A; padding: 5px; margin: 3px; font-weight:bold;text-align:center;font-size:120%;">Software development</div><br />
<div style="margin: 0 0 0 1em;"><br />
;[[Android SDK|Software Development Kit]]<br />
;[[Android Build System|Source Build System]]<br />
;[[Android Tools|Development Tools]]<br />
;[[Android Application Development|Application Development Resources]]<br />
;[[Android Scripting|Scripting]]<br />
;[[Android Debugging|Debugging]]<br />
;[[Android Testing|Testing]]<br />
</div><br />
| valign="top" style="margin: 0 0 0.5em 1em; border:1px solid #aaa; text-align:left; width: 33%;" cellpadding="5"|<br />
<div style="background: #eeeeee; border: 1px solid #2C547A; padding: 5px; margin: 3px; font-weight:bold;text-align:center;font-size:120%;">Android-based Systems</div><br />
<div style="margin: 0 0 0 1em;"><br />
;[[Android Hardware|Products (announced & shipped)]]<br />
;[[Android Porting|Porting efforts and issues]]<br />
;[http://en.wikipedia.org/wiki/Rooting_(Android_OS) Getting Root (Jailbreaking)]<br />
;[[Android Hardware Fixes|Miscellaneous Hardware Fixes]]<br />
;[[Android x86|Android x86]]<br />
;[[Android Applications|Applications and Services]]<br />
<br />
</div><br />
| valign="top" style="margin: 0 0 0.5em 1em; border:1px solid #aaa; text-align:left; width: 33%;" cellpadding="5"|<br />
<div style="background: #eeeeee; border: 1px solid #2C547A; padding: 5px; margin: 3px; font-weight:bold;text-align:center;font-size:120%;">Android Community</div><br />
<div style="margin: 0 0 0 1em;"><br />
;[[Android News|News]]<br />
;[[Android Events|Events]]<br />
;[[Android Web Resources|Web/Mailing List Directory]]<br />
;[[Android People|People]]<br />
;[[Android Organizations|Organizations]]<br />
</div><br />
|}<br />
</div><br />
<br />
[[Category:Android]]</div>Consthttp://elinux.org/ExpertsExperts2011-04-22T19:07:38Z<p>Const: /* The List */ + www.makelinux.com</p>
<hr />
<div>== '''Embedded Linux Expert List''' ==<br />
<br />
* [[Rusty_Russell_Quotes]] This page is here in honor of Rusty Russell, one of the funniest Linux kernel developers EVER<br />
<br />
=== Instructions for Experts ===<br />
This page is intended to provide a place for Embedded Linux Experts to advertise their availability, and describe their expertise, to companies interested in paying them for services. This could include contract work or fulltime employment.<br />
<br />
Linux experts are encouraged to provide their information in the table below so that companies may contact them for their areas of interest. Please put an expiration date for the information, so we can remove information when it<br />
gets stale. Or even better, when you have obtained work, please remove your entry from this table.<br />
<br />
See the [[Jobs]] page for jobs already posted to this site.<br />
<br />
=== Instructions for Employers ===<br />
Please contact the person below, if you have a position or contract work you would like to hire<br />
someone to do. This list is not intended to be used to ask for free support.<br />
<br />
You can also list your job on the [[Jobs]] page.<br />
<br />
== '''The List''' ==<br />
{| border="1" cellspacing="0" cellpadding="5"<br />
|- style="background:#CCCCCC"<br />
! style="width:200px" | Name (Link)<br />
! style="width:400px" | Expertise areas<br />
! style="width:200px" | Contact Info<br />
! style="width:100px" | Expires date<br />
|- align="center"<br />
| Constantine Shulyupin<br>Israel, Worldwide<br />
| TI DaVinci, drivers, boot loaders, fast boot<br />
| http://www.makelinux.com <br> mailto://const@makelinux.com<br />
| 2013<br />
|- align="center"<br />
| Sasha Sirotkin<br>FemtoLinux<br>Tel-Aviv (Israel)<br />
| Porting from VxWorks, ThreadX, Nucleus and other RTOS to Linux, device drivers, BSP<br />
| http://www.femtolinux.com <br> demiurg AT femtolinux DOT com<br />
| 2011<br />
|- align="center"<br />
| Dave Lynch<br>DLA Systems<br>Lancaster, PA(USA)<br />
| Embedded Software development, bootloaders, board bring-up, BSP, drivers, toolchains, rootfs, applications - Linux and other embedded RTOS's<br />
| http://www.dlasys.net<br>dhlii@dlasys.net<br />
| 2011<br />
|- align="center"<br />
| Leon Woestenberg, MSc. EE, Eindhoven, The Netherlands, EU<br />
| Embedded Linux, Real-time, OpenEmbedded, System and Hardware Design, Device Drivers, Training, Video Broadcast, FPGA's<br />
| [http://www.sidebranch.com/ www.sidebranch.com]<br />
| 2011<br />
|- align="center"<br />
| Ithamar Adema/ Mark Vels, Netherlands, EU<br />
| Embedded Linux, BSP ports & support, OpenWrt support, Device Drivers, Training, <br />
| [http://www.team-embedded.com/ www.team-embedded.com]<br />
| 2011<br />
|- align="center"<br />
| [[User:Arnout Vandecappelle|Arnout Vandecappelle]],<br>Leuven (Belgium)<br />
| Consultancy and Services in the field of Embedded Linux, Feasibility studies, BSP ports & support, Device drivers, Multimedia & networking, Debugging, Training<br />
| [mailto:contact@mind.be contact@mind.be]<br>[http://www.mind.be http://www.mind.be]<br />
| 2011<br />
|- align="center"<br />
| Chris Simmonds, Hampshire (UK), EU<br />
| Freelance consultant experienced in embedded and real-time Linux, U-Boot and board support packages<br />
| http://www.2net.co.uk, http://www.embedded-linux.co.uk/<br />
| 2011<br />
|- align="center"<br />
| Robert Berger, Embedded Software Specialist, Athens (Greece), EU<br />
| Consulting and Training for: Embedded Linux, Real-time, Debugging, U-boot, Development Process Improvement <br />
| elinux@reliableembeddedsystems.com [http://www.reliableembeddedsystems.com/ http://www.reliableembeddedsystems.com]<br />
| 2043<br />
|- align="center"<br />
| Roberto A. Foglietta, Genoa (Italy), EU<br />
| Embedded Linux for Telecommunication and Automotive <br />
| [http://www.roberto.foglietta/work/who_am_I www.roberto.foglietta/work]<br />
| 2010<br />
|- align="center"<br />
| Marco Cavallini, Bergamo (Italy), EU<br />
| Embedded Linux, Device Drivers, Real-time, OpenEmbedded, BSP Design, u-boot, training<br />
| [http://www.koansoftware.com KOAN sas]<br />
| 2015<br />
|- align="center"<br />
| Matthias Kaehlcke, Barcelona (Spain)<br />
| Embedded Linux and device drivers<br />
| matthias_AT_kaehlcke.net<br />
| 2010<br />
|- align="center"<br />
| David Anders<br>RAD Tech Labs<br>Dallas/Ft.worth, Texas<br />
| Embedded hardware and software development, board bringups, support packages, and drivers<br />
| http://www.rad-tech-labs.com<br>danders@rad-tech-labs.com<br />
| 2011<br />
|- align="center"<br />
| Sebastien Ronsse, MSc. EE, Seattle (WA), USA<br />
| Embedded Linux, Real-time, BSP ports & Support, Arm Architecture, System Design, Device Drivers, Training<br />
| sales@adeneo-embedded.com<br />
| 2010<br />
|- align="center"<br />
| Hunyue Yau, California (USA)<br />
| Embedded Linux, device drivers, board bring-up, ports, userland integration, training, prototyping, OMAP3<br />
| [http://www.hy-research.com/ www.hy-research.com]<br />
| 2010<br />
|- align="center"<br />
| Richard B. Johnson, Massachusetts (USA)<br />
| Embedded Linux, device drivers, ports, complete integration, tiny 'C' runtime library<br />
| [http://www.route495software.com/ www.Route495Software.com]<br />
| 2010<br />
|- align="center"<br />
| Young-Ho Song, Seoul (Korea)<br />
| Embedded Linux, Device drivers, Multimedia Communication & System, IPTV, Network Security<br />
| yhsongATnds.com <br />
whois [http://elinux.org/User:Young-Ho_Song Young-Ho Song]<br />
| 2010<br />
<br />
|- align="center"<br />
| Benjamin Zores, Strasbourg (France)<br />
| Embedded Linux, Device drivers, BSP Integration, Board Bring-Up, U-Boot, Multimedia Playback, Video Acceleration and Media Center applications<br />
| http://www.geexbox.org/<br>ben AT geexbox DOT org <br />
| 2011<br />
|}<br />
<br />
[[Category:Categories]]</div>Consthttp://elinux.org/Boot_TimeBoot Time2011-03-30T08:32:09Z<p>Const: /* Case Studies */</p>
<hr />
<div>== Introduction ==<br />
Boot Time includes topics such as measurement, analysis, human factors, initialization techniques, and reduction techniques.<br />
The time that a product takes to boot directly impacts the first perception an end user has of the product.<br />
Regardless of how attractive or well designed a consumer electronic device is, the time required to move the device from off to an interactive, usable state is critical to obtaining a positive end user experience. Turning on a device is Use Case #1.<br />
<br />
Booting up a device involves numerous steps and sequences of events. In order to use consistent terminology, the<br />
[[Bootup Time Working Group]] of the CE Linux Forum came up with a list of terms and their widely accepted definitions<br />
for this functionality area. See the following page for these terms:<br />
* [[Boot-up Time Definition Of Terms]]<br />
<br />
== Technology/Project Pages ==<br />
The following are individual pages with information about various technologies relevant to improving Boot Time for Linux. Some of these describe local patches available on this site. Others point to projects or patches maintained elsewhere.<br />
<br />
=== Measuring Boot-up Time ===<br />
*[[Printk Times]] - simple system for showing timing information for each printk.<br />
*[[Kernel Function Trace]] - system for reporting function timings in the kernel.<br />
*[[Linux Trace Toolkit]] - system for reporting timing data for certain kernel and process events.<br />
*[http://oprofile.sourceforge.net/news/ Oprofile] - system-wide profiler for Linux.<br />
*[[Bootchart]] - a tool for performance analysis and visualization of the Linux boot process. Resource utilization and process information are collected during the user-space portion of the boot process and are later rendered in a PNG, SVG or EPS encoded chart.<br />
*[http://people.redhat.com/berrange/systemtap/bootprobe/ Bootprobe] - a set of [[System Tap]] scripts for analyzing system bootup.<br />
* and, let us not forget: "cat /proc/uptime"<br />
* [[Tims Fastboot Tools#grabserial | grabserial]] - a nice utility from Tim Bird to log and timestamp console output<br />
* [[Tims Fastboot Tools#Tim's quick and dirty process trace|process trace]] - a simple patch from Tim Bird to log exec, fork and exit system calls.<br />
* [http://pengutronix.de/software/ptx_ts/index_en.html ptx_ts] - Pengutronix' TimeStamper: A small filter prepending timestamps to STDOUT; a bit similar to grabserial but not limited to serial ports<br />
* [[Initcall Debug]] - a kernel command line option to show time taken for initcalls.<br />
* See also: [[Kernel Instrumentation]] which lists some known kernel instrumentation tools. These are of interest for measuring kernel startup time.<br />
<br />
=== Technologies and Techniques for Reducing Boot Time ===<br />
==== Bootloader speedups ====<br />
*[[Kernel XIP]] - Allow kernel to be executed in-place in ROM or FLASH.<br />
*[[DMA Copy Of Kernel On Startup]] - Copy kernel from Flash to RAM using DMA<br />
*[[Uncompressed kernel]] - An uncompressed kernel might boot faster<br />
*[[Fast Kernel Decompression]]<br />
<br />
==== Kernel speedups ====<br />
*[[Disable Console]] - Avoid overhead of console output during system startup.<br />
*Disable bug and printk - Avoid the overhead of bug and printk. Disadvantage is that you loose a lot of info.<br />
*[[RTC No Sync]] - Avoid delay to synchronize system time with RTC clock edge on startup.<br />
*[[Short IDE Delays]] - Reduce duration of IDE startup delays (this is effective but possibly dangerous).<br />
*[[Hardcode kernel module info]] - Reduce the overhead of loading a module, by hardcoding some information used for loading the relocation information<br />
*[[IDE No Probe]] - Force kernel to observe the ide<x>=noprobe option.<br />
*[[Preset LPJ]] - Allow the use of a preset loops_per_jiffy value.<br />
*[[Asynchronous function calls]] - Allow probing or other functions to proceed in parallel, to overlap time-consuming boot-up activities.<br />
**[[Threaded Device Probing]] - Allow drivers to probe devices in parallel. (not mainlined, now deprecated?)<br />
*[[Reordering of driver initialization]] - Allow driver bus probing to start as soon as possible.<br />
*[[Deferred Initcalls]] - defer non-essential module initialization routines to after primary boot<br />
*NAND ECC improvement - The pre 2.6.28 nand_ecc.c has room for improvement. You can find an improved version in the mtd git at http://git.infradead.org/mtd-2.6.git?a=blob_plain;f=drivers/mtd/nand/nand_ecc.c;hb=HEAD. Documentation for this is in http://git.infradead.org/mtd-2.6.git?a=blob_plain;f=Documentation/mtd/nand_ecc.txt;hb=HEAD. This is only interesting if your system uses software ECC correction.<br />
*Check what kernel memory allocator you use. Slob or slub might be better than slab (which is the default in older kernels) <br />
*If your system does not need it, you can remove SYSFS and even PROCFS from the kernel. In one test removing sysfs saved 20 ms.<br />
*Carefully investigate all kernel configuration options on whether they are applicable or not. Even if you select an option that is not used in the end, it contributes to the kernel size and therefore to the kernel load time (assuming you are not doing kernel XIP). Often this will require some trial and measure! E.g. selecting CONFIG_CC_OPTIMIZE_FOR_SIZE (found under general setup) gave in one case a boot improvement of 20 ms. Not dramamtic, but when reducing boot time every penny counts!<br />
*Moving to a different compiler version might lead to shorter and/or faster code. Most often newer compilers produce better code. You might also want to play with compiler options to see what works best.<br />
* If you use initramfs in your kernel and a compressed kernel it is better to have an uncompressed initramfs image. This is to avoid having to uncompress data twice. A patch for this has been submitted to LKML. See http://lkml.org/lkml/2008/11/22/112 <br />
<br />
===== File System issues =====<br />
Different file systems have different initialization (mounting) times, for the same data sets. This<br />
is a function of whether meta-data must be read from storage into RAM or not, and what algorithms are<br />
used during the mount procedure.<br />
<br />
* [[Filesystem Information]] - has information about boot-up times of various file systems<br />
* [[File Systems]] - has information on various file systems that are interesting for embedded systems. Also includes some improvement suggestions.<br />
* [[Avoid Initramfs]] - explains on why intramfs should be avoided if you want to minimize boot time<br />
* Split partitions. If mounting a file system takes long, you can consider splitting that filesystem in two parts, one with the info that is needed during or immediately after boot, and one which can be mounted later on.<br />
* [[Ramdisks demasked]] - explains why using a ram disk generally results in a longer boot time, not a shorter one.<br />
<br />
==== User-space and application speedups ====<br />
* [[Optimize RC Scripts]] - Reduce overhead of running RC scripts<br />
* [[Parallel RC Scripts]] - Run RC scripts in parallel instead of sequentially<br />
* [[Application XIP]] - Allow programs and libraries to be executed in-place in ROM or FLASH<br />
* [[Pre Linking]] - Avoid cost of runtime linking on first program load<br />
* Statically link applications. This avoids the costs of runtime linking. Useful if you have only a few applications. In that case it could also reduce the size of your image as no dynamic libraries are needed<br />
* GNU_HASH: ~ 50% speed improvement in dynamic linking<br />
** See http://sourceware.org/ml/binutils/2006-06/msg00418.html<br />
* [[Application Init Optimizations]] - Improvements in program load and init time via: <br />
** use of mmap vs. read<br />
** control over page mapping characteristics.<br />
* [[Include modules in kernel image]] - Avoid extra overhead of module loading by adding the modules to the kernel image<br />
* Avoid udev, it takes quite some time to populate the /dev directory. In an embedded system it is often known what devices are present and in any case you know what drivers are available, so you know what device entries might be needed in /dev. These should be created statically, not dynamically. mknod is your friend, udev is your enemy.<br />
* If you still like udev and also like fast boot-up's, you might go this way: start your system with udev enabled and make kind of a backup of the created device nodes. Now, modify your init script like this: instead running udev, copy the device nodes that you just made a backup of into the device tree. Now, install the hotplug-daemon like you always do. That trick avoids the device node creation at startup but stills lets your system create device nodes later on. <br />
* If your device has a network connection, preferably use static IP addresses. Getting an address from a DHCP server takes additional time and has extra overhead associated with it.<br />
* Moving to a different compiler version might lead to shorter and/or faster code. Most often newer compilers produce better code. You might also want to play with compiler options to see what works best.<br />
* If possible move from glibc to uClibc. This leads to smaller executables and hence to faster load times.<br />
* library optimiser tool: http://libraryopt.sourceforge.net/ <br/> This will allow you to create an optimised library. As unneeded functions are removed this should lead to a performance gain. Normally there will be library pages which contain unused code (adjacent to code that is used). After optimizing the library this does not occur any more, so less pages are needed and hence less page loads, so some time can be saved.<br />
* Function reordering: http://www.celinux.org/elc08_presentations/DDLink%20FunctionReorder%2008%2004.pdf <br/> This is a technique to rearrange the functions within an executable so they appear in the order they are needed. This improves the load time of the application as all initialization code is grouped into a set of pages, instead of being scattered over a number of pages.<br />
<br />
==== Suspend related improvements ====<br />
Another approach to improve boot time is to use a suspend related mechanism. Two approaches are known.<br />
* Using the standard hibernate/resume approach. This is what has been demonstrated by Chan Ju, Park, from Samsung. See sheet 23 and onwards from this [[Media:LinuxBootupTimeReduction4DSC.ppt|PPT]] and section 2.7 of this [http://www.kernel.org/doc/ols/2006/ols2006v2-pages-239-248.pdf paper]. <br /> Issue with this approach is that flash write is much slower than flash read, so the actual creation of the hibernate image might take quite a while.<br />
* Implementing snapshot boot. This is done by Hiroki Kaminaga from Sony and is described at [[Suspend To Disk For ARM|snapshot boot for ARM]] and http://elinux.org/upload/3/37/Snapshot-boot-final.pdf<br />This is similar to hibernate and resume, but the hibernate file is retained and used upon every boot. Disadvantage is that no writable partitions should be mounted at the time of making the snapshot. Otherwise inconsistencies will occur if a partition is modified, while applications in the hibernate file might have information in the snapshot related to the unmodified partition.<br />
<br />
==== Miscellaneous topics ====<br />
<br />
[[About Compression]] discusses the effects of compression on boot time. This can affect both the kernel boot time as well as user-space startup.<br />
<br />
==== Uninvestigated speedups ====<br />
<br />
This section is a holding pen for ideas for improvement that are not implemented yet but that could result in a boot time gain. Please leave a note here if you are working on one of these items to avoid duplicate work.<br />
<br />
* '''Prepopulated buffer cache''' - As initramfs performs an additional copy of the data the idea is to have a prepopulated buffer cache. A simplistic scenario would allow dumping the buffer cache when the booting is completed and the user applications have initialised. This data then could be used in a subsequent boot to initialize the buffer cache (of course without copying). A possible approach would be to have those data to reside into the kernel image and use them directly. Alternately they could be loaded separately. <br /> Unfortunately my knowledge of the internals in this section is not yet good enough to do a trial implementation.<br /> Caveats:<br />
** is it possible to have the buffer cache split into two different parts, one which is statically allocated, one which is dynamically allocated?<br />
** the pages in the prepopulated buffer cache probably cannot be discarded, so they should be pinned<br />
** apart from the buffer cache data itself also some other variables might need restoring<br />
** a similar approach could also be used for the cached file data.<br />
*'''Dedicated fs''' - currently a lot of abstraction is done in fs to make a nice abstraction allowing easy addition of new filesystems and creating a unified view of those filesystem. While this is pretty neat, the abstraction layers also introduce some overhead. A solution could be to create a dedicated fs system, which supports only one (or maybe 2) filesystems, and eliminates the abstraction overhead. This will give some benefit, but the chance of getting this into the mainline is zero.<br />
<br />
== Articles and Presentations ==<br />
* "The Right Approach to Boot Time Reduction" - ([http://elinux.org/images/f/f7/RightApproachMinimalBootTimes.pdf Slides] | [http://www.youtube.com/watch?v=ULa4TPy7z0c YouTube Video])<br />
** Andrew Murray has presented at ELC Europe on October 28, 2010 (Free Electrons video [http://free-electrons.com/pub/video/2010/elce/elce2010-murray-boot-time.webm here])<br />
** This included a < 1 second QT cold Linux boot case study for an SH7724 with some additional information about 'function re-ordering' in user-space<br />
** Similar slides with < 1 second case study for OMAP3530EVM can be found [http://www.slideshare.net/andrewmurraympc/t-iswift-boot here]<br />
* "One Second Linux Boot Demonstration (new version)" ([http://www.youtube.com/watch?v=-l_DSZe8_F8 Youtube video by MontaVista])<br />
* "Tools and Techniques for Reducing Bootup Time" ([[Media:Tools-and-technique-for-reducing-bootup-time.ppt|PPT]] | [[Media:Tools-and-technique-for-reducing-bootup-time.odp|ODP]] | [[Media:Tools-and-technique-for-reducing-bootup-time.pdf|PDF]] | [http://free-electrons.com/pub/video/2008/elce/elce2008-bird-reducing-bootup-time.ogv video])<br />
** Tim Bird has presented at ELC Europe, on November 7, 2008, his latest collection of tips and tricks for reducing bootup time<br />
** [[Tims Fastboot Tools]] has online materials in support of this presentation<br />
* [http://www.mvista.com/download/author.php?a=37 Christopher Hallinan] has done a presentation at the MontaVista Vision conference 2008 on the topic of reducing boot time. Slides available [http://www.mvista.com/download/power/Reducing-boot-time-techniques-for-fast-booting.pdf here]<br />
* [http://lwn.net/Articles/192082/ Optimizing Linker Load Times]<br />
** (introducing various kinds of bootuptime reduction, prelinking, etc.)<br />
* [http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Benchmarking-boot-latency-on-x86/ Benchmarking boot latency on x86]<br />
** By Gilad Ben-Yossef, July 2008<br />
** A tutorial on using TSC register and the kernel PRINTK_TIMES feature to measure x86 system boot time, including BIOS, bootloader, kernel and time to first user program.<br />
* [http://tree.celinuxforum.org/CelfPubWiki/KoreaTechJamboree3?action=AttachFile&do=get&target=The_Fast_Booting_of_Embedded_Linux.pdf Fast Booting of Embedded Linux]<br />
** By HoJoon Park, Electrons and Telecommunications Research Institute (ETRI), Korea, Presented at the CELF [http://tree.celinuxforum.org/CelfPubWiki/KoreaTechJamboree3 3rd Korean Technical Jamboree], July 2008<br />
** Explains several different reduction techniques used for different phases of bootup time<br />
*Tim Bird's (Sony) survey of boot-up time reduction techniques:<br />
**[http://kernel.org/doc/ols/2004/ols2004v1-pages-79-88.pdf Methods to Improve Boot-up Time in Linux] - Paper prepared for 2004 Ottawa Linux Symposium<br />
**{{pdf|ReducingStartupTime v0.8.pdf|Reducing Startup Time in Embedded Linux Systems}} - December 2003 Presentation describing some existing boot-up time reduction techniques and strategies.<br />
* [http://free-electrons.com/articles/optimizations Embedded Linux optimizations]<br />
** By Free Electrons<br />
** Tutorial to reduce size, RAM, speed, power and cost of a Linux based embedded system]<br />
*Parallelizing Linux Boot on CE Devices<br />
** [http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2007Presentations?action=AttachFile&do=view&target=par.pdf PDF of Presentation]<br />
**[http://free-electrons.com/pub/video/2007/elce/elce-2007-vitaly-wool-parallel-boot.ogg Video of Presentation]<br />
*[http://www.ibm.com/developerworks/linux/library/l-boot-faster/ Parallelize Applications for Faster Linux Boot]<br />
**Authored by M. Tim Jones for IBM Developer Works<br />
**This article shows you options to increase the speed with which Linux boots, including two options for parallelizing the initialization process. It also shows you how to visualize graphically the performance of the boot process.<br />
<br />
=== Case Studies ===<br />
* [http://www.makelinux.com/emb/fastboot/omap 300 milliseconds from boot loader to shell on ARM with NAND] <br />
* Samsung proof-of-acceptability study for digital still camera: see [[Media:LinuxBootupTimeReduction4DSC.ppt|Boot Up Time Reduction PPT]] and the [http://www.kernel.org/doc/ols/2006/ols2006v2-pages-239-248.pdf paper] describing this.<br />
* [https://docs.blackfin.uclinux.org/doku.php?id=fast_boot_example Boot Linux from Processor Reset into user space in less than 1 Second]<br />
** In this white paper, Robin Getz describes the techniques used to fast-boot a blackfin development board.<br />
* [http://e2e.ti.com/support/embedded/f/354/t/51158.aspx Booting Linux dm365 Network Camera in 3.2 seconds]<br />
* [http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/p/7616/30088.aspx Boot of kernel and shell in 0.5 sec (not including u-boot and decompression)]<br />
<br />
* [http://www.linuxfordevices.com/c/a/News/Linux-boots-in-297-seconds/ Warp2, Lineo Solutions, 2008. 2.97 sec boot, ARM11, 400MHz]<br />
<br />
== Additional Projects/Mailing Lists/Resources ==<br />
=== Replacements for SysV 'init' ===<br />
The traditional method of starting a Linux system is to use /sbin/init, which<br />
processes the file /etc/inittab. This is an init program which processes a series of actions for different <br />
run-levels and system events (key-combinations and power events).<br />
<br />
See [http://linux.die.net/man/8/init the init(8) man page] and the [http://linux.die.net/man/5/inittab the inittab(5) man page].<br />
<br />
==== busybox init ====<br />
An 'init' applet is often included in [[BusyBox]]<br />
<br />
There used to be (as of 2000) some slight differences in the supported features of the 'inittab' file<br />
between busybox init and full-blown init. However, I don't know (as of 2010) if that's still the case.<br />
(See http://spblinux.de/2.0/doc/init.html for some details)<br />
<br />
Denys Vlasenko, one of the maintainers of busybox has suggested a replacement for traditional init<br />
for that tool called runsv. See http://busybox.net/~vda/init_vs_runsv.html<br />
<br />
==== upstart ====<br />
upstart is the name of a newer Linux desktop systems that provides the program /sbin/init,<br />
but with different operational semantics.<br />
<br />
* Home page: http://upstart.ubuntu.com/<br />
* Wikipedia page: http://en.wikipedia.org/wiki/Upstart<br />
<br />
==== Android init ====<br />
Android 'init' is a custom program for booting the Android system.<br />
<br />
See [[Android_Booting#.27init.27|Android 'init']]<br />
<br />
==== systemd ====<br />
systemd is a new project (as of May 2010) for starting daemons and services on a Linux desktop system<br />
<br />
See http://0pointer.de/blog/projects/systemd.html<br />
<br />
=== Kexec ===<br />
*Kexec is a system which allows a system to be '''rebooted''' without going through BIOS. That is, a Linux kernel can directly boot into another Linux kernel, without going through firmware. See the white paper at: [http://developer.osdl.org/andyp/kexec/whitepaper/kexec.pdf kexec.pdf]<br />
**2004 Kernel Summit presentation: [http://www.xenotime.net/linux/fastboot/fastboot-ks-2004.pdf fastboot.pdf]<br />
**here's another Kexec white paper:[http://www-106.ibm.com/developerworks/linux/library/l-kexec.html?ca=dgr-lnxw04 Reboot Fast]<br />
<br />
=== Splash Screen projects ===<br />
* [http://splashy.alioth.debian.org/wiki/ Splashy] - Technology to put up a spalsh screen early in the boot sequence. This is user-space code.<br />
** This seems to be the most current splash screen technology, for major distributions. A framebuffer driver for the kernel is required.<br />
* [http://dev.gentoo.org/~spock/projects/gensplash/ Gentoo Splashscreen] - newer technology to put a splash screen early in the boot sequence<br />
** See the HOWTO at: [http://gentoo-wiki.com/HOWTO_fbsplash HOWTO FBSplash]<br />
* [http://butterfeet.org/?p=8 PSplash] - PSplash is a userspace graphical boot splash screen for mainly embedded Linux devices supporting a 16bpp or 32bpp framebuffer.<br />
* [http://www.bootsplash.org/ bootsplash.org] - put up a splash screen early in boot sequence<br />
** This project requires kernel patches<br />
** This project is now abandoned, and work is being done on Splashy.<br />
<br />
=== Others ===<br />
<br />
*[http://www.linuxdevices.com/news/NS5907201615.html FSMLabs Fastboot] - press release by FSMLabs about fast booting of their product. Is any of this published?<br />
<br />
*[http://tree.celinuxforum.org/CelfPubWiki/ snapshot boot] - a technology uses software resume to boot up the system quickly.<br />
<br />
==== Apparently obsolete or abandoned material ====<br />
* [[Image:alert.gif]] ''in progress'' - [[Boot-up Time Reduction Howto]] - this is a project to catalog existing boot-up time reduction techniques.<br />
** Was originally intended to be the authoritative source for bootup time reduction information.<br />
** No one maintains it any more (as of Aug, 2008)<br />
*[[Image:alert.gif]]''no content yet'' - [[Boot-up Time Delay Taxonomy]] - list of delays categorized by boot phase, type and magnitude<br />
** Was to be a survey of common bootup delays found in embedded devices.<br />
** Was never really written.<br />
<br />
???<br />
* [[Bootup Time Spec]]<br />
* [[Bootup Time Things To Investigate]]<br />
* [[Bootup Time Working Group]]<br />
* [[Bootup Time Task List]]<br />
* [[Bootup Time Howto Task List]]<br />
* [[Fast Booting Translation]]<br />
<br />
== Companies, individuals or projects working on fast booting ==<br />
* Intel - Arjan van de Ven - see http://lwn.net/Articles/299483/<br />
* Tripeaks - see http://www.linuxdevices.com/news/NS8282586707.html<br />
* Lineo Solutions - see http://www.linuxdevices.com/news/NS5185504436.html<br />
* Monta Vista - see http://www.linuxdevices.com/news/NS2560585344.html<br />
* fastboot git tree - see http://lwn.net/Articles/299591/<br />
<br />
== Boot time check list ==<br />
<br />
From an [http://www.mail-archive.com/linux-embedded@vger.kernel.org/msg02139.html August 2009 discussion about boot time on ARM devices], several hints and advice regarding boot time optimization are available. While it may repeat a lot of above, below is a check list extracted from this discussion:<br />
<br />
* Is CPU's clock switched to maximum? If the kernel, bootloader or hardware is in charge of setting CPU power and speed scaling, then you should check that it boots with the CPU set at maximum speed instead of slowest. <br />
<br />
* Is your hardware (register) timing configuration of your SoC's memory interfaces (e.g. RAM and NOR/NAND timing) optimized? A lot of vendors ship their hardware with "well, it works, optimize later" settings. What you want is "as fast as possible, but sill stable and reliable" configuration. This might need some hardware knowledge and has to be customized to the individual memory devices used.<br />
<br />
* Does your boot loader uses I- and D-Cache? E.g. U-Boot doesn't enable D-Cache by default on ARM devices, as it needs customized MMU tables to do so.<br />
<br />
* Does kernel copy from permanent storage (e.g. NOR or NAND) to RAM use optimized functions? E.g. DMA, or on ARM at least load/store multiple commands (ldm/stm)?<br />
<br />
* If you use U-Boot's uImage, set "verify=no" in U-Boot to avoid checksum verification.<br />
<br />
* Optimize size of your kernel.<br />
** You might even try some of the embedded system kernel config options that, for example, eliminate all the printk strings, reduce data structures, or eliminate unneeded functionality.<br />
<br />
* How often is kernel (image) data copied? First by boot loader from storage to RAM, then by kernel's uncompressor to it's final destination? Once more? If you use compressed kernel and NOR flash, consider running the uncompressor XIP in NOR flash.<br />
<br />
* If you use compressed kernel, check compression algorithm. zlib is slow on decompression, and lzo is much faster. So if you implement lzo compression, you'll probably speed things up a little as well (check LKML for this). Having no compression at all may also be a good thing to try (see next topic).<br />
<br />
* Check to use uncompressed kernel (depends on your system configuration). Using an uncompressed kernel on a flash-based system may improve boot time. The reason is that compressed kernels are faster only when the throughput to the persistent storage is lower than the decompression throughput, and on typical embedded systems with DMA the throughput to memory outperforms the CPU-based decompression. Of course it depends on a lot of stuff like performance of flash controller, kernel storage filesystem performance, DMA controller performance, cache architecture etc. So it's individual per-system. Example: With using an uncomressed kernel (~2.8MB) uncompressing (running the uncompressor XIP in NOR flash) took ~0.5s longer than copying 2.8MB from flash to RAM.<br />
<br />
* Enable precalculated loops-per-jiffy<br />
<br />
* Enable kernel quiet option<br />
<br />
* If you use UBI: UBI is rather slow in attaching MTD devices. Everything is explained at MTD's [http://www.linux-mtd.infradead.org/doc/ubi.html#L_scalability UBI scalability] and [http://www.linux-mtd.infradead.org/doc/ubifs.html#L_scalability UBI fs scalability] sections. There is not very much you can do to speed it up but implement UBI2. UBIFS would stay intact. There were discussions about this and it does not seem to be impossibly difficult to do UBI2 ([http://www.linux-mtd.infradead.org/faq/ubi.html#L_attach_faster few ideas]).<br />
** In a follow-up e-mail, Sascha Hauer wrote:<br />
<pre> What's interesting about this is that the kernel NAND driver is much slower<br />
than the one in U-Boot. Looking at it it turned out that the kernel<br />
driver uses interrupts to wait for the controller to get ready.<br />
Switching this to polling nearly doubles the NAND performance. UBI<br />
mounts much faster now and this cuts off another few seconds from the<br />
boot process :) <br />
</pre><br />
<br />
* Use static device nodes during boot, and later setup busybox mdev for hotplug.<br />
<br />
* If you have network enabled, there might be some very long timeouts in the network code paths, which appear to be used whether you specify a static address or not. See the definitions of CONF_PRE_OPEN and CON_POST_OPEN in ''net/ipv4/ipconfig.c''. Check [http://patchwork.kernel.org/patch/31678/ ipdelay configuration patch].<br />
<br />
* Parallelize boot process.<br />
<br />
* Disable the option "Set system time from RTC on startup and resume", you can use the command hwclock -s at the of the init instead of slowing down the kernel.<br />
<br />
[[Category:Boot Time]]<br />
[[Category:Bootloader]]</div>Consthttp://elinux.org/Boot_TimeBoot Time2011-03-30T08:31:53Z<p>Const: /* Case Studies */</p>
<hr />
<div>== Introduction ==<br />
Boot Time includes topics such as measurement, analysis, human factors, initialization techniques, and reduction techniques.<br />
The time that a product takes to boot directly impacts the first perception an end user has of the product.<br />
Regardless of how attractive or well designed a consumer electronic device is, the time required to move the device from off to an interactive, usable state is critical to obtaining a positive end user experience. Turning on a device is Use Case #1.<br />
<br />
Booting up a device involves numerous steps and sequences of events. In order to use consistent terminology, the<br />
[[Bootup Time Working Group]] of the CE Linux Forum came up with a list of terms and their widely accepted definitions<br />
for this functionality area. See the following page for these terms:<br />
* [[Boot-up Time Definition Of Terms]]<br />
<br />
== Technology/Project Pages ==<br />
The following are individual pages with information about various technologies relevant to improving Boot Time for Linux. Some of these describe local patches available on this site. Others point to projects or patches maintained elsewhere.<br />
<br />
=== Measuring Boot-up Time ===<br />
*[[Printk Times]] - simple system for showing timing information for each printk.<br />
*[[Kernel Function Trace]] - system for reporting function timings in the kernel.<br />
*[[Linux Trace Toolkit]] - system for reporting timing data for certain kernel and process events.<br />
*[http://oprofile.sourceforge.net/news/ Oprofile] - system-wide profiler for Linux.<br />
*[[Bootchart]] - a tool for performance analysis and visualization of the Linux boot process. Resource utilization and process information are collected during the user-space portion of the boot process and are later rendered in a PNG, SVG or EPS encoded chart.<br />
*[http://people.redhat.com/berrange/systemtap/bootprobe/ Bootprobe] - a set of [[System Tap]] scripts for analyzing system bootup.<br />
* and, let us not forget: "cat /proc/uptime"<br />
* [[Tims Fastboot Tools#grabserial | grabserial]] - a nice utility from Tim Bird to log and timestamp console output<br />
* [[Tims Fastboot Tools#Tim's quick and dirty process trace|process trace]] - a simple patch from Tim Bird to log exec, fork and exit system calls.<br />
* [http://pengutronix.de/software/ptx_ts/index_en.html ptx_ts] - Pengutronix' TimeStamper: A small filter prepending timestamps to STDOUT; a bit similar to grabserial but not limited to serial ports<br />
* [[Initcall Debug]] - a kernel command line option to show time taken for initcalls.<br />
* See also: [[Kernel Instrumentation]] which lists some known kernel instrumentation tools. These are of interest for measuring kernel startup time.<br />
<br />
=== Technologies and Techniques for Reducing Boot Time ===<br />
==== Bootloader speedups ====<br />
*[[Kernel XIP]] - Allow kernel to be executed in-place in ROM or FLASH.<br />
*[[DMA Copy Of Kernel On Startup]] - Copy kernel from Flash to RAM using DMA<br />
*[[Uncompressed kernel]] - An uncompressed kernel might boot faster<br />
*[[Fast Kernel Decompression]]<br />
<br />
==== Kernel speedups ====<br />
*[[Disable Console]] - Avoid overhead of console output during system startup.<br />
*Disable bug and printk - Avoid the overhead of bug and printk. Disadvantage is that you loose a lot of info.<br />
*[[RTC No Sync]] - Avoid delay to synchronize system time with RTC clock edge on startup.<br />
*[[Short IDE Delays]] - Reduce duration of IDE startup delays (this is effective but possibly dangerous).<br />
*[[Hardcode kernel module info]] - Reduce the overhead of loading a module, by hardcoding some information used for loading the relocation information<br />
*[[IDE No Probe]] - Force kernel to observe the ide<x>=noprobe option.<br />
*[[Preset LPJ]] - Allow the use of a preset loops_per_jiffy value.<br />
*[[Asynchronous function calls]] - Allow probing or other functions to proceed in parallel, to overlap time-consuming boot-up activities.<br />
**[[Threaded Device Probing]] - Allow drivers to probe devices in parallel. (not mainlined, now deprecated?)<br />
*[[Reordering of driver initialization]] - Allow driver bus probing to start as soon as possible.<br />
*[[Deferred Initcalls]] - defer non-essential module initialization routines to after primary boot<br />
*NAND ECC improvement - The pre 2.6.28 nand_ecc.c has room for improvement. You can find an improved version in the mtd git at http://git.infradead.org/mtd-2.6.git?a=blob_plain;f=drivers/mtd/nand/nand_ecc.c;hb=HEAD. Documentation for this is in http://git.infradead.org/mtd-2.6.git?a=blob_plain;f=Documentation/mtd/nand_ecc.txt;hb=HEAD. This is only interesting if your system uses software ECC correction.<br />
*Check what kernel memory allocator you use. Slob or slub might be better than slab (which is the default in older kernels) <br />
*If your system does not need it, you can remove SYSFS and even PROCFS from the kernel. In one test removing sysfs saved 20 ms.<br />
*Carefully investigate all kernel configuration options on whether they are applicable or not. Even if you select an option that is not used in the end, it contributes to the kernel size and therefore to the kernel load time (assuming you are not doing kernel XIP). Often this will require some trial and measure! E.g. selecting CONFIG_CC_OPTIMIZE_FOR_SIZE (found under general setup) gave in one case a boot improvement of 20 ms. Not dramamtic, but when reducing boot time every penny counts!<br />
*Moving to a different compiler version might lead to shorter and/or faster code. Most often newer compilers produce better code. You might also want to play with compiler options to see what works best.<br />
* If you use initramfs in your kernel and a compressed kernel it is better to have an uncompressed initramfs image. This is to avoid having to uncompress data twice. A patch for this has been submitted to LKML. See http://lkml.org/lkml/2008/11/22/112 <br />
<br />
===== File System issues =====<br />
Different file systems have different initialization (mounting) times, for the same data sets. This<br />
is a function of whether meta-data must be read from storage into RAM or not, and what algorithms are<br />
used during the mount procedure.<br />
<br />
* [[Filesystem Information]] - has information about boot-up times of various file systems<br />
* [[File Systems]] - has information on various file systems that are interesting for embedded systems. Also includes some improvement suggestions.<br />
* [[Avoid Initramfs]] - explains on why intramfs should be avoided if you want to minimize boot time<br />
* Split partitions. If mounting a file system takes long, you can consider splitting that filesystem in two parts, one with the info that is needed during or immediately after boot, and one which can be mounted later on.<br />
* [[Ramdisks demasked]] - explains why using a ram disk generally results in a longer boot time, not a shorter one.<br />
<br />
==== User-space and application speedups ====<br />
* [[Optimize RC Scripts]] - Reduce overhead of running RC scripts<br />
* [[Parallel RC Scripts]] - Run RC scripts in parallel instead of sequentially<br />
* [[Application XIP]] - Allow programs and libraries to be executed in-place in ROM or FLASH<br />
* [[Pre Linking]] - Avoid cost of runtime linking on first program load<br />
* Statically link applications. This avoids the costs of runtime linking. Useful if you have only a few applications. In that case it could also reduce the size of your image as no dynamic libraries are needed<br />
* GNU_HASH: ~ 50% speed improvement in dynamic linking<br />
** See http://sourceware.org/ml/binutils/2006-06/msg00418.html<br />
* [[Application Init Optimizations]] - Improvements in program load and init time via: <br />
** use of mmap vs. read<br />
** control over page mapping characteristics.<br />
* [[Include modules in kernel image]] - Avoid extra overhead of module loading by adding the modules to the kernel image<br />
* Avoid udev, it takes quite some time to populate the /dev directory. In an embedded system it is often known what devices are present and in any case you know what drivers are available, so you know what device entries might be needed in /dev. These should be created statically, not dynamically. mknod is your friend, udev is your enemy.<br />
* If you still like udev and also like fast boot-up's, you might go this way: start your system with udev enabled and make kind of a backup of the created device nodes. Now, modify your init script like this: instead running udev, copy the device nodes that you just made a backup of into the device tree. Now, install the hotplug-daemon like you always do. That trick avoids the device node creation at startup but stills lets your system create device nodes later on. <br />
* If your device has a network connection, preferably use static IP addresses. Getting an address from a DHCP server takes additional time and has extra overhead associated with it.<br />
* Moving to a different compiler version might lead to shorter and/or faster code. Most often newer compilers produce better code. You might also want to play with compiler options to see what works best.<br />
* If possible move from glibc to uClibc. This leads to smaller executables and hence to faster load times.<br />
* library optimiser tool: http://libraryopt.sourceforge.net/ <br/> This will allow you to create an optimised library. As unneeded functions are removed this should lead to a performance gain. Normally there will be library pages which contain unused code (adjacent to code that is used). After optimizing the library this does not occur any more, so less pages are needed and hence less page loads, so some time can be saved.<br />
* Function reordering: http://www.celinux.org/elc08_presentations/DDLink%20FunctionReorder%2008%2004.pdf <br/> This is a technique to rearrange the functions within an executable so they appear in the order they are needed. This improves the load time of the application as all initialization code is grouped into a set of pages, instead of being scattered over a number of pages.<br />
<br />
==== Suspend related improvements ====<br />
Another approach to improve boot time is to use a suspend related mechanism. Two approaches are known.<br />
* Using the standard hibernate/resume approach. This is what has been demonstrated by Chan Ju, Park, from Samsung. See sheet 23 and onwards from this [[Media:LinuxBootupTimeReduction4DSC.ppt|PPT]] and section 2.7 of this [http://www.kernel.org/doc/ols/2006/ols2006v2-pages-239-248.pdf paper]. <br /> Issue with this approach is that flash write is much slower than flash read, so the actual creation of the hibernate image might take quite a while.<br />
* Implementing snapshot boot. This is done by Hiroki Kaminaga from Sony and is described at [[Suspend To Disk For ARM|snapshot boot for ARM]] and http://elinux.org/upload/3/37/Snapshot-boot-final.pdf<br />This is similar to hibernate and resume, but the hibernate file is retained and used upon every boot. Disadvantage is that no writable partitions should be mounted at the time of making the snapshot. Otherwise inconsistencies will occur if a partition is modified, while applications in the hibernate file might have information in the snapshot related to the unmodified partition.<br />
<br />
==== Miscellaneous topics ====<br />
<br />
[[About Compression]] discusses the effects of compression on boot time. This can affect both the kernel boot time as well as user-space startup.<br />
<br />
==== Uninvestigated speedups ====<br />
<br />
This section is a holding pen for ideas for improvement that are not implemented yet but that could result in a boot time gain. Please leave a note here if you are working on one of these items to avoid duplicate work.<br />
<br />
* '''Prepopulated buffer cache''' - As initramfs performs an additional copy of the data the idea is to have a prepopulated buffer cache. A simplistic scenario would allow dumping the buffer cache when the booting is completed and the user applications have initialised. This data then could be used in a subsequent boot to initialize the buffer cache (of course without copying). A possible approach would be to have those data to reside into the kernel image and use them directly. Alternately they could be loaded separately. <br /> Unfortunately my knowledge of the internals in this section is not yet good enough to do a trial implementation.<br /> Caveats:<br />
** is it possible to have the buffer cache split into two different parts, one which is statically allocated, one which is dynamically allocated?<br />
** the pages in the prepopulated buffer cache probably cannot be discarded, so they should be pinned<br />
** apart from the buffer cache data itself also some other variables might need restoring<br />
** a similar approach could also be used for the cached file data.<br />
*'''Dedicated fs''' - currently a lot of abstraction is done in fs to make a nice abstraction allowing easy addition of new filesystems and creating a unified view of those filesystem. While this is pretty neat, the abstraction layers also introduce some overhead. A solution could be to create a dedicated fs system, which supports only one (or maybe 2) filesystems, and eliminates the abstraction overhead. This will give some benefit, but the chance of getting this into the mainline is zero.<br />
<br />
== Articles and Presentations ==<br />
* "The Right Approach to Boot Time Reduction" - ([http://elinux.org/images/f/f7/RightApproachMinimalBootTimes.pdf Slides] | [http://www.youtube.com/watch?v=ULa4TPy7z0c YouTube Video])<br />
** Andrew Murray has presented at ELC Europe on October 28, 2010 (Free Electrons video [http://free-electrons.com/pub/video/2010/elce/elce2010-murray-boot-time.webm here])<br />
** This included a < 1 second QT cold Linux boot case study for an SH7724 with some additional information about 'function re-ordering' in user-space<br />
** Similar slides with < 1 second case study for OMAP3530EVM can be found [http://www.slideshare.net/andrewmurraympc/t-iswift-boot here]<br />
* "One Second Linux Boot Demonstration (new version)" ([http://www.youtube.com/watch?v=-l_DSZe8_F8 Youtube video by MontaVista])<br />
* "Tools and Techniques for Reducing Bootup Time" ([[Media:Tools-and-technique-for-reducing-bootup-time.ppt|PPT]] | [[Media:Tools-and-technique-for-reducing-bootup-time.odp|ODP]] | [[Media:Tools-and-technique-for-reducing-bootup-time.pdf|PDF]] | [http://free-electrons.com/pub/video/2008/elce/elce2008-bird-reducing-bootup-time.ogv video])<br />
** Tim Bird has presented at ELC Europe, on November 7, 2008, his latest collection of tips and tricks for reducing bootup time<br />
** [[Tims Fastboot Tools]] has online materials in support of this presentation<br />
* [http://www.mvista.com/download/author.php?a=37 Christopher Hallinan] has done a presentation at the MontaVista Vision conference 2008 on the topic of reducing boot time. Slides available [http://www.mvista.com/download/power/Reducing-boot-time-techniques-for-fast-booting.pdf here]<br />
* [http://lwn.net/Articles/192082/ Optimizing Linker Load Times]<br />
** (introducing various kinds of bootuptime reduction, prelinking, etc.)<br />
* [http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Benchmarking-boot-latency-on-x86/ Benchmarking boot latency on x86]<br />
** By Gilad Ben-Yossef, July 2008<br />
** A tutorial on using TSC register and the kernel PRINTK_TIMES feature to measure x86 system boot time, including BIOS, bootloader, kernel and time to first user program.<br />
* [http://tree.celinuxforum.org/CelfPubWiki/KoreaTechJamboree3?action=AttachFile&do=get&target=The_Fast_Booting_of_Embedded_Linux.pdf Fast Booting of Embedded Linux]<br />
** By HoJoon Park, Electrons and Telecommunications Research Institute (ETRI), Korea, Presented at the CELF [http://tree.celinuxforum.org/CelfPubWiki/KoreaTechJamboree3 3rd Korean Technical Jamboree], July 2008<br />
** Explains several different reduction techniques used for different phases of bootup time<br />
*Tim Bird's (Sony) survey of boot-up time reduction techniques:<br />
**[http://kernel.org/doc/ols/2004/ols2004v1-pages-79-88.pdf Methods to Improve Boot-up Time in Linux] - Paper prepared for 2004 Ottawa Linux Symposium<br />
**{{pdf|ReducingStartupTime v0.8.pdf|Reducing Startup Time in Embedded Linux Systems}} - December 2003 Presentation describing some existing boot-up time reduction techniques and strategies.<br />
* [http://free-electrons.com/articles/optimizations Embedded Linux optimizations]<br />
** By Free Electrons<br />
** Tutorial to reduce size, RAM, speed, power and cost of a Linux based embedded system]<br />
*Parallelizing Linux Boot on CE Devices<br />
** [http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2007Presentations?action=AttachFile&do=view&target=par.pdf PDF of Presentation]<br />
**[http://free-electrons.com/pub/video/2007/elce/elce-2007-vitaly-wool-parallel-boot.ogg Video of Presentation]<br />
*[http://www.ibm.com/developerworks/linux/library/l-boot-faster/ Parallelize Applications for Faster Linux Boot]<br />
**Authored by M. Tim Jones for IBM Developer Works<br />
**This article shows you options to increase the speed with which Linux boots, including two options for parallelizing the initialization process. It also shows you how to visualize graphically the performance of the boot process.<br />
<br />
=== Case Studies ===<br />
* [http://www.makelinux.com/emb/fastboot/omap 300 milliseconds from boot loader to shell ARM with NAND] <br />
* Samsung proof-of-acceptability study for digital still camera: see [[Media:LinuxBootupTimeReduction4DSC.ppt|Boot Up Time Reduction PPT]] and the [http://www.kernel.org/doc/ols/2006/ols2006v2-pages-239-248.pdf paper] describing this.<br />
* [https://docs.blackfin.uclinux.org/doku.php?id=fast_boot_example Boot Linux from Processor Reset into user space in less than 1 Second]<br />
** In this white paper, Robin Getz describes the techniques used to fast-boot a blackfin development board.<br />
* [http://e2e.ti.com/support/embedded/f/354/t/51158.aspx Booting Linux dm365 Network Camera in 3.2 seconds]<br />
* [http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/p/7616/30088.aspx Boot of kernel and shell in 0.5 sec (not including u-boot and decompression)]<br />
<br />
* [http://www.linuxfordevices.com/c/a/News/Linux-boots-in-297-seconds/ Warp2, Lineo Solutions, 2008. 2.97 sec boot, ARM11, 400MHz]<br />
<br />
== Additional Projects/Mailing Lists/Resources ==<br />
=== Replacements for SysV 'init' ===<br />
The traditional method of starting a Linux system is to use /sbin/init, which<br />
processes the file /etc/inittab. This is an init program which processes a series of actions for different <br />
run-levels and system events (key-combinations and power events).<br />
<br />
See [http://linux.die.net/man/8/init the init(8) man page] and the [http://linux.die.net/man/5/inittab the inittab(5) man page].<br />
<br />
==== busybox init ====<br />
An 'init' applet is often included in [[BusyBox]]<br />
<br />
There used to be (as of 2000) some slight differences in the supported features of the 'inittab' file<br />
between busybox init and full-blown init. However, I don't know (as of 2010) if that's still the case.<br />
(See http://spblinux.de/2.0/doc/init.html for some details)<br />
<br />
Denys Vlasenko, one of the maintainers of busybox has suggested a replacement for traditional init<br />
for that tool called runsv. See http://busybox.net/~vda/init_vs_runsv.html<br />
<br />
==== upstart ====<br />
upstart is the name of a newer Linux desktop systems that provides the program /sbin/init,<br />
but with different operational semantics.<br />
<br />
* Home page: http://upstart.ubuntu.com/<br />
* Wikipedia page: http://en.wikipedia.org/wiki/Upstart<br />
<br />
==== Android init ====<br />
Android 'init' is a custom program for booting the Android system.<br />
<br />
See [[Android_Booting#.27init.27|Android 'init']]<br />
<br />
==== systemd ====<br />
systemd is a new project (as of May 2010) for starting daemons and services on a Linux desktop system<br />
<br />
See http://0pointer.de/blog/projects/systemd.html<br />
<br />
=== Kexec ===<br />
*Kexec is a system which allows a system to be '''rebooted''' without going through BIOS. That is, a Linux kernel can directly boot into another Linux kernel, without going through firmware. See the white paper at: [http://developer.osdl.org/andyp/kexec/whitepaper/kexec.pdf kexec.pdf]<br />
**2004 Kernel Summit presentation: [http://www.xenotime.net/linux/fastboot/fastboot-ks-2004.pdf fastboot.pdf]<br />
**here's another Kexec white paper:[http://www-106.ibm.com/developerworks/linux/library/l-kexec.html?ca=dgr-lnxw04 Reboot Fast]<br />
<br />
=== Splash Screen projects ===<br />
* [http://splashy.alioth.debian.org/wiki/ Splashy] - Technology to put up a spalsh screen early in the boot sequence. This is user-space code.<br />
** This seems to be the most current splash screen technology, for major distributions. A framebuffer driver for the kernel is required.<br />
* [http://dev.gentoo.org/~spock/projects/gensplash/ Gentoo Splashscreen] - newer technology to put a splash screen early in the boot sequence<br />
** See the HOWTO at: [http://gentoo-wiki.com/HOWTO_fbsplash HOWTO FBSplash]<br />
* [http://butterfeet.org/?p=8 PSplash] - PSplash is a userspace graphical boot splash screen for mainly embedded Linux devices supporting a 16bpp or 32bpp framebuffer.<br />
* [http://www.bootsplash.org/ bootsplash.org] - put up a splash screen early in boot sequence<br />
** This project requires kernel patches<br />
** This project is now abandoned, and work is being done on Splashy.<br />
<br />
=== Others ===<br />
<br />
*[http://www.linuxdevices.com/news/NS5907201615.html FSMLabs Fastboot] - press release by FSMLabs about fast booting of their product. Is any of this published?<br />
<br />
*[http://tree.celinuxforum.org/CelfPubWiki/ snapshot boot] - a technology uses software resume to boot up the system quickly.<br />
<br />
==== Apparently obsolete or abandoned material ====<br />
* [[Image:alert.gif]] ''in progress'' - [[Boot-up Time Reduction Howto]] - this is a project to catalog existing boot-up time reduction techniques.<br />
** Was originally intended to be the authoritative source for bootup time reduction information.<br />
** No one maintains it any more (as of Aug, 2008)<br />
*[[Image:alert.gif]]''no content yet'' - [[Boot-up Time Delay Taxonomy]] - list of delays categorized by boot phase, type and magnitude<br />
** Was to be a survey of common bootup delays found in embedded devices.<br />
** Was never really written.<br />
<br />
???<br />
* [[Bootup Time Spec]]<br />
* [[Bootup Time Things To Investigate]]<br />
* [[Bootup Time Working Group]]<br />
* [[Bootup Time Task List]]<br />
* [[Bootup Time Howto Task List]]<br />
* [[Fast Booting Translation]]<br />
<br />
== Companies, individuals or projects working on fast booting ==<br />
* Intel - Arjan van de Ven - see http://lwn.net/Articles/299483/<br />
* Tripeaks - see http://www.linuxdevices.com/news/NS8282586707.html<br />
* Lineo Solutions - see http://www.linuxdevices.com/news/NS5185504436.html<br />
* Monta Vista - see http://www.linuxdevices.com/news/NS2560585344.html<br />
* fastboot git tree - see http://lwn.net/Articles/299591/<br />
<br />
== Boot time check list ==<br />
<br />
From an [http://www.mail-archive.com/linux-embedded@vger.kernel.org/msg02139.html August 2009 discussion about boot time on ARM devices], several hints and advice regarding boot time optimization are available. While it may repeat a lot of above, below is a check list extracted from this discussion:<br />
<br />
* Is CPU's clock switched to maximum? If the kernel, bootloader or hardware is in charge of setting CPU power and speed scaling, then you should check that it boots with the CPU set at maximum speed instead of slowest. <br />
<br />
* Is your hardware (register) timing configuration of your SoC's memory interfaces (e.g. RAM and NOR/NAND timing) optimized? A lot of vendors ship their hardware with "well, it works, optimize later" settings. What you want is "as fast as possible, but sill stable and reliable" configuration. This might need some hardware knowledge and has to be customized to the individual memory devices used.<br />
<br />
* Does your boot loader uses I- and D-Cache? E.g. U-Boot doesn't enable D-Cache by default on ARM devices, as it needs customized MMU tables to do so.<br />
<br />
* Does kernel copy from permanent storage (e.g. NOR or NAND) to RAM use optimized functions? E.g. DMA, or on ARM at least load/store multiple commands (ldm/stm)?<br />
<br />
* If you use U-Boot's uImage, set "verify=no" in U-Boot to avoid checksum verification.<br />
<br />
* Optimize size of your kernel.<br />
** You might even try some of the embedded system kernel config options that, for example, eliminate all the printk strings, reduce data structures, or eliminate unneeded functionality.<br />
<br />
* How often is kernel (image) data copied? First by boot loader from storage to RAM, then by kernel's uncompressor to it's final destination? Once more? If you use compressed kernel and NOR flash, consider running the uncompressor XIP in NOR flash.<br />
<br />
* If you use compressed kernel, check compression algorithm. zlib is slow on decompression, and lzo is much faster. So if you implement lzo compression, you'll probably speed things up a little as well (check LKML for this). Having no compression at all may also be a good thing to try (see next topic).<br />
<br />
* Check to use uncompressed kernel (depends on your system configuration). Using an uncompressed kernel on a flash-based system may improve boot time. The reason is that compressed kernels are faster only when the throughput to the persistent storage is lower than the decompression throughput, and on typical embedded systems with DMA the throughput to memory outperforms the CPU-based decompression. Of course it depends on a lot of stuff like performance of flash controller, kernel storage filesystem performance, DMA controller performance, cache architecture etc. So it's individual per-system. Example: With using an uncomressed kernel (~2.8MB) uncompressing (running the uncompressor XIP in NOR flash) took ~0.5s longer than copying 2.8MB from flash to RAM.<br />
<br />
* Enable precalculated loops-per-jiffy<br />
<br />
* Enable kernel quiet option<br />
<br />
* If you use UBI: UBI is rather slow in attaching MTD devices. Everything is explained at MTD's [http://www.linux-mtd.infradead.org/doc/ubi.html#L_scalability UBI scalability] and [http://www.linux-mtd.infradead.org/doc/ubifs.html#L_scalability UBI fs scalability] sections. There is not very much you can do to speed it up but implement UBI2. UBIFS would stay intact. There were discussions about this and it does not seem to be impossibly difficult to do UBI2 ([http://www.linux-mtd.infradead.org/faq/ubi.html#L_attach_faster few ideas]).<br />
** In a follow-up e-mail, Sascha Hauer wrote:<br />
<pre> What's interesting about this is that the kernel NAND driver is much slower<br />
than the one in U-Boot. Looking at it it turned out that the kernel<br />
driver uses interrupts to wait for the controller to get ready.<br />
Switching this to polling nearly doubles the NAND performance. UBI<br />
mounts much faster now and this cuts off another few seconds from the<br />
boot process :) <br />
</pre><br />
<br />
* Use static device nodes during boot, and later setup busybox mdev for hotplug.<br />
<br />
* If you have network enabled, there might be some very long timeouts in the network code paths, which appear to be used whether you specify a static address or not. See the definitions of CONF_PRE_OPEN and CON_POST_OPEN in ''net/ipv4/ipconfig.c''. Check [http://patchwork.kernel.org/patch/31678/ ipdelay configuration patch].<br />
<br />
* Parallelize boot process.<br />
<br />
* Disable the option "Set system time from RTC on startup and resume", you can use the command hwclock -s at the of the init instead of slowing down the kernel.<br />
<br />
[[Category:Boot Time]]<br />
[[Category:Bootloader]]</div>Consthttp://elinux.org/Maintain_a_catalog_of_online_Linux_documentationMaintain a catalog of online Linux documentation2011-02-16T23:49:55Z<p>Const: /* Description */ fixes</p>
<hr />
<div>; Summary: Maintain a catalog of online Linux documentation<br />
<br />
; Proposer: Constantine Shulyupin<br />
<br />
== Description ==<br />
<br />
Rob Landley in his article "Where Linux Kernel Documentation Hides",<br />
wrote in 2008:<br />
<br />
Google is great at finding things, but it doesn't tell you what to <br />
search for. Google is not a reference work that allows one to see<br />
available topics and home in on an area of interest, moving from<br />
more general to more specific.<br />
...<br />
Indexing the web's Linux kernel documentation just to provide a<br />
comprehensive reference is a huge undertaking. Even keeping an index<br />
up to date after its creation would be a project on par with any<br />
other major kernel subsystem. But without knowing here the holes are,<br />
writing new documentation to try to fill in those holes tends to<br />
reinvent the wheel.<br />
...<br />
In the absence of an obvious place to go on the web to<br />
find the most up-to-date existing documentation, newly<br />
created documentation tends to be repetitive and overlapping.<br />
<br />
I would like to improve Linux Technology Reference:<br />
http://www.makelinux.net/reference .<br />
It is going to be a comprehensive and easily accessible catalog about<br />
Linux, GNU, FOSS and embedded Linux for developers. It now contains 900+<br />
links to 100+ sites, ordered in 200+ categories. Four top level<br />
categories are: Linux OS - about user space system and applications,<br />
Linux kernel, Embedded Linux and Additional topics (design,<br />
documentation).<br />
<br />
The should be like for Linux like MSDN Library for Windows.<br />
<br />
Planed improvements:<br />
* Adding convenient search capabilities.<br />
* Optionally changing catalog engine.<br />
* Promotion on Linux related sites.<br />
* Periodical updates and expanding. (The last big review was performed two years ego).<br />
* Adding feedback and link submit capabilities.<br />
<br />
== Related work ==<br />
* Linux Technology Reference - http://www.makelinux.net/reference<br />
<br />
== Scope ==<br />
From some weeks to some month, depending on number of changes and budged.<br />
Up to some days each month periodically.<br />
<br />
== Contractor Candidates ==<br />
Constantine Shulyupin (me, the author of the site)<br />
<br />
== Comments ==<br />
* User comments on the site -<br />
http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers&discussionID=3549498&gid=49301<br />
<br />
Rob Landley commented:<br />
<br />
Another question that got raised during the Q&A and which I didn't<br />
manage to competently answer during the talk:<br />
<br />
"Why not just use a Wiki"?<br />
<br />
Wikis are great ways of accumulating a slush pile, but they suck at<br />
indexing content. How do you find anything on wikipedia? Via Google.<br />
Wikipedia is cross-linked out the wazoo but it hasn't even got<br />
alphabetical topic browsing like a print encyclopedia if you wanted to<br />
skim through to see what's there without already knowing what you're<br />
looking for.<br />
<br />
To give newbies a way into the material you need an obvious place to<br />
start. Some kind of overview you can drill down from, which turns out<br />
to be hard to do.<br />
----<br />
<br />
Rob also commented:<br />
<br />
... my immediate question is long-term maintenance.<br />
How do you add new things, how do you check old ones haven't bit-rotted,<br />
and what happens if you're hit by a bus or sidelined by malaria for six<br />
months.<br />
<br />
----<br />
<br />
[[Category:Project proposals 2011]]</div>Consthttp://elinux.org/User:ConstUser:Const2011-02-05T17:03:16Z<p>Const: Created page with "* http://www.MakeLinux.com"</p>
<hr />
<div>* http://www.MakeLinux.com</div>Consthttp://elinux.org/Other_wikisOther wikis2011-01-25T19:44:24Z<p>Const: updates</p>
<hr />
<div>Here are some links to other wikis that we might copy the design of:<br />
<br />
* http://en.gentoo-wiki.com/<br />
* http://thinkwiki.org/<br />
* https://rt.wiki.kernel.org/<br />
* http://wiki.linuxquestions.org/<br />
* http://linux.wikia.com<br />
<br />
[[Category:Community]]</div>Consthttp://elinux.org/Other_wikisOther wikis2011-01-24T23:32:04Z<p>Const: http://eLinux.org/wiki/ is deleted</p>
<hr />
<div>Here are some links to other wikis that we might copy the design of:<br />
<br />
* gentoo wiki - http://gentoo-wiki.com/Main_Page<br />
* thinkwiki.org - http://thinkwiki.org/wiki/ThinkWiki<br />
* rt.wiki.kernel.org - http://rt.wiki.kernel.org/index.php/Main_Page<br />
<br />
[[Category:Community]]</div>Consthttp://elinux.org/Boot_TimeBoot Time2011-01-07T16:47:00Z<p>Const: /* Case Studies */</p>
<hr />
<div>== Introduction ==<br />
Boot Time includes topics such as measurement, analysis, human factors, initialization techniques, and reduction techniques.<br />
The time that a product takes to boot directly impacts the first perception an end user has of the product.<br />
Regardless of how attractive or well designed a consumer electronic device is, the time required to move the device from off to an interactive, usable state is critical to obtaining a positive end user experience. Turning on a device is Use Case #1.<br />
<br />
Booting up a device involves numerous steps and sequences of events. In order to use consistent terminology, the<br />
[[Bootup Time Working Group]] of the CE Linux Forum came up with a list of terms and their widely accepted definitions<br />
for this functionality area. See the following page for these terms:<br />
* [[Boot-up Time Definition Of Terms]]<br />
<br />
== Technology/Project Pages ==<br />
The following are individual pages with information about various technologies relevant to improving Boot Time for Linux. Some of these describe local patches available on this site. Others point to projects or patches maintained elsewhere.<br />
<br />
=== Measuring Boot-up Time ===<br />
*[[Printk Times]] - simple system for showing timing information for each printk.<br />
*[[Kernel Function Trace]] - system for reporting function timings in the kernel.<br />
*[[Linux Trace Toolkit]] - system for reporting timing data for certain kernel and process events.<br />
*[http://oprofile.sourceforge.net/news/ Oprofile] - system-wide profiler for Linux.<br />
*[[Bootchart]] - a tool for performance analysis and visualization of the Linux boot process. Resource utilization and process information are collected during the user-space portion of the boot process and are later rendered in a PNG, SVG or EPS encoded chart.<br />
*[http://people.redhat.com/berrange/systemtap/bootprobe/ Bootprobe] - a set of [[System Tap]] scripts for analyzing system bootup.<br />
* and, let us not forget: "cat /proc/uptime"<br />
* [[Tims Fastboot Tools#grabserial | grabserial]] - a nice utility from Tim Bird to log and timestamp console output<br />
* [[Tims Fastboot Tools#Tim's quick and dirty process trace|process trace]] - a simple patch from Tim Bird to log exec, fork and exit system calls.<br />
* [http://pengutronix.de/software/ptx_ts/index_en.html ptx_ts] - Pengutronix' TimeStamper: A small filter prepending timestamps to STDOUT; a bit similar to grabserial but not limited to serial ports<br />
* [[Initcall Debug]] - a kernel command line option to show time taken for initcalls.<br />
* See also: [[Kernel Instrumentation]] which lists some known kernel instrumentation tools. These are of interest for measuring kernel startup time.<br />
<br />
=== Technologies and Techniques for Reducing Boot Time ===<br />
==== Bootloader speedups ====<br />
*[[Kernel XIP]] - Allow kernel to be executed in-place in ROM or FLASH.<br />
*[[DMA Copy Of Kernel On Startup]] - Copy kernel from Flash to RAM using DMA<br />
*[[Uncompressed kernel]] - An uncompressed kernel might boot faster<br />
*[[Fast Kernel Decompression]]<br />
<br />
==== Kernel speedups ====<br />
*[[Disable Console]] - Avoid overhead of console output during system startup.<br />
*Disable bug and printk - Avoid the overhead of bug and printk. Disadvantage is that you loose a lot of info.<br />
*[[RTC No Sync]] - Avoid delay to synchronize system time with RTC clock edge on startup.<br />
*[[Short IDE Delays]] - Reduce duration of IDE startup delays (this is effective but possibly dangerous).<br />
*[[Hardcode kernel module info]] - Reduce the overhead of loading a module, by hardcoding some information used for loading the relocation information<br />
*[[IDE No Probe]] - Force kernel to observe the ide<x>=noprobe option.<br />
*[[Preset LPJ]] - Allow the use of a preset loops_per_jiffy value.<br />
*[[Asynchronous function calls]] - Allow probing or other functions to proceed in parallel, to overlap time-consuming boot-up activities.<br />
**[[Threaded Device Probing]] - Allow drivers to probe devices in parallel. (not mainlined, now deprecated?)<br />
*[[Reordering of driver initialization]] - Allow driver bus probing to start as soon as possible.<br />
*[[Deferred Initcalls]] - defer non-essential module initialization routines to after primary boot<br />
*NAND ECC improvement - The pre 2.6.28 nand_ecc.c has room for improvement. You can find an improved version in the mtd git at http://git.infradead.org/mtd-2.6.git?a=blob_plain;f=drivers/mtd/nand/nand_ecc.c;hb=HEAD. Documentation for this is in http://git.infradead.org/mtd-2.6.git?a=blob_plain;f=Documentation/mtd/nand_ecc.txt;hb=HEAD. This is only interesting if your system uses software ECC correction.<br />
*Check what kernel memory allocator you use. Slob or slub might be better than slab (which is the default in older kernels) <br />
*If your system does not need it, you can remove SYSFS and even PROCFS from the kernel. In one test removing sysfs saved 20 ms.<br />
*Carefully investigate all kernel configuration options on whether they are applicable or not. Even if you select an option that is not used in the end, it contributes to the kernel size and therefore to the kernel load time (assuming you are not doing kernel XIP). Often this will require some trial and measure! E.g. selecting CONFIG_CC_OPTIMIZE_FOR_SIZE (found under general setup) gave in one case a boot improvement of 20 ms. Not dramamtic, but when reducing boot time every penny counts!<br />
*Moving to a different compiler version might lead to shorter and/or faster code. Most often newer compilers produce better code. You might also want to play with compiler options to see what works best.<br />
* If you use initramfs in your kernel and a compressed kernel it is better to have an uncompressed initramfs image. This is to avoid having to uncompress data twice. A patch for this has been submitted to LKML. See http://lkml.org/lkml/2008/11/22/112 <br />
<br />
===== File System issues =====<br />
Different file systems have different initialization (mounting) times, for the same data sets. This<br />
is a function of whether meta-data must be read from storage into RAM or not, and what algorithms are<br />
used during the mount procedure.<br />
<br />
* [[Filesystem Information]] - has information about boot-up times of various file systems<br />
* [[File Systems]] - has information on various file systems that are interesting for embedded systems. Also includes some improvement suggestions.<br />
* [[Avoid Initramfs]] - explains on why intramfs should be avoided if you want to minimize boot time<br />
* Split partitions. If mounting a file system takes long, you can consider splitting that filesystem in two parts, one with the info that is needed during or immediately after boot, and one which can be mounted later on.<br />
* [[Ramdisks demasked]] - explains why using a ram disk generally results in a longer boot time, not a shorter one.<br />
<br />
==== User-space and application speedups ====<br />
* [[Optimize RC Scripts]] - Reduce overhead of running RC scripts<br />
* [[Parallel RC Scripts]] - Run RC scripts in parallel instead of sequentially<br />
* [[Application XIP]] - Allow programs and libraries to be executed in-place in ROM or FLASH<br />
* [[Pre Linking]] - Avoid cost of runtime linking on first program load<br />
* Statically link applications. This avoids the costs of runtime linking. Useful if you have only a few applications. In that case it could also reduce the size of your image as no dynamic libraries are needed<br />
* GNU_HASH: ~ 50% speed improvement in dynamic linking<br />
** See http://sourceware.org/ml/binutils/2006-06/msg00418.html<br />
* [[Application Init Optimizations]] - Improvements in program load and init time via: <br />
** use of mmap vs. read<br />
** control over page mapping characteristics.<br />
* [[Include modules in kernel image]] - Avoid extra overhead of module loading by adding the modules to the kernel image<br />
* Avoid udev, it takes quite some time to populate the /dev directory. In an embedded system it is often known what devices are present and in any case you know what drivers are available, so you know what device entries might be needed in /dev. These should be created statically, not dynamically. mknod is your friend, udev is your enemy.<br />
* If you still like udev and also like fast boot-up's, you might go this way: start your system with udev enabled and make kind of a backup of the created device nodes. Now, modify your init script like this: instead running udev, copy the device nodes that you just made a backup of into the device tree. Now, install the hotplug-daemon like you always do. That trick avoids the device node creation at startup but stills lets your system create device nodes later on. <br />
* If your device has a network connection, preferably use static IP addresses. Getting an address from a DHCP server takes additional time and has extra overhead associated with it.<br />
* Moving to a different compiler version might lead to shorter and/or faster code. Most often newer compilers produce better code. You might also want to play with compiler options to see what works best.<br />
* If possible move from glibc to uClibc. This leads to smaller executables and hence to faster load times.<br />
* library optimiser tool: http://libraryopt.sourceforge.net/ <br/> This will allow you to create an optimised library. As unneeded functions are removed this should lead to a performance gain. Normally there will be library pages which contain unused code (adjacent to code that is used). After optimizing the library this does not occur any more, so less pages are needed and hence less page loads, so some time can be saved.<br />
* Function reordering: http://www.celinux.org/elc08_presentations/DDLink%20FunctionReorder%2008%2004.pdf <br/> This is a technique to rearrange the functions within an executable so they appear in the order they are needed. This improves the load time of the application as all initialization code is grouped into a set of pages, instead of being scattered over a number of pages.<br />
<br />
==== Suspend related improvements ====<br />
Another approach to improve boot time is to use a suspend related mechanism. Two approaches are known.<br />
* Using the standard hibernate/resume approach. This is what has been demonstrated by Chan Ju, Park, from Samsung. See sheet 23 and onwards from this [[Media:LinuxBootupTimeReduction4DSC.ppt|PPT]] and section 2.7 of this [http://www.kernel.org/doc/ols/2006/ols2006v2-pages-239-248.pdf paper]. <br /> Issue with this approach is that flash write is much slower than flash read, so the actual creation of the hibernate image might take quite a while.<br />
* Implementing snapshot boot. This is done by Hiroki Kaminaga from Sony and is described at [[Suspend To Disk For ARM|snapshot boot for ARM]] and http://elinux.org/upload/3/37/Snapshot-boot-final.pdf<br />This is similar to hibernate and resume, but the hibernate file is retained and used upon every boot. Disadvantage is that no writable partitions should be mounted at the time of making the snapshot. Otherwise inconsistencies will occur if a partition is modified, while applications in the hibernate file might have information in the snapshot related to the unmodified partition.<br />
<br />
==== Miscellaneous topics ====<br />
<br />
[[About Compression]] discusses the effects of compression on boot time. This can affect both the kernel boot time as well as user-space startup.<br />
<br />
==== Uninvestigated speedups ====<br />
<br />
This section is a holding pen for ideas for improvement that are not implemented yet but that could result in a boot time gain. Please leave a note here if you are working on one of these items to avoid duplicate work.<br />
<br />
* '''Prepopulated buffer cache''' - As initramfs performs an additional copy of the data the idea is to have a prepopulated buffer cache. A simplistic scenario would allow dumping the buffer cache when the booting is completed and the user applications have initialised. This data then could be used in a subsequent boot to initialize the buffer cache (of course without copying). A possible approach would be to have those data to reside into the kernel image and use them directly. Alternately they could be loaded separately. <br /> Unfortunately my knowledge of the internals in this section is not yet good enough to do a trial implementation.<br /> Caveats:<br />
** is it possible to have the buffer cache split into two different parts, one which is statically allocated, one which is dynamically allocated?<br />
** the pages in the prepopulated buffer cache probably cannot be discarded, so they should be pinned<br />
** apart from the buffer cache data itself also some other variables might need restoring<br />
** a similar approach could also be used for the cached file data.<br />
*'''Dedicated fs''' - currently a lot of abstraction is done in fs to make a nice abstraction allowing easy addition of new filesystems and creating a unified view of those filesystem. While this is pretty neat, the abstraction layers also introduce some overhead. A solution could be to create a dedicated fs system, which supports only one (or maybe 2) filesystems, and eliminates the abstraction overhead. This will give some benefit, but the chance of getting this into the mainline is zero.<br />
<br />
== Articles and Presentations ==<br />
* "The Right Approach to Boot Time Reduction" - ([http://elinux.org/images/f/f7/RightApproachMinimalBootTimes.pdf Slides] | [http://www.youtube.com/watch?v=ULa4TPy7z0c YouTube Video])<br />
** Andrew Murray has presented at ELC Europe on October 28, 2010<br />
** This included a < 1 second QT cold Linux boot case study for an SH7724 with some additional information about 'function re-ordering' in user-space<br />
** Similar slides with < 1 second case study for OMAP3530EVM can be found [http://www.slideshare.net/andrewmurraympc/t-iswift-boot here]<br />
* "One Second Linux Boot Demonstration (new version)" ([http://www.youtube.com/watch?v=-l_DSZe8_F8 Youtube video by MontaVista])<br />
* "Tools and Techniques for Reducing Bootup Time" ([[Media:Tools-and-technique-for-reducing-bootup-time.ppt|PPT]] | [[Media:Tools-and-technique-for-reducing-bootup-time.odp|ODP]] | [[Media:Tools-and-technique-for-reducing-bootup-time.pdf|PDF]] | [http://free-electrons.com/pub/video/2008/elce/elce2008-bird-reducing-bootup-time.ogv video])<br />
** Tim Bird has presented at ELC Europe, on November 7, 2008, his latest collection of tips and tricks for reducing bootup time<br />
** [[Tims Fastboot Tools]] has online materials in support of this presentation<br />
* [http://www.mvista.com/download/author.php?a=37 Christopher Hallinan] has done a presentation at the MontaVista Vision conference 2008 on the topic of reducing boot time. Slides available [http://www.mvista.com/download/power/Reducing-boot-time-techniques-for-fast-booting.pdf here]<br />
* [http://lwn.net/Articles/192082/ Optimizing Linker Load Times]<br />
** (introducing various kinds of bootuptime reduction, prelinking, etc.)<br />
* [http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Benchmarking-boot-latency-on-x86/ Benchmarking boot latency on x86]<br />
** By Gilad Ben-Yossef, July 2008<br />
** A tutorial on using TSC register and the kernel PRINTK_TIMES feature to measure x86 system boot time, including BIOS, bootloader, kernel and time to first user program.<br />
* [http://tree.celinuxforum.org/CelfPubWiki/KoreaTechJamboree3?action=AttachFile&do=get&target=The_Fast_Booting_of_Embedded_Linux.pdf Fast Booting of Embedded Linux]<br />
** By HoJoon Park, Electrons and Telecommunications Research Institute (ETRI), Korea, Presented at the CELF [http://tree.celinuxforum.org/CelfPubWiki/KoreaTechJamboree3 3rd Korean Technical Jamboree], July 2008<br />
** Explains several different reduction techniques used for different phases of bootup time<br />
*Tim Bird's (Sony) survey of boot-up time reduction techniques:<br />
**[http://kernel.org/doc/ols/2004/ols2004v1-pages-79-88.pdf Methods to Improve Boot-up Time in Linux] - Paper prepared for 2004 Ottawa Linux Symposium<br />
**{{pdf|ReducingStartupTime v0.8.pdf|Reducing Startup Time in Embedded Linux Systems}} - December 2003 Presentation describing some existing boot-up time reduction techniques and strategies.<br />
* [http://free-electrons.com/articles/optimizations Embedded Linux optimizations]<br />
** By Free Electrons<br />
** Tutorial to reduce size, RAM, speed, power and cost of a Linux based embedded system]<br />
*Parallelizing Linux Boot on CE Devices<br />
** [http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2007Presentations?action=AttachFile&do=view&target=par.pdf PDF of Presentation]<br />
**[http://free-electrons.com/pub/video/2007/elce/elce-2007-vitaly-wool-parallel-boot.ogg Video of Presentation]<br />
*[http://www.ibm.com/developerworks/linux/library/l-boot-faster/ Parallelize Applications for Faster Linux Boot]<br />
**Authored by M. Tim Jones for IBM Developer Works<br />
**This article shows you options to increase the speed with which Linux boots, including two options for parallelizing the initialization process. It also shows you how to visualize graphically the performance of the boot process.<br />
<br />
=== Case Studies ===<br />
* [http://www.makelinux.com/emb/fastboot/ 560 milliseconds from reset to shell on 300 MHz ARM DM365] <br />
* Samsung proof-of-acceptability study for digital still camera: see [[Media:LinuxBootupTimeReduction4DSC.ppt|Boot Up Time Reduction PPT]] and the [http://www.kernel.org/doc/ols/2006/ols2006v2-pages-239-248.pdf paper] describing this.<br />
* [https://docs.blackfin.uclinux.org/doku.php?id=fast_boot_example Boot Linux from Processor Reset into user space in less than 1 Second]<br />
** In this white paper, Robin Getz describes the techniques used to fast-boot a blackfin development board.<br />
* [http://e2e.ti.com/support/embedded/f/354/t/51158.aspx Booting Linux dm365 Network Camera in 3.2 seconds]<br />
* [http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/p/7616/30088.aspx Boot of kernel and shell in 0.5 sec (not including u-boot and decompression)]<br />
<br />
* [http://www.linuxfordevices.com/c/a/News/Linux-boots-in-297-seconds/ Warp2, Lineo Solutions, 2008. 2.97 sec boot, ARM11, 400MHz]<br />
<br />
== Additional Projects/Mailing Lists/Resources ==<br />
=== Replacements for SysV 'init' ===<br />
The traditional method of starting a Linux system is to use /sbin/init, which<br />
processes the file /etc/inittab. This is an init program which processes a series of actions for different <br />
run-levels and system events (key-combinations and power events).<br />
<br />
See [http://linux.die.net/man/8/init the init(8) man page] and the [http://linux.die.net/man/5/inittab the inittab(5) man page].<br />
<br />
==== busybox init ====<br />
An 'init' applet is often included in [[BusyBox]]<br />
<br />
There used to be (as of 2000) some slight differences in the supported features of the 'inittab' file<br />
between busybox init and full-blown init. However, I don't know (as of 2010) if that's still the case.<br />
(See http://spblinux.de/2.0/doc/init.html for some details)<br />
<br />
Denys Vlasenko, one of the maintainers of busybox has suggested a replacement for traditional init<br />
for that tool called runsv. See http://busybox.net/~vda/init_vs_runsv.html<br />
<br />
==== upstart ====<br />
upstart is the name of a newer Linux desktop systems that provides the program /sbin/init,<br />
but with different operational semantics.<br />
<br />
* Home page: http://upstart.ubuntu.com/<br />
* Wikipedia page: http://en.wikipedia.org/wiki/Upstart<br />
<br />
==== Android init ====<br />
Android 'init' is a custom program for booting the Android system.<br />
<br />
See [[Android_Booting#.27init.27|Android 'init']]<br />
<br />
==== systemd ====<br />
systemd is a new project (as of May 2010) for starting daemons and services on a Linux desktop system<br />
<br />
See http://0pointer.de/blog/projects/systemd.html<br />
<br />
=== Kexec ===<br />
*Kexec is a system which allows a system to be '''rebooted''' without going through BIOS. That is, a Linux kernel can directly boot into another Linux kernel, without going through firmware. See the white paper at: [http://developer.osdl.org/andyp/kexec/whitepaper/kexec.pdf kexec.pdf]<br />
**2004 Kernel Summit presentation: [http://www.xenotime.net/linux/fastboot/fastboot-ks-2004.pdf fastboot.pdf]<br />
**here's another Kexec white paper:[http://www-106.ibm.com/developerworks/linux/library/l-kexec.html?ca=dgr-lnxw04 Reboot Fast]<br />
<br />
=== Splash Screen projects ===<br />
* [http://splashy.alioth.debian.org/wiki/ Splashy] - Technology to put up a spalsh screen early in the boot sequence. This is user-space code.<br />
** This seems to be the most current splash screen technology, for major distributions. A framebuffer driver for the kernel is required.<br />
* [http://dev.gentoo.org/~spock/projects/gensplash/ Gentoo Splashscreen] - newer technology to put a splash screen early in the boot sequence<br />
** See the HOWTO at: [http://gentoo-wiki.com/HOWTO_fbsplash HOWTO FBSplash]<br />
* [http://butterfeet.org/?p=8 PSplash] - PSplash is a userspace graphical boot splash screen for mainly embedded Linux devices supporting a 16bpp or 32bpp framebuffer.<br />
* [http://www.bootsplash.org/ bootsplash.org] - put up a splash screen early in boot sequence<br />
** This project requires kernel patches<br />
** This project is now abandoned, and work is being done on Splashy.<br />
<br />
=== Others ===<br />
<br />
*[http://www.linuxdevices.com/news/NS5907201615.html FSMLabs Fastboot] - press release by FSMLabs about fast booting of their product. Is any of this published?<br />
<br />
*[http://tree.celinuxforum.org/CelfPubWiki/ snapshot boot] - a technology uses software resume to boot up the system quickly.<br />
<br />
==== Apparently obsolete or abandoned material ====<br />
* [[Image:alert.gif]] ''in progress'' - [[Boot-up Time Reduction Howto]] - this is a project to catalog existing boot-up time reduction techniques.<br />
** Was originally intended to be the authoritative source for bootup time reduction information.<br />
** No one maintains it any more (as of Aug, 2008)<br />
*[[Image:alert.gif]]''no content yet'' - [[Boot-up Time Delay Taxonomy]] - list of delays categorized by boot phase, type and magnitude<br />
** Was to be a survey of common bootup delays found in embedded devices.<br />
** Was never really written.<br />
<br />
???<br />
* [[Bootup Time Spec]]<br />
* [[Bootup Time Things To Investigate]]<br />
* [[Bootup Time Working Group]]<br />
* [[Bootup Time Task List]]<br />
* [[Bootup Time Howto Task List]]<br />
* [[Fast Booting Translation]]<br />
<br />
== Companies, individuals or projects working on fast booting ==<br />
* Intel - Arjan van de Ven - see http://lwn.net/Articles/299483/<br />
* Tripeaks - see http://www.linuxdevices.com/news/NS8282586707.html<br />
* Lineo Solutions - see http://www.linuxdevices.com/news/NS5185504436.html<br />
* Monta Vista - see http://www.linuxdevices.com/news/NS2560585344.html<br />
* fastboot git tree - see http://lwn.net/Articles/299591/<br />
<br />
== Boot time check list ==<br />
<br />
From an [http://www.mail-archive.com/linux-embedded@vger.kernel.org/msg02139.html August 2009 discussion about boot time on ARM devices], several hints and advice regarding boot time optimization are available. While it may repeat a lot of above, below is a check list extracted from this discussion:<br />
<br />
* Is CPU's clock switched to maximum? If the kernel, bootloader or hardware is in charge of setting CPU power and speed scaling, then you should check that it boots with the CPU set at maximum speed instead of slowest. <br />
<br />
* Is your hardware (register) timing configuration of your SoC's memory interfaces (e.g. RAM and NOR/NAND timing) optimized? A lot of vendors ship their hardware with "well, it works, optimize later" settings. What you want is "as fast as possible, but sill stable and reliable" configuration. This might need some hardware knowledge and has to be customized to the individual memory devices used.<br />
<br />
* Does your boot loader uses I- and D-Cache? E.g. U-Boot doesn't enable D-Cache by default on ARM devices, as it needs customized MMU tables to do so.<br />
<br />
* Does kernel copy from permanent storage (e.g. NOR or NAND) to RAM use optimized functions? E.g. DMA, or on ARM at least load/store multiple commands (ldm/stm)?<br />
<br />
* If you use U-Boot's uImage, set "verify=no" in U-Boot to avoid checksum verification.<br />
<br />
* Optimize size of your kernel.<br />
** You might even try some of the embedded system kernel config options that, for example, eliminate all the printk strings, reduce data structures, or eliminate unneeded functionality.<br />
<br />
* How often is kernel (image) data copied? First by boot loader from storage to RAM, then by kernel's uncompressor to it's final destination? Once more? If you use compressed kernel and NOR flash, consider running the uncompressor XIP in NOR flash.<br />
<br />
* If you use compressed kernel, check compression algorithm. zlib is slow on decompression, and lzo is much faster. So if you implement lzo compression, you'll probably speed things up a little as well (check LKML for this). Having no compression at all may also be a good thing to try (see next topic).<br />
<br />
* Check to use uncompressed kernel (depends on your system configuration). Using an uncompressed kernel on a flash-based system may improve boot time. The reason is that compressed kernels are faster only when the throughput to the persistent storage is lower than the decompression throughput, and on typical embedded systems with DMA the throughput to memory outperforms the CPU-based decompression. Of course it depends on a lot of stuff like performance of flash controller, kernel storage filesystem performance, DMA controller performance, cache architecture etc. So it's individual per-system. Example: With using an uncomressed kernel (~2.8MB) uncompressing (running the uncompressor XIP in NOR flash) took ~0.5s longer than copying 2.8MB from flash to RAM.<br />
<br />
* Enable precalculated loops-per-jiffy<br />
<br />
* Enable kernel quiet option<br />
<br />
* If you use UBI: UBI is rather slow in attaching MTD devices. Everything is explained at MTD's [http://www.linux-mtd.infradead.org/doc/ubi.html#L_scalability UBI scalability] and [http://www.linux-mtd.infradead.org/doc/ubifs.html#L_scalability UBI fs scalability] sections. There is not very much you can do to speed it up but implement UBI2. UBIFS would stay intact. There were discussions about this and it does not seem to be impossibly difficult to do UBI2 ([http://www.linux-mtd.infradead.org/faq/ubi.html#L_attach_faster few ideas]).<br />
** In a follow-up e-mail, Sascha Hauer wrote:<br />
<pre> What's interesting about this is that the kernel NAND driver is much slower<br />
than the one in U-Boot. Looking at it it turned out that the kernel<br />
driver uses interrupts to wait for the controller to get ready.<br />
Switching this to polling nearly doubles the NAND performance. UBI<br />
mounts much faster now and this cuts off another few seconds from the<br />
boot process :) <br />
</pre><br />
<br />
* Use static device nodes during boot, and later setup busybox mdev for hotplug.<br />
<br />
* If you have network enabled, there might be some very long timeouts in the network code paths, which appear to be used whether you specify a static address or not. See the definitions of CONF_PRE_OPEN and CON_POST_OPEN in ''net/ipv4/ipconfig.c''. Check [http://patchwork.kernel.org/patch/31678/ ipdelay configuration patch].<br />
<br />
* Parallelize boot process.<br />
<br />
* Disable the option "Set system time from RTC on startup and resume", you can use the command hwclock -s at the of the init instead of slowing down the kernel.<br />
<br />
[[Category:Boot Time]]<br />
[[Category:Bootloader]]</div>Consthttp://elinux.org/Boot_TimeBoot Time2011-01-07T16:45:12Z<p>Const: /* Case Studies */</p>
<hr />
<div>== Introduction ==<br />
Boot Time includes topics such as measurement, analysis, human factors, initialization techniques, and reduction techniques.<br />
The time that a product takes to boot directly impacts the first perception an end user has of the product.<br />
Regardless of how attractive or well designed a consumer electronic device is, the time required to move the device from off to an interactive, usable state is critical to obtaining a positive end user experience. Turning on a device is Use Case #1.<br />
<br />
Booting up a device involves numerous steps and sequences of events. In order to use consistent terminology, the<br />
[[Bootup Time Working Group]] of the CE Linux Forum came up with a list of terms and their widely accepted definitions<br />
for this functionality area. See the following page for these terms:<br />
* [[Boot-up Time Definition Of Terms]]<br />
<br />
== Technology/Project Pages ==<br />
The following are individual pages with information about various technologies relevant to improving Boot Time for Linux. Some of these describe local patches available on this site. Others point to projects or patches maintained elsewhere.<br />
<br />
=== Measuring Boot-up Time ===<br />
*[[Printk Times]] - simple system for showing timing information for each printk.<br />
*[[Kernel Function Trace]] - system for reporting function timings in the kernel.<br />
*[[Linux Trace Toolkit]] - system for reporting timing data for certain kernel and process events.<br />
*[http://oprofile.sourceforge.net/news/ Oprofile] - system-wide profiler for Linux.<br />
*[[Bootchart]] - a tool for performance analysis and visualization of the Linux boot process. Resource utilization and process information are collected during the user-space portion of the boot process and are later rendered in a PNG, SVG or EPS encoded chart.<br />
*[http://people.redhat.com/berrange/systemtap/bootprobe/ Bootprobe] - a set of [[System Tap]] scripts for analyzing system bootup.<br />
* and, let us not forget: "cat /proc/uptime"<br />
* [[Tims Fastboot Tools#grabserial | grabserial]] - a nice utility from Tim Bird to log and timestamp console output<br />
* [[Tims Fastboot Tools#Tim's quick and dirty process trace|process trace]] - a simple patch from Tim Bird to log exec, fork and exit system calls.<br />
* [http://pengutronix.de/software/ptx_ts/index_en.html ptx_ts] - Pengutronix' TimeStamper: A small filter prepending timestamps to STDOUT; a bit similar to grabserial but not limited to serial ports<br />
* [[Initcall Debug]] - a kernel command line option to show time taken for initcalls.<br />
* See also: [[Kernel Instrumentation]] which lists some known kernel instrumentation tools. These are of interest for measuring kernel startup time.<br />
<br />
=== Technologies and Techniques for Reducing Boot Time ===<br />
==== Bootloader speedups ====<br />
*[[Kernel XIP]] - Allow kernel to be executed in-place in ROM or FLASH.<br />
*[[DMA Copy Of Kernel On Startup]] - Copy kernel from Flash to RAM using DMA<br />
*[[Uncompressed kernel]] - An uncompressed kernel might boot faster<br />
*[[Fast Kernel Decompression]]<br />
<br />
==== Kernel speedups ====<br />
*[[Disable Console]] - Avoid overhead of console output during system startup.<br />
*Disable bug and printk - Avoid the overhead of bug and printk. Disadvantage is that you loose a lot of info.<br />
*[[RTC No Sync]] - Avoid delay to synchronize system time with RTC clock edge on startup.<br />
*[[Short IDE Delays]] - Reduce duration of IDE startup delays (this is effective but possibly dangerous).<br />
*[[Hardcode kernel module info]] - Reduce the overhead of loading a module, by hardcoding some information used for loading the relocation information<br />
*[[IDE No Probe]] - Force kernel to observe the ide<x>=noprobe option.<br />
*[[Preset LPJ]] - Allow the use of a preset loops_per_jiffy value.<br />
*[[Asynchronous function calls]] - Allow probing or other functions to proceed in parallel, to overlap time-consuming boot-up activities.<br />
**[[Threaded Device Probing]] - Allow drivers to probe devices in parallel. (not mainlined, now deprecated?)<br />
*[[Reordering of driver initialization]] - Allow driver bus probing to start as soon as possible.<br />
*[[Deferred Initcalls]] - defer non-essential module initialization routines to after primary boot<br />
*NAND ECC improvement - The pre 2.6.28 nand_ecc.c has room for improvement. You can find an improved version in the mtd git at http://git.infradead.org/mtd-2.6.git?a=blob_plain;f=drivers/mtd/nand/nand_ecc.c;hb=HEAD. Documentation for this is in http://git.infradead.org/mtd-2.6.git?a=blob_plain;f=Documentation/mtd/nand_ecc.txt;hb=HEAD. This is only interesting if your system uses software ECC correction.<br />
*Check what kernel memory allocator you use. Slob or slub might be better than slab (which is the default in older kernels) <br />
*If your system does not need it, you can remove SYSFS and even PROCFS from the kernel. In one test removing sysfs saved 20 ms.<br />
*Carefully investigate all kernel configuration options on whether they are applicable or not. Even if you select an option that is not used in the end, it contributes to the kernel size and therefore to the kernel load time (assuming you are not doing kernel XIP). Often this will require some trial and measure! E.g. selecting CONFIG_CC_OPTIMIZE_FOR_SIZE (found under general setup) gave in one case a boot improvement of 20 ms. Not dramamtic, but when reducing boot time every penny counts!<br />
*Moving to a different compiler version might lead to shorter and/or faster code. Most often newer compilers produce better code. You might also want to play with compiler options to see what works best.<br />
* If you use initramfs in your kernel and a compressed kernel it is better to have an uncompressed initramfs image. This is to avoid having to uncompress data twice. A patch for this has been submitted to LKML. See http://lkml.org/lkml/2008/11/22/112 <br />
<br />
===== File System issues =====<br />
Different file systems have different initialization (mounting) times, for the same data sets. This<br />
is a function of whether meta-data must be read from storage into RAM or not, and what algorithms are<br />
used during the mount procedure.<br />
<br />
* [[Filesystem Information]] - has information about boot-up times of various file systems<br />
* [[File Systems]] - has information on various file systems that are interesting for embedded systems. Also includes some improvement suggestions.<br />
* [[Avoid Initramfs]] - explains on why intramfs should be avoided if you want to minimize boot time<br />
* Split partitions. If mounting a file system takes long, you can consider splitting that filesystem in two parts, one with the info that is needed during or immediately after boot, and one which can be mounted later on.<br />
* [[Ramdisks demasked]] - explains why using a ram disk generally results in a longer boot time, not a shorter one.<br />
<br />
==== User-space and application speedups ====<br />
* [[Optimize RC Scripts]] - Reduce overhead of running RC scripts<br />
* [[Parallel RC Scripts]] - Run RC scripts in parallel instead of sequentially<br />
* [[Application XIP]] - Allow programs and libraries to be executed in-place in ROM or FLASH<br />
* [[Pre Linking]] - Avoid cost of runtime linking on first program load<br />
* Statically link applications. This avoids the costs of runtime linking. Useful if you have only a few applications. In that case it could also reduce the size of your image as no dynamic libraries are needed<br />
* GNU_HASH: ~ 50% speed improvement in dynamic linking<br />
** See http://sourceware.org/ml/binutils/2006-06/msg00418.html<br />
* [[Application Init Optimizations]] - Improvements in program load and init time via: <br />
** use of mmap vs. read<br />
** control over page mapping characteristics.<br />
* [[Include modules in kernel image]] - Avoid extra overhead of module loading by adding the modules to the kernel image<br />
* Avoid udev, it takes quite some time to populate the /dev directory. In an embedded system it is often known what devices are present and in any case you know what drivers are available, so you know what device entries might be needed in /dev. These should be created statically, not dynamically. mknod is your friend, udev is your enemy.<br />
* If you still like udev and also like fast boot-up's, you might go this way: start your system with udev enabled and make kind of a backup of the created device nodes. Now, modify your init script like this: instead running udev, copy the device nodes that you just made a backup of into the device tree. Now, install the hotplug-daemon like you always do. That trick avoids the device node creation at startup but stills lets your system create device nodes later on. <br />
* If your device has a network connection, preferably use static IP addresses. Getting an address from a DHCP server takes additional time and has extra overhead associated with it.<br />
* Moving to a different compiler version might lead to shorter and/or faster code. Most often newer compilers produce better code. You might also want to play with compiler options to see what works best.<br />
* If possible move from glibc to uClibc. This leads to smaller executables and hence to faster load times.<br />
* library optimiser tool: http://libraryopt.sourceforge.net/ <br/> This will allow you to create an optimised library. As unneeded functions are removed this should lead to a performance gain. Normally there will be library pages which contain unused code (adjacent to code that is used). After optimizing the library this does not occur any more, so less pages are needed and hence less page loads, so some time can be saved.<br />
* Function reordering: http://www.celinux.org/elc08_presentations/DDLink%20FunctionReorder%2008%2004.pdf <br/> This is a technique to rearrange the functions within an executable so they appear in the order they are needed. This improves the load time of the application as all initialization code is grouped into a set of pages, instead of being scattered over a number of pages.<br />
<br />
==== Suspend related improvements ====<br />
Another approach to improve boot time is to use a suspend related mechanism. Two approaches are known.<br />
* Using the standard hibernate/resume approach. This is what has been demonstrated by Chan Ju, Park, from Samsung. See sheet 23 and onwards from this [[Media:LinuxBootupTimeReduction4DSC.ppt|PPT]] and section 2.7 of this [http://www.kernel.org/doc/ols/2006/ols2006v2-pages-239-248.pdf paper]. <br /> Issue with this approach is that flash write is much slower than flash read, so the actual creation of the hibernate image might take quite a while.<br />
* Implementing snapshot boot. This is done by Hiroki Kaminaga from Sony and is described at [[Suspend To Disk For ARM|snapshot boot for ARM]] and http://elinux.org/upload/3/37/Snapshot-boot-final.pdf<br />This is similar to hibernate and resume, but the hibernate file is retained and used upon every boot. Disadvantage is that no writable partitions should be mounted at the time of making the snapshot. Otherwise inconsistencies will occur if a partition is modified, while applications in the hibernate file might have information in the snapshot related to the unmodified partition.<br />
<br />
==== Miscellaneous topics ====<br />
<br />
[[About Compression]] discusses the effects of compression on boot time. This can affect both the kernel boot time as well as user-space startup.<br />
<br />
==== Uninvestigated speedups ====<br />
<br />
This section is a holding pen for ideas for improvement that are not implemented yet but that could result in a boot time gain. Please leave a note here if you are working on one of these items to avoid duplicate work.<br />
<br />
* '''Prepopulated buffer cache''' - As initramfs performs an additional copy of the data the idea is to have a prepopulated buffer cache. A simplistic scenario would allow dumping the buffer cache when the booting is completed and the user applications have initialised. This data then could be used in a subsequent boot to initialize the buffer cache (of course without copying). A possible approach would be to have those data to reside into the kernel image and use them directly. Alternately they could be loaded separately. <br /> Unfortunately my knowledge of the internals in this section is not yet good enough to do a trial implementation.<br /> Caveats:<br />
** is it possible to have the buffer cache split into two different parts, one which is statically allocated, one which is dynamically allocated?<br />
** the pages in the prepopulated buffer cache probably cannot be discarded, so they should be pinned<br />
** apart from the buffer cache data itself also some other variables might need restoring<br />
** a similar approach could also be used for the cached file data.<br />
*'''Dedicated fs''' - currently a lot of abstraction is done in fs to make a nice abstraction allowing easy addition of new filesystems and creating a unified view of those filesystem. While this is pretty neat, the abstraction layers also introduce some overhead. A solution could be to create a dedicated fs system, which supports only one (or maybe 2) filesystems, and eliminates the abstraction overhead. This will give some benefit, but the chance of getting this into the mainline is zero.<br />
<br />
== Articles and Presentations ==<br />
* "The Right Approach to Boot Time Reduction" - ([http://elinux.org/images/f/f7/RightApproachMinimalBootTimes.pdf Slides] | [http://www.youtube.com/watch?v=ULa4TPy7z0c YouTube Video])<br />
** Andrew Murray has presented at ELC Europe on October 28, 2010<br />
** This included a < 1 second QT cold Linux boot case study for an SH7724 with some additional information about 'function re-ordering' in user-space<br />
** Similar slides with < 1 second case study for OMAP3530EVM can be found [http://www.slideshare.net/andrewmurraympc/t-iswift-boot here]<br />
* "One Second Linux Boot Demonstration (new version)" ([http://www.youtube.com/watch?v=-l_DSZe8_F8 Youtube video by MontaVista])<br />
* "Tools and Techniques for Reducing Bootup Time" ([[Media:Tools-and-technique-for-reducing-bootup-time.ppt|PPT]] | [[Media:Tools-and-technique-for-reducing-bootup-time.odp|ODP]] | [[Media:Tools-and-technique-for-reducing-bootup-time.pdf|PDF]] | [http://free-electrons.com/pub/video/2008/elce/elce2008-bird-reducing-bootup-time.ogv video])<br />
** Tim Bird has presented at ELC Europe, on November 7, 2008, his latest collection of tips and tricks for reducing bootup time<br />
** [[Tims Fastboot Tools]] has online materials in support of this presentation<br />
* [http://www.mvista.com/download/author.php?a=37 Christopher Hallinan] has done a presentation at the MontaVista Vision conference 2008 on the topic of reducing boot time. Slides available [http://www.mvista.com/download/power/Reducing-boot-time-techniques-for-fast-booting.pdf here]<br />
* [http://lwn.net/Articles/192082/ Optimizing Linker Load Times]<br />
** (introducing various kinds of bootuptime reduction, prelinking, etc.)<br />
* [http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Benchmarking-boot-latency-on-x86/ Benchmarking boot latency on x86]<br />
** By Gilad Ben-Yossef, July 2008<br />
** A tutorial on using TSC register and the kernel PRINTK_TIMES feature to measure x86 system boot time, including BIOS, bootloader, kernel and time to first user program.<br />
* [http://tree.celinuxforum.org/CelfPubWiki/KoreaTechJamboree3?action=AttachFile&do=get&target=The_Fast_Booting_of_Embedded_Linux.pdf Fast Booting of Embedded Linux]<br />
** By HoJoon Park, Electrons and Telecommunications Research Institute (ETRI), Korea, Presented at the CELF [http://tree.celinuxforum.org/CelfPubWiki/KoreaTechJamboree3 3rd Korean Technical Jamboree], July 2008<br />
** Explains several different reduction techniques used for different phases of bootup time<br />
*Tim Bird's (Sony) survey of boot-up time reduction techniques:<br />
**[http://kernel.org/doc/ols/2004/ols2004v1-pages-79-88.pdf Methods to Improve Boot-up Time in Linux] - Paper prepared for 2004 Ottawa Linux Symposium<br />
**{{pdf|ReducingStartupTime v0.8.pdf|Reducing Startup Time in Embedded Linux Systems}} - December 2003 Presentation describing some existing boot-up time reduction techniques and strategies.<br />
* [http://free-electrons.com/articles/optimizations Embedded Linux optimizations]<br />
** By Free Electrons<br />
** Tutorial to reduce size, RAM, speed, power and cost of a Linux based embedded system]<br />
*Parallelizing Linux Boot on CE Devices<br />
** [http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2007Presentations?action=AttachFile&do=view&target=par.pdf PDF of Presentation]<br />
**[http://free-electrons.com/pub/video/2007/elce/elce-2007-vitaly-wool-parallel-boot.ogg Video of Presentation]<br />
*[http://www.ibm.com/developerworks/linux/library/l-boot-faster/ Parallelize Applications for Faster Linux Boot]<br />
**Authored by M. Tim Jones for IBM Developer Works<br />
**This article shows you options to increase the speed with which Linux boots, including two options for parallelizing the initialization process. It also shows you how to visualize graphically the performance of the boot process.<br />
<br />
=== Case Studies ===<br />
* [http://www.makelinux.com/emb/fastboot/ 560 milliseconds from reset to shell on 300 MHz ARM DM365] <br />
* Samsung proof-of-acceptability study for digital still camera: see [[Media:LinuxBootupTimeReduction4DSC.ppt|Boot Up Time Reduction PPT]] and the [http://www.kernel.org/doc/ols/2006/ols2006v2-pages-239-248.pdf paper] describing this.<br />
* [https://docs.blackfin.uclinux.org/doku.php?id=fast_boot_example Boot Linux from Processor Reset into user space in less than 1 Second]<br />
** In this white paper, Robin Getz describes the techniques used to fast-boot a blackfin development board.<br />
* [http://e2e.ti.com/support/embedded/f/354/t/51158.aspx Booting Linux dm365 Network Camera in 3.2 seconds]<br />
* [http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/p/7616/30088.aspx Boot of kernel and shell in 0.5 sec (not including u-boot and decompression)]<br />
<br />
* [http://www.linuxfordevices.com/c/a/News/Linux-boots-in-297-seconds/ Warp2, Lineo Solutions, 2008. Rechnology to boot Linux in 2.97 seconds on a low-end system.]<br />
<br />
== Additional Projects/Mailing Lists/Resources ==<br />
=== Replacements for SysV 'init' ===<br />
The traditional method of starting a Linux system is to use /sbin/init, which<br />
processes the file /etc/inittab. This is an init program which processes a series of actions for different <br />
run-levels and system events (key-combinations and power events).<br />
<br />
See [http://linux.die.net/man/8/init the init(8) man page] and the [http://linux.die.net/man/5/inittab the inittab(5) man page].<br />
<br />
==== busybox init ====<br />
An 'init' applet is often included in [[BusyBox]]<br />
<br />
There used to be (as of 2000) some slight differences in the supported features of the 'inittab' file<br />
between busybox init and full-blown init. However, I don't know (as of 2010) if that's still the case.<br />
(See http://spblinux.de/2.0/doc/init.html for some details)<br />
<br />
Denys Vlasenko, one of the maintainers of busybox has suggested a replacement for traditional init<br />
for that tool called runsv. See http://busybox.net/~vda/init_vs_runsv.html<br />
<br />
==== upstart ====<br />
upstart is the name of a newer Linux desktop systems that provides the program /sbin/init,<br />
but with different operational semantics.<br />
<br />
* Home page: http://upstart.ubuntu.com/<br />
* Wikipedia page: http://en.wikipedia.org/wiki/Upstart<br />
<br />
==== Android init ====<br />
Android 'init' is a custom program for booting the Android system.<br />
<br />
See [[Android_Booting#.27init.27|Android 'init']]<br />
<br />
==== systemd ====<br />
systemd is a new project (as of May 2010) for starting daemons and services on a Linux desktop system<br />
<br />
See http://0pointer.de/blog/projects/systemd.html<br />
<br />
=== Kexec ===<br />
*Kexec is a system which allows a system to be '''rebooted''' without going through BIOS. That is, a Linux kernel can directly boot into another Linux kernel, without going through firmware. See the white paper at: [http://developer.osdl.org/andyp/kexec/whitepaper/kexec.pdf kexec.pdf]<br />
**2004 Kernel Summit presentation: [http://www.xenotime.net/linux/fastboot/fastboot-ks-2004.pdf fastboot.pdf]<br />
**here's another Kexec white paper:[http://www-106.ibm.com/developerworks/linux/library/l-kexec.html?ca=dgr-lnxw04 Reboot Fast]<br />
<br />
=== Splash Screen projects ===<br />
* [http://splashy.alioth.debian.org/wiki/ Splashy] - Technology to put up a spalsh screen early in the boot sequence. This is user-space code.<br />
** This seems to be the most current splash screen technology, for major distributions. A framebuffer driver for the kernel is required.<br />
* [http://dev.gentoo.org/~spock/projects/gensplash/ Gentoo Splashscreen] - newer technology to put a splash screen early in the boot sequence<br />
** See the HOWTO at: [http://gentoo-wiki.com/HOWTO_fbsplash HOWTO FBSplash]<br />
* [http://butterfeet.org/?p=8 PSplash] - PSplash is a userspace graphical boot splash screen for mainly embedded Linux devices supporting a 16bpp or 32bpp framebuffer.<br />
* [http://www.bootsplash.org/ bootsplash.org] - put up a splash screen early in boot sequence<br />
** This project requires kernel patches<br />
** This project is now abandoned, and work is being done on Splashy.<br />
<br />
=== Others ===<br />
<br />
*[http://www.linuxdevices.com/news/NS5907201615.html FSMLabs Fastboot] - press release by FSMLabs about fast booting of their product. Is any of this published?<br />
<br />
*[http://tree.celinuxforum.org/CelfPubWiki/ snapshot boot] - a technology uses software resume to boot up the system quickly.<br />
<br />
==== Apparently obsolete or abandoned material ====<br />
* [[Image:alert.gif]] ''in progress'' - [[Boot-up Time Reduction Howto]] - this is a project to catalog existing boot-up time reduction techniques.<br />
** Was originally intended to be the authoritative source for bootup time reduction information.<br />
** No one maintains it any more (as of Aug, 2008)<br />
*[[Image:alert.gif]]''no content yet'' - [[Boot-up Time Delay Taxonomy]] - list of delays categorized by boot phase, type and magnitude<br />
** Was to be a survey of common bootup delays found in embedded devices.<br />
** Was never really written.<br />
<br />
???<br />
* [[Bootup Time Spec]]<br />
* [[Bootup Time Things To Investigate]]<br />
* [[Bootup Time Working Group]]<br />
* [[Bootup Time Task List]]<br />
* [[Bootup Time Howto Task List]]<br />
* [[Fast Booting Translation]]<br />
<br />
== Companies, individuals or projects working on fast booting ==<br />
* Intel - Arjan van de Ven - see http://lwn.net/Articles/299483/<br />
* Tripeaks - see http://www.linuxdevices.com/news/NS8282586707.html<br />
* Lineo Solutions - see http://www.linuxdevices.com/news/NS5185504436.html<br />
* Monta Vista - see http://www.linuxdevices.com/news/NS2560585344.html<br />
* fastboot git tree - see http://lwn.net/Articles/299591/<br />
<br />
== Boot time check list ==<br />
<br />
From an [http://www.mail-archive.com/linux-embedded@vger.kernel.org/msg02139.html August 2009 discussion about boot time on ARM devices], several hints and advice regarding boot time optimization are available. While it may repeat a lot of above, below is a check list extracted from this discussion:<br />
<br />
* Is CPU's clock switched to maximum? If the kernel, bootloader or hardware is in charge of setting CPU power and speed scaling, then you should check that it boots with the CPU set at maximum speed instead of slowest. <br />
<br />
* Is your hardware (register) timing configuration of your SoC's memory interfaces (e.g. RAM and NOR/NAND timing) optimized? A lot of vendors ship their hardware with "well, it works, optimize later" settings. What you want is "as fast as possible, but sill stable and reliable" configuration. This might need some hardware knowledge and has to be customized to the individual memory devices used.<br />
<br />
* Does your boot loader uses I- and D-Cache? E.g. U-Boot doesn't enable D-Cache by default on ARM devices, as it needs customized MMU tables to do so.<br />
<br />
* Does kernel copy from permanent storage (e.g. NOR or NAND) to RAM use optimized functions? E.g. DMA, or on ARM at least load/store multiple commands (ldm/stm)?<br />
<br />
* If you use U-Boot's uImage, set "verify=no" in U-Boot to avoid checksum verification.<br />
<br />
* Optimize size of your kernel.<br />
** You might even try some of the embedded system kernel config options that, for example, eliminate all the printk strings, reduce data structures, or eliminate unneeded functionality.<br />
<br />
* How often is kernel (image) data copied? First by boot loader from storage to RAM, then by kernel's uncompressor to it's final destination? Once more? If you use compressed kernel and NOR flash, consider running the uncompressor XIP in NOR flash.<br />
<br />
* If you use compressed kernel, check compression algorithm. zlib is slow on decompression, and lzo is much faster. So if you implement lzo compression, you'll probably speed things up a little as well (check LKML for this). Having no compression at all may also be a good thing to try (see next topic).<br />
<br />
* Check to use uncompressed kernel (depends on your system configuration). Using an uncompressed kernel on a flash-based system may improve boot time. The reason is that compressed kernels are faster only when the throughput to the persistent storage is lower than the decompression throughput, and on typical embedded systems with DMA the throughput to memory outperforms the CPU-based decompression. Of course it depends on a lot of stuff like performance of flash controller, kernel storage filesystem performance, DMA controller performance, cache architecture etc. So it's individual per-system. Example: With using an uncomressed kernel (~2.8MB) uncompressing (running the uncompressor XIP in NOR flash) took ~0.5s longer than copying 2.8MB from flash to RAM.<br />
<br />
* Enable precalculated loops-per-jiffy<br />
<br />
* Enable kernel quiet option<br />
<br />
* If you use UBI: UBI is rather slow in attaching MTD devices. Everything is explained at MTD's [http://www.linux-mtd.infradead.org/doc/ubi.html#L_scalability UBI scalability] and [http://www.linux-mtd.infradead.org/doc/ubifs.html#L_scalability UBI fs scalability] sections. There is not very much you can do to speed it up but implement UBI2. UBIFS would stay intact. There were discussions about this and it does not seem to be impossibly difficult to do UBI2 ([http://www.linux-mtd.infradead.org/faq/ubi.html#L_attach_faster few ideas]).<br />
** In a follow-up e-mail, Sascha Hauer wrote:<br />
<pre> What's interesting about this is that the kernel NAND driver is much slower<br />
than the one in U-Boot. Looking at it it turned out that the kernel<br />
driver uses interrupts to wait for the controller to get ready.<br />
Switching this to polling nearly doubles the NAND performance. UBI<br />
mounts much faster now and this cuts off another few seconds from the<br />
boot process :) <br />
</pre><br />
<br />
* Use static device nodes during boot, and later setup busybox mdev for hotplug.<br />
<br />
* If you have network enabled, there might be some very long timeouts in the network code paths, which appear to be used whether you specify a static address or not. See the definitions of CONF_PRE_OPEN and CON_POST_OPEN in ''net/ipv4/ipconfig.c''. Check [http://patchwork.kernel.org/patch/31678/ ipdelay configuration patch].<br />
<br />
* Parallelize boot process.<br />
<br />
* Disable the option "Set system time from RTC on startup and resume", you can use the command hwclock -s at the of the init instead of slowing down the kernel.<br />
<br />
[[Category:Boot Time]]<br />
[[Category:Bootloader]]</div>Consthttp://elinux.org/Boot_TimeBoot Time2011-01-07T16:37:50Z<p>Const: /* Case Studies */ + 560 milliseconds from reset to shell on 300 MHz ARM DM365</p>
<hr />
<div>== Introduction ==<br />
Boot Time includes topics such as measurement, analysis, human factors, initialization techniques, and reduction techniques.<br />
The time that a product takes to boot directly impacts the first perception an end user has of the product.<br />
Regardless of how attractive or well designed a consumer electronic device is, the time required to move the device from off to an interactive, usable state is critical to obtaining a positive end user experience. Turning on a device is Use Case #1.<br />
<br />
Booting up a device involves numerous steps and sequences of events. In order to use consistent terminology, the<br />
[[Bootup Time Working Group]] of the CE Linux Forum came up with a list of terms and their widely accepted definitions<br />
for this functionality area. See the following page for these terms:<br />
* [[Boot-up Time Definition Of Terms]]<br />
<br />
== Technology/Project Pages ==<br />
The following are individual pages with information about various technologies relevant to improving Boot Time for Linux. Some of these describe local patches available on this site. Others point to projects or patches maintained elsewhere.<br />
<br />
=== Measuring Boot-up Time ===<br />
*[[Printk Times]] - simple system for showing timing information for each printk.<br />
*[[Kernel Function Trace]] - system for reporting function timings in the kernel.<br />
*[[Linux Trace Toolkit]] - system for reporting timing data for certain kernel and process events.<br />
*[http://oprofile.sourceforge.net/news/ Oprofile] - system-wide profiler for Linux.<br />
*[[Bootchart]] - a tool for performance analysis and visualization of the Linux boot process. Resource utilization and process information are collected during the user-space portion of the boot process and are later rendered in a PNG, SVG or EPS encoded chart.<br />
*[http://people.redhat.com/berrange/systemtap/bootprobe/ Bootprobe] - a set of [[System Tap]] scripts for analyzing system bootup.<br />
* and, let us not forget: "cat /proc/uptime"<br />
* [[Tims Fastboot Tools#grabserial | grabserial]] - a nice utility from Tim Bird to log and timestamp console output<br />
* [[Tims Fastboot Tools#Tim's quick and dirty process trace|process trace]] - a simple patch from Tim Bird to log exec, fork and exit system calls.<br />
* [http://pengutronix.de/software/ptx_ts/index_en.html ptx_ts] - Pengutronix' TimeStamper: A small filter prepending timestamps to STDOUT; a bit similar to grabserial but not limited to serial ports<br />
* [[Initcall Debug]] - a kernel command line option to show time taken for initcalls.<br />
* See also: [[Kernel Instrumentation]] which lists some known kernel instrumentation tools. These are of interest for measuring kernel startup time.<br />
<br />
=== Technologies and Techniques for Reducing Boot Time ===<br />
==== Bootloader speedups ====<br />
*[[Kernel XIP]] - Allow kernel to be executed in-place in ROM or FLASH.<br />
*[[DMA Copy Of Kernel On Startup]] - Copy kernel from Flash to RAM using DMA<br />
*[[Uncompressed kernel]] - An uncompressed kernel might boot faster<br />
*[[Fast Kernel Decompression]]<br />
<br />
==== Kernel speedups ====<br />
*[[Disable Console]] - Avoid overhead of console output during system startup.<br />
*Disable bug and printk - Avoid the overhead of bug and printk. Disadvantage is that you loose a lot of info.<br />
*[[RTC No Sync]] - Avoid delay to synchronize system time with RTC clock edge on startup.<br />
*[[Short IDE Delays]] - Reduce duration of IDE startup delays (this is effective but possibly dangerous).<br />
*[[Hardcode kernel module info]] - Reduce the overhead of loading a module, by hardcoding some information used for loading the relocation information<br />
*[[IDE No Probe]] - Force kernel to observe the ide<x>=noprobe option.<br />
*[[Preset LPJ]] - Allow the use of a preset loops_per_jiffy value.<br />
*[[Asynchronous function calls]] - Allow probing or other functions to proceed in parallel, to overlap time-consuming boot-up activities.<br />
**[[Threaded Device Probing]] - Allow drivers to probe devices in parallel. (not mainlined, now deprecated?)<br />
*[[Reordering of driver initialization]] - Allow driver bus probing to start as soon as possible.<br />
*[[Deferred Initcalls]] - defer non-essential module initialization routines to after primary boot<br />
*NAND ECC improvement - The pre 2.6.28 nand_ecc.c has room for improvement. You can find an improved version in the mtd git at http://git.infradead.org/mtd-2.6.git?a=blob_plain;f=drivers/mtd/nand/nand_ecc.c;hb=HEAD. Documentation for this is in http://git.infradead.org/mtd-2.6.git?a=blob_plain;f=Documentation/mtd/nand_ecc.txt;hb=HEAD. This is only interesting if your system uses software ECC correction.<br />
*Check what kernel memory allocator you use. Slob or slub might be better than slab (which is the default in older kernels) <br />
*If your system does not need it, you can remove SYSFS and even PROCFS from the kernel. In one test removing sysfs saved 20 ms.<br />
*Carefully investigate all kernel configuration options on whether they are applicable or not. Even if you select an option that is not used in the end, it contributes to the kernel size and therefore to the kernel load time (assuming you are not doing kernel XIP). Often this will require some trial and measure! E.g. selecting CONFIG_CC_OPTIMIZE_FOR_SIZE (found under general setup) gave in one case a boot improvement of 20 ms. Not dramamtic, but when reducing boot time every penny counts!<br />
*Moving to a different compiler version might lead to shorter and/or faster code. Most often newer compilers produce better code. You might also want to play with compiler options to see what works best.<br />
* If you use initramfs in your kernel and a compressed kernel it is better to have an uncompressed initramfs image. This is to avoid having to uncompress data twice. A patch for this has been submitted to LKML. See http://lkml.org/lkml/2008/11/22/112 <br />
<br />
===== File System issues =====<br />
Different file systems have different initialization (mounting) times, for the same data sets. This<br />
is a function of whether meta-data must be read from storage into RAM or not, and what algorithms are<br />
used during the mount procedure.<br />
<br />
* [[Filesystem Information]] - has information about boot-up times of various file systems<br />
* [[File Systems]] - has information on various file systems that are interesting for embedded systems. Also includes some improvement suggestions.<br />
* [[Avoid Initramfs]] - explains on why intramfs should be avoided if you want to minimize boot time<br />
* Split partitions. If mounting a file system takes long, you can consider splitting that filesystem in two parts, one with the info that is needed during or immediately after boot, and one which can be mounted later on.<br />
* [[Ramdisks demasked]] - explains why using a ram disk generally results in a longer boot time, not a shorter one.<br />
<br />
==== User-space and application speedups ====<br />
* [[Optimize RC Scripts]] - Reduce overhead of running RC scripts<br />
* [[Parallel RC Scripts]] - Run RC scripts in parallel instead of sequentially<br />
* [[Application XIP]] - Allow programs and libraries to be executed in-place in ROM or FLASH<br />
* [[Pre Linking]] - Avoid cost of runtime linking on first program load<br />
* Statically link applications. This avoids the costs of runtime linking. Useful if you have only a few applications. In that case it could also reduce the size of your image as no dynamic libraries are needed<br />
* GNU_HASH: ~ 50% speed improvement in dynamic linking<br />
** See http://sourceware.org/ml/binutils/2006-06/msg00418.html<br />
* [[Application Init Optimizations]] - Improvements in program load and init time via: <br />
** use of mmap vs. read<br />
** control over page mapping characteristics.<br />
* [[Include modules in kernel image]] - Avoid extra overhead of module loading by adding the modules to the kernel image<br />
* Avoid udev, it takes quite some time to populate the /dev directory. In an embedded system it is often known what devices are present and in any case you know what drivers are available, so you know what device entries might be needed in /dev. These should be created statically, not dynamically. mknod is your friend, udev is your enemy.<br />
* If you still like udev and also like fast boot-up's, you might go this way: start your system with udev enabled and make kind of a backup of the created device nodes. Now, modify your init script like this: instead running udev, copy the device nodes that you just made a backup of into the device tree. Now, install the hotplug-daemon like you always do. That trick avoids the device node creation at startup but stills lets your system create device nodes later on. <br />
* If your device has a network connection, preferably use static IP addresses. Getting an address from a DHCP server takes additional time and has extra overhead associated with it.<br />
* Moving to a different compiler version might lead to shorter and/or faster code. Most often newer compilers produce better code. You might also want to play with compiler options to see what works best.<br />
* If possible move from glibc to uClibc. This leads to smaller executables and hence to faster load times.<br />
* library optimiser tool: http://libraryopt.sourceforge.net/ <br/> This will allow you to create an optimised library. As unneeded functions are removed this should lead to a performance gain. Normally there will be library pages which contain unused code (adjacent to code that is used). After optimizing the library this does not occur any more, so less pages are needed and hence less page loads, so some time can be saved.<br />
* Function reordering: http://www.celinux.org/elc08_presentations/DDLink%20FunctionReorder%2008%2004.pdf <br/> This is a technique to rearrange the functions within an executable so they appear in the order they are needed. This improves the load time of the application as all initialization code is grouped into a set of pages, instead of being scattered over a number of pages.<br />
<br />
==== Suspend related improvements ====<br />
Another approach to improve boot time is to use a suspend related mechanism. Two approaches are known.<br />
* Using the standard hibernate/resume approach. This is what has been demonstrated by Chan Ju, Park, from Samsung. See sheet 23 and onwards from this [[Media:LinuxBootupTimeReduction4DSC.ppt|PPT]] and section 2.7 of this [http://www.kernel.org/doc/ols/2006/ols2006v2-pages-239-248.pdf paper]. <br /> Issue with this approach is that flash write is much slower than flash read, so the actual creation of the hibernate image might take quite a while.<br />
* Implementing snapshot boot. This is done by Hiroki Kaminaga from Sony and is described at [[Suspend To Disk For ARM|snapshot boot for ARM]] and http://elinux.org/upload/3/37/Snapshot-boot-final.pdf<br />This is similar to hibernate and resume, but the hibernate file is retained and used upon every boot. Disadvantage is that no writable partitions should be mounted at the time of making the snapshot. Otherwise inconsistencies will occur if a partition is modified, while applications in the hibernate file might have information in the snapshot related to the unmodified partition.<br />
<br />
==== Miscellaneous topics ====<br />
<br />
[[About Compression]] discusses the effects of compression on boot time. This can affect both the kernel boot time as well as user-space startup.<br />
<br />
==== Uninvestigated speedups ====<br />
<br />
This section is a holding pen for ideas for improvement that are not implemented yet but that could result in a boot time gain. Please leave a note here if you are working on one of these items to avoid duplicate work.<br />
<br />
* '''Prepopulated buffer cache''' - As initramfs performs an additional copy of the data the idea is to have a prepopulated buffer cache. A simplistic scenario would allow dumping the buffer cache when the booting is completed and the user applications have initialised. This data then could be used in a subsequent boot to initialize the buffer cache (of course without copying). A possible approach would be to have those data to reside into the kernel image and use them directly. Alternately they could be loaded separately. <br /> Unfortunately my knowledge of the internals in this section is not yet good enough to do a trial implementation.<br /> Caveats:<br />
** is it possible to have the buffer cache split into two different parts, one which is statically allocated, one which is dynamically allocated?<br />
** the pages in the prepopulated buffer cache probably cannot be discarded, so they should be pinned<br />
** apart from the buffer cache data itself also some other variables might need restoring<br />
** a similar approach could also be used for the cached file data.<br />
*'''Dedicated fs''' - currently a lot of abstraction is done in fs to make a nice abstraction allowing easy addition of new filesystems and creating a unified view of those filesystem. While this is pretty neat, the abstraction layers also introduce some overhead. A solution could be to create a dedicated fs system, which supports only one (or maybe 2) filesystems, and eliminates the abstraction overhead. This will give some benefit, but the chance of getting this into the mainline is zero.<br />
<br />
== Articles and Presentations ==<br />
* "The Right Approach to Boot Time Reduction" - ([http://elinux.org/images/f/f7/RightApproachMinimalBootTimes.pdf Slides] | [http://www.youtube.com/watch?v=ULa4TPy7z0c YouTube Video])<br />
** Andrew Murray has presented at ELC Europe on October 28, 2010<br />
** This included a < 1 second QT cold Linux boot case study for an SH7724 with some additional information about 'function re-ordering' in user-space<br />
** Similar slides with < 1 second case study for OMAP3530EVM can be found [http://www.slideshare.net/andrewmurraympc/t-iswift-boot here]<br />
* "One Second Linux Boot Demonstration (new version)" ([http://www.youtube.com/watch?v=-l_DSZe8_F8 Youtube video by MontaVista])<br />
* "Tools and Techniques for Reducing Bootup Time" ([[Media:Tools-and-technique-for-reducing-bootup-time.ppt|PPT]] | [[Media:Tools-and-technique-for-reducing-bootup-time.odp|ODP]] | [[Media:Tools-and-technique-for-reducing-bootup-time.pdf|PDF]] | [http://free-electrons.com/pub/video/2008/elce/elce2008-bird-reducing-bootup-time.ogv video])<br />
** Tim Bird has presented at ELC Europe, on November 7, 2008, his latest collection of tips and tricks for reducing bootup time<br />
** [[Tims Fastboot Tools]] has online materials in support of this presentation<br />
* [http://www.mvista.com/download/author.php?a=37 Christopher Hallinan] has done a presentation at the MontaVista Vision conference 2008 on the topic of reducing boot time. Slides available [http://www.mvista.com/download/power/Reducing-boot-time-techniques-for-fast-booting.pdf here]<br />
* [http://lwn.net/Articles/192082/ Optimizing Linker Load Times]<br />
** (introducing various kinds of bootuptime reduction, prelinking, etc.)<br />
* [http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Benchmarking-boot-latency-on-x86/ Benchmarking boot latency on x86]<br />
** By Gilad Ben-Yossef, July 2008<br />
** A tutorial on using TSC register and the kernel PRINTK_TIMES feature to measure x86 system boot time, including BIOS, bootloader, kernel and time to first user program.<br />
* [http://tree.celinuxforum.org/CelfPubWiki/KoreaTechJamboree3?action=AttachFile&do=get&target=The_Fast_Booting_of_Embedded_Linux.pdf Fast Booting of Embedded Linux]<br />
** By HoJoon Park, Electrons and Telecommunications Research Institute (ETRI), Korea, Presented at the CELF [http://tree.celinuxforum.org/CelfPubWiki/KoreaTechJamboree3 3rd Korean Technical Jamboree], July 2008<br />
** Explains several different reduction techniques used for different phases of bootup time<br />
*Tim Bird's (Sony) survey of boot-up time reduction techniques:<br />
**[http://kernel.org/doc/ols/2004/ols2004v1-pages-79-88.pdf Methods to Improve Boot-up Time in Linux] - Paper prepared for 2004 Ottawa Linux Symposium<br />
**{{pdf|ReducingStartupTime v0.8.pdf|Reducing Startup Time in Embedded Linux Systems}} - December 2003 Presentation describing some existing boot-up time reduction techniques and strategies.<br />
* [http://free-electrons.com/articles/optimizations Embedded Linux optimizations]<br />
** By Free Electrons<br />
** Tutorial to reduce size, RAM, speed, power and cost of a Linux based embedded system]<br />
*Parallelizing Linux Boot on CE Devices<br />
** [http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2007Presentations?action=AttachFile&do=view&target=par.pdf PDF of Presentation]<br />
**[http://free-electrons.com/pub/video/2007/elce/elce-2007-vitaly-wool-parallel-boot.ogg Video of Presentation]<br />
*[http://www.ibm.com/developerworks/linux/library/l-boot-faster/ Parallelize Applications for Faster Linux Boot]<br />
**Authored by M. Tim Jones for IBM Developer Works<br />
**This article shows you options to increase the speed with which Linux boots, including two options for parallelizing the initialization process. It also shows you how to visualize graphically the performance of the boot process.<br />
<br />
=== Case Studies ===<br />
* [http://www.makelinux.com/emb/fastboot/ 560 milliseconds from reset to shell on 300 MHz ARM DM365] <br />
* Samsung proof-of-acceptability study for digital still camera: see [[Media:LinuxBootupTimeReduction4DSC.ppt|Boot Up Time Reduction PPT]] and the [http://www.kernel.org/doc/ols/2006/ols2006v2-pages-239-248.pdf paper] describing this.<br />
* [https://docs.blackfin.uclinux.org/doku.php?id=fast_boot_example Boot Linux from Processor Reset into user space in less than 1 Second]<br />
** In this white paper, Robin Getz describes the techniques used to fast-boot a blackfin development board.<br />
* [http://e2e.ti.com/support/embedded/f/354/t/51158.aspx Booting Linux dm365 Network Camera in 3.2 seconds]<br />
* [http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/p/7616/30088.aspx Boot of kernel and shell in 0.5 sec (not including u-boot and decompression)]<br />
<br />
* Lineo Solutions announced (Nov. 2008) technology to boot Linux in 2.97 seconds on a low-end system. The system is called "Warp2" and appears to be a form of modified resume (similar to "snapshot boot" mentioned above.<br />
** See http://www.linuxfordevices.com/c/a/News/Linux-boots-in-297-seconds/<br />
<br />
== Additional Projects/Mailing Lists/Resources ==<br />
=== Replacements for SysV 'init' ===<br />
The traditional method of starting a Linux system is to use /sbin/init, which<br />
processes the file /etc/inittab. This is an init program which processes a series of actions for different <br />
run-levels and system events (key-combinations and power events).<br />
<br />
See [http://linux.die.net/man/8/init the init(8) man page] and the [http://linux.die.net/man/5/inittab the inittab(5) man page].<br />
<br />
==== busybox init ====<br />
An 'init' applet is often included in [[BusyBox]]<br />
<br />
There used to be (as of 2000) some slight differences in the supported features of the 'inittab' file<br />
between busybox init and full-blown init. However, I don't know (as of 2010) if that's still the case.<br />
(See http://spblinux.de/2.0/doc/init.html for some details)<br />
<br />
Denys Vlasenko, one of the maintainers of busybox has suggested a replacement for traditional init<br />
for that tool called runsv. See http://busybox.net/~vda/init_vs_runsv.html<br />
<br />
==== upstart ====<br />
upstart is the name of a newer Linux desktop systems that provides the program /sbin/init,<br />
but with different operational semantics.<br />
<br />
* Home page: http://upstart.ubuntu.com/<br />
* Wikipedia page: http://en.wikipedia.org/wiki/Upstart<br />
<br />
==== Android init ====<br />
Android 'init' is a custom program for booting the Android system.<br />
<br />
See [[Android_Booting#.27init.27|Android 'init']]<br />
<br />
==== systemd ====<br />
systemd is a new project (as of May 2010) for starting daemons and services on a Linux desktop system<br />
<br />
See http://0pointer.de/blog/projects/systemd.html<br />
<br />
=== Kexec ===<br />
*Kexec is a system which allows a system to be '''rebooted''' without going through BIOS. That is, a Linux kernel can directly boot into another Linux kernel, without going through firmware. See the white paper at: [http://developer.osdl.org/andyp/kexec/whitepaper/kexec.pdf kexec.pdf]<br />
**2004 Kernel Summit presentation: [http://www.xenotime.net/linux/fastboot/fastboot-ks-2004.pdf fastboot.pdf]<br />
**here's another Kexec white paper:[http://www-106.ibm.com/developerworks/linux/library/l-kexec.html?ca=dgr-lnxw04 Reboot Fast]<br />
<br />
=== Splash Screen projects ===<br />
* [http://splashy.alioth.debian.org/wiki/ Splashy] - Technology to put up a spalsh screen early in the boot sequence. This is user-space code.<br />
** This seems to be the most current splash screen technology, for major distributions. A framebuffer driver for the kernel is required.<br />
* [http://dev.gentoo.org/~spock/projects/gensplash/ Gentoo Splashscreen] - newer technology to put a splash screen early in the boot sequence<br />
** See the HOWTO at: [http://gentoo-wiki.com/HOWTO_fbsplash HOWTO FBSplash]<br />
* [http://butterfeet.org/?p=8 PSplash] - PSplash is a userspace graphical boot splash screen for mainly embedded Linux devices supporting a 16bpp or 32bpp framebuffer.<br />
* [http://www.bootsplash.org/ bootsplash.org] - put up a splash screen early in boot sequence<br />
** This project requires kernel patches<br />
** This project is now abandoned, and work is being done on Splashy.<br />
<br />
=== Others ===<br />
<br />
*[http://www.linuxdevices.com/news/NS5907201615.html FSMLabs Fastboot] - press release by FSMLabs about fast booting of their product. Is any of this published?<br />
<br />
*[http://tree.celinuxforum.org/CelfPubWiki/ snapshot boot] - a technology uses software resume to boot up the system quickly.<br />
<br />
==== Apparently obsolete or abandoned material ====<br />
* [[Image:alert.gif]] ''in progress'' - [[Boot-up Time Reduction Howto]] - this is a project to catalog existing boot-up time reduction techniques.<br />
** Was originally intended to be the authoritative source for bootup time reduction information.<br />
** No one maintains it any more (as of Aug, 2008)<br />
*[[Image:alert.gif]]''no content yet'' - [[Boot-up Time Delay Taxonomy]] - list of delays categorized by boot phase, type and magnitude<br />
** Was to be a survey of common bootup delays found in embedded devices.<br />
** Was never really written.<br />
<br />
???<br />
* [[Bootup Time Spec]]<br />
* [[Bootup Time Things To Investigate]]<br />
* [[Bootup Time Working Group]]<br />
* [[Bootup Time Task List]]<br />
* [[Bootup Time Howto Task List]]<br />
* [[Fast Booting Translation]]<br />
<br />
== Companies, individuals or projects working on fast booting ==<br />
* Intel - Arjan van de Ven - see http://lwn.net/Articles/299483/<br />
* Tripeaks - see http://www.linuxdevices.com/news/NS8282586707.html<br />
* Lineo Solutions - see http://www.linuxdevices.com/news/NS5185504436.html<br />
* Monta Vista - see http://www.linuxdevices.com/news/NS2560585344.html<br />
* fastboot git tree - see http://lwn.net/Articles/299591/<br />
<br />
== Boot time check list ==<br />
<br />
From an [http://www.mail-archive.com/linux-embedded@vger.kernel.org/msg02139.html August 2009 discussion about boot time on ARM devices], several hints and advice regarding boot time optimization are available. While it may repeat a lot of above, below is a check list extracted from this discussion:<br />
<br />
* Is CPU's clock switched to maximum? If the kernel, bootloader or hardware is in charge of setting CPU power and speed scaling, then you should check that it boots with the CPU set at maximum speed instead of slowest. <br />
<br />
* Is your hardware (register) timing configuration of your SoC's memory interfaces (e.g. RAM and NOR/NAND timing) optimized? A lot of vendors ship their hardware with "well, it works, optimize later" settings. What you want is "as fast as possible, but sill stable and reliable" configuration. This might need some hardware knowledge and has to be customized to the individual memory devices used.<br />
<br />
* Does your boot loader uses I- and D-Cache? E.g. U-Boot doesn't enable D-Cache by default on ARM devices, as it needs customized MMU tables to do so.<br />
<br />
* Does kernel copy from permanent storage (e.g. NOR or NAND) to RAM use optimized functions? E.g. DMA, or on ARM at least load/store multiple commands (ldm/stm)?<br />
<br />
* If you use U-Boot's uImage, set "verify=no" in U-Boot to avoid checksum verification.<br />
<br />
* Optimize size of your kernel.<br />
** You might even try some of the embedded system kernel config options that, for example, eliminate all the printk strings, reduce data structures, or eliminate unneeded functionality.<br />
<br />
* How often is kernel (image) data copied? First by boot loader from storage to RAM, then by kernel's uncompressor to it's final destination? Once more? If you use compressed kernel and NOR flash, consider running the uncompressor XIP in NOR flash.<br />
<br />
* If you use compressed kernel, check compression algorithm. zlib is slow on decompression, and lzo is much faster. So if you implement lzo compression, you'll probably speed things up a little as well (check LKML for this). Having no compression at all may also be a good thing to try (see next topic).<br />
<br />
* Check to use uncompressed kernel (depends on your system configuration). Using an uncompressed kernel on a flash-based system may improve boot time. The reason is that compressed kernels are faster only when the throughput to the persistent storage is lower than the decompression throughput, and on typical embedded systems with DMA the throughput to memory outperforms the CPU-based decompression. Of course it depends on a lot of stuff like performance of flash controller, kernel storage filesystem performance, DMA controller performance, cache architecture etc. So it's individual per-system. Example: With using an uncomressed kernel (~2.8MB) uncompressing (running the uncompressor XIP in NOR flash) took ~0.5s longer than copying 2.8MB from flash to RAM.<br />
<br />
* Enable precalculated loops-per-jiffy<br />
<br />
* Enable kernel quiet option<br />
<br />
* If you use UBI: UBI is rather slow in attaching MTD devices. Everything is explained at MTD's [http://www.linux-mtd.infradead.org/doc/ubi.html#L_scalability UBI scalability] and [http://www.linux-mtd.infradead.org/doc/ubifs.html#L_scalability UBI fs scalability] sections. There is not very much you can do to speed it up but implement UBI2. UBIFS would stay intact. There were discussions about this and it does not seem to be impossibly difficult to do UBI2 ([http://www.linux-mtd.infradead.org/faq/ubi.html#L_attach_faster few ideas]).<br />
** In a follow-up e-mail, Sascha Hauer wrote:<br />
<pre> What's interesting about this is that the kernel NAND driver is much slower<br />
than the one in U-Boot. Looking at it it turned out that the kernel<br />
driver uses interrupts to wait for the controller to get ready.<br />
Switching this to polling nearly doubles the NAND performance. UBI<br />
mounts much faster now and this cuts off another few seconds from the<br />
boot process :) <br />
</pre><br />
<br />
* Use static device nodes during boot, and later setup busybox mdev for hotplug.<br />
<br />
* If you have network enabled, there might be some very long timeouts in the network code paths, which appear to be used whether you specify a static address or not. See the definitions of CONF_PRE_OPEN and CON_POST_OPEN in ''net/ipv4/ipconfig.c''. Check [http://patchwork.kernel.org/patch/31678/ ipdelay configuration patch].<br />
<br />
* Parallelize boot process.<br />
<br />
* Disable the option "Set system time from RTC on startup and resume", you can use the command hwclock -s at the of the init instead of slowing down the kernel.<br />
<br />
[[Category:Boot Time]]<br />
[[Category:Bootloader]]</div>Consthttp://elinux.org/Boot_TimeBoot Time2011-01-05T22:44:04Z<p>Const: /* News */</p>
<hr />
<div>== Introduction ==<br />
Boot Time includes topics such as measurement, analysis, human factors, initialization techniques, and reduction techniques.<br />
The time that a product takes to boot directly impacts the first perception an end user has of the product.<br />
Regardless of how attractive or well designed a consumer electronic device is, the time required to move the device from off to an interactive, usable state is critical to obtaining a positive end user experience. Turning on a device is Use Case #1.<br />
<br />
Booting up a device involves numerous steps and sequences of events. In order to use consistent terminology, the<br />
[[Bootup Time Working Group]] of the CE Linux Forum came up with a list of terms and their widely accepted definitions<br />
for this functionality area. See the following page for these terms:<br />
* [[Boot-up Time Definition Of Terms]]<br />
<br />
== Technology/Project Pages ==<br />
The following are individual pages with information about various technologies relevant to improving Boot Time for Linux. Some of these describe local patches available on this site. Others point to projects or patches maintained elsewhere.<br />
<br />
=== Measuring Boot-up Time ===<br />
*[[Printk Times]] - simple system for showing timing information for each printk.<br />
*[[Kernel Function Trace]] - system for reporting function timings in the kernel.<br />
*[[Linux Trace Toolkit]] - system for reporting timing data for certain kernel and process events.<br />
*[http://oprofile.sourceforge.net/news/ Oprofile] - system-wide profiler for Linux.<br />
*[[Bootchart]] - a tool for performance analysis and visualization of the Linux boot process. Resource utilization and process information are collected during the user-space portion of the boot process and are later rendered in a PNG, SVG or EPS encoded chart.<br />
*[http://people.redhat.com/berrange/systemtap/bootprobe/ Bootprobe] - a set of [[System Tap]] scripts for analyzing system bootup.<br />
* and, let us not forget: "cat /proc/uptime"<br />
* [[Tims Fastboot Tools#grabserial | grabserial]] - a nice utility from Tim Bird to log and timestamp console output<br />
* [[Tims Fastboot Tools#Tim's quick and dirty process trace|process trace]] - a simple patch from Tim Bird to log exec, fork and exit system calls.<br />
* [http://pengutronix.de/software/ptx_ts/index_en.html ptx_ts] - Pengutronix' TimeStamper: A small filter prepending timestamps to STDOUT; a bit similar to grabserial but not limited to serial ports<br />
* [[Initcall Debug]] - a kernel command line option to show time taken for initcalls.<br />
* See also: [[Kernel Instrumentation]] which lists some known kernel instrumentation tools. These are of interest for measuring kernel startup time.<br />
<br />
=== Technologies and Techniques for Reducing Boot Time ===<br />
==== Bootloader speedups ====<br />
*[[Kernel XIP]] - Allow kernel to be executed in-place in ROM or FLASH.<br />
*[[DMA Copy Of Kernel On Startup]] - Copy kernel from Flash to RAM using DMA<br />
*[[Uncompressed kernel]] - An uncompressed kernel might boot faster<br />
*[[Fast Kernel Decompression]]<br />
<br />
==== Kernel speedups ====<br />
*[[Disable Console]] - Avoid overhead of console output during system startup.<br />
*Disable bug and printk - Avoid the overhead of bug and printk. Disadvantage is that you loose a lot of info.<br />
*[[RTC No Sync]] - Avoid delay to synchronize system time with RTC clock edge on startup.<br />
*[[Short IDE Delays]] - Reduce duration of IDE startup delays (this is effective but possibly dangerous).<br />
*[[Hardcode kernel module info]] - Reduce the overhead of loading a module, by hardcoding some information used for loading the relocation information<br />
*[[IDE No Probe]] - Force kernel to observe the ide<x>=noprobe option.<br />
*[[Preset LPJ]] - Allow the use of a preset loops_per_jiffy value.<br />
*[[Asynchronous function calls]] - Allow probing or other functions to proceed in parallel, to overlap time-consuming boot-up activities.<br />
**[[Threaded Device Probing]] - Allow drivers to probe devices in parallel. (not mainlined, now deprecated?)<br />
*[[Reordering of driver initialization]] - Allow driver bus probing to start as soon as possible.<br />
*[[Deferred Initcalls]] - defer non-essential module initialization routines to after primary boot<br />
*NAND ECC improvement - The pre 2.6.28 nand_ecc.c has room for improvement. You can find an improved version in the mtd git at http://git.infradead.org/mtd-2.6.git?a=blob_plain;f=drivers/mtd/nand/nand_ecc.c;hb=HEAD. Documentation for this is in http://git.infradead.org/mtd-2.6.git?a=blob_plain;f=Documentation/mtd/nand_ecc.txt;hb=HEAD. This is only interesting if your system uses software ECC correction.<br />
*Check what kernel memory allocator you use. Slob or slub might be better than slab (which is the default in older kernels) <br />
*If your system does not need it, you can remove SYSFS and even PROCFS from the kernel. In one test removing sysfs saved 20 ms.<br />
*Carefully investigate all kernel configuration options on whether they are applicable or not. Even if you select an option that is not used in the end, it contributes to the kernel size and therefore to the kernel load time (assuming you are not doing kernel XIP). Often this will require some trial and measure! E.g. selecting CONFIG_CC_OPTIMIZE_FOR_SIZE (found under general setup) gave in one case a boot improvement of 20 ms. Not dramamtic, but when reducing boot time every penny counts!<br />
*Moving to a different compiler version might lead to shorter and/or faster code. Most often newer compilers produce better code. You might also want to play with compiler options to see what works best.<br />
* If you use initramfs in your kernel and a compressed kernel it is better to have an uncompressed initramfs image. This is to avoid having to uncompress data twice. A patch for this has been submitted to LKML. See http://lkml.org/lkml/2008/11/22/112 <br />
<br />
===== File System issues =====<br />
Different file systems have different initialization (mounting) times, for the same data sets. This<br />
is a function of whether meta-data must be read from storage into RAM or not, and what algorithms are<br />
used during the mount procedure.<br />
<br />
* [[Filesystem Information]] - has information about boot-up times of various file systems<br />
* [[File Systems]] - has information on various file systems that are interesting for embedded systems. Also includes some improvement suggestions.<br />
* [[Avoid Initramfs]] - explains on why intramfs should be avoided if you want to minimize boot time<br />
* Split partitions. If mounting a file system takes long, you can consider splitting that filesystem in two parts, one with the info that is needed during or immediately after boot, and one which can be mounted later on.<br />
* [[Ramdisks demasked]] - explains why using a ram disk generally results in a longer boot time, not a shorter one.<br />
<br />
==== User-space and application speedups ====<br />
* [[Optimize RC Scripts]] - Reduce overhead of running RC scripts<br />
* [[Parallel RC Scripts]] - Run RC scripts in parallel instead of sequentially<br />
* [[Application XIP]] - Allow programs and libraries to be executed in-place in ROM or FLASH<br />
* [[Pre Linking]] - Avoid cost of runtime linking on first program load<br />
* Statically link applications. This avoids the costs of runtime linking. Useful if you have only a few applications. In that case it could also reduce the size of your image as no dynamic libraries are needed<br />
* GNU_HASH: ~ 50% speed improvement in dynamic linking<br />
** See http://sourceware.org/ml/binutils/2006-06/msg00418.html<br />
* [[Application Init Optimizations]] - Improvements in program load and init time via: <br />
** use of mmap vs. read<br />
** control over page mapping characteristics.<br />
* [[Include modules in kernel image]] - Avoid extra overhead of module loading by adding the modules to the kernel image<br />
* Avoid udev, it takes quite some time to populate the /dev directory. In an embedded system it is often known what devices are present and in any case you know what drivers are available, so you know what device entries might be needed in /dev. These should be created statically, not dynamically. mknod is your friend, udev is your enemy.<br />
* If you still like udev and also like fast boot-up's, you might go this way: start your system with udev enabled and make kind of a backup of the created device nodes. Now, modify your init script like this: instead running udev, copy the device nodes that you just made a backup of into the device tree. Now, install the hotplug-daemon like you always do. That trick avoids the device node creation at startup but stills lets your system create device nodes later on. <br />
* If your device has a network connection, preferably use static IP addresses. Getting an address from a DHCP server takes additional time and has extra overhead associated with it.<br />
* Moving to a different compiler version might lead to shorter and/or faster code. Most often newer compilers produce better code. You might also want to play with compiler options to see what works best.<br />
* If possible move from glibc to uClibc. This leads to smaller executables and hence to faster load times.<br />
* library optimiser tool: http://libraryopt.sourceforge.net/ <br/> This will allow you to create an optimised library. As unneeded functions are removed this should lead to a performance gain. Normally there will be library pages which contain unused code (adjacent to code that is used). After optimizing the library this does not occur any more, so less pages are needed and hence less page loads, so some time can be saved.<br />
* Function reordering: http://www.celinux.org/elc08_presentations/DDLink%20FunctionReorder%2008%2004.pdf <br/> This is a technique to rearrange the functions within an executable so they appear in the order they are needed. This improves the load time of the application as all initialization code is grouped into a set of pages, instead of being scattered over a number of pages.<br />
<br />
==== Suspend related improvements ====<br />
Another approach to improve boot time is to use a suspend related mechanism. Two approaches are known.<br />
* Using the standard hibernate/resume approach. This is what has been demonstrated by Chan Ju, Park, from Samsung. See sheet 23 and onwards from this [[Media:LinuxBootupTimeReduction4DSC.ppt|PPT]] and section 2.7 of this [http://www.kernel.org/doc/ols/2006/ols2006v2-pages-239-248.pdf paper]. <br /> Issue with this approach is that flash write is much slower than flash read, so the actual creation of the hibernate image might take quite a while.<br />
* Implementing snapshot boot. This is done by Hiroki Kaminaga from Sony and is described at [[Suspend To Disk For ARM|snapshot boot for ARM]] and http://elinux.org/upload/3/37/Snapshot-boot-final.pdf<br />This is similar to hibernate and resume, but the hibernate file is retained and used upon every boot. Disadvantage is that no writable partitions should be mounted at the time of making the snapshot. Otherwise inconsistencies will occur if a partition is modified, while applications in the hibernate file might have information in the snapshot related to the unmodified partition.<br />
<br />
==== Miscellaneous topics ====<br />
<br />
[[About Compression]] discusses the effects of compression on boot time. This can affect both the kernel boot time as well as user-space startup.<br />
<br />
==== Uninvestigated speedups ====<br />
<br />
This section is a holding pen for ideas for improvement that are not implemented yet but that could result in a boot time gain. Please leave a note here if you are working on one of these items to avoid duplicate work.<br />
<br />
* '''Prepopulated buffer cache''' - As initramfs performs an additional copy of the data the idea is to have a prepopulated buffer cache. A simplistic scenario would allow dumping the buffer cache when the booting is completed and the user applications have initialised. This data then could be used in a subsequent boot to initialize the buffer cache (of course without copying). A possible approach would be to have those data to reside into the kernel image and use them directly. Alternately they could be loaded separately. <br /> Unfortunately my knowledge of the internals in this section is not yet good enough to do a trial implementation.<br /> Caveats:<br />
** is it possible to have the buffer cache split into two different parts, one which is statically allocated, one which is dynamically allocated?<br />
** the pages in the prepopulated buffer cache probably cannot be discarded, so they should be pinned<br />
** apart from the buffer cache data itself also some other variables might need restoring<br />
** a similar approach could also be used for the cached file data.<br />
*'''Dedicated fs''' - currently a lot of abstraction is done in fs to make a nice abstraction allowing easy addition of new filesystems and creating a unified view of those filesystem. While this is pretty neat, the abstraction layers also introduce some overhead. A solution could be to create a dedicated fs system, which supports only one (or maybe 2) filesystems, and eliminates the abstraction overhead. This will give some benefit, but the chance of getting this into the mainline is zero.<br />
<br />
== Articles and Presentations ==<br />
* "The Right Approach to Boot Time Reduction" - ([http://elinux.org/images/f/f7/RightApproachMinimalBootTimes.pdf Slides] | [http://www.youtube.com/watch?v=ULa4TPy7z0c YouTube Video])<br />
** Andrew Murray has presented at ELC Europe on October 28, 2010<br />
** This included a < 1 second QT cold Linux boot case study for an SH7724 with some additional information about 'function re-ordering' in user-space<br />
** Similar slides with < 1 second case study for OMAP3530EVM can be found [http://www.slideshare.net/andrewmurraympc/t-iswift-boot here]<br />
* "One Second Linux Boot Demonstration (new version)" ([http://www.youtube.com/watch?v=-l_DSZe8_F8 Youtube video by MontaVista])<br />
* "Tools and Techniques for Reducing Bootup Time" ([[Media:Tools-and-technique-for-reducing-bootup-time.ppt|PPT]] | [[Media:Tools-and-technique-for-reducing-bootup-time.odp|ODP]] | [[Media:Tools-and-technique-for-reducing-bootup-time.pdf|PDF]] | [http://free-electrons.com/pub/video/2008/elce/elce2008-bird-reducing-bootup-time.ogv video])<br />
** Tim Bird has presented at ELC Europe, on November 7, 2008, his latest collection of tips and tricks for reducing bootup time<br />
** [[Tims Fastboot Tools]] has online materials in support of this presentation<br />
* [http://www.mvista.com/download/author.php?a=37 Christopher Hallinan] has done a presentation at the MontaVista Vision conference 2008 on the topic of reducing boot time. Slides available [http://www.mvista.com/download/power/Reducing-boot-time-techniques-for-fast-booting.pdf here]<br />
* [http://lwn.net/Articles/192082/ Optimizing Linker Load Times]<br />
** (introducing various kinds of bootuptime reduction, prelinking, etc.)<br />
* [http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Benchmarking-boot-latency-on-x86/ Benchmarking boot latency on x86]<br />
** By Gilad Ben-Yossef, July 2008<br />
** A tutorial on using TSC register and the kernel PRINTK_TIMES feature to measure x86 system boot time, including BIOS, bootloader, kernel and time to first user program.<br />
* [http://tree.celinuxforum.org/CelfPubWiki/KoreaTechJamboree3?action=AttachFile&do=get&target=The_Fast_Booting_of_Embedded_Linux.pdf Fast Booting of Embedded Linux]<br />
** By HoJoon Park, Electrons and Telecommunications Research Institute (ETRI), Korea, Presented at the CELF [http://tree.celinuxforum.org/CelfPubWiki/KoreaTechJamboree3 3rd Korean Technical Jamboree], July 2008<br />
** Explains several different reduction techniques used for different phases of bootup time<br />
*Tim Bird's (Sony) survey of boot-up time reduction techniques:<br />
**[http://kernel.org/doc/ols/2004/ols2004v1-pages-79-88.pdf Methods to Improve Boot-up Time in Linux] - Paper prepared for 2004 Ottawa Linux Symposium<br />
**{{pdf|ReducingStartupTime v0.8.pdf|Reducing Startup Time in Embedded Linux Systems}} - December 2003 Presentation describing some existing boot-up time reduction techniques and strategies.<br />
* [http://free-electrons.com/articles/optimizations Embedded Linux optimizations]<br />
** By Free Electrons<br />
** Tutorial to reduce size, RAM, speed, power and cost of a Linux based embedded system]<br />
*Parallelizing Linux Boot on CE Devices<br />
** [http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2007Presentations?action=AttachFile&do=view&target=par.pdf PDF of Presentation]<br />
**[http://free-electrons.com/pub/video/2007/elce/elce-2007-vitaly-wool-parallel-boot.ogg Video of Presentation]<br />
*[http://www.ibm.com/developerworks/linux/library/l-boot-faster/ Parallelize Applications for Faster Linux Boot]<br />
**Authored by M. Tim Jones for IBM Developer Works<br />
**This article shows you options to increase the speed with which Linux boots, including two options for parallelizing the initialization process. It also shows you how to visualize graphically the performance of the boot process.<br />
<br />
=== Case Studies ===<br />
* Samsung proof-of-acceptability study for digital still camera: see [[Media:LinuxBootupTimeReduction4DSC.ppt|Boot Up Time Reduction PPT]] and the [http://www.kernel.org/doc/ols/2006/ols2006v2-pages-239-248.pdf paper] describing this.<br />
* [https://docs.blackfin.uclinux.org/doku.php?id=fast_boot_example Boot Linux from Processor Reset into user space in less than 1 Second]<br />
** In this white paper, Robin Getz describes the techniques used to fast-boot a blackfin development board.<br />
* [http://e2e.ti.com/support/embedded/f/354/t/51158.aspx Booting Linux dm365 Network Camera in 3.2 seconds]<br />
* [http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/p/7616/30088.aspx Boot of kernel and shell in 0.5 sec (not including u-boot and decompression)]<br />
<br />
* Lineo Solutions announced (Nov. 2008) technology to boot Linux in 2.97 seconds on a low-end system. The system is called "Warp2" and appears to be a form of modified resume (similar to "snapshot boot" mentioned above.<br />
** See http://www.linuxfordevices.com/c/a/News/Linux-boots-in-297-seconds/<br />
<br />
== Additional Projects/Mailing Lists/Resources ==<br />
=== Replacements for SysV 'init' ===<br />
The traditional method of starting a Linux system is to use /sbin/init, which<br />
processes the file /etc/inittab. This is an init program which processes a series of actions for different <br />
run-levels and system events (key-combinations and power events).<br />
<br />
See [http://linux.die.net/man/8/init the init(8) man page] and the [http://linux.die.net/man/5/inittab the inittab(5) man page].<br />
<br />
==== busybox init ====<br />
An 'init' applet is often included in [[BusyBox]]<br />
<br />
There used to be (as of 2000) some slight differences in the supported features of the 'inittab' file<br />
between busybox init and full-blown init. However, I don't know (as of 2010) if that's still the case.<br />
(See http://spblinux.de/2.0/doc/init.html for some details)<br />
<br />
Denys Vlasenko, one of the maintainers of busybox has suggested a replacement for traditional init<br />
for that tool called runsv. See http://busybox.net/~vda/init_vs_runsv.html<br />
<br />
==== upstart ====<br />
upstart is the name of a newer Linux desktop systems that provides the program /sbin/init,<br />
but with different operational semantics.<br />
<br />
* Home page: http://upstart.ubuntu.com/<br />
* Wikipedia page: http://en.wikipedia.org/wiki/Upstart<br />
<br />
==== Android init ====<br />
Android 'init' is a custom program for booting the Android system.<br />
<br />
See [[Android_Booting#.27init.27|Android 'init']]<br />
<br />
==== systemd ====<br />
systemd is a new project (as of May 2010) for starting daemons and services on a Linux desktop system<br />
<br />
See http://0pointer.de/blog/projects/systemd.html<br />
<br />
=== Kexec ===<br />
*Kexec is a system which allows a system to be '''rebooted''' without going through BIOS. That is, a Linux kernel can directly boot into another Linux kernel, without going through firmware. See the white paper at: [http://developer.osdl.org/andyp/kexec/whitepaper/kexec.pdf kexec.pdf]<br />
**2004 Kernel Summit presentation: [http://www.xenotime.net/linux/fastboot/fastboot-ks-2004.pdf fastboot.pdf]<br />
**here's another Kexec white paper:[http://www-106.ibm.com/developerworks/linux/library/l-kexec.html?ca=dgr-lnxw04 Reboot Fast]<br />
<br />
=== Splash Screen projects ===<br />
* [http://splashy.alioth.debian.org/wiki/ Splashy] - Technology to put up a spalsh screen early in the boot sequence. This is user-space code.<br />
** This seems to be the most current splash screen technology, for major distributions. A framebuffer driver for the kernel is required.<br />
* [http://dev.gentoo.org/~spock/projects/gensplash/ Gentoo Splashscreen] - newer technology to put a splash screen early in the boot sequence<br />
** See the HOWTO at: [http://gentoo-wiki.com/HOWTO_fbsplash HOWTO FBSplash]<br />
* [http://butterfeet.org/?p=8 PSplash] - PSplash is a userspace graphical boot splash screen for mainly embedded Linux devices supporting a 16bpp or 32bpp framebuffer.<br />
* [http://www.bootsplash.org/ bootsplash.org] - put up a splash screen early in boot sequence<br />
** This project requires kernel patches<br />
** This project is now abandoned, and work is being done on Splashy.<br />
<br />
=== Others ===<br />
<br />
*[http://www.linuxdevices.com/news/NS5907201615.html FSMLabs Fastboot] - press release by FSMLabs about fast booting of their product. Is any of this published?<br />
<br />
*[http://tree.celinuxforum.org/CelfPubWiki/ snapshot boot] - a technology uses software resume to boot up the system quickly.<br />
<br />
==== Apparently obsolete or abandoned material ====<br />
* [[Image:alert.gif]] ''in progress'' - [[Boot-up Time Reduction Howto]] - this is a project to catalog existing boot-up time reduction techniques.<br />
** Was originally intended to be the authoritative source for bootup time reduction information.<br />
** No one maintains it any more (as of Aug, 2008)<br />
*[[Image:alert.gif]]''no content yet'' - [[Boot-up Time Delay Taxonomy]] - list of delays categorized by boot phase, type and magnitude<br />
** Was to be a survey of common bootup delays found in embedded devices.<br />
** Was never really written.<br />
<br />
???<br />
* [[Bootup Time Spec]]<br />
* [[Bootup Time Things To Investigate]]<br />
* [[Bootup Time Working Group]]<br />
* [[Bootup Time Task List]]<br />
* [[Bootup Time Howto Task List]]<br />
* [[Fast Booting Translation]]<br />
<br />
== Companies, individuals or projects working on fast booting ==<br />
* Intel - Arjan van de Ven - see http://lwn.net/Articles/299483/<br />
* Tripeaks - see http://www.linuxdevices.com/news/NS8282586707.html<br />
* Lineo Solutions - see http://www.linuxdevices.com/news/NS5185504436.html<br />
* Monta Vista - see http://www.linuxdevices.com/news/NS2560585344.html<br />
* fastboot git tree - see http://lwn.net/Articles/299591/<br />
<br />
== Boot time check list ==<br />
<br />
From an [http://www.mail-archive.com/linux-embedded@vger.kernel.org/msg02139.html August 2009 discussion about boot time on ARM devices], several hints and advice regarding boot time optimization are available. While it may repeat a lot of above, below is a check list extracted from this discussion:<br />
<br />
* Is CPU's clock switched to maximum? If the kernel, bootloader or hardware is in charge of setting CPU power and speed scaling, then you should check that it boots with the CPU set at maximum speed instead of slowest. <br />
<br />
* Is your hardware (register) timing configuration of your SoC's memory interfaces (e.g. RAM and NOR/NAND timing) optimized? A lot of vendors ship their hardware with "well, it works, optimize later" settings. What you want is "as fast as possible, but sill stable and reliable" configuration. This might need some hardware knowledge and has to be customized to the individual memory devices used.<br />
<br />
* Does your boot loader uses I- and D-Cache? E.g. U-Boot doesn't enable D-Cache by default on ARM devices, as it needs customized MMU tables to do so.<br />
<br />
* Does kernel copy from permanent storage (e.g. NOR or NAND) to RAM use optimized functions? E.g. DMA, or on ARM at least load/store multiple commands (ldm/stm)?<br />
<br />
* If you use U-Boot's uImage, set "verify=no" in U-Boot to avoid checksum verification.<br />
<br />
* Optimize size of your kernel.<br />
** You might even try some of the embedded system kernel config options that, for example, eliminate all the printk strings, reduce data structures, or eliminate unneeded functionality.<br />
<br />
* How often is kernel (image) data copied? First by boot loader from storage to RAM, then by kernel's uncompressor to it's final destination? Once more? If you use compressed kernel and NOR flash, consider running the uncompressor XIP in NOR flash.<br />
<br />
* If you use compressed kernel, check compression algorithm. zlib is slow on decompression, and lzo is much faster. So if you implement lzo compression, you'll probably speed things up a little as well (check LKML for this). Having no compression at all may also be a good thing to try (see next topic).<br />
<br />
* Check to use uncompressed kernel (depends on your system configuration). Using an uncompressed kernel on a flash-based system may improve boot time. The reason is that compressed kernels are faster only when the throughput to the persistent storage is lower than the decompression throughput, and on typical embedded systems with DMA the throughput to memory outperforms the CPU-based decompression. Of course it depends on a lot of stuff like performance of flash controller, kernel storage filesystem performance, DMA controller performance, cache architecture etc. So it's individual per-system. Example: With using an uncomressed kernel (~2.8MB) uncompressing (running the uncompressor XIP in NOR flash) took ~0.5s longer than copying 2.8MB from flash to RAM.<br />
<br />
* Enable precalculated loops-per-jiffy<br />
<br />
* Enable kernel quiet option<br />
<br />
* If you use UBI: UBI is rather slow in attaching MTD devices. Everything is explained at MTD's [http://www.linux-mtd.infradead.org/doc/ubi.html#L_scalability UBI scalability] and [http://www.linux-mtd.infradead.org/doc/ubifs.html#L_scalability UBI fs scalability] sections. There is not very much you can do to speed it up but implement UBI2. UBIFS would stay intact. There were discussions about this and it does not seem to be impossibly difficult to do UBI2 ([http://www.linux-mtd.infradead.org/faq/ubi.html#L_attach_faster few ideas]).<br />
** In a follow-up e-mail, Sascha Hauer wrote:<br />
<pre> What's interesting about this is that the kernel NAND driver is much slower<br />
than the one in U-Boot. Looking at it it turned out that the kernel<br />
driver uses interrupts to wait for the controller to get ready.<br />
Switching this to polling nearly doubles the NAND performance. UBI<br />
mounts much faster now and this cuts off another few seconds from the<br />
boot process :) <br />
</pre><br />
<br />
* Use static device nodes during boot, and later setup busybox mdev for hotplug.<br />
<br />
* If you have network enabled, there might be some very long timeouts in the network code paths, which appear to be used whether you specify a static address or not. See the definitions of CONF_PRE_OPEN and CON_POST_OPEN in ''net/ipv4/ipconfig.c''. Check [http://patchwork.kernel.org/patch/31678/ ipdelay configuration patch].<br />
<br />
* Parallelize boot process.<br />
<br />
* Disable the option "Set system time from RTC on startup and resume", you can use the command hwclock -s at the of the init instead of slowing down the kernel.<br />
<br />
[[Category:Boot Time]]<br />
[[Category:Bootloader]]</div>Consthttp://elinux.org/Boot_TimeBoot Time2011-01-05T22:16:17Z<p>Const: /* Articles and Presentations */ updated link</p>
<hr />
<div>== Introduction ==<br />
Boot Time includes topics such as measurement, analysis, human factors, initialization techniques, and reduction techniques.<br />
The time that a product takes to boot directly impacts the first perception an end user has of the product.<br />
Regardless of how attractive or well designed a consumer electronic device is, the time required to move the device from off to an interactive, usable state is critical to obtaining a positive end user experience. Turning on a device is Use Case #1.<br />
<br />
Booting up a device involves numerous steps and sequences of events. In order to use consistent terminology, the<br />
[[Bootup Time Working Group]] of the CE Linux Forum came up with a list of terms and their widely accepted definitions<br />
for this functionality area. See the following page for these terms:<br />
* [[Boot-up Time Definition Of Terms]]<br />
<br />
== Technology/Project Pages ==<br />
The following are individual pages with information about various technologies relevant to improving Boot Time for Linux. Some of these describe local patches available on this site. Others point to projects or patches maintained elsewhere.<br />
<br />
=== Measuring Boot-up Time ===<br />
*[[Printk Times]] - simple system for showing timing information for each printk.<br />
*[[Kernel Function Trace]] - system for reporting function timings in the kernel.<br />
*[[Linux Trace Toolkit]] - system for reporting timing data for certain kernel and process events.<br />
*[http://oprofile.sourceforge.net/news/ Oprofile] - system-wide profiler for Linux.<br />
*[[Bootchart]] - a tool for performance analysis and visualization of the Linux boot process. Resource utilization and process information are collected during the user-space portion of the boot process and are later rendered in a PNG, SVG or EPS encoded chart.<br />
*[http://people.redhat.com/berrange/systemtap/bootprobe/ Bootprobe] - a set of [[System Tap]] scripts for analyzing system bootup.<br />
* and, let us not forget: "cat /proc/uptime"<br />
* [[Tims Fastboot Tools#grabserial | grabserial]] - a nice utility from Tim Bird to log and timestamp console output<br />
* [[Tims Fastboot Tools#Tim's quick and dirty process trace|process trace]] - a simple patch from Tim Bird to log exec, fork and exit system calls.<br />
* [http://pengutronix.de/software/ptx_ts/index_en.html ptx_ts] - Pengutronix' TimeStamper: A small filter prepending timestamps to STDOUT; a bit similar to grabserial but not limited to serial ports<br />
* [[Initcall Debug]] - a kernel command line option to show time taken for initcalls.<br />
* See also: [[Kernel Instrumentation]] which lists some known kernel instrumentation tools. These are of interest for measuring kernel startup time.<br />
<br />
=== Technologies and Techniques for Reducing Boot Time ===<br />
==== Bootloader speedups ====<br />
*[[Kernel XIP]] - Allow kernel to be executed in-place in ROM or FLASH.<br />
*[[DMA Copy Of Kernel On Startup]] - Copy kernel from Flash to RAM using DMA<br />
*[[Uncompressed kernel]] - An uncompressed kernel might boot faster<br />
*[[Fast Kernel Decompression]]<br />
<br />
==== Kernel speedups ====<br />
*[[Disable Console]] - Avoid overhead of console output during system startup.<br />
*Disable bug and printk - Avoid the overhead of bug and printk. Disadvantage is that you loose a lot of info.<br />
*[[RTC No Sync]] - Avoid delay to synchronize system time with RTC clock edge on startup.<br />
*[[Short IDE Delays]] - Reduce duration of IDE startup delays (this is effective but possibly dangerous).<br />
*[[Hardcode kernel module info]] - Reduce the overhead of loading a module, by hardcoding some information used for loading the relocation information<br />
*[[IDE No Probe]] - Force kernel to observe the ide<x>=noprobe option.<br />
*[[Preset LPJ]] - Allow the use of a preset loops_per_jiffy value.<br />
*[[Asynchronous function calls]] - Allow probing or other functions to proceed in parallel, to overlap time-consuming boot-up activities.<br />
**[[Threaded Device Probing]] - Allow drivers to probe devices in parallel. (not mainlined, now deprecated?)<br />
*[[Reordering of driver initialization]] - Allow driver bus probing to start as soon as possible.<br />
*[[Deferred Initcalls]] - defer non-essential module initialization routines to after primary boot<br />
*NAND ECC improvement - The pre 2.6.28 nand_ecc.c has room for improvement. You can find an improved version in the mtd git at http://git.infradead.org/mtd-2.6.git?a=blob_plain;f=drivers/mtd/nand/nand_ecc.c;hb=HEAD. Documentation for this is in http://git.infradead.org/mtd-2.6.git?a=blob_plain;f=Documentation/mtd/nand_ecc.txt;hb=HEAD. This is only interesting if your system uses software ECC correction.<br />
*Check what kernel memory allocator you use. Slob or slub might be better than slab (which is the default in older kernels) <br />
*If your system does not need it, you can remove SYSFS and even PROCFS from the kernel. In one test removing sysfs saved 20 ms.<br />
*Carefully investigate all kernel configuration options on whether they are applicable or not. Even if you select an option that is not used in the end, it contributes to the kernel size and therefore to the kernel load time (assuming you are not doing kernel XIP). Often this will require some trial and measure! E.g. selecting CONFIG_CC_OPTIMIZE_FOR_SIZE (found under general setup) gave in one case a boot improvement of 20 ms. Not dramamtic, but when reducing boot time every penny counts!<br />
*Moving to a different compiler version might lead to shorter and/or faster code. Most often newer compilers produce better code. You might also want to play with compiler options to see what works best.<br />
* If you use initramfs in your kernel and a compressed kernel it is better to have an uncompressed initramfs image. This is to avoid having to uncompress data twice. A patch for this has been submitted to LKML. See http://lkml.org/lkml/2008/11/22/112 <br />
<br />
===== File System issues =====<br />
Different file systems have different initialization (mounting) times, for the same data sets. This<br />
is a function of whether meta-data must be read from storage into RAM or not, and what algorithms are<br />
used during the mount procedure.<br />
<br />
* [[Filesystem Information]] - has information about boot-up times of various file systems<br />
* [[File Systems]] - has information on various file systems that are interesting for embedded systems. Also includes some improvement suggestions.<br />
* [[Avoid Initramfs]] - explains on why intramfs should be avoided if you want to minimize boot time<br />
* Split partitions. If mounting a file system takes long, you can consider splitting that filesystem in two parts, one with the info that is needed during or immediately after boot, and one which can be mounted later on.<br />
* [[Ramdisks demasked]] - explains why using a ram disk generally results in a longer boot time, not a shorter one.<br />
<br />
==== User-space and application speedups ====<br />
* [[Optimize RC Scripts]] - Reduce overhead of running RC scripts<br />
* [[Parallel RC Scripts]] - Run RC scripts in parallel instead of sequentially<br />
* [[Application XIP]] - Allow programs and libraries to be executed in-place in ROM or FLASH<br />
* [[Pre Linking]] - Avoid cost of runtime linking on first program load<br />
* Statically link applications. This avoids the costs of runtime linking. Useful if you have only a few applications. In that case it could also reduce the size of your image as no dynamic libraries are needed<br />
* GNU_HASH: ~ 50% speed improvement in dynamic linking<br />
** See http://sourceware.org/ml/binutils/2006-06/msg00418.html<br />
* [[Application Init Optimizations]] - Improvements in program load and init time via: <br />
** use of mmap vs. read<br />
** control over page mapping characteristics.<br />
* [[Include modules in kernel image]] - Avoid extra overhead of module loading by adding the modules to the kernel image<br />
* Avoid udev, it takes quite some time to populate the /dev directory. In an embedded system it is often known what devices are present and in any case you know what drivers are available, so you know what device entries might be needed in /dev. These should be created statically, not dynamically. mknod is your friend, udev is your enemy.<br />
* If you still like udev and also like fast boot-up's, you might go this way: start your system with udev enabled and make kind of a backup of the created device nodes. Now, modify your init script like this: instead running udev, copy the device nodes that you just made a backup of into the device tree. Now, install the hotplug-daemon like you always do. That trick avoids the device node creation at startup but stills lets your system create device nodes later on. <br />
* If your device has a network connection, preferably use static IP addresses. Getting an address from a DHCP server takes additional time and has extra overhead associated with it.<br />
* Moving to a different compiler version might lead to shorter and/or faster code. Most often newer compilers produce better code. You might also want to play with compiler options to see what works best.<br />
* If possible move from glibc to uClibc. This leads to smaller executables and hence to faster load times.<br />
* library optimiser tool: http://libraryopt.sourceforge.net/ <br/> This will allow you to create an optimised library. As unneeded functions are removed this should lead to a performance gain. Normally there will be library pages which contain unused code (adjacent to code that is used). After optimizing the library this does not occur any more, so less pages are needed and hence less page loads, so some time can be saved.<br />
* Function reordering: http://www.celinux.org/elc08_presentations/DDLink%20FunctionReorder%2008%2004.pdf <br/> This is a technique to rearrange the functions within an executable so they appear in the order they are needed. This improves the load time of the application as all initialization code is grouped into a set of pages, instead of being scattered over a number of pages.<br />
<br />
==== Suspend related improvements ====<br />
Another approach to improve boot time is to use a suspend related mechanism. Two approaches are known.<br />
* Using the standard hibernate/resume approach. This is what has been demonstrated by Chan Ju, Park, from Samsung. See sheet 23 and onwards from this [[Media:LinuxBootupTimeReduction4DSC.ppt|PPT]] and section 2.7 of this [http://www.kernel.org/doc/ols/2006/ols2006v2-pages-239-248.pdf paper]. <br /> Issue with this approach is that flash write is much slower than flash read, so the actual creation of the hibernate image might take quite a while.<br />
* Implementing snapshot boot. This is done by Hiroki Kaminaga from Sony and is described at [[Suspend To Disk For ARM|snapshot boot for ARM]] and http://elinux.org/upload/3/37/Snapshot-boot-final.pdf<br />This is similar to hibernate and resume, but the hibernate file is retained and used upon every boot. Disadvantage is that no writable partitions should be mounted at the time of making the snapshot. Otherwise inconsistencies will occur if a partition is modified, while applications in the hibernate file might have information in the snapshot related to the unmodified partition.<br />
<br />
==== Miscellaneous topics ====<br />
<br />
[[About Compression]] discusses the effects of compression on boot time. This can affect both the kernel boot time as well as user-space startup.<br />
<br />
==== Uninvestigated speedups ====<br />
<br />
This section is a holding pen for ideas for improvement that are not implemented yet but that could result in a boot time gain. Please leave a note here if you are working on one of these items to avoid duplicate work.<br />
<br />
* '''Prepopulated buffer cache''' - As initramfs performs an additional copy of the data the idea is to have a prepopulated buffer cache. A simplistic scenario would allow dumping the buffer cache when the booting is completed and the user applications have initialised. This data then could be used in a subsequent boot to initialize the buffer cache (of course without copying). A possible approach would be to have those data to reside into the kernel image and use them directly. Alternately they could be loaded separately. <br /> Unfortunately my knowledge of the internals in this section is not yet good enough to do a trial implementation.<br /> Caveats:<br />
** is it possible to have the buffer cache split into two different parts, one which is statically allocated, one which is dynamically allocated?<br />
** the pages in the prepopulated buffer cache probably cannot be discarded, so they should be pinned<br />
** apart from the buffer cache data itself also some other variables might need restoring<br />
** a similar approach could also be used for the cached file data.<br />
*'''Dedicated fs''' - currently a lot of abstraction is done in fs to make a nice abstraction allowing easy addition of new filesystems and creating a unified view of those filesystem. While this is pretty neat, the abstraction layers also introduce some overhead. A solution could be to create a dedicated fs system, which supports only one (or maybe 2) filesystems, and eliminates the abstraction overhead. This will give some benefit, but the chance of getting this into the mainline is zero.<br />
<br />
== Articles and Presentations ==<br />
* "The Right Approach to Boot Time Reduction" - ([http://elinux.org/images/f/f7/RightApproachMinimalBootTimes.pdf Slides] | [http://www.youtube.com/watch?v=ULa4TPy7z0c YouTube Video])<br />
** Andrew Murray has presented at ELC Europe on October 28, 2010<br />
** This included a < 1 second QT cold Linux boot case study for an SH7724 with some additional information about 'function re-ordering' in user-space<br />
** Similar slides with < 1 second case study for OMAP3530EVM can be found [http://www.slideshare.net/andrewmurraympc/t-iswift-boot here]<br />
* "One Second Linux Boot Demonstration (new version)" ([http://www.youtube.com/watch?v=-l_DSZe8_F8 Youtube video by MontaVista])<br />
* "Tools and Techniques for Reducing Bootup Time" ([[Media:Tools-and-technique-for-reducing-bootup-time.ppt|PPT]] | [[Media:Tools-and-technique-for-reducing-bootup-time.odp|ODP]] | [[Media:Tools-and-technique-for-reducing-bootup-time.pdf|PDF]] | [http://free-electrons.com/pub/video/2008/elce/elce2008-bird-reducing-bootup-time.ogv video])<br />
** Tim Bird has presented at ELC Europe, on November 7, 2008, his latest collection of tips and tricks for reducing bootup time<br />
** [[Tims Fastboot Tools]] has online materials in support of this presentation<br />
* [http://www.mvista.com/download/author.php?a=37 Christopher Hallinan] has done a presentation at the MontaVista Vision conference 2008 on the topic of reducing boot time. Slides available [http://www.mvista.com/download/power/Reducing-boot-time-techniques-for-fast-booting.pdf here]<br />
* [http://lwn.net/Articles/192082/ Optimizing Linker Load Times]<br />
** (introducing various kinds of bootuptime reduction, prelinking, etc.)<br />
* [http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Benchmarking-boot-latency-on-x86/ Benchmarking boot latency on x86]<br />
** By Gilad Ben-Yossef, July 2008<br />
** A tutorial on using TSC register and the kernel PRINTK_TIMES feature to measure x86 system boot time, including BIOS, bootloader, kernel and time to first user program.<br />
* [http://tree.celinuxforum.org/CelfPubWiki/KoreaTechJamboree3?action=AttachFile&do=get&target=The_Fast_Booting_of_Embedded_Linux.pdf Fast Booting of Embedded Linux]<br />
** By HoJoon Park, Electrons and Telecommunications Research Institute (ETRI), Korea, Presented at the CELF [http://tree.celinuxforum.org/CelfPubWiki/KoreaTechJamboree3 3rd Korean Technical Jamboree], July 2008<br />
** Explains several different reduction techniques used for different phases of bootup time<br />
*Tim Bird's (Sony) survey of boot-up time reduction techniques:<br />
**[http://kernel.org/doc/ols/2004/ols2004v1-pages-79-88.pdf Methods to Improve Boot-up Time in Linux] - Paper prepared for 2004 Ottawa Linux Symposium<br />
**{{pdf|ReducingStartupTime v0.8.pdf|Reducing Startup Time in Embedded Linux Systems}} - December 2003 Presentation describing some existing boot-up time reduction techniques and strategies.<br />
* [http://free-electrons.com/articles/optimizations Embedded Linux optimizations]<br />
** By Free Electrons<br />
** Tutorial to reduce size, RAM, speed, power and cost of a Linux based embedded system]<br />
*Parallelizing Linux Boot on CE Devices<br />
** [http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2007Presentations?action=AttachFile&do=view&target=par.pdf PDF of Presentation]<br />
**[http://free-electrons.com/pub/video/2007/elce/elce-2007-vitaly-wool-parallel-boot.ogg Video of Presentation]<br />
*[http://www.ibm.com/developerworks/linux/library/l-boot-faster/ Parallelize Applications for Faster Linux Boot]<br />
**Authored by M. Tim Jones for IBM Developer Works<br />
**This article shows you options to increase the speed with which Linux boots, including two options for parallelizing the initialization process. It also shows you how to visualize graphically the performance of the boot process.<br />
<br />
=== Case Studies ===<br />
* Samsung proof-of-acceptability study for digital still camera: see [[Media:LinuxBootupTimeReduction4DSC.ppt|Boot Up Time Reduction PPT]] and the [http://www.kernel.org/doc/ols/2006/ols2006v2-pages-239-248.pdf paper] describing this.<br />
* [https://docs.blackfin.uclinux.org/doku.php?id=fast_boot_example Boot Linux from Processor Reset into user space in less than 1 Second]<br />
** In this white paper, Robin Getz describes the techniques used to fast-boot a blackfin development board.<br />
* [http://e2e.ti.com/support/embedded/f/354/t/51158.aspx Booting Linux dm365 Network Camera in 3.2 seconds]<br />
* [http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/p/7616/30088.aspx Boot of kernel and shell in 0.5 sec (not including u-boot and decompression)]<br />
<br />
=== News ===<br />
* Lineo Solutions announced (Nov. 2008) technology to boot Linux in 2.97 seconds on a low-end system. The system is called "Warp2" and appears to be a form of modified resume (similar to "snapshot boot" mentioned above.<br />
** See http://www.linuxdevices.com/news/NS5185504436.html<br />
<br />
== Additional Projects/Mailing Lists/Resources ==<br />
=== Replacements for SysV 'init' ===<br />
The traditional method of starting a Linux system is to use /sbin/init, which<br />
processes the file /etc/inittab. This is an init program which processes a series of actions for different <br />
run-levels and system events (key-combinations and power events).<br />
<br />
See [http://linux.die.net/man/8/init the init(8) man page] and the [http://linux.die.net/man/5/inittab the inittab(5) man page].<br />
<br />
==== busybox init ====<br />
An 'init' applet is often included in [[BusyBox]]<br />
<br />
There used to be (as of 2000) some slight differences in the supported features of the 'inittab' file<br />
between busybox init and full-blown init. However, I don't know (as of 2010) if that's still the case.<br />
(See http://spblinux.de/2.0/doc/init.html for some details)<br />
<br />
Denys Vlasenko, one of the maintainers of busybox has suggested a replacement for traditional init<br />
for that tool called runsv. See http://busybox.net/~vda/init_vs_runsv.html<br />
<br />
==== upstart ====<br />
upstart is the name of a newer Linux desktop systems that provides the program /sbin/init,<br />
but with different operational semantics.<br />
<br />
* Home page: http://upstart.ubuntu.com/<br />
* Wikipedia page: http://en.wikipedia.org/wiki/Upstart<br />
<br />
==== Android init ====<br />
Android 'init' is a custom program for booting the Android system.<br />
<br />
See [[Android_Booting#.27init.27|Android 'init']]<br />
<br />
==== systemd ====<br />
systemd is a new project (as of May 2010) for starting daemons and services on a Linux desktop system<br />
<br />
See http://0pointer.de/blog/projects/systemd.html<br />
<br />
=== Kexec ===<br />
*Kexec is a system which allows a system to be '''rebooted''' without going through BIOS. That is, a Linux kernel can directly boot into another Linux kernel, without going through firmware. See the white paper at: [http://developer.osdl.org/andyp/kexec/whitepaper/kexec.pdf kexec.pdf]<br />
**2004 Kernel Summit presentation: [http://www.xenotime.net/linux/fastboot/fastboot-ks-2004.pdf fastboot.pdf]<br />
**here's another Kexec white paper:[http://www-106.ibm.com/developerworks/linux/library/l-kexec.html?ca=dgr-lnxw04 Reboot Fast]<br />
<br />
=== Splash Screen projects ===<br />
* [http://splashy.alioth.debian.org/wiki/ Splashy] - Technology to put up a spalsh screen early in the boot sequence. This is user-space code.<br />
** This seems to be the most current splash screen technology, for major distributions. A framebuffer driver for the kernel is required.<br />
* [http://dev.gentoo.org/~spock/projects/gensplash/ Gentoo Splashscreen] - newer technology to put a splash screen early in the boot sequence<br />
** See the HOWTO at: [http://gentoo-wiki.com/HOWTO_fbsplash HOWTO FBSplash]<br />
* [http://butterfeet.org/?p=8 PSplash] - PSplash is a userspace graphical boot splash screen for mainly embedded Linux devices supporting a 16bpp or 32bpp framebuffer.<br />
* [http://www.bootsplash.org/ bootsplash.org] - put up a splash screen early in boot sequence<br />
** This project requires kernel patches<br />
** This project is now abandoned, and work is being done on Splashy.<br />
<br />
=== Others ===<br />
<br />
*[http://www.linuxdevices.com/news/NS5907201615.html FSMLabs Fastboot] - press release by FSMLabs about fast booting of their product. Is any of this published?<br />
<br />
*[http://tree.celinuxforum.org/CelfPubWiki/ snapshot boot] - a technology uses software resume to boot up the system quickly.<br />
<br />
==== Apparently obsolete or abandoned material ====<br />
* [[Image:alert.gif]] ''in progress'' - [[Boot-up Time Reduction Howto]] - this is a project to catalog existing boot-up time reduction techniques.<br />
** Was originally intended to be the authoritative source for bootup time reduction information.<br />
** No one maintains it any more (as of Aug, 2008)<br />
*[[Image:alert.gif]]''no content yet'' - [[Boot-up Time Delay Taxonomy]] - list of delays categorized by boot phase, type and magnitude<br />
** Was to be a survey of common bootup delays found in embedded devices.<br />
** Was never really written.<br />
<br />
???<br />
* [[Bootup Time Spec]]<br />
* [[Bootup Time Things To Investigate]]<br />
* [[Bootup Time Working Group]]<br />
* [[Bootup Time Task List]]<br />
* [[Bootup Time Howto Task List]]<br />
* [[Fast Booting Translation]]<br />
<br />
== Companies, individuals or projects working on fast booting ==<br />
* Intel - Arjan van de Ven - see http://lwn.net/Articles/299483/<br />
* Tripeaks - see http://www.linuxdevices.com/news/NS8282586707.html<br />
* Lineo Solutions - see http://www.linuxdevices.com/news/NS5185504436.html<br />
* Monta Vista - see http://www.linuxdevices.com/news/NS2560585344.html<br />
* fastboot git tree - see http://lwn.net/Articles/299591/<br />
<br />
== Boot time check list ==<br />
<br />
From an [http://www.mail-archive.com/linux-embedded@vger.kernel.org/msg02139.html August 2009 discussion about boot time on ARM devices], several hints and advice regarding boot time optimization are available. While it may repeat a lot of above, below is a check list extracted from this discussion:<br />
<br />
* Is CPU's clock switched to maximum? If the kernel, bootloader or hardware is in charge of setting CPU power and speed scaling, then you should check that it boots with the CPU set at maximum speed instead of slowest. <br />
<br />
* Is your hardware (register) timing configuration of your SoC's memory interfaces (e.g. RAM and NOR/NAND timing) optimized? A lot of vendors ship their hardware with "well, it works, optimize later" settings. What you want is "as fast as possible, but sill stable and reliable" configuration. This might need some hardware knowledge and has to be customized to the individual memory devices used.<br />
<br />
* Does your boot loader uses I- and D-Cache? E.g. U-Boot doesn't enable D-Cache by default on ARM devices, as it needs customized MMU tables to do so.<br />
<br />
* Does kernel copy from permanent storage (e.g. NOR or NAND) to RAM use optimized functions? E.g. DMA, or on ARM at least load/store multiple commands (ldm/stm)?<br />
<br />
* If you use U-Boot's uImage, set "verify=no" in U-Boot to avoid checksum verification.<br />
<br />
* Optimize size of your kernel.<br />
** You might even try some of the embedded system kernel config options that, for example, eliminate all the printk strings, reduce data structures, or eliminate unneeded functionality.<br />
<br />
* How often is kernel (image) data copied? First by boot loader from storage to RAM, then by kernel's uncompressor to it's final destination? Once more? If you use compressed kernel and NOR flash, consider running the uncompressor XIP in NOR flash.<br />
<br />
* If you use compressed kernel, check compression algorithm. zlib is slow on decompression, and lzo is much faster. So if you implement lzo compression, you'll probably speed things up a little as well (check LKML for this). Having no compression at all may also be a good thing to try (see next topic).<br />
<br />
* Check to use uncompressed kernel (depends on your system configuration). Using an uncompressed kernel on a flash-based system may improve boot time. The reason is that compressed kernels are faster only when the throughput to the persistent storage is lower than the decompression throughput, and on typical embedded systems with DMA the throughput to memory outperforms the CPU-based decompression. Of course it depends on a lot of stuff like performance of flash controller, kernel storage filesystem performance, DMA controller performance, cache architecture etc. So it's individual per-system. Example: With using an uncomressed kernel (~2.8MB) uncompressing (running the uncompressor XIP in NOR flash) took ~0.5s longer than copying 2.8MB from flash to RAM.<br />
<br />
* Enable precalculated loops-per-jiffy<br />
<br />
* Enable kernel quiet option<br />
<br />
* If you use UBI: UBI is rather slow in attaching MTD devices. Everything is explained at MTD's [http://www.linux-mtd.infradead.org/doc/ubi.html#L_scalability UBI scalability] and [http://www.linux-mtd.infradead.org/doc/ubifs.html#L_scalability UBI fs scalability] sections. There is not very much you can do to speed it up but implement UBI2. UBIFS would stay intact. There were discussions about this and it does not seem to be impossibly difficult to do UBI2 ([http://www.linux-mtd.infradead.org/faq/ubi.html#L_attach_faster few ideas]).<br />
** In a follow-up e-mail, Sascha Hauer wrote:<br />
<pre> What's interesting about this is that the kernel NAND driver is much slower<br />
than the one in U-Boot. Looking at it it turned out that the kernel<br />
driver uses interrupts to wait for the controller to get ready.<br />
Switching this to polling nearly doubles the NAND performance. UBI<br />
mounts much faster now and this cuts off another few seconds from the<br />
boot process :) <br />
</pre><br />
<br />
* Use static device nodes during boot, and later setup busybox mdev for hotplug.<br />
<br />
* If you have network enabled, there might be some very long timeouts in the network code paths, which appear to be used whether you specify a static address or not. See the definitions of CONF_PRE_OPEN and CON_POST_OPEN in ''net/ipv4/ipconfig.c''. Check [http://patchwork.kernel.org/patch/31678/ ipdelay configuration patch].<br />
<br />
* Parallelize boot process.<br />
<br />
* Disable the option "Set system time from RTC on startup and resume", you can use the command hwclock -s at the of the init instead of slowing down the kernel.<br />
<br />
[[Category:Boot Time]]<br />
[[Category:Bootloader]]</div>Consthttp://elinux.org/Linux_Kernel_ResourcesLinux Kernel Resources2010-01-30T11:25:19Z<p>Const: /* Books */ + LDD3 in html</p>
<hr />
<div>This page has references to various kernel resources (web sites and mailing lists) for developers.<br />
Most of this information was gathered over a year ago, and may not be accurate.<br />
<br />
/\ ''Note: You should always look at the kernel MAINTAINERS file for up-to-date information''<br />
<br />
<br />
<br />
== main (x86) kernel ==<br />
- web site = http://www.kernel.org/<br />
- [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary Linus' Git Repository]<br />
<br />
=== Mailing List (lkml) ===<br />
{| <br />
|- bgcolor="80c0c0"<br />
| align="center" | '''Item''' <br />
| align="center" | '''Link'''<br />
|- <br />
| List E-mail Address <br />
| linux-kernel@vger.kernel.org<br />
|- <br />
| Subscriptions (List Home) <br />
| http://vger.kernel.org/majordomo-info.html<br />
|- <br />
| Archives (Aims Group) <br />
| http://marc.theaimsgroup.com/?l=linux-kernel<br />
|- <br />
| Archives (lkml.org) <br />
| http://lkml.org/<br />
|- <br />
| Archives (as a Google group) <br />
| http://www.google.com/groups?hl=en&lr=&ie=UTF-8&group=linux.kernel<br />
|- <br />
| Archives (at Indiana University) <br />
| http://www.ussg.iu.edu/hypermail/<br />
|- <br />
| Google search of Ind. Univ. archives of LKML <br />
| [http://www.uwsg.iu.edu/search/?scope=kernel Search]<br />
|- <br />
| Summaries - (Kernel Traffic) <br />
| http://kt.zork.net/kernel-traffic/index.html<br />
|- <br />
| Latest summary <br />
| [http://kt.zork.net/kernel-traffic/latest.html latest kernel-traffic issue]<br />
|}<br />
<br />
=== Repository access ===<br />
{| <br />
|- bgcolor="80c0c0"<br />
| align="center" | '''Item''' <br />
| align="center" | '''Link'''<br />
|- <br />
| www.kernel.org<br />
| http://www.kernel.org/git/<br />
|}<br />
<br />
=== News ===<br />
- Linux Weekly News, Kernel page - http://lwn.net/Kernel/<br />
=== Changelog ===<br />
* Comprehensible changelog of the linux kernel<br />
** http://wiki.kernelnewbies.org/LinuxChanges<br />
<br />
* Announcemnts from linus<br />
** 2.6.3 http://lwn.net/Articles/71670/<br />
** 2.6.10 http://lwn.net/Articles/117188/<br />
** 2.6.12 http://lwn.net/Articles/140441/<br />
** 2.6.13 http://lwn.net/Articles/149480/<br />
** 2.6.14 http://lwn.net/Articles/157474/<br />
** 2.6.15 http://lwn.net/Articles/166131/<br />
<br />
* LWN atricles for spcific releases<br />
** 2.6.3 http://lwn.net/Articles/71669/<br />
** 2.6.10 http://lwn.net/Articles/117187/<br />
** 2.6.12 http://lwn.net/Articles/140165/<br />
** 2.6.15 http://lwn.net/Articles/166130/<br />
<br />
* LWN aricles on 2.6 API changes<br />
** 2.6 API changes http://lwn.net/Articles/2.6-kernel-api/<br />
** 2.6.12 API changes http://lwn.net/Articles/140164/<br />
<br />
== Architecture Sites ==<br />
=== MIPS ===<br />
- web site = http://www.linux-mips.org/wiki/Main_Page<br />
- mailing list = http://www.linux-mips.org/wiki/Net_Resources#Mailing_lists<br />
- Maintainer = Ralph Baechle<br />
<br />
- there's an alternate site on [[Source Forge]]<br />
- the site is: http://sourceforge.net/projects/linux-mips<br />
- Note that this is used for experimental stuff that hasn't been merged<br />
into the official mips tree by Ralph Baechle<br />
<br />
=== ARM ===<br />
- web site = http://www.arm.linux.org.uk/<br />
- cvs access = http://cvs.arm.linux.org.uk/<br />
- mailing list = http://www.arm.linux.org.uk/armlinux/mailinglists.php<br />
- wiki = http://www.linux-arm.org/<br />
- Maintainer = Russell King<br />
<br />
=== [[PowerPC]] ===<br />
- web site = http://penguinppc.org/<br />
- mailing lists = http://penguinppc.org/about/community.php#lists<br />
- Git repository = kernel.org:/pub/scm/linux/kernel/git/paulus/powerpc.git<br />
- Maintainer = Paul Mackerras<br />
- [[Power Macintosh]] Maintainer = Benjamin Herrenschmidt<br />
<br />
- cross-compiler mini-howto: http://penguinppc.org/embedded/cross-compiling/<br />
<br />
See the following for information on different linuxppc source trees available:<br />
http://www.penguinppc.org/dev/kernel.shtml<br />
=== SuperH (SH) ===<br />
- web site = http://www.linux-sh.org/<br />
- Git repository = kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git<br />
- mailing list address = linux-sh@vger.kernel.org<br />
- mailing list page = http://vger.kernel.org/vger-lists.html#linux-sh<br />
- mailing list archives = http://news.gmane.org/gmane.linux.ports.sh.devel<br />
- wiki = http://linux-sh.org/shwiki/FrontPage<br />
- Maintainer = Paul Mundt<br />
<br />
<br />
== Documentation ==<br />
<br />
=== Online ===<br />
- Rusty Russell's "Unreliable Guide to Locking" - http://kernelbook.sourceforge.net/kernel-locking.html<br />
- Embedded Linux kernel and driver development - http://free-electrons.com/training/drivers<br />
- Linux USB drivers - http://free-electrons.com/articles/linux-usb<br />
<br />
=== Books ===<br />
* ''Linux Kernel Developmen''t by Robert Love<br />
** Good introduction to Linux kernel development<br />
* ''Linux Device Drivers'' by Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman<br />
** Great book for getting started with Linux device drivers<br />
** Free online pdf edition: http://lwn.net/images/pdf/LDD3/<br />
** online html http://www.makelinux.net/ldd3/<br />
* ''Essential Linux Device Drivers'' by Sreekrishnan Venkateswaran<br />
** Introduction to driver development for major subsystems<br />
* ''Professional Linux Kernel Architecture'' by Wolfgang Mauerer<br />
** Introduction to the architecture, concepts and algorithms of the Linux kernel<br />
* ''Understanding the Linux Kernel'' by Daniel Bovet and Marco Cesati<br />
** Guided tour of the code that forms the core of all Linux operating systems<br />
* ''Linux Kernel in a Nutshell'' by Greg Kroah-Hartman<br />
** Overview of kernel configuration and building<br />
** Free online edition: http://www.kroah.com/lkn/<br />
<br />
== Cross-reference / code online ==<br />
* http://www.makelinux.net/kernel_map<br />
* http://www.linux-m32r.org/lxr/http/source/<br />
* http://lxr.free-electrons.com/<br />
* http://sosdg.org/~coywolf/lxr/source/<br />
* http://lxr.linux.no/source/<br />
<br />
[[Category:Development Tools]]</div>Consthttp://elinux.org/Linux_Kernel_ResourcesLinux Kernel Resources2010-01-30T11:22:22Z<p>Const: removed broken link http://glide.stanford.edu/lxr/source/</p>
<hr />
<div>This page has references to various kernel resources (web sites and mailing lists) for developers.<br />
Most of this information was gathered over a year ago, and may not be accurate.<br />
<br />
/\ ''Note: You should always look at the kernel MAINTAINERS file for up-to-date information''<br />
<br />
<br />
<br />
== main (x86) kernel ==<br />
- web site = http://www.kernel.org/<br />
- [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary Linus' Git Repository]<br />
<br />
=== Mailing List (lkml) ===<br />
{| <br />
|- bgcolor="80c0c0"<br />
| align="center" | '''Item''' <br />
| align="center" | '''Link'''<br />
|- <br />
| List E-mail Address <br />
| linux-kernel@vger.kernel.org<br />
|- <br />
| Subscriptions (List Home) <br />
| http://vger.kernel.org/majordomo-info.html<br />
|- <br />
| Archives (Aims Group) <br />
| http://marc.theaimsgroup.com/?l=linux-kernel<br />
|- <br />
| Archives (lkml.org) <br />
| http://lkml.org/<br />
|- <br />
| Archives (as a Google group) <br />
| http://www.google.com/groups?hl=en&lr=&ie=UTF-8&group=linux.kernel<br />
|- <br />
| Archives (at Indiana University) <br />
| http://www.ussg.iu.edu/hypermail/<br />
|- <br />
| Google search of Ind. Univ. archives of LKML <br />
| [http://www.uwsg.iu.edu/search/?scope=kernel Search]<br />
|- <br />
| Summaries - (Kernel Traffic) <br />
| http://kt.zork.net/kernel-traffic/index.html<br />
|- <br />
| Latest summary <br />
| [http://kt.zork.net/kernel-traffic/latest.html latest kernel-traffic issue]<br />
|}<br />
<br />
=== Repository access ===<br />
{| <br />
|- bgcolor="80c0c0"<br />
| align="center" | '''Item''' <br />
| align="center" | '''Link'''<br />
|- <br />
| www.kernel.org<br />
| http://www.kernel.org/git/<br />
|}<br />
<br />
=== News ===<br />
- Linux Weekly News, Kernel page - http://lwn.net/Kernel/<br />
=== Changelog ===<br />
* Comprehensible changelog of the linux kernel<br />
** http://wiki.kernelnewbies.org/LinuxChanges<br />
<br />
* Announcemnts from linus<br />
** 2.6.3 http://lwn.net/Articles/71670/<br />
** 2.6.10 http://lwn.net/Articles/117188/<br />
** 2.6.12 http://lwn.net/Articles/140441/<br />
** 2.6.13 http://lwn.net/Articles/149480/<br />
** 2.6.14 http://lwn.net/Articles/157474/<br />
** 2.6.15 http://lwn.net/Articles/166131/<br />
<br />
* LWN atricles for spcific releases<br />
** 2.6.3 http://lwn.net/Articles/71669/<br />
** 2.6.10 http://lwn.net/Articles/117187/<br />
** 2.6.12 http://lwn.net/Articles/140165/<br />
** 2.6.15 http://lwn.net/Articles/166130/<br />
<br />
* LWN aricles on 2.6 API changes<br />
** 2.6 API changes http://lwn.net/Articles/2.6-kernel-api/<br />
** 2.6.12 API changes http://lwn.net/Articles/140164/<br />
<br />
== Architecture Sites ==<br />
=== MIPS ===<br />
- web site = http://www.linux-mips.org/wiki/Main_Page<br />
- mailing list = http://www.linux-mips.org/wiki/Net_Resources#Mailing_lists<br />
- Maintainer = Ralph Baechle<br />
<br />
- there's an alternate site on [[Source Forge]]<br />
- the site is: http://sourceforge.net/projects/linux-mips<br />
- Note that this is used for experimental stuff that hasn't been merged<br />
into the official mips tree by Ralph Baechle<br />
<br />
=== ARM ===<br />
- web site = http://www.arm.linux.org.uk/<br />
- cvs access = http://cvs.arm.linux.org.uk/<br />
- mailing list = http://www.arm.linux.org.uk/armlinux/mailinglists.php<br />
- wiki = http://www.linux-arm.org/<br />
- Maintainer = Russell King<br />
<br />
=== [[PowerPC]] ===<br />
- web site = http://penguinppc.org/<br />
- mailing lists = http://penguinppc.org/about/community.php#lists<br />
- Git repository = kernel.org:/pub/scm/linux/kernel/git/paulus/powerpc.git<br />
- Maintainer = Paul Mackerras<br />
- [[Power Macintosh]] Maintainer = Benjamin Herrenschmidt<br />
<br />
- cross-compiler mini-howto: http://penguinppc.org/embedded/cross-compiling/<br />
<br />
See the following for information on different linuxppc source trees available:<br />
http://www.penguinppc.org/dev/kernel.shtml<br />
=== SuperH (SH) ===<br />
- web site = http://www.linux-sh.org/<br />
- Git repository = kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git<br />
- mailing list address = linux-sh@vger.kernel.org<br />
- mailing list page = http://vger.kernel.org/vger-lists.html#linux-sh<br />
- mailing list archives = http://news.gmane.org/gmane.linux.ports.sh.devel<br />
- wiki = http://linux-sh.org/shwiki/FrontPage<br />
- Maintainer = Paul Mundt<br />
<br />
<br />
== Documentation ==<br />
<br />
=== Online ===<br />
- Rusty Russell's "Unreliable Guide to Locking" - http://kernelbook.sourceforge.net/kernel-locking.html<br />
- Embedded Linux kernel and driver development - http://free-electrons.com/training/drivers<br />
- Linux USB drivers - http://free-electrons.com/articles/linux-usb<br />
<br />
=== Books ===<br />
* ''Linux Kernel Developmen''t by Robert Love<br />
** Good introduction to Linux kernel development<br />
* ''Linux Device Drivers'' by Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman<br />
** Great book for getting started with Linux device drivers<br />
** Free online edition: http://lwn.net/images/pdf/LDD3/<br />
* ''Essential Linux Device Drivers'' by Sreekrishnan Venkateswaran<br />
** Introduction to driver development for major subsystems<br />
* ''Professional Linux Kernel Architecture'' by Wolfgang Mauerer<br />
** Introduction to the architecture, concepts and algorithms of the Linux kernel<br />
* ''Understanding the Linux Kernel'' by Daniel Bovet and Marco Cesati<br />
** Guided tour of the code that forms the core of all Linux operating systems<br />
* ''Linux Kernel in a Nutshell'' by Greg Kroah-Hartman<br />
** Overview of kernel configuration and building<br />
** Free online edition: http://www.kroah.com/lkn/<br />
<br />
== Cross-reference / code online ==<br />
* http://www.makelinux.net/kernel_map<br />
* http://www.linux-m32r.org/lxr/http/source/<br />
* http://lxr.free-electrons.com/<br />
* http://sosdg.org/~coywolf/lxr/source/<br />
* http://lxr.linux.no/source/<br />
<br />
[[Category:Development Tools]]</div>Consthttp://elinux.org/Linux_Kernel_ResourcesLinux Kernel Resources2008-06-19T21:19:05Z<p>Const: /* Cross-reference / code online */ + interactive linux kernel map</p>
<hr />
<div>This page has references to various kernel resources (web sites and mailing lists) for developers.<br />
Most of this information was gathered over a year ago, and may not be accurate.<br />
<br />
/\ ''Note: You should always look at the kernel MAINTAINERS file for up-to-date information''<br />
<br />
<br />
<br />
== main (x86) kernel ==<br />
- web site = http://www.kernel.org/<br />
- [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary Linus' Git Repository]<br />
- kernel cross-reference online: http://glide.stanford.edu/lxr/source/ (only some version available)<br />
<br />
=== Mailing List (lkml) ===<br />
{| <br />
|- bgcolor="80c0c0"<br />
| align="center" | '''Item''' <br />
| align="center" | '''Link'''<br />
|- <br />
| List E-mail Address <br />
| linux-kernel@vger.kernel.org<br />
|- <br />
| Subscriptions (List Home) <br />
| http://vger.kernel.org/majordomo-info.html<br />
|- <br />
| Archives (Aims Group) <br />
| http://marc.theaimsgroup.com/?l=linux-kernel<br />
|- <br />
| Archives (lkml.org) <br />
| http://lkml.org/<br />
|- <br />
| Archives (as a Google group) <br />
| http://www.google.com/groups?hl=en&lr=&ie=UTF-8&group=linux.kernel<br />
|- <br />
| Archives (at Indiana University) <br />
| http://www.ussg.iu.edu/hypermail/<br />
|- <br />
| Google search of Ind. Univ. archives of LKML <br />
| [http://www.uwsg.iu.edu/search/?scope=kernel Search]<br />
|- <br />
| Summaries - (Kernel Traffic) <br />
| http://kt.zork.net/kernel-traffic/index.html<br />
|- <br />
| Latest summary <br />
| [http://kt.zork.net/kernel-traffic/latest.html latest kernel-traffic issue]<br />
|}<br />
<br />
=== Repository access ===<br />
{| <br />
|- bgcolor="80c0c0"<br />
| align="center" | '''Item''' <br />
| align="center" | '''Link'''<br />
|- <br />
| www.kernel.org<br />
| http://www.kernel.org/git/<br />
|}<br />
<br />
=== News ===<br />
- Linux Weekly News, Kernel page - http://lwn.net/Kernel/<br />
=== Changelog ===<br />
* Comprehensible changelog of the linux kernel<br />
** http://wiki.kernelnewbies.org/LinuxChanges<br />
<br />
* Announcemnts from linus<br />
** 2.6.3 http://lwn.net/Articles/71670/<br />
** 2.6.10 http://lwn.net/Articles/117188/<br />
** 2.6.12 http://lwn.net/Articles/140441/<br />
** 2.6.13 http://lwn.net/Articles/149480/<br />
** 2.6.14 http://lwn.net/Articles/157474/<br />
** 2.6.15 http://lwn.net/Articles/166131/<br />
<br />
* LWN atricles for spcific releases<br />
** 2.6.3 http://lwn.net/Articles/71669/<br />
** 2.6.10 http://lwn.net/Articles/117187/<br />
** 2.6.12 http://lwn.net/Articles/140165/<br />
** 2.6.15 http://lwn.net/Articles/166130/<br />
<br />
* LWN aricles on 2.6 API changes<br />
** 2.6 API changes http://lwn.net/Articles/2.6-kernel-api/<br />
** 2.6.12 API changes http://lwn.net/Articles/140164/<br />
<br />
== Architecture Sites ==<br />
=== MIPS ===<br />
- web site = http://www.linux-mips.org/wiki/Main_Page<br />
- mailing list = http://www.linux-mips.org/wiki/Net_Resources#Mailing_lists<br />
- Maintainer = Ralph Baechle<br />
<br />
- there's an alternate site on [[Source Forge]]<br />
- the site is: http://sourceforge.net/projects/linux-mips<br />
- Note that this is used for experimental stuff that hasn't been merged<br />
into the official mips tree by Ralph Baechle<br />
<br />
=== ARM ===<br />
- web site = http://www.arm.linux.org.uk/<br />
- cvs access = http://cvs.arm.linux.org.uk/<br />
- mailing list = http://www.arm.linux.org.uk/armlinux/mailinglists.php<br />
- wiki = http://www.linux-arm.org/<br />
- Maintainer = Russell King<br />
<br />
=== [[PowerPC]] ===<br />
- web site = http://penguinppc.org/<br />
- mailing lists = http://penguinppc.org/about/community.php#lists<br />
- Git repository = kernel.org:/pub/scm/linux/kernel/git/paulus/powerpc.git<br />
- Maintainer = Paul Mackerras<br />
- [[Power Macintosh]] Maintainer = Benjamin Herrenschmidt<br />
<br />
- cross-compiler mini-howto: http://penguinppc.org/embedded/cross-compiling/<br />
<br />
See the following for information on different linuxppc source trees available:<br />
http://www.penguinppc.org/dev/kernel.shtml<br />
=== SuperH (SH) ===<br />
- web site = http://www.linux-sh.org/<br />
- Git repository = kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git<br />
- mailing list address = linux-sh@vger.kernel.org<br />
- mailing list page = http://vger.kernel.org/vger-lists.html#linux-sh<br />
- mailing list archives = http://news.gmane.org/gmane.linux.ports.sh.devel<br />
- wiki = http://linux-sh.org/shwiki/FrontPage<br />
- Maintainer = Paul Mundt<br />
<br />
<br />
== Documentation ==<br />
- Linux Device Drivers - 3rd Edition, online - http://lwn.net/images/pdf/LDD3/<br />
- Rusty Russell's "Unreliable Guide to Locking" - http://kernelbook.sourceforge.net/kernel-locking.html<br />
<br />
== Cross-reference / code online ==<br />
* http://www.makelinux.net/kernel_map<br />
* http://www.linux-m32r.org/lxr/http/source/<br />
* http://lxr.free-electrons.com/<br />
* http://sosdg.org/~coywolf/lxr/source/<br />
* http://lxr.linux.no/source/<br />
<br />
[[Category:Development Tools]]</div>Const