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

Re: [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@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.

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

[Linus Walleij]

On Wed, Sep 23, 2020 at 12:13 AM Dmitry Osipenko <digetx@gmail.com> wrote:

> 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.

Hm let's try to fix that.

So you got the "Uncompressing Linux..." message before and all
worked fine? So we know the physical UART base is correct.

> 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.

Could you try to implement
waituarttxrdy in arch/arm/include/debug/tegra.S?
A copy of the contents in busyuart should work.

I suspect this could be FIFO overflow making the hardware
hang.

If this is trouble to you I can try to make a patch
that you can test, just tell me.

> 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

Hmmmm is the physical and virtual address to the UART
really correct?

Else it might write in some random memory.

Yours,
Linus Walleij

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

[Dmitry Osipenko]

29.09.2020 16:48, Linus Walleij пишет:
> On Wed, Sep 23, 2020 at 12:13 AM Dmitry Osipenko <digetx@gmail.com> wrote:
> 
>> 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.
> 
> Hm let's try to fix that.
> 
> So you got the "Uncompressing Linux..." message before and all
> worked fine? So we know the physical UART base is correct.
> 
>> 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.
> 
> Could you try to implement
> waituarttxrdy in arch/arm/include/debug/tegra.S?
> A copy of the contents in busyuart should work.
> 
> I suspect this could be FIFO overflow making the hardware
> hang.
> 
> If this is trouble to you I can try to make a patch
> that you can test, just tell me.
> 
>> 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
> 
> Hmmmm is the physical and virtual address to the UART
> really correct?
> 
> Else it might write in some random memory.

Hello Linus,

Just want to let you know that the problem isn't fixed yet and I haven't
got around to work on yet too. Hopefully next week!

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

[Linus Walleij]

On Wed, Nov 4, 2020 at 9:40 PM Dmitry Osipenko <digetx@gmail.com> wrote:
> 29.09.2020 16:48, Linus Walleij пишет:

> >> 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
> >
> > Hmmmm is the physical and virtual address to the UART
> > really correct?
> >
> > Else it might write in some random memory.
>
> Hello Linus,
>
> Just want to let you know that the problem isn't fixed yet and I haven't
> got around to work on yet too. Hopefully next week!

OK it's "just" debug code after all but it is working on at least 5
different platforms I tested with so I strongly suspect something
fishy with the Tegra include/debug/tegra.S.

This debug macro file is bigger than any of the others and I
see some suspicious amount of clock code and what not
in there so I am not sure what can cause this.

I would test to implement waituarttxrdy first and see what
happens if you just do that. I remember that those early
debug prints use the macros slightly different from the
"Uncompressing..." message.

Yours,
Linus Walleij