Pin the RISC-V toolchain to xPack GCC 14.3.0

[fdesbiens]

Pin the RISC-V toolchain to xPack GCC 14.3.0

Why

After #53 the ARM job pins Arm GNU Toolchain 14.3.Rel1, but the PolarFire job still pinned xPack riscv-none-elf-gcc14.2.0-1 — leaving the two cross-compilers in one pipeline a minor release apart for no reason. xPack published v14.3.0-1 on 2025-10-23, so both targets can sit on GCC 14.3 while still satisfying the AGENTS.md GCC 14 requirement.

What changed

One step, three values: the release tag, the tarball name, and the published SHA256.

	Before	After
Release	v14.2.0-1	v14.3.0-1
GCC	14.2.0	14.3.0
SHA256	a5eb7075…6200	be1768ef…c726

No other hardening was needed here. Unlike the ARM step before #53, this job already verified its download with sha256sum --check --strict, which is why #53's checksum fix did not apply to it.

Verification

Installed xPack GNU RISC-V Embedded GCC 14.3.0 locally and ran the full pipeline by hand:

• Clean build of polarfire_icicle_demo.elf.
• Headless Renode suite passes, exit 0, with every startup self-test green — _sbrk bounds, the HWTimer catch-up clamp, PLIC Hart 1 configuration (IRQ 91 prio=1 en=0x08000000 thresh=0 mie=0x800), the queue round-trip, ThreadX ticks, the LM75 alarm, and the PLIC RX interrupt.
• Checksum verified against the value published in the release assets.

One pre-existing issue, deliberately not folded in

The build emits:

ld: warning: app/polarfire_icicle_demo.elf has a LOAD segment with RWX permissions

I checked whether the bump introduced it: it did not. The current pipeline on 14.2.0 emits the identical warning (visible in the run 33430244827 build log, from riscv-none-elf/14.2.0). It points at the PolarFire linker script placing writable and executable content in one segment, and deserves its own change rather than being buried in a version bump.

Follow-up worth considering

The xPack and Renode downloads still re-fetch on every run — roughly 400 MB and 200 MB respectively, the latter in two separate jobs. actions/cache, as #53 added for the ARM toolchain, would apply to all three.

[fdesbiens]

Pin the RISC-V toolchain to xPack GCC 14.3.0

Why

After #53 the ARM job pins Arm GNU Toolchain 14.3.Rel1, but the PolarFire job still pinned xPack riscv-none-elf-gcc14.2.0-1 — leaving the two cross-compilers in one pipeline a minor release apart for no reason. xPack published v14.3.0-1 on 2025-10-23, so both targets can sit on GCC 14.3 while still satisfying the AGENTS.md GCC 14 requirement.

What changed

One step, three values: the release tag, the tarball name, and the published SHA256.

	Before	After
Release	v14.2.0-1	v14.3.0-1
GCC	14.2.0	14.3.0
SHA256	a5eb7075…6200	be1768ef…c726

No other hardening was needed here. Unlike the ARM step before #53, this job already verified its download with sha256sum --check --strict, which is why #53's checksum fix did not apply to it.

Verification

Installed xPack GNU RISC-V Embedded GCC 14.3.0 locally and ran the full pipeline by hand:

• Clean build of polarfire_icicle_demo.elf.
• Headless Renode suite passes, exit 0, with every startup self-test green — _sbrk bounds, the HWTimer catch-up clamp, PLIC Hart 1 configuration (IRQ 91 prio=1 en=0x08000000 thresh=0 mie=0x800), the queue round-trip, ThreadX ticks, the LM75 alarm, and the PLIC RX interrupt.
• Checksum verified against the value published in the release assets.

One pre-existing issue, deliberately not folded in

The build emits:

ld: warning: app/polarfire_icicle_demo.elf has a LOAD segment with RWX permissions

I checked whether the bump introduced it: it did not. The current pipeline on 14.2.0 emits the identical warning (visible in the run 33430244827 build log, from riscv-none-elf/14.2.0). It points at the PolarFire linker script placing writable and executable content in one segment, and deserves its own change rather than being buried in a version bump.

Follow-up worth considering

The xPack and Renode downloads still re-fetch on every run — roughly 400 MB and 200 MB respectively, the latter in two separate jobs. actions/cache, as #53 added for the ARM toolchain, would apply to all three.

