Skip to content

Add stm32mp2 support#446

Open
bruelc wants to merge 1 commit intoseL4:mainfrom
bruelc:stm32mp2
Open

Add stm32mp2 support#446
bruelc wants to merge 1 commit intoseL4:mainfrom
bruelc:stm32mp2

Conversation

@bruelc
Copy link
Copy Markdown
Contributor

@bruelc bruelc commented Mar 24, 2026

Hello,

This is a preliminary version enabling STM32MP2 support for Microkit. I am not yet familiar with all build options, so I may have missed some aspects. The SDK is built as follows:

python3 build_sdk.py --sel4=$KERNEL --boards=stm32mp2

It has been tested with the following examples: hello, arm_smc, and passive_server, using this build command:

make BUILD_DIR=install_build \
     MICROKIT_BOARD=stm32mp2 \
     MICROKIT_CONFIG=debug \
     MICROKIT_SDK=$MKMP25/release/microkit-sdk-2.1.0-dev

Remaining work / questions:

  • Test SMP support

A quick look at util64.S:mmu_enable() suggests that we probably need to align with PR #244 before testing.

I have not yet figured out how to enable SMP/PSCI support.
It appears to be enabled when smp_cores is defined in the build script, but I do not see yet execution reaching arm_secondary_cpu_entry_asm()...

  • No output in release mode

I am not seeing any UART output in release mode for the examples above.
Is it expected that UART output for PDs is only available in debug builds ?

Thank you for any comment/suggestion

@bruelc bruelc marked this pull request as draft March 24, 2026 17:52
@midnightveil
Copy link
Copy Markdown
Contributor

midnightveil commented Mar 24, 2026

I am not seeing any UART output in release mode for the examples above.
Is it expected that UART output for PDs is only available in debug builds ?

Yes, the microkit dbg puts only works in debug mode.

I have not yet figured out how to enable SMP/PSCI support.
It appears to be enabled when smp_cores is defined in the build script, but I do not see yet execution reaching arm_secondary_cpu_entry_asm()...

Just confirming you are using the smp-debug MICROKIT_CONFIG? If it's SMP it should be at least doing PSCI calls - do you see a PSCI version printed? I don't know what would be causing the PSCI calls to not work.

@bruelc
Copy link
Copy Markdown
Contributor Author

bruelc commented Mar 25, 2026

I am not seeing any UART output in release mode for the examples above.
Is it expected that UART output for PDs is only available in debug builds ?

Yes, the microkit dbg puts only works in debug mode.

Ah, OK, I didn't check that userland example uses microkit_dbg_puts(), sorry. I assumed a musl printf()...

I have not yet figured out how to enable SMP/PSCI support.
It appears to be enabled when smp_cores is defined in the build script, but I do not see yet execution reaching arm_secondary_cpu_entry_asm()...

Just confirming you are using the smp-debug MICROKIT_CONFIG? If it's SMP it should be at least doing PSCI calls - do you see a PSCI version printed? I don't know what would be causing the PSCI calls to not work.

I see the PSCI version printed. But now I suspect that CPU1 is just silently failing to start due to the missing 1:1 2 MB MMU mapping. I did not observe the same way of failing with the elfloader, but with branch buffers you never know :)
I will update the status after updating the Rust loader.

thank you

Christian

@midnightveil
Copy link
Copy Markdown
Contributor

midnightveil commented Mar 25, 2026 •
edited
Loading

I see the PSCI version printed. But now I suspect that CPU1 is just silently failing to start due to the missing 1:1 2 MB MMU mapping. I did not observe the same way of failing with the elfloader, but with branch buffers you never know :)
I will update the status after updating the Rust loader.

Hmm, I'd be surprised if the MMU mapping is the problem as you aren't seeing any output from CPU1. We have (admittedly a hack) where after exiting UBoot we disable the MMU & caches and then just before starting seL4 we setup the page tables. If you see no output from CPU1 at all then it means something else is likely going wrong.

