[PATCH 2/5] include/linux/unaligned/{l,b}e_byteshift.h: Fix usage for compressed kernels
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
Signed-off-by: Albin Tonnerre albin.tonne...@free-electrons.com
---
include/linux/unaligned/be_byteshift.h |2 +-
include/linux/unaligned/le_byteshift.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/unaligned/be_byteshift.h
b/include/linux/unaligned/be_byteshift.h
index 46dd12c..9356b24 100644
--- a/include/linux/unaligned/be_byteshift.h
+++ b/include/linux/unaligned/be_byteshift.h
@@ -1,7 +1,7 @@
#ifndef _LINUX_UNALIGNED_BE_BYTESHIFT_H
#define _LINUX_UNALIGNED_BE_BYTESHIFT_H
-#include linux/kernel.h
+#include linux/types.h
static inline u16 __get_unaligned_be16(const u8 *p)
{
diff --git a/include/linux/unaligned/le_byteshift.h
b/include/linux/unaligned/le_byteshift.h
index 59777e9..be376fb 100644
--- a/include/linux/unaligned/le_byteshift.h
+++ b/include/linux/unaligned/le_byteshift.h
@@ -1,7 +1,7 @@
#ifndef _LINUX_UNALIGNED_LE_BYTESHIFT_H
#define _LINUX_UNALIGNED_LE_BYTESHIFT_H
-#include linux/kernel.h
+#include linux/types.h
static inline u16 __get_unaligned_le16(const u8 *p)
{
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] Add support for LZO-compressed kernels
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.
This version applies to kernel 2.6.31-rc3
This part contains:
- Makefile routine to support lzo compression
- Fixes to the existing lzo compressor so that it can be used in
compressed kernels
- wrapper around the existing lzo1x_decompress, as it only extracts one
block at a time, while we need to extract a whole file here
- config dialog for kernel compression
Signed-off-by: Albin Tonnerre albin.tonne...@free-electrons.com
---
include/linux/decompress/unlzo.h | 10 +++
init/Kconfig | 18 -
lib/decompress_unlzo.c | 138 ++
lib/lzo/lzo1x_decompress.c |9 ++-
scripts/Makefile.lib |5 ++
5 files changed, 173 insertions(+), 7 deletions(-)
create mode 100644 include/linux/decompress/unlzo.h
create mode 100644 lib/decompress_unlzo.c
diff --git a/include/linux/decompress/unlzo.h b/include/linux/decompress/unlzo.h
new file mode 100644
index 000..d1925ea
--- /dev/null
+++ b/include/linux/decompress/unlzo.h
@@ -0,0 +1,10 @@
+#ifndef DECOMPRESS_UNLZO_H
+#define DECOMPRESS_UNLZO_H
+
+int unlzo(unsigned char *inbuf, int len,
+ int(*fill)(void*, unsigned int),
+ int(*flush)(void*, unsigned int),
+ unsigned char *output,
+ int *pos,
+ void(*error)(char *x));
+#endif
diff --git a/init/Kconfig b/init/Kconfig
index 1ce05a4..66281fb 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -115,10 +115,13 @@ config HAVE_KERNEL_BZIP2
config HAVE_KERNEL_LZMA
bool
+config HAVE_KERNEL_LZO
+ bool
+
choice
prompt Kernel compression mode
default KERNEL_GZIP
- depends on HAVE_KERNEL_GZIP || HAVE_KERNEL_BZIP2 || HAVE_KERNEL_LZMA
+ depends on HAVE_KERNEL_GZIP || HAVE_KERNEL_BZIP2 || HAVE_KERNEL_LZMA ||
HAVE_KERNEL_LZO
help
The linux kernel is a kind of self-extracting executable.
Several compression algorithms are available, which differ
@@ -141,9 +144,8 @@ config KERNEL_GZIP
bool Gzip
depends on HAVE_KERNEL_GZIP
help
- The old and tried gzip compression. Its compression ratio is
- the poorest among the 3 choices; however its speed (both
- compression and decompression) is the fastest.
+ The old and tried gzip compression. It provides a good balance
+ between compression ration and decompression speed.
config KERNEL_BZIP2
bool Bzip2
@@ -164,6 +166,14 @@ config KERNEL_LZMA
two. Compression is slowest. The kernel size is about 33%
smaller with LZMA in comparison to gzip.
+config KERNEL_LZO
+ bool LZO
+ depends on HAVE_KERNEL_LZO
+ help
+ Its compression ratio is the poorest among the 4. The kernel
+ size is about about 10% bigger than gzip; however its speed
+ (both compression and decompression) is the fastest.
+
endchoice
config SWAP
diff --git a/lib/decompress_unlzo.c b/lib/decompress_unlzo.c
new file mode 100644
index 000..d908b35
--- /dev/null
+++ b/lib/decompress_unlzo.c
@@ -0,0 +1,138 @@
+/*
+ * LZO decompressor for the Linux kernel. Code borrowed from the lzo
+ * implementation by Markus Franz Xaver Johannes Oberhumer.
+ *
+ * Linux kernel adaptation:
+ * Copyright (C) 2009
+ * Albin Tonnerre, Free Electrons albin.tonne...@free-electrons.com
+ *
+ * Original code:
+ * Copyright (C) 1996-2005 Markus Franz Xaver Johannes Oberhumer
+ * All Rights Reserved.
+ *
+ * lzop and the LZO library are free software; you can redistribute them
+ * and/or modify them under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; see the file COPYING.
+ * If not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Markus F.X.J. Oberhumer
+ * mar...@oberhumer.com
+ * http://www.oberhumer.com/opensource/lzop/
+ */
+
+#ifdef STATIC
+#include lzo/lzo1x_decompress.c
+#endif
+
+#include linux/lzo.h
+#include linux/decompress/mm.h
+#include linux/decompress/unlzo.h
+
+#include linux/compiler.h
+#include linux/types.h
+#include asm/unaligned.h
+
+static const unsigned char lzop_magic[] =
+{ 0x89,
[PATCH 4/5] Add support for LZO-compressed kernels for ARM
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.tonne...@free-electrons.com
---
arch/arm/Kconfig |2 +
arch/arm/boot/compressed/Makefile | 16 +++--
arch/arm/boot/compressed/misc.c | 110
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, 52 insertions(+), 94 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..4ea8f25 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)
@@ -94,15 +98,15 @@ 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)
@:
-$(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 9e6e512..c4ec564 100644
--- a/arch/arm/boot/compressed/misc.c
+++ b/arch/arm/boot/compressed/misc.c
@@ -18,11 +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 asm/unaligned.h
+
#ifdef STANDALONE_DEBUG
#define putstr printf
#else
@@ -189,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_NAME0x08 /* bit 3 set: original file name present */
-#define COMMENT 0x10 /* bit 4 set: file comment present */
-#define ENCRYPTED0x20 /* 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);}
@@ -234,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[];
Re: [PATCH 3/5] Add support for LZO-compressed kernels
kevin.gran...@gmail.com wrote: So for a compression ratio that is still relatively close to gzip, it's much faster to extract, at least in that case. Is that time to run the extraction algorithm, or time to read in image from media and extract? I think the time to read from the media would tend to dominate the decompression time. Either way, could you provide the other time for each algorithm in order to give a sense of how this might scale to other CPU speeds/media read speeds? If you have very slow media, you probably want to use LZMA. If you have a very slow CPU and comparatively fast media, LZO might be a good option... I have heard people asking for *uncompressed* kernels for this reason, but LZO runs at a significant fraction of memcpy() speed. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
On Tue, 14 Jul 2009 15:36:01 +0200 Pierre Ossman pie...@ossman.eu 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. 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. Thanks, Pierre. Until and unless someone else steps up I can act as maintainer of last resort for MMC. As I'm presently doing for fbdev, hwmon, rtc, spi, gpio, i2o and about 1000 other identifiable subsystems. Fortunately, MMC doesn't appear to have its own mailing list so I'll actually get to see the patches. I do monitor a couple of subsystem-specific lists (fbdev, hwmon) but the delays can be awful - a month or two. When it comes to subsystems about which I have little knowledge I tend to work as follows: - scan the patch to see if anything stands out to my inexperienced eye - if possible, comment on it to make a bit of noise and to let the submitter and others know that a) someone has looked at it and b) there's a chance that it'll be merged. - try to identify some people who might have an interest in the patch and/or who might have related experience which would help them review this one effectively. So if someone finds themselves cc'ed on an MMC email from myself, please do take a bit of time to pass an eye across it, and let us know that you have done so - it really helps. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
Andrew Morton wrote: Until and unless someone else steps up I can act as maintainer of last resort for MMC. As I'm presently doing for fbdev, hwmon, rtc, spi, gpio, i2o and about 1000 other identifiable subsystems. If no-one else is helping out, Im happy to also be CC'd on MMC patches. I've been out of the loop, as I mentioned, but I dont mind helping out. I'm currently helping someone bring a PCI based TMIO type device online via email. Pierre - do you have a bunch of MMC spec-type docs around? I've lost all but the few sparse datasheets for TMIO that I had, so some docs covering protocol / commands would be useful. Any references / downloads that you know of? -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