[fdesbiens]

Pin the RISC-V toolchain to xPack GCC 14.3.0

Why

After #53 the ARM job pins Arm GNU Toolchain 14.3.Rel1, but the PolarFire job still pinned xPack riscv-none-elf-gcc14.2.0-1 — leaving the two cross-compilers in one pipeline a minor release apart for no reason. xPack published v14.3.0-1 on 2025-10-23, so both targets can sit on GCC 14.3 while still satisfying the AGENTS.md GCC 14 requirement.

What changed

One step, three values: the release tag, the tarball name, and the published SHA256.

	Before	After
Release	v14.2.0-1	v14.3.0-1
GCC	14.2.0	14.3.0
SHA256	a5eb7075…6200	be1768ef…c726

No other hardening was needed here. Unlike the ARM step before #53, this job already verified its download with sha256sum --check --strict, which is why #53's checksum fix did not apply to it.

Verification

Installed xPack GNU RISC-V Embedded GCC 14.3.0 locally and ran the full pipeline by hand:

• Clean build of polarfire_icicle_demo.elf.
• Headless Renode suite passes, exit 0, with every startup self-test green — _sbrk bounds, the HWTimer catch-up clamp, PLIC Hart 1 configuration (IRQ 91 prio=1 en=0x08000000 thresh=0 mie=0x800), the queue round-trip, ThreadX ticks, the LM75 alarm, and the PLIC RX interrupt.
• Checksum verified against the value published in the release assets.

One pre-existing issue, deliberately not folded in

The build emits:

ld: warning: app/polarfire_icicle_demo.elf has a LOAD segment with RWX permissions

I checked whether the bump introduced it: it did not. The current pipeline on 14.2.0 emits the identical warning (visible in the run 33430244827 build log, from riscv-none-elf/14.2.0). It points at the PolarFire linker script placing writable and executable content in one segment, and deserves its own change rather than being buried in a version bump.

Follow-up worth considering

The xPack and Renode downloads still re-fetch on every run — roughly 400 MB and 200 MB respectively, the latter in two separate jobs. actions/cache, as #53 added for the ARM toolchain, would apply to all three.

[fdesbiens]

Pin the RISC-V toolchain to xPack GCC 14.3.0

Why

After #53 the ARM job pins Arm GNU Toolchain 14.3.Rel1, but the PolarFire job still pinned xPack riscv-none-elf-gcc14.2.0-1 — leaving the two cross-compilers in one pipeline a minor release apart for no reason. xPack published v14.3.0-1 on 2025-10-23, so both targets can sit on GCC 14.3 while still satisfying the AGENTS.md GCC 14 requirement.

What changed

One step, three values: the release tag, the tarball name, and the published SHA256.

	Before	After
Release	v14.2.0-1	v14.3.0-1
GCC	14.2.0	14.3.0
SHA256	a5eb7075…6200	be1768ef…c726

No other hardening was needed here. Unlike the ARM step before #53, this job already verified its download with sha256sum --check --strict, which is why #53's checksum fix did not apply to it.

Verification

Installed xPack GNU RISC-V Embedded GCC 14.3.0 locally and ran the full pipeline by hand:

• Clean build of polarfire_icicle_demo.elf.
• Headless Renode suite passes, exit 0, with every startup self-test green — _sbrk bounds, the HWTimer catch-up clamp, PLIC Hart 1 configuration (IRQ 91 prio=1 en=0x08000000 thresh=0 mie=0x800), the queue round-trip, ThreadX ticks, the LM75 alarm, and the PLIC RX interrupt.
• Checksum verified against the value published in the release assets.

One pre-existing issue, deliberately not folded in

The build emits:

ld: warning: app/polarfire_icicle_demo.elf has a LOAD segment with RWX permissions

I checked whether the bump introduced it: it did not. The current pipeline on 14.2.0 emits the identical warning (visible in the run 33430244827 build log, from riscv-none-elf/14.2.0). It points at the PolarFire linker script placing writable and executable content in one segment, and deserves its own change rather than being buried in a version bump.

Follow-up worth considering

The xPack and Renode downloads still re-fetch on every run — roughly 400 MB and 200 MB respectively, the latter in two separate jobs. actions/cache, as #53 added for the ARM toolchain, would apply to all three.

