* 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: Matthieu CASTET @ 2009-08-11 13:51 UTC (permalink / raw)
To: Albin Tonnerre
Cc: Sam Ravnborg, Russell King - ARM Linux, Alain Knaff,
hpa@zytor.com, linux-kernel@vger.kernel.org,
linux-embedded@vger.kernel.org, akpm@linux-foundation.org
In-Reply-To: <20090811094418.GI9704@pc-ras4041.res.insa>
Albin Tonnerre a écrit :
> 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 ?
It is defined in libc ;)
You need either to provide a fake one, or use don't use libgcc.
Matthieu
^ permalink raw reply
* Re: [PATCH 4/6] Add support for LZO-compressed kernels for ARM
From: Sam Ravnborg @ 2009-08-11 13:39 UTC (permalink / raw)
To: Albin Tonnerre
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: <20090811094418.GI9704@pc-ras4041.res.insa>
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.
Sam
^ permalink raw reply
* conntrack disables network
From: Necati Demir @ 2009-08-11 12:23 UTC (permalink / raw)
To: linux-embedded
Hi,
I am using 2300SX (http://www.compactpc.com.tw/ebox-2300SX.htm).
When i enable conntrack in kernel configuration for NAT operations,
ethernet card does not work. This is really strange. I mean, i can see
eth0 in ifconfig output, but when i run "udhcpc -i eth0" it does not
get IP. I tried giving IP manually and i did. But it still does not
ping network.
When i disable conntrack, everything is fine again.
Any suggestion?
--
Necati Demir
http://demir.web.tr
http://blog.demir.web.tr
ndemir [~] demir.web.tr
necati83 [~] gmail.com
--------------------------------------
^ permalink raw reply
* Re: [PATCH 4/6] Add support for LZO-compressed kernels for ARM
From: Albin Tonnerre @ 2009-08-11 9:44 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: <20090807210816.GA29797@merkur.ravnborg.org>
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 ?
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: Sam Ravnborg @ 2009-08-07 21:08 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Albin Tonnerre, Matthieu CASTET, Alain Knaff, hpa@zytor.com,
linux-kernel@vger.kernel.org, linux-embedded@vger.kernel.org,
akpm@linux-foundation.org
In-Reply-To: <20090807200001.GE31543@n2100.arm.linux.org.uk>
On Fri, Aug 07, 2009 at 09:00:01PM +0100, Russell King - ARM Linux wrote:
> On Fri, Aug 07, 2009 at 03:55:24PM +0200, Albin Tonnerre wrote:
> > That's true for the actual kernel image, but not for the bootstrap code we use
> > when compiling compressed kernels. arch/arm/boot/compressed/Makefile uses
> > libgcc, unless I'm overlooking something here:
> >
> > arm-unknown-linux-uclibcgnueabi-ld -EL --defsym zreladdr=0x20008000
> > --defsym initrd_phys=0x20410000 --defsym params_phys=0x20000100 -p
> > --no-undefined -X
> > /home/albin/x-tools/arm-unknown-linux-uclibcgnueabi/lib/gcc/arm-unknown-linux-uclibcgnueabi/4.3.2/libgcc.a
> > -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 -o
> > arch/arm/boot/compressed/vmlinux
>
> It's because libgcc appears in the wrong place in the command line, and
> due to the way kbuild works, we can't get it into the right place easily.
>
> Linkers are sensitive to the order of archives on the command line - its
> pointless having an archive as the first file argument because none of
> the contained objects will ever be pulled in.
>
> Sam - any ideas how to solve this?
We could add libgcc as a prerequisite.
Untested patch below.
This is a ittle hackish - otherwise we have to change the
definition of ld or use a private version.
I added explanations for some of the linker symbols when
I was there. I cannot the ld options.
If you decide to use this it has my:
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Sam
diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index ce39dc5..4f980f2 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -87,15 +87,24 @@ 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
+
+libgcc = $(shell $(CC) $(KBUILD_CFLAGS) --print-libgcc-file-name)
# 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
+ $(addprefix $(obj)/, $(OBJS)) $(libgcc) FORCE
$(call if_changed,ld)
@:
Sam
^ permalink raw reply related
* Re: [PATCH 4/6] Add support for LZO-compressed kernels for ARM
From: H. Peter Anvin @ 2009-08-07 20:21 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Albin Tonnerre, Matthieu CASTET, Alain Knaff, sam@ravnborg.org,
linux-kernel@vger.kernel.org, linux-embedded@vger.kernel.org,
akpm@linux-foundation.org
In-Reply-To: <20090807200001.GE31543@n2100.arm.linux.org.uk>
On 08/07/2009 01:00 PM, Russell King - ARM Linux wrote:
> On Fri, Aug 07, 2009 at 03:55:24PM +0200, Albin Tonnerre wrote:
>> That's true for the actual kernel image, but not for the bootstrap code we use
>> when compiling compressed kernels. arch/arm/boot/compressed/Makefile uses
>> libgcc, unless I'm overlooking something here:
>>
>> arm-unknown-linux-uclibcgnueabi-ld -EL --defsym zreladdr=0x20008000
>> --defsym initrd_phys=0x20410000 --defsym params_phys=0x20000100 -p
>> --no-undefined -X
>> /home/albin/x-tools/arm-unknown-linux-uclibcgnueabi/lib/gcc/arm-unknown-linux-uclibcgnueabi/4.3.2/libgcc.a
>> -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 -o
>> arch/arm/boot/compressed/vmlinux
>
> It's because libgcc appears in the wrong place in the command line, and
> due to the way kbuild works, we can't get it into the right place easily.
>
> Linkers are sensitive to the order of archives on the command line - its
> pointless having an archive as the first file argument because none of
> the contained objects will ever be pulled in.
>
> Sam - any ideas how to solve this?
Can we use the group feature of ld for this?
-hpa
^ permalink raw reply
* Re: [PATCH 4/6] Add support for LZO-compressed kernels for ARM
From: Russell King - ARM Linux @ 2009-08-07 20:00 UTC (permalink / raw)
To: Albin Tonnerre
Cc: Matthieu CASTET, Alain Knaff, sam@ravnborg.org, hpa@zytor.com,
linux-kernel@vger.kernel.org, linux-embedded@vger.kernel.org,
akpm@linux-foundation.org
In-Reply-To: <20090807135524.GF4455@laptop>
On Fri, Aug 07, 2009 at 03:55:24PM +0200, Albin Tonnerre wrote:
> That's true for the actual kernel image, but not for the bootstrap code we use
> when compiling compressed kernels. arch/arm/boot/compressed/Makefile uses
> libgcc, unless I'm overlooking something here:
>
> arm-unknown-linux-uclibcgnueabi-ld -EL --defsym zreladdr=0x20008000
> --defsym initrd_phys=0x20410000 --defsym params_phys=0x20000100 -p
> --no-undefined -X
> /home/albin/x-tools/arm-unknown-linux-uclibcgnueabi/lib/gcc/arm-unknown-linux-uclibcgnueabi/4.3.2/libgcc.a
> -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 -o
> arch/arm/boot/compressed/vmlinux
It's because libgcc appears in the wrong place in the command line, and
due to the way kbuild works, we can't get it into the right place easily.
Linkers are sensitive to the order of archives on the command line - its
pointless having an archive as the first file argument because none of
the contained objects will ever be pulled in.
Sam - any ideas how to solve this?
^ permalink raw reply
* Re: [PATCH 4/6] Add support for LZO-compressed kernels for ARM
From: Albin Tonnerre @ 2009-08-07 13:55 UTC (permalink / raw)
To: Matthieu CASTET
Cc: Alain Knaff, Russell King - ARM Linux, sam@ravnborg.org,
hpa@zytor.com, linux-kernel@vger.kernel.org,
linux-embedded@vger.kernel.org, akpm@linux-foundation.org
In-Reply-To: <4A7C2BA4.7030408@parrot.com>
On Fri, Aug 07, 2009 at 03:27:00PM +0200, Matthieu CASTET wrote :
> Albin Tonnerre a écrit :
> > On Fri, Aug 07, 2009 at 01:50:03PM +0200, Matthieu CASTET wrote :
> >> Albin Tonnerre a écrit :
> >>> On Fri, Aug 07, 2009 at 11:36:56AM +0200, Alain Knaff wrote :
> >>>> On 08/07/09 11:24, Albin Tonnerre wrote:
> >>>>> Regards,
> >>>> Could it be that the patches that remove division (zutil.h and inflate.c)
> >>>> have somehow not been applied?
> >>> Indeed, they've not been applied. However, I'd rather try to understand why
> >>> exactly this is an issue when compiling with -Os and not -O2 instead of working
> >>> around it by removing the divisions.
> >> Look at the generated code.
> >> Arm doesn't have division instruction.
> >> May be at -Os gcc emit a call to the software division, but at -O2 it
> >> manage to optimise the division (transform it in shift, inline some
> >> builtin, ...).
> > Yes, I figured that out. What I don't get, though, is that it fails while the
> > software division symbol (__aeabi_uidivmod here) does seem to be provided by
> > libgcc.
> AFAIK we don't link the kernel with libgcc.
> That's why the kernel provide __aeabi_* in arch/arm/lib
That's true for the actual kernel image, but not for the bootstrap code we use
when compiling compressed kernels. arch/arm/boot/compressed/Makefile uses
libgcc, unless I'm overlooking something here:
arm-unknown-linux-uclibcgnueabi-ld -EL --defsym zreladdr=0x20008000
--defsym initrd_phys=0x20410000 --defsym params_phys=0x20000100 -p
--no-undefined -X
/home/albin/x-tools/arm-unknown-linux-uclibcgnueabi/lib/gcc/arm-unknown-linux-uclibcgnueabi/4.3.2/libgcc.a
-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 -o
arch/arm/boot/compressed/vmlinux
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: Matthieu CASTET @ 2009-08-07 13:27 UTC (permalink / raw)
To: Albin Tonnerre
Cc: Alain Knaff, Russell King - ARM Linux, sam@ravnborg.org,
hpa@zytor.com, linux-kernel@vger.kernel.org,
linux-embedded@vger.kernel.org, akpm@linux-foundation.org
In-Reply-To: <20090807130130.GE4455@laptop>
Albin Tonnerre a écrit :
> On Fri, Aug 07, 2009 at 01:50:03PM +0200, Matthieu CASTET wrote :
>> Albin Tonnerre a écrit :
>>> On Fri, Aug 07, 2009 at 11:36:56AM +0200, Alain Knaff wrote :
>>>> On 08/07/09 11:24, Albin Tonnerre wrote:
>
>>>>> Regards,
>
>>>> Could it be that the patches that remove division (zutil.h and inflate.c)
>>>> have somehow not been applied?
>
>>> Indeed, they've not been applied. However, I'd rather try to understand why
>>> exactly this is an issue when compiling with -Os and not -O2 instead of working
>>> around it by removing the divisions.
>
>> Look at the generated code.
>
>> Arm doesn't have division instruction.
>> May be at -Os gcc emit a call to the software division, but at -O2 it
>> manage to optimise the division (transform it in shift, inline some
>> builtin, ...).
>
> Yes, I figured that out. What I don't get, though, is that it fails while the
> software division symbol (__aeabi_uidivmod here) does seem to be provided by
> libgcc.
>
AFAIK we don't link the kernel with libgcc.
That's why the kernel provide __aeabi_* in arch/arm/lib
^ permalink raw reply
* Re: [PATCH 4/6] Add support for LZO-compressed kernels for ARM
From: Albin Tonnerre @ 2009-08-07 13:01 UTC (permalink / raw)
To: Matthieu CASTET
Cc: Alain Knaff, Russell King - ARM Linux, sam@ravnborg.org,
hpa@zytor.com, linux-kernel@vger.kernel.org,
linux-embedded@vger.kernel.org, akpm@linux-foundation.org
In-Reply-To: <4A7C14EB.1060701@parrot.com>
On Fri, Aug 07, 2009 at 01:50:03PM +0200, Matthieu CASTET wrote :
> Albin Tonnerre a écrit :
> > On Fri, Aug 07, 2009 at 11:36:56AM +0200, Alain Knaff wrote :
> >> On 08/07/09 11:24, Albin Tonnerre wrote:
> >>> Regards,
> >> Could it be that the patches that remove division (zutil.h and inflate.c)
> >> have somehow not been applied?
> > Indeed, they've not been applied. However, I'd rather try to understand why
> > exactly this is an issue when compiling with -Os and not -O2 instead of working
> > around it by removing the divisions.
> Look at the generated code.
> Arm doesn't have division instruction.
> May be at -Os gcc emit a call to the software division, but at -O2 it
> manage to optimise the division (transform it in shift, inline some
> builtin, ...).
Yes, I figured that out. What I don't get, though, is that it fails while the
software division symbol (__aeabi_uidivmod here) does seem to be provided by
libgcc.
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: Matthieu CASTET @ 2009-08-07 11:50 UTC (permalink / raw)
To: Albin Tonnerre
Cc: Alain Knaff, Russell King - ARM Linux, sam@ravnborg.org,
hpa@zytor.com, linux-kernel@vger.kernel.org,
linux-embedded@vger.kernel.org, akpm@linux-foundation.org
In-Reply-To: <20090807102117.GB4455@laptop>
Albin Tonnerre a écrit :
> On Fri, Aug 07, 2009 at 11:36:56AM +0200, Alain Knaff wrote :
>> On 08/07/09 11:24, Albin Tonnerre wrote:
>
>>> Regards,
>
>> Could it be that the patches that remove division (zutil.h and inflate.c)
>> have somehow not been applied?
>
> Indeed, they've not been applied. However, I'd rather try to understand why
> exactly this is an issue when compiling with -Os and not -O2 instead of working
> around it by removing the divisions.
>
Look at the generated code.
Arm doesn't have division instruction.
May be at -Os gcc emit a call to the software division, but at -O2 it
manage to optimise the division (transform it in shift, inline some
builtin, ...).
Matthieu
^ permalink raw reply
* Re: [PATCH 4/6] Add support for LZO-compressed kernels for ARM
From: Alain Knaff @ 2009-08-07 11:29 UTC (permalink / raw)
To: Albin Tonnerre
Cc: Russell King - ARM Linux, sam, hpa, linux-kernel, linux-embedded,
akpm
In-Reply-To: <20090807102117.GB4455@laptop>
On 08/07/09 12:21, Albin Tonnerre wrote:
> Indeed, they've not been applied. However, I'd rather try to understand why
> exactly this is an issue when compiling with -Os and not -O2 instead of working
> around it by removing the divisions.
>
> Regards,
Well, I for myself couldn't get it to compile _at_all_ for ARM as long as
there were any division operations in the code. My theory was that the ARM
processor doesn't have native division, and that this is being supplied by
some kind of run-time library, which is not linked with when building the
pre-boot environment. But if it works with some compilation flags but not
others, something more complex must be going on...
... or could it be that with some flags, the compiler generates "division
emulation" code, but not with others (such as when optimizing for size?)
Regards,
Alain
^ permalink raw reply
* Re: [PATCH 4/6] Add support for LZO-compressed kernels for ARM
From: Albin Tonnerre @ 2009-08-07 10:21 UTC (permalink / raw)
To: Alain Knaff
Cc: Russell King - ARM Linux, sam, hpa, linux-kernel, linux-embedded,
akpm
In-Reply-To: <4A7BF5B8.4030907@knaff.lu>
On Fri, Aug 07, 2009 at 11:36:56AM +0200, Alain Knaff wrote :
> On 08/07/09 11:24, Albin Tonnerre wrote:
> > 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.)
> > I also happen to have issues related to the linker not finding __aeabi_uidivmod,
> > but only when compiling with CONFIG_CC_OPTIMIZE_FOR_SIZE. Is it similar for you,
> > or does it also fail when compiling with -O2 ?
> >> 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.
> > I don't have my ARM platforms at hand, but I'll so these comparisons in a couple
> > days when I access to them again.
> > Regards,
> Could it be that the patches that remove division (zutil.h and inflate.c)
> have somehow not been applied?
Indeed, they've not been applied. However, I'd rather try to understand why
exactly this is an issue when compiling with -Os and not -O2 instead of working
around it by removing the divisions.
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: Alain Knaff @ 2009-08-07 9:36 UTC (permalink / raw)
To: Albin Tonnerre
Cc: Russell King - ARM Linux, sam, hpa, linux-kernel, linux-embedded,
akpm
In-Reply-To: <20090807092423.GA4455@laptop>
On 08/07/09 11:24, Albin Tonnerre wrote:
> 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.)
>
> I also happen to have issues related to the linker not finding __aeabi_uidivmod,
> but only when compiling with CONFIG_CC_OPTIMIZE_FOR_SIZE. Is it similar for you,
> or does it also fail when compiling with -O2 ?
>
>> 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.
>
> I don't have my ARM platforms at hand, but I'll so these comparisons in a couple
> days when I access to them again.
>
> Regards,
Could it be that the patches that remove division (zutil.h and inflate.c)
have somehow not been applied?
Regards,
Alain
^ permalink raw reply
* Re: [PATCH 4/6] Add support for LZO-compressed kernels for ARM
From: Russell King - ARM Linux @ 2009-08-07 9:34 UTC (permalink / raw)
To: Albin Tonnerre; +Cc: sam, hpa, alain, linux-kernel, linux-embedded, akpm
In-Reply-To: <20090807092423.GA4455@laptop>
On Fri, Aug 07, 2009 at 11:24:52AM +0200, Albin Tonnerre wrote:
> I also happen to have issues related to the linker not finding __aeabi_uidivmod,
> but only when compiling with CONFIG_CC_OPTIMIZE_FOR_SIZE. Is it similar for you,
> or does it also fail when compiling with -O2 ?
I tend not to build with -O2 because it seems to tickle compiler bugs
(which is the reverse of -Os on x86.) I'll give it a go over the
next few days.
^ permalink raw reply
* Re: [PATCH 4/6] Add support for LZO-compressed kernels for ARM
From: Albin Tonnerre @ 2009-08-07 9:24 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.)
I also happen to have issues related to the linker not finding __aeabi_uidivmod,
but only when compiling with CONFIG_CC_OPTIMIZE_FOR_SIZE. Is it similar for you,
or does it also fail when compiling with -O2 ?
> 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.
I don't have my ARM platforms at hand, but I'll so these comparisons in a couple
days when I access to them again.
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: Russell King - ARM Linux @ 2009-08-06 22:40 UTC (permalink / raw)
To: Albin Tonnerre; +Cc: sam, hpa, alain, linux-kernel, linux-embedded, akpm
In-Reply-To: <1249311501-23102-4-git-send-email-albin.tonnerre@free-electrons.com>
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.)
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.
I was going to get those numbers, but the platform I was going to run
the tests on has died on me today.
^ permalink raw reply
* Re: New MMC maintainer needed
From: Pierre Ossman @ 2009-08-06 8:54 UTC (permalink / raw)
To: David Brownell
Cc: Andrew Morton, linux-kernel, linux-embedded, nico, nicolas.ferre,
hskinnemoen, tony, manuel.lauss, mirq-linux, ppisa,
jarkko.lavinen, ben, saschasommer, avorontsov, oakad, ian,
HaraldWelte, JosephChan, adrian.hunter
In-Reply-To: <200908031851.24375.david-b@pacbell.net>
[-- Attachment #1: Type: text/plain, Size: 1757 bytes --]
On Mon, 3 Aug 2009 18:51:23 -0700
David Brownell <david-b@pacbell.net> wrote:
> On Friday 31 July 2009, Pierre Ossman wrote:
> > Restoring back the system state from MMC after a successful hibernation
> > http://marc.info/?t=124818534700003&r=1&w=2
> >
> > I don't agree with this approach. The point of the workqueue is so that
> > the kernel can do things in parallel, so this patch is a step back. The
> > problem is really with how the kernel doesn't properly cope with
> > asynchronous disk scanning during bootup. The root_delay parameter was
> > added for this for the "normal" case, but it seems more work is needed.
>
(confusion on my end, I wasn't thinking about root_delay but rootwait)
> Doesn't handing of resumes needs more attention overall?
>
Very much so. I haven't given that area much love since a) I haven't
had the time, b) I don't have any systems with fancy enough suspend
handling to do anything interesting.
> Example, root on eMMC (e.g. a 32-MByte non-removable chip) wouldn't
> resume at all well the last time I checked ... mounted file systems
> (not just root) made trouble. Hardware that reliably reports card
> insert/remove was rude in the same ways.
The general lack of removal detection during suspend tends to make
everything more complicated than one would like. But I'm sure it's
manageable just as long as someone puts enough time into it. I'm still
very much opposed to just assuming that the user never removes the card
during suspend though.
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 2/6] include/linux/unaligned/{l,b}e_byteshift.h: Fix usage for compressed kernels
From: Russell King - ARM Linux @ 2009-08-05 21:19 UTC (permalink / raw)
To: Albin Tonnerre
Cc: Andrew Morton, sam, hpa, alain, linux-kernel, linux-embedded
In-Reply-To: <20090805092956.GD5854@laptop>
On Wed, Aug 05, 2009 at 11:29:56AM +0200, Albin Tonnerre wrote:
> linux/kernel.h brings at least:
> extern int console_printk[];
> extern const char hex_asc[];
> which causes errors at link-time as they are not available when
> compiling the pre-boot environement. There are also a few others:
To be clear, for Andrew's benefit, the reason this happens is because
we disable the 'static' when building on ARM - this is because we build
the decompressor with -fPIC, so we can relocate _just_ the data segment
without writing at all to the text segment.
This is so that we can flash the compressed image into read only memory
and have the kernel boot directly from that memory, without having to
have an expensive and unnecessary copy.
Having static data and functions causes complications which make this
impossible to otherwise achieve. I don't remember the details, I'm not
an expert on the ARM shared library stuff.
^ permalink raw reply
* Embedded Linux Conference 2009 videos
From: Michael Opdenacker @ 2009-08-05 13:04 UTC (permalink / raw)
To: linux-embedded mailing list
Greetings,
We are proud to release the videos that we took at ELC 2009 in San
Francisco:
http://free-electrons.com/blog/elc-2009-videos/
In particular, don't miss the "Embedded Linux and Mainline Kernel"
keynote from David Woodhouse, and the "Embedded Linux Kernel Features
and Development" panel with Jonathan Corbet, Matt Mackall, David
Woodhouse and Tim Bird. There are lots of other talks related to the
kernel on embedded platforms.
Some of the videos are now in HD resolution, which should now make it
possible to read the slides directly from the video.
Cheers,
Satoru Ueda, Tim Bird, Thomas Petazzoni and Michael Opdenacker.
--
Michael Opdenacker, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 2/6] include/linux/unaligned/{l,b}e_byteshift.h: Fix usage for compressed kernels
From: Albin Tonnerre @ 2009-08-05 9:29 UTC (permalink / raw)
To: Andrew Morton; +Cc: sam, hpa, linux, alain, linux-kernel, linux-embedded
In-Reply-To: <20090804155550.3203f5f4.akpm@linux-foundation.org>
On Tue, Aug 04, 2009 at 03:55:50PM -0700, Andrew Morton wrote :
> On Mon, 3 Aug 2009 16:58:17 +0200
> Albin Tonnerre <albin.tonnerre@free-electrons.com> wrote:
> > When unaligned accesses are required for uncompressing a kernel (such as
> > for LZO decompression on ARM in a patch that follows), including
> > <linux/kernel.h> causes issues as it brings in a lot of things that are
> > not available in the decompression environment.
> > However, those files apparently use nothing from <linux/kernel.h>, all
> > they need is the declaration of types such as u32 or u64, so
> > <linux/types.h> should be enough
> Again, please provide a full description of thes "issues" which a patch
> addresses so that the patch's importance can be understood by others,
> thanks.
linux/kernel.h brings at least:
extern int console_printk[];
extern const char hex_asc[];
which causes errors at link-time as they are not available when
compiling the pre-boot environement. There are also a few others:
arch/arm/boot/compressed/misc.o: In function `valid_user_regs':
/home/albin/devel/free-electrons/gits/linux-2.6/arch/arm/include/asm/ptrace.h:158: undefined reference to `elf_hwcap'
arch/arm/boot/compressed/misc.o: In function `console_silent':
/home/albin/devel/free-electrons/gits/linux-2.6/include/linux/kernel.h:292: undefined reference to `console_printk'
arch/arm/boot/compressed/misc.o: In function `console_verbose':
/home/albin/devel/free-electrons/gits/linux-2.6/include/linux/kernel.h:297: undefined reference to `console_printk'
arch/arm/boot/compressed/misc.o: In function `pack_hex_byte':
/home/albin/devel/free-electrons/gits/linux-2.6/include/linux/kernel.h:360: undefined reference to `hex_asc'
arch/arm/boot/compressed/misc.o: In function `hweight_long':
/home/albin/devel/free-electrons/gits/linux-2.6/include/linux/bitops.h:45: undefined reference to `hweight32'
arch/arm/boot/compressed/misc.o: In function `__cmpxchg_local_generic':
/home/albin/devel/free-electrons/gits/linux-2.6/include/asm-generic/cmpxchg-local.h:21: undefined reference to `wrong_size_cmpxchg'
/home/albin/devel/free-electrons/gits/linux-2.6/include/asm-generic/cmpxchg-local.h:42: undefined reference to `wrong_size_cmpxchg'
arch/arm/boot/compressed/misc.o: In function `__xchg':
/home/albin/devel/free-electrons/gits/linux-2.6/arch/arm/include/asm/system.h:309: undefined reference to `__bad_xchg'
make[2]: *** [arch/arm/boot/compressed/vmlinux] Error 1
make[1]: *** [arch/arm/boot/compressed/vmlinux] Error 2
Regards,
--
Albin Tonnerre, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 3/6] Add support for LZO-compressed kernels
From: Albin Tonnerre @ 2009-08-05 9:19 UTC (permalink / raw)
To: Andrew Morton; +Cc: sam, hpa, linux, alain, linux-kernel, linux-embedded
In-Reply-To: <20090804160043.82b256d8.akpm@linux-foundation.org>
On Tue, Aug 04, 2009 at 04:00:43PM -0700, Andrew Morton wrote :
> On Mon, 3 Aug 2009 16:58:18 +0200
> Albin Tonnerre <albin.tonnerre@free-electrons.com> wrote:
> > This is the first part of the lzo patch
> > The lzo compressor is worse than gzip at compression, but faster at
> > extraction. Here are some figures for an ARM board I'm working on:
> > Uncompressed size: 3.24Mo
> > gzip 1.61Mo 0.72s
> > lzo 1.75Mo 0.48s
> > So for a compression ratio that is still relatively close to gzip, it's
> > much faster to extract, at least in that case.
> Is 3.2Mb a typical kernel size for small systems? It sounds large.
This one actually embeds an initramfs which accounts for about half of the size.
> > +#ifdef STATIC
> What is this STATIC thing for?
That's what is currently used to test whether you're compiling the pre-boot
environment. eg. include/linux/decompress/mm.h uses this to determine whether it
should provide a malloc() implementation or simply #define malloc(a) kmalloc(a, GFP_KERNEL),
and a lot of similar things
--
Albin Tonnerre, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 1/6] lib/decompress_*: only include <linux/slab.h> if STATIC is not defined
From: Phillip Lougher @ 2009-08-05 2:06 UTC (permalink / raw)
To: Andrew Morton
Cc: Albin Tonnerre, sam, hpa, linux, alain, linux-kernel,
linux-embedded
In-Reply-To: <20090804180854.d5dbb07f.akpm@linux-foundation.org>
Andrew Morton wrote:
> On Wed, 05 Aug 2009 01:47:57 +0100 Phillip Lougher <phillip@lougher.demon.co.uk> wrote:
>
>>
>> What do you normally do in this situation?
>
> I normally fix the rejects ;)
>
> But I'd like to confirm that the two patches don't fix the same thing
> via different means. Lacking a full description of Albin's "issues",
> that's hard to determine. They do appear to be unrelated.
>
No they're not fixing the same thing.
Albin's patch is moving #include <slab.h> inside the #ifndef STATIC ...
#endif code segment. This ensures that <slab.h>
isn't included when the file is being built in the stripped down
pre-boot environment. I imagine Albin's issues is that slab.h
pulls in a lot of definitions unnecessary in the pre-boot
environment and which rely on things which are missing
in the stripped down pre-boot environment.
My changes to the #ifndef STATIC logic defines PREBOOT if
STATIC is defined. My patch uses the PREBOOT definition
later to define the decompress wrapper function, which is only
needed in the preboot environment.
i.e.
#ifdef STATIC
#define PREBOOT
#else
#include <linux/decompress/unlzma.h>
#endif
...
Lots of code
...
#ifdef PREBOOT
static int INIT decompress.....
#endif
Obvious question, why doesn't my patch use STATIC here rather than
PREBOOT? The header file <linux/decompress/unlzma.h> defines STATIC, .i.e
the #ifndef STATIC case defines STATIC via an include file, which makes
decisions on STATIC later in the file impossible.
>> I'm happy to send a revised
>> bzip2-lzma-remove-nasty-uncompressed-size-hack-in-pre-boot-environment.patch
>> that would apply cleanly on-top of Alvin's patch, but, this will obviously
>> create dependencies on his patch being applied.
>
> Reworked
> lib-decompress_-only-include-linux-slabh-if-static-is-not-defined.patch:
The patch looks OK.
Thanks
Phillip
^ permalink raw reply
* Re: New MMC maintainer needed
From: David VomLehn @ 2009-08-05 1:42 UTC (permalink / raw)
To: David Brownell
Cc: Pierre Ossman, Andrew Morton, linux-kernel, linux-embedded, nico,
nicolas.ferre, hskinnemoen, tony, manuel.lauss, mirq-linux, ppisa,
jarkko.lavinen, ben, saschasommer, avorontsov, oakad, ian,
HaraldWelte, JosephChan, adrian.hunter
In-Reply-To: <200908031851.24375.david-b@pacbell.net>
On Mon, Aug 03, 2009 at 06:51:23PM -0700, David Brownell wrote:
> On Friday 31 July 2009, Pierre Ossman wrote:
> > Restoring back the system state from MMC after a successful hibernation
> > http://marc.info/?t=124818534700003&r=1&w=2
> >
> > I don't agree with this approach. The point of the workqueue is so that
> > the kernel can do things in parallel, so this patch is a step back. The
> > problem is really with how the kernel doesn't properly cope with
> > asynchronous disk scanning during bootup. The root_delay parameter was
> > added for this for the "normal" case, but it seems more work is needed.
>
> Doesn't handing of resumes needs more attention overall?
>
> Example, root on eMMC (e.g. a 32-MByte non-removable chip) wouldn't
> resume at all well the last time I checked ... mounted file systems
> (not just root) made trouble. Hardware that reliably reports card
> insert/remove was rude in the same ways.
>
> - Dave
I've been half- (or less) watching this discussion, but I'm sort of thinking
that one piece of this might be a patch I just reposted that provides for
synchronizing the discovery/initialization of devices during start up with
their use. One thing I expect it to do is to largely eliminate the need for
root_delay. It currently knows nothing about resuming, but perhaps it should.
Since the patch touches USB and SCSI, as well as some core kernel pieces, it
was posted to a bunch of places, but by tomorrow you should be able to find it
by searching for "initdev" in the kernel mailing list archives.
David VomLehn
^ 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