Document decisions on wiki #14

New Issue

neil · 2024-01-16T14:30:52Z

neil commented

2024-01-16 14:30:52 +00:00

In our first meeting, we decided on the following:

* Images should be generic so as to be able to be installed on any board, where possible.
    * uboot can live on SPI or external flash
    * We need to help document this for our users and have guides on how to get the SBCs working. This is a big pain point for many SBC users as there is so much variation.
        * To this end, we should investigate some tooling to aid in writing images for boards which will boot on the first try.
* Uboot should similarly be generic and work for all boards, insofar as it is practical to do so.
    * Some boards this doesn't make sense for, e.g., ones that have uboot from 2014 + hundreds of patches, however, these are few and far between. For these, we can package them as RPMs and provide them (see note below re: licensing)
* We will wait for the next Kernel.org LTS to be cut, as that should have all the changes for the boards we're talking about.
* We will engage with our upstreams (Fedora, ELRepo, etc) for changes we make with the Kernel SIG for AltArch/SBC support.
    * This necessitates participating in SIG/Kernel to represent our needs in these kernels.
* We should strive to perform native builds when possible, but recognize that emulation is a necessary evil.

We need to put this on the wiki.

In our first meeting, we decided on the following: ``` * Images should be generic so as to be able to be installed on any board, where possible. * uboot can live on SPI or external flash * We need to help document this for our users and have guides on how to get the SBCs working. This is a big pain point for many SBC users as there is so much variation. * To this end, we should investigate some tooling to aid in writing images for boards which will boot on the first try. * Uboot should similarly be generic and work for all boards, insofar as it is practical to do so. * Some boards this doesn't make sense for, e.g., ones that have uboot from 2014 + hundreds of patches, however, these are few and far between. For these, we can package them as RPMs and provide them (see note below re: licensing) * We will wait for the next Kernel.org LTS to be cut, as that should have all the changes for the boards we're talking about. * We will engage with our upstreams (Fedora, ELRepo, etc) for changes we make with the Kernel SIG for AltArch/SBC support. * This necessitates participating in SIG/Kernel to represent our needs in these kernels. * We should strive to perform native builds when possible, but recognize that emulation is a necessary evil. ``` We need to put this on the wiki.

Sign in to join this conversation.