Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move to and extend zephyr,memory-attr #60049

Merged
merged 3 commits into from
Jul 25, 2023

Conversation

carlocaione
Copy link
Collaborator

@carlocaione carlocaione commented Jul 5, 2023

The zephyr,memory-region-mpu property was added in #43119 as a convenient way to create and configure MPU regions using information coming from DT. It has been used a lot since it was introduced so I guess we can consider it a Zephyr success story ™ .

Unfortunately it has been proved to be a bit limited and with some important limitations:

  1. It was introduced as a property of the compatible zephyr,memory-region that is used to create linker regions and sections from DT data. This means that we can actually create MPU regions only for DT-defined regions and sections.
  2. The naming is unfortunate because it is implying that it is used only for MPU.
  3. It is misplaced being in include/zephyr/linker/devicetree_regions.h and still it has nothing to do with the linker at all.
  4. It is exporting a function called LINKER_DT_REGION_MPU that again has nothing to do with the linker.

Point (1) is also particularly limiting because it is preventing us to characterize memory regions that are not generated using the zephyr,memory-region compatible, like generic mmio-sram regions.

While we fix all the issues, we also want to extend a bit the range of usefulness of this property. We are renaming it zephyr,memory-attr and it is now carrying information about the type of memory the property is attached to (cacheable, non-cacheable, IO, eXecutable, etc...). The user can use this property and the DT API coming with it to act on the memory node it is accompanied by.

We are still providing the DT_MEMORY_ATTR_APPLY() macro that can be used to create the MPU regions as before, but we are adding also a DT_MEMORY_ATTR_FOREACH_NODE() macro that can be used to cycle through the memory nodes and act on those.

Some use-cases:

In general the idea is being able to detect and work with memory regions and their attributes in an easy way instead of resorting to custom code.

povergoing
povergoing previously approved these changes Jul 7, 2023
@microbuilder
Copy link
Member

@carlocaione Maybe we should add this change to the release notes now to make sure the change doesn't get lost?

hubertmis
hubertmis previously approved these changes Jul 14, 2023
@manuargue
Copy link
Member

Hi @carlocaione , changes for NXP S32 affected platforms LGTM. Approved that part.

Btw, I'm working on a pr to extend this feature to Cortex-A/R Aarch32, but I haven't had time to file a PR yet. And I also saw there's some big refactoring going on for those arch in another pr, so I think better I'll wait for that to get merged. My intention is to "normalize" the memory attribute names across all the Arm Aarch32 archs and to document (similarly to #60049 (review)) in a table what are the memory attributes assigned. Are you already working in something like this or would be fine to continue in this direction and raise a pr?

@carlocaione
Copy link
Collaborator Author

Btw, I'm working on a pr to extend this feature to Cortex-A/R Aarch32, but I haven't had time to file a PR yet. And I also saw there's some big refactoring going on for those arch in another pr, so I think better I'll wait for that to get merged. My intention is to "normalize" the memory attribute names across all the Arm Aarch32 archs and to document (similarly to #60049 (review)) in a table what are the memory attributes assigned. Are you already working in something like this or would be fine to continue in this direction and raise a pr?

I'm not working on it but it sounds like a very welcome improvement and I'm not currently working on it. So feel free to keep working on it if you are willing to, that definitely would help a lot.

doc/build/dts/api/api.rst Outdated Show resolved Hide resolved
dts/bindings/base/zephyr,memory-attr.yaml Show resolved Hide resolved
include/zephyr/devicetree/memory-attr.h Show resolved Hide resolved
include/zephyr/devicetree/memory-attr.h Outdated Show resolved Hide resolved
tests/lib/devicetree/api/src/main.c Show resolved Hide resolved
doc/releases/release-notes-3.5.rst Show resolved Hide resolved
The 'zephyr,memory-region-mpu' property was addede gqas a
convenient way to create and configure MPU regions using information
coming from DT. It has been used a lot since it was introduced so I
guess we can consider it a Zephyr success story ™ .

Unfortunately it has been proved to be a bit limited and with some
important limitations:

1. It was introduced as a property of the compatible
   zephyr,memory-region that is used to create linker regions and
   sections from DT data. This means that we can actually create MPU
   regions only for DT-defined regions and sections.
2. The naming is unfortunate because it is implying that it is used only
   for MPU.
3. It is misplaced being in include/zephyr/linker/devicetree_regions.h
   and still it has nothing to do with the linker at all.
4. It is exporting a function called LINKER_DT_REGION_MPU that again has
   nothing to do with the linker.

Point (1) is also particularly limiting because it is preventing us to
characterize memory regions that are not generated using the
'zephyr,memory-region' compatible, like generic mmio-sram regions.

While we fix all the issues, we also want to extend a bit the range of
usefulness of this property. We are renaming it 'zephyr,memory-attr' and
it is now carrying information about the type of memory the property is
attached to (cacheable, non-cacheable, IO, eXecutable, etc...). The user
can use this property and the DT API coming with it to act on the memory
node it is accompanied by.

We are still providing the DT_MEMORY_ATTR_APPLY() macro that can be used
to create the MPU regions as before, but we are adding also a
DT_MEMORY_ATTR_FOREACH_NODE() macro that can be used to cycle through
the memory nodes and act on those.

Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Move to 'zephyr,memory-attr' and use the newly introduced helpers.

Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Add DT changes to the 3.5 release notes.

Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Copy link
Member

@carlescufi carlescufi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks very reasonable to me

Copy link
Member

@microbuilder microbuilder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the release notes.

zassert_true(!strcmp(val_apply[1].name, "memory@44332211"), "");
zassert_equal(val_apply[1].base, 0x44332211, "");
zassert_equal(val_apply[1].size, 0x2000, "");
zassert_equal(val_apply[1].attr, 0xCACA, "");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this 0xCACA be REGION_RAM_NOCACHE_ATTR?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, maybe for readability but after all this is a test, so it doesn't really matter?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants