* [cip-dev] u-boot policy for CIP
2017-03-16 12:07 [cip-dev] u-boot policy for CIP Chris Paterson
@ 2017-03-23 18:03 ` Agustin Benito Bethencourt
2017-03-24 16:15 ` Wolfgang Mauerer
2017-03-24 17:53 ` Ben Hutchings
2 siblings, 0 replies; 6+ messages in thread
From: Agustin Benito Bethencourt @ 2017-03-23 18:03 UTC (permalink / raw)
To: cip-dev
Hi,
On 16/03/17 12:07, Chris Paterson wrote:
> Hello all,
>
> I?m bringing a discussion I?ve started in other places here as it will
> benefit from wider participation.
>
> As you know the aim of CIP is to maintain not just the Kernel, but a
> number of other ?core packages?. One of these is u-boot.
>
> For the Kernel the project will provide super long term support for a
> chosen version. For u-boot this will be harder to achieve as
>
> a)there are no ?LTS? versions of u-boot to base our ?SLTS? version on;
>
> b)a lot of hardware providers tend to use forks for their platforms,
> rather than add full functionality upstream.
>
> Ideally CIP should choose a version of u-boot and use it when
> testing/verifying the CIP Kernel on the reference hardware. 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?
>
> How do we decide what u-boot version to support? Currently it looks like
> the BBB platform are shipped with 2014.04 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?
>
> Is there a particular feature set that CIP requires?
>
> Forgive my random ramblings, I appreciate there are a lot of different
> questions here!
Slightly related to this topic, Ben H. gave a talk/Q&A about hardware
support in Debian Stable back in DebConf13
Link: https://www.youtube.com/watch?v=oLTs1ikQR5E
>
> [1] https://github.com/u-boot/u-boot/tree/master/board/ti/am335x
>
> [2] https://github.com/u-boot/u-boot/tree/master/board/renesas
>
> Kind regards, Chris
>
>
>
> _______________________________________________
> cip-dev mailing list
> cip-dev at lists.cip-project.org
> https://lists.cip-project.org/mailman/listinfo/cip-dev
>
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito at codethink.co.uk
^ permalink raw reply [flat|nested] 6+ messages in thread
* [cip-dev] u-boot policy for CIP
2017-03-16 12:07 [cip-dev] u-boot policy for CIP Chris Paterson
2017-03-23 18:03 ` Agustin Benito Bethencourt
@ 2017-03-24 16:15 ` Wolfgang Mauerer
2017-03-24 17:53 ` Ben Hutchings
2 siblings, 0 replies; 6+ messages in thread
From: Wolfgang Mauerer @ 2017-03-24 16:15 UTC (permalink / raw)
To: cip-dev
Hi Chris,
On 16.03.2017 13:07, Chris Paterson wrote:
> Hello all,
>
>
>
> I?m bringing a discussion I?ve started in other places here as it will
> benefit from wider participation.
>
>
>
> As you know the aim of CIP is to maintain not just the Kernel, but a
> number of other ?core packages?. One of these is u-boot.
>
>
>
> For the Kernel the project will provide super long term support for a
> chosen version. For u-boot this will be harder to achieve as
>
> a) there are no ?LTS? versions of u-boot to base our ?SLTS? version on;
>
> b) a lot of hardware providers tend to use forks for their
> platforms, rather than add full functionality upstream.
thanks for raising this question. The problem you describe does not just
exist for U-Boot, but also for many other components that we will be
looking into.
>
>
>
> Ideally CIP should choose a version of u-boot and use it when
> testing/verifying the CIP Kernel on the reference hardware. 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?
I also assume that updating the bootloader is currently not required
for many appliances, so it suffices to ensure it is labelled properly
and can be (slt) re-produced for these cases.
However, things change when networking features of U-Boot come
into play. These are usually used during product development, but
I imagine that certain (IoT-class) devices will use such features more
in the future. For these cases, it would be desirable to have something
like a CIP standardised update process for the boot loader besides
a SLTS version. Do member companies plan to employ these features
for other than development/debugging purposes in the future?
If the boot loader is part of a secure/trusted boot scenario, the
ability to update U-Boot will also become more important, but that
depends on the threat models.
To me, it seems important to collect information from the members
on U-Boot use-cases, and then decide if and what further action is
necessary. For Siemens at least, I would not be able to come up with a
definitive set of requirements without asking around in the company.
>
>
>
> How do we decide what u-boot version to support? Currently it looks like
> the BBB platform are shipped with 2014.04 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?
Having upstream support for the HW components is a critical precondition
for me. CIP has committed to working with the upstream projects as
closely as possible, and maintaining code outside is usually a good
recipe for disaster... Unless there's a really compelling reason
for sticking with a vendor fork, which I cannot think of any in our
context, we should always start from the upstream projects.
Or, in other words: Companies should usually be pushed to bring their
changes upstream, I'm not aware of any case where this has created more
problems than it has solved issues.
>
>
>
> Is there a particular feature set that CIP requires?
that is something we would have to define. I again guess it makes sense
to collect configurations from products of the member companies, as the
in-company variability will already likely be substantial.
Best regards, Wolfgang
>
>
>
> Forgive my random ramblings, I appreciate there are a lot of different
> questions here!
>
>
>
>
>
> [1] https://github.com/u-boot/u-boot/tree/master/board/ti/am335x
>
> [2] https://github.com/u-boot/u-boot/tree/master/board/renesas
>
>
>
> Kind regards, Chris
>
>
>
> _______________________________________________
> cip-dev mailing list
> cip-dev at lists.cip-project.org
> https://lists.cip-project.org/mailman/listinfo/cip-dev
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [cip-dev] u-boot policy for CIP
2017-03-16 12:07 [cip-dev] u-boot policy for CIP Chris Paterson
2017-03-23 18:03 ` Agustin Benito Bethencourt
2017-03-24 16:15 ` Wolfgang Mauerer
@ 2017-03-24 17:53 ` Ben Hutchings
2017-04-12 8:34 ` Chris Paterson
2 siblings, 1 reply; 6+ messages in thread
From: Ben Hutchings @ 2017-03-24 17:53 UTC (permalink / raw)
To: cip-dev
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [cip-dev] u-boot policy for CIP
2017-03-24 17:53 ` Ben Hutchings
@ 2017-04-12 8:34 ` Chris Paterson
2017-04-12 13:56 ` Wolfgang Mauerer
0 siblings, 1 reply; 6+ messages in thread
From: Chris Paterson @ 2017-04-12 8:34 UTC (permalink / raw)
To: cip-dev
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.
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.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [cip-dev] u-boot policy for CIP
2017-04-12 8:34 ` Chris Paterson
@ 2017-04-12 13:56 ` Wolfgang Mauerer
0 siblings, 0 replies; 6+ messages in thread
From: Wolfgang Mauerer @ 2017-04-12 13:56 UTC (permalink / raw)
To: cip-dev
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
>
^ permalink raw reply [flat|nested] 6+ messages in thread