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

Dmitry Osipenko digetx at gmail.com
Wed Nov 4 15:40:05 EST 2020


29.09.2020 16:48, 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.

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!



More information about the linux-arm-kernel mailing list