Are you able to add a print at the end of the plat_start_cpu function that indicates success? It's possible that doing the PSCI (SVC call) is crashing in some way.

example output from PSCI booting on the odroidc4 
LDR|INFO: disabling MMU (if it was enabled)
LDR|INFO: altloader for seL4 starting
LDR|INFO: Flags:
             seL4 configured as hypervisor
LDR|INFO: Kernel:      entry:   0x0000008000000000
LDR|INFO: Root server: physmem: 0x000000000025c000 -- 0x0000000000299000
LDR|INFO:              virtmem: 0x0000000000200000 -- 0x000000000023d000
LDR|INFO:              entry  : 0x000000000021205c
LDR|INFO: region: 0x00000000   addr: 0x0000000000000000   size: 0x000000000025c000   offset: 0x0000000000000000   type: 0x0000000000000001
LDR|INFO: region: 0x00000001   addr: 0x000000000025c000   size: 0x0000000000009178   offset: 0x000000000025c000   type: 0x0000000000000001
LDR|INFO: region: 0x00000002   addr: 0x0000000000266178   size: 0x0000000000015d48   offset: 0x0000000000265178   type: 0x0000000000000001
LDR|INFO: region: 0x00000003   addr: 0x000000000027cec0   size: 0x00000000000100b0   offset: 0x000000000027aec0   type: 0x0000000000000001
LDR|INFO: region: 0x00000004   addr: 0x000000000028d000   size: 0x0000000000001bec   offset: 0x000000000028af70   type: 0x0000000000000001
LDR|INFO: region: 0x00000005   addr: 0x000000000028f000   size: 0x000000000000a000   offset: 0x000000000028cb5c   type: 0x0000000000000001
LDR|INFO: copying region 0x00000000
LDR|INFO: copying region 0x00000001
LDR|INFO: copying region 0x00000002
LDR|INFO: copying region 0x00000003
LDR|INFO: copying region 0x00000004
LDR|INFO: copying region 0x00000005
LDR|INFO|CPU0: Active CPUs to start: 0x00000004
LDR|INFO|CPU0: Starting CPU 1
LDR|INFO|CPU1: secondary CPU entry with MPIDR_EL1 0x0000000081000100
LDR|INFO|CPU1: enabling MMU
LDR|INFO|CPU1: CurrentEL=EL2
LDR|INFO|CPU1: Resetting CNTVOFF
LDR|INFO|CPU1: enabling MMU
LDR|INFO|CPU1: jumping to kernel
LDR|INFO|CPU0: Starting CPU 2
LDR|INFO|CPU2: secondary CPU entry with MPIDR_EL1 0x0000000081000200
LDR|INFO|CPU2: enabling MMU
LDR|INFO|CPU2: CurrentEL=EL2
LDR|INFO|CPU2: Resetting CNTVOFF
LDR|INFO|CPU2: enabling MMU
LDR|INFO|CPU2: jumping to kernel
LDR|INFO|CPU0: Starting CPU 3
LDR|INFO|CPU3: secondary CPU entry with MPIDR_EL1 0x0000000081000300
LDR|INFO|CPU3: enabling MMU
LDR|INFO|CPU3: CurrentEL=EL2
LDR|INFO|CPU3: Resetting CNTVOFF
LDR|INFO|CPU3: enabling MMU
LDR|INFO|CPU3: jumping to kernel
LDR|INFO|CPU0: enabling MMU
LDR|INFO|CPU0: CurrentEL=EL2
LDR|INFO|CPU0: Resetting CNTVOFF
LDR|INFO|CPU0: enabling MMU
LDR|INFO|CPU0: jumping to kernel
Bootstrapping kernel
available phys memory regions: 2
  [0..5000000)
  [5300000..f5800000)
reserved virt address space regions: 2
  [8000000000..800025c000)
  [800025c000..8000299000)
