[U-Boot] 2017.05-RC3 hanging on DM3730

[Siarhei Siamashka <siarhei.siamashka@gmail.com>]

On Thu, 4 May 2017 18:38:39 -0500
Adam Ford <aford173@gmail.com> wrote:

> On Thu, May 4, 2017 at 6:08 PM, Tom Rini <trini@konsulko.com> wrote:
> > On Thu, May 04, 2017 at 05:58:47PM -0500, Adam Ford wrote:  
> >> On Thu, May 4, 2017 at 4:27 PM, Tom Rini <trini@konsulko.com> wrote:  
> >> > On Thu, May 04, 2017 at 04:06:33PM -0500, Adam Ford wrote:
> >> >  
> >> >> Tom,
> >> >>
> >> >> I re-synced my U-boot trunk today and did a clean build and found that
> >> >> SPL isn't able to load U-Boot.
> >> >>
> >> >> U-Boot SPL 2017.05-rc3 (May 04 2017 - 15:48:21)
> >> >>
> >> >>
> >> >> I haven't had a chance yet to bisect the issue.  Do you know when you
> >> >> plan to do the 2017.05 release?  I'd like to try and locate the issue
> >> >> before the final release.  
> >> >
> >> > I'd like to do the release on Monday.  Can you please start bisecting?  
> >>
> >> I bisected it since I won't have time tomorrow or this weekend.
> >>
> >> Commit 7584f2e0fb0f ("arm: omap3: Compile clock.c with -marm option to
> >> unbreak OMAP3530") seems to break the OMAP3630 (DM3730) in that
> >> nothing boots at all:
> >>
> >>    (dead)
> >>
> >>
> >> Commit 19a75b8cf8d1("arm: omap3: Bring back ARM errata workaround
> >> 725233") at least shows some activity, but not enough to do anything:
> >>
> >>    U-Boot SPL 2017.03-00007-g19a75b8 (May 04 2017 - 17:53:10)
> >>
> >>    (dead)
> >>
> >> I am wondering if other OMAP36/37 devices have had any issues?  
> >
> > My bbXM is working.  Can you try and see which of the errata is breaking
> > your particular setup?  Thanks!  
> 
> It appears to be a toolchain issue.  I use Buildroot which builds
> everything from scratch. I specify some items like glibc, gcc version,
> binutils, etc.
> 
> I am not sure why the removal of "CFLAGS_clock.o += -marm" causes an issue.
> 
> When I built it with Linaro 2016.11 it worked, but that version is
> tuned for a corex-A9, but it proves the code is ok.  Sorry for the
> noise.

Hello,

It is actually unlikely to be a toolchain issue, but more like
some racy code in U-boot, which happens to be timing sensitive. As
the commit message [1] says, it was not a proper fix but a quick and
dirty workaround. More information is also available in the mailing
list archive [2].
    
Anyway, thanks a lot for your feedback. It's good to know that DM3730
is also affected. Because this clearly rules out any possible impact
of some Thumb2 errata (OMAP3530 had an old bug ridden Cortex-A8, but
DM3730 has the latest revision of it).

Right now the OMAP3 clock code has some sort of a timing sensitive
latent bug and it may potentially blow up on any future toolchain
update (regardless of the use of the ARM or Thumb2 mode). So it's
best if somebody finds the root cause and fixes it. But I guess,
OMAP3 is very old and does not get much love nowadays.


1. http://git.denx.de/?p=u-boot.git;a=commit;h=7584f2e0fb0f
2. https://lists.denx.de/pipermail/u-boot/2017-March/283078.html

-- 
Best regards,
Siarhei Siamashka