soc: rp2350: enable support for building with CONFIG_XIP=n

[dsseng]

Should be also possible on RP2040 but has less practical applications due to lack of UART boot.

Usage: west build -b rpi_pico2/rp2350a/m33 samples/subsys/usb/console -- -DCONFIG_XIP=n

Signed-off-by: Dmitrii Sharshakov [email protected]

[dsseng]

Doesn't regress building without the snippet as nothing but commit hash changes in the built image

[tejlmand]

Did you look at: #36800

[dsseng]

Did you look at: #36800

Hm, I briefly read it now. Seems they also ended up patching DT, so this is basically it, but done as a snippet with an overlay to be applied easily

Should I try just XIP=n to see if Zephyr automatically ignores flash and links into RAM? The only issue is that we have to add the image header to the RP2350 executable, thus we must use the ld script to add that section

[dsseng]

CONFIG_XIP=n didn't relocate the code for RP2350, so perhaps that's a different story. Clarification: RAM boot in this case is not copying everything to RAM on start, but rather creating an image which only resides in RAM and can be applied without flash memory present

[dsseng]

Did you look at: #36800

@tejlmand Could you please elaborate? I am doing basically the same. What should I give more attention to? Thanks

[tejlmand]

CONFIG_XIP=n didn't relocate the code for RP2350, so perhaps that's a different story. Clarification: RAM boot in this case is not copying everything to RAM on start, but rather creating an image which only resides in RAM and can be applied without flash memory present

Thanks for checking up.
I just wanted to make sure you knew about the other option and that it didn't cover your use-case.

[tejlmand]

Having a ram boot / code location snippet could make sense., but it should be a generic snippet, where there could be a specific entry for handling of rpi_pico2, see https://docs.zephyrproject.org/latest/build/snippets/writing.html#board-specific-settings on how to do so in a snippet.

However, as commented, then it seems that ram code size is very depending on the sample / application size, and thus any size defined in the snippet would likely have to be adjusted.

For this reason, then perhaps it would be better to have a new test or sample which shows how a sample can be built and executed from flash / or placed directy in ram without using Zephyr's relocation feature.

Then users can build as:

$ west build -b rpi_pico2/rp2350a/m33 <new-sample>

or applying the overlay that could live together with the sample, like this:

$ west build -b rpi_pico2/rp2350a/m33 <new-sample> -- -DDTC_OVERLAY_FILE=ram.overlay

An example of such approach can be seen in https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/subsys/fs/format/ where a ramdisk.overlay overlay file is provided that the user can specify.
The advantage of dtc overlay approach is that it becomes more visible to users that the ram.overlay file should be copied to their own sample, and that they won't have to modify an upstream snippet.
The disadvantage of such approach compared to the snippet approach is of course that it's less visible that the ram option exists for any sample.

[dsseng]

Having a ram boot / code location snippet could make sense., but it should be a generic snippet, where there could be a specific entry for handling of rpi_pico2, see docs.zephyrproject.org/latest/build/snippets/writing.html#board-specific-settings on how to do so in a snippet.

Okay, perhaps with a regex I can match *rp2350* as this is applicable for all boards on this chip

However, as commented, then it seems that ram code size is very depending on the sample / application size, and thus any size defined in the snippet would likely have to be adjusted

It is not likely to have to be adjusted. 256 KB "flash" and 256 KB RAM should be fine for most cases and others should be able to make a custom overlay/dts.

The disadvantage of such approach compared to the snippet approach is of course that it's less visible that the ram option exists for any sample.

Yes, and this is more complex than a snippet for the development workflow.

I will probably implement a SoC-specific overlay in the snippet, so that we match not only rpi_pico2/rp2350a/m33 but e.g. adafruit_feather_rp2350/rp2350a/hazard3 or any other case. Resizing partitions should not be needed as the memory seems rather abundant for most use cases

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[tejlmand]

Hm, I actually did some more work on XIP=n build for RP2, and perhaps I should just do a bit of a different thing. Please wait, this PR will be repurposed to make XIP=n build a bootable image.

perhaps marking the PR DNM or convert to draft meanwhile.

[dsseng]

Hm, I actually did some more work on XIP=n build for RP2, and perhaps I should just do a bit of a different thing. Please wait, this PR will be repurposed to make XIP=n build a bootable image.

perhaps marking the PR DNM or convert to draft meanwhile.

@tejlmand ah, sorry, I've already rewritten everything. You're welcome to review now

[ajf58]

This is a neater solution than what I'd done originally (and was subsequently copied around). LGTM.

[nordicjm]

DTS changes OK

[dsseng]

@tejlmand could you please take a look? These changes already got 3 approvals, so perhaps it'd be best to merge them to avoid unnecessary stale PRs and merge conflicts. Thank you!