automotive-sig January 2026

automotive-sig@lists.centos.org

4 participants
3 discussions

Re: [CentOS-devel] Fwd: [PROPOSAL] Creating the NVIDIA Enablement SIG - Accelerating NVIDIA Upstream Integration
by Sandro Bonazzola 15 Jan '26

15 Jan '26

@CentOS Automotive SIG <automotive-sig(a)lists.centos.org> may be interested as well. Il giorno mer 14 gen 2026 alle ore 21:18 Amy Marrich via devel < devel(a)lists.centos.org> ha scritto: > > ---------- Forwarded message --------- > From: Amnon Ilan <ailan(a)redhat.com> > Date: Tue, Jan 13, 2026 at 2:35 PM > Subject: [PROPOSAL] Creating the NVIDIA Enablement SIG - Accelerating > NVIDIA Upstream Integration > To: <devel(a)lists.centos.org> > Cc: Amy Marrich <amarrich(a)redhat.com>, Neo Jia <cjia(a)nvidia.com>, < > newtonl(a)nvidia.com> > > > Hello everyone, > > I would like to propose the creation of a new Special Interest Group: the NVIDIA > Enablement SIG. > Purpose > > The NVIDIA Enablement SIG will integrate these "in-flight" upstream > patches from NVIDIA into a specialized variant of CentOS Stream, allowing > the community to test and utilize next-generation hardware capabilities > today. > Scope > > The initial work of the SIG will focus on the foundational layers of the > stack required for modern compute and graphics hardware: > > - > > Linux Kernel: Integrating and testing patches submitted by NVIDIA to > the kernel community that improve hardware support and system integration. > - > > Virtualization (QEMU & libvirt): Implementing upcoming changes that > enhance how virtual machines interact with hardware accelerators and modern > GPU architectures. > - > > Continuous Alignment: Ensuring these patches maintain parallel > compatibility with the core CentOS Stream codebase as they evolve during > the upstream review process. > > Deliverables > > - > > SIG Repositories: builds of the kernel, qemu-kvm, and libvirt > containing the latest upstream-bound patches. > - > > Enablement Packages: A centos-release-nvidia-enablement package to > provide users with an easy path to opt-in to these experimental stacks. > - > > Future work: > - > > Expanded package set as appropriate > - > > Install media / images > > Initial Members > > - > > Amnon Ilan - (Proposed Chair) > - > > Amy Marrich - (Board Sponsor) > - > > Neo Gia > - > > Newton Liu > - > > [Member Name] (We invite anyone interested in the future of > open-source hardware enablement to join us.) > > Resources Requested > > - > > Wiki: sigs.centos.org/nvidia-enablement > - > > CBS Access: Build tags and targets for CentOS Stream 10. > > We look forward to hearing the community's thoughts on this proposal. > > Best regards, > > Amnon Ilan > _______________________________________________ > devel mailing list -- devel(a)lists.centos.org > To unsubscribe send an email to devel-leave(a)lists.centos.org > -- Sandro Bonazzola MANAGER, ENGINEERING Red Hat In-Vehicle Operating System Red Hat <https://www.redhat.com/> <https://www.redhat.com/> <https://redhat.com/options> *Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.*

1 0

CentOS Bringup issue for J784S4 EVM board.
by sanskruti.bk＠mistralsolutions.com 13 Jan '26

13 Jan '26

We are experiencing issues while booting the J784S4 EVM board using prebuilt images. We have attached the detailed build procedure followed, along with the error logs observed during the boot process of the J784S4 board, for your reference. Please share the recommended procedure to create a bootable SD card using the prebuilt images. Procedure - 1. Site followed - https://sig.centos.org/automotive/provisioning/flashing-texas- instruments/ 2. Prebuilt image – 1. https://download.autosd.sig.centos.org/AutoSD-9/nightly/TI/auto- osbuild-j784s4evm-autosd9-qa-regular-aarch64-2208122337.e5a9b30b.raw.xz 3. To uncompress the image - $ xz -d =/home/sanskruti/Downloads/auto-osbuild- j784s4evm-autosd9-qa-regular-aarch64-2208122337.e5a9b30b.raw.xz 4. To flash image to sd card - sudo dd if=/home/sanskruti/Downloads/auto-osbuild- j784s4evm-autosd9-qa-regular-aarch64-2208122337.e5a9b30b.raw of=/dev/mmcblk0p bs=4M status=progress conv=fsync Output - (Logs after plug in the SD card to board) U-Boot SPL 2025.07-3.el9 (Sep 29 2025 - 00:00:00 +0000) SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.9--v11.00.09+ (Fancy Rat)') Initialized 4 DRAM controllers SPL initial stack usage: 13456 bytes Trying to boot from MMC2 Loading Environment from nowhere... OK Starting ATF on ARM64 core... NOTICE: BL31: v2.13.0(debug): NOTICE: BL31: Built : 00:00:00, Sep 29 2025 INFO: GICv3 without legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: Maximum SPI INTID supported: 991 INFO: SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.9--v11.00.09+ (Fancy Rat)') INFO: BL31: Initializing runtime services INFO: BL31: cortex_a72: CPU workaround for erratum 1319367 was applied INFO: BL31: cortex_a72: CPU workaround for CVE 2018_3639 was applied INFO: BL31: cortex_a72: CPU workaround for CVE 2022_23960 was applied INFO: BL31: Initializing BL32 I/TC: I/TC: OP-TEE version: Unknown_4.6 (gcc version 12.1.1 20220507 (Red Hat Cross 12.1.1-1) (GCC)) #1 Mon Sep 24 I/TC: WARNING: This OP-TEE configuration might be insecure! I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html I/TC: Primary CPU initializing I/TC: GIC redistributor base address not provided I/TC: Assuming default GIC group status and modifier I/TC: SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.9--v11.00.09+ (Fancy Rat)') I/TC: Activated SA2UL device I/TC: Fixing SA2UL firewall owner for GP device I/TC: Enabled firewalls for SA2UL TRNG device I/TC: SA2UL TRNG initialized I/TC: SA2UL Drivers initialized I/TC: HUK Initialized I/TC: Primary CPU switching to normal world boot INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x80080000 INFO: SPSR = 0x3c9 U-Boot SPL 2025.07-3.el9 (Sep 29 2025 - 00:00:00 +0000) SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.9--v11.00.09+ (Fancy Rat)') Trying to boot from MMC2 U-Boot 2025.07-3.el9 (Sep 29 2025 - 00:00:00 +0000) SoC: J784S4 SR1.0 GP Model: Texas Instruments J784S4 EVM DRAM: 2 GiB (total 32 GiB) cdns3_bind: unsupported dr_mode Core: 135 devices, 34 uclasses, devicetree: separate Flash: 0 Bytes MMC: mmc@4f80000: 0, mmc@4fb0000: 1 Loading Environment from nowhere... OK In: serial@2880000 Out: serial@2880000 Err: serial@2880000 am65_cpsw_nuss ethernet@46000000: K3 CPSW: nuss_ver: 0x6BA02102 cpsw_ver: 0x6BA82102 ale_ver: 0x00293904 Po1 Net: eth0: ethernet@46000000port@1 Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc1 is current device SD/MMC found on device 1 Failed to load 'uEnv.txt' Scanning for bootflows in all bootdevs Seq Method State Uclass Part Name Filename --- ----------- ------ -------- ---- ------------------------ ---------------- Scanning global bootmeth 'efi_mgr': Cannot persist EFI variables without system partition 0 efi_mgr ready (none) 0 <NULL> ** Booting bootflow '<NULL>' with efi_mgr Booting: Label: mmc 1 Device path: /VenHw(e61d73b9-a384-4acc-aeab- 82e828f3628b,0000000000000000)/VenHw(e61d) Starting ukiboot version 0.2.0 Unable to find ukibootctl partition Unable to find active slot Error: Unable to boot (Not Found) ## Application failed, r = 14 Boot failed (err=-14) Scanning bootdev 'mmc(a)4fb0000.bootdev': 1 efi ready mmc 1 mmc(a)4fb0000.bootdev.part_ /EFI/BOOT/BOOTAA64.EFI ** Booting bootflow 'mmc(a)4fb0000.bootdev.part_1' with efi Booting /\EFI\BOOT\BOOTAA64.EFI Starting ukiboot version 0.2.0 Unable to find ukibootctl partition Unable to find active slot Error: Unable to boot (Not Found) ## Application failed, r = 14 Boot failed (err=-22) Scanning bootdev 'mmc(a)4f80000.bootdev': No USB controllers found Scanning bootdev 'port(a)1.bootdev': k3-navss-ringacc ringacc@2b800000: Ring Accelerator probed rings:286, gp- rings[96,20] sci-dev-id:328 k3-navss-ringacc ringacc@2b800000: dma-ring-reset-quirk: disabled am65_cpsw_nuss_port ethernet@46000000port@1: K3 CPSW: rflow_id_base: 3 ethernet@46000000port@1 Waiting for PHY auto negotiation to complete......... TIMEOUT ! am65_cpsw_nuss_port ethernet@46000000port@1: phy_startup failed am65_cpsw_nuss_port ethernet@46000000port@1: am65_cpsw_start end error BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 BOOTP broadcast 4 BOOTP broadcast 5 BOOTP broadcast 6 BOOTP broadcast 7 BOOTP broadcast 8 BOOTP broadcast 9 BOOTP broadcast 10 BOOTP broadcast 11 BOOTP broadcast 12 BOOTP broadcast 13 BOOTP broadcast 14 BOOTP broadcast 15 BOOTP broadcast 16 BOOTP broadcast 17 Retry time exceeded; starting again Scanning bootdev 'port(a)1.bootdev': am65_cpsw_nuss_port ethernet@46000000port@1: K3 CPSW: rflow_id_base: 3 ethernet@46000000port@1 Waiting for PHY auto negotiation to complete......... TIMEOUT ! am65_cpsw_nuss_port ethernet@46000000port@1: phy_startup failed am65_cpsw_nuss_port ethernet@46000000port@1: am65_cpsw_start end error BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 BOOTP broadcast 4 BOOTP broadcast 5 BOOTP broadcast 6 BOOTP broadcast 7 BOOTP broadcast 8 BOOTP broadcast 9 BOOTP broadcast 10 BOOTP broadcast 11 BOOTP broadcast 12 BOOTP broadcast 13 BOOTP broadcast 14 BOOTP broadcast 15 BOOTP broadcast 16 BOOTP broadcast 17 Retry time exceeded; starting again No more bootdevs --- ----------- ------ -------- ---- ------------------------ ---------------- (2 bootflows, 2 valid) =>

2 1

CI failure notifications?
by Pierre-Yves Chibon 09 Jan '26

09 Jan '26

Good Morning Everyone, In the sig-docs [1] repository we have a CI job that runs daily and builds, runs and checks a number of images [2]. When those builds/runs/checks fail there is usually a good reason that we should go and check. Currently I believe I'm the only one being notified about those failure. As part of https://gitlab.com/CentOS/automotive/sig-docs/-/merge_requests/441 I'd like this list to be notified, but I don't want to do this without asking before. So what do you all think? Is anyone against this? If not, then I'll go ahead with the change and if it starts to be too annoying/noisy we can always revisit later :) Looking forward for your feedback :) Pierre

1 1

2026

2025

2024

2023

2022

2021

automotive-sig January 2026