* [PATCH 1/5] lib/decompress_*: only include <linux/slab.h> if STATIC is not defined
From: Albin Tonnerre @ 2009-07-22 14:01 UTC (permalink / raw)
To: linux, hpa; +Cc: alain, linux-kernel, linux-embedded, Albin Tonnerre
These includes were added by 079effb6933f34b9b1b67b08bd4fd7fb672d16ef to
fix the build when using kmemtrace. However this is not necessary when
used to create a compressed kernel, and actually creates issues (brings
a lot of things unavailable in the decompression environment), so don't
include it if STATIC is defined.
Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
---
lib/decompress_bunzip2.c | 2 +-
lib/decompress_inflate.c | 2 +-
lib/decompress_unlzma.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/decompress_bunzip2.c b/lib/decompress_bunzip2.c
index 708e2a8..14b0c7d 100644
--- a/lib/decompress_bunzip2.c
+++ b/lib/decompress_bunzip2.c
@@ -47,10 +47,10 @@
#ifndef STATIC
#include <linux/decompress/bunzip2.h>
+#include <linux/slab.h>
#endif /* !STATIC */
#include <linux/decompress/mm.h>
-#include <linux/slab.h>
#ifndef INT_MAX
#define INT_MAX 0x7fffffff
diff --git a/lib/decompress_inflate.c b/lib/decompress_inflate.c
index e36b296..fc30d50 100644
--- a/lib/decompress_inflate.c
+++ b/lib/decompress_inflate.c
@@ -19,11 +19,11 @@
#include "zlib_inflate/inflate.h"
#include "zlib_inflate/infutil.h"
+#include <linux/slab.h>
#endif /* STATIC */
#include <linux/decompress/mm.h>
-#include <linux/slab.h>
#define INBUF_LEN (16*1024)
diff --git a/lib/decompress_unlzma.c b/lib/decompress_unlzma.c
index 32123a1..f078c88 100644
--- a/lib/decompress_unlzma.c
+++ b/lib/decompress_unlzma.c
@@ -31,10 +31,10 @@
#ifndef STATIC
#include <linux/decompress/unlzma.h>
+#include <linux/slab.h>
#endif /* STATIC */
#include <linux/decompress/mm.h>
-#include <linux/slab.h>
#define MIN(a, b) (((a) < (b)) ? (a) : (b))
--
1.6.0.4
^ permalink raw reply related
* Re: [RFC] move __devinit or __init printk constant format strings to __devinitconst or __initdata?
From: Matt Mackall @ 2009-07-22 5:17 UTC (permalink / raw)
To: Joe Perches
Cc: David Daney, linux-embedded, linux-kernel, Paul Gortmaker,
David Woodhouse, Tim Bird
In-Reply-To: <1248238202.31365.576.camel@Joe-Laptop.home>
On Tue, 2009-07-21 at 21:50 -0700, Joe Perches wrote:
> On Tue, 2009-07-21 at 20:28 -0500, Matt Mackall wrote:
> > On Tue, 2009-07-21 at 16:50 -0700, David Daney wrote:
> > > It would be tricky, the string data from the entire compilation unit is
> > > intermingled. You would have to separate out only those strings
> > > referenced from __init sections into their own section and fix up all
> > > symbols and relocations that were affected.
> > Exactly. Annoying but not impossible.
>
> But faster and likely easier to do once in source.
How long have you been hanging out here, Joe? You really thing it's
going to be EASY to push this change to literally thousands of drivers?
Your idea may work but it isn't pretty and also isn't an obvious big win
and is therefore going to hit a lot of friction from lots of different
people. It's already getting friction from me and I actually care about
this sort of thing.
That effort would be better spent working on something transparent,
automatic, and painless. Something people won't put up a fight about.
> > > Probably easier would be to use the plug-in feature that will be part of
> > > GCC-4.5 (or will that be called GCC-5.0??), and create a special Linux
> > > kernel GCC plug-in that just emits the __init literal strings to the
> > > proper section to begin with.
>
> Which is what the proposed marking would
> more or less do today.
>
> > > We don't want the kernel to get left
> > > behind in the GCC plug-in race.
>
> Any guess when gcc 4.5/5.0 might become available?
> It's in stage 1 now. Mid 2010 or so?
>
> 4.4.0 was April 21, 2009
> 4.3.0 was March 5, 2008
> 4.2.0 was May 13, 2007
>
> Could you please send me what you think is a
> reasonable .config for an embedded box.
Lots of devices have only MTD, JFFS, ethernet, and one other driver like
wifi.
--
http://selenic.com : development and support for Mercurial and Linux
^ permalink raw reply
* Re: [RFC] move __devinit or __init printk constant format strings to __devinitconst or __initdata?
From: Joe Perches @ 2009-07-22 4:50 UTC (permalink / raw)
To: Matt Mackall
Cc: David Daney, linux-embedded, linux-kernel, Paul Gortmaker,
David Woodhouse, Tim Bird
In-Reply-To: <1248226085.10466.251.camel@calx>
On Tue, 2009-07-21 at 20:28 -0500, Matt Mackall wrote:
> On Tue, 2009-07-21 at 16:50 -0700, David Daney wrote:
> > It would be tricky, the string data from the entire compilation unit is
> > intermingled. You would have to separate out only those strings
> > referenced from __init sections into their own section and fix up all
> > symbols and relocations that were affected.
> Exactly. Annoying but not impossible.
But faster and likely easier to do once in source.
> > Probably easier would be to use the plug-in feature that will be part of
> > GCC-4.5 (or will that be called GCC-5.0??), and create a special Linux
> > kernel GCC plug-in that just emits the __init literal strings to the
> > proper section to begin with.
Which is what the proposed marking would
more or less do today.
> > We don't want the kernel to get left
> > behind in the GCC plug-in race.
Any guess when gcc 4.5/5.0 might become available?
It's in stage 1 now. Mid 2010 or so?
4.4.0 was April 21, 2009
4.3.0 was March 5, 2008
4.2.0 was May 13, 2007
Could you please send me what you think is a
reasonable .config for an embedded box.
cheers, Joe
^ permalink raw reply
* Re: [RFC] move __devinit or __init printk constant format strings to __devinitconst or __initdata?
From: Matt Mackall @ 2009-07-22 1:28 UTC (permalink / raw)
To: David Daney
Cc: Joe Perches, linux-embedded, linux-kernel, Paul Gortmaker,
David Woodhouse, Tim Bird
In-Reply-To: <4A665442.1010006@caviumnetworks.com>
On Tue, 2009-07-21 at 16:50 -0700, David Daney wrote:
> Joe Perches wrote:
> > On Tue, 2009-07-21 at 17:57 -0500, Matt Mackall wrote:
> >> On Tue, 2009-07-21 at 14:56 -0700, Joe Perches wrote:
> >>> On Tue, 2009-07-21 at 16:48 -0500, Matt Mackall wrote:
> >>>> On Tue, 2009-07-21 at 14:20 -0700, Joe Perches wrote:
> >>>>> Is moving constant string formats to __devinitconst or __initdata
> >>>>> useful for embedded environments?
> >>>> Interesting notion, but not worth the trouble in my mind. I think it's
> >>>> more worthwhile to look into automatic such stuff in the build somehow.
> >>> I think it's not possible today to get gcc to mark
> >>> the format strings without source modification.
> >> Yep, that's why I specifically said 'build'. It can probably be done in
> >> a post-processing step with some ELF wizardry.
> >
> > Know any elven wizards?
> >
>
> It would be tricky, the string data from the entire compilation unit is
> intermingled. You would have to separate out only those strings
> referenced from __init sections into their own section and fix up all
> symbols and relocations that were affected.
Exactly. Annoying but not impossible.
> Probably easier would be to use the plug-in feature that will be part of
> GCC-4.5 (or will that be called GCC-5.0??), and create a special Linux
> kernel GCC plug-in that just emits the __init literal strings to the
> proper section to begin with. This wouldn't be unprecedented, the
> Mozilla people already use their own extensions to GCC, and will
> probably migrate to GCC plug-ins. We don't want the kernel to get left
> behind in the GCC plug-in race.
There are no doubt a number of things we could be doing with such
extensions.
--
http://selenic.com : development and support for Mercurial and Linux
^ permalink raw reply
* Re: [RFC] move __devinit or __init printk constant format strings to __devinitconst or __initdata?
From: David Daney @ 2009-07-21 23:50 UTC (permalink / raw)
To: Joe Perches
Cc: Matt Mackall, linux-embedded, linux-kernel, Paul Gortmaker,
David Woodhouse, Tim Bird
In-Reply-To: <1248217502.31365.381.camel@Joe-Laptop.home>
Joe Perches wrote:
> On Tue, 2009-07-21 at 17:57 -0500, Matt Mackall wrote:
>> On Tue, 2009-07-21 at 14:56 -0700, Joe Perches wrote:
>>> On Tue, 2009-07-21 at 16:48 -0500, Matt Mackall wrote:
>>>> On Tue, 2009-07-21 at 14:20 -0700, Joe Perches wrote:
>>>>> Is moving constant string formats to __devinitconst or __initdata
>>>>> useful for embedded environments?
>>>> Interesting notion, but not worth the trouble in my mind. I think it's
>>>> more worthwhile to look into automatic such stuff in the build somehow.
>>> I think it's not possible today to get gcc to mark
>>> the format strings without source modification.
>> Yep, that's why I specifically said 'build'. It can probably be done in
>> a post-processing step with some ELF wizardry.
>
> Know any elven wizards?
>
It would be tricky, the string data from the entire compilation unit is
intermingled. You would have to separate out only those strings
referenced from __init sections into their own section and fix up all
symbols and relocations that were affected.
Probably easier would be to use the plug-in feature that will be part of
GCC-4.5 (or will that be called GCC-5.0??), and create a special Linux
kernel GCC plug-in that just emits the __init literal strings to the
proper section to begin with. This wouldn't be unprecedented, the
Mozilla people already use their own extensions to GCC, and will
probably migrate to GCC plug-ins. We don't want the kernel to get left
behind in the GCC plug-in race.
David Daney
^ permalink raw reply
* Re: [RFC] move __devinit or __init printk constant format strings to __devinitconst or __initdata?
From: Joe Perches @ 2009-07-21 23:05 UTC (permalink / raw)
To: Matt Mackall
Cc: linux-embedded, linux-kernel, Paul Gortmaker, David Woodhouse,
Tim Bird
In-Reply-To: <1248217044.10466.202.camel@calx>
On Tue, 2009-07-21 at 17:57 -0500, Matt Mackall wrote:
> On Tue, 2009-07-21 at 14:56 -0700, Joe Perches wrote:
> > On Tue, 2009-07-21 at 16:48 -0500, Matt Mackall wrote:
> > > On Tue, 2009-07-21 at 14:20 -0700, Joe Perches wrote:
> > > > Is moving constant string formats to __devinitconst or __initdata
> > > > useful for embedded environments?
> > > Interesting notion, but not worth the trouble in my mind. I think it's
> > > more worthwhile to look into automatic such stuff in the build somehow.
> > I think it's not possible today to get gcc to mark
> > the format strings without source modification.
> Yep, that's why I specifically said 'build'. It can probably be done in
> a post-processing step with some ELF wizardry.
Know any elven wizards?
> > It's pretty easy to script a source conversion.
>
> And that script has to be run how often?
Once.
> I don't think people will find
> the churn (and general extra ugliness) acceptable. For a typical
> stripped-down embedded kernel, the amount of gain here will be fairly
> minimal. I'd be surprised if you got as much as 1K out of it.
Got a typical config that uses printks I could try?
^ permalink raw reply
* Re: [RFC] move __devinit or __init printk constant format strings to __devinitconst or __initdata?
From: Matt Mackall @ 2009-07-21 22:57 UTC (permalink / raw)
To: Joe Perches
Cc: linux-embedded, linux-kernel, Paul Gortmaker, David Woodhouse,
Tim Bird
In-Reply-To: <1248213403.31365.343.camel@Joe-Laptop.home>
On Tue, 2009-07-21 at 14:56 -0700, Joe Perches wrote:
> On Tue, 2009-07-21 at 16:48 -0500, Matt Mackall wrote:
> > On Tue, 2009-07-21 at 14:20 -0700, Joe Perches wrote:
> > > Is moving constant string formats to __devinitconst or __initdata
> > > useful for embedded environments?
> > > As in:
> > > #define printk_section(section, fmt, ...) \
> > > ({ static const section char __fmt[] = fmt; printk(__fmt, ##__VA_ARGS__); })
> > > #define pr_err_section(section, fmt, ...) \
> > > printk_section(section, KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
> > > with a use of:
> > > static int __devinit foo_probe(struct platform_device *pdev)
> > > {
> > > if (bar())
> > > pr_err_section(__devinitconst,
> > > "A long error message\n");
> > > }
>
> > Interesting notion, but not worth the trouble in my mind. I think it's
> > more worthwhile to look into automatic such stuff in the build somehow.
>
> I think it's not possible today to get gcc to mark
> the format strings without source modification.
Yep, that's why I specifically said 'build'. It can probably be done in
a post-processing step with some ELF wizardry.
> It's pretty easy to script a source conversion.
And that script has to be run how often? I don't think people will find
the churn (and general extra ugliness) acceptable. For a typical
stripped-down embedded kernel, the amount of gain here will be fairly
minimal. I'd be surprised if you got as much as 1K out of it.
--
http://selenic.com : development and support for Mercurial and Linux
^ permalink raw reply
* Re: [RFC] move __devinit or __init printk constant format strings to __devinitconst or __initdata?
From: Joe Perches @ 2009-07-21 21:56 UTC (permalink / raw)
To: Matt Mackall
Cc: linux-embedded, linux-kernel, Paul Gortmaker, David Woodhouse,
Tim Bird
In-Reply-To: <1248212925.10466.143.camel@calx>
On Tue, 2009-07-21 at 16:48 -0500, Matt Mackall wrote:
> On Tue, 2009-07-21 at 14:20 -0700, Joe Perches wrote:
> > Is moving constant string formats to __devinitconst or __initdata
> > useful for embedded environments?
> > As in:
> > #define printk_section(section, fmt, ...) \
> > ({ static const section char __fmt[] = fmt; printk(__fmt, ##__VA_ARGS__); })
> > #define pr_err_section(section, fmt, ...) \
> > printk_section(section, KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
> > with a use of:
> > static int __devinit foo_probe(struct platform_device *pdev)
> > {
> > if (bar())
> > pr_err_section(__devinitconst,
> > "A long error message\n");
> > }
> Interesting notion, but not worth the trouble in my mind. I think it's
> more worthwhile to look into automatic such stuff in the build somehow.
I think it's not possible today to get gcc to mark
the format strings without source modification.
It's pretty easy to script a source conversion.
^ permalink raw reply
* Re: [RFC] move __devinit or __init printk constant format strings to __devinitconst or __initdata?
From: Matt Mackall @ 2009-07-21 21:48 UTC (permalink / raw)
To: Joe Perches
Cc: linux-embedded, linux-kernel, Paul Gortmaker, David Woodhouse,
Tim Bird
In-Reply-To: <1248211253.31365.337.camel@Joe-Laptop.home>
On Tue, 2009-07-21 at 14:20 -0700, Joe Perches wrote:
> Is moving constant string formats to __devinitconst or __initdata
> useful for embedded environments?
>
> As in:
>
> #define printk_section(section, fmt, ...) \
> ({ static const section char __fmt[] = fmt; printk(__fmt, ##__VA_ARGS__); })
>
> #define pr_err_section(section, fmt, ...) \
> printk_section(section, KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
>
> with a use of:
>
> static int __devinit foo_probe(struct platform_device *pdev)
> {
> if (bar())
> pr_err_section(__devinitconst,
> "A long error message\n");
> }
>
> or
>
> static int __init foo_init(struct platform_device *pdev)
> {
> if (bar())
> pr_err_section(__initdata,
> "A long error message\n");
> }
Interesting notion, but not worth the trouble in my mind. I think it's
more worthwhile to look into automatic such stuff in the build somehow.
--
http://selenic.com : development and support for Mercurial and Linux
^ permalink raw reply
* [RFC] move __devinit or __init printk constant format strings to __devinitconst or __initdata?
From: Joe Perches @ 2009-07-21 21:20 UTC (permalink / raw)
To: linux-embedded
Cc: linux-kernel, Paul Gortmaker, David Woodhouse, Matt Mackall,
Tim Bird
Is moving constant string formats to __devinitconst or __initdata
useful for embedded environments?
As in:
#define printk_section(section, fmt, ...) \
({ static const section char __fmt[] = fmt; printk(__fmt, ##__VA_ARGS__); })
#define pr_err_section(section, fmt, ...) \
printk_section(section, KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
with a use of:
static int __devinit foo_probe(struct platform_device *pdev)
{
if (bar())
pr_err_section(__devinitconst,
"A long error message\n");
}
or
static int __init foo_init(struct platform_device *pdev)
{
if (bar())
pr_err_section(__initdata,
"A long error message\n");
}
^ permalink raw reply
* syslog stops to deliver to console
From: Zaphod @ 2009-07-21 8:37 UTC (permalink / raw)
To: linux-embedded
Hi
I have ppc arch and sysklogd-1.5 working on it.
The syslogd has config file which orders to redirect output to console
(/dev/console) and IP of other Linux machine.
I have application with 3 threads doing syslog every 50msec. After less that
minute the console stops to show messages, but the other Linux machine still
gets them.
Is it known problem?
Thanks for help.
^ permalink raw reply
* Re: New MMC maintainer needed
From: Alex Dubov @ 2009-07-15 4:59 UTC (permalink / raw)
To: LKML, linux-embedded, Nicolas Pitre, Nicolas Ferre,
Haavard Skinnemoen
> I'm afraid the time has come for me
> to step down as maintainer for the
> MMC/SD/SDIO subsystem and for someone else to take over the
> rudder. It
> is no secret that I haven't been able to give the
> maintainer role the
> resources it required, and as a result it has gone from
> being a fun
> hobby to a burdensome chore. I was hoping it was a
> temporary slump, but
> this has been the norm for over a year now, so it's time
> for me to
> throw in the towel.
What an unfortunate thing.
Franky speaking, I couldn't manage any time to work on Linux
in the last year myself. I had such a great plans for Memstick
and such, yet none advanced.
At this rate, the future of the flash cards on Linux will
become highly uncertain.
:-(
^ permalink raw reply
* Re: New MMC maintainer needed
From: Ian Molton @ 2009-07-14 21:04 UTC (permalink / raw)
To: Pierre Ossman
Cc: LKML, linux-embedded, Nicolas Pitre, Nicolas Ferre,
Haavard Skinnemoen, Tony Lindgren, David Brownell, manuel.lauss,
mirq-linux, Pavel Pisa, Jarkko Lavinen, Ben Dooks, saschasommer,
avorontsov, Alex Dubov, HaraldWelte, JosephChan, Adrian Hunter
In-Reply-To: <20090714153601.6dfe70ff@mjolnir.ossman.eu>
Pierre Ossman wrote:
> I'm afraid the time has come for me to step down as maintainer for the
> MMC/SD/SDIO subsystem and for someone else to take over the rudder.
Thank you for your time and effort on this subsystem.
I havent done anything 'deep' in MMC for some time (since my initial SD
mem card support), so I dont feel qualified to step up. Hopefully we'll
find someone suitable.
^ permalink raw reply
* Re: [PATCH 1/2] MMC Agressive clocking framework v4
From: Linus Walleij @ 2009-07-14 15:19 UTC (permalink / raw)
To: Pierre Ossman; +Cc: Linus Walleij, linux-arm-kernel, linux-embedded
In-Reply-To: <63386a3d0907140812q20b5e0bbl63c2906dea6af5e9@mail.gmail.com>
2009/7/14 Linus Walleij <linus.ml.walleij@gmail.com>:
> 2009/6/21 Linus Walleij <linus.walleij@stericsson.com>:
>
>> This patch modified the MMC core code to optionally call the
>> set_ios() operation on the driver with the clock frequency set
>> to 0
>
> Ping on this. It's soon been a month since the last version and
> I know we're in vacation times but...
Aw sorry now I saw you mail about being unable to continue doing
MMC maintenance.
I will proceed to send the patch to Andrew if noone picks up the
rôle, OK.
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/2] MMC Agressive clocking framework v4
From: Linus Walleij @ 2009-07-14 15:12 UTC (permalink / raw)
To: Pierre Ossman; +Cc: Linus Walleij, linux-arm-kernel, linux-embedded
In-Reply-To: <1245617982-5007-1-git-send-email-linus.walleij@stericsson.com>
2009/6/21 Linus Walleij <linus.walleij@stericsson.com>:
> This patch modified the MMC core code to optionally call the
> set_ios() operation on the driver with the clock frequency set
> to 0
Ping on this. It's soon been a month since the last version and
I know we're in vacation times but...
Linus Walleij
^ permalink raw reply
* New MMC maintainer needed
From: Pierre Ossman @ 2009-07-14 13:36 UTC (permalink / raw)
To: LKML, linux-embedded, Nicolas Pitre, Nicolas Ferre,
Haavard Skinnemoen
[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]
I'm afraid the time has come for me to step down as maintainer for the
MMC/SD/SDIO subsystem and for someone else to take over the rudder. It
is no secret that I haven't been able to give the maintainer role the
resources it required, and as a result it has gone from being a fun
hobby to a burdensome chore. I was hoping it was a temporary slump, but
this has been the norm for over a year now, so it's time for me to
throw in the towel.
I don't have any clear nominees for a replacement, but if you feel that
you are in a position to take over the maintainer role then please
raise your hand.
I only have a few patches in my queue right now and I can push those
off to Linus before I quit. There are however a lot of unhandled
messages that need attention. I can provide a list once a successor has
been named.
I realise that you have put a lot of time and effort into the patches
you send me and I am truly sorry that I haven't been able to handle
them better. Hopefully me stepping down means that we get someone who
can actually take care of everything in a timely manner.
I haven't decided what to do with the sdhci maintainership yet. Right
now I only know I need a break and freeing myself from the MMC
maintainer role is the first step. Hopefully I can return as a
developer in the future.
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: syslog for embedded
From: David McCullough @ 2009-07-14 10:48 UTC (permalink / raw)
To: Roberto A. Foglietta; +Cc: zaphod001, linux-embedded
In-Reply-To: <e4c675870907140323x7e9846d3hb09a89fda239b984@mail.gmail.com>
Jivin Roberto A. Foglietta lays it down ...
> 2009/7/14 Zaphod <zaphod001@gmail.com>:
> > Hi All,
> >
> > i am trying to find good syslog suitable for embedded.
> > Means,
> > 1. no use of dynamic allocations
> > 2. small footprint
> > 3. redirection to multiple destination (number of IPs, file, console)
> >
> > Thanks everyone for help.
>
> AFAIK busbox syslogd miss the 3rd requirement. If any other existing
> syslog still miss at least one of the requirements then upgrading
> busybox with the network support would be a viable solution.
The version of busybox that is included in the uClinux-dist:
http://www.uclinux.org/pub/uClinux/dist/
has extensions to do most if not all of 3. I can't recall how much of
that functionality has made it back upstream.
You can have a peek at a much older version of uCLinux-dist at:
http://cvs.uclinux.org/cgi-bin/cvsweb.cgi/uClinux-dist/user/busybox/
might save the big download,
Cheers,
Davidm
--
David McCullough, david_mccullough@securecomputing.com, Ph:+61 734352815
McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org
^ permalink raw reply
* Re: syslog for embedded
From: Roberto A. Foglietta @ 2009-07-14 10:23 UTC (permalink / raw)
To: zaphod001; +Cc: linux-embedded
In-Reply-To: <4A5C576B.4040203@gmail.com>
2009/7/14 Zaphod <zaphod001@gmail.com>:
> Hi All,
>
> i am trying to find good syslog suitable for embedded.
> Means,
> 1. no use of dynamic allocations
> 2. small footprint
> 3. redirection to multiple destination (number of IPs, file, console)
>
> Thanks everyone for help.
AFAIK busbox syslogd miss the 3rd requirement. If any other existing
syslog still miss at least one of the requirements then upgrading
busybox with the network support would be a viable solution.
Ciao,
--
Roberto A. Foglietta,
Linux Embedded Consultant
mobile: (+39) 349.33.30.697
^ permalink raw reply
* syslog for embedded
From: Zaphod @ 2009-07-14 10:01 UTC (permalink / raw)
To: linux-embedded
Hi All,
i am trying to find good syslog suitable for embedded.
Means,
1. no use of dynamic allocations
2. small footprint
3. redirection to multiple destination (number of IPs, file, console)
Thanks everyone for help.
^ permalink raw reply
* Re: Status of bzip2 and lzma kernel compression for ARM?
From: Albin Tonnerre @ 2009-07-13 19:17 UTC (permalink / raw)
To: Alain Knaff, Mike Rapoport
Cc: Michael Opdenacker, Florian Fainelli, Thomas Petazzoni,
Russell King - ARM Linux, Linux Kernel Mailing List,
linux-arm-kernel, linux-embedded mailing list
In-Reply-To: <20090703154327.GE4278@pc-ras4041.res.insa>
On Fri, Jul 03, 2009 at 05:43:27PM +0200, Albin Tonnerre wrote :
>However, it now hangs right after the 'done, booting the
> kernel.'
>
After some further work, here's an updated patch that works properly on ARM,
at least for gzip and lzma (I'm getting an 'out of memory' error with bzip2).
As a side note, my previous remarks about the LZMA header not being created
properly only apply to the git tree, as this is caused by commit
d3dd3b5a29bb9582957451531fed461628dfc834. 2.6.30 and 2.6.30.1 don't have this
issue
Regards,
Albin
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9d02cdb..5cde822 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -18,6 +18,9 @@ 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_BZIP2
+ select HAVE_KERNEL_LZMA
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 fbe5eef..c29a88f 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -63,8 +63,15 @@ 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) = gz
+suffix_$(CONFIG_KERNEL_BZIP2) = bz2
+suffix_$(CONFIG_KERNEL_LZMA) = lzma
+
+targets := vmlinux vmlinux.lds \
+ piggy.gz piggy.gz.o \
+ piggy.bz2 piggy.bz2.o \
+ piggy.lzma piggy.lzma.o \
+ font.o font.c head.o misc.o $(OBJS)
ifeq ($(CONFIG_FUNCTION_TRACER),y)
ORIG_CFLAGS := $(KBUILD_CFLAGS)
@@ -91,7 +98,7 @@ LDFLAGS_vmlinux += -p --no-undefined -X \
# would otherwise mess up our GOT table
CFLAGS_misc.o := -Dstatic=
-$(obj)/vmlinux: $(obj)/vmlinux.lds $(obj)/$(HEAD) $(obj)/piggy.o \
+$(obj)/vmlinux: $(obj)/vmlinux.lds $(obj)/$(HEAD) $(obj)/piggy.$(suffix_y).o \
$(addprefix $(obj)/, $(OBJS)) FORCE
$(call if_changed,ld)
@:
@@ -99,7 +106,17 @@ $(obj)/vmlinux: $(obj)/vmlinux.lds $(obj)/$(HEAD) $(obj)/piggy.o \
$(obj)/piggy.gz: $(obj)/../Image FORCE
$(call if_changed,gzip)
-$(obj)/piggy.o: $(obj)/piggy.gz FORCE
+$(obj)/piggy.bz2: $(obj)/../Image FORCE
+ $(call if_changed,bzip2)
+
+$(obj)/piggy.lzma: $(obj)/../Image FORCE
+ $(call if_changed,lzma)
+
+$(obj)/piggy.gz.o: $(obj)/piggy.gz FORCE
+
+$(obj)/piggy.bz2.o: $(obj)/piggy.bz2 FORCE
+
+$(obj)/piggy.lzma.o: $(obj)/piggy.lzma FORCE
CFLAGS_font.o := -Dstatic=
diff --git a/arch/arm/boot/compressed/misc.c b/arch/arm/boot/compressed/misc.c
index 9e6e512..4ba7249 100644
--- a/arch/arm/boot/compressed/misc.c
+++ b/arch/arm/boot/compressed/misc.c
@@ -18,6 +18,12 @@
unsigned int __machine_arch_type;
+/* Prevent inclusion of string.h */
+#define _LINUX_STRING_H_
+
+/* ARM has no support for division or modulo in its pre-boot environment */
+#define NO_DIVISION
+
#include <linux/compiler.h> /* for inline */
#include <linux/types.h> /* for size_t */
#include <linux/stddef.h> /* for NULL */
@@ -189,116 +195,31 @@ 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);}
-# define Trace(x) fprintf x
-# define Tracev(x) {if (verbose) fprintf x ;}
-# define Tracevv(x) {if (verbose>1) fprintf x ;}
-# define Tracec(c,x) {if (verbose && (c)) fprintf x ;}
-# define Tracecv(c,x) {if (verbose>1 && (c)) fprintf x ;}
-#else
-# define Assert(cond,msg)
-# define Trace(x)
-# define Tracev(x)
-# define Tracevv(x)
-# define Tracec(c,x)
-# 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 void error(char *m);
-static void putstr(const char *);
+static unsigned long free_mem_ptr;
+static unsigned long free_mem_end_ptr;
-extern int end;
-static ulg free_mem_ptr;
-static ulg free_mem_end_ptr;
+#define ARCH_HAS_DECOMP_WDOG
-#ifdef STANDALONE_DEBUG
-#define NO_INFLATE_MALLOC
+#ifdef CONFIG_KERNEL_GZIP
+#include "../../../../lib/decompress_inflate.c"
#endif
-#define ARCH_HAS_DECOMP_WDOG
-
-#include "../../../../lib/inflate.c"
+#ifdef CONFIG_KERNEL_BZIP2
+#include "../../../../lib/decompress_bunzip2.c"
+#endif
-/* ===========================================================================
- * 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");
+#ifdef CONFIG_KERNEL_LZMA
+#include "../../../../lib/decompress_unlzma.c"
+#endif
- inbuf = input_data;
- insize = &input_data_end[0] - &input_data[0];
- inptr = 1;
- return inbuf[0];
-}
-
-/* ===========================================================================
- * 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(".");
-}
#ifndef arch_error
#define arch_error(x)
@@ -317,20 +238,37 @@ static void error(char *x)
#ifndef STANDALONE_DEBUG
-ulg
-decompress_kernel(ulg output_start, ulg free_mem_ptr_p, ulg free_mem_ptr_end_p,
+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 */
- free_mem_ptr = free_mem_ptr_p;
- free_mem_end_ptr = free_mem_ptr_end_p;
+ unsigned long output_ptr;
+ char *ptr;
+ size_t input_len = input_data_end - input_data;
+ size_t pos = 0;
+
__machine_arch_type = arch_id;
arch_decomp_setup();
- makecrc();
- putstr("Uncompressing Linux...");
- gunzip();
+ ptr = (unsigned char *) (((unsigned long)input_data_end) - 4);
+
+ /* The uncompressed size is appended at the end of the compressed file, but
+ * we have no guarantee that it's 2-bytes aligned. Therefore, use a char *
+ * to get the size. At least on my box, trying to access a non 2-bytes
+ * aligned unsigned long resulted in some weirdness
+ */
+
+ output_ptr = ptr[0] | ptr[1] << 8 | ptr[2] << 16 | ptr[3] << 24;
+
+ free_mem_ptr = free_mem_ptr_p;
+ free_mem_end_ptr = free_mem_ptr_end_p;
+
+ putstr("Decompressing Linux...");
+ decompress(input_data, input_len,
+ NULL, NULL, (unsigned char *) output_start, &pos, error);
putstr(" done, booting the kernel.\n");
return output_ptr;
}
@@ -340,11 +278,8 @@ char output_buffer[1500*1024];
int main()
{
- output_data = output_buffer;
-
- makecrc();
putstr("Uncompressing Linux...");
- gunzip();
+ decompress(input_data, input_len, NULL, output_buffer, NULL);
putstr("done.\n");
return 0;
}
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.bz2.S b/arch/arm/boot/compressed/piggy.bz2.S
new file mode 100644
index 0000000..c5ecbde
--- /dev/null
+++ b/arch/arm/boot/compressed/piggy.bz2.S
@@ -0,0 +1,6 @@
+ .section .piggydata,#alloc
+ .globl input_data
+input_data:
+ .incbin "arch/arm/boot/compressed/piggy.bz2"
+ .globl input_data_end
+input_data_end:
diff --git a/arch/arm/boot/compressed/piggy.gz.S b/arch/arm/boot/compressed/piggy.gz.S
new file mode 100644
index 0000000..54c9518
--- /dev/null
+++ b/arch/arm/boot/compressed/piggy.gz.S
@@ -0,0 +1,6 @@
+ .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.lzma.S b/arch/arm/boot/compressed/piggy.lzma.S
new file mode 100644
index 0000000..d7e69cf
--- /dev/null
+++ b/arch/arm/boot/compressed/piggy.lzma.S
@@ -0,0 +1,6 @@
+ .section .piggydata,#alloc
+ .globl input_data
+input_data:
+ .incbin "arch/arm/boot/compressed/piggy.lzma"
+ .globl input_data_end
+input_data_end:
diff --git a/arch/arm/boot/uImage.lzma b/arch/arm/boot/uImage.lzma
new file mode 100644
index 0000000..4fb24eb
Binary files /dev/null and b/arch/arm/boot/uImage.lzma differ
diff --git a/include/linux/decompress/mm.h b/include/linux/decompress/mm.h
index 12ff8c3..8becfce 100644
--- a/include/linux/decompress/mm.h
+++ b/include/linux/decompress/mm.h
@@ -64,6 +64,8 @@ static void free(void *where)
#include <linux/string.h>
#include <linux/vmalloc.h>
+#include <linux/slab.h>
+
/* Use defines rather than static inline in order to avoid spurious
* warnings when not needed (indeed large_malloc / large_free are not
* needed by inflate */
diff --git a/include/linux/zutil.h b/include/linux/zutil.h
index 6adfa9a..bedd56b 100644
--- a/include/linux/zutil.h
+++ b/include/linux/zutil.h
@@ -60,6 +60,19 @@ typedef uLong (*check_func) (uLong check, const Byte *buf,
#define DO8(buf,i) DO4(buf,i); DO4(buf,i+4);
#define DO16(buf) DO8(buf,0); DO8(buf,8);
+#ifdef NO_DIVISION
+static inline unsigned long mod65521(unsigned long s)
+{
+ while (1) {
+ if (s < BASE)
+ return s;
+ if (s < 0x10000)
+ return s-BASE;
+ s = (s & 0xffff) + 15 * (s >> 16);
+ }
+}
+#endif
+
/* ========================================================================= */
/*
Update a running Adler-32 checksum with the bytes buf[0..len-1] and
@@ -97,8 +110,13 @@ static inline uLong zlib_adler32(uLong adler,
s1 += *buf++;
s2 += s1;
} while (--k);
+#ifdef NO_DIVISION
+ s1 = mod65521(s1);
+ s2 = mod65521(s2);
+#else
s1 %= BASE;
s2 %= BASE;
+#endif
}
return (s2 << 16) | s1;
}
diff --git a/lib/decompress_bunzip2.c b/lib/decompress_bunzip2.c
index 708e2a8..5d3ddb5 100644
--- a/lib/decompress_bunzip2.c
+++ b/lib/decompress_bunzip2.c
@@ -50,7 +50,6 @@
#endif /* !STATIC */
#include <linux/decompress/mm.h>
-#include <linux/slab.h>
#ifndef INT_MAX
#define INT_MAX 0x7fffffff
diff --git a/lib/decompress_inflate.c b/lib/decompress_inflate.c
index e36b296..839a329 100644
--- a/lib/decompress_inflate.c
+++ b/lib/decompress_inflate.c
@@ -23,7 +23,6 @@
#endif /* STATIC */
#include <linux/decompress/mm.h>
-#include <linux/slab.h>
#define INBUF_LEN (16*1024)
diff --git a/lib/decompress_unlzma.c b/lib/decompress_unlzma.c
index 32123a1..546f2f4 100644
--- a/lib/decompress_unlzma.c
+++ b/lib/decompress_unlzma.c
@@ -34,7 +34,6 @@
#endif /* STATIC */
#include <linux/decompress/mm.h>
-#include <linux/slab.h>
#define MIN(a, b) (((a) < (b)) ? (a) : (b))
diff --git a/lib/zlib_inflate/inflate.c b/lib/zlib_inflate/inflate.c
index f5ce87b..566bf1e 100644
--- a/lib/zlib_inflate/inflate.c
+++ b/lib/zlib_inflate/inflate.c
@@ -247,6 +247,23 @@ static int zlib_inflateSyncPacket(z_streamp strm)
((((q) >> 24) & 0xff) + (((q) >> 8) & 0xff00) + \
(((q) & 0xff00) << 8) + (((q) & 0xff) << 24))
+#ifdef NO_DIVISION
+/*
+ modulo 15 routine for those architectures that don't have division
+*/
+static inline unsigned long mod31(unsigned long s)
+{
+ while (1) {
+ if (s < 31)
+ return s;
+ if (s < 32)
+ return 0;
+ s = (s >> 5) + (s & 31);
+ }
+}
+#endif
+
+
/*
inflate() uses a state machine to process as much input data and generate as
much output data as possible before returning. The state machine is
@@ -370,7 +387,12 @@ int zlib_inflate(z_streamp strm, int flush)
}
NEEDBITS(16);
if (
- ((BITS(8) << 8) + (hold >> 8)) % 31) {
+#ifdef NO_DIVISION
+ mod31((BITS(8) << 8) + (hold >> 8))
+#else
+ ((BITS(8) << 8) + (hold >> 8)) % 31
+#endif
+ ) {
strm->msg = (char *)"incorrect header check";
state->mode = BAD;
break;
--
Albin Tonnerre, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ permalink raw reply related
* Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
From: Pavel Machek @ 2009-07-09 23:42 UTC (permalink / raw)
To: Marco Stornelli
Cc: tim.bird, jamie, Linux Embedded, Linux Kernel, Linux FS Devel,
Daniel Walker
In-Reply-To: <4A47A94E.4020808@gmail.com>
On Sun 2009-06-28 19:33:02, Marco Stornelli wrote:
> Pavel Machek wrote:
> >>>>> Ah now the write protection is a "needed feature", in your previous
> >>>>> comment you talked about why not use ext2/3.......
> >>>>>
> >>>>> Marco
> >>>>>
> >>>> Just for your information I tried the same test with pc in a virtual machine with 32MB of RAM:
> >>>>
> >>>> Version 1.03e ------Sequential Output------ --Sequential Input- --Random-
> >>>> -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
> >>>> Machine Size:chnk K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
> >>>> hostname 15M:1k 14156 99 128779 100 92240 100 11669 100 166242 99 80058 82
> >>>> ------Sequential Create------ --------Random Create--------
> >>>> -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
> >>>> files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
> >>>> 4 2842 99 133506 104 45088 101 2787 99 79581 101 58212 102
> >>>>
> >>>> These data are the proof of the importance of the environment, workload and so on when we talk
> >>>> about benchmark. Your consideration are really superficial.
> >>> Unfortunately, your numbers are meaningless.
> >> I don't think so.
> >>
> >>> (PCs should have cca 3GB/sec RAM transfer rates; and you demosstrated
> >>> cca 166MB/sec read rate; disk is 80MB/sec, so that's too slow. If you
> >>> want to prove your filesystem the filesystem is reasonably fast,
> >>> compare it with ext2 on ramdisk.)
> >>>
> >> This is the point. I don't want compare it with ext2 from performance
> >> point of view. This comparison makes no sense for me. I've done this
> >> test to prove that if you change environment you can change in a
> >> purposeful way the results.
> >
> > Yes, IOW you demonstrated that the numbers are machine-dependend and
> > really meaningless.
> >
> > ext2 comparison would tell you how much pramfs sucks (or not).
>
> Here the test with ext2 (same environment):
>
> Version 1.03e ------Sequential Output------ --Sequential Input- --Random-
> -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
> Machine Size:chnk K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
> hostname 15M:1k 10262 83 40847 82 38574 82 9866 92 62252 98 25204 81
> ------Sequential Create------ --------Random Create--------
> -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
> files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
> 1 19859 98 44804 61 68830 100 13566 99 157129 100 30431 98
>
Ok, so pramfs is significantly faster than ext2. Interesting, and good
for pramfs.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: need help finding a WiFi + BT SDIO chipset/module for Linux
From: Jonathan Cameron @ 2009-07-03 17:02 UTC (permalink / raw)
To: Aras Vaichas; +Cc: linux-embedded
In-Reply-To: <ed62800907022017v4756c909n12f4105ee6e35f1d@mail.gmail.com>
Aras Vaichas wrote:
> On Fri, Jul 3, 2009 at 11:23 AM, Aras
> Vaichas<arasv@magellan-technology.com> wrote:
>> Hi,
>>
>> can someone point me in the right direction to choose an OEM WiFI +
>> Bluetooth chipset/module suitable for an embedded Linux system? I'd
>> prefer if it was connected via SDIO.
>
> Sorry to answer my own question.
>
> This article sums it up pretty well with what I've found so far.
>
> http://bec-systems.com/site/90/the-embedded-wifi-module-quest
>
> The two main contenders seem to be Marvell and Atheros for SDIO OEM modules.
That's about right. Unless things have changed recently, the support for
the atheros 6000 series chips isn't good. There are a couple of
drivers out there, but I've never gotten anything to work with the board
we have. I know the openmoko guys were working on this.
Marvell drivers are in kernel and work well so that's what we
went with.
^ permalink raw reply
* Re: Status of bzip2 and lzma kernel compression for ARM?
From: Albin Tonnerre @ 2009-07-03 15:43 UTC (permalink / raw)
To: Mike Rapoport
Cc: Alain Knaff, Michael Opdenacker, Florian Fainelli,
Thomas Petazzoni, Russell King - ARM Linux,
Linux Kernel Mailing List, linux-arm-kernel,
linux-embedded mailing list
In-Reply-To: <4A48B1D9.90306@compulab.co.il>
On Mon, Jun 29, 2009 at 03:21:45PM +0300, Mike Rapoport wrote :
>
>
> Alain Knaff wrote:
> > Alain Knaff wrote:
> >> Attached is a version of the ARM patch for 2.6.30
> >>
> >> There seems to be some issues with the include files (which did not pose
> >> any problems in 2.6.28...), but hopefully somebody more experienced with
> >> the ARM architecture (and with its recent development) than I can help
> >> out there.
> >>
> >> Regards,
> >>
> >> Alain
> >
> > Actually, the needed changes turned out to be easier than I initially
> > feared. Attached a version that compiles all right.
>
> I gave it a quick test and it hangs before "Decompressing kernel" is output.
> I hope I'll have time this week to debug what's wrong there.
On my testing board, it hangs after "Decompressing kernel" is output. It seems
that it's getting stuck in the following piece of code in lib/decompressor_lzma.c
while (get_pos(&wr) < header.dst_size) {
int pos_state = get_pos(&wr) & pos_state_mask;
uint16_t *prob = p + LZMA_IS_MATCH +
(cst.state << LZMA_NUM_POS_BITS_MAX) + pos_state;
if (rc_is_bit_0(&rc, prob))
process_bit0(&wr, &rc, &cst, p, pos_state, prob,
lc, literal_pos_mask);
else {
process_bit1(&wr, &rc, &cst, p, pos_state, prob);
if (cst.rep0 == 0)
break;
}
}
Based on some quick tests, it seems that header.dst_size is 0xFFFFFFFFFFFFFFFF,
and if my understanding is correct, it's because LZMA doesn't write the file
size in the header if it reads its input from a pipe, and piggy.lzma turns out
to be created using a pipe.
Replacing cmd_lzma in scripts/Makefile.lib by the following snippet:
cmd_lzma = (lzma -9 -c $(filter-out FORCE, $^) > $@ && $(call size_append, $(filter-out FORCE,$^)) >> $@ ) || (rm -f $@ ; false)
does the trick, as lzma is able to write the file size in the header (and I
think the second part is useless, as it's the filesize encoded in 32bits
little-endian). However, it now hangs right after the 'done, booting the
kernel.'
Hope that helps,
--
Albin Tonnerre, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php
^ permalink raw reply
* Re: 2.6.27- Sending uevent from a driver
From: Jamie Lokier @ 2009-07-03 15:36 UTC (permalink / raw)
To: Alan Cox
Cc: Daniel Ng, Greg KH, linux-embedded-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20090702111107.08332a4b-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>
Alan Cox wrote:
> > Or, maybe the userspace program can receive some sort of interrupt
> > from the TTY device when it is ready for I/O.
> >
> > Perhaps there is another way to avoid continued polling?
>
> TIOCMIWAIT ioctl for modem signals, and just using poll/select() on the
> tty for I/O.
Ah yes, the undocumented ioctl... I knew there was one, just couldn't
find it in the man page just now.
-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: need help finding a WiFi + BT SDIO chipset/module for Linux
From: Aras Vaichas @ 2009-07-03 3:17 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <ed62800907021823t2518700cv3710d3aa46371369@mail.gmail.com>
On Fri, Jul 3, 2009 at 11:23 AM, Aras
Vaichas<arasv@magellan-technology.com> wrote:
> Hi,
>
> can someone point me in the right direction to choose an OEM WiFI +
> Bluetooth chipset/module suitable for an embedded Linux system? I'd
> prefer if it was connected via SDIO.
Sorry to answer my own question.
This article sums it up pretty well with what I've found so far.
http://bec-systems.com/site/90/the-embedded-wifi-module-quest
The two main contenders seem to be Marvell and Atheros for SDIO OEM modules.
Aras
^ 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