rust/cpu: Set value for cortex-m33

[chrysn]

Contribution description

Updating some Rust tests I needed something to test on, and the nRF5340dk was closed but … oh my, no Rust support?

That was because the target triple (RUST_TARGET = thumbv8m.main-none-eabihf) was not set. More precisely, it was commented out because I mad an assumption originally but had no hardware to test it.

Testing procedure

• Run any example on nrf5340dk.
• Note that before this, things failed with "There are unsatisfied feature requirements: rust_target", or when run with CONTINUE_ON_EXPECTED_ERRORS=1, with "Error: No RUST_TARGET was set for this platform."
• If we just uncommented the old value (no hf suffix), the linker complains about inconsistent calling conventions ("uses VFP register arguments, [...] does not").

Note that I didn't have a built-in usable programmer; nrf53 doesn't have openocd support, and JLink is proprietary. I flashed using probe-rs (cf. #21466 but I did it manually here).

Open questions

Do we have a non-hard-float variant of m33 too? If so, there'd need to be another if/else, but probably then also have a different CPU_CORE value, so I think we just only support M33 with HF (it's optional in the ISA, but are there even any M33 we support that don't have it?).

Declaration of AI-Tools / LLMs usage:

AI-Tools / LLMs that were used are:

• none

[riot-ci]

Murdock results

✔️ PASSED

ed4a34b cpu/rp2350: Disable Rust support even though M33s generally have it

Success	Failures	Total	Runtime
165178	0	165178	02h:17m:44s

Artifacts

• Documentation preview

[crasbe]

I tested it with #22175 (the STM32U3 has an M33) and it works as you described. The rust-hello-world example also works.

[crasbe]

Do we have a non-hard-float variant of m33 too? If so, there'd need to be another if/else, but probably then also have a different CPU_CORE value, so I think we just only support M33 with HF (it's optional in the ISA, but are there even any M33 we support that don't have it?).

It would appear that we currently default to Hard Float for all M33:

RIOT/makefiles/arch/cortexm.inc.mk

Lines 64 to 73 in 48322fb

	# Add soft or hard FPU CFLAGS depending on the module
	ifneq (,$(filter cortexm_fpu,$(USEMODULE)))
	ifneq (,$(filter $(CPU_CORE),cortex-m33 cortex-m7))
	CFLAGS_FPU ?= -mfloat-abi=hard -mfpu=fpv5-sp-d16
	else
	CFLAGS_FPU ?= -mfloat-abi=hard -mfpu=fpv4-sp-d16
	endif
	else
	CFLAGS_FPU ?= -mfloat-abi=soft
	endif

[chrysn]

Thanks for the quick test & review!

[crasbe]

It seems hard float is not enabled for the RP2350 in the SDK version we're using: raspberrypi/pico-sdk#2783

[crasbe]

It seems hard float is not enabled for the RP2350 in the SDK version we're using: raspberrypi/pico-sdk#2783

Well great, it'll be part of the 2.2.1 Release (we use 2.2.0), but that wasn't released yet 🫠

Ping @AnnsAnns, the residential RP2350 expert 👀

[chrysn]

OK, if it's conditional on cortexm_fpu, that's almost actionable … except that the features only become available later, so I'll somehow need to set "yeah we have a RUST_TARGET" in at Makefile .features time, and then decide which value at MAkeile .include time (?).

[AnnsAnns]

there is no reference in the datasheet from a quick look, we might be able to simply pin to the commit that added hardfp support to be safe?

[chrysn]

I appreciate updating this, but as there is an example of M33 using no hardfp for some reason, I'm also using this to ensure that things work on both sides.

(I'm running into other trouble with the picosdk after a fix, but that might be a case of blocking Rust builds on that platform until that is resolved / opening a different issue).

[AnnsAnns]

I appreciate updating this, but as there is an example of M33 using no hardfp for some reason, I'm also using this to ensure that things work on both sides.

(I'm running into other trouble with the picosdk after a fix, but that might be a case of blocking Rust builds on that platform until that is resolved / opening a different issue).

I must admit that I have no clue 😅 The only thing I can say is that Rust works on the Pico 2 Hazard3 but I dont remember how that target looks

[chrysn]

I've pushed a proposed workaround for the "some don't use FPU". Even outside the RP2350 troubles, this can be tested by building either for nrf5340dk-app or xg23-pk6068a and adding DISABLE_MODULE=cortexm_fpu -- now it builds for both no matter whether that module is on or not.

For the RP, I'm looking for a way to just block the combination until I find out what's precisely going on (something about the __isb of picosdk acts up; pure Rust applications don't have that issue because they don't bindgen as excessively as we do).

[chrysn]

Can we defer the rp issue to #22294?

With the "full build" flag set, if this goes through, there should be no surprises next time we attempt merging.

[crasbe]

Suggested change

	include $(RIOTCPU)/rp2350_common/Makefile.features
	include $(RIOTCPU)/cortexm_common/Makefile.features
	# Explicitly *not* supported, see <https://github.com/RIOT-OS/RIOT/issues/22294>
	FEATURES_PROVIDED := $(filter-out rust_target,$(FEATURES_PROVIDED))
	# Explicitly *not* supported, see <https://github.com/RIOT-OS/RIOT/issues/22294>
	FEATURES_BLACKLIST += rust_target
	include $(RIOTCPU)/rp2350_common/Makefile.features
	include $(RIOTCPU)/cortexm_common/Makefile.features

Why not use the official mechanism for that?

[crasbe]

Suggested change

	ifeq ($(CPU_CORE),cortex-m33)
	# See Makefile.features where RUST_TARGET is set the first time -- but it is
	# set to "to-be-set-later". See there for full explanation.
	ifneq (,$(filter cortexm_fpu,$(USEMODULE)))
	RUST_TARGET = thumbv8m.main-none-eabihf
	else
	RUST_TARGET = thumbv8m.main-none-eabi
	endif
	endif
	ifeq (to-be-set-later, $(RUST_TARGET))
	# RUST_TARGET is set in `cpu/cortexm_common/Makefile.features` for most cores,
	# manually set it here for `to-be-set-later`. See there for a full
	# explanation.
	ifeq (cortex-m33, $(CPU_CORE))
	ifneq (,$(filter cortexm_fpu, $(USEMODULE)))
	RUST_TARGET = thumbv8m.main-none-eabihf
	else
	RUST_TARGET = thumbv8m.main-none-eabi
	endif
	else
	$(error RUST_TARGET set to 'to-be-set-later' but never actually set!)
	endif
	endif

IMO it's nicer to catch it in our buildsystem than getting a weird and wonderful error message from the Rust compiler that it does not know what to-be-set-later is supposed to be 🤔😅