[Dev] Reference Software Platform 15.10 Alpha Release!

Amit Kucheria amit.kucheria at linaro.org
Mon Nov 9 07:51:49 UTC 2015

Hi Thomas,

On Sat, Nov 7, 2015 at 8:15 PM, Ricardo Salveti
<ricardo.salveti at linaro.org> wrote:
> On Sat, Nov 7, 2015 at 7:14 AM, Thomas B. Rücker <thomas at ruecker.fi> wrote:

>> Here's a major challenge Linaro doesn't bother to acknowledge beyond
>> awkward IRC comments:
>> - Address the non-compliance of your 96boards
>> - Publish a compliant open source boot loader for db410c that loads
>> after ROM code, as required by spec. (see previous mails)
> Definitely, we did have quite a few discussions round this topic, but
> will let Amit add more to it (since I personally didn't have much time
> to cover this topic).

Awkward indeed. There is currently no *process* to check for
compliance, there is only the compliance web page that I view as a
charter on what 96boards would like to be.

I'm working on such a process checklist. That should allow us to have
discussions about compliance with each board vendor and allow the
community to pick the most suitable board based on their needs.

>>> We hope you enjoy the release!
>> I'm certainly going to try it out, it looks promising.
>>> On behalf of the Linaro 96Boards team,
>>> Ricardo Salveti
>> Cheers,
>> Thomas
>> PS: Please resist the obvious management approach "Let's adjust the spec
>> to match what we have". It would essentially completely discredit your
>> efforts and send the signal that Linaro does not care about those goals,
>> but instead completely bends to member commercial interests and those

The reality, I suspect, is a bit more boring in most cases: the
vendor's engineering teams have moved on to newer SoCs, open sourcing
was never planned for the legacy, low-level boot code and nobody is
available to write a clean open source implementation.

Should we not allow the release of any boards that aren't 100%
spec-compliant? Or should we instead publish the compliance report for
each board and let the community decide if the board fits their needs?
I hope the second approach will find favour with the community so we
can continue pushing vendors for better spec-compliance and highlight
loss of potential business due to non-compliance.

I honestly believe that the developer community would be interested to
see several board options available that boot with a modern stack[1],
more of the code being merged upstream in every merge window, more
consolidation happening at each release[2] and an easier
out-of-the-box developer experience. Then if you really wanted a fully
open graphics stack, you'd pick one board but if your main interest
was hacking on the boot firmware, you'd pick another one[3].

>> boards are worthless for most use cases.
>> Acknowledge you fsckd up big time, publish a post mortem, consolidate
>> your compliance documentation to be less confusing, make sure all future
>> boards are compliant.
> I don't think changing the spec to match what we have was something
> that was discussed, since we want the boards to be compliant with what
> we already have. Having open source firmware is a big win.

Agreed. We need to convince the board vendors of the commercial
benefits of complying with the specification and then let the
community vote with their wallets. We'll also need some time to get
the compliance process in place while putting out new releases with
fresh software.

Looking forward to your comments.


[1] Mainline or close to mainline versions of kernel, bootloader,
plumbing, Xorg, AOSP that are constantly tracked by Linaro engineers
[2] Consistent bootloader interface, single kernel image, single Xorg
version across GPU drivers, consistent programming model for the
expansion interfaces, ...
[3] And if you want to hack on the entire software stack, perhaps you
might find something of interest on the Linaro careers page? ;-)

More information about the Dev mailing list