* Re: New MMC maintainer needed
From: Matt Fleming @ 2009-08-11 14:02 UTC (permalink / raw)
To: Adrian Hunter
Cc: Pierre Ossman, Andrew Morton, linux-kernel@vger.kernel.org,
linux-embedded@vger.kernel.org, nico@cam.org,
nicolas.ferre@rfo.atmel.com, hskinnemoen@atmel.com,
tony@atomide.com, david-b@pacbell.net, manuel.lauss@gmail.com,
mirq-linux@rere.qmqm.pl, ppisa@pikron.com,
Lavinen Jarkko (Nokia-D/Helsinki), ben@fluff.org,
saschasommer@freenet.de, avorontsov@ru.mvista.com,
oakad@yahoo.com, ian@mnementh.co.uk, HaraldWelte
In-Reply-To: <4A76C658.6050002@nokia.com>
On Mon, Aug 03, 2009 at 02:13:28PM +0300, Adrian Hunter wrote:
> Pierre Ossman wrote:
>> Con:
>>
>> - The scanning code gets less clear as you increase the number of
>> possible paths through it.
>>
>> - Different systems will have different init sequences, possibly
>> provoking bugs in the cards.
>>
>> - Host driver writers now have more capability bits they have to
>> consider. And these might be less than obvious since SD/MMC/SDIO are
>> normally compatible so these bits seem useless.
>>
>> - With the current logic (which was better in the first version),
>> "normal" drivers will have to explicitly state that they work as
>> intended by setting all bits.
>
> And the pro is objective.
>
>> Pro:
>>
>> - A slightly reduced scanning time.
>
> That's great! Why do you disregard this so easily?
>
Ping. Adrian, do you have any initialisation times for this patch? I'm
afraid I don't have any eMMC hardware, so I'm not able to gather any
numbers.
^ permalink raw reply
* Re: [PATCH 4/6] Add support for LZO-compressed kernels for ARM
From: Albin Tonnerre @ 2009-08-11 14:17 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Russell King - ARM Linux, Matthieu CASTET, Alain Knaff,
hpa@zytor.com, linux-kernel@vger.kernel.org,
linux-embedded@vger.kernel.org, akpm@linux-foundation.org
In-Reply-To: <20090811133943.GA3130@merkur.ravnborg.org>
On Tue, Aug 11, 2009 at 03:39:43PM +0200, Sam Ravnborg wrote :
> On Tue, Aug 11, 2009 at 11:44:18AM +0200, Albin Tonnerre wrote:
> > Hi Sam,
> >
> > On Fri, Aug 07, 2009 at 11:08:16PM +0200, Sam Ravnborg wrote :
> > > We could add libgcc as a prerequisite.
> > > Untested patch below.
> >
> > When compiling with this patch applied, I get the following error:
> >
> > Kernel: arch/arm/boot/Image is ready
> > LD arch/arm/boot/compressed/vmlinux
> > /home/albin/x-tools/arm-unknown-linux-uclibcgnueabi/lib/gcc/arm-unknown-linux-uclibcgnueabi/4.3.2/libgcc.a(_dvmd_lnx.o):
> > In function `__div0':
> > /home/albin/devel/free-electrons/toolchain/targets/src/gcc-4.3.2/libgcc/../gcc/config/arm/lib1funcs.asm:1079:
> > undefined reference to `raise'
> > make[2]: *** [arch/arm/boot/compressed/vmlinux] Error 1
> > make[1]: *** [arch/arm/boot/compressed/vmlinux] Error 2
> >
> > I've got no idea where this symbol is defined, though. Has anyone an idea on
> > this ?
>
> To make sure thet hack did what it was intended could you
> try to build with V=1 and post output of the ld command.
>
Here it is:
make -f scripts/Makefile.build obj=arch/arm/boot/compressed
arch/arm/boot/compressed/vmlinux
arm-unknown-linux-uclibcgnueabi-ld -EL --defsym zreladdr=0x20008000
--defsym initrd_phys=0x20410000 --defsym params_phys=0x20000100 -p
--no-undefined -X -T arch/arm/boot/compressed/vmlinux.lds
arch/arm/boot/compressed/head.o arch/arm/boot/compressed/piggy.gzip.o arch/arm/boot/compressed/misc.o
/home/albin/x-tools/arm-unknown-linux-uclibcgnueabi/lib/gcc/arm-unknown-linux-uclibcgnueabi/4.3.2/libgcc.a -o arch/arm/boot/compressed/vmlinux
/home/albin/x-tools/arm-unknown-linux-uclibcgnueabi/lib/gcc/arm-unknown-linux-uclibcgnueabi/4.3.2/libgcc.a(_dvmd_lnx.o):
In function `__div0':
/home/albin/devel/free-electrons/toolchain/targets/src/gcc-4.3.2/libgcc/../gcc/config/arm/lib1funcs.asm:1079:
undefined reference to `raise'
So it seems like the hack indeed did what is was supposed to do.
Regards,
--
Albin Tonnerre, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 4/6] Add support for LZO-compressed kernels for ARM
From: H. Peter Anvin @ 2009-08-11 16:03 UTC (permalink / raw)
To: Albin Tonnerre
Cc: Sam Ravnborg, Russell King - ARM Linux, Matthieu CASTET,
Alain Knaff, linux-kernel@vger.kernel.org,
linux-embedded@vger.kernel.org, akpm@linux-foundation.org
In-Reply-To: <20090811094418.GI9704@pc-ras4041.res.insa>
On 08/11/2009 02:44 AM, Albin Tonnerre wrote:
> Hi Sam,
>
> On Fri, Aug 07, 2009 at 11:08:16PM +0200, Sam Ravnborg wrote :
>> We could add libgcc as a prerequisite.
>> Untested patch below.
>
> When compiling with this patch applied, I get the following error:
>
> Kernel: arch/arm/boot/Image is ready
> LD arch/arm/boot/compressed/vmlinux
> /home/albin/x-tools/arm-unknown-linux-uclibcgnueabi/lib/gcc/arm-unknown-linux-uclibcgnueabi/4.3.2/libgcc.a(_dvmd_lnx.o):
> In function `__div0':
> /home/albin/devel/free-electrons/toolchain/targets/src/gcc-4.3.2/libgcc/../gcc/config/arm/lib1funcs.asm:1079:
> undefined reference to `raise'
> make[2]: *** [arch/arm/boot/compressed/vmlinux] Error 1
> make[1]: *** [arch/arm/boot/compressed/vmlinux] Error 2
>
> I've got no idea where this symbol is defined, though. Has anyone an idea on
> this ?
>
raise() gets called by libgcc to handle division by zero.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: [PATCH 4/6] Add support for LZO-compressed kernels for ARM
From: Albin Tonnerre @ 2009-08-11 16:27 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Sam Ravnborg, Russell King - ARM Linux, Matthieu CASTET,
Alain Knaff, linux-kernel@vger.kernel.org,
linux-embedded@vger.kernel.org, akpm@linux-foundation.org
In-Reply-To: <4A819642.10700@zytor.com>
On Tue, Aug 11, 2009 at 09:03:14AM -0700, H. Peter Anvin wrote :
> On 08/11/2009 02:44 AM, Albin Tonnerre wrote:
> > Hi Sam,
> >
> > On Fri, Aug 07, 2009 at 11:08:16PM +0200, Sam Ravnborg wrote :
> >> We could add libgcc as a prerequisite.
> >> Untested patch below.
> >
> > When compiling with this patch applied, I get the following error:
> >
> > Kernel: arch/arm/boot/Image is ready
> > LD arch/arm/boot/compressed/vmlinux
> > /home/albin/x-tools/arm-unknown-linux-uclibcgnueabi/lib/gcc/arm-unknown-linux-uclibcgnueabi/4.3.2/libgcc.a(_dvmd_lnx.o):
> > In function `__div0':
> > /home/albin/devel/free-electrons/toolchain/targets/src/gcc-4.3.2/libgcc/../gcc/config/arm/lib1funcs.asm:1079:
> > undefined reference to `raise'
> > make[2]: *** [arch/arm/boot/compressed/vmlinux] Error 1
> > make[1]: *** [arch/arm/boot/compressed/vmlinux] Error 2
> >
> > I've got no idea where this symbol is defined, though. Has anyone an idea on
> > this ?
> >
>
> raise() gets called by libgcc to handle division by zero.
So I guess the only options left are either define a dummy raise() function, or
get rid of the divisions like Alain Knaff did in his patch ?
Regards,
--
Albin Tonnerre, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 4/6] Add support for LZO-compressed kernels for ARM
From: H. Peter Anvin @ 2009-08-11 16:31 UTC (permalink / raw)
To: Albin Tonnerre
Cc: Sam Ravnborg, Russell King - ARM Linux, Matthieu CASTET,
Alain Knaff, linux-kernel@vger.kernel.org,
linux-embedded@vger.kernel.org, akpm@linux-foundation.org
In-Reply-To: <20090811162730.GM9704@pc-ras4041.res.insa>
On 08/11/2009 09:27 AM, Albin Tonnerre wrote:
>
> So I guess the only options left are either define a dummy raise() function, or
> get rid of the divisions like Alain Knaff did in his patch ?
>
Define a dummy raise, get rid of the divisions, or provide your own
division function (there is probably one in the kernel already...)
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: New MMC maintainer needed
From: Andrew Morton @ 2009-08-12 22:27 UTC (permalink / raw)
To: Matt Fleming
Cc: adrian.hunter, pierre, 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
In-Reply-To: <20090811140223.GA4278@console-pimps.org>
davem has set up linux-mmc@vger.kernel.org for us. It will be archived
at marc.info. Thanks to both..
I was thinking that we wouldn't need a separate list but then I
realised I didn't have anywhere to send MMC bug reports.
echo "subscribe linux-mmc" | mail majordomo@vger.kernel.org
^ permalink raw reply
* Re: New MMC maintainer needed
From: ellis @ 2009-08-12 22:52 UTC (permalink / raw)
To: linux-embedded
It'll also be archived at http://www.spinics.net/lists/linux-mmc/
^ permalink raw reply
* Re: New MMC maintainer needed
From: Adrian Hunter @ 2009-08-13 7:01 UTC (permalink / raw)
To: Matt Fleming
Cc: Pierre Ossman, Andrew Morton, linux-kernel@vger.kernel.org,
linux-embedded@vger.kernel.org, nico@cam.org,
nicolas.ferre@rfo.atmel.com, hskinnemoen@atmel.com,
tony@atomide.com, david-b@pacbell.net, manuel.lauss@gmail.com,
mirq-linux@rere.qmqm.pl, ppisa@pikron.com,
Lavinen Jarkko (Nokia-D/Helsinki), ben@fluff.org,
saschasommer@freenet.de, avorontsov@ru.mvista.com,
oakad@yahoo.com, ian@mnementh.co.uk, HaraldWelte
In-Reply-To: <20090811140223.GA4278@console-pimps.org>
Matt Fleming wrote:
> On Mon, Aug 03, 2009 at 02:13:28PM +0300, Adrian Hunter wrote:
>> Pierre Ossman wrote:
>>> Con:
>>>
>>> - The scanning code gets less clear as you increase the number of
>>> possible paths through it.
>>>
>>> - Different systems will have different init sequences, possibly
>>> provoking bugs in the cards.
>>>
>>> - Host driver writers now have more capability bits they have to
>>> consider. And these might be less than obvious since SD/MMC/SDIO are
>>> normally compatible so these bits seem useless.
>>>
>>> - With the current logic (which was better in the first version),
>>> "normal" drivers will have to explicitly state that they work as
>>> intended by setting all bits.
>> And the pro is objective.
>>
>>> Pro:
>>>
>>> - A slightly reduced scanning time.
>> That's great! Why do you disregard this so easily?
>>
>
> Ping. Adrian, do you have any initialisation times for this patch? I'm
> afraid I don't have any eMMC hardware, so I'm not able to gather any
> numbers.
>
Sorry for the slow reply.
Results in microseconds:
before after
eMMC 194145 193641
uSD 4143 2129
However, that excludes powering up. For example the pbias setting
on omap_hsmmc for MMC1 (uSD for us) has a 100ms delay.
So the difference is negligible.
Although, the notion of unnecessarily sending SDIO commands
to an uSD, and SDIO and SD commands to an eMMC, seems wrong.
Especially when trying to debug very-hard-to-reproduce errors.
^ permalink raw reply
* Re: New MMC maintainer needed
From: Matt Fleming @ 2009-08-13 8:21 UTC (permalink / raw)
To: Andrew Morton
Cc: adrian.hunter, pierre, 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
In-Reply-To: <20090812152731.d07bd980.akpm@linux-foundation.org>
On Wed, Aug 12, 2009 at 03:27:31PM -0700, Andrew Morton wrote:
>
> davem has set up linux-mmc@vger.kernel.org for us. It will be archived
> at marc.info. Thanks to both..
>
> I was thinking that we wouldn't need a separate list but then I
> realised I didn't have anywhere to send MMC bug reports.
>
> echo "subscribe linux-mmc" | mail majordomo@vger.kernel.org
>
Unless someone has beaten me to it,
From a920e6c11635cab6261541a487db7b68b4892a74 Mon Sep 17 00:00:00 2001
From: Matt Fleming <matt@console-pimps.org>
Date: Thu, 13 Aug 2009 09:17:23 +0100
Subject: [PATCH] mmc: Add linux-mmc mailing list
A new linux-mmc mailing list has been set up at vger.kernel.org for all
things related to MMC/SD development.
Signed-off-by: Matt Fleming <matt@console-pimps.org>
---
MAINTAINERS | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index b1114cf..e16c7dd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3420,6 +3420,7 @@ S: Supported
F: drivers/mfd/
MULTIMEDIA CARD (MMC), SECURE DIGITAL (SD) AND SDIO SUBSYSTEM
+L: linux-mmc@vger.kernel.org
S: Orphan
F: drivers/mmc/
F: include/linux/mmc/
--
1.6.4.rc0
^ permalink raw reply related
* Re: [PATCH 4/6] Add support for LZO-compressed kernels for ARM
From: Albin Tonnerre @ 2009-08-13 9:30 UTC (permalink / raw)
To: H. Peter Anvin, Russell King - ARM Linux
Cc: Sam Ravnborg, Matthieu CASTET, Alain Knaff,
linux-kernel@vger.kernel.org, linux-embedded@vger.kernel.org,
akpm@linux-foundation.org
In-Reply-To: <4A819CDD.1000700@zytor.com>
On Tue, Aug 11, 2009 at 09:31:25AM -0700, H. Peter Anvin wrote :
> On 08/11/2009 09:27 AM, Albin Tonnerre wrote:
> >
> > So I guess the only options left are either define a dummy raise() function, or
> > get rid of the divisions like Alain Knaff did in his patch ?
> >
>
> Define a dummy raise, get rid of the divisions, or provide your own
> division function (there is probably one in the kernel already...)
Yes, there's such a function in arch/arm/lib/lib1funcs.S, which in turns
requires the __div0 symbol, defined in arch/arm/kernel/traps.c, and this one
cannot be used as it brings plenty of symbols that aren't available in the
pre-boot environment. So anyway, we have to define our own symbols there. Either
we use libgcc and define raise(), or lib1funcs and define __div0().
Russell, what's your take on this ?
Regards,
--
Albin Tonnerre, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 4/6] Add support for LZO-compressed kernels for ARM
From: Albin Tonnerre @ 2009-08-13 12:25 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: sam, hpa, alain, linux-kernel, linux-embedded, akpm
In-Reply-To: <20090806224055.GH31579@n2100.arm.linux.org.uk>
On Thu, Aug 06, 2009 at 11:40:55PM +0100, Russell King - ARM Linux wrote :
> On Mon, Aug 03, 2009 at 04:58:19PM +0200, Albin Tonnerre wrote:
> > This is the second part of patch. This part includes:
> > - changes to ach/arch/boot/Makefile to make it easier to add new
> > compression types
> > - new piggy.lzo.S necessary for lzo compression
> > - changes in arch/arm/boot/compressed/misc.c to allow the use of lzo or
> > gzip, depending on the config
> > - Kconfig support
>
> FYI, with these patches applied and selecting GZIP method, I get
> linker errors. I've been unable to track down what's going on, but
> it appears to be a libgcc issue.
>
> In spite of the decompressor being built as an EABI object, gcc seems
> to be issuing calls to __umodsi3, which isn't in the EABI libgcc
> (they're called something different - don't ask.)
Looks like this one is on its way to getting solved.
> So I think these patches need further testing and evaluation on ARM
> before they can be merged. Moreover, I'd like to see some comparisons
> between the _current_ gzip method, the new gzip method and the lzo
> method on ARM.
The figures I posted with my patch were from an ARM (AT91SAM9263) 180MHz CPU.
For the record (average on 25 boots with each compression method):
Uncompressed size: 3.24Mo
gzip 1.61Mo 0.72s
lzo 1.75Mo 0.48s
Some tests with the current gzip code give about 1.64s decompression time.
Regards,
--
Albin Tonnerre, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 4/6] Add support for LZO-compressed kernels for ARM
From: H. Peter Anvin @ 2009-08-13 14:07 UTC (permalink / raw)
To: Albin Tonnerre
Cc: Russell King - ARM Linux, Sam Ravnborg, Matthieu CASTET,
Alain Knaff, linux-kernel@vger.kernel.org,
linux-embedded@vger.kernel.org, akpm@linux-foundation.org
In-Reply-To: <20090813093036.GG4051@pc-ras4041.res.insa>
On 08/13/2009 02:30 AM, Albin Tonnerre wrote:
> On Tue, Aug 11, 2009 at 09:31:25AM -0700, H. Peter Anvin wrote :
>> On 08/11/2009 09:27 AM, Albin Tonnerre wrote:
>>> So I guess the only options left are either define a dummy raise() function, or
>>> get rid of the divisions like Alain Knaff did in his patch ?
>>>
>> Define a dummy raise, get rid of the divisions, or provide your own
>> division function (there is probably one in the kernel already...)
>
> Yes, there's such a function in arch/arm/lib/lib1funcs.S, which in turns
> requires the __div0 symbol, defined in arch/arm/kernel/traps.c, and this one
> cannot be used as it brings plenty of symbols that aren't available in the
> pre-boot environment. So anyway, we have to define our own symbols there. Either
> we use libgcc and define raise(), or lib1funcs and define __div0().
>
I would go with the variant in the kernel, as being a known quantity.
Your __div0 function can just loop forever.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: New MMC maintainer needed
From: Nicolas Pitre @ 2009-08-13 17:03 UTC (permalink / raw)
To: Adrian Hunter
Cc: Matt Fleming, Pierre Ossman, Andrew Morton,
linux-kernel@vger.kernel.org, linux-embedded@vger.kernel.org,
nicolas.ferre@rfo.atmel.com, hskinnemoen@atmel.com,
tony@atomide.com, david-b@pacbell.net, manuel.lauss@gmail.com,
mirq-linux@rere.qmqm.pl, ppisa@pikron.com,
Lavinen Jarkko (Nokia-D/Helsinki), ben@fluff.org,
saschasommer@freenet.de, avorontsov@ru.mvista.com,
oakad@yahoo.com, ian@mnementh.co.uk, HaraldWel
In-Reply-To: <4A83BA65.1080608@nokia.com>
On Thu, 13 Aug 2009, Adrian Hunter wrote:
> Results in microseconds:
>
> before after
> eMMC 194145 193641
> uSD 4143 2129
>
> However, that excludes powering up. For example the pbias setting
> on omap_hsmmc for MMC1 (uSD for us) has a 100ms delay.
>
> So the difference is negligible.
I therefore tend to agree with Pierre and Andrew. This doesn't make
enough of a difference to increase the complexity and maintenance cost
of the code for such a trivial improvement.
> Although, the notion of unnecessarily sending SDIO commands
> to an uSD, and SDIO and SD commands to an eMMC, seems wrong.
> Especially when trying to debug very-hard-to-reproduce errors.
Simply commenting out the SD/SDIO or MMC probe call in the code is
very simple when you're debugging. Then if you actually come to the
conclusion that some real bugs are due to this cross probe and can prove
it then we might reconsider.
Currently, generic host drivers are sometimes used in the context of a
uSD slot, sometimes in the context of a SD/SDIO/MMC slot, sometimes with
a hardwired SDIO based chip soldered on the board, and they don't need
any special flags to distinguish between those use cases. This greatly
helps maintainability, and that should prevail over slight latency
improvements to non timing critical events such as card insertion.
Nicolas
^ permalink raw reply
* [PATCH 4/6 v2] Add support for LZO-compressed kernels for ARM
From: Albin Tonnerre @ 2009-08-14 10:08 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: sam, hpa, alain, linux-kernel, linux-embedded, akpm
In-Reply-To: <20090806224055.GH31579@n2100.arm.linux.org.uk>
This is the second part of patch. This part includes:
- changes to ach/arch/boot/Makefile to make it easier to add new
compression types
- new piggy.lzo.S necessary for lzo compression
- changes in arch/arm/boot/compressed/misc.c to allow the use of lzo or
gzip, depending on the config
- Kconfig support
Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
---
Changes:
Compiling with -Os failed due to missing __aeabi_uidivmod.
Link using arch/arm/lib/lib1funcs.o which provides this symbol, and
define a dummy __div0 function in arch/arm/boot/compressed/misc.c, as
this symbol is required by lib1funcs.
arch/arm/Kconfig | 2 +
arch/arm/boot/compressed/Makefile | 31 ++++++---
arch/arm/boot/compressed/misc.c | 116 ++++++++++-----------------------
arch/arm/boot/compressed/piggy.S | 6 --
arch/arm/boot/compressed/piggy.gzip.S | 6 ++
arch/arm/boot/compressed/piggy.lzo.S | 6 ++
6 files changed, 70 insertions(+), 97 deletions(-)
delete mode 100644 arch/arm/boot/compressed/piggy.S
create mode 100644 arch/arm/boot/compressed/piggy.gzip.S
create mode 100644 arch/arm/boot/compressed/piggy.lzo.S
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index aef63c8..ea71c0c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -18,6 +18,8 @@ config ARM
select HAVE_KRETPROBES if (HAVE_KPROBES)
select HAVE_FUNCTION_TRACER if (!XIP_KERNEL)
select HAVE_GENERIC_DMA_COHERENT
+ select HAVE_KERNEL_GZIP
+ select HAVE_KERNEL_LZO
help
The ARM series is a line of low-power-consumption RISC chip designs
licensed by ARM Ltd and targeted at embedded applications and
diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index ce39dc5..5b4629b 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -63,8 +63,12 @@ endif
SEDFLAGS = s/TEXT_START/$(ZTEXTADDR)/;s/BSS_START/$(ZBSSADDR)/
-targets := vmlinux vmlinux.lds piggy.gz piggy.o font.o font.c \
- head.o misc.o $(OBJS)
+suffix_$(CONFIG_KERNEL_GZIP) = gzip
+suffix_$(CONFIG_KERNEL_LZO) = lzo
+
+targets := vmlinux vmlinux.lds \
+ piggy.$(suffix_y) piggy.$(suffix_y).o \
+ font.o font.c head.o misc.o $(OBJS)
ifeq ($(CONFIG_FUNCTION_TRACER),y)
ORIG_CFLAGS := $(KBUILD_CFLAGS)
@@ -87,22 +91,31 @@ endif
ifneq ($(PARAMS_PHYS),)
LDFLAGS_vmlinux += --defsym params_phys=$(PARAMS_PHYS)
endif
-LDFLAGS_vmlinux += -p --no-undefined -X \
- $(shell $(CC) $(KBUILD_CFLAGS) --print-libgcc-file-name) -T
+# ?
+LDFLAGS_vmlinux += -p
+# Report unresolved symbol references
+LDFLAGS_vmlinux += --no-undefined
+# Delete all temporary local symbols
+LDFLAGS_vmlinux += -X
+# Next argument is a linker script
+LDFLAGS_vmlinux += -T
+
+# For __aeabi_uidivmod
+lib1funcs = $(srctree)/arch/$(SRCARCH)/lib/lib1funcs.o
# Don't allow any static data in misc.o, which
# would otherwise mess up our GOT table
CFLAGS_misc.o := -Dstatic=
-$(obj)/vmlinux: $(obj)/vmlinux.lds $(obj)/$(HEAD) $(obj)/piggy.o \
- $(addprefix $(obj)/, $(OBJS)) FORCE
+$(obj)/vmlinux: $(obj)/vmlinux.lds $(obj)/$(HEAD) $(obj)/piggy.$(suffix_y).o \
+ $(addprefix $(obj)/, $(OBJS)) $(lib1funcs) FORCE
$(call if_changed,ld)
@:
-$(obj)/piggy.gz: $(obj)/../Image FORCE
- $(call if_changed,gzip)
+$(obj)/piggy.$(suffix_y): $(obj)/../Image FORCE
+ $(call if_changed,$(suffix_y))
-$(obj)/piggy.o: $(obj)/piggy.gz FORCE
+$(obj)/piggy.$(suffix_y).o: $(obj)/piggy.$(suffix_y) FORCE
CFLAGS_font.o := -Dstatic=
diff --git a/arch/arm/boot/compressed/misc.c b/arch/arm/boot/compressed/misc.c
index 17153b5..57077c8 100644
--- a/arch/arm/boot/compressed/misc.c
+++ b/arch/arm/boot/compressed/misc.c
@@ -18,10 +18,15 @@
unsigned int __machine_arch_type;
+#define _LINUX_STRING_H_
+
#include <linux/compiler.h> /* for inline */
#include <linux/types.h> /* for size_t */
#include <linux/stddef.h> /* for NULL */
#include <asm/string.h>
+#include <linux/linkage.h>
+
+#include <asm/unaligned.h>
#ifdef STANDALONE_DEBUG
#define putstr printf
@@ -188,34 +193,8 @@ static inline __ptr_t memcpy(__ptr_t __dest, __const __ptr_t __src,
/*
* gzip delarations
*/
-#define OF(args) args
#define STATIC static
-typedef unsigned char uch;
-typedef unsigned short ush;
-typedef unsigned long ulg;
-
-#define WSIZE 0x8000 /* Window size must be at least 32k, */
- /* and a power of two */
-
-static uch *inbuf; /* input buffer */
-static uch window[WSIZE]; /* Sliding window buffer */
-
-static unsigned insize; /* valid bytes in inbuf */
-static unsigned inptr; /* index of next byte to be processed in inbuf */
-static unsigned outcnt; /* bytes in output buffer */
-
-/* gzip flag byte */
-#define ASCII_FLAG 0x01 /* bit 0 set: file probably ascii text */
-#define CONTINUATION 0x02 /* bit 1 set: continuation of multi-part gzip file */
-#define EXTRA_FIELD 0x04 /* bit 2 set: extra field present */
-#define ORIG_NAME 0x08 /* bit 3 set: original file name present */
-#define COMMENT 0x10 /* bit 4 set: file comment present */
-#define ENCRYPTED 0x20 /* bit 5 set: file is encrypted */
-#define RESERVED 0xC0 /* bit 6,7: reserved */
-
-#define get_byte() (inptr < insize ? inbuf[inptr++] : fill_inbuf())
-
/* Diagnostic functions */
#ifdef DEBUG
# define Assert(cond,msg) {if(!(cond)) error(msg);}
@@ -233,24 +212,20 @@ static unsigned outcnt; /* bytes in output buffer */
# define Tracecv(c,x)
#endif
-static int fill_inbuf(void);
-static void flush_window(void);
static void error(char *m);
extern char input_data[];
extern char input_data_end[];
-static uch *output_data;
-static ulg output_ptr;
-static ulg bytes_out;
+static unsigned char *output_data;
+static unsigned long output_ptr;
static void error(char *m);
static void putstr(const char *);
-extern int end;
-static ulg free_mem_ptr;
-static ulg free_mem_end_ptr;
+static unsigned long free_mem_ptr;
+static unsigned long free_mem_end_ptr;
#ifdef STANDALONE_DEBUG
#define NO_INFLATE_MALLOC
@@ -258,46 +233,13 @@ static ulg free_mem_end_ptr;
#define ARCH_HAS_DECOMP_WDOG
-#include "../../../../lib/inflate.c"
-
-/* ===========================================================================
- * Fill the input buffer. This is called only when the buffer is empty
- * and at least one byte is really needed.
- */
-int fill_inbuf(void)
-{
- if (insize != 0)
- error("ran out of input data");
-
- inbuf = input_data;
- insize = &input_data_end[0] - &input_data[0];
-
- inptr = 1;
- return inbuf[0];
-}
+#ifdef CONFIG_KERNEL_GZIP
+#include "../../../../lib/decompress_inflate.c"
+#endif
-/* ===========================================================================
- * Write the output window window[0..outcnt-1] and update crc and bytes_out.
- * (Used for the decompressed data only.)
- */
-void flush_window(void)
-{
- ulg c = crc;
- unsigned n;
- uch *in, *out, ch;
-
- in = window;
- out = &output_data[output_ptr];
- for (n = 0; n < outcnt; n++) {
- ch = *out++ = *in++;
- c = crc_32_tab[((int)c ^ ch) & 0xff] ^ (c >> 8);
- }
- crc = c;
- bytes_out += (ulg)outcnt;
- output_ptr += (ulg)outcnt;
- outcnt = 0;
- putstr(".");
-}
+#ifdef CONFIG_KERNEL_LZO
+#include "../../../../lib/decompress_unlzo.c"
+#endif
#ifndef arch_error
#define arch_error(x)
@@ -314,22 +256,33 @@ static void error(char *x)
while(1); /* Halt */
}
+asmlinkage void __div0(void)
+{
+ error("Attempting division by 0!");
+}
+
#ifndef STANDALONE_DEBUG
-ulg
-decompress_kernel(ulg output_start, ulg free_mem_ptr_p, ulg free_mem_ptr_end_p,
- int arch_id)
+unsigned long
+decompress_kernel(unsigned long output_start, unsigned long free_mem_ptr_p,
+ unsigned long free_mem_ptr_end_p,
+ int arch_id)
{
- output_data = (uch *)output_start; /* Points to kernel start */
+ unsigned char *tmp;
+
+ output_data = (unsigned char *)output_start;
free_mem_ptr = free_mem_ptr_p;
free_mem_end_ptr = free_mem_ptr_end_p;
__machine_arch_type = arch_id;
arch_decomp_setup();
- makecrc();
+ tmp = (unsigned char *) (((unsigned long)input_data_end) - 4);
+ output_ptr = get_unaligned_le32(tmp);
+
putstr("Uncompressing Linux...");
- gunzip();
+ decompress(input_data, input_data_end - input_data,
+ NULL, NULL, output_data, NULL, error);
putstr(" done, booting the kernel.\n");
return output_ptr;
}
@@ -341,11 +294,10 @@ int main()
{
output_data = output_buffer;
- makecrc();
putstr("Uncompressing Linux...");
- gunzip();
+ decompress(input_data, input_data_end - input_data,
+ NULL, NULL, output_data, NULL, error);
putstr("done.\n");
return 0;
}
#endif
-
diff --git a/arch/arm/boot/compressed/piggy.S b/arch/arm/boot/compressed/piggy.S
deleted file mode 100644
index 54c9518..0000000
--- a/arch/arm/boot/compressed/piggy.S
+++ /dev/null
@@ -1,6 +0,0 @@
- .section .piggydata,#alloc
- .globl input_data
-input_data:
- .incbin "arch/arm/boot/compressed/piggy.gz"
- .globl input_data_end
-input_data_end:
diff --git a/arch/arm/boot/compressed/piggy.gzip.S b/arch/arm/boot/compressed/piggy.gzip.S
new file mode 100644
index 0000000..a68adf9
--- /dev/null
+++ b/arch/arm/boot/compressed/piggy.gzip.S
@@ -0,0 +1,6 @@
+ .section .piggydata,#alloc
+ .globl input_data
+input_data:
+ .incbin "arch/arm/boot/compressed/piggy.gzip"
+ .globl input_data_end
+input_data_end:
diff --git a/arch/arm/boot/compressed/piggy.lzo.S b/arch/arm/boot/compressed/piggy.lzo.S
new file mode 100644
index 0000000..a425ad9
--- /dev/null
+++ b/arch/arm/boot/compressed/piggy.lzo.S
@@ -0,0 +1,6 @@
+ .section .piggydata,#alloc
+ .globl input_data
+input_data:
+ .incbin "arch/arm/boot/compressed/piggy.lzo"
+ .globl input_data_end
+input_data_end:
--
Albin Tonnerre, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ permalink raw reply related
* New fast(?)-boot results on ARM
From: Robert Schwebel @ 2009-08-14 17:02 UTC (permalink / raw)
To: linux-kernel, linux-embedded; +Cc: Arjan van de Ven, Tim Bird, kernel
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"
[ 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
[ 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
[ 2.418729] < 0.001730> CPU: ARM926EJ-S [41069264] revision 4 (ARMv5TEJ), cr=00053177
[ 2.423081] < 0.004352> CPU: VIVT data cache, VIVT instruction cache
[ 2.426592] < 0.003511> Machine: phyCORE-i.MX27
[ 2.430609] < 0.004017> Memory policy: ECC disabled, Data cache writeback
[ 2.439704] < 0.009095> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
[ 2.463977] < 0.024273> Kernel command line: console=ttymxc0,115200 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)"
[ 2.467580] < 0.003603> Unknown boot option `mt9v022.sensor_type=color': ignoring
[ 2.471632] < 0.004052> PID hash table entries: 512 (order: 9, 2048 bytes)
[ 2.479971] < 0.008339> Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 2.485485] < 0.005514> Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 2.485560] < 0.000075> Memory: 128MB = 128MB total
[ 2.490595] < 0.005035> Memory: 126108KB available (3104K code, 350K data, 100K init, 0K highmem)
[ 2.494609] < 0.004014> NR_IRQS:272
[ 2.494654] < 0.000045> MXC GPIO hardware
[ 2.498595] < 0.003941> MXC IRQ initialized
[ 2.502600] < 0.004005> Console: colour dummy device 80x30
[ 2.506591] < 0.003991> Calibrating delay loop... 199.06 BogoMIPS (lpj=995328)
[ 2.506641] < 0.000050> Mount-cache hash table entries: 512
[ 2.510651] < 0.004010> CPU: Testing write buffer coherency: ok
[ 2.514594] < 0.003943> NET: Registered protocol family 16
[ 2.518678] < 0.004084> bio: create slab <bio-0> at 0
[ 2.522584] < 0.003906> NET: Registered protocol family 2
[ 2.526639] < 0.004055> IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 2.530592] < 0.003953> TCP established hash table entries: 4096 (order: 3, 32768 bytes)
[ 2.539728] < 0.009136> TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
[ 2.542647] < 0.002919> TCP: Hash tables configured (established 4096 bind 4096)
[ 2.542696] < 0.000049> TCP reno registered
[ 2.546573] < 0.003877> NET: Registered protocol family 1
[ 2.555898] < 0.009325> NetWinder Floating Point Emulator V0.97 (extended precision)
[ 2.555969] < 0.000071> msgmni has been set to 246
[ 2.560063] < 0.004094> io scheduler noop registered (default)
[ 2.560109] < 0.000046> i.MX Framebuffer driver
[ 2.564237] < 0.004128> Serial: IMX driver
[ 2.567840] < 0.003603> Platform driver 'imx-uart' needs updating - please use dev_pm_ops
[ 2.571898] < 0.004058> imx-uart.0: ttymxc0 at MMIO 0x1000a000 (irq = 20) is a IMX
[ 2.576220] < 0.004322> console [ttymxc0] enabled
[ 2.583937] < 0.007717> imx-uart.1: ttymxc1 at MMIO 0x1000b000 (irq = 19) is a IMX
[ 2.590616] < 0.006679> imx-uart.2: ttymxc2 at MMIO 0x1000c000 (irq = 18) is a IMX
[ 2.590734] < 0.000118> FEC Ethernet Driver
[ 2.599694] < 0.008960> Platform driver 'fec' needs updating - please use dev_pm_ops
[ 2.599745] < 0.000051> fec: PHY @ 0x0, ID 0x00221613 -- KS8721BL
[ 2.612095] < 0.012350> physmap platform flash device: 02000000 at c0000000
[ 2.615634] < 0.003539> physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank
[ 2.620073] < 0.004439> Intel/Sharp Extended Query Table at 0x010A
[ 2.624187] < 0.004114> Intel/Sharp Extended Query Table at 0x010A
[ 2.627835] < 0.003648> Intel/Sharp Extended Query Table at 0x010A
[ 2.631976] < 0.004141> Intel/Sharp Extended Query Table at 0x010A
[ 2.636182] < 0.004206> Intel/Sharp Extended Query Table at 0x010A
[ 2.640245] < 0.004063> Using buffer write method
[ 2.642569] < 0.002324> Using auto-unlock on power-up/resume
[ 2.646576] < 0.004007> cfi_cmdset_0001: Erase suspend on write enabled
[ 2.650581] < 0.004005> 4 cmdlinepart partitions found on MTD device physmap-flash.0
[ 2.654627] < 0.004046> Creating 4 MTD partitions on "physmap-flash.0":
[ 2.658594] < 0.003967> 0x000000000000-0x000000040000 : "uboot"
[ 2.666646] < 0.008052> 0x000000040000-0x000000060000 : "ubootenv"
[ 2.674574] < 0.007928> 0x000000060000-0x000000360000 : "kernel"
[ 2.678570] < 0.003996> 0x000000360000-0x000002000000 : "root"
[ 2.690623] < 0.012053> NAND device: Manufacturer ID: 0x20, Chip ID: 0x36 (ST Micro NAND 64MiB 1,8V 8-bit)
[ 2.694572] < 0.003949> RedBoot partition parsing not available
[ 2.698575] < 0.004003> 4 cmdlinepart partitions found on MTD device mxc_nand
[ 2.706596] < 0.008021> Creating 4 MTD partitions on "mxc_nand":
[ 2.706645] < 0.000049> 0x000000000000-0x000000040000 : "uboot"
[ 2.717895] < 0.011250> 0x000000040000-0x000000060000 : "ubootenv"
[ 2.726578] < 0.008683> 0x000000060000-0x000000360000 : "kernel"
[ 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"
[ 5.014566] < 0.001409> UBI: MTD device size: 60 MiB
[ 5.018660] < 0.004094> UBI: number of good PEBs: 3880
[ 5.022585] < 0.003925> UBI: number of bad PEBs: 0
[ 5.026797] < 0.004212> UBI: max. allowed volumes: 89
[ 5.026849] < 0.000052> UBI: wear-leveling threshold: 4096
[ 5.030779] < 0.003930> UBI: number of internal volumes: 1
[ 5.034583] < 0.003804> UBI: number of user volumes: 1
[ 5.046572] < 0.011989> UBI: available PEBs: 0
[ 5.046622] < 0.000050> UBI: total number of reserved PEBs: 3880
[ 5.046657] < 0.000035> UBI: number of PEBs reserved for bad PEB handling: 38
[ 5.050606] < 0.003949> UBI: max/mean erase counter: 2/0
[ 5.050668] < 0.000062> UBI: image sequence number: 0
[ 5.058619] < 0.007951> UBI: background thread "ubi_bgt0d" started, PID 215
[ 5.062620] < 0.004001> oprofile: using timer interrupt.
[ 5.070584] < 0.007964> TCP cubic registered
[ 5.070637] < 0.000053> NET: Registered protocol family 17
[ 5.074624] < 0.003987> RPC: Registered udp transport module.
[ 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=
[ 6.630579] < 0.011927> UBIFS: recovery needed
[ 6.662655] < 0.032076> UBIFS: recovery completed
[ 6.666587] < 0.003932> UBIFS: mounted UBI device 0, volume 1, name "root"
[ 6.670570] < 0.003983> UBIFS: file system size: 58490880 bytes (57120 KiB, 55 MiB, 3808 LEBs)
[ 6.678572] < 0.008002> UBIFS: journal size: 7741440 bytes (7560 KiB, 7 MiB, 504 LEBs)
[ 6.682573] < 0.004001> UBIFS: media format: w4/r0 (latest is w4/r0)
[ 6.686572] < 0.003999> UBIFS: default compressor: lzo
[ 6.690562] < 0.003990> UBIFS: reserved for root: 0 bytes (0 KiB)
[ 6.694599] < 0.004037> VFS: Mounted root (ubifs filesystem) on device 0:12.
[ 6.702568] < 0.007969> Freeing init memory: 100K
init started: BusyBox v1.13.4 (2009-08-06 08:30:14 CEST)
[ 7.050625] < 0.187504> mounting filesystems...done.
[ 7.078608] < 0.027983> running rc.d services...
[ 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
[ 8.918710] < 0.107613> syslogd starting
[ 9.050585] < 0.131875> tweaking ondemand scaling governor
[ 10.010600] < 0.960015> Starting system message bus: dbus.
[ 10.118607] < 0.108007> /etc/rc.d/S16openssh: .: line 11: can't open /lib/init/initmethod-bbinit-functions.sh
[ 10.122561] < 0.003954> run-parts: /etc/rc.d/S16openssh exited with code 2
[ 10.246641] < 0.124080> Starting telnetd...
[ 10.442761] < 0.196120> sound not supported, skipping mixer state
[ 10.756354] < 0.313593> sound: restoring
[ 10.940567] < 0.184213> alsactl: load_state:1608: No soundcards found...
[ 11.046578] < 0.106011> starting network interfaces...
[ 11.370586] < 0.324008> ALSA lib confmisc.c:768:(parse_card) cannot find card '0'
[ 11.377491] < 0.006905> ALSA lib conf.c:3513:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory
[ 11.384742] < 0.007251> ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
[ 11.392825] < 0.008083> ALSA lib conf.c:3513:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory
[ 11.398567] < 0.005742> ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name
[ 11.410599] < 0.012032> ALSA lib conf.c:3513:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
[ 11.418625] < 0.008026> ALSA lib conf.c:3985:(snd_config_expand) Evaluate error: No such file or directory
[ 11.422605] < 0.003980> ALSA lib pcm.c:2202:(snd_pcm_open_noupdate) Unknown PCM default
[ 11.428764] < 0.006159> aplay: main:590: audio open error: No such file or directory
[ 11.490669] < 0.061905> ip: RTNETLINK answers: File exists
[ 12.150608] < 0.659939> ip: cannot find device "can0"
[ 12.213228] < 0.062620> ip: SIOCGIFFLAGS: No such device
[ 12.314609] < 0.101381> lighttpd: starting
[ 12.767898] < 0.453289> lighttpd: done
[ 12.846591] < 0.078693> pure-ftpd: no /etc/pure-ftpd.defaults found.
[ 12.914630] < 0.068039> /usr/sbin/pure-ftpd
[ 13.035649] < 0.121019> pure-ftpd: starting pure-ftpd: /usr/sbin/pure-ftpd
[ 13.082624] < 0.046975> pure-ftpd: no upload script defined, skipping
[ 13.090595] < 0.007971> done
[ 13.242901] < 0.152306> loading modules
[ 13.291592] < 0.048691> mx27_camera
[ 13.334611] < 0.043019> FATAL: Module mx27_camera not found.
[ 13.354552] < 0.019941> pca953x
[ 13.414614] < 0.060062> FATAL: Module pca953x not found.
[ 13.434597] < 0.019983> plat-ram
[ 13.479436] < 0.044839> FATAL: Module plat_ram not found.
[ 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>
Robert
--
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: Zan Lynx @ 2009-08-14 18:19 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>
Robert Schwebel wrote:
> - 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.
2.4s in uncompression? That seems like an obvious target for improvement.
Your kernel seems awfully large. 3104K code? You should definitely find
out what is making it that big and cut out everything you do not need.
You might even try some of the embedded system scripts that rip out all
the printk strings.
If you get the kernel size way down then use a uncompressed kernel and
it should boot a lot faster if the bottleneck is CPU speed.
However, it is probably IO speed. There could be something really wrong
and slow with your MTD. Does it DMA or is it doing something crazy like
using the CPU to read a byte at a time?
Or maybe its cheap and slow flash. In that case I think your only hope
is to make all the code as small as possible and/or find a different
flash filesystem that does not have to read so much of the device to
mount. Perhaps use a read-only compressed filesystem for the system
binaries and reflash it for software upgrades. Only init and mount the
writable flash for user-storable data well after system boot has finished.
--
Zan Lynx
zlynx@acm.org
"Knowledge is Power. Power Corrupts. Study Hard. Be Evil."
^ permalink raw reply
* Re: New fast(?)-boot results on ARM
From: Jamie Lokier @ 2009-08-14 18:46 UTC (permalink / raw)
To: Zan Lynx
Cc: Robert Schwebel, linux-kernel, linux-embedded, Arjan van de Ven,
Tim Bird, kernel
In-Reply-To: <4A85AAC4.7050505@acm.org>
Zan Lynx wrote:
> Or maybe its cheap and slow flash. In that case I think your only hope
> is to make all the code as small as possible and/or find a different
> flash filesystem that does not have to read so much of the device to
> mount. Perhaps use a read-only compressed filesystem for the system
> binaries and reflash it for software upgrades. Only init and mount the
> writable flash for user-storable data well after system boot has finished.
Fwiw, logfs claims to mount quickly, but I haven't heard much about it
in recent months and http://logfs.org/logfs/ implies it's not really
stable yet. But maybe if you're working on a prototype that doesn't
matter so much.
-- Jamie
^ permalink raw reply
* Re: New fast(?)-boot results on ARM
From: Robert Schwebel @ 2009-08-14 18:57 UTC (permalink / raw)
To: Zan Lynx; +Cc: linux-kernel, linux-embedded, Arjan van de Ven, Tim Bird, kernel
In-Reply-To: <4A85AAC4.7050505@acm.org>
Zan,
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.
However, I have a little bit the impression that most systems which are
hyped as "fast boot" out there are optimized so aggressively that they
are not really usable in real life applications any more. So we try to
configure the systems in a "realistic" way. I know that we won't get the
last milliseconds that way - but I'd like to find out how far we can go.
> Your kernel seems awfully large. 3104K code? You should definitely find
> out what is making it that big and cut out everything you do not need.
Definitely, will audit again.
> You might even try some of the embedded system scripts that rip out
> all the printk strings.
Hmm, that's definitely in the "last-minute-before-product" category.
> If you get the kernel size way down then use a uncompressed kernel and
> it should boot a lot faster if the bottleneck is CPU speed.
I'll try that.
> However, it is probably IO speed. There could be something really wrong
> and slow with your MTD. Does it DMA or is it doing something crazy like
> using the CPU to read a byte at a time?
Will check.
> Or maybe its cheap and slow flash. In that case I think your only hope
> is to make all the code as small as possible and/or find a different
> flash filesystem that does not have to read so much of the device to
> mount. Perhaps use a read-only compressed filesystem for the system
> binaries and reflash it for software upgrades. Only init and mount the
> writable flash for user-storable data well after system boot has
> finished.
That would be also a last-minute change, but surely worth to be
evaluated.
We recently changed from jffs2 to ubifs and hoped to gain speed during
that step.
Thanks for your feedback!
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: Robert Schwebel @ 2009-08-14 18:58 UTC (permalink / raw)
To: Jamie Lokier
Cc: Zan Lynx, linux-kernel, linux-embedded, Arjan van de Ven,
Tim Bird, kernel
In-Reply-To: <20090814184651.GA12021@shareable.org>
On Fri, Aug 14, 2009 at 07:46:51PM +0100, Jamie Lokier wrote:
> Zan Lynx wrote:
> > Or maybe its cheap and slow flash. In that case I think your only
> > hope is to make all the code as small as possible and/or find a
> > different flash filesystem that does not have to read so much of the
> > device to mount. Perhaps use a read-only compressed filesystem for
> > the system binaries and reflash it for software upgrades. Only init
> > and mount the writable flash for user-storable data well after
> > system boot has finished.
>
> Fwiw, logfs claims to mount quickly, but I haven't heard much about it
> in recent months and http://logfs.org/logfs/ implies it's not really
> stable yet. But maybe if you're working on a prototype that doesn't
> matter so much.
Is logfs ready for production in the meantime? Last time I checked it
was still more or less Jörn's pet project and ubifs seemed much more
mature.
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: Denys Vlasenko @ 2009-08-14 20:04 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 7:02 PM, Robert
Schwebel<r.schwebel@pengutronix.de> wrote:
> 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"
> [ 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.
> [ 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)
> [ 2.418729] < 0.001730> CPU: ARM926EJ-S [41069264] revision 4 (ARMv5TEJ), cr=00053177
> [ 2.423081] < 0.004352> CPU: VIVT data cache, VIVT instruction cache
> [ 2.426592] < 0.003511> Machine: phyCORE-i.MX27
...
> [ 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.
> [ 5.014566] < 0.001409> UBI: MTD device size: 60 MiB
> [ 5.018660] < 0.004094> UBI: number of good PEBs: 3880
> [ 5.022585] < 0.003925> UBI: number of bad PEBs: 0
> [ 5.026797] < 0.004212> UBI: max. allowed volumes: 89
> [ 5.026849] < 0.000052> UBI: wear-leveling threshold: 4096
> [ 5.030779] < 0.003930> UBI: number of internal volumes: 1
> [ 5.034583] < 0.003804> UBI: number of user volumes: 1
> [ 5.046572] < 0.011989> UBI: available PEBs: 0
> [ 5.046622] < 0.000050> UBI: total number of reserved PEBs: 3880
> [ 5.046657] < 0.000035> UBI: number of PEBs reserved for bad PEB handling: 38
> [ 5.050606] < 0.003949> UBI: max/mean erase counter: 2/0
> [ 5.050668] < 0.000062> UBI: image sequence number: 0
> [ 5.058619] < 0.007951> UBI: background thread "ubi_bgt0d" started, PID 215
> [ 5.062620] < 0.004001> oprofile: using timer interrupt.
> [ 5.070584] < 0.007964> TCP cubic registered
> [ 5.070637] < 0.000053> NET: Registered protocol family 17
> [ 5.074624] < 0.003987> RPC: Registered udp transport module.
> [ 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.
> [ 6.630579] < 0.011927> UBIFS: recovery needed
> [ 6.662655] < 0.032076> UBIFS: recovery completed
> [ 6.666587] < 0.003932> UBIFS: mounted UBI device 0, volume 1, name "root"
> [ 6.670570] < 0.003983> UBIFS: file system size: 58490880 bytes (57120 KiB, 55 MiB, 3808 LEBs)
> [ 6.678572] < 0.008002> UBIFS: journal size: 7741440 bytes (7560 KiB, 7 MiB, 504 LEBs)
> [ 6.682573] < 0.004001> UBIFS: media format: w4/r0 (latest is w4/r0)
> [ 6.686572] < 0.003999> UBIFS: default compressor: lzo
> [ 6.690562] < 0.003990> UBIFS: reserved for root: 0 bytes (0 KiB)
> [ 6.694599] < 0.004037> VFS: Mounted root (ubifs filesystem) on device 0:12.
> [ 6.702568] < 0.007969> Freeing init memory: 100K
So, about 4 seconds for kernel init (I subtracted DHCP and boot loader times).
And now userspace takes 7 seconds, mostly because it does not
parallelize boot process:
> init started: BusyBox v1.13.4 (2009-08-06 08:30:14 CEST)
> [ 7.050625] < 0.187504> mounting filesystems...done.
> [ 7.078608] < 0.027983> running rc.d services...
these services seem to start one by one:
> [ 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
> [ 8.918710] < 0.107613> syslogd starting
> [ 9.050585] < 0.131875> tweaking ondemand scaling governor
> [ 10.010600] < 0.960015> Starting system message bus: dbus.
...
> [ 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>
--
vda
^ permalink raw reply
* Re: New fast(?)-boot results on ARM
From: Robert Schwebel @ 2009-08-14 20:43 UTC (permalink / raw)
To: Denys Vlasenko
Cc: linux-kernel, linux-embedded, Arjan van de Ven, Tim Bird, kernel
In-Reply-To: <1158166a0908141304y70300ab3p899b0d4609efded9@mail.gmail.com>
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.
> > [ 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.
> > [ 2.418729] < 0.001730> CPU: ARM926EJ-S [41069264] revision 4 (ARMv5TEJ), cr=00053177
> > [ 2.423081] < 0.004352> CPU: VIVT data cache, VIVT instruction cache
> > [ 2.426592] < 0.003511> Machine: phyCORE-i.MX27
> ...
> > [ 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.
So it seems like our UBS is much slower than usual?
> > [ 5.014566] < 0.001409> UBI: MTD device size: 60 MiB
> > [ 5.018660] < 0.004094> UBI: number of good PEBs: 3880
> > [ 5.022585] < 0.003925> UBI: number of bad PEBs: 0
> > [ 5.026797] < 0.004212> UBI: max. allowed volumes: 89
> > [ 5.026849] < 0.000052> UBI: wear-leveling threshold: 4096
> > [ 5.030779] < 0.003930> UBI: number of internal volumes: 1
> > [ 5.034583] < 0.003804> UBI: number of user volumes: 1
> > [ 5.046572] < 0.011989> UBI: available PEBs: 0
> > [ 5.046622] < 0.000050> UBI: total number of reserved PEBs: 3880
> > [ 5.046657] < 0.000035> UBI: number of PEBs reserved for bad PEB handling: 38
> > [ 5.050606] < 0.003949> UBI: max/mean erase counter: 2/0
> > [ 5.050668] < 0.000062> UBI: image sequence number: 0
> > [ 5.058619] < 0.007951> UBI: background thread "ubi_bgt0d" started, PID 215
> > [ 5.062620] < 0.004001> oprofile: using timer interrupt.
> > [ 5.070584] < 0.007964> TCP cubic registered
> > [ 5.070637] < 0.000053> NET: Registered protocol family 17
> > [ 5.074624] < 0.003987> RPC: Registered udp transport module.
> > [ 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?
> So, about 4 seconds for kernel init (I subtracted DHCP and boot loader times).
>
> And now userspace takes 7 seconds, mostly because it does not
> parallelize boot process:
>
> > init started: BusyBox v1.13.4 (2009-08-06 08:30:14 CEST)
> > [ 7.050625] < 0.187504> mounting filesystems...done.
> > [ 7.078608] < 0.027983> running rc.d services...
>
> these services seem to start one by one:
>
> > [ 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
> > [ 8.918710] < 0.107613> syslogd starting
> > [ 9.050585] < 0.131875> tweaking ondemand scaling governor
> > [ 10.010600] < 0.960015> Starting system message bus: dbus.
> ...
> > [ 13.546627] < 0.024002> OSELAS(R)-phyCORE-trunk (PTXdist-1.99.svn/2009-08-06T08:37:25+0200)
Well, the application is started in the very beginning, so all the
services should start while the app is already gaining speed.
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: Linus Walleij @ 2009-08-14 21:01 UTC (permalink / raw)
To: Robert Schwebel
Cc: Zan Lynx, linux-kernel, linux-embedded, Arjan van de Ven,
Tim Bird, kernel
In-Reply-To: <20090814185731.GN13320@pengutronix.de>
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.
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.
Linus Walleij
^ permalink raw reply
* Re: New fast(?)-boot results on ARM
From: Robert Schwebel @ 2009-08-14 21:15 UTC (permalink / raw)
To: Linus Walleij
Cc: Robert Schwebel, Zan Lynx, linux-kernel, linux-embedded,
Arjan van de Ven, Tim Bird, kernel
In-Reply-To: <63386a3d0908141401t6050f39ey8d85213aeccf748a@mail.gmail.com>
On Fri, Aug 14, 2009 at 11:01:58PM +0200, Linus Walleij 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.
>
> 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.
We have also done that on NOR based systems, but I'm not sure if it will
work out for NAND as well.
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: Zan Lynx @ 2009-08-14 21:35 UTC (permalink / raw)
To: Linus Walleij
Cc: Robert Schwebel, linux-kernel, linux-embedded, Arjan van de Ven,
Tim Bird, kernel
In-Reply-To: <63386a3d0908141401t6050f39ey8d85213aeccf748a@mail.gmail.com>
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.
--
Zan Lynx
zlynx@acm.org
"Knowledge is Power. Power Corrupts. Study Hard. Be Evil."
^ 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