[fdesbiens]

Pin the RISC-V toolchain to xPack GCC 14.3.0

Why

After #53 the ARM job pins Arm GNU Toolchain 14.3.Rel1, but the PolarFire job still pinned xPack riscv-none-elf-gcc14.2.0-1 — leaving the two cross-compilers in one pipeline a minor release apart for no reason. xPack published v14.3.0-1 on 2025-10-23, so both targets can sit on GCC 14.3 while still satisfying the AGENTS.md GCC 14 requirement.

What changed

One step, three values: the release tag, the tarball name, and the published SHA256.

	Before	After
Release	v14.2.0-1	v14.3.0-1
GCC	14.2.0	14.3.0
SHA256	a5eb7075…6200	be1768ef…c726

No other hardening was needed here. Unlike the ARM step before #53, this job already verified its download with sha256sum --check --strict, which is why #53's checksum fix did not apply to it.

Verification

Installed xPack GNU RISC-V Embedded GCC 14.3.0 locally and ran the full pipeline by hand:

• Clean build of polarfire_icicle_demo.elf.
• Headless Renode suite passes, exit 0, with every startup self-test green — _sbrk bounds, the HWTimer catch-up clamp, PLIC Hart 1 configuration (IRQ 91 prio=1 en=0x08000000 thresh=0 mie=0x800), the queue round-trip, ThreadX ticks, the LM75 alarm, and the PLIC RX interrupt.
• Checksum verified against the value published in the release assets.

One pre-existing issue, deliberately not folded in

The build emits:

ld: warning: app/polarfire_icicle_demo.elf has a LOAD segment with RWX permissions

I checked whether the bump introduced it: it did not. The current pipeline on 14.2.0 emits the identical warning (visible in the run 33430244827 build log, from riscv-none-elf/14.2.0). It points at the PolarFire linker script placing writable and executable content in one segment, and deserves its own change rather than being buried in a version bump.

Follow-up worth considering

The xPack and Renode downloads still re-fetch on every run — roughly 400 MB and 200 MB respectively, the latter in two separate jobs. actions/cache, as #53 added for the ARM toolchain, would apply to all three.

[fdesbiens]

Pin the RISC-V toolchain to xPack GCC 14.3.0

Why

After #53 the ARM job pins Arm GNU Toolchain 14.3.Rel1, but the PolarFire job still pinned xPack riscv-none-elf-gcc14.2.0-1 — leaving the two cross-compilers in one pipeline a minor release apart for no reason. xPack published v14.3.0-1 on 2025-10-23, so both targets can sit on GCC 14.3 while still satisfying the AGENTS.md GCC 14 requirement.

What changed

One step, three values: the release tag, the tarball name, and the published SHA256.

	Before	After
Release	v14.2.0-1	v14.3.0-1
GCC	14.2.0	14.3.0
SHA256	a5eb7075…6200	be1768ef…c726

No other hardening was needed here. Unlike the ARM step before #53, this job already verified its download with sha256sum --check --strict, which is why #53's checksum fix did not apply to it.

Verification

Installed xPack GNU RISC-V Embedded GCC 14.3.0 locally and ran the full pipeline by hand:

• Clean build of polarfire_icicle_demo.elf.
• Headless Renode suite passes, exit 0, with every startup self-test green — _sbrk bounds, the HWTimer catch-up clamp, PLIC Hart 1 configuration (IRQ 91 prio=1 en=0x08000000 thresh=0 mie=0x800), the queue round-trip, ThreadX ticks, the LM75 alarm, and the PLIC RX interrupt.
• Checksum verified against the value published in the release assets.

One pre-existing issue, deliberately not folded in

The build emits:

ld: warning: app/polarfire_icicle_demo.elf has a LOAD segment with RWX permissions

I checked whether the bump introduced it: it did not. The current pipeline on 14.2.0 emits the identical warning (visible in the run 33430244827 build log, from riscv-none-elf/14.2.0). It points at the PolarFire linker script placing writable and executable content in one segment, and deserves its own change rather than being buried in a version bump.

Follow-up worth considering

The xPack and Renode downloads still re-fetch on every run — roughly 400 MB and 200 MB respectively, the latter in two separate jobs. actions/cache, as #53 added for the ARM toolchain, would apply to all three.

