boards: st: stm32h7s78_dk: add Ethernet support #99296

bklaric1 · 2025-11-13T09:32:49Z

Changes

Added mac and mdio configuration to stm32h7s78_dk-common.dtsi and enabled them. The RMII Ethernet pin configuration follows this schematic from ST: MB1736.
~~Added fallback option for definition of sram_eth_node in mpu_regions.c and sections.ld. This definition earlier defaulted to sram2, but now has sram1 as fallback option.~~ Defined the SRAM region for Ethernet descriptor and buffer
using memory-regions = <...> in the mac node (as discussed) and added the updated definition of sram_eth_node to mpu_regions.c and sections.ld. Also added the needed property in dts/bindings/ethernet/st,stm32h7-ethernet.yaml.
- Added memory-regions = <...> to boards/st/nucleo_h7s3l8/nucleo_h7s3l8.dts, since they use the same mpu_regions.c and sections.ld.
Updated stm32h7s78_dk.yaml and stm32h7s78_dk_stm32h7s7xx_ext_flash_app.yaml to include the Ethernet tag.
Updated index.rst to include the Ethernet feature and documented the steps needed in order to use Ethernet for this board.
Added tests/drivers/memc/ram/boards/stm32h7s78_dk_stm32h7s7xx_ext_flash_app.overlay and updated tests/drivers/memc/ram/boards/stm32h7s78_dk.overlay since Ethernet drivers fully consume sram1 node and thus fail the test without the additions.
Added #memory-region-cells = <0>; to all possible memory regions (sram1 and sram2 nodes) in dts/arm/st/h7rs/stm32h7rs.dtsi

Tests

I tested these changes with the following examples:

I could ping the board after flashing both samples and also open the website in the browser. Everything worked as expected.

Notes

I opened #99164 in order to discuss how to implement the fallback for sram2 and whether this approach is correct. Taking a look at the discussion should answer some questions about the implementation.

Closes #99164

bklaric1 · 2025-11-18T08:51:11Z

The #99505 should be resolved first before proceeding with the merge (if it even gets to that point), since the changes to mpu_regions.c might become obsolete.

soc/st/stm32/stm32h7rsx/mpu_regions.c

bklaric1 · 2025-11-20T11:03:59Z

Regarding the failed checks:

compliance check fail (intendation and trailing whitespace) will be fixed with the next commit

twister check error wasn't caused by changes that my commit introduced as far as I can say. The error output:

