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

[Linus Walleij]

On Wed, Sep 23, 2020 at 12:13 AM Dmitry Osipenko <digetx at 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