apache · xiaoxiang781216 · Jul 3, 2026 · May 28, 2026 · May 31, 2026 · May 28, 2026
diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS
diff --git a/Documentation/applications/examples/ft80x/index.rst b/Documentation/applications/examples/ft80x/index.rst
@@ -4,4 +4,4 @@
 
 This examples has ports of several FTDI demos for the FTDI/BridgeTek FT80x GUI
 chip. As an example configuration, see
-``nuttx/boards/arm/stm32/viewtool-stm32f107/configs/ft80x/defconfig``.
+``nuttx/boards/arm/stm32f1/viewtool-stm32f107/configs/ft80x/defconfig``.
diff --git a/Documentation/applications/system/usbmsc/index.rst b/Documentation/applications/system/usbmsc/index.rst
@@ -13,7 +13,7 @@ This function will be called by the ``system/usbmsc`` indirectly via the ``board
 block device drivers. For examples of the implementation of
 ``board_usbmsc_initialize()`` see
 ``boards/arm/lpc214x/mcu123-lpc214x/src/up_usbmsc.c`` or
-``boards/arm/stm32/stm3210e-eval/src/usbmsc.c``.
+``boards/arm/stm32f1/stm3210e-eval/src/usbmsc.c``.
 
 Configuration options:
 

diff --git a/Documentation/components/drivers/character/input/keypad.rst b/Documentation/components/drivers/character/input/keypad.rst
@@ -62,7 +62,7 @@ kbd-codec layer.
      ``board_kmatrix_initialize("/dev/keypad0")``).
 
 **Reference Implementation (STM32F4Discovery)**. The current reference
-is in ``boards/arm/stm32/common/src/stm32_kmatrix_gpio.c``:
+is in ``boards/arm/common/stm32/src/stm32_kmatrix_gpio.c``:
 
 - Rows: ``BOARD_KMATRIX_ROW0..3`` (outputs)
 - Columns: ``BOARD_KMATRIX_COL0..2`` (inputs with pull-up)

diff --git a/Documentation/components/drivers/character/input/mpr121.rst b/Documentation/components/drivers/character/input/mpr121.rst
@@ -53,7 +53,7 @@ kbd-codec layer.
      ``board_mpr121_initialize(0, 1)`` for ``/dev/keymap0`` and ``i2c1``).
 
 **Reference Implementation (STM32F4Discovery)**. The current reference
-is in ``boards/arm/stm32/common/src/stm32_mpr121.c``:
+is in ``boards/arm/common/stm32/src/stm32_mpr121.c``:
 
 - Keymap: 4x3 keypad layout
 - Registration: ``board_mpr121_initialize()`` calls

diff --git a/Documentation/components/drivers/character/input/sbutton.rst b/Documentation/components/drivers/character/input/sbutton.rst
@@ -23,7 +23,7 @@ It uses a kind of "polymorphism" in C to allow the driver to get
 access to the functions responsible to attach and enable the
 interrupt and to get the status of the pin.
 See ``include/nuttx/input/sbutton.h``
-and ``boards/arm/stm32/common/src/stm32_sbutton.c`` to understand
+and ``boards/arm/common/stm32/src/stm32_sbutton.c`` to understand
 better how it works. But basically the board file (config data)
 creates a struct when the first field (variable) is the config
 struct used the but SButton driver (``drivers/input/sbutton.c``).

@@ -59,7 +59,7 @@ Files supporting USERLED can be found in the following locations:
 
 Something important to note is that your board initialization code (normally named ``<arch>_bringup.c`` should call the function to register the driver.
 
-For stm32f4discovery board this initialization code is placed at ``boards/arm/stm32/stm32f4discovery/src/stm32_bringup.c`` and this is the block responsible to initialize the subsystem:
+For stm32f4discovery board this initialization code is placed at ``boards/arm/stm32f4/stm32f4discovery/src/stm32_bringup.c`` and this is the block responsible to initialize the subsystem:
 
 .. code-block:: C
 

@@ -39,7 +39,7 @@ Serial Device Drivers
    `character drivers <#chardrivers>`__ and are accessed as other
    character drivers.
 
--  **Examples**: ``arch/arm/src/stm32/stm32_serial.c``,
+-  **Examples**: ``arch/arm/src/common/stm32/stm32_serial_m3m4_v1v2v3v4.c``,
    ``arch/arm/src/lpc214x/lpc214x_serial.c``,
    ``arch/z16/src/z16f/z16f_serial.c``, etc.
 

@@ -85,7 +85,7 @@ LCDs
   Generic LCD driver for LCDs based on the Solomon Systech
   SSD1289 LCD controller. Think of this as a template for an LCD driver
   that you will probably have to customize for any particular LCD
-  hardware. (See also boards/arm/stm32/hymini-stm32v/src/ssd1289.c below).
+  hardware. (See also boards/arm/stm32f1/hymini-stm32v/src/ssd1289.c below).
 
 - ``st7567.c``
 
@@ -120,7 +120,7 @@ OLEDs
   OLED Display Module, UUG-2864AMBAG01, Univision Technology Inc.
   Based on the SH1101A controller.  Example usage::
 
-      boards/arm/stm32/stm32f4discovery
+      boards/arm/stm32f4/stm32f4discovery
       boards/arm/lpc214x/zp214xpa
 
 - ``ug-9664hswag01.c``
@@ -140,7 +140,7 @@ OLEDs
   Densitron Technologies DD-12864WO-4A which is based on SSD1309 LCD
   controller. Example usage::
 
-      boards/arm/stm32/stm32f4discovery
+      boards/arm/stm32f4/stm32f4discovery
       boards/arm/sam34/sam4l-xplained
 
 Segment LCDS (SLCDs)

@@ -29,7 +29,7 @@ SDIO Device Drivers
    #. Provide that instance to the initialization method of the
       higher level device driver.
 
--  **Examples**: ``arch/arm/src/stm32/stm32_sdio.c`` and
+-  **Examples**: ``arch/arm/src/common/stm32/stm32_sdio_m3m4_v1.c`` and
    ``drivers/mmcsd/mmcsd_sdio.c``
 
 Implementing an SDIO lower-half

@@ -19,7 +19,7 @@ USB Device-Side Drivers
    ``arch/arm/src/lpc17xx_40xx/lpc17_40_usbdev.c``,
    ``arch/arm/src/lpc214x/lpc214x_usbdev.c``,
    ``arch/arm/src/lpc313x/lpc313x_usbdev.c``, and
-   ``arch/arm/src/stm32/stm32_usbdev.c``.
+   ``arch/arm/src/common/stm32/stm32_usbdev_m3m4_v1.c``.
 
 -  ``struct usbdevclass_driver_s``. Each USB device class
    driver must implement an instance of

@@ -17,7 +17,7 @@ USB Host-Side Drivers
 
 
    **Examples**: ``arch/arm/src/lpc17xx_40xx/lpc17_40_usbhost.c``,
-   ``arch/arm/src/stm32/stm32_otgfshost.c``,
+   ``arch/arm/src/common/stm32/stm32_otgfshost_m3m4_v1.c``,
    ``arch/arm/src/sama5/sam_ohci.c``, and
    ``arch/arm/src/sama5/sam_ehci.c``.
 

@@ -227,7 +227,7 @@ squash before submitting the Pull Request:
 
     .. code-block:: bash
 
-       arch/arm/stm32/: Add arch support for stm32 platform
+       arch/arm/stm32f4/: Add arch support for stm32f4 platform
 
        This patch adds initial support for stm32 platform. Please read
        the documentation included for more details how to wire the display.

diff --git a/Documentation/guides/changing_systemclockconfig.rst b/Documentation/guides/changing_systemclockconfig.rst
@@ -28,7 +28,7 @@ Custom Clock Configuration
 The ``configs/vsn/`` configuration does something like you say. It skips the 
 initial clock configuration by defining 
 ``CONFIG_ARCH_BOARD_STM32_CUSTOM_CLOCKCONFIG=y``. Then the normal clock 
-configuration logic in ``arch/arm/src/stm32/stm32_rcc.c`` is not executed.
+configuration logic in ``arch/arm/src/stm32f4/stm32_rcc.c`` is not executed.
 Instead, the "custom" clock initialization at ``configs/vsn/src/sysclock.c``
 is called:
 
@@ -83,7 +83,7 @@ are hardcoded in the board.h header file. So you have two options:
 
 2. **Variable Peripheral Clocking**. You can make the peripheral clocking 
    variable. I had to do this for the SAMA5Dx family. Look at 
-   ``boards/arm/stm32/sama5d4-ek/include/board_sdram.h`` for example. Notice 
+   ``boards/arm/sama5/sama5d4-ek/include/board_sdram.h`` for example. Notice
    that the frequencies are not constants, but function calls:
 
 .. code-block:: c

diff --git a/Documentation/guides/etcromfs.rst b/Documentation/guides/etcromfs.rst
@@ -86,7 +86,7 @@ behave as follows at Nuttx start-up time:
 ``CONFIG_ETC_ROMFS=y`` in the NuttX configuration file. They might
 provide useful examples:
 
-  -  ``boards/arm/stm32/hymini-stm32v/nsh2``
+  -  ``boards/arm/stm32f1/hymini-stm32v/nsh2``
   -  ``boards/arm/dm320/ntosd-dm320/nsh``
   -  ``boards/sim/sim/sim/nsh``
   -  ``boards/sim/sim/sim/nsh2``

@@ -61,4 +61,5 @@ Guides
   optee.rst
   qemu_tips.rst
   lwl.rst
+  stm32_ports.rst
 
diff --git a/Documentation/guides/ipv6.rst b/Documentation/guides/ipv6.rst
@@ -218,7 +218,7 @@ Board Configurations
 
 At present, there are three board configuration that are pre-configured to 
 use IPv6: ``nuttx/boards/arm/tiva/dk-tm4c129x/configs/ipv6``, 
-``nuttx/boards/arm/stm32/stm32f4discovery/ipv6``, and 
+``nuttx/boards/arm/stm32f4/stm32f4discovery/ipv6``, and
 ``nuttx/boards/arm/tiva/tm4c1294-launchpad/configs/ipv6``. These default 
 configurations have only IPv6 enabled. But the `README` files at in those 
 board directories describes how to enable `both` IPv4 and IPv6 simultaneously.
@@ -345,4 +345,4 @@ the network utils (``netutils``).
 * Netutils: The network utilities in ``apps/netutils`` have been adapted to 
   work with IPv6: DHCP, FTP, TFTP, Telnet, etc. Support for managing IPv6 
   address have been included in the ``netlib``, but nothing else has yet been 
-  updated.
+  updated.
diff --git a/Documentation/guides/nsh_network_link_management.rst b/Documentation/guides/nsh_network_link_management.rst
@@ -45,7 +45,7 @@ must be satisfied:
   are implemented for Atmel SAM4/4, SAMA5 families, and for the STMicro STM32.
   See ``nuttx/arch/arm/src/sam34/sam_emac.c``,
   ``nuttx/arch/arm/src/sam34/sam_emaca.c``, ``sam_emacb.c``, and ``sam_gmac.c``,
-  and ``nuttx/arch/arm/src/stm32/stm32_eth.c``.
+  and ``nuttx/arch/arm/src/common/stm32/stm32_eth_m3m4_v1.c``.
 - ``CONFIG_ARCH_PHY_INTERRUPT``  
   This is not a user-selectable option. Rather, it is set when selecting a board
   that supports PHY interrupts. In most architectures, the PHY interrupt is not

@@ -52,7 +52,7 @@ Precautions
 1.If you need to implement the ofloader on a different board,
 you will need to read the `wiki <https://wiki.segger.com/SEGGER_Flash_Loader>`
 and refer to the implementation of "ofloader.ld" linker script located
-in the "boards/arm/stm32/stm32f429i-disco/scripts" directory.
+in the "boards/arm/stm32f4/stm32f429i-disco/scripts" directory.
 This linker script defines how the different sections of the NuttX image are placed in memory.
 You should configure the corresponding sections to be located in RAM,
 where the J-Link can write the image correctly.

diff --git a/Documentation/guides/partially_linked_elf.rst b/Documentation/guides/partially_linked_elf.rst
@@ -40,7 +40,7 @@ compatible with the example provided here:
 
    In this example, let's illustrate this using an STM32F4-Discovery
    configuration. We will assume that you have modified the
-   ``boards/arm/stm32/stm32fdiscovery/src/stm32_bringup.c`` file, adding the
+   ``boards/arm/stm32f4/stm32f4discovery/src/stm32_bringup.c`` file, adding the
    following:
 
    .. code-block:: c

diff --git a/Documentation/guides/port_drivers_to_stm32f7.rst b/Documentation/guides/port_drivers_to_stm32f7.rst
@@ -191,7 +191,7 @@ An Example
 There is a good example in the STM32 Ethernet driver. The STM32 F7 
 Ethernet driver (``arch/arm/src/stm32f7/stm32_ethernet.c``) derives 
 directly from the STM32 F4 Ethernet driver 
-(``arch/arm/src/stm32/stm32_eth.c``). These two Ethernet MAC peripherals 
+(``arch/arm/src/common/stm32/stm32_eth_m3m4_v1.c``). These two Ethernet MAC peripherals
 are nearly identical. Only changes that are a direct consequence of the 
 STM32 F7 D-Cache were required to make the driver work on the STM32 F7. 
 Those changes are summarized below.

diff --git a/Documentation/guides/protected_build.rst b/Documentation/guides/protected_build.rst
@@ -177,18 +177,18 @@ Files and Directories
 Here is a summary of directories and files used by the STM32F4Discovery
 protected build:
 
-* ``boards/arm/stm32/stm32f4discovery/configs/kostest``. This is the kernel
+* ``boards/arm/stm32f4/stm32f4discovery/configs/kostest``. This is the kernel
   mode OS test configuration. The two standard configuration files
   can be found in this directory: (1) ``defconfig`` and (2) ``Make.defs``.
-* ``boards/arm/stm32/stm32f4discovery/kernel``. This is the first past
+* ``boards/arm/stm32f4/stm32f4discovery/kernel``. This is the first past
   build directory. The Makefile in this directory is invoked to
   produce the pass1 object (``nuttx_user.elf`` in this case). The
   second pass object is created by ``arch/arm/src/Makefile``. Also
   in this directory is the file ``userspace.c``. The user-mode blob
   contains a header that includes information need by the kernel
   blob in order to interface with the user-code. That header is
   defined in by this file.
-* ``boards/arm/stm32/stm32f4discovery/scripts``. Linker scripts for
+* ``boards/arm/stm32f4/stm32f4discovery/scripts``. Linker scripts for
   the kernel mode build are found in this directory. This includes
   (1) ``memory.ld`` which hold the common memory map, (2) ``user-space.ld``
   that is used for linking the pass1 user-mode blob, and (3)
@@ -314,11 +314,11 @@ Comparing the "Flat" Build Configuration with the Protected Build Configuration
 ===============================================================================
 
 Compare, for example the configuration
-``boards/arm/stm32/stm32f4discovery/configs/ostest`` and the
-configuration ``boards/arm/stm32/stm32f4discovery/configs/kostest``.
+``boards/arm/stm32f4/stm32f4discovery/configs/ostest`` and the
+configuration ``boards/arm/stm32f4/stm32f4discovery/configs/kostest``.
 These two configurations are identical except that one builds a
 "flat" version of OS test and the other builds a kernel version
-of the OS test. See the file ``boards/arm/stm32/stm32f4discovery/README.txt``
+of the OS test. See the file ``boards/arm/stm32f4/stm32f4discovery/README.txt``
 for more details about those configurations.
 
 The configurations can be compared using the ``cmpconfig`` tool:
@@ -328,7 +328,7 @@ The configurations can be compared using the ``cmpconfig`` tool:
     cd tools
     make -f Makefile.host cmpconfig
     cd ..
-    tools/cmpconfig boards/arm/stm32/stm32f4discovery/configs/ostest/defconfig boards/arm/stm32/stm32f4discovery/configs/kostest/defconfig
+    tools/cmpconfig boards/arm/stm32f4/stm32f4discovery/configs/ostest/defconfig boards/arm/stm32f4/stm32f4discovery/configs/kostest/defconfig
 
 Here is a summary of the meaning of all of the important differences in the
 configurations. This should be enough information for you to convert any
@@ -337,7 +337,7 @@ configuration from a "flat" to a protected build:
 * ``CONFIG_BUILD_2PASS=y``. This enables the two pass build.
 * ``CONFIG_BUILD_PROTECTED=y``. This option enables the "two pass"
   protected build.
-* ``CONFIG_PASS1_BUILDIR="boards/arm/stm32/stm32f4discovery/kernel"``.
+* ``CONFIG_PASS1_BUILDIR="boards/arm/stm32f4/stm32f4discovery/kernel"``.
   This tells the build system the (relative) location of the pass1 build directory.
 * ``CONFIG_PASS1_OBJECT=""``. In some "two pass" build configurations,
   the build system need to know the name of the first pass object.
@@ -382,7 +382,7 @@ configuration from a "flat" to a protected build:
   These includes such things as initializing device drivers.
   These same initialization steps must be performed in kernel
   mode for the protected build and ``CONFIG_BOARD_LATE_INITIALIZE``.
-  See ``boards/arm/stm32/stm32f4discovery/src/up_boot.c`` for an
+  See ``boards/arm/stm32f4/stm32f4discovery/src/up_boot.c`` for an
   example of such board initialization code.
 
 Architecture-Specific Options:
@@ -409,8 +409,8 @@ Size Expansion
 The protected build will, or course, result in a FLASH image that is
 larger than that of the corresponding "flat" build. How much larger?
 I don't have the numbers in hand, but you can build
-``boards/arm/stm32/stm32f4discovery/configs/nsh`` and
-``boards/arm/stm32/stm32f4discovery/configs/kostest`` and compare
+``boards/arm/stm32f4/stm32f4discovery/configs/nsh`` and
+``boards/arm/stm32f4/stm32f4discovery/configs/kostest`` and compare
 the resulting binaries for yourself using the ``size`` command.
 
 Increases in size are expected because:

diff --git a/Documentation/guides/smaller_vector_tables.rst b/Documentation/guides/smaller_vector_tables.rst
@@ -202,7 +202,7 @@ Most ARMv7-M architectures support two mechanism for handling interrupts:
   ``CONFIG_ARMV7M_CMNVECTOR=y`` that can be found in 
   ``arch/arm/src/armv7-m/``, and
 * MCU-specific interrupt handling logic. For the 
-  STM32, this logic can be found at ``arch/arm/src/stm32/gnu/stm32_vectors.S``.
+  STM32, this logic can be found at ``arch/arm/src/stm32f4/gnu/stm32_vectors.S``.
 
 The `common` vector logic is slightly more efficient, 
 the MCU-specific logic is slightly more flexible.
@@ -229,7 +229,7 @@ This technical approach requires changes to three files:
   define ``only`` the small set of 20 ``mapped`` IRQ numbers in 
   the range from 0 through 19. It would also set ``NR_IRQS`` 
   to the value 20.
-* A new header file at ``arch/arm/src/stm32/hardware``, say 
+* A new header file at ``arch/arm/src/stm32f4/hardware``, say
   ``xyz_vector.h``. It would be similar to the other vector 
   definitions files in that directory: It will consist 
   of a sequence of 100 ``VECTOR`` and ``UNUSED`` macros. It will 
@@ -248,7 +248,7 @@ This has all been replaced with the common vector handling at
 Vector Definitions
 ==================
 
-In ``arch/arm/src/stm32/gnu/stm32_vector.S``, notice that the 
+In ``arch/arm/src/stm32f4/gnu/stm32_vectors.S``, notice that the
 ``xyz_vector.h`` file will be included twice. Before each 
 inclusion, the macros ``VECTOR`` and ``UNUSED`` are defined.
 
@@ -290,7 +290,7 @@ file like this:
     ...
 
 Where the value of ``STM32_IRQ_USART1`` was defined to 
-be 12 in the ``arch/arm/include/stm32/xyz_irq.h`` header 
+be 12 in the ``arch/arm/include/stm32f4/xyz_irq.h`` header
 file. When ``xyz_vector.h`` is included by ``stm32_vectors.S`` 
 with the above definitions for ``VECTOR`` and ``UNUSED``, the 
 following would result:
@@ -349,7 +349,7 @@ second time the ``xzy_vector.h`` is included by ``stm32_vectors.S``:
 In the above USART1 example, a single handler would be 
 generated that will provide the IRQ number 12. Remember 
 that 12 is the expansion of the macro ``STM32_IRQ_USART1`` 
-that is provided in the ``arch/arm/include/stm32/xyz_irq.h`` 
+that is provided in the ``arch/arm/include/stm32f4/xyz_irq.h``
 header file:
 
 .. code-block:: asm