Skip to content

Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern - #53

Merged
fdesbiens merged 1 commit into
eclipse-threadx:devfrom
fdesbiens:fix/pin-arm-gcc-14.3
Aug 31, 2026
Merged

Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern#53
fdesbiens merged 1 commit into
eclipse-threadx:devfrom
fdesbiens:fix/pin-arm-gcc-14.3

Conversation

@fdesbiens

@fdesbiensfdesbiens commented Aug 31, 2026

Copy link
Copy Markdown
Contributor

Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern

Why

The ARM job pinned 14.2.Rel1, chosen only because it was the newest release I was aware of when #50 added the pin. eclipse-threadx/threadx already pins 14.3.rel1 in ci_cortex_m.yml for the Cortex-M ports — so samplex was lagging the flagship repository rather than choosing between two versions.

Both satisfy the AGENTS.md GCC 14 requirement. Matching threadx means a toolchain bump becomes one reviewable line in each repository instead of a per-repository decision.

What changed

The install steps now mirror ci_cortex_m.yml rather than paraphrasing it, which fixes three weaknesses in the version this replaces:

BeforeAfter
No integrity check on the archive at allsha256sum -c against the published .sha256asc
~150 MB downloaded on every runactions/cache keyed on the pinned version
wget -q, no version recordedcurl -fsSL (fails the step on HTTP errors) plus a step reporting the compiler version into the log

Version and target move into job env vars (GCC_VERSION, GCC_TARGET) using the same names threadx uses, so the two files stay diffable.

Validation record re-measured

14.2.114.3.1
ROM22068 B22064 B
RAM6000 B6000 B

The figures and the pin move together deliberately — letting them drift is what left a stale 15.2.1 measurement in this README before.

Verification

Locally under Arm GNU Toolchain 14.3.Rel1 (GCC 14.3.1 20250623):

  • Clean build with -Wall -Wshadow -Wdouble-promotion -Werror — the point release introduces no new diagnostics.
  • Headless Renode suite passes, exit 0, all seven startup self-tests green.
  • Confirmed both the archive and its .sha256asc return 200 from the pinned URL.

Not in scope

PolarFire's RISC-V toolchain stays on xPack 14.2.0 — a different vendor on a different release cadence, and AGENTS.md's GCC 14 requirement is satisfied. The xPack and Renode downloads in the other jobs could take the same caching and checksum treatment; worth a follow-up, but kept out of this change so the diff stays reviewable.

