[PATCH] ARM: uncompress: Enable debug in head.S

[Dmitry Osipenko]

01.09.2020 15:47, Linus Walleij пишет:
> The assembly file head.S includes some debug code that does
> not get enabled when we select CONFIG_DEBUG_UNCOMPRESS.
> The debug in head.S relies on the user tagging on -DDEBUG
> on the compilation command line.
> 
> To simplify debugging, tag on -DDEBUG so that we also get
> these debug messages when selecting CONFIG_DEBUG_UNCOMPRESS.
> 
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
>  arch/arm/boot/compressed/Makefile | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
> index 362e17e37398..ba50e0f4781e 100644
> --- a/arch/arm/boot/compressed/Makefile
> +++ b/arch/arm/boot/compressed/Makefile
> @@ -12,6 +12,7 @@ HEAD	= head.o
>  OBJS	+= misc.o decompress.o
>  ifeq ($(CONFIG_DEBUG_UNCOMPRESS),y)
>  OBJS	+= debug.o
> +AFLAGS_head.o += -DDEBUG
>  endif
>  FONTC	= $(srctree)/lib/fonts/font_acorn_8x8.c
>  
> 

Hello, Linus!

I have CONFIG_DEBUG_UNCOMPRESS=y and was trying today's linux-next which
unfortunately doesn't work well on NVIDIA Tegra30 because it's
frequently failing to boot, hanging early during boot, about 1 of 5
boots are failing. Then I also noticed that Tegra20 has a similar
problem, but worse, only 1 of 10 boots succeed.

I loaded Tegra2 QEMU and got it also hanging on boot. I retried multiple
times and most of the times it's was a silent CPU hang, but one time I
got an endlessly reoccurring debug message from QEMU telling that CPU
tries to write to a wrong/non-existent IO address. Then I attached to
QEMU's GDB session and found that CPU hangs at the busyuart. Reverting
this patch resolves the trouble for both QEMU and real HW.

I also tried to revert only the "ARM: 9006/1: uncompress: Wait for ready
and busy in debug prints" patch and got this in QEMU:

Starting kernel ...

DTB:0x016F6A20 (0x00005DA6)
C:0x010000C0-0x016FC820->0x0125AF00-0x01957660
Uncompressing Linux...

LZMA data is corrupt

 -- System halted

Interestingly, disabling CONFIG_THUMB2_KERNEL fixes the LZMA corruption
in QEMU and kernel boots up fine, but it doesn't help the real HW. I
don't have UART access to the real HW, hence have no clue what's wrong
with it.