* Re: [PATCH] ARM: uncompress: Enable debug in head.S [not found] <20200901124736.155281-1-linus.walleij@linaro.org> @ 2020-09-22 22:13 ` Dmitry Osipenko 2020-09-29 13:48 ` Linus Walleij 0 siblings, 1 reply; 4+ messages in thread From: Dmitry Osipenko @ 2020-09-22 22:13 UTC (permalink / raw) To: Linus Walleij, Russell King; +Cc: linux-arm-kernel, linux-tegra 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] ARM: uncompress: Enable debug in head.S 2020-09-22 22:13 ` [PATCH] ARM: uncompress: Enable debug in head.S Dmitry Osipenko @ 2020-09-29 13:48 ` Linus Walleij 2020-11-04 20:40 ` Dmitry Osipenko 0 siblings, 1 reply; 4+ messages in thread From: Linus Walleij @ 2020-09-29 13:48 UTC (permalink / raw) To: Dmitry Osipenko; +Cc: Russell King, Linux ARM, linux-tegra 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] ARM: uncompress: Enable debug in head.S 2020-09-29 13:48 ` Linus Walleij @ 2020-11-04 20:40 ` Dmitry Osipenko 2020-11-10 13:28 ` Linus Walleij 0 siblings, 1 reply; 4+ messages in thread From: Dmitry Osipenko @ 2020-11-04 20:40 UTC (permalink / raw) To: Linus Walleij; +Cc: Russell King, Linux ARM, linux-tegra 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! ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] ARM: uncompress: Enable debug in head.S 2020-11-04 20:40 ` Dmitry Osipenko @ 2020-11-10 13:28 ` Linus Walleij 0 siblings, 0 replies; 4+ messages in thread From: Linus Walleij @ 2020-11-10 13:28 UTC (permalink / raw) To: Dmitry Osipenko; +Cc: Russell King, Linux ARM, linux-tegra 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-11-10 13:29 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20200901124736.155281-1-linus.walleij@linaro.org> 2020-09-22 22:13 ` [PATCH] ARM: uncompress: Enable debug in head.S Dmitry Osipenko 2020-09-29 13:48 ` Linus Walleij 2020-11-04 20:40 ` Dmitry Osipenko 2020-11-10 13:28 ` Linus Walleij
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).