/opt/toolchains/zephyr-sdk-0.17.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: zephyr/zephyr_pre0.elf section `SRAM1' will not fit in region `SRAM1'
/opt/toolchains/zephyr-sdk-0.17.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: region `SRAM1' overflowed by 256 bytes

states that the SRAM1 region is overflowed. But the comment in the mpu_regions.c file states the following:

zephyr/soc/st/stm32/stm32h7rsx/mpu_regions.c

Line 39 in f1c2ce4

    
           /* Region 6 - Ethernet DMA descriptor RAM (overlays the first 256B of SRAM_ETH_BUF)*/

So I think this isn't relevant to the PR, but I might be wrong.

Note: next commit will also add - netif:eth to stm32h7s78_dk_stm32h7s7xx_ext_flash_app.yaml, since I forgot to add that.

etienne-lms

Could you squash to 2 commits?

dts/bindings/ethernet/st,stm32h7-ethernet.yaml

boards/st/stm32h7s78_dk/stm32h7s78_dk-common.dtsi

bklaric1 · 2025-11-26T09:06:10Z

Squashed upcoming commit into 2. commit and added the requested changes.

bklaric1 · 2025-11-26T09:33:35Z

Regarding the failed Compliance Check: I don't see the trailing whitespace that is being reported, neither locally nor in GitHub Web Editor, so I can't really fix this.

pdgendt · 2025-11-26T09:52:26Z

Regarding the failed Compliance Check: I don't see the trailing whitespace that is being reported, neither locally nor in GitHub Web Editor, so I can't really fix this.

Your first commit introduces a trailing whitespace, which is then fixed by your second commit. This isn't allowed.

bklaric1 · 2025-11-26T11:29:19Z

@pdgendt I edited the first commit and removed the trailing whitespace there. Hopefully this fixes the CI check error.

etienne-lms · 2025-12-03T06:52:00Z

Since I have already squashed the commits into one commit, should I still split them up or is the current single commit good enough?

This unique commit as-is makes sense to me.

I am open to looking into adding the memory-region property to mac node for H7x series. As you said, H7x and H7rs are similar enough. This should be done in a seperate PR, right?

Ok for another P-R.

soc/st/stm32/stm32h7rsx/mpu_regions.c

bklaric1 · 2025-12-03T08:38:30Z

@etienne-lms Amended the last commit to include the requested changes.
Edit: some requested changes might be wrong. Take a look at the review comments.

Question: do I need to add a (second) Copyright line when I edit an existing file or only when I create a new file?

bklaric1 · 2025-12-04T08:28:58Z

@etienne-lms I kindly ask again that you review my comments to your changes to see why the twister-builds fail (and how to fix the fail → revert to the #error ... block check I already had). That way this PR can move forward. Thanks in advance.

maass-hamburg · 2025-12-08T16:21:28Z

dts/bindings/ethernet/st,stm32h7-ethernet.yaml

 include: st,stm32-ethernet-common.yaml
+
+properties:
+  memory-region:


maybe have it consistent between the stm ethernet macs, and do it like in dts/bindings/ethernet/st,stm32mp13-ethernet.yaml and use memory-regions (with an s)

Missed the s. Will update.
But if we are trying to be consistent, shouldn't the property also include the required: true as in st,stm32mp13-ethernet.yaml?

zephyr/dts/bindings/ethernet/st,stm32mp13-ethernet.yaml

Lines 16 to 22 in a1970eb

properties:

memory-regions:

required: true

description: |

Memory region in which the Ethernet DMA lists and data buffers will be

placed. The memory region has to be non-cacheable and accessible by the

Ethernet peripheral.

Probably not, the soc/st/stm32/stm32h7x doesn't use it and we still want to be able to have it on the main ram by not setting it.
Implied by

BUILD_ASSERT(!DT_SAME_NODE(sram_eth_node, DT_CHOSEN(zephyr_sram)), "Remove property memory-region from 'mac' node " "to locate ethernet buffers in system RAM.")

But that's something the ST people (@etienne-lms )should decide

Added the s across the commit.

maass-hamburg · 2025-12-09T10:44:39Z

dts/bindings/ethernet/st,stm32h7-ethernet.yaml


 compatible: "st,stm32h7-ethernet"

 include: st,stm32-ethernet-common.yaml


add

include: - "st,stm32-ethernet-common.yaml" - "memory-region.yaml"

and remove type: phandle

If I do that, then I get the following error:

devicetree error: <Node /memory@30000000 in /zephyr/dts/arm/st/h7rs/stm32h7rs.dtsi:60> lacks #memory-region-cells

That line corresponds to sram1:

zephyr/dts/arm/st/h7rs/stm32h7rs.dtsi

Lines 60 to 65 in 923ece1

sram1: memory@30000000 {

reg = <0x30000000 DT_SIZE_K(16)>;

compatible = "zephyr,memory-region", "mmio-sram";

zephyr,memory-region = "SRAM1";

zephyr,memory-attr = <DT_MEM_ARM(ATTR_MPU_RAM)>;

};

The memory region stm32mp series uses for Ethernet is custom defined region and not predefined region as sram1 or sram2. And in that custom defined region the attribute #memory-region-cells is defined:

zephyr/boards/st/stm32mp135f_dk/stm32mp135f_dk.dts

Lines 78 to 83 in 923ece1

eth_ram: sram@2fffc000 {

compatible = "zephyr,memory-region", "mmio-sram";

reg = <0x2fffc000 DT_SIZE_K(16)>;

#memory-region-cells = <0>;

zephyr,memory-region = "ETH_SRAM";

};

What do you suggest here?
Note that I tried to get Ethernet working with custom region but wasn't successful.

add #memory-region-cells = <0>; to all possible memory regions?

Adding it fixes the mentioned error and doesn't break anything else with this build (http_server sample). I added it to the sram0, sram1 and sram2 nodes.
However, I can't guarantee that this addition doesn't break something else unrelated to Ethernet. I can add it to the commit and see if it triggers any twister-build errors. Would that work?

maass-hamburg · 2025-12-09T11:02:00Z

soc/st/stm32/stm32h7rsx/mpu_regions.c

+BUILD_ASSERT(!DT_SAME_NODE(sram_eth_node, DT_CHOSEN(zephyr_sram)),
+	     "Remove property memory-regions from 'mac' node "
+	     "to locate ethernet buffers in system RAM.")


you could do

#if DT_NODE_HAS_STATUS_OKAY(sram_eth_node) && !DT_SAME_NODE(sram_eth_node, DT_CHOSEN(zephyr_sram))

here and in the sections.ld file to get rid of the build assert

Removing assert and replacing it with a similar check works. For example, I already had this:

#if DT_NODE_HAS_COMPAT(sram_eth_node, zephyr_sram) #error "Invalid Ethernet memory-region: cannot use zephyr,sram. \ Use a SRAM region like sram1 or sram2 for Ethernet."

but @etienne-lms suggested BUILD_ASSERT instead.

then leave it

Okay. But what do I do about the failing twister-builds caused by the BUILD_ASSERT?

apply:

diff --git a/soc/st/stm32/stm32h7rsx/mpu_regions.c b/soc/st/stm32/stm32h7rsx/mpu_regions.c index 5384d8bb2a6..f28fdf8b5b4 100644 --- a/soc/st/stm32/stm32h7rsx/mpu_regions.c +++ b/soc/st/stm32/stm32h7rsx/mpu_regions.c @@ -34,10 +34,6 @@ static const struct arm_mpu_region mpu_regions[] = { DT_NODE_HAS_PROP(DT_NODELABEL(mac), memory_regions) #define sram_eth_node DT_PHANDLE(DT_NODELABEL(mac), memory_regions) -BUILD_ASSERT(!DT_SAME_NODE(sram_eth_node, DT_CHOSEN(zephyr_sram)), - "Remove property memory-regions from 'mac' node " - "to locate ethernet buffers in system RAM.") - #if DT_NODE_HAS_STATUS_OKAY(sram_eth_node) /* Region 5 - Ethernet DMA buffer RAM */ MPU_REGION_ENTRY("SRAM_ETH_BUF", DT_REG_ADDR(sram_eth_node), @@ -48,6 +44,12 @@ BUILD_ASSERT(!DT_SAME_NODE(sram_eth_node, DT_CHOSEN(zephyr_sram)), #endif }; +#ifdef sram_eth_node + BUILD_ASSERT(!DT_SAME_NODE(sram_eth_node, DT_CHOSEN(zephyr_sram)), + "Remove property memory-regions from 'mac' node " + "to locate ethernet buffers in system RAM."); +#endif + const struct arm_mpu_config mpu_config = { .num_regions = ARRAY_SIZE(mpu_regions), .mpu_regions = mpu_regions,

you can't do a BUILD_ASSERT inside a
static const struct arm_mpu_region mpu_regions[] = {

Add Ethernet configuration for mac and mdio nodes. Define the SRAM region for Ethernet descriptor and buffer using memory-regions = <...> in the mac node for this board and for nucleo_h7s3l8, since they both use the same mpu_regions.c and sections.ld files. Add memory-regions property to st,stm32h7-ethernet.yaml file. Update mpu_regions.c and sections.ld to use the region defined in board's .dtsi file. Add an assert to mpu_regions.c to check if the memory-region node refers to the zephyr,sram region. Disable mac node in .overlay files for tests/drivers/memc/ram since ethernet drivers that get enabled by it consume sram1 node and thus fail the test. Update the yaml files to include Ethernet tag and update documentation to explain Ethernet usage. Signed-off-by: Benjamin Klaric <benjamin.klaric01@gmail.com>

sonarqubecloud · 2025-12-09T14:26:18Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

etienne-lms · 2025-12-09T17:29:35Z

Question: do I need to add a (second) Copyright line when I edit an existing file or only when I create a new file

You don't need to add a copyright line at source/header files entry when you modify them to have your copyright implicitly taken into account. What drives the copyright owners list is the Git reversion history, which tracks all contributions, not the file entry inline comment.
You are free to add your copyright line, but it's not handy when each contributor adds its own line, especially for small modifications.

bklaric1 · 2025-12-10T08:25:46Z

You don't need to add a copyright line at source/header files entry when you modify them to have your copyright implicitly taken into account. What drives the copyright owners list is the Git reversion history, which tracks all contributions, not the file entry inline comment. You are free to add your copyright line, but it's not handy when each contributor adds its own line, especially for small modifications.

That is what I thought, just wanted to be sure. Thanks for the explanation. Noted for future PRs.

etienne-lms · 2025-12-10T07:59:51Z

soc/st/stm32/stm32h7rsx/mpu_regions.c

 };

+#ifdef sram_eth_node
+	BUILD_ASSERT(!DT_SAME_NODE(sram_eth_node, DT_CHOSEN(zephyr_sram)),


Indentation

Suggested change

BUILD_ASSERT(!DT_SAME_NODE(sram_eth_node, DT_CHOSEN(zephyr_sram)),

BUILD_ASSERT(!DT_SAME_NODE(sram_eth_node, DT_CHOSEN(zephyr_sram)),

etienne-lms · 2025-12-10T08:08:54Z

dts/arm/st/h7rs/stm32h7rs.dtsi

 		reg = <0x24000000 DT_SIZE_K(456)>;
 		compatible = "zephyr,memory-region", "mmio-sram";
 		zephyr,memory-region = "SRAM0";
+		#memory-region-cells = <0>;


Can be removed. We don't expect one to reference &sram0 as a memory-region phandle.

etienne-lms · 2025-12-10T08:14:34Z

dts/arm/st/h7rs/stm32h7rs.dtsi

 		compatible = "zephyr,memory-region", "mmio-sram";
 		zephyr,memory-region = "SRAM1";
+		#memory-region-cells = <0>;
 		zephyr,memory-attr = <DT_MEM_ARM(ATTR_MPU_RAM)>;


From the change made in #97731, won't sram1 MPU attributes here now conflicts with the one defined by mpu_regions.c?

That is partially what I was discussing with @TD-JBL in #99164.
I can only confirm that I get no errors during build process and Ethernet works as expected with either sram1 or sram2.

From the change made in #97731, won't sram1 MPU attributes here now conflicts with the one defined by mpu_regions.c?

Yes it will create 2 overlaying mpu regions for sram1 and the one from zephyr,memory-attr has the higher priority and should cause problems with caching on the dma region, but for whatever reason it seems to work.

etienne-lms · 2025-12-10T12:49:53Z

boards/st/nucleo_h7s3l8/nucleo_h7s3l8.dts

 	pinctrl-names = "default";
 	phy-connection-type = "rmii";
 	phy-handle = <&eth_phy>;
+	memory-regions = <&sram1>;


Maybe use sram2 to preserve to previous configuration?
Otherwise, the commit message should tell that h7rs based device ethnet buffers are now in sram1 (AXI SRAM1) by default instead of sram2 (AXI SRAM2).

sram1 and sram2 are AHB, sram0 is AXI sram (called sram 1-4 in the datasheet/rm)

sram2 is disabled by default. That is why I opted to use sram1.
I can switch to using sram2 but that requires the node to be enabled by default. Otherwise an introduction of a fallback is needed (to sram1).
What should I do here?
I will update the commit message in any case. Thanks @TD-JBL for clarification.

Yes the sram2 is disabled to have users enable it on purpose:

Use as normal ram: enabled it in your board and set zephyr,memory-attr = <DT_MEM_ARM(ATTR_MPU_RAM)>

Use it as dma buffer for ethernet, enable it in your board and let mpu_regions.c configure the mpu-region for it.
I don't mind changing this behaviour, maybe have it already enabled... not sure whats be best way

I don't think that preserving behavior is that important for a dev board

erwango

See comment for equivalent change on H7.
Please apply the same for H7RS (configure memory in .dtsi files)

zephyrbot added area: Boards/SoCs platform: STM32 ST Micro STM32 labels Nov 13, 2025

zephyrbot requested review from FRASTM, GeorgeCGV, djiatsaf-st, erwango, etienne-lms, gautierg-st, juickar and mathieuchopstm November 13, 2025 09:34

zephyrbot assigned erwango Nov 13, 2025

etienne-lms reviewed Nov 18, 2025

View reviewed changes

soc/st/stm32/stm32h7rsx/mpu_regions.c Outdated Show resolved Hide resolved

This was referenced Nov 20, 2025

samples: http_server: https variant not working on stm32h7s78dk #99737

Closed

boards: st: stm32h7s78_dk: add optional FDCAN support #99752

Closed

zephyrbot added area: Ethernet area: Devicetree Bindings labels Nov 24, 2025

zephyrbot requested review from ClaCodes, decsny, lmajewski, maass-hamburg and pdgendt November 24, 2025 15:34

etienne-lms reviewed Nov 24, 2025

View reviewed changes

dts/bindings/ethernet/st,stm32h7-ethernet.yaml Outdated Show resolved Hide resolved

boards/st/stm32h7s78_dk/stm32h7s78_dk-common.dtsi Outdated Show resolved Hide resolved

boards/st/stm32h7s78_dk/stm32h7s78_dk-common.dtsi Outdated Show resolved Hide resolved

bklaric1 force-pushed the feat-stm32h7s78_dk-ethernet branch from 2fdc201 to dc13beb Compare November 26, 2025 09:02

bklaric1 force-pushed the feat-stm32h7s78_dk-ethernet branch from dc13beb to 473226c Compare November 26, 2025 11:27

bklaric1 requested a review from etienne-lms December 2, 2025 10:33

etienne-lms reviewed Dec 3, 2025

View reviewed changes

soc/st/stm32/stm32h7rsx/mpu_regions.c Outdated Show resolved Hide resolved

soc/st/stm32/stm32h7rsx/mpu_regions.c Outdated Show resolved Hide resolved

soc/st/stm32/stm32h7rsx/mpu_regions.c Outdated Show resolved Hide resolved

bklaric1 force-pushed the feat-stm32h7s78_dk-ethernet branch from f24dfb6 to a491c3a Compare December 3, 2025 08:32

bklaric1 force-pushed the feat-stm32h7s78_dk-ethernet branch 5 times, most recently from 39967ac to 9884696 Compare December 3, 2025 14:05

bklaric1 requested a review from etienne-lms December 3, 2025 14:27

bklaric1 force-pushed the feat-stm32h7s78_dk-ethernet branch from 9884696 to a54f308 Compare December 3, 2025 14:31

bklaric1 force-pushed the feat-stm32h7s78_dk-ethernet branch from a54f308 to 99ec211 Compare December 8, 2025 15:37

maass-hamburg reviewed Dec 8, 2025

View reviewed changes

bklaric1 force-pushed the feat-stm32h7s78_dk-ethernet branch from 99ec211 to 1f3a8e3 Compare December 9, 2025 10:14

zephyrbot requested a review from maass-hamburg December 9, 2025 10:15

maass-hamburg reviewed Dec 9, 2025

View reviewed changes

bklaric1 force-pushed the feat-stm32h7s78_dk-ethernet branch from 1f3a8e3 to cd00b2c Compare December 9, 2025 13:59

zephyrbot requested a review from maass-hamburg December 9, 2025 14:00

maass-hamburg approved these changes Dec 9, 2025

View reviewed changes

etienne-lms reviewed Dec 10, 2025

View reviewed changes

bklaric1 mentioned this pull request Dec 11, 2025

boards: st: h7: add memory-regions property to mac node #100910

Open

bklaric1 requested a review from etienne-lms December 15, 2025 08:42

erwango requested changes Dec 15, 2025

View reviewed changes

	properties:
	memory-regions:
	required: true
	description: \|
	Memory region in which the Ethernet DMA lists and data buffers will be
	placed. The memory region has to be non-cacheable and accessible by the
	Ethernet peripheral.


		compatible: "st,stm32h7-ethernet"

		include: st,stm32-ethernet-common.yaml

	sram1: memory@30000000 {
	reg = <0x30000000 DT_SIZE_K(16)>;
	compatible = "zephyr,memory-region", "mmio-sram";
	zephyr,memory-region = "SRAM1";
	zephyr,memory-attr = <DT_MEM_ARM(ATTR_MPU_RAM)>;
	};

	eth_ram: sram@2fffc000 {
	compatible = "zephyr,memory-region", "mmio-sram";
	reg = <0x2fffc000 DT_SIZE_K(16)>;
	#memory-region-cells = <0>;
	zephyr,memory-region = "ETH_SRAM";
	};

	BUILD_ASSERT(!DT_SAME_NODE(sram_eth_node, DT_CHOSEN(zephyr_sram)),
	BUILD_ASSERT(!DT_SAME_NODE(sram_eth_node, DT_CHOSEN(zephyr_sram)),

boards: st: stm32h7s78_dk: add Ethernet support #99296

Are you sure you want to change the base?

boards: st: stm32h7s78_dk: add Ethernet support #99296

Conversation

bklaric1 commented Nov 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes

Tests

Notes

Uh oh!

bklaric1 commented Nov 18, 2025

Uh oh!

Uh oh!

bklaric1 commented Nov 20, 2025

Uh oh!

etienne-lms left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

bklaric1 commented Nov 26, 2025

Uh oh!

bklaric1 commented Nov 26, 2025

Uh oh!

pdgendt commented Nov 26, 2025

Uh oh!

bklaric1 commented Nov 26, 2025

Uh oh!

etienne-lms commented Dec 3, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

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

Uh oh!

Uh oh!

bklaric1 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!

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!

sonarqubecloud bot commented Dec 9, 2025

Quality Gate passed

Uh oh!

etienne-lms commented Dec 9, 2025

Uh oh!

bklaric1 commented Dec 10, 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!

bklaric1 commented Nov 13, 2025 •

edited

Loading

bklaric1 commented Dec 3, 2025 •

edited

Loading

bklaric1 Dec 11, 2025 •

edited

Loading