-
Notifications
You must be signed in to change notification settings - Fork 6.6k
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
Conversation
7ffb953
to
c8ccfd0
Compare
@carlocaione Maybe we should add this change to the release notes now to make sure the change doesn't get lost? |
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? |
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. |
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>
There was a problem hiding this 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
There was a problem hiding this 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, ""); |
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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?
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:
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.include/zephyr/linker/devicetree_regions.h
and still it has nothing to do with the linker at all.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 genericmmio-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 aDT_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.