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.

Sign up for GitHub

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

llext: disable for Harvard ARC variants #82491

Merged
merged 1 commit into from
Dec 16, 2024
+4 −0
Merged

llext: disable for Harvard ARC variants #82491

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions doc/services/llext/index.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,3 +22,5 @@ and introspected to some degree, as well as unloaded when no longer needed.

The LLEXT subsystem requires architecture-specific support. It is currently
available only on RISC-V, ARM, ARM64, ARC (experimental) and Xtensa cores.
Harvard architecture cores that separate code and data paths and have no
common memory are not supported.
Comment on lines +25 to +26
Copy link
Collaborator

Choose a reason for hiding this comment

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

Just a comment: for ARC with HARVARD (which in most of the cases means ICCM + DCCM usage) it's really easy to overcome this by loading to ICCM directly. moreover CCMs are uncached (cause they are already fast enough) - so we won't even need to have caches sync.

Copy link
Collaborator Author

@tagunil tagunil Dec 5, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

Sure, but neither LLEXT nor our linker scripts are exactly ready for that at the moment. Besides, it could be quite wasteful to load the whole ELF into ICCM (LLEXT_STORAGE_WRITABLE=y case) or to place the whole LLEXT heap into ICCM (LLEXT_STORAGE_WRITABLE=n case). Do our real-world Harvard configurations have enough ICCM to make it practical? If they do, we may prioritize such work to make it happen.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Right, I guess ideally we would need split heaps for this sort of architecture am I understanding this right? There's other reasons to consider this as well, like avoiding needing all of user mode for memory permission bits.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Right, I guess ideally we would need split heaps for this sort of architecture am I understanding this right? There's other reasons to consider this as well, like avoiding needing all of user mode for memory permission bits.

Yes, I think we should at least consider splitting the heap into executable and non-executable parts.

1 change: 1 addition & 0 deletions subsys/llext/Kconfig
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,7 @@ menuconfig LLEXT
bool "Linkable loadable extensions"
select CACHE_MANAGEMENT if DCACHE
select KERNEL_WHOLE_ARCHIVE
depends on !HARVARD
help
Enable the linkable loadable extension subsystem

Expand Down
1 change: 1 addition & 0 deletions tests/subsys/llext/simple/testcase.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,6 +13,7 @@ common:
- qemu_cortex_r5 # ARM Cortex-R5 (ARMv7-R ISA)
- mps2/an385 # ARM Cortex-M3 (ARMv7-M ISA)
- mps2/an521/cpu0 # ARM Cortex-M33 (ARMv8-M ISA)
filter: not CONFIG_HARVARD
extra_configs:
- arch:arm64:CONFIG_LLEXT_HEAP_SIZE=128
extra_conf_files:
Expand Down
Loading