[fdesbiens]

Pin the RISC-V toolchain to xPack GCC 14.3.0

Why

After #53 the ARM job pins Arm GNU Toolchain 14.3.Rel1, but the PolarFire job still pinned xPack riscv-none-elf-gcc14.2.0-1 — leaving the two cross-compilers in one pipeline a minor release apart for no reason. xPack published v14.3.0-1 on 2025-10-23, so both targets can sit on GCC 14.3 while still satisfying the AGENTS.md GCC 14 requirement.

What changed

One step, three values: the release tag, the tarball name, and the published SHA256.

	Before	After
Release	v14.2.0-1	v14.3.0-1
GCC	14.2.0	14.3.0
SHA256	a5eb7075…6200	be1768ef…c726

No other hardening was needed here. Unlike the ARM step before #53, this job already verified its download with sha256sum --check --strict, which is why #53's checksum fix did not apply to it.

Verification

Installed xPack GNU RISC-V Embedded GCC 14.3.0 locally and ran the full pipeline by hand:

• Clean build of polarfire_icicle_demo.elf.
• Headless Renode suite passes, exit 0, with every startup self-test green — _sbrk bounds, the HWTimer catch-up clamp, PLIC Hart 1 configuration (IRQ 91 prio=1 en=0x08000000 thresh=0 mie=0x800), the queue round-trip, ThreadX ticks, the LM75 alarm, and the PLIC RX interrupt.
• Checksum verified against the value published in the release assets.

One pre-existing issue, deliberately not folded in

The build emits:

ld: warning: app/polarfire_icicle_demo.elf has a LOAD segment with RWX permissions

I checked whether the bump introduced it: it did not. The current pipeline on 14.2.0 emits the identical warning (visible in the run 33430244827 build log, from riscv-none-elf/14.2.0). It points at the PolarFire linker script placing writable and executable content in one segment, and deserves its own change rather than being buried in a version bump.

Follow-up worth considering

The xPack and Renode downloads still re-fetch on every run — roughly 400 MB and 200 MB respectively, the latter in two separate jobs. actions/cache, as #53 added for the ARM toolchain, would apply to all three.

[fdesbiens]

Pin the RISC-V toolchain to xPack GCC 14.3.0

Why

After #53 the ARM job pins Arm GNU Toolchain 14.3.Rel1, but the PolarFire job still pinned xPack riscv-none-elf-gcc14.2.0-1 — leaving the two cross-compilers in one pipeline a minor release apart for no reason. xPack published v14.3.0-1 on 2025-10-23, so both targets can sit on GCC 14.3 while still satisfying the AGENTS.md GCC 14 requirement.

What changed

One step, three values: the release tag, the tarball name, and the published SHA256.

	Before	After
Release	v14.2.0-1	v14.3.0-1
GCC	14.2.0	14.3.0
SHA256	a5eb7075…6200	be1768ef…c726

No other hardening was needed here. Unlike the ARM step before #53, this job already verified its download with sha256sum --check --strict, which is why #53's checksum fix did not apply to it.

Verification

Installed xPack GNU RISC-V Embedded GCC 14.3.0 locally and ran the full pipeline by hand:

• Clean build of polarfire_icicle_demo.elf.
• Headless Renode suite passes, exit 0, with every startup self-test green — _sbrk bounds, the HWTimer catch-up clamp, PLIC Hart 1 configuration (IRQ 91 prio=1 en=0x08000000 thresh=0 mie=0x800), the queue round-trip, ThreadX ticks, the LM75 alarm, and the PLIC RX interrupt.
• Checksum verified against the value published in the release assets.

One pre-existing issue, deliberately not folded in

The build emits:

ld: warning: app/polarfire_icicle_demo.elf has a LOAD segment with RWX permissions

I checked whether the bump introduced it: it did not. The current pipeline on 14.2.0 emits the identical warning (visible in the run 33430244827 build log, from riscv-none-elf/14.2.0). It points at the PolarFire linker script placing writable and executable content in one segment, and deserves its own change rather than being buried in a version bump.

Follow-up worth considering

The xPack and Renode downloads still re-fetch on every run — roughly 400 MB and 200 MB respectively, the latter in two separate jobs. actions/cache, as #53 added for the ARM toolchain, would apply to all three.