[cip-dev] u-boot policy for CIP

[wolfgang.mauerer@siemens.com (Wolfgang Mauerer)]

Hi Chris,

On 12.04.2017 10:34, Chris Paterson wrote:
> Hello all,
>
> I'd like to reach some conclusion on the discussion/policy about
> u-boot. We briefly spoke about it in the last TSC, and agreed to
> continue the discussion here.
>
> As highlighted by Ben and Wolfgang, a policy should be driven by the
> use-case requirements from the member companies. Until more feedback
> comes in from the member companies, would it be an idea for me to
> draft an outline policy we can use to focus discussions? Sometimes it
> is easier to have a starting point to amend, rather than waffle
> aimlessly.

that's a good idea, thanks for pushing this forward. Discussions
are usually easier when there's some starting point. I'll try
to get some in-company requirements via our internal channels.

Thanks, Wolfgang
>
> On a side note, I won't be able to attend the next TSC (Easter
> holidays), but please continue the discussion without me.
>
>
> Kind regards, Chris
>
>
>> From: Ben Hutchings [mailto:ben.hutchings at codethink.co.uk] Sent: 24
>> March 2017 17:53
>>
>> On Thu, 2017-03-16 at 12:07 +0000, Chris Paterson wrote:
>>
>>> I?m bringing a discussion I?ve started in other places here as it
>>> will benefit from wider participation.
>>
>> Thank you.  I have limited knowledge of u-boot, but I did work on
>> it recently to add support for a new board.
>>
>> [...]
>>> Ideally CIP should choose a version of u-boot and use it when
>>> testing/verifying the CIP Kernel on the reference hardware.
>>
>> We should certainly pick one version for each reference board.
>>
>>> How we actively maintain that version (bug fixes/security
>>> patches/features?) is another question. Given that most devices
>>> in the field won?t have a way to update u-boot in the field
>>> (security issues/practicalities), I think ?SLTS? support for
>>> u-boot may not be required. Perhaps we just tag a version of
>>> u-boot at the launch of a new CIP Kernel and stick with it?
>>
>> If u-boot is configured to use network boot, or to require
>> authentication of its environment or boot images, or authentication
>> to interrupt boot (CONFIG_AUTOBOOT_KEYED=y), then it is sometimes
>> handling untrusted input and might need security updates.
>> Otherwise it probably does not.
>>
>> It seems possible that some fixes might be needed to improve
>> reliability, e.g. if boot timing changes as hardware gets older.
>>
>>> How do we decide what u-boot version to support? Currently it
>>> looks like the BBB platform are shipped with 2014.04
>>
>> I have a new BBB that came with 2015.10 installed.  So we cannot be
>> certain that a particular model of board will always be shipped
>> with the same version!
>>
>>> and the Renesas platform is shipped with 2013.01. That said, it
>>> looks like there is upstream support for BBB [1], but how the
>>> feature set compares to the version shipped with the platform I
>>> don?t know. There is also support for some Renesas platforms [2],
>>> but not for the exact board CIP will be using.
>>>
>>> Do we want to push Ti/Renesas to ensure there is full support
>>> for their boards upstream? When this is done do we pick the first
>>> version that includes this support to work with? Or do we just
>>> stick with the vendor provided forks?
>>
>> I don't have an opinion on whether CIP should provide support for
>> u-boot, beyond the testing it will get through booting each kernel
>> to be tested.  If we do, I would prefer not to include vendor forks
>> as this could greatly increase the maintenance effort.
>>
>>> Is there a particular feature set that CIP requires?
>> [...]
>>
>> For testing purposes we will need at least an unauthenticated
>> command prompt (CONFIG_AUTOBOOT_KEYED=n), networking and TFTP
>> support. That probably isn't a complete list.
>>
>> Ben.
>>
>> -- Ben Hutchings Software Developer, Codethink Ltd.
>>
>
> _______________________________________________ cip-dev mailing list
> cip-dev at lists.cip-project.org
> https://lists.cip-project.org/mailman/listinfo/cip-dev
>