cortex_m: Enable fpu on startup #749

tact1m4n3 · 2025-12-04T14:25:49Z

No description provided.

mathk · 2025-12-04T14:28:17Z

core/src/cpus/cortex_m.zig

        }

-        microzig_main();
+        @call(.never_inline, microzig_main, .{});


NP: instead can we use the noinline from the microzig.zig ? it won't be that big of an issue for other chip ?

Imo it's ok that calls inside microzig_main get inlined because the FPU is already enabled when execution gets there.

this would bubble up the hf store to the startup function and you end up with the same issue IIUC.

Sorry, I don't understand what you are referring to. Can you elaborate?

Ah sorry I think I was not clear. I though of flagging the microzig_main as noinline for every CPU not only arm. Just to simplify this @call other arch could suffer the same issue. It might also deserve a small explanation why we don't want microzig_main not to be inlined ? Feel free to discard this comment if you don't think it worth the effort.

Definitely worth a comment to explain.

I though of flagging the microzig_main as noinline for every CPU not only arm.

How can this be achieved? Idk of a way to make calls to microzig_main never inline (since it's always referenced as extern). But I will mark this PR as draft for now. I want to do a bit of refactoring.

I added the comment. Is it ok?

Great comment, I was unsure why this was an issue but that makes sense to me!

core/src/cpus/cortex_m.zig

tact1m4n3 · 2025-12-04T16:21:29Z

core/src/cpus/cortex_m.zig

+/// the startup of other cores.
+pub inline fn enable_fpu() void {
+    // Taken from the rust crate cortex-m-rt.
+    asm volatile (


I've implemented this using raw assembly since we might be missing some register definitions for FPU in some cortex-m variants and also it allows being embedded in naked functions.

tact1m4n3 · 2025-12-04T16:26:22Z

core/src/cpus/cortex_m.zig

+const mpu_present = @hasDecl(microzig.chip, "properties") and
+    @hasDecl(microzig.chip.properties, "cpu.mpuPresent") and
+    std.mem.eql(u8, microzig.chip.properties.@"cpu.mpuPresent", "true");
+const fpu_present = @hasDecl(microzig.chip, "properties") and


Sometimes code generated by regz doesn't include a properties declaration => if you used in the past fpu_present or mpu_present you got a compilation error.

mattnite

Looks good to me once that flag is done, and the conversation with @mathk is resolved.

mattnite · 2025-12-04T16:27:48Z

core/src/cpus/cortex_m.zig

        }

+        if (builtin.abi.float() == .hard) {
+            enable_fpu();


I like that this change makes microzig have more "batteries included" by default, but let's allow the user to disable the FPU at build time, with a flag named disable_fpu.

I can add this but isn't it a footgun? You could achieve the same by switching to soft float in the rp2350_arm target in build.zig and you don't risk crashing.

I added the option

tact1m4n3 · 2025-12-05T18:37:38Z

core/src/cpus/cortex_m.zig

+pub const CPU_Options = struct {
+    /// If true, interrupt vectors are moved to RAM so handlers can be set at runtime.
+    ///
+    /// NOTE: Not supported on cortex_m0.
+    ram_vector_table: bool = false,
+
+    /// If true, the Cortex-M interrupts will be initialized with a more verbose variant
+    /// of the interrupt handlers which print the interrupt name.
+    ///
+    /// NOTE: This option is enabled in debug builds by default.
+    verbose_unhandled_irq: bool = (builtin.mode == .Debug),
+
+    /// If true, the FPU will be enabled in the startup code.
+    ///
+    /// NOTE: This option is enabled by default if hard float is enabled.
+    /// NOTE: Not supported on cortex_m0, cortex_m0plus and cortex_m3.
+    enable_fpu: bool = builtin.abi.float() == .hard,
+};


I made common CPU variant between cortex m flavours to be easier to add options. I also added compilation errors if for instance you try to use a ram vector table on cortex m0 or if you try to enable the FPU on the cortex ms that don't support it.

Let me know what you think of this

tools/regz/src/patch.zig

tact1m4n3 · 2025-12-05T19:11:15Z

Only one last thing remains: standardising fpu and mpu present chip properties (there is a long standing TODO about this in cortex_m.zig)

tact1m4n3 · 2025-12-05T19:58:40Z

tools/regz/src/atdf.zig

        "caption",
    });

+    const property_name_map: std.StaticStringMap([]const u8) = .initComptime(.{


Is it ok to hardcode these here? Same applies for svd

These should probably be documented. Currently we just rename the properties. Another option which I like is to duplicate them with the microzig standard name (keep __MPU_PRESENT but also export mpu_present). But this makes set_device_property a bit weird. For this to work we should add some sort of property aliasing at least for the database (where if you change one, you change the other).

I'm fine with this for now, but honestly we should standardize these for regz/microzig soon. Similar to how we transform register schemas to a common structure, we can do the same for some specific properties, and leave the rest as they come.

tools/regz/src/Database.zig

tact1m4n3 · 2025-12-05T20:20:44Z

Only one last thing remains: standardising fpu and mpu present chip properties (there is a long standing TODO about this in cortex_m.zig)

Is this needed though? A different approach would be to check both fields (__FPU_PRESENT and @"cpu.fpuPresent") in cortex_m.zig when we assign fpu_present.

mattnite · 2025-12-06T06:43:55Z

@tacit1m4n3 I'm not sure where __FPU_PRESENT is from, maybe embassy? But I do know cpu.fpuPresent is part of the CMSIS/SVD spec so what you've outlined is good.

mattnite

Looks great to me, strong work! Let's let @Grazfather and @mathk chime in and then we can merge

tact1m4n3 · 2025-12-06T10:12:08Z

@tact1m4n3 I'm not sure where __FPU_PRESENT is from

I got a CI compile error from an atsam chip that it didn't have an fpu available. Except it did but the property was called __FPU_PRESENT = "1" :) So I figured that is the convention for atdf specs (is it?). This is why I added the __FPU_PRESENT -> fpu_present mapping in atdf.zig

Enable fpu on cortex m startup

28ca874

mathk reviewed Dec 4, 2025

View reviewed changes

core/src/cpus/cortex_m.zig Show resolved Hide resolved

tact1m4n3 and others added 4 commits December 4, 2025 16:39

Fix CI and add barrier instructions

2472054

Remove lazy state preservation

05f1849

Merge branch 'main' into cortex_m_enable_fpu

d5126e1

Add check in multicore

05ee0ad

tact1m4n3 commented Dec 4, 2025

View reviewed changes

Revert change

516a9aa

tact1m4n3 commented Dec 4, 2025

View reviewed changes

mattnite requested changes Dec 4, 2025

View reviewed changes

tact1m4n3 added 2 commits December 4, 2025 18:40

Final changes

a2dfbaf

Fix a bit of formatting

3559290

tact1m4n3 marked this pull request as draft December 5, 2025 15:02

tact1m4n3 added 3 commits December 5, 2025 18:01

Add inline comment

e73819a

Add set_device_property patch and error message

d1d115d

Add enable FPU option and refactor cpu options

dd877fe

tact1m4n3 marked this pull request as ready for review December 5, 2025 18:33

tact1m4n3 commented Dec 5, 2025

View reviewed changes

tools/regz/src/patch.zig Show resolved Hide resolved

tact1m4n3 marked this pull request as draft December 5, 2025 19:09

tact1m4n3 added 2 commits December 5, 2025 21:31

Fix patch and atsam

07e7e53

Standardize fpu, mpu and nvic prio bits properties

f82fc72

tact1m4n3 marked this pull request as ready for review December 5, 2025 19:53

Merge branch 'main' into cortex_m_enable_fpu

88e9574

tact1m4n3 commented Dec 5, 2025

View reviewed changes

tools/regz/src/Database.zig Show resolved Hide resolved

tact1m4n3 requested review from Grazfather and mattnite December 5, 2025 20:01

tact1m4n3 requested a review from mathk December 5, 2025 20:01

mattnite approved these changes Dec 6, 2025

View reviewed changes

cortex_m: Enable fpu on startup #749

Are you sure you want to change the base?

cortex_m: Enable fpu on startup #749

Conversation

tact1m4n3 commented Dec 4, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mattnite left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

tact1m4n3 commented Dec 5, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tact1m4n3 Dec 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

tact1m4n3 commented Dec 5, 2025

Uh oh!

mattnite commented Dec 6, 2025

Uh oh!

mattnite left a comment

Choose a reason for hiding this comment

Uh oh!

tact1m4n3 commented Dec 6, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

tact1m4n3 Dec 5, 2025 •

edited

Loading