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