codedude/wiki
1
0
Fork 0
forked from sig_altarch/wiki
Code Pull requests Activity

Merge pull request 'add meeting notes for 2023-10-20' (#11) from meeting/20231020 into main

Browse source 
Reviewed-on: sig_altarch/wiki#11
This commit is contained in:
Bryan Zuelly 2023-10-21 14:48:03 +00:00
commit 9a15bb1050
1 changed files with 150 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

150
docs/events/meeting-notes/2023-10-20.md Normal file
View file

@ -0,0 +1,150 @@
# SIG/AltArch meeting 2023-10-20
## Attendees:
* Sherif
* Bryan
* Pratham Patel
* Pablo Greco
* Alan Marshall
* Brian Clemens
* Neil Hanlon
## Discussions:
### Current Status
Originally, Skip and Pablo built rpi image and kernel. Afterwards, Sherif began working with Pablo to build a generic arm kernel for more than just RPis. GenericArm image is being built with Empanadas, but not widely used. It should support Rpi as well as others.
As a rule, we cannot rely on EPEL dependencies, and will need to pull them into our build roots. We should work on/request tooling to aid in these operations--i.e., something to identify dependencies, and perform imports of them for us.
#### Kernels
Building 5.15 and 6.1 kernels in SIG/AltArch, but will be moving them to SIG/Kernel
Will also include kernel-mainline (6.5/6.6).
#### SBCs
Recently, Bryan and Pratham began working with other SBCs like 3 Libre Computing boards, Orange Pi 5, Rock5b, Odroid purchased by RESF provided to several testers.
##### Libre boards
* are largely generic
* Rocky uboot is problematic (USB issues), but upstream uboot works w/ our kernel
* (Neil has tested this and it works great -- it's running a bunch of IOT stuff for him)
* Pratham - have we tested building from their source? or just using their uboot?
* Bryan - it's been 6-8 months since we've tried it, but it should be re-investigated
* We all recall it being a USB-related issue, but this should be confirmed.
##### Orange Pi 5
* requires 6.5-ish kernel
* nothing upstreamed in uboot yet
##### Rock5b
* requries a 6.6-rc kernel
* uboot 3.10 + some pci patches
##### Odroid
* hasn't been looked into yet
### Discussions
Pablo:
* Need to separate kernel vs uboot. We are near to the end of the year, so we are very close to a new kernel LTS being cut which will probably be based on
* re: uboot -- would like to stay as close to vanilla (Fedora) uboot as possible, but that is obviously difficult for every single board, practically. Ideally, we can build these as RPMs, just like "normal" uboot (this would also make composing images a lot easier, logistically speaking). Another option, if we have to, is to build specific binaries and provide them in a "one-off" repo to users as needed.
Sherif:
* tool like `arm-image-installer` script to download the right uboot, image, etc, and put it into the disk at the right place. basically: make it pretty fool proof
* like spi-tool (?) from Pine64
* Fedora and Debian are doing something like this
* In general, we want to have the least amount of uboots required, whatever the case
* try to port changes into a single generic uboot where possible
* tl;dr - there are *a lot* of boards. can't please everyone
Pratham - questions on Kernels
* was using elrepo kernels to test (mainline, mostly)
* realized RHEL kernels are missing configs for booting these boards
* built kernel.org kernel, and it boots all three libre boards and the rock5b
* How to proceed from here? There are a lot of configs which need setting, e.g..
* Storytime!
* we all use the same kernel.org tarballs -- without changes
* Sherif and Pablo worked on changes to contribute to elrepo, they are very welcoming, in general.
* The configs and specs are going to be--mostly, where the Kernel contributions can be
* we should always be contributing back to elrepo, so that the entire community can benefit from the changes/features we add
* We also begin to limit the amount of backports/changes we need to do over time
* the current rocky LTS kernel is the same now as elrepo, due to the PR we've introduced
* another example - HPC sig kernel
* stripped down kernel for compute nodes, based on the Rocky base kernel with patches
* openpatch :D
* https://elrepo.org/bugs/view.php?id=1345
* We should document this and our policy on upstreaming work to ELRepo for Kernel changes.
* tl;dr - base work on elrepo and make PRs there, then bring them into SIG/Kernel
#### Generic Image
* Pablo - some boards look for grub binaries in a _highly_ specific location, and we need to make sure that we make a copy of those (links) into those locations
* i.e., their uboots aren't looking for grubx64.efi in the right place
* Neil - We can announce the availability of this more generally in our 9.3 / 8.9 releases coming in November.
### alternative alternative architctures
#### 32 bit arm (armhfp/arm7vl)
* We are looking for hardware which we can use to do these builds. We have some VMs currently, but they are not quite powerful enough.
* OSU OSL should have some Lenovo eMags for us, at some point.
* Neil to reach out to Ramareth
* Neil to reach out to Aaron from Ampere
* If we can't get anything from OSU, let's ping SolidRun or Ampere to see if they can do anything for us and figure it ourselves.
#### riscv
* right now, it takes 2+ days to build gcc in qemu
* there have been a lot of good changes in qemu to add more support but we should try and do native builds if possible.
* Neil - Investigate what and how much riscv hardware we need.. and where we'll host it
* https://www.crowdsupply.com/milk-v/milk-v-pioneer
## Decisions
* 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.
!!! note "uboot and other licensing"
We need to ensure that we are careful about the licensing of softwares we wish to include in the SIG distribution.
## Action items:
* Libre Compute - Try/Investigate using vendor tree to build uboot - Pratham
* Investigate `arm-image-installer` script/tool for helping write disk images for specific boards - Sherif (?)
* Odroid N2 - Track installability
* Investigate backport of uboot configuration to work with our uboot and/or track upstreaming process
* Orange Pi 5 - Track installability
* Investigate backport of uboot configuration to work with our uboot and/or track upstreaming process
* Rock5b - Track installability
* Investigate backport of uboot configuration to work with our uboot and/or track upstreaming process
* Libre Computing Boards (3)
* Investigate backport of uboot configuration to work with our uboot and/or track upstreaming process
* Maintenance - Importing dependencies from Fedora/EPEL
* Investigate tooling for this
* Document process on backporting uboot and kernels - Pablo
* To include information on how we work and interact with upstreams, with examples! - Sherif
* Check and investigate which boards have hardcoded grubx64 paths in their uboot; address them
* Acquire armhfp (arm7vl) hardware - Neil to reach out to OSU OSL
* Neil - Investigate what and how much riscv hardware we need.. and where we'll host it
### Next Meeting
* Discuss meeting time - biweekly?
## Old business:
* N/A