clock_sync_test[1]: t0 = 267926952, t = 267926955, td = 3
clock_sync_test[3]: t0 = 268025659, t = 268025662, td = 3
clock_sync_test[2]: t0 = 268149505, t = 268149508, td = 3
Booting all finished, dropped to user space
INFO  [sel4_capdl_initializer::initialize] Starting CapDL initializer
INFO  [sel4_capdl_initializer::initialize] Starting threads
hellMoO,N |wIoNrFlOd:
 Microkit Monitor started!
hello, world

@bruelc
Copy link
Copy Markdown
Contributor Author

bruelc commented Mar 30, 2026

I see the PSCI version printed. But now I suspect that CPU1 is just silently failing to start due to the missing 1:1 2 MB MMU mapping. I did not observe the same way of failing with the elfloader, but with branch buffers you never know :)
I will update the status after updating the Rust loader.

Hmm, I'd be surprised if the MMU mapping is the problem as you aren't seeing any output from CPU1. We have (admittedly a hack) where after exiting UBoot we disable the MMU & caches and then just before starting seL4 we setup the page tables. If you see no output from CPU1 at all then it means something else is likely going wrong.

Are you able to add a print at the end of the plat_start_cpu function that indicates success? It's possible that doing the PSCI (SVC call) is crashing in some way.

example output from PSCI booting on the odroidc4

Hello,

I finally managed to get SMP working. However, simply changing the MMU mapping to exclude secure memory was not sufficient (but necessary); I also needed to map those regions as Normal Non-Cacheable and Inner Shareable (for the print_lock synchronisation variable)

Another issue I encountered is that, for reasons I do not yet understand, my compiler does not correctly expand the atomic builtins. I'll check different versions or check the -cpu flags, but as a temporary workaround, to confirm the status I used inline asm stlr/ldar instructions instead. Seems like there are still some checks to do around the cpu synchronisation barriers.

As a result, this patch will require some other preparatory PRs.

@bruelc bruelc mentioned this pull request Mar 31, 2026
Open
@bruelc
Copy link
Copy Markdown
Contributor Author

bruelc commented Apr 1, 2026 •
edited
Loading

depends on
#464
#465

@bruelc bruelc marked this pull request as ready for review April 1, 2026 12:36
@bruelc
Add stm32mp2 support
dbba99d 
Signed-off-by: Christian Bruel <christian.bruel@foss.st.com>
@midnightveil
Copy link
Copy Markdown
Contributor

midnightveil commented Apr 24, 2026 •
edited
Loading

Hi! Just trying to test this out locally with the STM32 boards you sent us.

We run into the following isues using the TF-A the boards come with on their SD card, that they set SPSR = 0x3c5 corresponding to EL1 mode. Is there a different image that should be used instead to boot into EL2?

Also — the microkit project has its own manual (see manual.md), which should be updated with instructions to get the appropriate image.

INFO:    Boot used partition fsbl1
NOTICE:  BL2: v2.8-stm32mp2-r1.1(debug):lts-v2.8.15-dirty(567af710)
NOTICE:  BL2: Built : 00:51:33, Jan 26 2024
INFO:    BL2: Loading image id 26

[...]

I/TC: Primary CPU switching to normal world boot
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x84000000
INFO:    SPSR = 0x3c5

U-Boot 2022.10-stm32mp-r2-rc15 (Oct 03 2022 - 19:25:32 +0000)

CPU: STM32MP257FAI Rev.Y
Model: STMicroelectronics STM32MP257F-EV1 Evaluation Board
Board: stm32mp2 (st,stm32mp257f-ev1)
Board: MB1936 Var1.1 Rev.D-02

[....]

STM32MP> setenv loadaddr 0x88000000
setenv loadaddr 0x88000000
STM32MP> tftp ${loadaddr} /stm32mp257f-ev1-1/sel4-image
tftp ${loadaddr} /stm32mp257f-ev1-1/sel4-image
Using eth2@482d0000 device
TFTP from server 172.16.0.2; our IP address is 172.16.1.0
Filename '/stm32mp257f-ev1-1/sel4-image'.
Load address: 0x88000000
Loading: #################################################################
         #################################################################
         ######################################################
         8.7 MiB/s
