1
0
forked from sig_altarch/wiki

Compare commits

..

31 Commits
main ... main

Author SHA1 Message Date
08293ba4a8
disabled auto-expand,added selinux note to readme,removed links section
All checks were successful
mkdocs build / build (push) Successful in 1m21s
2024-10-27 09:16:45 -04:00
83f53e6f4e
first meeting decisions from meta issue #14
All checks were successful
mkdocs build / build (push) Successful in 1m22s
2024-10-16 20:30:56 -04:00
965f853868
added Skip to members
All checks were successful
mkdocs build / build (push) Successful in 1m22s
2024-10-13 21:49:20 -04:00
923c152ee2
removed layout, added members
All checks were successful
mkdocs build / build (push) Successful in 1m24s
2024-10-13 21:00:02 -04:00
fda563d224
Added .pages file to directory for custom sorting(sorting events to the bottom)
All checks were successful
mkdocs build / build (push) Successful in 1m24s
Corrected a few syntax errors.
2024-10-03 21:22:06 -04:00
2c1771fff3
directory structure cleanup
All checks were successful
mkdocs build / build (push) Successful in 1m17s
2024-10-03 20:33:54 -04:00
e80ac9785b
added cairo to Dockerfile to fix preview issue
All checks were successful
mkdocs build / build (push) Successful in 1m22s
2024-10-02 23:04:59 -04:00
0f69c874bf
updated amlogicboards.md 2024-10-02 07:13:25 -04:00
a1b2d004aa
reorg 2024-10-02 07:11:23 -04:00
281e46c3cc
first pass reorg 2024-08-25 14:38:51 -04:00
7b6be30ae3
switch to use Fastly for deploying
All checks were successful
mkdocs build / build (push) Successful in 1m19s
2024-08-24 22:48:52 -04:00
4d462f3d75
add 2024-08-23 meeting notes
All checks were successful
mkdocs build / build (push) Successful in 29s
2024-08-24 22:27:58 -04:00
4ccb86dee7
add (old) meeting notes from November I just found 2024-08-24 22:26:16 -04:00
8245a60c4c Merge pull request 'Pi Zero 2W solutions' (#17) from codedude/wiki:main into main
All checks were successful
mkdocs build / build (push) Successful in 33s
Reviewed-on: sig_altarch/wiki#17
2024-08-09 02:49:51 +00:00
43efb83aff
Pi Zero 2W solutions 2024-08-08 22:46:51 -04:00
d04cdafbbf Merge pull request 'add meeting minutes for 2024-02-09, 2024-02-23' (#15) from meeting/2024-02-23 into main
All checks were successful
mkdocs build / build (push) Successful in 27s
Reviewed-on: sig_altarch/wiki#15
2024-02-23 17:34:30 +00:00
6cd709f053
add meeting minutes for 2024-02-09, 2024-02-23 2024-02-23 12:33:37 -05:00
7214d1b2b4 Merge pull request 'sbc kernel url correction' (#14) from codedude/wiki:main into main
All checks were successful
mkdocs build / build (push) Successful in 1m2s
Reviewed-on: sig_altarch/wiki#14
2024-01-27 02:24:53 +00:00
6990758bd0 sbc kernel url correction 2024-01-26 21:21:03 -05:00
7c32cb70fd Merge pull request 'Add notes for 2024-01-26' (#13) from meeting/2024-01-26 into main
All checks were successful
mkdocs build / build (push) Successful in 42s
Reviewed-on: sig_altarch/wiki#13
2024-01-26 17:21:10 +00:00
3099c07c07
Add notes for 2024-01-26 2024-01-26 12:09:30 -05:00
47cf07609a
add minutes for 2024-01-12
All checks were successful
mkdocs build / build (push) Successful in 48s
2024-01-12 11:34:01 -05:00
284a726db5 Merge pull request 'meeting 2023-12-15' (#12) from meeting/2023-12-15 into main
All checks were successful
mkdocs build / build (push) Successful in 29s
Reviewed-on: sig_altarch/wiki#12
2023-12-15 17:05:25 +00:00
b7c5becc96
meeting 2023-12-15 2023-12-15 12:04:06 -05:00
340a10da55 Merge pull request 'Added contribution instructions' (#8) from skip/sig_altarch_wiki:main into main
All checks were successful
mkdocs build / build (push) Successful in 26s
Reviewed-on: sig_altarch/wiki#8
2023-11-17 02:43:02 +00:00
9a15bb1050 Merge pull request 'add meeting notes for 2023-10-20' (#11) from meeting/20231020 into main
All checks were successful
mkdocs build / build (push) Successful in 27s
Reviewed-on: sig_altarch/wiki#11
2023-10-21 14:48:03 +00:00
c38dbd0ae1 add meeting notes for 2023-10-20 2023-10-20 17:07:34 +00:00
7346d20c06 Merge pull request 'Add solution for dnf needs-restarting -f issue to wiki' (#10) from funzi/wiki:main into main
All checks were successful
mkdocs build / build (push) Successful in 44s
Reviewed-on: sig_altarch/wiki#10
2023-08-01 21:45:45 +00:00
ad9bb7ce11
Add solution for dnf needs-restarting -f issue 2023-08-01 21:10:15 +02:00
0949836220 Merge pull request 'vf2: add a notice about updating board firmware' (#9) from thefossguy/wiki:main into main
All checks were successful
mkdocs build / build (push) Successful in 29s
Reviewed-on: sig_altarch/wiki#9
2023-04-29 08:34:09 +00:00
e5ede0fce9 vf2: add a notice about updating board firmware 2023-04-29 14:02:49 +05:30
36 changed files with 3115 additions and 99 deletions

View File

@ -11,31 +11,31 @@ jobs:
image: docker.io/rockylinux:9
steps:
- name: Install deps
run: dnf -y install git python3 python3-pip
- name: setup ssh
env:
SSH_KEY: "${{ secrets.SSH_KEY }}"
run: |
mkdir -p ~/.ssh/
echo "$SSH_KEY" > ~/.ssh/id_rsa
chmod 0700 ~/.ssh/
chmod 0600 ~/.ssh/id_rsa
dnf -y upgrade
dnf -y install git python3 python3-pip cairo-devel
- name: checkout
env:
GIT_SSH_COMMAND: "ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no"
run:
git clone https://git.resf.org/$GITHUB_REPOSITORY.git $GITHUB_WORKSPACE
- name: Install python requirements
run: python3 -m pip install -r requirements.txt
- name: Build
run: |
python3 -m mkdocs build
- name: Install fastly CLI
run: |
dnf -y install \
npm \
https://github.com/fastly/cli/releases/download/v10.13.3/fastly_10.13.3_linux_amd64.rpm
- name: Deploy
env:
GIT_SSH_COMMAND: "ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no"
GIT_AUTHOR_NAME: "Rocky Bot"
GIT_AUTHOR_EMAIL: "auto@rockylinux.org"
FASTLY_API_TOKEN: "${{ secrets.FASTLY_API_TOKEN }}"
run: |
git remote set-url origin ssh://git@git.resf.org:22220/$GITHUB_REPOSITORY.git
python3 -m mkdocs gh-deploy --force
pushd compute-js
npm install
fastly compute publish

2
.gitignore vendored Normal file
View File

@ -0,0 +1,2 @@
/site
.cache

View File

@ -1,7 +1,7 @@
FROM rockylinux:9
RUN dnf update -y &&\
dnf install -y git python3-pip &&\
dnf install -y git python3-pip cairo &&\
dnf clean all
# bind volume $CWD > /wiki exists in docker-compose.yml

View File

@ -13,16 +13,16 @@ This Wiki is browseable at **https://sig-altarch.rocky.page** .
Feel free to contribute to this Wiki via pull request.
You can test any changes locally by running it with Docker/Podman compose on your PC. Clone this wiki, `cd` into the folder, and run:
You can test any changes locally by running it with Docker/Podman compose on your PC. Clone this wiki, `cd` into the folder, set SeLinux to permissive temporarily and run:
```
setenforce 0
docker-compose up
```
It should build and run the wiki container. You can browse it and see your live edits by visiting `localhost:8000` .
## Continuous Integration / Continuous Deployment
Actions Runner executes workflow to publish to https://sig-altarch.rocky.page on push to main.

4
compute-js/.gitignore vendored Normal file
View File

@ -0,0 +1,4 @@
/node_modules
/bin
/pkg
/static-publisher

2
compute-js/.publish-id Normal file
View File

@ -0,0 +1,2 @@
# Generated by @fastly/compute-js-static-publish.
2U3RUindKvK1F6Sb7AEHXZ

12
compute-js/fastly.toml Normal file
View File

@ -0,0 +1,12 @@
# This file describes a Fastly Compute package. To learn more visit:
# https://www.fastly.com/documentation/reference/compute/fastly-toml
authors = ["sig-altarch@rocky.page"]
description = "SIG/AltArch Wiki"
language = "javascript"
manifest_version = 2
name = "sig-altarch.rocky.page"
service_id = "vvJfk2GYOVZGX7FPrEHEa5"
[scripts]
build = "npm run build"

2051
compute-js/package-lock.json generated Normal file

File diff suppressed because it is too large Load Diff

23
compute-js/package.json Normal file
View File

@ -0,0 +1,23 @@
{
"name": "sig-altarch.rocky.page",
"version": "0.1.0",
"description": "SIG/Altarch Wiki",
"author": "sig-altarch@rocky.page",
"type": "module",
"devDependencies": {
"@fastly/compute-js-static-publish": "^6.0.3"
},
"dependencies": {
"@fastly/js-compute": "^3.20.0"
},
"engines": {
"node": ">=18.0.0"
},
"license": "UNLICENSED",
"private": true,
"scripts": {
"deploy": "fastly compute deploy",
"prebuild": "npx @fastly/compute-js-static-publish --build-static",
"build": "js-compute-runtime ./src/index.js ./bin/main.wasm"
}
}

18
compute-js/src/index.js Normal file
View File

@ -0,0 +1,18 @@
/// <reference types="@fastly/js-compute" />
import { getServer } from '../static-publisher/statics.js';
const staticContentServer = getServer();
// eslint-disable-next-line no-restricted-globals
addEventListener("fetch", (event) => event.respondWith(handleRequest(event)));
async function handleRequest(event) {
const response = await staticContentServer.serveRequest(event.request);
if (response != null) {
return response;
}
// Do custom things here!
// Handle API requests, serve non-static responses, etc.
return new Response('Not found', { status: 404 });
}

View File

@ -0,0 +1,34 @@
/*
* Copyright Fastly, Inc.
* Licensed under the MIT license. See LICENSE file for details.
*/
// Commented items are defaults, feel free to modify and experiment!
// See README for a detailed explanation of the configuration options.
/** @type {import('@fastly/compute-js-static-publish').StaticPublisherConfig} */
const config = {
rootDir: "../site",
staticContentRootDir: "./static-publisher",
// kvStoreName: false,
// excludeDirs: [ './node_modules' ],
// excludeDotFiles: true,
// includeWellKnown: true,
// contentAssetInclusionTest: (filename) => true,
// contentCompression: [ 'br', 'gzip' ], // For this config value, default is [] if kvStoreName is null.
// moduleAssetInclusionTest: (filename) => false,
// contentTypes: [
// { test: /.custom$/, contentType: 'application/x-custom', text: false },
// ],
server: {
publicDirPrefix: "",
staticItems: ["/assets/"],
// compression: [ 'br', 'gzip' ],
spaFile: false,
notFoundPageFile: "/404.html",
autoExt: [],
autoIndex: ["index.html","index.htm"],
},
};
export default config;

View File

@ -5,6 +5,7 @@ services:
- type: bind
source: .
target: /wiki
build:
context: .
ports:

3
docs/.pages Normal file
View File

@ -0,0 +1,3 @@
nav:
- single_board_computers
- events

33
docs/assets/extra.css Normal file
View File

@ -0,0 +1,33 @@
:root {
@media screen and (max-width: 76.234375em) {
.md-nav__title[for="__drawer"] {
background: linear-gradient(135deg, #10b981 0%, #1055b9 100%);
}
}
}
[data-md-color-scheme="resf"] {
--md-accent-fg-color: #0e7391;
--md-primary-fg-color--dark: #107fa1;
--md-primary-fg-color--light: #FFFFFF;
--md-primary-fg-color: #107fa1;
--md-typeset-a-color: #107fa1;
}
[data-md-color-scheme="resf-dark"] {
color-scheme: dark;
--md-default-fg-color: #FFFFFF;
--md-default-bg-color: rgb(30, 33, 41);
--md-primary-fg-color: #107fa1;
--md-primary-bg-color: #FFFFFF;
--md-primary-fg-color--dark: #107fa1;
--md-accent-fg-color: #0e7391;
--md-default-fg-color--light: rgba(226, 228, 233, 0.56);
--md-typeset-table-color: rgba(240, 241, 244, 0.12);
--md-typeset-color: rgba(226, 228, 233, 0.82);
--md-typeset-a-color: #107fa1;
}

View File

@ -0,0 +1,3 @@
<svg width="4096" height="4096" viewBox="0 0 192 192" fill="none" xmlns="http://www.w3.org/2000/svg">
<path fill-rule="evenodd" clip-rule="evenodd" d="M186.658 127.658C190.119 117.746 192 107.093 192 96C192 42.9807 149.019 0 96 0C42.9807 0 0 42.9807 0 96C0 122.234 10.523 146.011 27.5783 163.338L124.958 65.9584L149 90L186.658 127.658ZM169.122 158.205L124.958 114.042L55.7978 183.202C68.0268 188.849 81.6455 192 96 192C125.288 192 151.514 178.884 169.122 158.205Z" fill="white"/>
</svg>

After

Width:  |  Height:  |  Size: 487 B

Binary file not shown.

After

Width:  |  Height:  |  Size: 381 KiB

BIN
docs/assets/resf-icon.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.3 MiB

View File

@ -0,0 +1,63 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg
width="44.450001mm"
height="44.450001mm"
viewBox="0 0 44.450001 44.450001"
version="1.1"
id="svg1"
inkscape:version="1.3.2 (091e20ef0f, 2023-11-25)"
sodipodi:docname="resf-white.svg"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns="http://www.w3.org/2000/svg"
xmlns:svg="http://www.w3.org/2000/svg">
<sodipodi:namedview
id="namedview1"
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1.0"
inkscape:showpageshadow="2"
inkscape:pageopacity="0.0"
inkscape:pagecheckerboard="0"
inkscape:deskcolor="#d1d1d1"
inkscape:document-units="mm"
inkscape:zoom="1.624662"
inkscape:cx="105.86818"
inkscape:cy="665.36917"
inkscape:window-width="1440"
inkscape:window-height="3356"
inkscape:window-x="0"
inkscape:window-y="52"
inkscape:window-maximized="1"
inkscape:current-layer="layer1" />
<defs
id="defs1" />
<g
inkscape:label="Layer 1"
inkscape:groupmode="layer"
id="layer1"
transform="translate(-2.5796834,-3.8748417)">
<path
d="M 2.5796834,3.8748417 H 47.029686 V 31.39389 l -6.87626,-6.876256 -5.13556,5.135562 -10.27113,-10.271125 -5.13556,5.135298 -10.2710976,-10.271045 -6.760395,6.760289 z"
fill="#ffffff"
id="path3"
style="stroke-width:0.264583" />
<path
d="m 40.153426,32.220977 -16.10386,16.103865 h 22.98012 v -9.227609 z"
fill="#ffffff"
id="path4"
style="stroke-width:0.264583" />
<path
d="M 24.746736,27.085415 31.166056,33.505 16.346271,48.324842 H 3.5072594 Z"
fill="#ffffff"
id="path5"
style="stroke-width:0.264583" />
<path
d="m 9.3400784,21.949588 -6.760395,6.760633 V 41.549127 L 15.759558,28.369173 Z"
fill="#ffffff"
id="path6"
style="stroke-width:0.264583" />
</g>
</svg>

After

Width:  |  Height:  |  Size: 2.0 KiB

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

View File

@ -0,0 +1,59 @@
# SIG/AltArch meeting 2023-11-03
## Attendees
* Sherif
* Bryan
* Neil Hanlon
## Old Business
* Discuss meeting time - ~~biweekly~~ monthly.
* https://www.when2meet.com/?22213293-gYJPM
* Send out to channel asking for people to put in their availability for the first week of December
* Going forward we will repeat the meeting monhtly on the first whatever day of the month we choose
* Document decisions from last time
* https://sig-altarch.rocky.page/events/meeting-notes/2023-10-20/#decisions
* Neil to make ticket to encompass updating the SIG documentation (purpose, how to join and participate, our decisions, etc)
* Create tickets for work on boards
* Neil will create tickets in sig_altarch/meta for all of [these](https://sig-altarch.rocky.page/events/meeting-notes/2023-10-20/#action-items)
* Configure upstream monitoring for releases of new packages (uboot) - Neil
* this is the "Maintenance - Importing dependencies from Fedora/EPEL" bit
* https://release-monitoring.org/
* https://pagure.io/centos-sig-hyperscale/package-updates/blob/main/f/package_updates
## New Business
* Fix missing packages for uboot in rocky 8 (Sherif)
* two packages need to be rebuilt
* can these be PRed to Fedora or UBoot?
* Bryan will look into opening a PR with Fedoras
* Neil can help with the 'how'
* https://src.fedoraproject.org/rpms/uboot-tools1
* Login w/ Fedora account, can create a fork and then open a PR against the main repo
* https://git.rockylinux.org/sig/altarch/src/uboot-tools/-/commit/0d07de7701b023c642a4d776852e05cb6bd3318e
* GenericArm image
* Would like to release "officially" w/ 9.3 and 8.9 building using empanadas
## Open Floor / Discussions
* Bryan working on the Libre Tritium H5 (ALL-H3-CC (H5))
* Progressing well, will need to open an issue to add config to elrepo kernel
* Rockchip status -
* Sherif was working to add new Rockchip boards, but needs to rebase his PR against latest mainline
* Will need help testing as he only has the RockPro64
* Probably first week of december
* Some libre boards are also rockchip (Renegade)
* Long term, we can have a single unified kernel (yay!)
* Kernel LTS
* Pablo and Sherif working on this.
* Kernel ML
* Need to work with Mustafa on this (Neil)
* some things have regressed in Kernel Packer
* Update configuration in ELRepo for rockchips
* Sherif to rebase later
## Next Meeting
* Should we make the Mainline kernel the default kernel for the SIG/Altarch GenericArm image? ** need to resolve before new 8 and 9 releases **
* Probably yes, but we'll circulate this. Neil will create a ticket.

View File

@ -0,0 +1,103 @@
# SIG/AltArch meeting 2023-12-15
## Attendees:
* Sherif
* Bryan
* Pablo Greco
* Neil Hanlon
* Skip Grube
## Follow Ups
* 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
* Neil is working on this as part of SIG/HPC, too
* 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
## Discussions
* Neil provided Sherif with 2 RPi CM4s (+ IO boards), an RPi5, and a SiFive VF2 (RiscV) at SC23 in November
* Need to work on integrating SBC and related changes into SIG/Kernel mainline in order to have unified kernel
* Bryan has tried mainline kernel, but it isn't booting -- ends up in dracut shell.
* Will figure out how to capture logs via serial
* Libre Tritium H5
* It's all Skip's fault
* 32-bit arm (armhfp/arm7vl) Rocky Port
* Sherif has some odroid boards from work he can donate
* Odroid XU4 x2
* Odroid XU4Q x1 - XU4 w/ massive heatsink
* Current status (per Pablo)
* have the full bootstrap up to 9.1; we need to start building atop it
* need to add Peridot support for armhfp (i can't remember if we included the arch as an option)
* where will we host the odroid boards from Sherif
* Most of the SBCs for arm7vl/armhfp are not powerful enough to be good build hosts. Maybe we should try Honeycombs? (Solid-run)
* Pablo used his honeycomb and a fedora image to do the initial bootstrap builds
* Neil will reach out to OSU about availability of Lenovo eMAGs for us
* has neil spoken to Fabian? - No ; Neil will do this
* RISCv Rocky Port Status
* Neil - Investigate what and how much riscv hardware we need.. and where we'll host it
* This probably is going to be a whole bunch of VF2s
* P670 (16-core - MilkV oasis) would be great, but, upstream support is not yet there. VF2 is a better target for Rocky 9
* Various conversations happened here but Neil was dealing with keeping all the mice in his house dead. The following is second-hand :)
* Rpi Kernel - Should it live?
* We want to get rid of it, but we can't yet. Skip says yes
* Plan:
* Build the rpi kernel as a variant of the mainline
* rpi kernel will be subsumed into kernel-mainline-sbc, not further upstream
* This will allow more obvious contribution to ELrepo for SBCs
* RPI image will be replaced with a new GenericArm-SBC image produced by Empanadas which includes kernel-mainline-sbc
* Next meetings
* Dec 29 - Cancel.
* Jan 12 - Keep
## Action Items
* 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
## Old business
### 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.

View File

@ -0,0 +1,89 @@
# 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'](https://gitlab.com/cki-project/kernel-ark/-/blob/os-build/Kconfig.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.

View File

@ -0,0 +1,46 @@
# SIG/AltArch meeting 2024-01-26
## Attendees
* Neil Hanlon
* Bryan (codedude)
* Sherif Nagy
## Follow Ups
* Jan 2024 Uboot - Sherif completed, published 18 Jan
* RPI5 - Not going great
* Fedora can't boot it either, and it's not upstream yet
* Kernel is still missing Pi5 DTB
* Armbian is working, but they're probably patching the DTB
* Skip was working on firmware, not sure of status
* Bryan has a working Kernel, but it's hacky and broken... but it works (nominally)
* SBC Testing
* Testing of new Uboot underway
* Libre Tritium H5 - works fine
* Libre Le Potato - _appears_ that Libre hasn't upstreamed their entire uboot
* 2024 uboot, lots of NIC resets; vendor firmware doesn't do this
* Fedora “recommends” using vendor uboot for Potato
* **Q**: Do we want to recommend Le Potato but with Vendor Uboot for now?
* Rock5B/OrangePi uboot patches - not actually working right
* thefossguy built a one-off uboot for the OrangePi using an upstream tool (which is possibly proprietary/non-free)
## Tickets
https://git.resf.org/sig_altarch/meta/issues/4 - Jan 2024 uboot - Closed
## Open Floor
* mainline-sbc kernel
* [ ] Neil to get documentation for Kernel Packer and start the sbc kernel config repo
* SIG/Kernel tickets for variant creation
* https://git.rockylinux.org/codedude/kernel-mainline-sbc
* [SIG/Kernel#1](https://git.resf.org/sig_kernel/meta/issues/1)
* [SIG/Kernel#7](https://git.resf.org/sig_kernel/meta/issues/7)
* [SIG/Kernel#8](https://git.resf.org/sig_kernel/meta/issues/8)
* KernelPacker needs two things:
* Spec template + KConfig
## Action Items
* [ ] Neil to get documentation for Kernel Packer and start the sbc kernel config repo

View File

@ -0,0 +1,74 @@
# SIG/AltArch meeting 2024-02-09
## Attendees
* Neil Hanlon
* Sherif Nagy
* Brian Clemens
* Stack
## Follow Ups
* Raspberry Pi5
* need 16k page kernel variant created
```
--# diff config-6.1.0-rpi7-rpi-2712 config-6.1.0-rpi7-rpi-v8
31c31
< CONFIG_LOCALVERSION="-v8-16k"
---
> CONFIG_LOCALVERSION="-v8"
270,275c270,275
< CONFIG_ARM64_PAGE_SHIFT=14
< CONFIG_ARM64_CONT_PTE_SHIFT=7
< CONFIG_ARM64_CONT_PMD_SHIFT=5
< CONFIG_ARCH_MMAP_RND_BITS_MIN=16
< CONFIG_ARCH_MMAP_RND_BITS_MAX=30
< CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=9
---
> CONFIG_ARM64_PAGE_SHIFT=12
> CONFIG_ARM64_CONT_PTE_SHIFT=4
> CONFIG_ARM64_CONT_PMD_SHIFT=4
> CONFIG_ARCH_MMAP_RND_BITS_MIN=18
> CONFIG_ARCH_MMAP_RND_BITS_MAX=24
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=11
391,392c391,392
< # CONFIG_ARM64_4K_PAGES is not set
< CONFIG_ARM64_16K_PAGES=y
---
> CONFIG_ARM64_4K_PAGES=y
> # CONFIG_ARM64_16K_PAGES is not set
394,395c394
< # CONFIG_ARM64_VA_BITS_36 is not set
< CONFIG_ARM64_VA_BITS_47=y
---
> CONFIG_ARM64_VA_BITS_39=y
397c396
< CONFIG_ARM64_VA_BITS=47
---
> CONFIG_ARM64_VA_BITS=39
422c421
< CONFIG_ARCH_FORCE_MAX_ORDER=12
---
> CONFIG_ARCH_FORCE_MAX_ORDER=11
889a889
> CONFIG_ARCH_WANTS_THP_SWAP=y
```
* Post-setup changes required to select which one user should boot
* i.e., change initramfs / kernel lines to -v8 in config.txt / config-kernel.txt
* https://chat.rockylinux.org/rocky-linux/pl/e7h9sqcb4pdnpqpwah3wcjxjac
* Neil and Sherif spoke to risc-v folks at FOSDEM/SOOCon24
* No exact timeline, but hoping to get leads on hardware to use
## Open Floor
* Stack: the wiki looks abandoned because the index page is empty/stubbed
## Action Items
* Follow up on Orange Pi5
* Follow up on Libre boards
* Create variant for 16k kernel
* Kernel Packer for altarch
* Actually put content on wiki index/landing page so it doesn't look abandoned

View File

@ -0,0 +1,59 @@
# SIG/AltArch meeting 2024-02-23
## Attendees
* Neil Hanlon
* Sherif Nagy
* Brian Clemens
* Stack
* Alan Sill
## Follow Ups
* SBC Support - We're close on a lot of the boards we aim to support (Orange Pi, Libre boards, Rock Pro, RPi5, etc)
* Raspberry Pi5
* Needs 16k kernel variant
* arm-trusted-firmware in staging for 8 and 9
* please test, adds support for some SBCs we target
* RISC-V - Communications ongoing with RISC-V foundation for firmware
* What else do we want aside from what they may be able to give us?
## Open Floor
* Alan has Turing Pi boards to run his Pis--would be nice to be able to test these
* Jeff Geerling did a video recently on Turing Pi cluster board
* "little clusters" -- just shared NFS, works ok. needs to be NVME because of i/o thrashing, though
* Stack: there has been a lot of interest in SBCs in Rocky the past few months
* Would be good to have a plan to convert interested parties to contributors
* we have a lot of SBC $$$ to spend on HW for folks
* Roadmap & Status -- What do we support, who supports it, what works/doesn't work
* https://git.resf.org/testing/SBC-progress-tracking
* Risc-V
* Alan has [Lichee Pi 4a](https://wiki.sipeed.com/hardware/en/lichee/th1520/lc4a/lc4a.html) | https://sipeed.com/licheepi4a
* Should we include non-altarch (x86_64) SBCs in our list of what works?
* They work out of the box (for the most part), so, let's just include them
* https://radxa.com/products/x/x2l/#techspec - GPIO via a Pico
* Alan wants to get this running under Rocky at some point
* also looking at https://www.mixtile.com/cluster-box/
* Stack: Grace Hopper?
* seems to be only debian from NVidia
* Brian: Yoshi (CIQ) may have a contact that knows more information about Grace Hopper and Rocky
* Sherif: Intel GPU update
* Met with them through HPC SIG (Jeremy)
* DKMS version first for testing
* Later: signed for secureboot and installable as kmod package (kernel SIG)
* User tools in HPC SIG
* NVIDIA -- maybe we can talk to them after we show this working well, collaborate
* Needs legal review and sign-off from NVIDIA
* many questions about this... e.g. How can we trust signing a proprietary blob for SB signing?
* Stack's SBC tower: https://52pi.com/products/52pi-rack-tower-acrylic-cluster-case-for-raspberry-pi-12-layer?_pos=21&_sid=39b8f5ea0&_ss=r
## Action Items
* Neil to reach out to Equinix regarding arm hw for altarch
* Neil to reply to RV folks
* Neil to look into wiki content population
* Neil to file ticket to investigate kernel packer to repack upstream RPi kernel
* Neil to work on SBC Kernel variant config in KernelPacker
* Sherif to work on Raspberry Pi kernel variants

View File

@ -0,0 +1,32 @@
# SIG/AltArch meeting 2024-08-23
## Attendees
* Neil Hanlon
* Sherif Nagy
* Bryan Zuelly
* Daniel
* Stack
## Discussions
* [ ] Sherif to move rpi kernel into SIG repo
* https://forums.rockylinux.org/t/beta-sbc-images/15488/2
* beta generic images
* Stack: these are working really well
* what do we need to do to get this across the line?
* we need to build the kernel as the SIG
* [ ] Bryan to send Neil the kconfig were gonna user
* [ ] build three different images in kiwi
* GPT, MBR, RPi
* [ ] Neil to move SIG Wiki to Fastly
### Open Floor
* armhfp - nice to have, maybe we can get back to this at some point?
## Action Items
* [ ] 📝 Sherif to move rpi kernel into SIG repo
* [ ] 📝 Bryan to send Neil the kconfig were gonna user
* [ ] 📝 build three different images in kiwi
* [ ] 📝 Neil to move SIG Wiki to Fastly

View File

@ -0,0 +1,11 @@
### Decisions from 1st meeting - no exact date
* 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.
* 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.

View File

@ -1,16 +1,18 @@
# SIG/AltArch Wiki
## Links
## Responsibilities
## Meetings / Communications
Meetings are held fortnightly. Additional details can be found on the [Public_Calendar](https://calendar.google.com/calendar/u/0/embed?src=c_2e1oqh6t0i6sqhja5nu9lq8lgo@group.calendar.google.com)
## Members
## Project layout
- Sherif Nagy
- Skip Grube
- Pablo Greco
- Neil Hanlon
- Pratham Patel
- Bryan Zuelly
## Getting In Touch / Contributing
The primary way to get into contact with the Sig/AltArch group would be our Mattermost [channel](https://chat.rockylinux.org/rocky-linux/channels/altarch).
mkdocs.yml # The configuration file.
docs/
index.md # The documentation homepage.
... # Other markdown pages, images and other files.

View File

@ -0,0 +1,10 @@
# Amlogic-Based boards
The Libre boards below will require the use of the ```libretech-flash-tool``` provided by libre computer. it can be found on [their](https://github.com/libre-computer-project/libretech-flash-tool) github page.
- LibreTech-AC 'LaFrite'(S805X)
- LibreTech CC 'LePotato'(S905X)

View File

@ -0,0 +1,12 @@
# Rockchip-based Boards
For the boards below you will use the ```libretech-flash-tool``` from Libre. It can be found on [their](https://github.com/libre-computer-project/libretech-flash-tool) github page.
- rk3328
- rk3399
- roc-cc-rk3399
The Orange Pi 5 and Rock 5b require proprietary blogs from Rockchip. The Rock5b uboot is built and provided by Raxda. The Orange Pi 5 uboot can be obtained from project on github or built locally using a docker container. More info to come soon.
- Raxda Rock 5b
- Orange Pi 5

View File

@ -68,6 +68,8 @@ To install Rocky Linux on the VisionFive 2 SBC, there is one pre-requisite that
### Pre-requisite: Update board firmware
**NOTE: PLEASE READ THESE STEPS AND CAREFULLY FOLLOW THEM. IF DONE INCORRECTLY, YOUR BOARD MAY GET BRICKED!**
1. Download the following files:
- [sdcard.img](https://github.com/starfive-tech/VisionFive2/releases/download/VF2_v2.8.0/sdcard.img) (this image is from release v2.8.0)
- [u-boot-spl.bin.normal.out](https://github.com/starfive-tech/VisionFive2/releases/download/VF2_v2.11.5/u-boot-spl.bin.normal.out)

View File

@ -0,0 +1,95 @@
---
title: dnf-claims-restart
author: Funzi
---
# `dnf` always claims to require a restart
### Symptom
Even though the system has been restarted recently, e.g., after a Kernel update, `dnf needs-restarting -r` always
returns with exit code `1`.
```
# dnf needs-restarting -r
Core libraries or services have been updated since boot-up:
* dbus
* dbus-daemon
* glibc
* linux-firmware
* systemd
Reboot is required to fully utilize these updates.
More information: https://access.redhat.com/solutions/27943
```
**This affects both Rocky Linux 8 and 9.** However,
a [patch for 9.3 is to be released soon](https://github.com/rpm-software-management/dnf-plugins-core/pull/468).
### Cause
The `dnf` plugin uses the `mtime` of `/proc/1` which is set to start of epoch due to lack of RTC on Raspberry Pi. The
correct system time is set later at boot once network connectivity is established and an NTP server is reachable.
Compared to 1970, every package update is after the last reboot which causes the wrong result.
### Solution
Until 9.3 is released, or if the system is still on
8.x, [the patch](https://github.com/rpm-software-management/dnf-plugins-core/pull/468/commits/b8132e1e04fb44c9ef8ab7dbcea2d2b3b920be2c)
can be manually applied to all versions.
```
# patch /usr/lib/python3.6/site-packages/dnf-plugins/needs_restarting.py <<EOF
--- a/plugins/needs_restarting.py
+++ b/plugins/needs_restarting.py
@@ -34,6 +34,7 @@ import functools
import os
import re
import stat
+import time
# For which package updates we should recommend a reboot
@@ -199,7 +200,28 @@ class ProcessStart(object):
@staticmethod
def get_boot_time():
- return int(os.stat('/proc/1').st_mtime)
+ """
+ We have two sources from which to derive the boot time. These values vary
+ depending on containerization, existence of a Real Time Clock, etc.
+ For our purposes we want the latest derived value.
+ - st_mtime of /proc/1
+ Reflects the time the first process was run after booting
+ This works for all known cases except machines without
+ a RTC - they awake at the start of the epoch.
+ - /proc/uptime
+ Seconds field of /proc/uptime subtracted from the current time
+ Works for machines without RTC iff the current time is reasonably correct.
+ Does not work on containers which share their kernel with the
+ host - there the host kernel uptime is returned
+ """
+
+ proc_1_boot_time = int(os.stat('/proc/1').st_mtime)
+ if os.path.isfile('/proc/uptime'):
+ with open('/proc/uptime', 'rb') as f:
+ uptime = f.readline().strip().split()[0].strip()
+ proc_uptime_boot_time = int(time.time() - float(uptime))
+ return max(proc_1_boot_time, proc_uptime_boot_time)
+ return proc_1_boot_time
@staticmethod
def get_sc_clk_tck():
--
2.41.0
EOF
```
It is advisable to `version-lock` the plugin version until it's fixed upstream. On 8.x, that might be the only solutions
if the patch is not backported to 8.x upstream.
**Use at your own risk!**
```
# dnf versionlock add python3-dnf-plugins-core
```

View File

@ -0,0 +1,28 @@
---
title: Pi Zero 2W
author: Codedude
---
# Pi Zero 2W wont boot
### Problem
The Raspberry Pi Zero 2W wont boot using the standard Rocky LInux Raspberry Pi image.
### Solution
Using info gathered from [Rocky_Linux_forum_post](https://forums.rockylinux.org/trocky-linux-9-0-rpi-image-fail-to-boot-on-rpi3-workaround/7802/2)
```
# Blacklist brcmfmac
1. mount root partition
2. create a file called "01-rpi-blacklist.conf" in /etc/modprobe.d
3. umount root partition
4. boot the sd card in the pi zero 2w.
Then:
5. run /usr/bin/fix-wifi-rpi.sh This script extracts all firmware files. Feel free to look it over before running it.
6. delete the 01-rpi-blacklist.conf file from /etc/modprobe.ed
7. reboot
8. Wifi should now be functional
```

View File

@ -1,49 +0,0 @@
---
title: Supported SBC Hardware
author: Bryan Z.
---
# Rocky Linux Supported SBC Hardware Models
## Raspberry Pi SBCs
| Model | Image | Status |
|---------------|-----------------------------------|---------------|
| Pi 4B | RockyLinux_Rpi_9-latest.img.xz | Complete |
| Pi 3B/B+ | RockyLinux_Rpi_9-latest.img.xz | Complete |
## Banana Pi
| Model | Status |
|---------------|---------------------------------------------------|
| Unknown | Stage 1(hardware being procured) |
## Orange Pi
| Model | Status |
|---------------|---------------------------------------------------|
| Unknown | Stage 1(hardware being procured) |
## Pine
| Model | Image | Status |
|---------------|----------------------------------------------------------|----------------------------------------|
| Pine64 | | Stage 1(hardware being obtained) |
| RockPro64 | Rocky-9.1-aarch64-generic-Minimal-rk3399-sda.raw.tar.gz | Complete |
| A64_LTS | | Stage 1(hardware being obtained) |
## Libre Computer
| Model | Status |
|---------------|----------------------------------------------------------------|
| Renegade | Stage 2(hw obtained, initial testing to discover whats needed) |
| La Frite | Stage 2(hw obtained, initial testing to discover whats needed) |
| Tritium | Stage 2(hw obtained, initial testing to discover whats needed) |
| Le Potato | Stage 2(hw obtained, initial testing to discover whats needed) |
## Ordoid
| Model | Status |
|---------------|-----------------------------------------------------------------|
| N2+ | Stage 2(hw obtained, initial testing to discover what's needed) |
## Khadas
| Model | Image | Status |
|---------------|---------------------------------------------------|
| In early phases of discovery. | | |

View File

@ -11,24 +11,23 @@ repo_name: sig_altarch/wiki
edit_uri: _edit/main/docs/
# Copyright
copyright: Copyright &copy; 2023 Rocky Enterprise Software Foundation
copyright: Copyright &copy; 2024 Rocky Enterprise Software Foundation
extra_css:
- assets/extra.css
# Configuration
theme:
name: material
logo: assets/icon-white.svg
logo: assets/resf-white.svg
palette:
- media: "(prefers-color-scheme: light)"
scheme: default
primary: teal
accent: teal
scheme: resf
toggle:
icon: material/weather-night
name: Switch to dark mode
- media: "(prefers-color-scheme: dark)"
scheme: slate
primary: teal
accent: teal
scheme: resf-dark
toggle:
icon: material/weather-sunny
name: Switch to light mode
@ -39,7 +38,7 @@ theme:
- python
- yaml
features:
- navigation.expand
# - navigation.expand
- navigation.indexes
- navigation.instant
- navigation.sections
@ -54,6 +53,7 @@ theme:
# Plugins
plugins:
- autolinks
- social
- awesome-pages
- git-revision-date-localized:
type: date
@ -69,8 +69,8 @@ markdown_extensions:
- meta
- pymdownx.details # this allows collapsible attributions
- pymdownx.emoji:
emoji_index: !!python/name:materialx.emoji.twemoji
emoji_generator: !!python/name:materialx.emoji.to_svg
emoji_index: !!python/name:material.extensions.emoji.twemoji
emoji_generator: !!python/name:material.extensions.emoji.to_svg
- pymdownx.superfences
- pymdownx.tabbed:
alternate_style: true

View File

@ -1,7 +1,51 @@
mkdocs
mkdocs-autolinks-plugin
mkdocs-awesome-pages-plugin
mkdocs-git-revision-date-localized-plugin
mkdocs-macros-plugin
mkdocs-material
mkdocs-windmill
babel==2.16.0
bracex==2.5
cairocffi==1.7.1
CairoSVG==2.7.1
certifi==2024.7.4
cffi==1.17.0
charset-normalizer==3.3.2
click==8.1.7
colorama==0.4.6
cssselect2==0.7.0
defusedxml==0.7.1
ghp-import==2.1.0
gitdb==4.0.11
GitPython==3.1.43
idna==3.8
Jinja2==3.1.4
Markdown==3.7
MarkupSafe==2.1.5
mergedeep==1.3.4
mkdocs==1.6.0
mkdocs-autolinks-plugin==0.7.1
mkdocs-awesome-pages-plugin==2.9.3
mkdocs-get-deps==0.2.0
mkdocs-git-revision-date-localized-plugin==1.2.7
mkdocs-macros-plugin==1.0.5
mkdocs-material==9.5.33
mkdocs-material-extensions==1.3.1
mkdocs-windmill==1.0.5
natsort==8.4.0
packaging==24.1
paginate==0.5.6
pathspec==0.12.1
pillow==10.4.0
platformdirs==4.2.2
pycparser==2.22
Pygments==2.18.0
pymdown-extensions==10.9
python-dateutil==2.9.0.post0
pytz==2024.1
PyYAML==6.0.2
pyyaml_env_tag==0.1
regex==2024.7.24
requests==2.32.3
six==1.16.0
smmap==5.0.1
termcolor==2.4.0
tinycss2==1.3.0
urllib3==2.2.2
watchdog==4.0.2
wcmatch==9.0
webencodings==0.5.1