[U-Boot] Please pull u-boot-dm

[Stephen Warren]

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 <trini at 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 <trini at 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.