ARM: uncompress.h multi-platform enablement

From: Stephen Warren <[email protected]>

Create a common location for uncompress.h, and select the included debug macro file using config option.

This does the same for uncompress.h as a recent patch for debug-macro.S, which was based on a suggestion by Russell King and implemented by Rob Herring.

Cc Rob Herring <[email protected]>

Cc Russell King <[email protected]>

Signed-off-by Stephen Warren <[email protected]>

---
 arch/arm/Kconfig.debug                     |   10 ++++
 arch/arm/boot/compressed/misc.c            |   64 +---------------------------
 arch/arm/include/debug/icedcc-uncompress.h |   61 ++++++++++++++++++++++++++
 arch/arm/include/debug/none-uncompress.h   |    3 +
 4 files changed, 75 insertions(+), 63 deletions(-)
 create mode 100644 arch/arm/include/debug/icedcc-uncompress.h
 create mode 100644 arch/arm/include/debug/none-uncompress.h

arch/arm/Kconfig.debug +0 -0

index b0f3857..0daec3d 100644
@@ -420,6 +420,16 @@ config DEBUG_LL_INCLUDE
 		DEBUG_VEXPRESS_UART0_CA9 || DEBUG_VEXPRESS_UART0_RS1

Quoted 10 lines · Stephen Warren

From: Stephen Warren <[email protected]>

Create a common location for uncompress.h, and select the included debug macro file using config option.

This does the same for uncompress.h as a recent patch for debug-macro.S, which was based on a suggestion by Russell King and implemented by Rob Herring.

arch/arm/Kconfig.debug +0 -0

arch/arm/Kconfig.debug config DEBUG_LL_INCLUDE · line 430

Quoted 8 lines

arch/arm/Kconfig.debug +8 -0

+config UNCOMPRESS_INCLUDE
+	string
+	default "debug/icedcc-uncompress.h" if DEBUG_ICEDCC
+	default "debug/none-uncompress.h" if ARCH_MULTIPLATFORM || \
+		DEBUG_HIGHBANK_UART || DEBUG_MVEBU_UART || \
+		DEBUG_PICOXCELL_UART || DEBUG_SOCFPGA_UART || \
+		DEBUG_VEXPRESS_UART0_DETECT || DEBUG_VEXPRESS_UART0_CA9 || \
+		DEBUG_VEXPRESS_UART0_RS1

I would ask to add DEBUG_LL_UART_NONE to the or-ed list, which fixes the build of platforms without mach/uncompress.h and mach/debug-macro.S in case NONE is selected, but I'm not sure.

If I got the point of Russel right, uncompress.h is not a debug trace and maybe should not depend on any DEBUG_LL* option?

From: Stephen Warren <[email protected]>

Tegra's uncompress and debug-macro.S communicate to each-other. Hence, we can't be left without uncompress.h in a multi-platform enabled kernel, or we'll lose features. This series allows uncompress.h to be used in a multi-platform kernel, restores the mvebu uncompress.h, and finally moves the Tegra debug macros into the common location. The series as mainly an RFC due to the outstanding question of where to put Tegra's <mach/iomap.h> in the final patch.

Quoted 10 lines · Stephen Warren

From: Stephen Warren <[email protected]>

Tegra's uncompress and debug-macro.S communicate to each-other. Hence, we can't be left without uncompress.h in a multi-platform enabled kernel, or we'll lose features. This series allows uncompress.h to be used in a multi-platform kernel, restores the mvebu uncompress.h, and finally moves the Tegra debug macros into the common location. The series as mainly an RFC due to the outstanding question of where to put Tegra's <mach/iomap.h> in the final patch.

To follow up on the IRC discussion we had yesterday leading to this patch set, I had another idea of how to handle the same: Since the decompressor code is actually fairly separate from the kernel, we could also build multiple versions of it, and link in the same compressed vmlinux.

That rubbishes the idea of a single kernel though, which is to give distros a single kernel image that they can boot on different ARM platforms.

They want a single kernel binary that works everywhere, not one which they need to select the right binary to work on platform X. Yes, the internal uncompressed bulk may be the same, but it would require distros to carry around N different kernel images for N different platforms.

Quoted 9 lines · Russell King - ARM Linux

That rubbishes the idea of a single kernel though, which is to give distros a single kernel image that they can boot on different ARM platforms.

They want a single kernel binary that works everywhere, not one which they need to select the right binary to work on platform X. Yes, the internal uncompressed bulk may be the same, but it would require distros to carry around N different kernel images for N different platforms.

Right. It still helps the distros ensure that they only have a single configuration and a single binary to test, which I expect is their main interest, but keeping multiple copies of the same binary with different headers is a bit silly, I agree.

On PowerPC, we have a similar problem, and the way that distros usually deal with that is to do the final link of the zImage from the post-install stage of their rpm or deb packages, depending on the platform they are on. In the same stage, they also link in the newly created initrd and the device tree blob if necessary.

