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