On 07/15/2016 10:29 AM, Tom Rini wrote:
On Fri, Jul 15, 2016 at 10:22:36AM -0600, Simon Glass wrote:
Hi Tom,
On 15 July 2016 at 10:13, Tom Rini <tr...@konsulko.com> wrote:
On Fri, Jul 15, 2016 at 10:08:34AM -0600, Simon Glass wrote:
Hi Tom,
On 15 July 2016 at 09:46, Tom Rini <tr...@konsulko.com> wrote:
On Fri, Jul 15, 2016 at 09:28:21AM -0600, Stephen Warren wrote:
On 07/14/2016 10:02 PM, Simon Glass wrote:
Hi Tom,
Here is the of-platdata implementation, including the introduction of
sandbox_spl.
The following changes since commit 3a592a1349ac3961b0f4f2db0a8d9f128225d897:
Revert "armv8: Enable CPUECTLR.SMPEN for coherency" (2016-07-14
17:36:18 -0400)
are available in the git repository at:
git://git.denx.de/u-boot-dm.git
for you to fetch changes up to 1269625177f120d659f66b18de4b532b16c44561:
dm: Update the of-platdata README for the new features (2016-07-14
20:40:24 -0600)
FYI, the latest u-boot-dm/mater fails test/py test test_ofplatdata()
on the following boards for me: beaver, dalmore, jetson-tk1. That's
all the 32-bit Tegra boards I'm testing.
It's also adding a warning:
w+(sandbox_spl) spl/dts/dt-platdata.c:38:2: warning: excess elements in
array initialize
r
w+(sandbox_spl) spl/dts/dt-platdata.c:38:2: warning: (near
initialization for ‘dtv_spl_t
est2.stringarray’)
What toolchain is this? Can you please send me the dt-platdata.c and
include/generated/dt-structs.h files?
I believe that was in Debian/Jessie and gcc-4.9.2. I'll send the files
off-list.
OK, I'm a bit stumped by that. There are two string arrays - it should
set the type to the larger of the two (i.e. 3 elements instead of 2).
I don't see this problem in my self. What version of Python do you
run? I will dig in and see if I can figure out what it is later on
today.
It's a stock Debian/Jessie, so whatever is default.
But given that sandbox_spl is a new board, perhaps it is OK to apply
this for now?
Yeah, but please follow up with a patch to fix the test thing Stephen
found and I'll grab it before pushing, test failures turn his Jenkins
setup red and then other stuff doesn't happen, iirc. Thanks!
Build failures prevent any tests from running on any boards,
unfortunately (perhaps I should make separate Jenkins jobs for each
board, or make the test trigger not depend on the build status).
Test failures don't prevent any other tests from running, but they do
make it harder to notice new failures; in the face of test failures,
each Jenkins test job has both an old and a new status of "failed" and I
then have to manually compare the list of failed tests. It's much easier
to notice new failures.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
