sig_altarch/wiki
9
0
Fork 4
generated from sig_core/wiki-template
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
6cd709f053
wiki/docs/events/meeting-notes/2024-01-12.md
Neil Hanlon 47cf07609a
All checks were successful
mkdocs build / build (push) Successful in 48s
Details
add minutes for 2024-01-12
2024-01-12 11:34:01 -05:00

4.5 KiB
Raw Blame History

SIG/AltArch meeting 2024-01-12

Attendees:

* Sherif
* Bryan
* Neil Hanlon
* Skip Grube
* Jason Rodriguez
* Jonathan Maple

Follow Ups

  • SBC Testing with vendor uboot - https://git.resf.org/codedude/SBC-Testing
    • Basically everything is working except one of the Libre boards (Frite)
    • https://git.resf.org/codedude/SBC-Testing/src/branch/main/testing/details.md
    • Whack-a-mole with kernel options and support for different kernels
      • Might be possible to patch for RK3389, as enabling this board breaks Libre borads
      • Also is possible to disable USB2 for RK3389, but this is not preferable
    • Kernel Config - RHEL vs Kernel KConfigs
      • SIG/Kernel kernel is based on the Fedora Rawhide branch of kernel, but uses the KConfig named '.redhat'
      • We want to use this as a base, and change config options as needed to enable SBCs
  • January 2024 UBoot is out with fixes, should help with some of the reliance on Vendor UBoots
    • Bryan will work on testing new uboot with these boards for next meeting
  • OSU OSL has arm hardware available for us, this will help enable armhfp/arm7vl/32-bit arm
    • Hoping to have this ready to build things in the beginning of February
  • RISCV hardware
    • Should look at getting a few more SiFive VF2

Open Floor

  • Raspberry Pi 5 Support
    • check upstream for firmware, throw into our repo, rebuild image and test

Action Items

  • Build Jan 2024 UBoot - Sherif
  • Raspberry Pi 5 Support - Skip
  • Order RPI 5 hardware for testers/altarch - Neil
    • Maybe buy this locally in London instead for Pablo -- nevermind they're not in London...
      • Pimironi or pihut - ship to Sherif
  • Neil to actually make tickets for the follow ups / decisions. But, like, for real this time
    • I'm really going to do it this week, I promise.
  • Setup ARM hardware for armhfp - neil
  • Neil to figure out what RISCv hardware we need

Old business

2023-12-15

  • Neil to actually make tickets for the follow ups / decisions. But, like, for real this time.
  • Neil to reach out to people re: ARMHFP hardwares
    • Ampere
    • OSUOSL
    • Fabian (arrfab)
  • Neil to figure out what RISCv hardware we need
  • Announce Dec 29th meeting cancelation

2023-10-20

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
  • Orange Pi 5 - Track installability
  • Rock5b - Track installability
  • Libre Computing Boards (3)
  • Maintenance - Importing dependencies from Fedora/EPEL
  • 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

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.