Hi Thomas,
On Sat, Nov 7, 2015 at 8:15 PM, Ricardo Salveti ricardo.salveti@linaro.org wrote:
On Sat, Nov 7, 2015 at 7:14 AM, Thomas B. Rücker thomas@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.
Regards, Amit
[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? ;-)