done
Bytes transferred = 2699204 (292fc4 hex)
STM32MP> go ${load addr}
go ${loadaddr}
## Starting application at 0x88000000 ...
LDR|INFO|CPU0: CurrentEL=EL1
LDR|ERROR|CPU0: seL4 configured as a hypervisor, but not in EL2
LDR|ERROR: failed to ensure correct EL

@bruelc
Copy link
Copy Markdown
Contributor Author

bruelc commented Apr 24, 2026

Hi! Just trying to test this out locally with the STM32 boards you sent us.

We run into the following isues using the TF-A the boards come with on their SD card, that they set SPSR = 0x3c5 corresponding to EL1 mode. Is there a different image that should be used instead to boot into EL2?

STM32MP> setenv loadaddr 0x88000000
setenv loadaddr 0x88000000
STM32MP> tftp ${loadaddr} /stm32mp257f-ev1-1/sel4-image
tftp ${loadaddr} /stm32mp257f-ev1-1/sel4-image
Using eth2@482d0000 device
TFTP from server 172.16.0.2; our IP address is 172.16.1.0
Filename '/stm32mp257f-ev1-1/sel4-image'.
Load address: 0x88000000
Loading: #################################################################
#################################################################
######################################################
8.7 MiB/s
done
Bytes transferred = 2699204 (292fc4 hex)
STM32MP> go ${load addr}
go ${loadaddr}

Starting application at 0x88000000 ...

LDR|INFO|CPU0: CurrentEL=EL1
LDR|ERROR|CPU0: seL4 configured as a hypervisor, but not in EL2
LDR|ERROR: failed to ensure correct EL

Either you run a very old version of TF-A (EL2 support was introduced a couple of year ago), or you run a 32bit build of seL4 (64bit u-boot does a mode switch to boot 32bit binary kernel). Can you double check please ?

You can also rebuild TF-A from an alternate buildroot from bootlin https://github.com/bootlin/buildroot-external-st

It is less updated and featured than the OSTL Yocto distribution , but perfectly enough for our needs

Also — the microkit project has its own manual (see manual.md), which should be updated with instructions to get the appropriate image.

ok

@midnightveil
Copy link
Copy Markdown
Contributor

midnightveil commented Apr 24, 2026 •
edited
Loading

Either you run a very old version of TF-A (EL2 support was introduced a couple of year ago),

We run the version that came on the SD card with the boards, which seems to have been built in 2024. By "EL2 support was introduced a couple of year ago" do you mean in the STM32 version of TF-A?" I know we have other boards that are much older than boot in EL2 from TF-A.

Anyhow, OK — I guess we need to reflash the SD cards with more appropriate versions of the firmware. I think it would be helpful to mention this briefly in the manual.

@bruelc
Copy link
Copy Markdown
Contributor Author

bruelc commented Apr 24, 2026 •
edited
Loading

Either you run a very old version of TF-A (EL2 support was introduced a couple of year ago),

We run the version that came on the SD card with the boards, which seems to have been built in 2024. By "EL2 support was introduced a couple of year ago" do you mean in the STM32 version of TF-A?" I know we have other boards that are much older than boot in EL2 from TF-A.

sorry, I used the wrong wording: s/introduced/enabled.

Anyhow, OK — I guess we need to reflash the SD cards with more appropriate versions of the firmware. I think it would be helpful to mention this briefly in the manual.

OK. Another caveat that I noticed is that TF-A enables a watchdog. If it is not re-armed by a iwdg driver (e.g by the Linux VM), native seL4 applications with lot of traces in debug mode might not complete in time.
I need to mention this as well (and a way to disable it)

edit: tell me if you need help, I can send you a raw file ready to flash in between.

Sign up for free to 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.

2 participants

@bruelc @midnightveil