Interesting things are happening, but many people on this list might not be subscribed to linaro-announce, so here's a full quote:
On Sat, 7 Nov 2015 03:53:43 -0300, wrote:
It took a bit longer than originally planned, but we're finally able to announce the first Reference Software Platform release (alpha).
The Reference Software Platform Lead Project is part of the Linaro 96Boards initiative. The goal of the project is to deliver Linaro output for ARM SoCs using 96Boards products for use cases ranging from the Embedded to the Enterprise segments. This release includes bootloader, kernel, distributions (Debian) and AOSP. It comprise loadable software for the current 96Boards products (HiKey and Dragonboard410c), reference source code, and documentation on installing the images and building the source code.
In case you are unfamiliar with the project, we had a great session that was presented during Linaro Connect SFO15, and it can be found at http://connect.linaro.org/resource/sfo15/sfo15-104-the-96boards-software-ref...
Goals we had for this release:
- Bootstrap the CI jobs required to build and publish the components
and images (more details at https://github.com/96boards/documentation/wiki/Reference-Software-CI)
- Single Debian root file system that could be consumed by both HiKey
and Dragonboard410c
- Recent kernel, even if not yet fully functional, since the goal is
to reduce maintenance and support overhead and accelerate ongoing development by focusing on upstream feature support
- AOSP based on latest Android Release (6.0 Marshmallow), initially just HiKey
A lot was accomplished during last month, and we're happy to announce that we're using a 4.3 based kernel for both HiKey and Dragonboard410c (Debian). The builds are still not sharing the same branch (due conflicts at the adv7511 driver), but we hope to be able to get this fixed over the next few weeks (and published as part of our next release).
While the release supports many of the available hardware features for both Hikey and Dragonboard410c, it is in ALPHA state, so bugs are expected. For a better user experience, please use the previous releases available at https://builds.96boards.org/releases/dragonboard410c/ and https://builds.96boards.org/releases/hikey/.
Highlights for this release:
CE Debian RPBs:
- Debian 8.2 "Jessie"
- 4.3 kernel (with additional patches)
- OpenJDK 8 included by default
- 96Boards artworks and default settings
CE AOSP RPB:
- AOSP Android Marshmallow 6.0
- 3.18 based kernel
Install instructions, known issues, test reports and instructions to build from source are all published at https://github.com/96boards/documentation/wiki/ReferenceSoftware. We should also see more progress into a more complete set of documentation during the course of the next release.
For general questions or support requests, please go to the 96boards.org Community forum - https://www.96boards.org/forums/. Please submit bugs to the 96Boards.org bugzilla (https://bugs.96boards.org/). For IRC support, please go to the #96boards channel @Freeode.
What about this mailing list?
Make sure to check https://github.com/96boards/documentation/wiki/ReferenceSoftware for more information about this project and the release.
Challenges for the next release (15.12 - official date to be announced):
- Have both boards using a single kernel tree/branch and a single kernel binary
- Better understanding about the upstream gaps
- Adding support for CE AOSP for Dragonboard410c (with freedreno)
- Adding support for CE OE/Yocto
- Enterprise Edition
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)
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 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.
On Sat, Nov 7, 2015 at 7:14 AM, Thomas B. Rücker thomas@ruecker.fi wrote:
Interesting things are happening, but many people on this list might not be subscribed to linaro-announce, so here's a full quote:
By bad, wasn't sure if this list was a good target for announcements. Will include it next time, thanks for forwarding the email.
On Sat, 7 Nov 2015 03:53:43 -0300, wrote:
It took a bit longer than originally planned, but we're finally able to announce the first Reference Software Platform release (alpha).
The Reference Software Platform Lead Project is part of the Linaro 96Boards initiative. The goal of the project is to deliver Linaro output for ARM SoCs using 96Boards products for use cases ranging from the Embedded to the Enterprise segments. This release includes bootloader, kernel, distributions (Debian) and AOSP. It comprise loadable software for the current 96Boards products (HiKey and Dragonboard410c), reference source code, and documentation on installing the images and building the source code.
In case you are unfamiliar with the project, we had a great session that was presented during Linaro Connect SFO15, and it can be found at http://connect.linaro.org/resource/sfo15/sfo15-104-the-96boards-software-ref...
Goals we had for this release:
- Bootstrap the CI jobs required to build and publish the components
and images (more details at https://github.com/96boards/documentation/wiki/Reference-Software-CI)
- Single Debian root file system that could be consumed by both HiKey
and Dragonboard410c
- Recent kernel, even if not yet fully functional, since the goal is
to reduce maintenance and support overhead and accelerate ongoing development by focusing on upstream feature support
- AOSP based on latest Android Release (6.0 Marshmallow), initially just HiKey
A lot was accomplished during last month, and we're happy to announce that we're using a 4.3 based kernel for both HiKey and Dragonboard410c (Debian). The builds are still not sharing the same branch (due conflicts at the adv7511 driver), but we hope to be able to get this fixed over the next few weeks (and published as part of our next release).
While the release supports many of the available hardware features for both Hikey and Dragonboard410c, it is in ALPHA state, so bugs are expected. For a better user experience, please use the previous releases available at https://builds.96boards.org/releases/dragonboard410c/ and https://builds.96boards.org/releases/hikey/.
Highlights for this release:
CE Debian RPBs:
- Debian 8.2 "Jessie"
- 4.3 kernel (with additional patches)
- OpenJDK 8 included by default
- 96Boards artworks and default settings
CE AOSP RPB:
- AOSP Android Marshmallow 6.0
- 3.18 based kernel
Install instructions, known issues, test reports and instructions to build from source are all published at https://github.com/96boards/documentation/wiki/ReferenceSoftware. We should also see more progress into a more complete set of documentation during the course of the next release.
For general questions or support requests, please go to the 96boards.org Community forum - https://www.96boards.org/forums/. Please submit bugs to the 96Boards.org bugzilla (https://bugs.96boards.org/). For IRC support, please go to the #96boards channel @Freeode.
What about this mailing list?
Definitely, thanks for pointing it out, will change the wiki page to include this list as well.
Make sure to check https://github.com/96boards/documentation/wiki/ReferenceSoftware for more information about this project and the release.
Challenges for the next release (15.12 - official date to be announced):
- Have both boards using a single kernel tree/branch and a single kernel binary
- Better understanding about the upstream gaps
- Adding support for CE AOSP for Dragonboard410c (with freedreno)
- Adding support for CE OE/Yocto
- Enterprise Edition
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).
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 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.
Thanks,
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? ;-)
Hi Amit,
Sorry, was a bit busy with other things.
On 11/09/2015 07:51 AM, Amit Kucheria wrote:
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.
So you don't even collect the mandated self-compliance reports from vendors? In that case I have a 96borads compliant bridge for sale and to go on the website.
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.
That's great to hear!
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?
If you want to establish a credible project and for 96boards to have actually any meaning beyond being a Linaro member PR outlet, definitely you should not.
Or should we instead publish the compliance report for each board and let the community decide if the board fits their needs?
That may be suitable as a band aid to limit the damage that was done. You should certainly clarify in which way the published boards (CE: HiKey, Dragonboard 410c; EE: none) are violating the published specifications. As said above you shouldn't publish more non-compliant boards. This would maybe help reestablish some trust within the community (may depend on your definition of community).
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 for one will unsubscribe from the mailing list and drop the IRC channel if Linaro chooses for 96boards to be such a toothless venture. There is no value if the spec doesn't need to be followed and EVERYTHING IS OPTIONAL.
On a snarky see-the-positive-in-this note: At least it would enable CE boards with proper Ethernet also on the small form factor, as height and size restrictions are then also optional.
I honestly believe that the developer community would be interested to see several board options available that boot with a modern stack[1],
Yes, as long as the SoC supports things with its locked down boot loader and total lack of documentation for gpu, peripherals, registers, etc. Everything is optional!
more of the code being merged upstream in every merge window, more consolidation happening at each release[2]
Sure, but what does this specifically have to do with board hardware? Hardware runs software, yes... But it can have any size or shape.
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].
Well if such will exist, ever. Remember, everything is now optional and IPR protection and corporate interests rule without bounds.
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.
Depending on your definition of community this might end up having none beyond some people looking for cheap EVMs, although I don't think I can buy any of the SoCs used on 96boards so far in Qty==1.
We'll also need some time to get the compliance process in place while putting out new releases with fresh software.
Can't resist to state the obvious: That should have been in place before the first board was ever announced.
[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? ;-)
Cheers,
Thomas
-
Amit Kucheria -
Ricardo Salveti -
Thomas B. Rücker