| Message ID | 1373897706-15331-1-git-send-email-julien.grall@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, 15 Jul 2013, Julien Grall wrote: > Even if uncompress debug is disabled, some board will continue to print > information during uncompress step. Are you talking about DEBUG_UNCOMPRESS? Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected, some board will continue to print information during the uncompress step"? Isn't this a bug in the platform specific code that should be fixed anyway? > By using debug/uncompress.h include, all debug output will be disabled. I am not sure if this is the right solution to the problem. I think it might be better to add the appropriate ifdefs into the platform specific code. Arnd, what do you think? > This is usefull in Xen environment for DOM0 because the UART is stolen by > Xen. > > Signed-off-by: Julien Grall <julien.grall@linaro.org> > > arch/arm/Kconfig.debug | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug > index 21cc8a7..86c023d 100644 > --- a/arch/arm/Kconfig.debug > +++ b/arch/arm/Kconfig.debug > @@ -679,7 +679,7 @@ config DEBUG_UNCOMPRESS > > config UNCOMPRESS_INCLUDE > string > - default "debug/uncompress.h" if ARCH_MULTIPLATFORM > + default "debug/uncompress.h" if ARCH_MULTIPLATFORM || !DEBUG_UNCOMPRESS > default "mach/uncompress.h" > > config EARLY_PRINTK > -- > 1.7.10.4 >
On Wed, Jul 17, 2013 at 02:25:38PM +0100, Stefano Stabellini wrote: > On Mon, 15 Jul 2013, Julien Grall wrote: > > Even if uncompress debug is disabled, some board will continue to print > > information during uncompress step. > > Are you talking about DEBUG_UNCOMPRESS? > Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected, > some board will continue to print information during the uncompress step"? > > Isn't this a bug in the platform specific code that should be fixed anyway? Hang on, let's be clear what's going on here. 1. The normal output from the decompressor is *not* debugging. By that I mean the "Uncompressing kernel... done" message. That is part of user output. 2. In non-multiplatform environments, the decompressor will normally use the putc/flush functions found in arch/arm/mach-*/include/mach/uncompress.h to implement its output, irrespective of the DEBUG_UNCOMPRESS setting. (An interesting point is that DEBUG_UNCOMPRESS really should depend on MULTIPLATFORM so that this point is explicit - the option requires MULTIPLATFORM to be set.) 3. DEBUG_UNCOMPRESS allows the functions which we've implemented for LL debug to be re-used for decompressor output. 4. When DEBUG_UNCOMPRESS is not set in a multiplatform kernel, the decompressors putc() and flush() functions are stubbed out. So, it's quite right that you get output from the decompressor even when DEBUG_UNCOMPRESS is not set. There's no problem with that.
On 17 July 2013 14:25, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote: > On Mon, 15 Jul 2013, Julien Grall wrote: >> Even if uncompress debug is disabled, some board will continue to print >> information during uncompress step. > > Are you talking about DEBUG_UNCOMPRESS? > Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected, > some board will continue to print information during the uncompress step"? Yes. On the arndale, uncompress log are directly output on UART-2. This is annoying because Xen doesn't expose the UART to dom0. > Isn't this a bug in the platform specific code that should be fixed anyway? > >> By using debug/uncompress.h include, all debug output will be disabled. > > I am not sure if this is the right solution to the problem. > I think it might be better to add the appropriate ifdefs into the > platform specific code. -- Julien Grall
On Thu, Jul 18, 2013 at 05:15:21PM +0100, Julien Grall wrote: > On 17 July 2013 14:25, Stefano Stabellini > <stefano.stabellini@eu.citrix.com> wrote: > > On Mon, 15 Jul 2013, Julien Grall wrote: > >> Even if uncompress debug is disabled, some board will continue to print > >> information during uncompress step. > > > > Are you talking about DEBUG_UNCOMPRESS? > > Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected, > > some board will continue to print information during the uncompress step"? > > Yes. On the arndale, uncompress log are directly output on UART-2. > This is annoying because Xen doesn't expose the UART to dom0. The DEBUG_UNCOMPRESS option is not about whether the decompressor produces output or not. It is about the implementation of that output. * With non-multiplatform kernels, the output is sent to whatever functions are found in arch/arm/*/include/mach/uncompress.h. * With multiplatform kernels with DEBUG_UNCOMPRESS set, the output is sent using the kernel's LL debug functions. (hence it's name - it's saying that it uses the debug macros.) * With multiplatform kernels without DEBUG_UNCOMPRESS set, there is no way to know where to send the *normal* decompressor output, so we have decided that in this case and this case only, it shall be silent. The final thing to remember is... the normal output from the decompressor is *NOT* debug output. It's informational or error output. Everything here is working as intended.
On 07/17/2013 04:11 PM, Russell King - ARM Linux wrote: > On Wed, Jul 17, 2013 at 02:25:38PM +0100, Stefano Stabellini wrote: >> On Mon, 15 Jul 2013, Julien Grall wrote: >>> Even if uncompress debug is disabled, some board will continue to print >>> information during uncompress step. >> >> Are you talking about DEBUG_UNCOMPRESS? >> Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected, >> some board will continue to print information during the uncompress step"? >> >> Isn't this a bug in the platform specific code that should be fixed anyway? > > Hang on, let's be clear what's going on here. > > 1. The normal output from the decompressor is *not* debugging. By that > I mean the "Uncompressing kernel... done" message. That is part of > user output. > > 2. In non-multiplatform environments, the decompressor will normally use > the putc/flush functions found in arch/arm/mach-*/include/mach/uncompress.h > to implement its output, irrespective of the DEBUG_UNCOMPRESS setting. > (An interesting point is that DEBUG_UNCOMPRESS really should depend on > MULTIPLATFORM so that this point is explicit - the option requires > MULTIPLATFORM to be set.) > > 3. DEBUG_UNCOMPRESS allows the functions which we've implemented for LL > debug to be re-used for decompressor output. When Xen will boot, it will use one UART, given by the user, to be able to log its information. Xen will not map the UART region and the IRQ to dom0. Of course it will not be present in the device tree either. So if Linux tries to access to this memory region, it will crash. When Linux will boot as dom0, it will either use an hvc console or another UART. In case of multi-platform environments, there is no issue because when CONFIG_DEBUG_UNCOMPRESS is disabled. Now, in non-multiplatform environment, the decompressor will use a pre-defined UART. This UART may be already used by Xen and Linux will abort at the first access. I think, the decompressor should be able to detect if the UART exists (I'm not sure it's possible) or disabled at compile time uncompress log. Do you have any better ideas? Cheers,
On Thu, Jul 18, 2013 at 05:43:37PM +0100, Julien Grall wrote: > When Xen will boot, it will use one UART, given by the user, to be able > to log its information. Xen will not map the UART region and the IRQ to > dom0. Of course it will not be present in the device tree either. So if > Linux tries to access to this memory region, it will crash. > > When Linux will boot as dom0, it will either use an hvc console or > another UART. > > In case of multi-platform environments, there is no issue because when > CONFIG_DEBUG_UNCOMPRESS is disabled. > > Now, in non-multiplatform environment, the decompressor will use a > pre-defined UART. This UART may be already used by Xen and Linux will > abort at the first access. > > I think, the decompressor should be able to detect if the UART exists > (I'm not sure it's possible) or disabled at compile time uncompress log. > > Do you have any better ideas? Let me get this straight. 1. You want to run an _existing_ platforms kernel under Xen, where the platform assumes that it has various devices at various locations, and will make direct accesses to those devices. 2. You don't want to provide some of those devices, and you arrange for those unprovided devices to fault. Excuse me if I think that's really silly. Lastly, aren't all ARMv7 kernels (therefore Xen supporting kernels) supposed to be part of the multiplatform kernel stuff now?
On Thu, 18 Jul 2013, Russell King - ARM Linux wrote: > On Thu, Jul 18, 2013 at 05:43:37PM +0100, Julien Grall wrote: > > When Xen will boot, it will use one UART, given by the user, to be able > > to log its information. Xen will not map the UART region and the IRQ to > > dom0. Of course it will not be present in the device tree either. So if > > Linux tries to access to this memory region, it will crash. > > > > When Linux will boot as dom0, it will either use an hvc console or > > another UART. > > > > In case of multi-platform environments, there is no issue because when > > CONFIG_DEBUG_UNCOMPRESS is disabled. > > > > Now, in non-multiplatform environment, the decompressor will use a > > pre-defined UART. This UART may be already used by Xen and Linux will > > abort at the first access. > > > > I think, the decompressor should be able to detect if the UART exists > > (I'm not sure it's possible) or disabled at compile time uncompress log. > > > > Do you have any better ideas? > > Let me get this straight. > > 1. You want to run an _existing_ platforms kernel under Xen, where the > platform assumes that it has various devices at various locations, > and will make direct accesses to those devices. > > 2. You don't want to provide some of those devices, and you arrange for > those unprovided devices to fault. > > Excuse me if I think that's really silly. Unfortunately not all the platforms are available on multiplatform kernels. Also by the same argument, we wouldn't need device tree on non-multiplatform kernels because we could hardcode almost anything. > Lastly, aren't all ARMv7 kernels (therefore Xen supporting kernels) > supposed to be part of the multiplatform kernel stuff now? Most of them, yes. However some of them, like exynos5250, are not yet.
On Thu, 2013-07-18 at 17:15 +0100, Julien Grall wrote: > On 17 July 2013 14:25, Stefano Stabellini > <stefano.stabellini@eu.citrix.com> wrote: > > On Mon, 15 Jul 2013, Julien Grall wrote: > >> Even if uncompress debug is disabled, some board will continue to print > >> information during uncompress step. > > > > Are you talking about DEBUG_UNCOMPRESS? > > Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected, > > some board will continue to print information during the uncompress step"? > > Yes. On the arndale, uncompress log are directly output on UART-2. > This is annoying because Xen doesn't expose the UART to dom0. This is because Xen wants/tries to use the UART as its own console, right? There are at least two other options: Either Xen uses a different UART to that configured statically into the kernel image (depends on how many UARTs the platform exposes) or Xen uses no serial console at all. Of course long term we just need to wait for the exynos stuff to get integrated into the multiplatform kernel. Having no Xen serial console is not as bad as it seems for actual deployment, it is actually already the default on x86 (a serial console needs to be explicitly configured). The Xen console would still be available via the "xl dmesg" command and for debug environments people can just hack around the issue for now (until MP kernels arrive for the platform). Perhaps a useful compromise would be for Xen to initially use the console but to hand it over to dom0 once it starts (similar to how we handle VGA where it is present), Xen could also steal it back on panic (since dom0 isn't going to be using it after that...). Alternatively, since these early UART routines tend to be pretty simple polled affairs, we could also consider extending the existing vpl011 code to have platform configurable addresses for the output and status registers and a configurable fixed value for the read of the status register. I'm not keen to have this code turn into a full "emulator" but so long as it stays within the remit given in vpl011.c: /* * This is not intended to be a full emulation of a PL011 * device. Rather it is intended to provide a sufficient veneer of one * that early code (such as Linux's boot time decompressor) which * hardcodes output directly to such a device are able to make progress. * * This device is not intended to be enumerable or exposed to the OS * (e.g. via Device Tree). */ then I think I could live with it getting a bit more flexible about where the registers live in order to be able to handle more UART variants. Ian.
On Fri, 19 Jul 2013, Ian Campbell wrote: > On Thu, 2013-07-18 at 17:15 +0100, Julien Grall wrote: > > On 17 July 2013 14:25, Stefano Stabellini > > <stefano.stabellini@eu.citrix.com> wrote: > > > On Mon, 15 Jul 2013, Julien Grall wrote: > > >> Even if uncompress debug is disabled, some board will continue to print > > >> information during uncompress step. > > > > > > Are you talking about DEBUG_UNCOMPRESS? > > > Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected, > > > some board will continue to print information during the uncompress step"? > > > > Yes. On the arndale, uncompress log are directly output on UART-2. > > This is annoying because Xen doesn't expose the UART to dom0. > > This is because Xen wants/tries to use the UART as its own console, > right? > > There are at least two other options: Either Xen uses a different UART > to that configured statically into the kernel image (depends on how many > UARTs the platform exposes) or Xen uses no serial console at all. > > Of course long term we just need to wait for the exynos stuff to get > integrated into the multiplatform kernel. > > Having no Xen serial console is not as bad as it seems for actual > deployment, it is actually already the default on x86 (a serial console > needs to be explicitly configured). The Xen console would still be > available via the "xl dmesg" command and for debug environments people > can just hack around the issue for now (until MP kernels arrive for the > platform). > > Perhaps a useful compromise would be for Xen to initially use the > console but to hand it over to dom0 once it starts (similar to how we > handle VGA where it is present), Xen could also steal it back on panic > (since dom0 isn't going to be using it after that...). I like this last option, it looks like the best compromise. > Alternatively, since these early UART routines tend to be pretty simple > polled affairs, we could also consider extending the existing vpl011 > code to have platform configurable addresses for the output and status > registers and a configurable fixed value for the read of the status > register. I'm not keen to have this code turn into a full "emulator" but > so long as it stays within the remit given in vpl011.c: > /* > * This is not intended to be a full emulation of a PL011 > * device. Rather it is intended to provide a sufficient veneer of one > * that early code (such as Linux's boot time decompressor) which > * hardcodes output directly to such a device are able to make progress. > * > * This device is not intended to be enumerable or exposed to the OS > * (e.g. via Device Tree). > */ > then I think I could live with it getting a bit more flexible about > where the registers live in order to be able to handle more UART > variants. We could end up emulating way too many devices and not all the platforms expect a pl011 uart.
On Fri, 2013-07-19 at 10:52 +0100, Stefano Stabellini wrote: > On Fri, 19 Jul 2013, Ian Campbell wrote: > > On Thu, 2013-07-18 at 17:15 +0100, Julien Grall wrote: > > > On 17 July 2013 14:25, Stefano Stabellini > > > <stefano.stabellini@eu.citrix.com> wrote: > > > > On Mon, 15 Jul 2013, Julien Grall wrote: > > > >> Even if uncompress debug is disabled, some board will continue to print > > > >> information during uncompress step. > > > > > > > > Are you talking about DEBUG_UNCOMPRESS? > > > > Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected, > > > > some board will continue to print information during the uncompress step"? > > > > > > Yes. On the arndale, uncompress log are directly output on UART-2. > > > This is annoying because Xen doesn't expose the UART to dom0. > > > > This is because Xen wants/tries to use the UART as its own console, > > right? > > > > There are at least two other options: Either Xen uses a different UART > > to that configured statically into the kernel image (depends on how many > > UARTs the platform exposes) or Xen uses no serial console at all. > > > > Of course long term we just need to wait for the exynos stuff to get > > integrated into the multiplatform kernel. > > > > Having no Xen serial console is not as bad as it seems for actual > > deployment, it is actually already the default on x86 (a serial console > > needs to be explicitly configured). The Xen console would still be > > available via the "xl dmesg" command and for debug environments people > > can just hack around the issue for now (until MP kernels arrive for the > > platform). > > > > Perhaps a useful compromise would be for Xen to initially use the > > console but to hand it over to dom0 once it starts (similar to how we > > handle VGA where it is present), Xen could also steal it back on panic > > (since dom0 isn't going to be using it after that...). > > I like this last option, it looks like the best compromise. > > > > Alternatively, since these early UART routines tend to be pretty simple > > polled affairs, we could also consider extending the existing vpl011 > > code to have platform configurable addresses for the output and status > > registers and a configurable fixed value for the read of the status > > register. I'm not keen to have this code turn into a full "emulator" but > > so long as it stays within the remit given in vpl011.c: > > /* > > * This is not intended to be a full emulation of a PL011 > > * device. Rather it is intended to provide a sufficient veneer of one > > * that early code (such as Linux's boot time decompressor) which > > * hardcodes output directly to such a device are able to make progress. > > * > > * This device is not intended to be enumerable or exposed to the OS > > * (e.g. via Device Tree). > > */ > > then I think I could live with it getting a bit more flexible about > > where the registers live in order to be able to handle more UART > > variants. > > We could end up emulating way too many devices and not all the platforms > expect a pl011 uart. My point was that all of these debug routines expect exactly two things: * An output register where they can write a character * A status register which when read indicates that a new byte can be sent The existing pl011.c could be extended to provide this level of functionality for *any* UART, at least to the degree required by this code, almost trivially, by simply making the two addresses and the static status register value configurable. The status register value is static for us because we have no FIFOs and just accumulate into a buffer to be sent to the real console, so it is always possible to send another byte. ISTR some talk of doing something similar for the early-printk stuff via DT, might have imagined that though... Ian.
On Fri, 19 Jul 2013, Ian Campbell wrote: > On Fri, 2013-07-19 at 10:52 +0100, Stefano Stabellini wrote: > > On Fri, 19 Jul 2013, Ian Campbell wrote: > > > On Thu, 2013-07-18 at 17:15 +0100, Julien Grall wrote: > > > > On 17 July 2013 14:25, Stefano Stabellini > > > > <stefano.stabellini@eu.citrix.com> wrote: > > > > > On Mon, 15 Jul 2013, Julien Grall wrote: > > > > >> Even if uncompress debug is disabled, some board will continue to print > > > > >> information during uncompress step. > > > > > > > > > > Are you talking about DEBUG_UNCOMPRESS? > > > > > Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected, > > > > > some board will continue to print information during the uncompress step"? > > > > > > > > Yes. On the arndale, uncompress log are directly output on UART-2. > > > > This is annoying because Xen doesn't expose the UART to dom0. > > > > > > This is because Xen wants/tries to use the UART as its own console, > > > right? > > > > > > There are at least two other options: Either Xen uses a different UART > > > to that configured statically into the kernel image (depends on how many > > > UARTs the platform exposes) or Xen uses no serial console at all. > > > > > > Of course long term we just need to wait for the exynos stuff to get > > > integrated into the multiplatform kernel. > > > > > > Having no Xen serial console is not as bad as it seems for actual > > > deployment, it is actually already the default on x86 (a serial console > > > needs to be explicitly configured). The Xen console would still be > > > available via the "xl dmesg" command and for debug environments people > > > can just hack around the issue for now (until MP kernels arrive for the > > > platform). > > > > > > Perhaps a useful compromise would be for Xen to initially use the > > > console but to hand it over to dom0 once it starts (similar to how we > > > handle VGA where it is present), Xen could also steal it back on panic > > > (since dom0 isn't going to be using it after that...). > > > > I like this last option, it looks like the best compromise. > > > > > > > Alternatively, since these early UART routines tend to be pretty simple > > > polled affairs, we could also consider extending the existing vpl011 > > > code to have platform configurable addresses for the output and status > > > registers and a configurable fixed value for the read of the status > > > register. I'm not keen to have this code turn into a full "emulator" but > > > so long as it stays within the remit given in vpl011.c: > > > /* > > > * This is not intended to be a full emulation of a PL011 > > > * device. Rather it is intended to provide a sufficient veneer of one > > > * that early code (such as Linux's boot time decompressor) which > > > * hardcodes output directly to such a device are able to make progress. > > > * > > > * This device is not intended to be enumerable or exposed to the OS > > > * (e.g. via Device Tree). > > > */ > > > then I think I could live with it getting a bit more flexible about > > > where the registers live in order to be able to handle more UART > > > variants. > > > > We could end up emulating way too many devices and not all the platforms > > expect a pl011 uart. > > My point was that all of these debug routines expect exactly two things: > * An output register where they can write a character > * A status register which when read indicates that a new byte can be > sent > > The existing pl011.c could be extended to provide this level of > functionality for *any* UART, at least to the degree required by this > code, almost trivially, by simply making the two addresses and the > static status register value configurable. > > The status register value is static for us because we have no FIFOs and > just accumulate into a buffer to be sent to the real console, so it is > always possible to send another byte. > > ISTR some talk of doing something similar for the early-printk stuff via > DT, might have imagined that though... That's interesting but what about the meaning of the various bits of the status register? It's not going to be always the same for the various uarts, we would need to take into account at least that.
On Fri, 2013-07-19 at 11:06 +0100, Stefano Stabellini wrote: > On Fri, 19 Jul 2013, Ian Campbell wrote: > > On Fri, 2013-07-19 at 10:52 +0100, Stefano Stabellini wrote: > > > On Fri, 19 Jul 2013, Ian Campbell wrote: > > > > On Thu, 2013-07-18 at 17:15 +0100, Julien Grall wrote: > > > > > On 17 July 2013 14:25, Stefano Stabellini > > > > > <stefano.stabellini@eu.citrix.com> wrote: > > > > > > On Mon, 15 Jul 2013, Julien Grall wrote: > > > > > >> Even if uncompress debug is disabled, some board will continue to print > > > > > >> information during uncompress step. > > > > > > > > > > > > Are you talking about DEBUG_UNCOMPRESS? > > > > > > Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected, > > > > > > some board will continue to print information during the uncompress step"? > > > > > > > > > > Yes. On the arndale, uncompress log are directly output on UART-2. > > > > > This is annoying because Xen doesn't expose the UART to dom0. > > > > > > > > This is because Xen wants/tries to use the UART as its own console, > > > > right? > > > > > > > > There are at least two other options: Either Xen uses a different UART > > > > to that configured statically into the kernel image (depends on how many > > > > UARTs the platform exposes) or Xen uses no serial console at all. > > > > > > > > Of course long term we just need to wait for the exynos stuff to get > > > > integrated into the multiplatform kernel. > > > > > > > > Having no Xen serial console is not as bad as it seems for actual > > > > deployment, it is actually already the default on x86 (a serial console > > > > needs to be explicitly configured). The Xen console would still be > > > > available via the "xl dmesg" command and for debug environments people > > > > can just hack around the issue for now (until MP kernels arrive for the > > > > platform). > > > > > > > > Perhaps a useful compromise would be for Xen to initially use the > > > > console but to hand it over to dom0 once it starts (similar to how we > > > > handle VGA where it is present), Xen could also steal it back on panic > > > > (since dom0 isn't going to be using it after that...). > > > > > > I like this last option, it looks like the best compromise. > > > > > > > > > > Alternatively, since these early UART routines tend to be pretty simple > > > > polled affairs, we could also consider extending the existing vpl011 > > > > code to have platform configurable addresses for the output and status > > > > registers and a configurable fixed value for the read of the status > > > > register. I'm not keen to have this code turn into a full "emulator" but > > > > so long as it stays within the remit given in vpl011.c: > > > > /* > > > > * This is not intended to be a full emulation of a PL011 > > > > * device. Rather it is intended to provide a sufficient veneer of one > > > > * that early code (such as Linux's boot time decompressor) which > > > > * hardcodes output directly to such a device are able to make progress. > > > > * > > > > * This device is not intended to be enumerable or exposed to the OS > > > > * (e.g. via Device Tree). > > > > */ > > > > then I think I could live with it getting a bit more flexible about > > > > where the registers live in order to be able to handle more UART > > > > variants. > > > > > > We could end up emulating way too many devices and not all the platforms > > > expect a pl011 uart. > > > > My point was that all of these debug routines expect exactly two things: > > * An output register where they can write a character > > * A status register which when read indicates that a new byte can be > > sent > > > > The existing pl011.c could be extended to provide this level of > > functionality for *any* UART, at least to the degree required by this > > code, almost trivially, by simply making the two addresses and the > > static status register value configurable. > > > > The status register value is static for us because we have no FIFOs and > > just accumulate into a buffer to be sent to the real console, so it is > > always possible to send another byte. > > > > ISTR some talk of doing something similar for the early-printk stuff via > > DT, might have imagined that though... > > That's interesting but what about the meaning of the various bits of the > status register? It's not going to be always the same for the various > uarts, we would need to take into account at least that. Yes, hence making the static value read from the status register configurable too. Ian.
On Thursday 18 July 2013, Stefano Stabellini wrote: > > Lastly, aren't all ARMv7 kernels (therefore Xen supporting kernels) > > supposed to be part of the multiplatform kernel stuff now? > > Most of them, yes. However some of them, like exynos5250, are not yet. It's just a matter of time. I had a patch for 3.10 to enable multiplatform on exynos, but it missed both the 3.10 and 3.11 merge windows by a small margin (for different reasons). We definitely want all ARMv7 platforms to be multiplatform in the not too distant future. Arnd
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index 21cc8a7..86c023d 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -679,7 +679,7 @@ config DEBUG_UNCOMPRESS config UNCOMPRESS_INCLUDE string - default "debug/uncompress.h" if ARCH_MULTIPLATFORM + default "debug/uncompress.h" if ARCH_MULTIPLATFORM || !DEBUG_UNCOMPRESS default "mach/uncompress.h" config EARLY_PRINTK
Even if uncompress debug is disabled, some board will continue to print information during uncompress step. By using debug/uncompress.h include, all debug output will be disabled. This is usefull in Xen environment for DOM0 because the UART is stolen by Xen. Signed-off-by: Julien Grall <julien.grall@linaro.org> --- arch/arm/Kconfig.debug | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)