29.09.2020 16:48, Linus Walleij пишет: > 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. 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!
