Repository navigation
Conversation
sdk-nrf-bm ships s145 per SoC family (nrf54l, nrf54lm, ...): one API header
set per family and one hex per SoC in it. Mirror that layout for the nRF54L
family:
cores/nRF5/nordic/softdevice/s145_nrf54l_10.0.1_API/ L05 / L10 / L15
bootloader/s145/10.0.1/nrf54l/s145_nrf54l{05,10,15}_10.0.1_softdevice.hex
The L05/L10/L15 linker scripts become *_s145_v10.ld with the 10.0.1
SoftDevice bases (0x5A800 / 0xDA800 / 0x15A800); the 9.0.0 hex and API
headers are dropped.
[cvaldess: squashed from andyshinn/nRF54_Arduino 958690f and 552b4ea onto
master. Left out the nRF54LM20A SoftDevice hex, its nrf54lm API directory,
the nRF54LM20A lines in the docs and the test changes that point at the
fork platform, since master has no nRF54LM20A support yet. Kept master's
linker structure and only moved __softdevice_start__. The package version
is left to the release.]
The boards on meshtastic/platform-nordicnrf54 master still select s145 9.0.0 and the v9 linker scripts, which this tree no longer ships. Point the smoke test at the platform branch that moves them to 10.0.1; switch back to master once that is released.
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 14 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Second of the three PRs for the move to s145 10.0.1, in the order @caveman99 set in andyshinn#1: the bootloader (meshtastic/nRF54_Bootloader#4) is released first, then this, then the platform (meshtastic/platform-nordicnrf54#3) moving both pins and the boards together.
It's @andyshinn's 958690f and 552b4ea from
ashinn/nrf54lm20a, squashed onto master with his authorship. Master has no nRF54LM20A support yet, so the LM20A SoftDevice hex, itsnrf54lmAPI directory and the LM20A lines in the docs are left out; they can come with the LM20A support. The commit message says what was trimmed.What it changes
sdk-nrf-bm's per-family layout:cores/nRF5/nordic/softdevice/s145_nrf54l_10.0.1_API/andbootloader/s145/10.0.1/nrf54l/s145_nrf54l{05,10,15}_10.0.1_softdevice.hex. The 9.0.0 headers and hex files are removed.nrf54l{05,10,15}_s145_v9.ldbecome*_s145_v10.ld, with the 10.0.1 bases: 0x5A800 / 0xDA800 / 0x15A800 (were 0x58C00 / 0xD8C00 / 0x158C00). App FLASH, InternalFS and the bootloader settings page don't move. Master's linker structure is kept; only__softdevice_start__changes.NRF_EVT_RADIO_CANCELEDis gone, and theNRF_SOC_EVTSentries after it are renumbered (NRF_EVT_RAND_SEED_REQUEST9 → 8). Code that uses the names is fine once rebuilt; an application built against one version can't run on the other anyway, since the SoftDevice base moves too.tests/blinkbuilds against the platform PR branch (99af5cd), since platform master still selects 9.0.0 and the v9 scripts. It goes back to platform master once that is released.Migration
A board on 9.0.0 can't get to 10.0.1 by DFU: the bootloader can't replace the SoftDevice, and its interrupt forwarding is built for the old base. It needs a one-time reflash over SWD of the 10.0.1 SoftDevice, a bootloader built for 10.0.1 and the application.
Don't send a DFU package built for 10.0.1 to a board still on bootloader v0.3.0: it erases the application before it rejects the package, and the board stays in the bootloader until it gets a 9.0.0 package or SWD.
Testing
tests/blinkbuilds for all five boards against this and the platform PR.nRF54L15-DK, starting from bootloader v0.3.0 + s145 9.0.0. Meshtastic's
nrf54l15dkenv built against this core (plus the MDK bump from #8) and the platform PR. Against the 9.0.0 build of the same tree, the application differs only in the SoftDevice base, theNRF_EVT_RAND_SEED_REQUESTvalue in two comparisons, and build dates.Over SWD, without a chip erase: 10.0.1 SoftDevice + bootloader from the bootloader PR + application. Then:
Not covered: the L05 and L10 (no hardware), the XIAO boards (flashed over their CMSIS-DAP, not tried), BLE OTA through the 10.0.1 bootloader, and anything longer than a few minutes on 10.0.1.