- automotive-sig - lists.centos.org

CentOS Bringup issue for J784S4 EVM board.
by Sanskruti Baburao Kadam 10 Mar '26

10 Mar '26

Hi, 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. Thanks and regards, Sanskruti K.

2 1

Custom kernel build fails: rsync: Argument list too long
by Sebastian Hetze 02 Mar '26

02 Mar '26

Hi *, when trying to build the centos-stream-9 main-automotive kernel for the x86_64 architecture as described in the automotive sig documentation <https://sigs.centos.org/automotive/building/building_an_os_image_that%20use…>, it fails. The failing command appears to be /usr/bin/make -s 'HOSTCFLAGS=-O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' 'HOSTLDFLAGS=-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 ' -j12 ARCH=x86_64 V=1 'TARGETS=bpf cgroup mm livepatch net net/forwarding net/mptcp netfilter tc-testing memfd drivers/net/bonding iommu cachestat drivers/net' SKIP_TARGETS= FORCE_TARGETS=1 INSTALL_PATH=/home/she/rpmbuild/BUILDROOT/kernel-automotive-5.14.0-570.518_at.el9iv.x86_64/usr/libexec/kselftests VMLINUX_H= DEFAULT_INSTALL_HDR_PATH=0 install with the error make[3]: Entering directory '/home/she/Workspace/centos-stream-9/redhat/rpm/BUILD/kernel-5.14.0-570.518_at.el9iv/linux-5.14.0-570.518_at.el9iv.x86_64/tools/testing/selftests/bpf' Auto-detecting system features: ... llvm: [ OFF ] make[3]: rsync: Argument list too long make[3]: *** [Makefile:768: test_progs-no_alu32-extras] Error 127 make[3]: Leaving directory '/home/she/Workspace/centos-stream-9/redhat/rpm/BUILD/kernel-5.14.0-570.518_at.el9iv/linux-5.14.0-570.518_at.el9iv.x86_64/tools/testing/selftests/bpf' make[2]: *** [Makefile:233: install] Error 2 This is the unmodified main-automotive branch of the current centos-stream-9 kernel on a current centos-stream-9 system. Setting ulimit -S -s unlimited for ARG_MAX 6291456 does not make any difference. It looks like the actual problem is not with the rsync command line. Any hint what is going wrong and how to proceed? Beste Grüße Sebastian Hetze -- Principal Software Engineer Red Hat GmbH. Niederlassung Berlin Leipziger Platz 16, 10117 Berlin Mobil: +49 173 8914205 E-Mail: she(a)redhat.com Registered seat: Werner von Siemens Ring 14, D-85630 Grasbrunn, Germany Commercial register: Amtsgericht Muenchen/Munich, HRB 153243,Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross

3 2

Changing commit access for the Automotive SIG
by Jeffrey Osier-Mixon 02 Mar '26

02 Mar '26

Hi folks - we are paring down the number of inactive accounts who have commit access to the SIG repos. If you haven't committed, sent email, or otherwise interacted with the SIG in the past 3 months, we will be decommissioning your permission. If you feel this is in error, please get in touch and we can fix it. thanks Jeffrey "Jefro" Osier-Mixon | josiermi(a)redhat.com Distinguished Community Architect Automotive, Edge, & Hardware Enablement Communities Red Hat Open Source & AI Program Office Book a meeting: https://calendar.app.google/sMBa7Xe8CLSEUdGV9

2 1

Enforcing 2FA to the CentOS/automotive namespace
by Pierre-Yves Chibon 25 Feb '26

25 Feb '26

Good Morning Everyone, I would like to raise the topic of enforcing 2FA on the entire CentOS/Automotive namespace on gitlab: https://gitlab.com/CentOS/automotive/ This is something I can do, but before I click the button I'd like to ask: is anyone opposed to this? If not, I'll switch the configuration next week. Thanks in advance for your thoughts! Pierre

5 5

New repository request
by mengel＠redhat.com 23 Feb '26

23 Feb '26

Hi everyone, I would like to request a new repository creation: https://gitlab.com/CentOS/automotive/src/sysboot This repository will host a package creating system boot checks based on systemd by using simple unit drop-ins. This will, later on, also be used in [automotive-image-builder](https://gitlab.com/CentOS/automotive/src/automoti…. Regards, Michael Engel Senior Software Engineer, Red Hat https://www.redhat.com mengel(a)redhat.com https://www.redhat.com

2 3

Building an AUTOSD Image for TDA4 EVM
by sanskruti.bk＠mistralsolutions.com 19 Feb '26

19 Feb '26

I am experiencing issues while building an AUTOSD image for TDA4 EVM Board. I have attached the detailed build procedure followed, along with the error logs observed during the build process of the TDA4 EVM board, for your reference. Please share the recommended procedure to create a bootable SD card using the AUTOSD image. Website followed - https://docs.centos.org/automotive-sig-documentation/provisioning/flashing-… OS - CentOS Stream 10 (On virtual machine manager) Commands used - [sk@localhost automotive-image-builder]$ sudo ./bin/aib-dev build-deprecated \ --container \ --target tda4vm_sk \ --mode package \ --export image \ examples/simple.aib.yml . Output - usage: aib-dev [-h] [--version] [--verbose] {build-deprecated,build,list-distro,list-targets,list-rpms,download} ... aib-dev: error: unrecognized arguments: tda4vm_sk --mode package --export image examples/simple.aib.yml .

3 7

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

26 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

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

25 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

Request: kernel-ivos-qualcomm dist-git repository
by scweaver＠redhat.com 21 Jan '26

21 Jan '26

Please create a dist-git repo for kernel-ivos-qualcomm at https://gitlab.com/CentOS/automotive/rpms/kernel-ivos-qualcomm This repo will be used in the same way that we use https://gitlab.com/CentOS/automotive/rpms/kernel-automotive today. For AutoSD builds we will push to the c10s-sig-automotive-main branch. (We do not need a c9s branch.) Thank you, Scott

2 1

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

2026

2025

2024

2023

2022

2021

automotive-sig