Quoted 13 lines · Arnd Bergmann

Quoted 10 lines · Stephen Warren

From: Stephen Warren <[email protected]>

Tegra's uncompress and debug-macro.S communicate to each-other. Hence, we can't be left without uncompress.h in a multi-platform enabled kernel, or we'll lose features. This series allows uncompress.h to be used in a multi-platform kernel, restores the mvebu uncompress.h, and finally moves the Tegra debug macros into the common location. The series as mainly an RFC due to the outstanding question of where to put Tegra's <mach/iomap.h> in the final patch.

Quoted 4 lines

To follow up on the IRC discussion we had yesterday leading to this patch set, I had another idea of how to handle the same: Since the decompressor code is actually fairly separate from the kernel, we could also build multiple versions of it, and link in the same compressed vmlinux.

That rubbishes the idea of a single kernel though, which is to give distros a single kernel image that they can boot on different ARM platforms.

They want a single kernel binary that works everywhere, not one which they need to select the right binary to work on platform X. Yes, the _internal_ uncompressed bulk may be the same, but it would require distros to carry around N different kernel images for N different platforms.

Will those of us not interested in a single kernel binary that works everywhere be able to configure an ARM kernel image without a lot of bloat?

Quoted 3 lines · Tim Bird

Will those of us not interested in a single kernel binary that works everywhere be able to configure an ARM kernel image without a lot of bloat?

I'm not aware of increase in code size from the single kernel image yet. If you find something, let us know.

My main issue is to avoid requiring the loading of drivers and features that are not required for a platform, if the platform does not need it (or the developer chooses to omit it). I may have mis-read this thread, but it sounded like the uncompress code was going to be moved to a common area and not be configurable.

Right now, a multiplatform kernel has no way of debugging the decompressor using console output, so it's actually /smaller/ than a single-platform kernel, but also less capable.

Quoted 3 lines · Arnd Bergmann

Right now, a multiplatform kernel has no way of debugging the decompressor using console output, so it's actually /smaller/ than a single-platform kernel, but also less capable.

Err, are you sure about all your details above? You do realise when debugging is disabled there is no debug code included anywhere in the decompressor?

I think what you're referring to is not the debug output, but the normal decompressor output. (The "Decompressing Linux..." message is not debug output.)

Let's be a little more clear about what "less capable" means - it will be unable to report any errors that occur during the decompression. What that means is that you'll end up with mere silence should an error occur.

In the Tegra case, by omitting uncompress.h, we lose more than just the "Decompressing Linux..." message; uncompress.h contains code to parse extract the platform's debug UART ID from data set up by the boot ROM (since we have 5 UARTs), and pass this on to debug-macro.S.

Without uncompress.h running, debug-macro.S would either have to hard-code a single UART ID (and different boards uses different UARTs, which would make running a single kernel image across all Tegra devices with earlyprintk enabled impossible) *or* we'd have to port the UART ID extraction code to debug-macro.S too,

which I don't fancy very much since that's assembly whereas uncompress.h is C.

From: Stephen Warren <[email protected]>

Tegra's uncompress and debug-macro.S communicate to each-other. Hence, we can't be left without uncompress.h in a multi-platform enabled kernel, or we'll lose features. This series allows uncompress.h to be used in a multi-platform kernel, restores the mvebu uncompress.h, and finally moves the Tegra debug macros into the common location. The series as mainly an RFC due to the outstanding question of where to put Tegra's <mach/iomap.h> in the final patch.

Stephen Warren (3):
ARM: move ICEDCC uncompress.h to common location
ARM: mvebu: restore uncompress.h
ARM: tegra: move debug macros to include/debug

 arch/arm/Kconfig.debug                             |   20 ++++++
 arch/arm/boot/compressed/misc.c                    |   64 +-------------------
 arch/arm/include/debug/icedcc-uncompress.h         |   61 +++++++++++++++++++
 arch/arm/include/debug/mvebu-uncompress.h          |   43 +++++++++++++
 arch/arm/include/debug/none-uncompress.h           |    3 +
 .../debug/tegra-uncompress.h}                      |    6 +-
 .../mach/debug-macro.S => include/debug/tegra.S}   |    6 +-
 7 files changed, 132 insertions(+), 71 deletions(-)
 create mode 100644 arch/arm/include/debug/icedcc-uncompress.h
 create mode 100644 arch/arm/include/debug/mvebu-uncompress.h
 create mode 100644 arch/arm/include/debug/none-uncompress.h
 rename arch/arm/{mach-tegra/include/mach/uncompress.h => include/debug/tegra-uncompress.h} (98%)
 rename arch/arm/{mach-tegra/include/mach/debug-macro.S => include/debug/tegra.S} (96%)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel