STM32MP13x support

[antisvin]

There's no available hardware yet AFAICT, but ST have published Linux kernel support about this device and there's some info online. So it's a simpler MPU with 1 A7 core running up to 900 Mhz, no M4 coprocessor. There will be a discovery board from ST.

Seems to be largely compatible with STM32MP15x on software side.

[danngreen]

Interesting! I heard rumors about a new MP1 series. Presumably these would be cheaper than the MP15x.

It looks like they use the same BOOTROM. If the GIC is also the same, then code for these projects should port easily (just updating pins and peripheral numbers). We'll see.

I do see support for USB-C DRD, for which the MP15x series requires an external chip.

Edit: the DTS references the same GIC as the MP15x:
stm32mp131.dtsi

[antisvin]

I would be surprised if changes go much further than tweaks to some peripherals. I.e. kernel patches mention that GPIO banks can be secured, whatever that means.

[danngreen]

Yeah, likely very similar. The DTS references a different EXTI peripheral, but a lot of things are missing from the linux DTS files, so it's hard to say. I haven't looked into the u-boot or TFA yet repos yet.

[antisvin]

ST have added product pages and documentation for MP13x chips. A comparison to MP15x is available here - https://www.st.com/resource/en/application_note/an5475-migration-of-applications-from-stm32mp15x-lines-to-stm32mp13x-lines-microprocessor-stmicroelectronics.pdf

They also offer a discovery kit for it - https://www.st.com/en/evaluation-tools/stm32mp135f-dk.html

[danngreen]

I actually just received my MP135 discovery kit! I haven't played with it yet.

The most exciting change to me is that ST announced they will officially support RTOS on the MP13x series (at least, there will be an Azure port). The migration guide even mentions that the A7 can run on bare metal. So we may see this repo become obsolete someday :) Not anytime soon, CubeMX still provides no code generation (only DTS), which is even less supportive than the MP15x (where at least you can get example code by selecting peripherals for the M4 core).

Anyways, I looked at the differences in bootroom, and if we don't need any security or encryption then it looks like just some minor differences in the FSBL header should get a minimal bare metal system booting.

[antisvin]

That's a bit too optimistic, I still have seen no indication whatsoever that ST is going to support bare metal on cortex-A cores. Of course it's nice to see them stating the obvious (that it can run on it), but they haven't made any changes to their MPU offer where they consider A cores Linux only and have not even created a Cube FW repo.

[antisvin]

There's a comment from ST employee on their forums that promises support for baremetal code on MP13x to be released by the end of the year: https://community.st.com/s/question/0D53W00002DZDseSAH/how-to-run-on-bare-metal-rtos-on-stm32mp135fdk-discovery-board

[danngreen]

Good to hear some details and a rough time estimate from ST. Yes, I heard something similar from an engineer in their the video announcement of the MP13x line, but no date was given then. I still plan to port this project for the MP13x soon

[danngreen]

A little update on this: I made a board with the MP135 chip, and it powers on and runs code in SYSRAM.

However, there is no CMSIS device file, nor SVD files, nor any mention of the MP13x line in ST's HAL. I had hoped the registers would be more-or-less aligned with the MP15x series, but that's not the case (i.e. RCC registers have different addresses, but same names).
The only resources available are the reference manual, and the U-Boot drivers for MP13x. Technically, either one of these would be sufficient, but the lack of good resources is making it take longer than I had hoped. I do still want to have baremetal examples for this line of chips.

There is this forum post: https://community.st.com/t5/stm32-mpu-products/how-to-run-on-bare-metal-rtos-on-stm32mp135f-dk-discovery-board/td-p/81248

Sounds like they intend to release the support files for baremetal usage at the end of the year (which I hope includes at least the CMSIS device files).

[danngreen]

Cube HAL for the MP13x is released!
https://github.com/STMicroelectronics/STM32CubeMP13

It includes the CMSIS device files, and looks like a full set of peripheral drivers (including RCC and DDR Init).

[youngsea2000]

MP13x 的 Cube HAL 已发布！ https://github.com/STMicroelectronics/STM32CubeMP13

它包含 CMSIS 设备文件，看起来像一整套外围驱动程序（包括 RCC 和 DDR Init）。

https://github.com/youngsea2000/STM32MP1xx_Baremetal/tree/main/bootloader/FSBLA/FSBLA_Sdmmc1

I attempted to port CubeMP13's FSBLA_Sdmmc1 to the STM32MP15 and succeeded; the user program can now start normally from C0000100. The changes included configuring the RCC clock and adding the TZPC program to the HAL library (from CubeMP13). It appears the program is running smoothly.

[danngreen]

Thanks for sharing! I'm looking at your project, comparing it to the original FSBL_Sdmmc project from ST to see exactly what changed. I'm interested in doing the opposite changes to make the MP1-Boot project run on the MP13x chip. As you say, it looks like very minimal changes.

[youngsea2000]

I will explain the main changes as follows:

1. Removed the definition of GPT_TABLE_PRESENT in the Makefile
   (This change is not made in my current commit).

2. Removed PMIC-related code due to the absence of PMIC on the board
   Specifically, the PMIC-related code has been removed from /Drivers/BSP/STM32MP1xx_ATK, and the following lines in main.c have been deleted:

   131|#if (USE_STPMIC1x) && !defined(USE_DDR)
   132|  /* Configure PMIC */
   133|  BSP_PMIC_Init();
   134|  BSP_PMIC_InitRegulators();
   135|#endif

3. Modified program loading location and other related code changes
   The following code sections have been updated:

   Original Code:

   104|  uint32_t index = 0;
   129|  __HAL_RCC_MCE_CLK_ENABLE();
   148|  __HAL_RCC_TZC_CLK_ENABLE();
   259|  nbCubeExampleBlock = sizeCubeExample / BLOCKSIZE;
   265|  if(HAL_SD_ReadBlocks_DMA(&SDHandle, (uint8_t *)DDR_MEM_ADD, (exampleOffset + NB_BLOCK_HEADER), nbCubeExampleBlock+1) != HAL_OK)
   277|  p_AppEntryPoint = (void *)(DDR_MEM_ADD);

   Modified Code:

   104|#ifdef GPT_TABLE_PRESENT 
   105|  uint32_t index = 0; 
   106|#endif /* GPT_TABLE_PRESENT */
   130|  // __HAL_RCC_MCE_CLK_ENABLE();
   150|  __HAL_RCC_TZC1_CLK_ENABLE();
   255|  nbCubeExampleBlock = (sizeCubeExample + 256) / BLOCKSIZE + 1;
   261|  if(HAL_SD_ReadBlocks_DMA(&SDHandle, (uint8_t *)(DDR_MEM_ADD), exampleOffset, nbCubeExampleBlock) != HAL_OK)
   273|  p_AppEntryPoint = (void *)(DDR_MEM_ADD+0x100); 
   274|  __disable_irq();

4. Modified RCC configuration

5. Added and modified files in Drivers/STM32MP1xx_HAL_Driver_EX/. These files are sourced from STM32CubeMP13.

[youngsea2000]

Fortunately, a week ago, STM32CubeMP13 was updated and added External_Mem_Loader_A7 and SD_Ext_Loader, which allows me to start supporting GPT Part startup for STM32MP157.