* Re: New fast(?)-boot results on ARM
From: Dirk Behme @ 2009-08-18 15:31 UTC (permalink / raw)
To: Sascha Hauer
Cc: Robert Schwebel, linux-kernel, linux-embedded, Arjan van de Ven,
Tim Bird, kernel
In-Reply-To: <20090818140605.GB9943@pengutronix.de>
Sascha Hauer wrote:
> On Fri, Aug 14, 2009 at 07:02:28PM +0200, Robert Schwebel wrote:
>> Hi,
>>
>> On Thu, Aug 13, 2009 at 05:33:26PM +0200, Robert Schwebel wrote:
>>> On Thu, Aug 13, 2009 at 08:28:26AM -0700, Arjan van de Ven wrote:
>>>>> That's bad :-) So there is no room for improvement any more in our
>>>>> ARM boot sequences ...
>>>> on x86 we're doing pretty well ;-)
>>> On i.MX27 (400 MHz ARM926EJ-S) we currently need 7 s, measured from
>>> power-on through the kernel up to "starting init". This is with
>>>
>>> - no delay in u-boot-v2
>>> - rootfs on NAND (UBIFS)
>>> - quiet
>>> - precalculated loops-per-jiffy
>>> - zImage kernel instead of uImage
>> Here's a little video of our demo system booting:
>> http://www.youtube.com/watch?v=xDbUnNsj0cI
>>
>> As you can see there, it needs about 15 s from the release of the reset button
>> up to the moment where the application shows it's Qt 4.5.2 based GUI (which is
>> when we fade over from the initial framebuffer to the final one, in order to
>> hide the qt application startup noise).
>>
>> And below is the boot log (after turning "quiet" off again). The numbers are
>> the timestamp and the delta to the last timestamp, measured on the controlling
>> PC by looking at the serial console output. The ptx_ts script starts when the
>> regexp was found, so the numbers start basically in the moment when u-boot-v2
>> has initialized the system up to the point where we can see something.
>>
>> Result:
>>
>> - 2.4 s up from u-boot to the end of "Uncompressing Linux"
>> - 300 ms until ubifs initialization starts
>> - 3.7 s for ubifs, until "mounted root"
>>
>> So we basically have 7 s for the kernel. The rest is userspace, which hasn't
>> seen much optimization yet, other than trying to start the GUI application as
>> early as possible, while doing all other init stuff in parallel. Adding "quiet"
>> brings us another 300 ms.
>>
>> That's factor 70 away from the 110 ms boot time Tim has talked about some days
>> ago (and he measured on an ARM cpu which had almost half the speed of this
>> one), and I'm wondering what we can do to improve the boot time.
>>
>> Robert
>>
>> rsc@thebe:~$ microcom | ptx_ts "U-Boot 2.0.0-rc9"
>> [ 13.522625] < 0.043189>
>> [ 13.546627] < 0.024002> OSELAS(R)-phyCORE-trunk (PTXdist-1.99.svn/2009-08-06T08:37:25+0200)
>> [ 13.558613] < 0.011986>
>> [ 13.690643] < 0.132030> _ ____ ___ ____ _____
>> [ 13.690731] < 0.000088> _ __ | |__ _ _ / ___/ _ \| _ \| ____|
>> [ 13.698595] < 0.007864> | '_ \| '_ \| | | | | | | | | |_) | _|
>> [ 13.698654] < 0.000059> | |_) | | | | |_| | |__| |_| | _ <| |___
>> [ 13.702581] < 0.003927> | .__/|_| |_|\__, |\____\___/|_| \_\_____|
>> [ 13.706573] < 0.003992> |_| |___/
>> [ 13.706622] < 0.000049>
>> [ 13.725043] < 0.018421>
>> [ 14.742608] < 1.017565>
>
> I made some changes suggested in this thread:
>
> - enable MMU in the bootloader
> - use assembler optimized memcpy/memset in the bootloader
> - start an uncompressed image
> - disable IP autoconfiguration in the Kernel
> - use lpj= command line parameter
> - use static device nodes instead of udev
> - skip some init scripts
> - made the kernel smaller (I do not have both configs handy, so I do not
> know what exactly I changed)
>
> Already looks much better:
>
> [ 0.000005] < 0.000005> U-Boot 2.0.0-rc10-00241-g3f10fe9-dirty (Aug 18 2009 - 13:29:25)
> [ 0.000026] < 0.000021>
> [ 0.000041] < 0.000015> Board: Phytec phyCORE-i.MX27
> [ 0.000054] < 0.000013> cfi_probe: cfi_flash base: 0xc0000000 size: 0x02000000
> [ 0.000067] < 0.000013> NAND device: Manufacturer ID: 0x20, Chip ID: 0x36 (ST Micro NAND 64MiB 1,8V 8-bit)
> [ 0.000080] < 0.000013> imxfb@imxfb0: i.MX Framebuffer driver
> [ 0.000092] < 0.000012> dma_alloc: 0xa6f56e40 0x10000000
> [ 0.000105] < 0.000013> dma_alloc: 0xa6f57088 0x10000000
> [ 0.000118] < 0.000013> dev_protect: currently broken
> [ 0.000129] < 0.000011> Using environment in NOR Flash
> [ 0.000141] < 0.000012> initialising PLLs
> [ 0.128972] < 0.128831> Malloc space: 0xa6f00000 -> 0xa7f00000 (size 16 MB)
> [ 0.128995] < 0.000023> Stack space : 0xa6ef8000 -> 0xa6f00000 (size 32 kB)
> [ 0.129008] < 0.000013> running /env/bin/init...
> [ 0.224963] < 0.095955>
> [ 0.224984] < 0.000021> Hit any key to stop autoboot: 0
> [ 0.224999] < 0.000015> copy
> [ 0.592964] < 0.367965> done
> [ 0.652010] < 0.059046> Linux version 2.6.31-rc4-00004-g05786f8-dirty (sha@octopus) (gcc version 4.3.2 (OSELAS.Toolchain-1.99.3) ) #206 PREEMPT Tue Aug 18 14:08:51 CEST 2009
So, this are ~0.6 s in boot loader and kernel copy until kernel
starts, correct?
What's the size of the uncompressed kernel copied here?
Best regards
Dirk
Btw.: I tried to summarize some hints given in this thread in
http://elinux.org/Boot_Time#Boot_time_check_list
Please feel free to add and correct stuff!
> [ 0.652030] < 0.000020> CPU: ARM926EJ-S [41069264] revision 4 (ARMv5TEJ), cr=00053177
> [ 0.652044] < 0.000014> CPU: VIVT data cache, VIVT instruction cache
> [ 0.652057] < 0.000013> Machine: phyCORE-i.MX27
> [ 0.652069] < 0.000012> Memory policy: ECC disabled, Data cache writeback
> [ 0.652082] < 0.000013> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
> [ 0.706012] < 0.053930> Kernel command line: console=ttymxc0,115200 earlyprintk lpj=995328 mt9v022.sensor_type=color ip=192.168.23.197:192.168.23.2:192.168.23.2:255.255.0.0::: ubi.mtd=7 root=ubi0:root rootfstype=ubifs mtdparts="physmap-flash.0:256k(uboot)ro,128k(ubootenv),3M(kernel),-(root);mxc_nand:256k(uboot)ro,128k(ubootenv),3M(kernel),-(root)"
> [ 0.706034] < 0.000022> console [earlyser0] enabled
> [ 0.706049] < 0.000015> Unknown boot option `mt9v022.sensor_type=color': ignoring
> [ 0.706062] < 0.000013> PID hash table entries: 512 (order: 9, 2048 bytes)
> [ 0.706075] < 0.000013> Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
> [ 0.706087] < 0.000012> Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
> [ 0.755997] < 0.049910> Memory: 128MB = 128MB total
> [ 0.756016] < 0.000019> Memory: 127004KB available (2404K code, 205K data, 80K init, 0K highmem)
> [ 0.756030] < 0.000014> NR_IRQS:272
> [ 0.756042] < 0.000012> MXC GPIO hardware
> [ 0.756055] < 0.000013> MXC IRQ initialized
> [ 0.756067] < 0.000012> Console: colour dummy device 80x30
> [ 0.756079] < 0.000012> Calibrating delay loop (skipped) preset value.. 199.06 BogoMIPS (lpj=995328)
> [ 0.756092] < 0.000013> Mount-cache hash table entries: 512
> [ 0.756104] < 0.000012> CPU: Testing write buffer coherency: ok
> [ 0.771968] < 0.015864> NET: Registered protocol family 16
> [ 0.803967] < 0.031999> bio: create slab <bio-0> at 0
> [ 0.869007] < 0.065040> NET: Registered protocol family 2
> [ 0.869025] < 0.000018> IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
> [ 0.869040] < 0.000015> TCP established hash table entries: 4096 (order: 3, 32768 bytes)
> [ 0.869053] < 0.000013> TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
> [ 0.869066] < 0.000013> TCP: Hash tables configured (established 4096 bind 4096)
> [ 0.869078] < 0.000012> TCP reno registered
> [ 0.869090] < 0.000012> NET: Registered protocol family 1
> [ 0.869103] < 0.000013> msgmni has been set to 248
> [ 0.869115] < 0.000012> io scheduler noop registered (default)
> [ 0.869127] < 0.000012> i.MX Framebuffer driver
> [ 0.884970] < 0.015843> Console: switching to colour frame buffer device 30x40
> [ 0.974022] < 0.089052> Serial: IMX driver
> [ 0.974127] < 0.000105> Platform driver 'imx-uart' needs updating - please use dev_pm_ops
> [ 0.974217] < 0.000090> imx-uart.0: ttymxc0 at MMIO 0x1000a000 (irq = 20) is a IMX
> [ 0.974306] < 0.000089> console handover: boot [earlyser0] -> real [ttymxc0]
> [ 0.974392] < 0.000086> imx-uart.1: ttymxc1 at MMIO 0x1000b000 (irq = 19) is a IMX
> [ 0.974481] < 0.000089> imx-uart.2: ttymxc2 at MMIO 0x1000c000 (irq = 18) is a IMX
> [ 0.974569] < 0.000088> FEC Ethernet Driver
> [ 0.974651] < 0.000082> Platform driver 'fec' needs updating - please use dev_pm_ops
> [ 0.974737] < 0.000086> fec: PHY @ 0x0, ID 0x00221613 -- KS8721BL
> [ 1.019018] < 0.044281> physmap platform flash device: 02000000 at c0000000
> [ 1.019118] < 0.000100> physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank
> [ 1.019207] < 0.000089> Intel/Sharp Extended Query Table at 0x010A
> [ 1.019293] < 0.000086> Intel/Sharp Extended Query Table at 0x010A
> [ 1.019377] < 0.000084> Intel/Sharp Extended Query Table at 0x010A
> [ 1.019460] < 0.000083> Intel/Sharp Extended Query Table at 0x010A
> [ 1.019544] < 0.000084> Intel/Sharp Extended Query Table at 0x010A
> [ 1.019627] < 0.000083> Using buffer write method
> [ 1.019714] < 0.000087> Using auto-unlock on power-up/resume
> [ 1.019797] < 0.000083> cfi_cmdset_0001: Erase suspend on write enabled
> [ 1.019881] < 0.000084> 4 cmdlinepart partitions found on MTD device physmap-flash.0
> [ 1.082018] < 0.062137> Creating 4 MTD partitions on "physmap-flash.0":
> [ 1.082112] < 0.000094> 0x000000000000-0x000000040000 : "uboot"
> [ 1.082199] < 0.000087> 0x000000040000-0x000000060000 : "ubootenv"
> [ 1.082287] < 0.000088> 0x000000060000-0x000000360000 : "kernel"
> [ 1.082371] < 0.000084> 0x000000360000-0x000002000000 : "root"
> [ 1.082453] < 0.000082> NAND device: Manufacturer ID: 0x20, Chip ID: 0x36 (ST Micro NAND 64MiB 1,8V 8-bit)
> [ 1.082543] < 0.000090> RedBoot partition parsing not available
> [ 1.082627] < 0.000084> 4 cmdlinepart partitions found on MTD device mxc_nand
> [ 1.082715] < 0.000088> Creating 4 MTD partitions on "mxc_nand":
> [ 1.082798] < 0.000083> 0x000000000000-0x000000040000 : "uboot"
> [ 1.082882] < 0.000084> 0x000000040000-0x000000060000 : "ubootenv"
> [ 1.097976] < 0.015094> 0x000000060000-0x000000360000 : "kernel"
> [ 1.113978] < 0.016002> 0x000000360000-0x000004000000 : "root"
> [ 1.425012] < 0.311034> UBI: attaching mtd7 to ubi0
> [ 1.425043] < 0.000031> UBI: physical eraseblock size: 16384 bytes (16 KiB)
> [ 1.425057] < 0.000014> UBI: logical eraseblock size: 15360 bytes
> [ 1.425071] < 0.000014> UBI: smallest flash I/O unit: 512
> [ 1.425083] < 0.000012> UBI: VID header offset: 512 (aligned 512)
> [ 1.425096] < 0.000013> UBI: data offset: 1024
> [ 3.008058] < 1.582962> UBI: attached mtd7 to ubi0
> [ 3.008090] < 0.000032> UBI: MTD device name: "root"
> [ 3.008105] < 0.000015> UBI: MTD device size: 60 MiB
> [ 3.008119] < 0.000014> UBI: number of good PEBs: 3880
> [ 3.008132] < 0.000013> UBI: number of bad PEBs: 0
> [ 3.008145] < 0.000013> UBI: max. allowed volumes: 89
> [ 3.008159] < 0.000014> UBI: wear-leveling threshold: 4096
> [ 3.008172] < 0.000013> UBI: number of internal volumes: 1
> [ 3.008185] < 0.000013> UBI: number of user volumes: 1
> [ 3.008199] < 0.000014> UBI: available PEBs: 0
> [ 3.008212] < 0.000013> UBI: total number of reserved PEBs: 3880
> [ 3.008226] < 0.000014> UBI: number of PEBs reserved for bad PEB handling: 38
> [ 3.051029] < 0.042803> UBI: max/mean erase counter: 2/0
> [ 3.051052] < 0.000023> UBI: image sequence number: 0
> [ 3.051066] < 0.000014> UBI: background thread "ubi_bgt0d" started, PID 218
> [ 3.051081] < 0.000015> i2c /dev entries driver
> [ 3.051094] < 0.000013> rtc-pcf8563 1-0051: chip found, driver version 0.4.3
> [ 3.051108] < 0.000014> rtc-pcf8563 1-0051: rtc core: registered rtc-pcf8563 as rtc0
> [ 3.051122] < 0.000014> Driver for 1-wire Dallas network protocol.
> [ 3.148042] < 0.096920> i.MX SDHC driver
> [ 3.148067] < 0.000025> mxc-mmc: probe of mxc-mmc.1 failed with error -16
> [ 3.148082] < 0.000015> TCP cubic registered
> [ 3.148095] < 0.000013> NET: Registered protocol family 17
> [ 3.148107] < 0.000012> RPC: Registered udp transport module.
> [ 3.148119] < 0.000012> RPC: Registered tcp transport module.
> [ 3.148132] < 0.000013> rtc-pcf8563 1-0051: low voltage detected, date/time is not reliable.
> [ 3.148145] < 0.000013> rtc-pcf8563 1-0051: retrieved date/time is not valid.
> [ 3.148157] < 0.000012> rtc-pcf8563 1-0051: hctosys: invalid date/time
> [ 3.148170] < 0.000013> UBIFS: recovery needed
> [ 3.211043] < 0.062873> UBIFS: recovery completed
> [ 3.211064] < 0.000021> UBIFS: mounted UBI device 0, volume 1, name "root"
> [ 3.211080] < 0.000016> UBIFS: file system size: 58490880 bytes (57120 KiB, 55 MiB, 3808 LEBs)
> [ 3.211093] < 0.000013> UBIFS: journal size: 7741440 bytes (7560 KiB, 7 MiB, 504 LEBs)
> [ 3.211105] < 0.000012> UBIFS: media format: w4/r0 (latest is w4/r0)
> [ 3.211118] < 0.000013> UBIFS: default compressor: lzo
> [ 3.211130] < 0.000012> UBIFS: reserved for root: 0 bytes (0 KiB)
> [ 3.211143] < 0.000013> VFS: Mounted root (ubifs filesystem) on device 0:12.
> [ 3.211155] < 0.000012> Freeing init memory: 80K
> init started: BusyBox v1.13.4 (2009-08-06 08:30:14 CEST)
> [ 3.514007] < 0.159993> mounting filesystems...done.
> [ 3.546005] < 0.031998> running rc.d services...
> [ 3.626007] < 0.080002> syslogd starting
> [ 3.786013] < 0.160006> Starting telnetd...
> [ 3.962014] < 0.176001> starting network interfaces...
> [ 4.818032] < 0.856018> eth0: config: auto-negotiation on, 100FDX, 100HDX, 10FDX, 10HDX.
> [ 5.058038] < 0.240006> ip: cannot find device "can0"
> [ 5.250040] < 0.192002> ip: SIOCGIFFLAGS: No such device
> [ 5.298033] < 0.047993>
> [ 5.336039] < 0.038006> OSELAS(R)-phyCORE-trunk (PTXdist-1.99.svn/2009-08-06T08:37:25+0200)
> [ 5.368028] < 0.031989>
> [ 5.840066] < 0.472038> _ ____ ___ ____ _____
> [ 5.840090] < 0.000024> _ __ | |__ _ _ / ___/ _ \| _ \| ____|
> [ 5.840104] < 0.000014> | '_ \| '_ \| | | | | | | | | |_) | _|
> [ 5.840116] < 0.000012> | |_) | | | | |_| | |__| |_| | _ <| |___
> [ 5.840129] < 0.000013> | .__/|_| |_|\__, |\____\___/|_| \_\_____|
> [ 5.840141] < 0.000012> |_| |___/
> [ 5.840154] < 0.000013>
>
> Sascha
>
^ permalink raw reply
* Re: New fast(?)-boot results on ARM
From: Sascha Hauer @ 2009-08-18 14:06 UTC (permalink / raw)
To: Robert Schwebel
Cc: linux-kernel, linux-embedded, Arjan van de Ven, Tim Bird, kernel
In-Reply-To: <20090814170228.GM13320@pengutronix.de>
On Fri, Aug 14, 2009 at 07:02:28PM +0200, Robert Schwebel wrote:
> Hi,
>
> On Thu, Aug 13, 2009 at 05:33:26PM +0200, Robert Schwebel wrote:
> > On Thu, Aug 13, 2009 at 08:28:26AM -0700, Arjan van de Ven wrote:
> > > > That's bad :-) So there is no room for improvement any more in our
> > > > ARM boot sequences ...
> > >
> > > on x86 we're doing pretty well ;-)
> >
> > On i.MX27 (400 MHz ARM926EJ-S) we currently need 7 s, measured from
> > power-on through the kernel up to "starting init". This is with
> >
> > - no delay in u-boot-v2
> > - rootfs on NAND (UBIFS)
> > - quiet
> > - precalculated loops-per-jiffy
> > - zImage kernel instead of uImage
>
> Here's a little video of our demo system booting:
> http://www.youtube.com/watch?v=xDbUnNsj0cI
>
> As you can see there, it needs about 15 s from the release of the reset button
> up to the moment where the application shows it's Qt 4.5.2 based GUI (which is
> when we fade over from the initial framebuffer to the final one, in order to
> hide the qt application startup noise).
>
> And below is the boot log (after turning "quiet" off again). The numbers are
> the timestamp and the delta to the last timestamp, measured on the controlling
> PC by looking at the serial console output. The ptx_ts script starts when the
> regexp was found, so the numbers start basically in the moment when u-boot-v2
> has initialized the system up to the point where we can see something.
>
> Result:
>
> - 2.4 s up from u-boot to the end of "Uncompressing Linux"
> - 300 ms until ubifs initialization starts
> - 3.7 s for ubifs, until "mounted root"
>
> So we basically have 7 s for the kernel. The rest is userspace, which hasn't
> seen much optimization yet, other than trying to start the GUI application as
> early as possible, while doing all other init stuff in parallel. Adding "quiet"
> brings us another 300 ms.
>
> That's factor 70 away from the 110 ms boot time Tim has talked about some days
> ago (and he measured on an ARM cpu which had almost half the speed of this
> one), and I'm wondering what we can do to improve the boot time.
>
> Robert
>
> rsc@thebe:~$ microcom | ptx_ts "U-Boot 2.0.0-rc9"
> [ 13.522625] < 0.043189>
> [ 13.546627] < 0.024002> OSELAS(R)-phyCORE-trunk (PTXdist-1.99.svn/2009-08-06T08:37:25+0200)
> [ 13.558613] < 0.011986>
> [ 13.690643] < 0.132030> _ ____ ___ ____ _____
> [ 13.690731] < 0.000088> _ __ | |__ _ _ / ___/ _ \| _ \| ____|
> [ 13.698595] < 0.007864> | '_ \| '_ \| | | | | | | | | |_) | _|
> [ 13.698654] < 0.000059> | |_) | | | | |_| | |__| |_| | _ <| |___
> [ 13.702581] < 0.003927> | .__/|_| |_|\__, |\____\___/|_| \_\_____|
> [ 13.706573] < 0.003992> |_| |___/
> [ 13.706622] < 0.000049>
> [ 13.725043] < 0.018421>
> [ 14.742608] < 1.017565>
I made some changes suggested in this thread:
- enable MMU in the bootloader
- use assembler optimized memcpy/memset in the bootloader
- start an uncompressed image
- disable IP autoconfiguration in the Kernel
- use lpj= command line parameter
- use static device nodes instead of udev
- skip some init scripts
- made the kernel smaller (I do not have both configs handy, so I do not
know what exactly I changed)
Already looks much better:
[ 0.000005] < 0.000005> U-Boot 2.0.0-rc10-00241-g3f10fe9-dirty (Aug 18 2009 - 13:29:25)
[ 0.000026] < 0.000021>
[ 0.000041] < 0.000015> Board: Phytec phyCORE-i.MX27
[ 0.000054] < 0.000013> cfi_probe: cfi_flash base: 0xc0000000 size: 0x02000000
[ 0.000067] < 0.000013> NAND device: Manufacturer ID: 0x20, Chip ID: 0x36 (ST Micro NAND 64MiB 1,8V 8-bit)
[ 0.000080] < 0.000013> imxfb@imxfb0: i.MX Framebuffer driver
[ 0.000092] < 0.000012> dma_alloc: 0xa6f56e40 0x10000000
[ 0.000105] < 0.000013> dma_alloc: 0xa6f57088 0x10000000
[ 0.000118] < 0.000013> dev_protect: currently broken
[ 0.000129] < 0.000011> Using environment in NOR Flash
[ 0.000141] < 0.000012> initialising PLLs
[ 0.128972] < 0.128831> Malloc space: 0xa6f00000 -> 0xa7f00000 (size 16 MB)
[ 0.128995] < 0.000023> Stack space : 0xa6ef8000 -> 0xa6f00000 (size 32 kB)
[ 0.129008] < 0.000013> running /env/bin/init...
[ 0.224963] < 0.095955>
[ 0.224984] < 0.000021> Hit any key to stop autoboot: 0
[ 0.224999] < 0.000015> copy
[ 0.592964] < 0.367965> done
[ 0.652010] < 0.059046> Linux version 2.6.31-rc4-00004-g05786f8-dirty (sha@octopus) (gcc version 4.3.2 (OSELAS.Toolchain-1.99.3) ) #206 PREEMPT Tue Aug 18 14:08:51 CEST 2009
[ 0.652030] < 0.000020> CPU: ARM926EJ-S [41069264] revision 4 (ARMv5TEJ), cr=00053177
[ 0.652044] < 0.000014> CPU: VIVT data cache, VIVT instruction cache
[ 0.652057] < 0.000013> Machine: phyCORE-i.MX27
[ 0.652069] < 0.000012> Memory policy: ECC disabled, Data cache writeback
[ 0.652082] < 0.000013> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
[ 0.706012] < 0.053930> Kernel command line: console=ttymxc0,115200 earlyprintk lpj=995328 mt9v022.sensor_type=color ip=192.168.23.197:192.168.23.2:192.168.23.2:255.255.0.0::: ubi.mtd=7 root=ubi0:root rootfstype=ubifs mtdparts="physmap-flash.0:256k(uboot)ro,128k(ubootenv),3M(kernel),-(root);mxc_nand:256k(uboot)ro,128k(ubootenv),3M(kernel),-(root)"
[ 0.706034] < 0.000022> console [earlyser0] enabled
[ 0.706049] < 0.000015> Unknown boot option `mt9v022.sensor_type=color': ignoring
[ 0.706062] < 0.000013> PID hash table entries: 512 (order: 9, 2048 bytes)
[ 0.706075] < 0.000013> Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.706087] < 0.000012> Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.755997] < 0.049910> Memory: 128MB = 128MB total
[ 0.756016] < 0.000019> Memory: 127004KB available (2404K code, 205K data, 80K init, 0K highmem)
[ 0.756030] < 0.000014> NR_IRQS:272
[ 0.756042] < 0.000012> MXC GPIO hardware
[ 0.756055] < 0.000013> MXC IRQ initialized
[ 0.756067] < 0.000012> Console: colour dummy device 80x30
[ 0.756079] < 0.000012> Calibrating delay loop (skipped) preset value.. 199.06 BogoMIPS (lpj=995328)
[ 0.756092] < 0.000013> Mount-cache hash table entries: 512
[ 0.756104] < 0.000012> CPU: Testing write buffer coherency: ok
[ 0.771968] < 0.015864> NET: Registered protocol family 16
[ 0.803967] < 0.031999> bio: create slab <bio-0> at 0
[ 0.869007] < 0.065040> NET: Registered protocol family 2
[ 0.869025] < 0.000018> IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.869040] < 0.000015> TCP established hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.869053] < 0.000013> TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.869066] < 0.000013> TCP: Hash tables configured (established 4096 bind 4096)
[ 0.869078] < 0.000012> TCP reno registered
[ 0.869090] < 0.000012> NET: Registered protocol family 1
[ 0.869103] < 0.000013> msgmni has been set to 248
[ 0.869115] < 0.000012> io scheduler noop registered (default)
[ 0.869127] < 0.000012> i.MX Framebuffer driver
[ 0.884970] < 0.015843> Console: switching to colour frame buffer device 30x40
[ 0.974022] < 0.089052> Serial: IMX driver
[ 0.974127] < 0.000105> Platform driver 'imx-uart' needs updating - please use dev_pm_ops
[ 0.974217] < 0.000090> imx-uart.0: ttymxc0 at MMIO 0x1000a000 (irq = 20) is a IMX
[ 0.974306] < 0.000089> console handover: boot [earlyser0] -> real [ttymxc0]
[ 0.974392] < 0.000086> imx-uart.1: ttymxc1 at MMIO 0x1000b000 (irq = 19) is a IMX
[ 0.974481] < 0.000089> imx-uart.2: ttymxc2 at MMIO 0x1000c000 (irq = 18) is a IMX
[ 0.974569] < 0.000088> FEC Ethernet Driver
[ 0.974651] < 0.000082> Platform driver 'fec' needs updating - please use dev_pm_ops
[ 0.974737] < 0.000086> fec: PHY @ 0x0, ID 0x00221613 -- KS8721BL
[ 1.019018] < 0.044281> physmap platform flash device: 02000000 at c0000000
[ 1.019118] < 0.000100> physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank
[ 1.019207] < 0.000089> Intel/Sharp Extended Query Table at 0x010A
[ 1.019293] < 0.000086> Intel/Sharp Extended Query Table at 0x010A
[ 1.019377] < 0.000084> Intel/Sharp Extended Query Table at 0x010A
[ 1.019460] < 0.000083> Intel/Sharp Extended Query Table at 0x010A
[ 1.019544] < 0.000084> Intel/Sharp Extended Query Table at 0x010A
[ 1.019627] < 0.000083> Using buffer write method
[ 1.019714] < 0.000087> Using auto-unlock on power-up/resume
[ 1.019797] < 0.000083> cfi_cmdset_0001: Erase suspend on write enabled
[ 1.019881] < 0.000084> 4 cmdlinepart partitions found on MTD device physmap-flash.0
[ 1.082018] < 0.062137> Creating 4 MTD partitions on "physmap-flash.0":
[ 1.082112] < 0.000094> 0x000000000000-0x000000040000 : "uboot"
[ 1.082199] < 0.000087> 0x000000040000-0x000000060000 : "ubootenv"
[ 1.082287] < 0.000088> 0x000000060000-0x000000360000 : "kernel"
[ 1.082371] < 0.000084> 0x000000360000-0x000002000000 : "root"
[ 1.082453] < 0.000082> NAND device: Manufacturer ID: 0x20, Chip ID: 0x36 (ST Micro NAND 64MiB 1,8V 8-bit)
[ 1.082543] < 0.000090> RedBoot partition parsing not available
[ 1.082627] < 0.000084> 4 cmdlinepart partitions found on MTD device mxc_nand
[ 1.082715] < 0.000088> Creating 4 MTD partitions on "mxc_nand":
[ 1.082798] < 0.000083> 0x000000000000-0x000000040000 : "uboot"
[ 1.082882] < 0.000084> 0x000000040000-0x000000060000 : "ubootenv"
[ 1.097976] < 0.015094> 0x000000060000-0x000000360000 : "kernel"
[ 1.113978] < 0.016002> 0x000000360000-0x000004000000 : "root"
[ 1.425012] < 0.311034> UBI: attaching mtd7 to ubi0
[ 1.425043] < 0.000031> UBI: physical eraseblock size: 16384 bytes (16 KiB)
[ 1.425057] < 0.000014> UBI: logical eraseblock size: 15360 bytes
[ 1.425071] < 0.000014> UBI: smallest flash I/O unit: 512
[ 1.425083] < 0.000012> UBI: VID header offset: 512 (aligned 512)
[ 1.425096] < 0.000013> UBI: data offset: 1024
[ 3.008058] < 1.582962> UBI: attached mtd7 to ubi0
[ 3.008090] < 0.000032> UBI: MTD device name: "root"
[ 3.008105] < 0.000015> UBI: MTD device size: 60 MiB
[ 3.008119] < 0.000014> UBI: number of good PEBs: 3880
[ 3.008132] < 0.000013> UBI: number of bad PEBs: 0
[ 3.008145] < 0.000013> UBI: max. allowed volumes: 89
[ 3.008159] < 0.000014> UBI: wear-leveling threshold: 4096
[ 3.008172] < 0.000013> UBI: number of internal volumes: 1
[ 3.008185] < 0.000013> UBI: number of user volumes: 1
[ 3.008199] < 0.000014> UBI: available PEBs: 0
[ 3.008212] < 0.000013> UBI: total number of reserved PEBs: 3880
[ 3.008226] < 0.000014> UBI: number of PEBs reserved for bad PEB handling: 38
[ 3.051029] < 0.042803> UBI: max/mean erase counter: 2/0
[ 3.051052] < 0.000023> UBI: image sequence number: 0
[ 3.051066] < 0.000014> UBI: background thread "ubi_bgt0d" started, PID 218
[ 3.051081] < 0.000015> i2c /dev entries driver
[ 3.051094] < 0.000013> rtc-pcf8563 1-0051: chip found, driver version 0.4.3
[ 3.051108] < 0.000014> rtc-pcf8563 1-0051: rtc core: registered rtc-pcf8563 as rtc0
[ 3.051122] < 0.000014> Driver for 1-wire Dallas network protocol.
[ 3.148042] < 0.096920> i.MX SDHC driver
[ 3.148067] < 0.000025> mxc-mmc: probe of mxc-mmc.1 failed with error -16
[ 3.148082] < 0.000015> TCP cubic registered
[ 3.148095] < 0.000013> NET: Registered protocol family 17
[ 3.148107] < 0.000012> RPC: Registered udp transport module.
[ 3.148119] < 0.000012> RPC: Registered tcp transport module.
[ 3.148132] < 0.000013> rtc-pcf8563 1-0051: low voltage detected, date/time is not reliable.
[ 3.148145] < 0.000013> rtc-pcf8563 1-0051: retrieved date/time is not valid.
[ 3.148157] < 0.000012> rtc-pcf8563 1-0051: hctosys: invalid date/time
[ 3.148170] < 0.000013> UBIFS: recovery needed
[ 3.211043] < 0.062873> UBIFS: recovery completed
[ 3.211064] < 0.000021> UBIFS: mounted UBI device 0, volume 1, name "root"
[ 3.211080] < 0.000016> UBIFS: file system size: 58490880 bytes (57120 KiB, 55 MiB, 3808 LEBs)
[ 3.211093] < 0.000013> UBIFS: journal size: 7741440 bytes (7560 KiB, 7 MiB, 504 LEBs)
[ 3.211105] < 0.000012> UBIFS: media format: w4/r0 (latest is w4/r0)
[ 3.211118] < 0.000013> UBIFS: default compressor: lzo
[ 3.211130] < 0.000012> UBIFS: reserved for root: 0 bytes (0 KiB)
[ 3.211143] < 0.000013> VFS: Mounted root (ubifs filesystem) on device 0:12.
[ 3.211155] < 0.000012> Freeing init memory: 80K
init started: BusyBox v1.13.4 (2009-08-06 08:30:14 CEST)
[ 3.514007] < 0.159993> mounting filesystems...done.
[ 3.546005] < 0.031998> running rc.d services...
[ 3.626007] < 0.080002> syslogd starting
[ 3.786013] < 0.160006> Starting telnetd...
[ 3.962014] < 0.176001> starting network interfaces...
[ 4.818032] < 0.856018> eth0: config: auto-negotiation on, 100FDX, 100HDX, 10FDX, 10HDX.
[ 5.058038] < 0.240006> ip: cannot find device "can0"
[ 5.250040] < 0.192002> ip: SIOCGIFFLAGS: No such device
[ 5.298033] < 0.047993>
[ 5.336039] < 0.038006> OSELAS(R)-phyCORE-trunk (PTXdist-1.99.svn/2009-08-06T08:37:25+0200)
[ 5.368028] < 0.031989>
[ 5.840066] < 0.472038> _ ____ ___ ____ _____
[ 5.840090] < 0.000024> _ __ | |__ _ _ / ___/ _ \| _ \| ____|
[ 5.840104] < 0.000014> | '_ \| '_ \| | | | | | | | | |_) | _|
[ 5.840116] < 0.000012> | |_) | | | | |_| | |__| |_| | _ <| |___
[ 5.840129] < 0.000013> | .__/|_| |_|\__, |\____\___/|_| \_\_____|
[ 5.840141] < 0.000012> |_| |___/
[ 5.840154] < 0.000013>
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: New fast(?)-boot results on ARM
From: Robert Schwebel @ 2009-08-18 10:53 UTC (permalink / raw)
To: Alex Riesen
Cc: Marco Stornelli, Johannes Stezenbach, Denys Vlasenko,
linux-kernel, linux-embedded, Arjan van de Ven, Tim Bird, kernel
In-Reply-To: <81b0412b0908180348n75af1113wb380919eaeaaf29b@mail.gmail.com>
On Tue, Aug 18, 2009 at 12:48:50PM +0200, Alex Riesen wrote:
> But many of the problems you described and suggested solutions
> point at userspace, right? (like pre-defined static /dev, mdev script,
> or using of specially designed rootfs)
Yes, right. But even there, mdev is more in the "embedded special"
league than udev, for example, and highly specialized read-only root
filesystems as well.
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: New fast(?)-boot results on ARM
From: Alex Riesen @ 2009-08-18 10:48 UTC (permalink / raw)
To: Robert Schwebel
Cc: Marco Stornelli, Johannes Stezenbach, Denys Vlasenko,
linux-kernel, linux-embedded, Arjan van de Ven, Tim Bird, kernel
In-Reply-To: <20090818104410.GO29655@pengutronix.de>
On Tue, Aug 18, 2009 at 12:44, Robert Schwebel<r.schwebel@pengutronix.de> wrote:
> On Tue, Aug 18, 2009 at 12:34:52PM +0200, Alex Riesen wrote:
>> On Tue, Aug 18, 2009 at 12:21, Robert Schwebel<r.schwebel@pengutronix.de> wrote:
>> > - In general we want to have our systems close to what the mainline
>> > does; Automation & Embedded is only a small market, and anything
>> > which is *not* specific to these markets but mainline is good.
>>
>> BTW, what is your mainline (or it looks like you mean "upstream")?
>
> unpatched kernel.org
>
But many of the problems you described and suggested solutions
point at userspace, right? (like pre-defined static /dev, mdev script,
or using of specially designed rootfs)
^ permalink raw reply
* Re: New fast(?)-boot results on ARM
From: Robert Schwebel @ 2009-08-18 10:44 UTC (permalink / raw)
To: Alex Riesen
Cc: Marco Stornelli, Johannes Stezenbach, Denys Vlasenko,
linux-kernel, linux-embedded, Arjan van de Ven, Tim Bird, kernel
In-Reply-To: <81b0412b0908180334u51fd957dh36f2a4946dffbb0b@mail.gmail.com>
On Tue, Aug 18, 2009 at 12:34:52PM +0200, Alex Riesen wrote:
> On Tue, Aug 18, 2009 at 12:21, Robert Schwebel<r.schwebel@pengutronix.de> wrote:
> > - In general we want to have our systems close to what the mainline
> > does; Automation & Embedded is only a small market, and anything
> > which is *not* specific to these markets but mainline is good.
>
> BTW, what is your mainline (or it looks like you mean "upstream")?
unpatched kernel.org
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: New fast(?)-boot results on ARM
From: Alex Riesen @ 2009-08-18 10:34 UTC (permalink / raw)
To: Robert Schwebel
Cc: Marco Stornelli, Johannes Stezenbach, Denys Vlasenko,
linux-kernel, linux-embedded, Arjan van de Ven, Tim Bird, kernel
In-Reply-To: <20090818102136.GN29655@pengutronix.de>
On Tue, Aug 18, 2009 at 12:21, Robert Schwebel<r.schwebel@pengutronix.de> wrote:
> - In general we want to have our systems close to what the mainline
> does; Automation & Embedded is only a small market, and anything
> which is *not* specific to these markets but mainline is good.
BTW, what is your mainline (or it looks like you mean "upstream")?
^ permalink raw reply
* Re: New fast(?)-boot results on ARM
From: Robert Schwebel @ 2009-08-18 10:21 UTC (permalink / raw)
To: Marco Stornelli
Cc: Johannes Stezenbach, Denys Vlasenko, linux-kernel, linux-embedded,
Arjan van de Ven, Tim Bird, kernel
In-Reply-To: <4A8A7D38.5020201@gmail.com>
Marco,
On Tue, Aug 18, 2009 at 12:06:48PM +0200, Marco Stornelli wrote:
> Yeah, I agree, do you really need udevd, device file creation at every
> start-up in /dev? Usually static devices nodes and mdev for hotplug are
> enough or at least you could use a simple script to create only once
> time the devices file (mdev -s). About the fs, do you really need a
> rootfs with ubifs? I mean, you could "split" your fs. You could use a
> read-only fs (SquashFS for example) for your root-fs, ubifs for
> permanent storage data (mounted under /data for example) and a ram fs
> for volatile data.
Well, we try to find out what is possible with a fast booting Linux
system which *still* is as "vanilla" as possible.
All the "boot-in-one-second" systems out there are highly squeezed,
which is surely good if you have a scenario with high production
volumes. You can do the optimization in the last steps then and it
doesn't really matter how much time you spend with testing to come from
a system that works for a developer to a production system.
For most of our use cases here at Pengutronix, we see that:
- Customers want in-system upgradability on a per-packet base; so the
flash filesystems should be normally r/o, but may be remounted r/w.
- Development systems should be close to production systems, in order to
be able to have more "early testing"; so things like printk-ripout or
special non-mainline patches/tweaks should be avoided as far as
possible.
- In general we want to have our systems close to what the mainline
does; Automation & Embedded is only a small market, and anything
which is *not* specific to these markets but mainline is good.
So let's see what we'll reach while trying what people have suggested.
Thanks,
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: New fast(?)-boot results on ARM
From: Marco Stornelli @ 2009-08-18 10:06 UTC (permalink / raw)
To: Robert Schwebel
Cc: Johannes Stezenbach, Denys Vlasenko, linux-kernel, linux-embedded,
Arjan van de Ven, Tim Bird, kernel
In-Reply-To: <20090815103532.GA5596@sig21.net>
Johannes Stezenbach wrote:
> On Fri, Aug 14, 2009 at 10:43:05PM +0200, Robert Schwebel wrote:
>> On Fri, Aug 14, 2009 at 10:04:57PM +0200, Denys Vlasenko wrote:
>>>> rsc@thebe:~$ microcom | ptx_ts "U-Boot 2.0.0-rc9"
>
>>>> [ 7.137924] < 0.059316> starting udev
>>>> [ 7.147925] < 0.010001> mounting tmpfs at /dev
>>>> [ 7.182299] < 0.034374> creating static nodes
>>>> [ 7.410613] < 0.228314> starting udevd...done
>>>> [ 8.811097] < 1.400484> waiting for devices...done
>
> And suddenly devtmpfs sounds like a good idea ;-)
>
> We use static device nodes during boot, and later
> setup busybox mdev for hotplug.
>
>
> Johannes
>
Yeah, I agree, do you really need udevd, device file creation at every
start-up in /dev? Usually static devices nodes and mdev for hotplug are
enough or at least you could use a simple script to create only once
time the devices file (mdev -s). About the fs, do you really need a
rootfs with ubifs? I mean, you could "split" your fs. You could use a
read-only fs (SquashFS for example) for your root-fs, ubifs for
permanent storage data (mounted under /data for example) and a ram fs
for volatile data.
Marco
^ permalink raw reply
* Re: New MMC maintainer needed
From: Nicolas Ferre @ 2009-08-18 9:33 UTC (permalink / raw)
To: Pierre Ossman, Andrew Morton
Cc: linux-kernel, linux-embedded, nico, nicolas.ferre, hskinnemoen,
tony, david-b, manuel.lauss, mirq-linux, ppisa, jarkko.lavinen,
ben, saschasommer, avorontsov, oakad, ian, HaraldWelte,
JosephChan, adrian.hunter
In-Reply-To: <20090731122623.254fd0f1@mjolnir.ossman.eu>
Pierre Ossman :
> This things are currently lingering in my inbox:
[..]
> [PATCH 1/2] atmel-mci: Unified Atmel MCI drivers (AVR32 & AT91)
> http://marc.info/?l=linux-arm-kernel&m=124577578729455
>
> This is nice work and it's really up to Nicolas when he wants it merged.
Ok guys, it should be fine if we can plan a merge for those bits: I have
additional patches that are waiting on top of this one...
Thanks a lot. Bye,
--
Nicolas Ferre
^ permalink raw reply
* Re: new ipdelay= option for faster netboot
From: David Miller @ 2009-08-18 5:00 UTC (permalink / raw)
To: vda.linux
Cc: tim.bird, r.schwebel, linux-kernel, linux-embedded, arjan, kernel,
netdev
In-Reply-To: <200908180656.54011.vda.linux@googlemail.com>
From: Denys Vlasenko <vda.linux@googlemail.com>
Date: Tue, 18 Aug 2009 06:56:53 +0200
> Since DHCP and any other networking activity like TCP connects
> accomodate packet loss, things should work even without any delay
> in kernel IP config code. The delay will be just shifted to the
> moment when first DHCP/TCP/whatever negotiation happens.
Until the link is up, the packet scheduler just holds onto packets
and queued them up.
When the link comes up, this queue is released and the packets
sent out.
That's why it's beneficial to wait some time until the link
comes up before we start sending stuff out. Because otherwise
any timeouts used will be inaccurate.
This could code be spiffed up to wait for the link up indication
on devices it cares about. Feel free to code that up :-)
^ permalink raw reply
* Re: new ipdelay= option for faster netboot
From: Denys Vlasenko @ 2009-08-18 4:56 UTC (permalink / raw)
To: David Miller
Cc: tim.bird, r.schwebel, linux-kernel, linux-embedded, arjan, kernel,
netdev
In-Reply-To: <20090817.182754.50348941.davem@davemloft.net>
On Tuesday 18 August 2009 03:27, David Miller wrote:
> From: Tim Bird <tim.bird@am.sony.com>
> Date: Mon, 17 Aug 2009 18:24:26 -0700
>
> > David Miller wrote:
> >> I have card/switch combinations that take up to 10 seconds to
> >> negotiate a proper link.
> >
> > What types of delays are these timeouts supposed to
> > cover?
>
> The problem is that if you don't first give at least some time for the
> link to come up, the remaining time it takes the link to come up will
> end up chewing into the actual bootp/dhcp protocol timeouts. And
> that's what we're trying to avoid.
But in this case, they assign a static IP. They do not use DHCP.
So they pay this time penalty even if they wouldn't use networking
until sometime later (or never).
Since DHCP and any other networking activity like TCP connects
accomodate packet loss, things should work even without any delay
in kernel IP config code. The delay will be just shifted to the
moment when first DHCP/TCP/whatever negotiation happens.
If dropping delays altogether sounds too big a change,
then it makes sense at least to allow people to tweak it with
ipdelay=TIME_IN_MS
--
vda
^ permalink raw reply
* Re: new ipdelay= option for faster netboot
From: Willy Tarreau @ 2009-08-18 4:56 UTC (permalink / raw)
To: david
Cc: Rick Jones, David Miller, tim.bird, r.schwebel, vda.linux,
linux-kernel, linux-embedded, arjan, kernel, netdev
In-Reply-To: <alpine.DEB.2.00.0908171942430.30426@asgard.lang.hm>
On Mon, Aug 17, 2009 at 07:45:33PM -0700, david@lang.hm wrote:
> On Mon, 17 Aug 2009, Rick Jones wrote:
>
> >David Miller wrote:
> >>I have card/switch combinations that take up to 10 seconds to
> >>negotiate a proper link.
> >
> >Gotta love it when things adhere to specs...
>
> the default on Cisco switches is to wait 30 seconds before fully enabling
> the port so that it can listen for spanning tree broadcasts.
And this causes a lot of trouble in high availability environments,
because the link is up but unusable. So if you're using it as a primary
bond link you can lose connectivity for that time. Fortunately, you can
configure the port in "switchport mode access", "portfast" mode to avoid
this annoying delay.
Willy
^ permalink raw reply
* Re: new ipdelay= option for faster netboot
From: david @ 2009-08-18 2:45 UTC (permalink / raw)
To: Rick Jones
Cc: David Miller, tim.bird, r.schwebel, vda.linux, linux-kernel,
linux-embedded, arjan, kernel, netdev
In-Reply-To: <4A8A0454.8000902@hp.com>
On Mon, 17 Aug 2009, Rick Jones wrote:
> David Miller wrote:
>> I have card/switch combinations that take up to 10 seconds to
>> negotiate a proper link.
>
> Gotta love it when things adhere to specs...
the default on Cisco switches is to wait 30 seconds before fully enabling
the port so that it can listen for spanning tree broadcasts.
for windows systems this doesn't cause any problems (they take long enough
to boot), but for a tightly configured linux box it can be fully booted
long before the switch decides to enable the port (for that matter, I have
a bare-metal install process that takes about 90 seconds from hitting
power, from a CD. I could probably speed things up by switching to USB
boot media)
David Lang
^ permalink raw reply
* Re: new ipdelay= option for faster netboot
From: David Miller @ 2009-08-18 1:56 UTC (permalink / raw)
To: tim.bird
Cc: r.schwebel, vda.linux, linux-kernel, linux-embedded, arjan,
kernel, netdev
In-Reply-To: <4A8A06A0.2070402@am.sony.com>
From: Tim Bird <tim.bird@am.sony.com>
Date: Mon, 17 Aug 2009 18:40:48 -0700
> David Miller wrote:
>> From: Tim Bird <tim.bird@am.sony.com>
>> Date: Mon, 17 Aug 2009 18:24:26 -0700
>>
>>> David Miller wrote:
>>>> I have card/switch combinations that take up to 10 seconds to
>>>> negotiate a proper link.
>>> What types of delays are these timeouts supposed to
>>> cover?
>>
>> The problem is that if you don't first give at least some time for the
>> link to come up, the remaining time it takes the link to come up will
>> end up chewing into the actual bootp/dhcp protocol timeouts. And
>> that's what we're trying to avoid.
>
> What link? I'm not that familiar with networking.
The speed and duplex settings which are negotiated or forced between
the ethernet card and whatever is at the other end of the cable.
> Assuming I'm using ethernet, what link needs to come up?
All modern ethernet cards do autonegotiation of link parameters
with whatever is at the other end of the ethernet cable. Cards
created ages ago which only support 10MB half-duplex typically
do not support autonegotiation at all.
This autonegotiation works like a protocol where the two link partners
go back and forth trying to figure out the best speed and duplex
settings to use. There are advertisements of link capabilities and
stuff like that.
It should happen almost instantaneously, but there are millions
upon millions of cruddy parts out there, and some of them take
a long time to go through this negotiation process.
^ permalink raw reply
* Re: new ipdelay= option for faster netboot
From: Tim Bird @ 2009-08-18 1:40 UTC (permalink / raw)
To: David Miller
Cc: r.schwebel, vda.linux, linux-kernel, linux-embedded, arjan,
kernel, netdev
In-Reply-To: <20090817.182754.50348941.davem@davemloft.net>
David Miller wrote:
> From: Tim Bird <tim.bird@am.sony.com>
> Date: Mon, 17 Aug 2009 18:24:26 -0700
>
>> David Miller wrote:
>>> I have card/switch combinations that take up to 10 seconds to
>>> negotiate a proper link.
>> What types of delays are these timeouts supposed to
>> cover?
>
> The problem is that if you don't first give at least some time for the
> link to come up, the remaining time it takes the link to come up will
> end up chewing into the actual bootp/dhcp protocol timeouts. And
> that's what we're trying to avoid.
What link? I'm not that familiar with networking.
Assuming I'm using ethernet, what link needs to come up?
Is this something to do with power propagation to the
physical wire? Is there some MAC layer negotiation
between the card and the switch? Is it the time for
the switch to do speed detection?
And, can any of this be more accurately determined
or guessed-at with knowledge of the onboard hardware?
Or is it dependent on external conditions?
Where would be a good place to find out more about
startup delays for networking chips and/or protocols?
Our usual solution is to kick the can down the road
and let user-space initialize anything that takes a long
time, while we do other stuff like focus the camera or display
the TV picture. It would be good to learn more about
this.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: new ipdelay= option for faster netboot
From: Rick Jones @ 2009-08-18 1:31 UTC (permalink / raw)
To: David Miller
Cc: tim.bird, r.schwebel, vda.linux, linux-kernel, linux-embedded,
arjan, kernel, netdev
In-Reply-To: <20090817.180323.253692704.davem@davemloft.net>
David Miller wrote:
> I have card/switch combinations that take up to 10 seconds to
> negotiate a proper link.
Gotta love it when things adhere to specs...
rick jones
has also experienced nic/whatnot combinations that are far from IEEE specs... :(
^ permalink raw reply
* Re: new ipdelay= option for faster netboot
From: David Miller @ 2009-08-18 1:27 UTC (permalink / raw)
To: tim.bird
Cc: r.schwebel, vda.linux, linux-kernel, linux-embedded, arjan,
kernel, netdev
In-Reply-To: <4A8A02CA.7040305@am.sony.com>
From: Tim Bird <tim.bird@am.sony.com>
Date: Mon, 17 Aug 2009 18:24:26 -0700
> David Miller wrote:
>> I have card/switch combinations that take up to 10 seconds to
>> negotiate a proper link.
>
> What types of delays are these timeouts supposed to
> cover?
The problem is that if you don't first give at least some time for the
link to come up, the remaining time it takes the link to come up will
end up chewing into the actual bootp/dhcp protocol timeouts. And
that's what we're trying to avoid.
^ permalink raw reply
* Re: new ipdelay= option for faster netboot
From: Tim Bird @ 2009-08-18 1:24 UTC (permalink / raw)
To: David Miller
Cc: r.schwebel, vda.linux, linux-kernel, linux-embedded, arjan,
kernel, netdev
In-Reply-To: <20090817.180323.253692704.davem@davemloft.net>
David Miller wrote:
> From: Tim Bird <tim.bird@am.sony.com>
> Date: Mon, 17 Aug 2009 15:35:01 -0700
>
>> Tim Bird wrote:
>>> See the definitions of CONF_PRE_OPEN and CON_POST_OPEN
>>> in net/ipv4/ipconfig.c
>>>
>>> They are set to ridiculously long values. In my experience,
>>> you can cut them down considerably with no dangerous side
>>> effects (but I haven't asked the network guys about the
>>> possible downsides).
>> It turns out that others have seen this delay. Simon
>> Arlott recently posted a patch to make the delay avoidable
>> at boot time from the kernel command line.
>>
>> See http://patchwork.kernel.org/patch/31678/
>
> "Rediculiously long" is a relative term.
No offense intended. I could have phrased this
better. The delays were a few orders of
magnitude longer than apparently needed, on my
embedded test systems with ethernet. I didn't
try eliminating them completely, as in the Arlott patch.
1.5 seconds is a long time for me. My bootup time budget for
the kernel ranges from 0.5 to 3.0 seconds, depending on the
product.
> I have card/switch combinations that take up to 10 seconds to
> negotiate a proper link.
What types of delays are these timeouts supposed to
cover? Networking delays or hardware bring-up delays?
(Or both)? If for networking delays, is this for all
types of networks, or just some (e.g. ones that create
virtual circuits)?
I'm trying to get a sense for whether the card/switch
combinations that would take this long would be encountered
in the types of embedded devices I code for. (TVs, camcorders,
etc.)
>
> So what's there now is actually a quite agressive setting.
>
> And BTW, discussions about stuff like this belong on
> netdev@vger.kernel.org, which has been added to the CC:
I was going to wait to see if this solved Robert's
problem, before widening the discussion. But I'm happy
to find out more about these delays now.
Thanks,
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: new ipdelay= option for faster netboot
From: David Miller @ 2009-08-18 1:03 UTC (permalink / raw)
To: tim.bird
Cc: r.schwebel, vda.linux, linux-kernel, linux-embedded, arjan,
kernel, netdev
In-Reply-To: <4A89DB15.6060101@am.sony.com>
From: Tim Bird <tim.bird@am.sony.com>
Date: Mon, 17 Aug 2009 15:35:01 -0700
> Tim Bird wrote:
>> See the definitions of CONF_PRE_OPEN and CON_POST_OPEN
>> in net/ipv4/ipconfig.c
>>
>> They are set to ridiculously long values. In my experience,
>> you can cut them down considerably with no dangerous side
>> effects (but I haven't asked the network guys about the
>> possible downsides).
>
> It turns out that others have seen this delay. Simon
> Arlott recently posted a patch to make the delay avoidable
> at boot time from the kernel command line.
>
> See http://patchwork.kernel.org/patch/31678/
"Rediculiously long" is a relative term.
I have card/switch combinations that take up to 10 seconds to
negotiate a proper link.
So what's there now is actually a quite agressive setting.
And BTW, discussions about stuff like this belong on
netdev@vger.kernel.org, which has been added to the CC:
^ permalink raw reply
* new ipdelay= option for faster netboot (was Re: New fast(?)-boot results on ARM)
From: Tim Bird @ 2009-08-17 22:35 UTC (permalink / raw)
To: Robert Schwebel
Cc: Denys Vlasenko, linux-kernel, linux-embedded, Arjan van de Ven,
kernel
In-Reply-To: <4A89AC40.2040109@am.sony.com>
Tim Bird wrote:
> See the definitions of CONF_PRE_OPEN and CON_POST_OPEN
> in net/ipv4/ipconfig.c
>
> They are set to ridiculously long values. In my experience,
> you can cut them down considerably with no dangerous side
> effects (but I haven't asked the network guys about the
> possible downsides).
It turns out that others have seen this delay. Simon
Arlott recently posted a patch to make the delay avoidable
at boot time from the kernel command line.
See http://patchwork.kernel.org/patch/31678/
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: New fast(?)-boot results on ARM
From: Tim Bird @ 2009-08-17 19:15 UTC (permalink / raw)
To: Robert Schwebel
Cc: Denys Vlasenko, linux-kernel, linux-embedded, Arjan van de Ven,
kernel
In-Reply-To: <20090814204305.GA31727@pengutronix.de>
Robert Schwebel wrote:
> On Fri, Aug 14, 2009 at 10:04:57PM +0200, Denys Vlasenko wrote:
>>> [ �5.082616] < �0.007992> RPC: Registered tcp transport module.
>>> [ �5.605159] < �0.522543> eth0: config: auto-negotiation on, 100FDX, 100HDX, 10FDX, 10HDX.
>>> [ �6.602621] < �0.997462> IP-Config: Complete:
>>> [ �6.606638] < �0.004017> � � �device=eth0, addr=192.168.23.197, mask=255.255.0.0, gw=192.168.23.2,
>>> [ �6.614588] < �0.007950> � � �host=192.168.23.197, domain=, nis-domain=(none),
>>> [ �6.618652] < �0.004064> � � �bootserver=192.168.23.2, rootserver=192.168.23.2, rootpath=
>> Well, this ~1 second is not really kernel's fault, it's DHCP delay.
>> But, do you need to do it at this moment?
>> You do not seem to be using networking filesystems.
>> You can run DHCP client in userspace.
>
> The board has ip autoconfig configured in, because we also use tftp/nfs
> boot for development. But it had been disabled on the commandline:
>
> ip=192.168.23.197:192.168.23.2:192.168.23.2:255.255.0.0:::
>
> That shouldn't do dhcp, right?
I think it doesn't, but I'm not positive. The DHCP trasmissions
themselves don't take very long. There are 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
They are set to ridiculously long values. In my experience,
you can cut them down considerably with no dangerous side
effects (but I haven't asked the network guys about the
possible downsides).
Here's a patch which I've used in the past. (Sorry
if it doesn't apply cleanly, I just extracted it from
a PDF and the whitespace may have gotten messed up.
It's short enough that you can hand-edit the files if
there's a problem.)
I'd like to hear back, if you apply this, whether it shortens
the network startup time for you.
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 42065ff..e42d83f 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -86,8 +86,10 @@
#endif
/* Define the friendly delay before and after opening net devices */
-#define CONF_PRE_OPEN 500 /* Before opening: 1/2 second */
-#define CONF_POST_OPEN 1 /* After opening: 1 second */
+/*#define CONF_PRE_OPEN 500 /* Before opening: 1/2 second */
+/*#define CONF_POST_OPEN 1 /* After opening: 1 second */
+#define CONF_PRE_OPEN 5 /* Before opening: 5 milli seconds */
+#define CONF_POST_OPEN 10 /* After opening: 10 milli seconds */
/* Define the timeout for waiting for a DHCP/BOOTP/RARP reply */
#define CONF_OPEN_RETRIES 2 /* (Re)open devices twice */
@@ -1292,7 +1294,7 @@ static int __init ip_auto_config(void)
return -1;
/* Give drivers a chance to settle */
- ssleep(CONF_POST_OPEN);
+ msleep(CONF_POST_OPEN);
/*
* If the config information is insufficient (e.g., our IP address or
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply related
* Re: New fast(?)-boot results on ARM
From: Johannes Stezenbach @ 2009-08-15 10:35 UTC (permalink / raw)
To: Robert Schwebel
Cc: Denys Vlasenko, linux-kernel, linux-embedded, Arjan van de Ven,
Tim Bird, kernel
In-Reply-To: <20090814204305.GA31727@pengutronix.de>
On Fri, Aug 14, 2009 at 10:43:05PM +0200, Robert Schwebel wrote:
> On Fri, Aug 14, 2009 at 10:04:57PM +0200, Denys Vlasenko wrote:
> > > rsc@thebe:~$ microcom | ptx_ts "U-Boot 2.0.0-rc9"
Now that microcom is in Debian sid (thanks!), where can I find ptx_ts?
It seems to be quite useful.
> > > [ 0.874559] < 0.003967> Hit any key to stop autoboot: 0
> >
> > boot loader is not fast. considering its simple task, it can be made
> > faster.
>
> Yup, will check. Almost 1 s seems really long.
I'm working on a SoC with a 200MHz ARM926EJ-S. We managed to get
to 1.5sec from power-on to "starting init". The main difference to
your platform seems to be that we use NOR flash. The kernel is
not optimized, it still has some debug options turned on and
is used during development. (however, the 1.5sec is with "quiet")
The root fs is cramfs. The kernel version is 2.6.20.
For u-boot we enabled the D-cache which gave a decent speed up
(on ARM926EJ-S this requires one to set up page tables and enable
MMU, but it's not that difficult). I don't have the numbers here
but I think it still takes ~300ms in u-boot, and ~1.2s for the kernel boot.
> > > [ 1.326621] < 0.452062> loaded zImage from /dev/nand0.kernel.bb with size 1679656
> > > [ 2.009996] < 0.683375> Uncompressing Linux............................................................................................................... done, booting the kernel.
> > > [ 2.416999] < 0.407003> Linux version 2.6.31-rc4-g056f82f-dirty (sha@octopus) (gcc version 4.3.2 (OSELAS.Toolchain-1.99.3) ) #1 PREEMPT Thu Aug 6 08:37:19 CEST 2009
> >
> > Other people already commented on this (kernel is too big)
>
> Not sure (the kernel is already customized for the board), but I'll take
> a look again.
We are booting 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.
BTW, we are using uImage and set verify=no in u-boot. We use u-boot-1.3.0.
> > > [ 5.082616] < 0.007992> RPC: Registered tcp transport module.
> > > [ 5.605159] < 0.522543> eth0: config: auto-negotiation on, 100FDX, 100HDX, 10FDX, 10HDX.
What is happening here? Waiting for eth link negotiation?
> > > [ 6.602621] < 0.997462> IP-Config: Complete:
> > > [ 6.606638] < 0.004017> device=eth0, addr=192.168.23.197, mask=255.255.0.0, gw=192.168.23.2,
> > > [ 6.614588] < 0.007950> host=192.168.23.197, domain=, nis-domain=(none),
> > > [ 6.618652] < 0.004064> bootserver=192.168.23.2, rootserver=192.168.23.2, rootpath=
> >
> > Well, this ~1 second is not really kernel's fault, it's DHCP delay.
> > But, do you need to do it at this moment?
> > You do not seem to be using networking filesystems.
> > You can run DHCP client in userspace.
>
> The board has ip autoconfig configured in, because we also use tftp/nfs
> boot for development. But it had been disabled on the commandline:
>
> ip=192.168.23.197:192.168.23.2:192.168.23.2:255.255.0.0:::
>
> That shouldn't do dhcp, right?
Try to boot with eth cable unplugged, see if it hangs in IP-config.
If it were doing static configuration it would be faster.
However, unless you need ethernet to boot (NFS root) I'd suggest
doing eth config in userspace.
> > > [ 7.137924] < 0.059316> starting udev
> > > [ 7.147925] < 0.010001> mounting tmpfs at /dev
> > > [ 7.182299] < 0.034374> creating static nodes
> > > [ 7.410613] < 0.228314> starting udevd...done
> > > [ 8.811097] < 1.400484> waiting for devices...done
And suddenly devtmpfs sounds like a good idea ;-)
We use static device nodes during boot, and later
setup busybox mdev for hotplug.
Johannes
^ permalink raw reply
* Re: New fast(?)-boot results on ARM
From: Artem Bityutskiy @ 2009-08-15 6:21 UTC (permalink / raw)
To: Zan Lynx
Cc: Linus Walleij, Robert Schwebel, linux-kernel, linux-embedded,
Arjan van de Ven, Tim Bird, kernel
In-Reply-To: <4A85D89F.8080900@acm.org>
On 08/15/2009 12:35 AM, Zan Lynx wrote:
> Linus Walleij wrote:
>> 2009/8/14 Robert Schwebel <r.schwebel@pengutronix.de>:
>>> On Fri, Aug 14, 2009 at 12:19:48PM -0600, Zan Lynx wrote:
>>
>>>>> That's factor 70 away from the 110 ms boot time Tim has talked about
>>>>> some days ago (and he measured on an ARM cpu which had almost half
>>>>> the speed of this one), and I'm wondering what we can do to improve
>>>>> the boot time.
>>>> 2.4s in uncompression? That seems like an obvious target for
>>>> improvement.
>>> Indeed, we'll check that.
>>
>> We got rid of uncompression on a flash-based system vastly improving
>> 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.
>
> I thought of another thing to check related to slow decompression. 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.
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. I saw
some discussions about this on lkml. Having no compression at all may also
be a good thing to try.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
^ permalink raw reply
* Re: New fast(?)-boot results on ARM
From: Artem Bityutskiy @ 2009-08-15 6:14 UTC (permalink / raw)
To: Denys Vlasenko
Cc: Robert Schwebel, linux-kernel, linux-embedded, Arjan van de Ven,
Tim Bird, kernel
In-Reply-To: <1158166a0908141304y70300ab3p899b0d4609efded9@mail.gmail.com>
On 08/14/2009 11:04 PM, Denys Vlasenko wrote:
>> [ 2.742628]< 0.016050> 0x000000360000-0x000004000000 : "root"
>> [ 3.058610]< 0.315982> UBI: attaching mtd7 to ubi0
>> [ 3.062878]< 0.004268> UBI: physical eraseblock size: 16384 bytes (16 KiB)
>> [ 3.070601]< 0.007723> UBI: logical eraseblock size: 15360 bytes
>> [ 3.070665]< 0.000064> UBI: smallest flash I/O unit: 512
>> [ 3.078564]< 0.007899> UBI: VID header offset: 512 (aligned 512)
>> [ 3.078609]< 0.000045> UBI: data offset: 1024
>> [ 5.006609]< 1.928000> UBI: attached mtd7 to ubi0
>> [ 5.013157]< 0.006548> UBI: MTD device name: "root"
>
> As others commented, ubi looks slow and you probably need to find out why.
Right. UBI is rather slow in attaching MTD devices. Everything is explained
here:
http://www.linux-mtd.infradead.org/doc/ubi.html#L_scalability
http://www.linux-mtd.infradead.org/doc/ubifs.html#L_scalability
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. Here are few ideas:
http://www.linux-mtd.infradead.org/faq/ubi.html#L_attach_faster
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
^ permalink raw reply
* Re: New fast(?)-boot results on ARM
From: Dirk Behme @ 2009-08-15 5:59 UTC (permalink / raw)
To: Robert Schwebel
Cc: Denys Vlasenko, linux-kernel, linux-embedded, Arjan van de Ven,
Tim Bird, kernel
In-Reply-To: <20090814204305.GA31727@pengutronix.de>
Robert Schwebel wrote:
> On Fri, Aug 14, 2009 at 10:04:57PM +0200, Denys Vlasenko wrote:
>>> rsc@thebe:~$ microcom | ptx_ts "U-Boot 2.0.0-rc9"
>>> [ 2.395740] < 2.395740>
>>> [ 2.395860] < 0.000120>
>>> [ 0.000011] < 0.000011> U-Boot 2.0.0-rc9 (Aug 5 2009 - 10:05:58)
>>> [ 0.000059] < 0.000048>
>>> [ 0.003823] < 0.003764> Board: Phytec phyCORE-i.MX27
>>> [ 0.010753] < 0.006930> cfi_probe: cfi_flash base: 0xc0000000 size: 0x02000000
>>> [ 0.018711] < 0.007958> NAND device: Manufacturer ID: 0x20, Chip ID: 0x36 (ST Micro NAND 64MiB 1,8V 8-bit)
>>> [ 0.026592] < 0.007881> imxfb@imxfb0: i.MX Framebuffer driver
>>> [ 0.178655] < 0.152063> dev_protect: currently broken
>>> [ 0.178736] < 0.000081> Using environment in NOR Flash
>>> [ 0.182577] < 0.003841> initialising PLLs
>>> [ 0.367142] < 0.184565> Malloc space: 0xa3f00000 -> 0xa7f00000 (size 64 MB)
>>> [ 0.370568] < 0.003426> Stack space : 0xa3ef8000 -> 0xa3f00000 (size 32 kB)
>>> [ 0.445993] < 0.075425> running /env/bin/init...
>>> [ 0.870592] < 0.424599>
>>> [ 0.874559] < 0.003967> Hit any key to stop autoboot: 0
>> boot loader is not fast. considering its simple task, it can be made
>> faster.
>
> Yup, will check. Almost 1 s seems really long.
Some things to check regarding this and kernel uncompression (copy):
- How often is (compressed/uncompressed) kernel data copied? Once the
compressed one from storage (NOR/NAND?) to RAM by boot loader? Then by
kernel's uncompression from RAM to it's final location in RAM?
- For boot loader and uncompression, is D-Cache enabled?
- Is data (image) copy done by optimized functions? Using (a) DMA or
at least (b) some optimized memcpy using ARM's ldmia/stmia?
Best regards
Dirk
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox