- automotive-sig - lists.centos.org

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

Re: New repository under automotive/demos
by Pierre-Yves Chibon 01 Dec '25

01 Dec '25

On Mon, Nov 24, 2025 at 07:14:47PM +0200, Shmuel Melamud via automotive-sig wrote: > Hi Everyone, > > I need a new repository 'vm-connect' under > https://gitlab.com/CentOS/automotive/demos to place sample > configurations to be used for inter-VM communication. The project has been created: https://gitlab.com/CentOS/automotive/demos/vm-connect# Sorry for the delay :] Let me know if there is anything else I can help with! Cheers, Pierre

1 0

New repository under automotive/demos
by Shmuel Melamud 24 Nov '25

24 Nov '25

Hi Everyone, I need a new repository 'vm-connect' under https://gitlab.com/CentOS/automotive/demos to place sample configurations to be used for inter-VM communication. Can you please give me permissions for adding a repository or create the repository for myself? Shmuel

1 0

Repository request
by mengel＠redhat.com 13 Oct '25

13 Oct '25

Hi everyone, I would like to request a new repository to be created: https://gitlab.com/CentOS/automotive/src/selcraft This repository will host a project for generating selinux policies for automotive based on a configuration. I intend to move the contents of https://gitlab.com/mengel1/custom-qm-policy as soon as the repo is created. Regards, Michael Engel

2 1

linux-firmware-automotive development repository request
by Ian Mullins 23 Sep '25

23 Sep '25

Hello, I'm requesting the creation of a new repository in the src namespace as seen below: - https://gitlab.com/CentOS/automotive/src/linux-firmware-automotive The linux-firmware-automotive project currently resides in https://gitlab.com/CentOS/automotive/rpms/linux-firmware-automotive, which serves both as development and dist-git repo. The new repository is required to migrate the development of the project, leaving the original project repository as dist-git only. Kind regards, Ian

2 1

Re: Request to create a repository `k3-upstream-boot`
by Enric Balletbo i Serra 28 Aug '25

28 Aug '25

Dear list, Hopefully I'm subscribed now and the email is not lost. I'd like to make a request for a `k3-upstream-boot` repository at ` https://gitlab.com/CentOS/automotive/rpms/` <https://gitlab.com/CentOS/automotive/rpms/>. This repository will host the RPM package for firmware needed to boot TI k3 platforms like the J784S4 EVM and AM69-SK boards. While here, I'd like to take the opportunity to ask you to create another repository, 's32g-vendor-boot'. Similar to the other, this repository will host the RPM package for firmware needed to boot S32G platforms using the public vendor components/repositories Your help is appreciated. Best regards, Enric > On Thu, Jul 31, 2025 at 4:13 PM Enric Balletbo i Serra < > eballetb(a)redhat.com> wrote: > >> Dear list, >> >> Could you please create a `k3-upstream-boot` repository in our GitLab >> instance under https://gitlab.com/CentOS/automotive/rpms/? >> >> The purpose of this repository is to track the rpm package that >> contains the firmware required to boot different TI k3 platforms like >> J784S4 EVM and AM69-SK boards. >> >> Best regards, >> Enric >> >

2 3

Re: Request to create a repository `k3-upstream-boot`
by Pierre-Yves Chibon 28 Aug '25

28 Aug '25

On Wed, Aug 27, 2025 at 01:35:26PM +0200, Enric Balletbo i Serra via automotive-sig wrote: > Dear list, > Hopefully I'm subscribed now and the email is not lost. I'd like to make a > request for a `k3-upstream-boot` repository at > `[1]https://gitlab.com/CentOS/automotive/rpms/`. This repository will host > the RPM package for firmware needed to boot TI k3 platforms like the > J784S4 EVM and AM69-SK boards. > While here, I'd like to take the opportunity to ask you to create another > repository, 's32g-vendor-boot'. Similar to the other, this repository will > host the RPM package for firmware needed to boot S32G platforms using the > public vendor components/repositories Both projects have been created: https://gitlab.com/CentOS/automotive/rpms/k3-upstream-boot https://gitlab.com/CentOS/automotive/rpms/s32g-vendor-boot Happy packing! Pierre PS: now sent from the right email

2 2

Demo repo creation: soafee-virtual-platform-blueprint
by Leonardo Rossetti 21 Jul '25

21 Jul '25

Hello, I would like to request a new demo repository in https://gitlab.com/CentOS/automotive/demos, named "soafee-virtual-platform-blueprint". This repository will host demo files to run our SOAFEE virtual platform blueprint (AutoSD Frankenbuild for now). Regards, -- Leonardo Rossetti Principal Software Engineer, Red Hat <https://www.redhat.com> lrossett(a)redhat.com <https://www.redhat.com>

2 2

2026

2025

2024

2023

2022

2021

automotive-sig