@fdesbiens
Pinned the Arm toolchain to 14.3.Rel1 and adopted the ThreadX install…
fbac0db
… pattern
The ARM job pinned 14.2.Rel1, chosen only because it was the newest release
at the time. eclipse-threadx/threadx already pins 14.3.rel1 in
ci_cortex_m.yml for the Cortex-M ports, so samplex was lagging the flagship
repository rather than choosing between two versions. Both satisfy the
AGENTS.md GCC 14 requirement; matching threadx means a toolchain bump is one
reviewable line in each repository instead of a per-repository decision.
The install steps now mirror ci_cortex_m.yml rather than paraphrasing it,
which fixes three weaknesses in the version this replaces:
- The archive was fetched with no integrity check at all. It is now
verified with sha256sum against the published .sha256asc.
- Roughly 150 MB was downloaded on every run. actions/cache, keyed on the
pinned version, now avoids that.
- wget -q hid transfer detail. curl -fsSL fails the step on an HTTP error,
and a new step reports the resulting compiler version so the log records
what actually built the ELF.
Version and target move into job env vars (GCC_VERSION, GCC_TARGET) using the
same names threadx uses, so the two files stay diffable and a future bump is
a one-line change.
Re-measured the NUCLEO validation record under the newly pinned compiler:
22064 B ROM, down 4 bytes from 14.2.1; RAM unchanged at 6000 B. The figures
and the pin move together deliberately, since letting them drift is what left
a stale 15.2.1 measurement in this file before.
Verified under Arm GNU Toolchain 14.3.Rel1: clean build with -Wall -Wshadow
-Wdouble-promotion -Werror, no new diagnostics from the point release, and
the headless Renode suite still passes with all seven startup self-tests.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
@fdesbiens
fdesbiens merged commit 1ff7ae1 into eclipse-threadx:devAug 31, 2026
5 checks passed
@fdesbiens
fdesbiens deleted the fix/pin-arm-gcc-14.3 branch August 31, 2026 19:25
This was referenced Aug 31, 2026
Merged
Merged
fdesbiens added a commit that referenced this pull request Aug 31, 2026
@fdesbiens
Pinned the NUCLEO Renode download and cached every toolchain fetch (#55)
bba3b91
Two problems in the pipeline, one of them mine.
The NUCLEO Renode job fetched renode-latest.linux-portable.tar.gz with no
version pin and no checksum, while the PolarFire job three jobs above it
already pinned Renode 1.16.1 and verified its SHA256. That pin landed in #49,
so it was present in this file when #51 added the NUCLEO job; the new job was
modelled on an older copy of the PolarFire step rather than the current one.
The result was a suite whose emulator could change under it on any Renode
release, with nothing verifying what was downloaded. The NUCLEO job now uses
the same pinned, checksum-verified step as PolarFire. The checksum was
recomputed from the published artefact rather than copied on trust.
Separately, every run re-downloaded roughly a gigabyte: the xPack RISC-V
toolchain at ~414 MB and Renode at ~52 MB in each of two jobs. All three are
now restored by actions/cache, keyed on the pinned version so a future bump
invalidates the cache instead of silently serving the old one. This completes
what #53 started for the Arm toolchain.
Caching only makes sense because these are now pinned. Caching an unpinned
"latest" artefact would have frozen CI on whichever build happened to be
fetched first, turning a reproducibility gap into an invisible one.
All four jobs now follow the same shape: cache, install only on a cache miss,
then put the tool on PATH as a separate step so it runs on hit and miss alike.
The PolarFire job also gains a version-reporting step, matching the Arm job, so
the log records which compiler produced the ELF.
Verified both constructed download URLs resolve, and that the Renode 1.16.1
checksum matches the published artefact.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@fdesbiens
, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all 
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern by fdesbiens · Pull Request #53 · eclipse-threadx/samplex · GitHub
Skip to content
Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern - #53
Merged
fdesbiens merged 1 commit into
eclipse-threadx:devfrom 
fdesbiens:fix/pin-arm-gcc-14.3
Aug 31, 2026
Merged
Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern#53
fdesbiens merged 1 commit into
eclipse-threadx:devfrom 
fdesbiens:fix/pin-arm-gcc-14.3
Conversation
@fdesbiens
@fdesbiensfdesbiens
commented
Aug 31, 2026

Copy link


Copy Markdown

Contributor
Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern
Why
The ARM job pinned 14.2.Rel1, chosen only because it was the newest release I was aware of when #50 added the pin. eclipse-threadx/threadx already pins 14.3.rel1 in ci_cortex_m.yml for the Cortex-M ports — so samplex was lagging the flagship repository rather than choosing between two versions.
Both satisfy the AGENTS.md GCC 14 requirement. Matching threadx means a toolchain bump becomes one reviewable line in each repository instead of a per-repository decision.
What changed
The install steps now mirror ci_cortex_m.yml rather than paraphrasing it, which fixes three weaknesses in the version this replaces:
BeforeAfter
No integrity check on the archive at allsha256sum -c against the published .sha256asc
~150 MB downloaded on every runactions/cache keyed on the pinned version
wget -q, no version recordedcurl -fsSL (fails the step on HTTP errors) plus a step reporting the compiler version into the log
Version and target move into job env vars (GCC_VERSION, GCC_TARGET) using the same names threadx uses, so the two files stay diffable.
Validation record re-measured
14.2.114.3.1
ROM22068 B22064 B
RAM6000 B6000 B
The figures and the pin move together deliberately — letting them drift is what left a stale 15.2.1 measurement in this README before.
Verification
Locally under Arm GNU Toolchain 14.3.Rel1 (GCC 14.3.1 20250623):
  • Clean build with -Wall -Wshadow -Wdouble-promotion -Werror — the point release introduces no new diagnostics.
  • Headless Renode suite passes, exit 0, all seven startup self-tests green.
  • Confirmed both the archive and its .sha256asc return 200 from the pinned URL.
Not in scope
PolarFire's RISC-V toolchain stays on xPack 14.2.0 — a different vendor on a different release cadence, and AGENTS.md's GCC 14 requirement is satisfied. The xPack and Renode downloads in the other jobs could take the same caching and checksum treatment; worth a follow-up, but kept out of this change so the diff stays reviewable.
@fdesbiens
Pinned the Arm toolchain to 14.3.Rel1 and adopted the ThreadX install…
fbac0db
… pattern
The ARM job pinned 14.2.Rel1, chosen only because it was the newest release
at the time. eclipse-threadx/threadx already pins 14.3.rel1 in
ci_cortex_m.yml for the Cortex-M ports, so samplex was lagging the flagship
repository rather than choosing between two versions. Both satisfy the
AGENTS.md GCC 14 requirement; matching threadx means a toolchain bump is one
reviewable line in each repository instead of a per-repository decision.
The install steps now mirror ci_cortex_m.yml rather than paraphrasing it,
which fixes three weaknesses in the version this replaces:
- The archive was fetched with no integrity check at all. It is now
verified with sha256sum against the published .sha256asc.
- Roughly 150 MB was downloaded on every run. actions/cache, keyed on the
pinned version, now avoids that.
- wget -q hid transfer detail. curl -fsSL fails the step on an HTTP error,
and a new step reports the resulting compiler version so the log records
what actually built the ELF.
Version and target move into job env vars (GCC_VERSION, GCC_TARGET) using the
same names threadx uses, so the two files stay diffable and a future bump is
a one-line change.
Re-measured the NUCLEO validation record under the newly pinned compiler:
22064 B ROM, down 4 bytes from 14.2.1; RAM unchanged at 6000 B. The figures
and the pin move together deliberately, since letting them drift is what left
a stale 15.2.1 measurement in this file before.
Verified under Arm GNU Toolchain 14.3.Rel1: clean build with -Wall -Wshadow
-Wdouble-promotion -Werror, no new diagnostics from the point release, and
the headless Renode suite still passes with all seven startup self-tests.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
@fdesbiens
fdesbiens
merged commit 1ff7ae1
into
eclipse-threadx:devAug 31, 2026

5 checks passed

@fdesbiens
fdesbiens
deleted the

fix/pin-arm-gcc-14.3

branch
August 31, 2026 19:25

This was referenced Aug 31, 2026
 Merged

 Merged

fdesbiens added a commit
that referenced
this pull request
Aug 31, 2026
@fdesbiens
Pinned the NUCLEO Renode download and cached every toolchain fetch (#55)
bba3b91
Two problems in the pipeline, one of them mine.
The NUCLEO Renode job fetched renode-latest.linux-portable.tar.gz with no
version pin and no checksum, while the PolarFire job three jobs above it
already pinned Renode 1.16.1 and verified its SHA256. That pin landed in #49,
so it was present in this file when #51 added the NUCLEO job; the new job was
modelled on an older copy of the PolarFire step rather than the current one.
The result was a suite whose emulator could change under it on any Renode
release, with nothing verifying what was downloaded. The NUCLEO job now uses
the same pinned, checksum-verified step as PolarFire. The checksum was
recomputed from the published artefact rather than copied on trust.
Separately, every run re-downloaded roughly a gigabyte: the xPack RISC-V
toolchain at ~414 MB and Renode at ~52 MB in each of two jobs. All three are
now restored by actions/cache, keyed on the pinned version so a future bump
invalidates the cache instead of silently serving the old one. This completes
what #53 started for the Arm toolchain.
Caching only makes sense because these are now pinned. Caching an unpinned
"latest" artefact would have frozen CI on whichever build happened to be
fetched first, turning a reproducibility gap into an invisible one.
All four jobs now follow the same shape: cache, install only on a cache miss,
then put the tool on PATH as a separate step so it runs on hit and miss alike.
The PolarFire job also gains a version-reporting step, matching the Arm job, so
the log records which compiler produced the ELF.
Verified both constructed download URLs resolve, and that the Renode 1.16.1
checksum matches the published artefact.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@fdesbiens

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Force GitHub README to respect dark mode
(function() {
var style = document.createElement('style');
style.textContent = '
.markdown-body {
color-scheme: dark light;
}
.markdown-body pre { background: #161b22 !important; }
.markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }
.markdown-body table th, .markdown-body table td { border-color: #30363d !important; }
.markdown-body img { background: #0d1117; }
.markdown-body blockquote { border-left-color: #8b949e; }
.markdown-body hr { border-color: #30363d; }
';
document.head.appendChild(style);
})();
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern by fdesbiens · Pull Request #53 · eclipse-threadx/samplex · GitHub
Skip to content
Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern - #53
Merged
fdesbiens merged 1 commit into
eclipse-threadx:devfrom 
fdesbiens:fix/pin-arm-gcc-14.3
Aug 31, 2026
Merged
Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern#53
fdesbiens merged 1 commit into
eclipse-threadx:devfrom 
fdesbiens:fix/pin-arm-gcc-14.3
Conversation
@fdesbiens
@fdesbiensfdesbiens
commented
Aug 31, 2026

Copy link


Copy Markdown

Contributor
Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern
Why
The ARM job pinned 14.2.Rel1, chosen only because it was the newest release I was aware of when #50 added the pin. eclipse-threadx/threadx already pins 14.3.rel1 in ci_cortex_m.yml for the Cortex-M ports — so samplex was lagging the flagship repository rather than choosing between two versions.
Both satisfy the AGENTS.md GCC 14 requirement. Matching threadx means a toolchain bump becomes one reviewable line in each repository instead of a per-repository decision.
What changed
The install steps now mirror ci_cortex_m.yml rather than paraphrasing it, which fixes three weaknesses in the version this replaces:
BeforeAfter
No integrity check on the archive at allsha256sum -c against the published .sha256asc
~150 MB downloaded on every runactions/cache keyed on the pinned version
wget -q, no version recordedcurl -fsSL (fails the step on HTTP errors) plus a step reporting the compiler version into the log
Version and target move into job env vars (GCC_VERSION, GCC_TARGET) using the same names threadx uses, so the two files stay diffable.
Validation record re-measured
14.2.114.3.1
ROM22068 B22064 B
RAM6000 B6000 B
The figures and the pin move together deliberately — letting them drift is what left a stale 15.2.1 measurement in this README before.
Verification
Locally under Arm GNU Toolchain 14.3.Rel1 (GCC 14.3.1 20250623):
  • Clean build with -Wall -Wshadow -Wdouble-promotion -Werror — the point release introduces no new diagnostics.
  • Headless Renode suite passes, exit 0, all seven startup self-tests green.
  • Confirmed both the archive and its .sha256asc return 200 from the pinned URL.
Not in scope
PolarFire's RISC-V toolchain stays on xPack 14.2.0 — a different vendor on a different release cadence, and AGENTS.md's GCC 14 requirement is satisfied. The xPack and Renode downloads in the other jobs could take the same caching and checksum treatment; worth a follow-up, but kept out of this change so the diff stays reviewable.
@fdesbiens
Pinned the Arm toolchain to 14.3.Rel1 and adopted the ThreadX install…
fbac0db
… pattern
The ARM job pinned 14.2.Rel1, chosen only because it was the newest release
at the time. eclipse-threadx/threadx already pins 14.3.rel1 in
ci_cortex_m.yml for the Cortex-M ports, so samplex was lagging the flagship
repository rather than choosing between two versions. Both satisfy the
AGENTS.md GCC 14 requirement; matching threadx means a toolchain bump is one
reviewable line in each repository instead of a per-repository decision.
The install steps now mirror ci_cortex_m.yml rather than paraphrasing it,
which fixes three weaknesses in the version this replaces:
- The archive was fetched with no integrity check at all. It is now
verified with sha256sum against the published .sha256asc.
- Roughly 150 MB was downloaded on every run. actions/cache, keyed on the
pinned version, now avoids that.
- wget -q hid transfer detail. curl -fsSL fails the step on an HTTP error,
and a new step reports the resulting compiler version so the log records
what actually built the ELF.
Version and target move into job env vars (GCC_VERSION, GCC_TARGET) using the
same names threadx uses, so the two files stay diffable and a future bump is
a one-line change.
Re-measured the NUCLEO validation record under the newly pinned compiler:
22064 B ROM, down 4 bytes from 14.2.1; RAM unchanged at 6000 B. The figures
and the pin move together deliberately, since letting them drift is what left
a stale 15.2.1 measurement in this file before.
Verified under Arm GNU Toolchain 14.3.Rel1: clean build with -Wall -Wshadow
-Wdouble-promotion -Werror, no new diagnostics from the point release, and
the headless Renode suite still passes with all seven startup self-tests.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
@fdesbiens
fdesbiens
merged commit 1ff7ae1
into
eclipse-threadx:devAug 31, 2026

5 checks passed

@fdesbiens
fdesbiens
deleted the

fix/pin-arm-gcc-14.3

branch
August 31, 2026 19:25

This was referenced Aug 31, 2026
 Merged

 Merged

fdesbiens added a commit
that referenced
this pull request
Aug 31, 2026
@fdesbiens
Pinned the NUCLEO Renode download and cached every toolchain fetch (#55)
bba3b91
Two problems in the pipeline, one of them mine.
The NUCLEO Renode job fetched renode-latest.linux-portable.tar.gz with no
version pin and no checksum, while the PolarFire job three jobs above it
already pinned Renode 1.16.1 and verified its SHA256. That pin landed in #49,
so it was present in this file when #51 added the NUCLEO job; the new job was
modelled on an older copy of the PolarFire step rather than the current one.
The result was a suite whose emulator could change under it on any Renode
release, with nothing verifying what was downloaded. The NUCLEO job now uses
the same pinned, checksum-verified step as PolarFire. The checksum was
recomputed from the published artefact rather than copied on trust.
Separately, every run re-downloaded roughly a gigabyte: the xPack RISC-V
toolchain at ~414 MB and Renode at ~52 MB in each of two jobs. All three are
now restored by actions/cache, keyed on the pinned version so a future bump
invalidates the cache instead of silently serving the old one. This completes
what #53 started for the Arm toolchain.
Caching only makes sense because these are now pinned. Caching an unpinned
"latest" artefact would have frozen CI on whichever build happened to be
fetched first, turning a reproducibility gap into an invisible one.
All four jobs now follow the same shape: cache, install only on a cache miss,
then put the tool on PATH as a separate step so it runs on hit and miss alike.
The PolarFire job also gains a version-reporting step, matching the Arm job, so
the log records which compiler produced the ELF.
Verified both constructed download URLs resolve, and that the Renode 1.16.1
checksum matches the published artefact.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@fdesbiens

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Highlight search terms from Google/DuckDuckGo/Bing referrer
(function() {
var ref = document.referrer;
var terms = [];
if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {
var url = new URL(ref);
var q = url.searchParams.get('q') || url.searchParams.get('p');
if (q) {
terms = q.split(/\s+/).filter(function(t) { return t.length > 2; });
}
}
if (terms.length === 0) return;
var style = document.createElement('style');
style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';
document.head.appendChild(style);
function highlight(node) {
if (node.nodeType === 3) { // text node
var text = node.textContent;
var found = false;
terms.forEach(function(term) {
var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi');
if (regex.test(text)) {
found = true;
var frag = document.createDocumentFragment();
var parts = text.split(regex);
parts.forEach(function(part, i) {
if (i % 2 === 0) {
frag.appendChild(document.createTextNode(part));
} else {
var span = document.createElement('span');
span.className = 'userscript-highlight';
span.textContent = part;
frag.appendChild(span);
}
});
node.parentNode.replaceChild(frag, node);
}
});
} else if (node.nodeType === 1 && node.childNodes) { // element
var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];
if (!skipTags.includes(node.tagName)) {
Array.from(node.childNodes).forEach(highlight);
}
}
}
highlight(document.body);
// Re-highlight on dynamic content
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1 || node.nodeType === 3) highlight(node);
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern by fdesbiens · Pull Request #53 · eclipse-threadx/samplex · GitHub
Skip to content
Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern - #53
Merged
fdesbiens merged 1 commit into
eclipse-threadx:devfrom 
fdesbiens:fix/pin-arm-gcc-14.3
Aug 31, 2026
Merged
Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern#53
fdesbiens merged 1 commit into
eclipse-threadx:devfrom 
fdesbiens:fix/pin-arm-gcc-14.3
Conversation
@fdesbiens
@fdesbiensfdesbiens
commented
Aug 31, 2026

Copy link


Copy Markdown

Contributor
Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern
Why
The ARM job pinned 14.2.Rel1, chosen only because it was the newest release I was aware of when #50 added the pin. eclipse-threadx/threadx already pins 14.3.rel1 in ci_cortex_m.yml for the Cortex-M ports — so samplex was lagging the flagship repository rather than choosing between two versions.
Both satisfy the AGENTS.md GCC 14 requirement. Matching threadx means a toolchain bump becomes one reviewable line in each repository instead of a per-repository decision.
What changed
The install steps now mirror ci_cortex_m.yml rather than paraphrasing it, which fixes three weaknesses in the version this replaces:
BeforeAfter
No integrity check on the archive at allsha256sum -c against the published .sha256asc
~150 MB downloaded on every runactions/cache keyed on the pinned version
wget -q, no version recordedcurl -fsSL (fails the step on HTTP errors) plus a step reporting the compiler version into the log
Version and target move into job env vars (GCC_VERSION, GCC_TARGET) using the same names threadx uses, so the two files stay diffable.
Validation record re-measured
14.2.114.3.1
ROM22068 B22064 B
RAM6000 B6000 B
The figures and the pin move together deliberately — letting them drift is what left a stale 15.2.1 measurement in this README before.
Verification
Locally under Arm GNU Toolchain 14.3.Rel1 (GCC 14.3.1 20250623):
  • Clean build with -Wall -Wshadow -Wdouble-promotion -Werror — the point release introduces no new diagnostics.
  • Headless Renode suite passes, exit 0, all seven startup self-tests green.
  • Confirmed both the archive and its .sha256asc return 200 from the pinned URL.
Not in scope
PolarFire's RISC-V toolchain stays on xPack 14.2.0 — a different vendor on a different release cadence, and AGENTS.md's GCC 14 requirement is satisfied. The xPack and Renode downloads in the other jobs could take the same caching and checksum treatment; worth a follow-up, but kept out of this change so the diff stays reviewable.
@fdesbiens
Pinned the Arm toolchain to 14.3.Rel1 and adopted the ThreadX install…
fbac0db
… pattern
The ARM job pinned 14.2.Rel1, chosen only because it was the newest release
at the time. eclipse-threadx/threadx already pins 14.3.rel1 in
ci_cortex_m.yml for the Cortex-M ports, so samplex was lagging the flagship
repository rather than choosing between two versions. Both satisfy the
AGENTS.md GCC 14 requirement; matching threadx means a toolchain bump is one
reviewable line in each repository instead of a per-repository decision.
The install steps now mirror ci_cortex_m.yml rather than paraphrasing it,
which fixes three weaknesses in the version this replaces:
- The archive was fetched with no integrity check at all. It is now
verified with sha256sum against the published .sha256asc.
- Roughly 150 MB was downloaded on every run. actions/cache, keyed on the
pinned version, now avoids that.
- wget -q hid transfer detail. curl -fsSL fails the step on an HTTP error,
and a new step reports the resulting compiler version so the log records
what actually built the ELF.
Version and target move into job env vars (GCC_VERSION, GCC_TARGET) using the
same names threadx uses, so the two files stay diffable and a future bump is
a one-line change.
Re-measured the NUCLEO validation record under the newly pinned compiler:
22064 B ROM, down 4 bytes from 14.2.1; RAM unchanged at 6000 B. The figures
and the pin move together deliberately, since letting them drift is what left
a stale 15.2.1 measurement in this file before.
Verified under Arm GNU Toolchain 14.3.Rel1: clean build with -Wall -Wshadow
-Wdouble-promotion -Werror, no new diagnostics from the point release, and
the headless Renode suite still passes with all seven startup self-tests.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
@fdesbiens
fdesbiens
merged commit 1ff7ae1
into
eclipse-threadx:devAug 31, 2026

5 checks passed

@fdesbiens
fdesbiens
deleted the

fix/pin-arm-gcc-14.3

branch
August 31, 2026 19:25

This was referenced Aug 31, 2026
 Merged

 Merged

fdesbiens added a commit
that referenced
this pull request
Aug 31, 2026
@fdesbiens
Pinned the NUCLEO Renode download and cached every toolchain fetch (#55)
bba3b91
Two problems in the pipeline, one of them mine.
The NUCLEO Renode job fetched renode-latest.linux-portable.tar.gz with no
version pin and no checksum, while the PolarFire job three jobs above it
already pinned Renode 1.16.1 and verified its SHA256. That pin landed in #49,
so it was present in this file when #51 added the NUCLEO job; the new job was
modelled on an older copy of the PolarFire step rather than the current one.
The result was a suite whose emulator could change under it on any Renode
release, with nothing verifying what was downloaded. The NUCLEO job now uses
the same pinned, checksum-verified step as PolarFire. The checksum was
recomputed from the published artefact rather than copied on trust.
Separately, every run re-downloaded roughly a gigabyte: the xPack RISC-V
toolchain at ~414 MB and Renode at ~52 MB in each of two jobs. All three are
now restored by actions/cache, keyed on the pinned version so a future bump
invalidates the cache instead of silently serving the old one. This completes
what #53 started for the Arm toolchain.
Caching only makes sense because these are now pinned. Caching an unpinned
"latest" artefact would have frozen CI on whichever build happened to be
fetched first, turning a reproducibility gap into an invisible one.
All four jobs now follow the same shape: cache, install only on a cache miss,
then put the tool on PATH as a separate step so it runs on hit and miss alike.
The PolarFire job also gains a version-reporting step, matching the Arm job, so
the log records which compiler produced the ELF.
Verified both constructed download URLs resolve, and that the Renode 1.16.1
checksum matches the published artefact.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@fdesbiens

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Strip utm_, fbclid, gclid, etc. from all links on page
(function() {
var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',
'ref', 'ref_src', 'source', 'medium', 'campaign'];
function cleanUrl(url) {
try {
var u = new URL(url, window.location.origin);
var changed = false;
trackingParams.forEach(function(p) {
if (u.searchParams.has(p)) {
u.searchParams.delete(p);
changed = true;
}
});
return changed ? u.toString() : url;
} catch (e) {
return url;
}
}
function cleanLinks() {
document.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
cleanLinks();
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1) {
if (node.tagName === 'A') cleanLinks();
node.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '
Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern by fdesbiens · Pull Request #53 · eclipse-threadx/samplex · GitHub
Skip to content
Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern - #53
Merged
fdesbiens merged 1 commit into
eclipse-threadx:devfrom 
fdesbiens:fix/pin-arm-gcc-14.3
Aug 31, 2026
Merged
Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern#53
fdesbiens merged 1 commit into
eclipse-threadx:devfrom 
fdesbiens:fix/pin-arm-gcc-14.3
Conversation
@fdesbiens
@fdesbiensfdesbiens
commented
Aug 31, 2026

Copy link


Copy Markdown

Contributor
Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern
Why
The ARM job pinned 14.2.Rel1, chosen only because it was the newest release I was aware of when #50 added the pin. eclipse-threadx/threadx already pins 14.3.rel1 in ci_cortex_m.yml for the Cortex-M ports — so samplex was lagging the flagship repository rather than choosing between two versions.
Both satisfy the AGENTS.md GCC 14 requirement. Matching threadx means a toolchain bump becomes one reviewable line in each repository instead of a per-repository decision.
What changed
The install steps now mirror ci_cortex_m.yml rather than paraphrasing it, which fixes three weaknesses in the version this replaces:
BeforeAfter
No integrity check on the archive at allsha256sum -c against the published .sha256asc
~150 MB downloaded on every runactions/cache keyed on the pinned version
wget -q, no version recordedcurl -fsSL (fails the step on HTTP errors) plus a step reporting the compiler version into the log
Version and target move into job env vars (GCC_VERSION, GCC_TARGET) using the same names threadx uses, so the two files stay diffable.
Validation record re-measured
14.2.114.3.1
ROM22068 B22064 B
RAM6000 B6000 B
The figures and the pin move together deliberately — letting them drift is what left a stale 15.2.1 measurement in this README before.
Verification
Locally under Arm GNU Toolchain 14.3.Rel1 (GCC 14.3.1 20250623):
  • Clean build with -Wall -Wshadow -Wdouble-promotion -Werror — the point release introduces no new diagnostics.
  • Headless Renode suite passes, exit 0, all seven startup self-tests green.
  • Confirmed both the archive and its .sha256asc return 200 from the pinned URL.
Not in scope
PolarFire's RISC-V toolchain stays on xPack 14.2.0 — a different vendor on a different release cadence, and AGENTS.md's GCC 14 requirement is satisfied. The xPack and Renode downloads in the other jobs could take the same caching and checksum treatment; worth a follow-up, but kept out of this change so the diff stays reviewable.
@fdesbiens
Pinned the Arm toolchain to 14.3.Rel1 and adopted the ThreadX install…
fbac0db
… pattern
The ARM job pinned 14.2.Rel1, chosen only because it was the newest release
at the time. eclipse-threadx/threadx already pins 14.3.rel1 in
ci_cortex_m.yml for the Cortex-M ports, so samplex was lagging the flagship
repository rather than choosing between two versions. Both satisfy the
AGENTS.md GCC 14 requirement; matching threadx means a toolchain bump is one
reviewable line in each repository instead of a per-repository decision.
The install steps now mirror ci_cortex_m.yml rather than paraphrasing it,
which fixes three weaknesses in the version this replaces:
- The archive was fetched with no integrity check at all. It is now
verified with sha256sum against the published .sha256asc.
- Roughly 150 MB was downloaded on every run. actions/cache, keyed on the
pinned version, now avoids that.
- wget -q hid transfer detail. curl -fsSL fails the step on an HTTP error,
and a new step reports the resulting compiler version so the log records
what actually built the ELF.
Version and target move into job env vars (GCC_VERSION, GCC_TARGET) using the
same names threadx uses, so the two files stay diffable and a future bump is
a one-line change.
Re-measured the NUCLEO validation record under the newly pinned compiler:
22064 B ROM, down 4 bytes from 14.2.1; RAM unchanged at 6000 B. The figures
and the pin move together deliberately, since letting them drift is what left
a stale 15.2.1 measurement in this file before.
Verified under Arm GNU Toolchain 14.3.Rel1: clean build with -Wall -Wshadow
-Wdouble-promotion -Werror, no new diagnostics from the point release, and
the headless Renode suite still passes with all seven startup self-tests.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
@fdesbiens
fdesbiens
merged commit 1ff7ae1
into
eclipse-threadx:devAug 31, 2026

5 checks passed

@fdesbiens
fdesbiens
deleted the

fix/pin-arm-gcc-14.3

branch
August 31, 2026 19:25

This was referenced Aug 31, 2026
 Merged

 Merged

fdesbiens added a commit
that referenced
this pull request
Aug 31, 2026
@fdesbiens
Pinned the NUCLEO Renode download and cached every toolchain fetch (#55)
bba3b91
Two problems in the pipeline, one of them mine.
The NUCLEO Renode job fetched renode-latest.linux-portable.tar.gz with no
version pin and no checksum, while the PolarFire job three jobs above it
already pinned Renode 1.16.1 and verified its SHA256. That pin landed in #49,
so it was present in this file when #51 added the NUCLEO job; the new job was
modelled on an older copy of the PolarFire step rather than the current one.
The result was a suite whose emulator could change under it on any Renode
release, with nothing verifying what was downloaded. The NUCLEO job now uses
the same pinned, checksum-verified step as PolarFire. The checksum was
recomputed from the published artefact rather than copied on trust.
Separately, every run re-downloaded roughly a gigabyte: the xPack RISC-V
toolchain at ~414 MB and Renode at ~52 MB in each of two jobs. All three are
now restored by actions/cache, keyed on the pinned version so a future bump
invalidates the cache instead of silently serving the old one. This completes
what #53 started for the Arm toolchain.
Caching only makes sense because these are now pinned. Caching an unpinned
"latest" artefact would have frozen CI on whichever build happened to be
fetched first, turning a reproducibility gap into an invisible one.
All four jobs now follow the same shape: cache, install only on a cache miss,
then put the tool on PATH as a separate step so it runs on hit and miss alike.
The PolarFire job also gains a version-reporting step, matching the Arm job, so
the log records which compiler produced the ELF.
Verified both constructed download URLs resolve, and that the Renode 1.16.1
checksum matches the published artefact.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@fdesbiens

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Auto-enable theater mode on YouTube
(function() {
function tryTheater() {
var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]');
if (btn && !btn.classList.contains('activated')) {
btn.click();
}
}
// Try immediately
tryTheater();
// Try after navigation (SPA)
var lastUrl = location.href;
setInterval(function() {
if (location.href !== lastUrl) {
lastUrl = location.href;
setTimeout(tryTheater, 500);
}
}, 1000);
// Also try on player load
var observer = new MutationObserver(tryTheater);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern by fdesbiens · Pull Request #53 · eclipse-threadx/samplex · GitHub
Skip to content
Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern - #53
Merged
fdesbiens merged 1 commit into
eclipse-threadx:devfrom 
fdesbiens:fix/pin-arm-gcc-14.3
Aug 31, 2026
Merged
Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern#53
fdesbiens merged 1 commit into
eclipse-threadx:devfrom 
fdesbiens:fix/pin-arm-gcc-14.3
Conversation
@fdesbiens
@fdesbiensfdesbiens
commented
Aug 31, 2026

Copy link


Copy Markdown

Contributor
Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern
Why
The ARM job pinned 14.2.Rel1, chosen only because it was the newest release I was aware of when #50 added the pin. eclipse-threadx/threadx already pins 14.3.rel1 in ci_cortex_m.yml for the Cortex-M ports — so samplex was lagging the flagship repository rather than choosing between two versions.
Both satisfy the AGENTS.md GCC 14 requirement. Matching threadx means a toolchain bump becomes one reviewable line in each repository instead of a per-repository decision.
What changed
The install steps now mirror ci_cortex_m.yml rather than paraphrasing it, which fixes three weaknesses in the version this replaces:
BeforeAfter
No integrity check on the archive at allsha256sum -c against the published .sha256asc
~150 MB downloaded on every runactions/cache keyed on the pinned version
wget -q, no version recordedcurl -fsSL (fails the step on HTTP errors) plus a step reporting the compiler version into the log
Version and target move into job env vars (GCC_VERSION, GCC_TARGET) using the same names threadx uses, so the two files stay diffable.
Validation record re-measured
14.2.114.3.1
ROM22068 B22064 B
RAM6000 B6000 B
The figures and the pin move together deliberately — letting them drift is what left a stale 15.2.1 measurement in this README before.
Verification
Locally under Arm GNU Toolchain 14.3.Rel1 (GCC 14.3.1 20250623):
  • Clean build with -Wall -Wshadow -Wdouble-promotion -Werror — the point release introduces no new diagnostics.
  • Headless Renode suite passes, exit 0, all seven startup self-tests green.
  • Confirmed both the archive and its .sha256asc return 200 from the pinned URL.
Not in scope
PolarFire's RISC-V toolchain stays on xPack 14.2.0 — a different vendor on a different release cadence, and AGENTS.md's GCC 14 requirement is satisfied. The xPack and Renode downloads in the other jobs could take the same caching and checksum treatment; worth a follow-up, but kept out of this change so the diff stays reviewable.
@fdesbiens
Pinned the Arm toolchain to 14.3.Rel1 and adopted the ThreadX install…
fbac0db
… pattern
The ARM job pinned 14.2.Rel1, chosen only because it was the newest release
at the time. eclipse-threadx/threadx already pins 14.3.rel1 in
ci_cortex_m.yml for the Cortex-M ports, so samplex was lagging the flagship
repository rather than choosing between two versions. Both satisfy the
AGENTS.md GCC 14 requirement; matching threadx means a toolchain bump is one
reviewable line in each repository instead of a per-repository decision.
The install steps now mirror ci_cortex_m.yml rather than paraphrasing it,
which fixes three weaknesses in the version this replaces:
- The archive was fetched with no integrity check at all. It is now
verified with sha256sum against the published .sha256asc.
- Roughly 150 MB was downloaded on every run. actions/cache, keyed on the
pinned version, now avoids that.
- wget -q hid transfer detail. curl -fsSL fails the step on an HTTP error,
and a new step reports the resulting compiler version so the log records
what actually built the ELF.
Version and target move into job env vars (GCC_VERSION, GCC_TARGET) using the
same names threadx uses, so the two files stay diffable and a future bump is
a one-line change.
Re-measured the NUCLEO validation record under the newly pinned compiler:
22064 B ROM, down 4 bytes from 14.2.1; RAM unchanged at 6000 B. The figures
and the pin move together deliberately, since letting them drift is what left
a stale 15.2.1 measurement in this file before.
Verified under Arm GNU Toolchain 14.3.Rel1: clean build with -Wall -Wshadow
-Wdouble-promotion -Werror, no new diagnostics from the point release, and
the headless Renode suite still passes with all seven startup self-tests.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
@fdesbiens
fdesbiens
merged commit 1ff7ae1
into
eclipse-threadx:devAug 31, 2026

5 checks passed

@fdesbiens
fdesbiens
deleted the

fix/pin-arm-gcc-14.3

branch
August 31, 2026 19:25

This was referenced Aug 31, 2026
 Merged

 Merged

fdesbiens added a commit
that referenced
this pull request
Aug 31, 2026
@fdesbiens
Pinned the NUCLEO Renode download and cached every toolchain fetch (#55)
bba3b91
Two problems in the pipeline, one of them mine.
The NUCLEO Renode job fetched renode-latest.linux-portable.tar.gz with no
version pin and no checksum, while the PolarFire job three jobs above it
already pinned Renode 1.16.1 and verified its SHA256. That pin landed in #49,
so it was present in this file when #51 added the NUCLEO job; the new job was
modelled on an older copy of the PolarFire step rather than the current one.
The result was a suite whose emulator could change under it on any Renode
release, with nothing verifying what was downloaded. The NUCLEO job now uses
the same pinned, checksum-verified step as PolarFire. The checksum was
recomputed from the published artefact rather than copied on trust.
Separately, every run re-downloaded roughly a gigabyte: the xPack RISC-V
toolchain at ~414 MB and Renode at ~52 MB in each of two jobs. All three are
now restored by actions/cache, keyed on the pinned version so a future bump
invalidates the cache instead of silently serving the old one. This completes
what #53 started for the Arm toolchain.
Caching only makes sense because these are now pinned. Caching an unpinned
"latest" artefact would have frozen CI on whichever build happened to be
fetched first, turning a reproducibility gap into an invisible one.
All four jobs now follow the same shape: cache, install only on a cache miss,
then put the tool on PATH as a separate step so it runs on hit and miss alike.
The PolarFire job also gains a version-reporting step, matching the Arm job, so
the log records which compiler produced the ELF.
Verified both constructed download URLs resolve, and that the Renode 1.16.1
checksum matches the published artefact.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@fdesbiens

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Remove or un-stick sticky/fixed headers that block content
(function() {
function unstick() {
document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) {
if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {
el.style.position = 'static';
el.style.top = 'auto';
el.style.zIndex = 'auto';
}
});
}
unstick();
var observer = new MutationObserver(unstick);
observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });
})();
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern by fdesbiens · Pull Request #53 · eclipse-threadx/samplex · GitHub
Skip to content
Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern - #53
Merged
fdesbiens merged 1 commit into
eclipse-threadx:devfrom 
fdesbiens:fix/pin-arm-gcc-14.3
Aug 31, 2026
Merged
Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern#53
fdesbiens merged 1 commit into
eclipse-threadx:devfrom 
fdesbiens:fix/pin-arm-gcc-14.3
Conversation
@fdesbiens
@fdesbiensfdesbiens
commented
Aug 31, 2026

Copy link


Copy Markdown

Contributor
Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern
Why
The ARM job pinned 14.2.Rel1, chosen only because it was the newest release I was aware of when #50 added the pin. eclipse-threadx/threadx already pins 14.3.rel1 in ci_cortex_m.yml for the Cortex-M ports — so samplex was lagging the flagship repository rather than choosing between two versions.
Both satisfy the AGENTS.md GCC 14 requirement. Matching threadx means a toolchain bump becomes one reviewable line in each repository instead of a per-repository decision.
What changed
The install steps now mirror ci_cortex_m.yml rather than paraphrasing it, which fixes three weaknesses in the version this replaces:
BeforeAfter
No integrity check on the archive at allsha256sum -c against the published .sha256asc
~150 MB downloaded on every runactions/cache keyed on the pinned version
wget -q, no version recordedcurl -fsSL (fails the step on HTTP errors) plus a step reporting the compiler version into the log
Version and target move into job env vars (GCC_VERSION, GCC_TARGET) using the same names threadx uses, so the two files stay diffable.
Validation record re-measured
14.2.114.3.1
ROM22068 B22064 B
RAM6000 B6000 B
The figures and the pin move together deliberately — letting them drift is what left a stale 15.2.1 measurement in this README before.
Verification
Locally under Arm GNU Toolchain 14.3.Rel1 (GCC 14.3.1 20250623):
  • Clean build with -Wall -Wshadow -Wdouble-promotion -Werror — the point release introduces no new diagnostics.
  • Headless Renode suite passes, exit 0, all seven startup self-tests green.
  • Confirmed both the archive and its .sha256asc return 200 from the pinned URL.
Not in scope
PolarFire's RISC-V toolchain stays on xPack 14.2.0 — a different vendor on a different release cadence, and AGENTS.md's GCC 14 requirement is satisfied. The xPack and Renode downloads in the other jobs could take the same caching and checksum treatment; worth a follow-up, but kept out of this change so the diff stays reviewable.
@fdesbiens
Pinned the Arm toolchain to 14.3.Rel1 and adopted the ThreadX install…
fbac0db
… pattern
The ARM job pinned 14.2.Rel1, chosen only because it was the newest release
at the time. eclipse-threadx/threadx already pins 14.3.rel1 in
ci_cortex_m.yml for the Cortex-M ports, so samplex was lagging the flagship
repository rather than choosing between two versions. Both satisfy the
AGENTS.md GCC 14 requirement; matching threadx means a toolchain bump is one
reviewable line in each repository instead of a per-repository decision.
The install steps now mirror ci_cortex_m.yml rather than paraphrasing it,
which fixes three weaknesses in the version this replaces:
- The archive was fetched with no integrity check at all. It is now
verified with sha256sum against the published .sha256asc.
- Roughly 150 MB was downloaded on every run. actions/cache, keyed on the
pinned version, now avoids that.
- wget -q hid transfer detail. curl -fsSL fails the step on an HTTP error,
and a new step reports the resulting compiler version so the log records
what actually built the ELF.
Version and target move into job env vars (GCC_VERSION, GCC_TARGET) using the
same names threadx uses, so the two files stay diffable and a future bump is
a one-line change.
Re-measured the NUCLEO validation record under the newly pinned compiler:
22064 B ROM, down 4 bytes from 14.2.1; RAM unchanged at 6000 B. The figures
and the pin move together deliberately, since letting them drift is what left
a stale 15.2.1 measurement in this file before.
Verified under Arm GNU Toolchain 14.3.Rel1: clean build with -Wall -Wshadow
-Wdouble-promotion -Werror, no new diagnostics from the point release, and
the headless Renode suite still passes with all seven startup self-tests.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
@fdesbiens
fdesbiens
merged commit 1ff7ae1
into
eclipse-threadx:devAug 31, 2026

5 checks passed

@fdesbiens
fdesbiens
deleted the

fix/pin-arm-gcc-14.3

branch
August 31, 2026 19:25

This was referenced Aug 31, 2026
 Merged

 Merged

fdesbiens added a commit
that referenced
this pull request
Aug 31, 2026
@fdesbiens
Pinned the NUCLEO Renode download and cached every toolchain fetch (#55)
bba3b91
Two problems in the pipeline, one of them mine.
The NUCLEO Renode job fetched renode-latest.linux-portable.tar.gz with no
version pin and no checksum, while the PolarFire job three jobs above it
already pinned Renode 1.16.1 and verified its SHA256. That pin landed in #49,
so it was present in this file when #51 added the NUCLEO job; the new job was
modelled on an older copy of the PolarFire step rather than the current one.
The result was a suite whose emulator could change under it on any Renode
release, with nothing verifying what was downloaded. The NUCLEO job now uses
the same pinned, checksum-verified step as PolarFire. The checksum was
recomputed from the published artefact rather than copied on trust.
Separately, every run re-downloaded roughly a gigabyte: the xPack RISC-V
toolchain at ~414 MB and Renode at ~52 MB in each of two jobs. All three are
now restored by actions/cache, keyed on the pinned version so a future bump
invalidates the cache instead of silently serving the old one. This completes
what #53 started for the Arm toolchain.
Caching only makes sense because these are now pinned. Caching an unpinned
"latest" artefact would have frozen CI on whichever build happened to be
fetched first, turning a reproducibility gap into an invisible one.
All four jobs now follow the same shape: cache, install only on a cache miss,
then put the tool on PATH as a separate step so it runs on hit and miss alike.
The PolarFire job also gains a version-reporting step, matching the Arm job, so
the log records which compiler produced the ELF.
Verified both constructed download URLs resolve, and that the Renode 1.16.1
checksum matches the published artefact.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@fdesbiens

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Universal Dark Mode - works on any site
(function() {
var enabled = true;
function applyDarkMode() {
if (!enabled) return;
// Create style element if it doesn't exist
var style = document.getElementById('universal-dark-mode-style');
if (!style) {
style = document.createElement('style');
style.id = 'universal-dark-mode-style';
document.head.appendChild(style);
}
// Dark mode CSS - inverts colors but preserves images/video
style.textContent = '
/* Invert everything except media */
html {
filter: invert(1) hue-rotate(180deg) !important;
background: #1a1a2e !important;
}
/* Restore images, videos, iframes, canvas */
img, video, iframe, canvas, svg, picture, [style*="background-image"] {
filter: invert(1) hue-rotate(180deg) !important;
}
/* Preserve specific elements that should not be inverted */
.no-dark-mode, .no-dark-mode *,
[data-theme="light"], [data-theme="light"],
.ace_editor, .ace_editor *,
.CodeMirror, .CodeMirror *,
.monaco-editor, .monaco-editor *,
.markdown-body pre, .markdown-body pre *,
.highlight, .highlight *,
pre code, pre code * {
filter: none !important;
}
/* Fix common UI elements */
.modal, .popup, .dropdown-menu, .tooltip, .popover {
filter: invert(1) hue-rotate(180deg) !important;
background: #2d2d44 !important;
border-color: #444 !important;
}
/* Scrollbars */
::-webkit-scrollbar { background: #1a1a2e !important; }
::-webkit-scrollbar-thumb { background: #444 !important; }
::-webkit-scrollbar-thumb:hover { background: #555 !important; }
/* Selection */
::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
';
}
function removeDarkMode() {
var style = document.getElementById('universal-dark-mode-style');
if (style) style.remove();
}
// Toggle with Alt+Shift+D
document.addEventListener('keydown', function(e) {
if (e.altKey && e.shiftKey && e.key === 'D') {
e.preventDefault();
enabled = !enabled;
if (enabled) {
applyDarkMode();
console.log('[Universal Dark Mode] Enabled');
} else {
removeDarkMode();
console.log('[Universal Dark Mode] Disabled');
}
}
});
// Apply on load
applyDarkMode();
// Re-apply on dynamic content
var observer = new MutationObserver(function(mutations) {
if (enabled && !document.getElementById('universal-dark-mode-style')) {
applyDarkMode();
}
});
observer.observe(document.head, { childList: true });
console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');
})();
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();
Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern by fdesbiens · Pull Request #53 · eclipse-threadx/samplex · GitHub
Skip to content
Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern - #53
Merged
fdesbiens merged 1 commit into
eclipse-threadx:devfrom 
fdesbiens:fix/pin-arm-gcc-14.3
Aug 31, 2026
Merged
Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern#53
fdesbiens merged 1 commit into
eclipse-threadx:devfrom 
fdesbiens:fix/pin-arm-gcc-14.3
Conversation
@fdesbiens
@fdesbiensfdesbiens
commented
Aug 31, 2026

Copy link


Copy Markdown

Contributor
Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern
Why
The ARM job pinned 14.2.Rel1, chosen only because it was the newest release I was aware of when #50 added the pin. eclipse-threadx/threadx already pins 14.3.rel1 in ci_cortex_m.yml for the Cortex-M ports — so samplex was lagging the flagship repository rather than choosing between two versions.
Both satisfy the AGENTS.md GCC 14 requirement. Matching threadx means a toolchain bump becomes one reviewable line in each repository instead of a per-repository decision.
What changed
The install steps now mirror ci_cortex_m.yml rather than paraphrasing it, which fixes three weaknesses in the version this replaces:
BeforeAfter
No integrity check on the archive at allsha256sum -c against the published .sha256asc
~150 MB downloaded on every runactions/cache keyed on the pinned version
wget -q, no version recordedcurl -fsSL (fails the step on HTTP errors) plus a step reporting the compiler version into the log
Version and target move into job env vars (GCC_VERSION, GCC_TARGET) using the same names threadx uses, so the two files stay diffable.
Validation record re-measured
14.2.114.3.1
ROM22068 B22064 B
RAM6000 B6000 B
The figures and the pin move together deliberately — letting them drift is what left a stale 15.2.1 measurement in this README before.
Verification
Locally under Arm GNU Toolchain 14.3.Rel1 (GCC 14.3.1 20250623):
  • Clean build with -Wall -Wshadow -Wdouble-promotion -Werror — the point release introduces no new diagnostics.
  • Headless Renode suite passes, exit 0, all seven startup self-tests green.
  • Confirmed both the archive and its .sha256asc return 200 from the pinned URL.
Not in scope
PolarFire's RISC-V toolchain stays on xPack 14.2.0 — a different vendor on a different release cadence, and AGENTS.md's GCC 14 requirement is satisfied. The xPack and Renode downloads in the other jobs could take the same caching and checksum treatment; worth a follow-up, but kept out of this change so the diff stays reviewable.
@fdesbiens
Pinned the Arm toolchain to 14.3.Rel1 and adopted the ThreadX install…
fbac0db
… pattern
The ARM job pinned 14.2.Rel1, chosen only because it was the newest release
at the time. eclipse-threadx/threadx already pins 14.3.rel1 in
ci_cortex_m.yml for the Cortex-M ports, so samplex was lagging the flagship
repository rather than choosing between two versions. Both satisfy the
AGENTS.md GCC 14 requirement; matching threadx means a toolchain bump is one
reviewable line in each repository instead of a per-repository decision.
The install steps now mirror ci_cortex_m.yml rather than paraphrasing it,
which fixes three weaknesses in the version this replaces:
- The archive was fetched with no integrity check at all. It is now
verified with sha256sum against the published .sha256asc.
- Roughly 150 MB was downloaded on every run. actions/cache, keyed on the
pinned version, now avoids that.
- wget -q hid transfer detail. curl -fsSL fails the step on an HTTP error,
and a new step reports the resulting compiler version so the log records
what actually built the ELF.
Version and target move into job env vars (GCC_VERSION, GCC_TARGET) using the
same names threadx uses, so the two files stay diffable and a future bump is
a one-line change.
Re-measured the NUCLEO validation record under the newly pinned compiler:
22064 B ROM, down 4 bytes from 14.2.1; RAM unchanged at 6000 B. The figures
and the pin move together deliberately, since letting them drift is what left
a stale 15.2.1 measurement in this file before.
Verified under Arm GNU Toolchain 14.3.Rel1: clean build with -Wall -Wshadow
-Wdouble-promotion -Werror, no new diagnostics from the point release, and
the headless Renode suite still passes with all seven startup self-tests.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
@fdesbiens
fdesbiens
merged commit 1ff7ae1
into
eclipse-threadx:devAug 31, 2026

5 checks passed

@fdesbiens
fdesbiens
deleted the

fix/pin-arm-gcc-14.3

branch
August 31, 2026 19:25

This was referenced Aug 31, 2026
 Merged

 Merged

fdesbiens added a commit
that referenced
this pull request
Aug 31, 2026
@fdesbiens
Pinned the NUCLEO Renode download and cached every toolchain fetch (#55)
bba3b91
Two problems in the pipeline, one of them mine.
The NUCLEO Renode job fetched renode-latest.linux-portable.tar.gz with no
version pin and no checksum, while the PolarFire job three jobs above it
already pinned Renode 1.16.1 and verified its SHA256. That pin landed in #49,
so it was present in this file when #51 added the NUCLEO job; the new job was
modelled on an older copy of the PolarFire step rather than the current one.
The result was a suite whose emulator could change under it on any Renode
release, with nothing verifying what was downloaded. The NUCLEO job now uses
the same pinned, checksum-verified step as PolarFire. The checksum was
recomputed from the published artefact rather than copied on trust.
Separately, every run re-downloaded roughly a gigabyte: the xPack RISC-V
toolchain at ~414 MB and Renode at ~52 MB in each of two jobs. All three are
now restored by actions/cache, keyed on the pinned version so a future bump
invalidates the cache instead of silently serving the old one. This completes
what #53 started for the Arm toolchain.
Caching only makes sense because these are now pinned. Caching an unpinned
"latest" artefact would have frozen CI on whichever build happened to be
fetched first, turning a reproducibility gap into an invisible one.
All four jobs now follow the same shape: cache, install only on a cache miss,
then put the tool on PATH as a separate step so it runs on hit and miss alike.
The PolarFire job also gains a version-reporting step, matching the Arm job, so
the log records which compiler produced the ELF.
Verified both constructed download URLs resolve, and that the Renode 1.16.1
checksum matches the published artefact.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@fdesbiens