My employer is committed to producing product with the DM3730 until mid
2020's. Even if nobody else pushes OMAP3, I am willing to experiment and
try code. If someone has something they need me to try.
Adam
On Jul 24, 2017 10:10 PM, "Siarhei Siamashka" <siarhei.siamas...@gmail.com>
wrote:
> On Thu, 4 May 2017 18:38:39 -0500
> Adam Ford <aford...@gmail.com> wrote:
>
> > On Thu, May 4, 2017 at 6:08 PM, Tom Rini <tr...@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 <tr...@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
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
