[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YUQyQgFAOFnBlcdP@atomide.com>
Date: Fri, 17 Sep 2021 09:14:26 +0300
From: Tony Lindgren <tony@...mide.com>
To: "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
Cc: "linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
Grygorii Strashko <grygorii.strashko@...com>,
Suman Anna <s-anna@...com>, "Andrew F. Davis" <afd@...com>,
Paul Barker <paul.barker@...cloud.com>,
Peter Ujfalusi <peter.ujfalusi@...il.com>,
BenoƮt Cousson <bcousson@...libre.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: beaglebone black boot failure Linux v5.15.rc1
Hi,
* Vaittinen, Matti <Matti.Vaittinen@...rohmeurope.com> [210916 09:15]:
> Yesterday I asked about this at #armlinux so if someone saw my message
> there - this is the same topic.
>
> My beaglebone black (rev c) based test environment fails to boot with
> v5.15-rc1. Boot succeeds with the v5.14.
>
> I use pretty old uBoot, TFTP to load kernel and device-tree, and have
> hosted the rootfs on NFS server.
Using older u-boot versions should be just fine. Using bootz with zImage
instead of uimage is a good reason to update for folks using a really
old u-boot though.
> The v5.15-rc1 fails to boot with no prints from kernel visible in serial
> console. Please see the serial log at the end of this message.
>
> Bisecting the Linus' tree pointed out the commit:
> [1c7ba565e70365763ea780666a3eee679344b962] ARM: dts: am335x-baltos:
> switch to new cpsw switch drv
>
> I don't see this exact commit touching the BBB device-tree. In Linus'
> tree it is a part of a merge commit. Reverting the whole merge on top of
> the v5.15-rc1
>
> This reverts commit 81b6a285737700c2e04ef0893617b80481b6b4b7, reversing
> changes made to f73979109bc11a0ed26b6deeb403fb5d05676ffc.
>
> makes my beaglebone black to boot again.
>
> Yesterday I tried adding this patch:
> https://lore.kernel.org/linux-omap/20210915065032.45013-1-tony@atomide.com/T/#u
> pointed by Tom on top of the v5.15-rc1 - no avail. I also did #define
> DEBUG at ti-sys.c as was suggested by Tom - but I don't see any more output.
Correction, that was me, not Tom :)
For me, adding any kind of delay fixed the issue. Also adding some printk
statements fixed it for me.
> Any suggestions what to check next?
Maybe try the attached patch? If it helps, just try with the with the
ti,sysc-delay-us = <2> added as few modules need that after enable.
It's also possible there is an issue with some other device that is now
getting enabled other than pruss. The last XXX printk output should show
the last device being probed.
Looks like you need to also enable CONFIG_SERIAL_EARLYCON=y, and pass
console=ttyS0,115200 debug earlycon in the kernel command line.
Regards,
Tony
View attachment "debug.patch" of type "text/plain" (1057 bytes)
Powered by blists - more mailing lists