Skip to content

RFC ARM: Decompressor multiplatform support

Domenico Andreoli linux-arm-kernel 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 RFC Latest12 patches 0 repliesNew

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/12ARM: Add strstr to the decompressor+0 -00 replies
2/12ARM: kernel -> decompressor relocation handling+0 -00 replies
3/12ARM: Add indirection around arch_decomp_setup()/arch_error()+0 -00 replies
4/12ARM: Add architecture specific decompressor tags+0 -00 replies
5/12ARM: Add DT support to decompressor tags+0 -01 reply
5/12ARM: Add DT support to decompressor tags+0 -00 replies
6/12ARM: Work around OMAPs arch_decomp_setup()+0 -00 replies
7/12ARM: Add multi-arch console support to the decompressor+0 -00 replies
8/12ARM: Add DT support to the decompressor console+0 -00 replies
9/12ARM: Decompressor support for AMBA PL010 UARTs+0 -00 replies
10/12ARM: Decompressor support for AMBA PL011 UARTs+0 -00 replies
11/12ARM: Decompressor support for Samsung UARTs+0 -00 replies
12/12ARM: Decompressor support for OMAP UARTs+0 -00 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [RFC PATCH 00/12] ARM: Decompressor multiplatform support

Hi all,

here is a new edition of my work in the decompressor area.

My intent is to get rid of uncompress.h and prepare the decompressor to dynamically select the various machine specific decompressor init steps, included the selection of the appropriate console driver.

Currently the mainline kernel defines these steps statically and indeed has some trouble to boot on different boards with the same binary.

What this patch does is allowing the four functions (arch_decomp_setup, arch_error, putc and flush) currently used to define such static steps to be packed in quantity and to be selected/executed by the decompressor accordingly to the machid or DT passed by the boot loader.

I forgot to say that all this code and data is relocated from the kernel image to the decompressor during the build. So some pointer arithmetic is required on the decompressor side. This unfortunately brings in also some limitations in the code/data to be relocated.

The patchset is of course far from being ready for anything but development and testing. I really looked into only three SoCs but I know that aside from a kind of graphic adapter somewhere all the other are a variation of these three players.

I'm able to test it on a out-of-tree bcm4760 board and a Samsung S5P6450. I also build tested a dozen of other random samsung and ti/omap defconfigs, sometimes nailing down problems. I've also my qq2440 ;)

The patchset also applies on top of Arnd's multiplatform tree and the resulting binary boots on the bcm4760 board. In that configuration I get the most fat relocation of code and data, with an amazing number of four drivers and don't known how many console tags. I had also some fun efficiently packing all that stuff :)

That said, thank you for the comments :)

cheers,
Domenico