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@xxxxxxxxxx> > --- > 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.
