llext: disable for Harvard ARC variants

[tagunil]

Some ARC processor configurations have separate memory for code (ICCM) and for data (DCCM). Such configurations are unsuitable for LLEXT, except for some quite special cases. For now, disable LLEXT and its tests for these devices completely.

[tagunil]

@laurenmurphyx64, I don't know which ARC cores you're interested in for LLEXT, so I'd like to have your input on that, as you are the person who enabled LLEXT for ARC in the first place.

[pillo79]

Nice, did not know about that symbol, it definitely is a good filter.

Not a blocker but maybe the LLEXT docs should mention that as well? Something along the lines of "Harvard architectures, that separate code and data paths, are not supported" would be enough IMO.

[ruuddw]

"Such configurations are unsuitable for LLEXT"
That's a limitation of current LLEXT, not a fundamental issue right? What's required to handle separate code and data segments? Just a LLEXT loader update, or are there other problems with Harvard architectures?

[tagunil]

Not a blocker but maybe the LLEXT docs should mention that as well? Something along the lines of "Harvard architectures, that separate code and data paths, are not supported" would be enough IMO.

Sure, I've just added the line to the docs in the updated commit.

[tagunil]

"Such configurations are unsuitable for LLEXT"
That's a limitation of current LLEXT, not a fundamental issue right? What's required to handle separate code and data segments? Just a LLEXT loader update, or are there other problems with Harvard architectures?

Well, the whole idea of LLEXT, as I see it, is to be able to load some executable code into data memory and execute it from there. So if our processor has no common memory, but only ICCM and DCCM, where should we load the code? DCCM is not an option, because the processor cannot execute from there, right? ICCM might be an option, if it's writable by the processor and if we could convince the linker to put all the buffers there, but does it make sense?

[ruuddw]

Execution from DCCM is blocked indeed (good for security as well). But ICCM supports both code and data (with some performance penalty, as instruction fetches and load/store instructions use the same port instead of independent ports). And a loader could also load the code part into ICCM and the data part in DCCM.

[tagunil]

Execution from DCCM is blocked indeed (good for security as well). But ICCM supports both code and data (with some performance penalty, as instruction fetches and load/store instructions use the same port instead of independent ports). And a loader could also load the code part into ICCM and the data part in DCCM.

I think the first option could be implemented if we hack our linker script to place the LLEXT heap into ICCM and rework the LLEXT_STORAGE_WRITABLE option into something like LLEXT_STORAGE_WRITABLE_EXECUTABLE. But the question is if it's worth the effort right now. Do we have any practical use case for LLEXT on these hardware configurations?

[laurenmurphyx64]

@laurenmurphyx64, I don't know which ARC cores you're interested in for LLEXT, so I'd like to have your input on that, as you are the person who enabled LLEXT for ARC in the first place.

But the question is if it's worth the effort right now. Do we have any practical use case for LLEXT on these hardware configurations?

@tagunil The best person for me to ask about what cores / configurations we're considering using is @teburd, but he's out of town for the next two weeks... I don't have any objections to this PR as it is, though, so I'll approve it.

[lyakh]

Execution from DCCM is blocked indeed (good for security as well). But ICCM supports both code and data (with some performance penalty, as instruction fetches and load/store instructions use the same port instead of independent ports). And a loader could also load the code part into ICCM and the data part in DCCM.

@ruuddw FWIW we do move different ELF sections to different memory regions / types in SOF application code, but with the current LLEXT API it isn't very convenient. It should improve if @teburd 's idea of separate load and link steps gets implemented

[ruuddw]

Thanks @lyakh for confirming that there is no fundamental issue with supporting ARC Harvard-style targets, just implementation work. I'm not aware of an urgent need for this support, we can wait for the simpler support of multiple regions. Maybe an ARC target can be used for testing that?

[evgeniy-paltsev]

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.

[tagunil]

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.

[teburd]

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.

[tagunil]

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.