Hi All,
The CPU’s on our unmatched board has four U74 cores and a single S7 core. When booted into Linux i can see the S7 core in the devicetree and it seems it isn’t used at all.
Is there a way to actually use this S7 core?
There absolutely is, though the ability might not be exposed to Linux users right now. If you’re doing bare metal programming, then no problem.
If you’re running Linux then you’d have to read the boot code to see how it’s been set up. It’s probably sitting in a loop with a PAUSE or WFI. Hopefully the interrupt vector is set to somewhere useful, such as in its ITIM at 0x0180_0000. You could then write some code into that memory and send the core an interrupt by writing to the hart 0 msip bit at 0x0200_0000.
You need to be running M mode to do this, which probably means adding something into SBI to support it.
Assuming no one has already done the work to support using the S7 core in Linux, which I assume has not been done.
I couldn’t find how it’s set up … but that could be my fault since i’m not very familiar with this area 
. I did notice that the devicetree lists the S7 core with “status=disabled”. I couldn’t find the code that reads this property to see the action that’s taken.
The wfi loop is in u-boot. The linux support for status is presumably this
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/riscv/kernel/cpu.c?h=v5.14-rc3#n15
and see the definition for of_device_is_available
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/of/base.c?h=v5.14-rc3#n589
It has to be disabled as far as Linux is concerned, always, because it does not implement the RV64GC instruction set that Linux requires.
Using the S7 core would be something at a lower level than Linux.
Bruce is correct: RISC-V Linux does not currently support the “S7 monitor core” on the FU-740 SoC. Like Bruce says, Linux expects (at least) the RV64IMAFDC ISA, whereas the monitor core is missing the “FD” part, i.e., single- and double-precision floating point. Of course, these could be simulated with soft-float, you’d just have to build your own kernel/libraries to do so.
Perhaps a more serious issue is that – I believe – Linux also expects support for “user” and “supervisor” privilege modes. The monitor core supports user mode, but (I think) not supervisor mode. I imagine it’s possible to get Linux to run in (omnipresent) machine mode, but I suspect this would be a major undertaking.
Another absence is virtual memory: the monitor core has no MMU. However, there have been successful efforts to port/run Linux on microcontrollers without virtual memory. I don’t see why similar techniques couldn’t be applied to the monitor core.
There are probably more hardware absences, and there are probably software workarounds for each.
I suspect it’s technologically possible to port Linux to the monitor core; however, after a certain amount of hacking, can you still call it “Linux”? The real issue, as I see it, is a practical one: this type of work requires the dedicated attention of an experienced Linux developer. And, in addition to the engineering effort, there’s the political question of whether the Linux community would welcome these patches upstream.
1 Like
You absolutely DO NOT want to run Linux on the S7 code. That’s completely ridiculous.
What would be useful would be to run Linux on the other four cores that are designed for it, but have some standard mechanism from Linux to download bare metal code into the S7’s ITIM (or elsewhere), and get it to execute.
You’d want to make sure that only root (or a user in some new special group) could do it, and you’d need to have a way for the root (or whatever) user to break out of Linux’s S mode and do things in M mode – which is normally the province of OpenSBI only. Thus you’d need to modify OpenSBI to add support for this. And probably modify the Linux kernel to have some syscall to use the OpenSBI support.
I’m just pondering (not volunteering) what would be practical applications for the S7 core?
Something that could actually be used in OpenSBI.
Mining Doge?
You could – with a lot of work – offload all kinds of things on to it. Managing I/O, compression and encryption, zeroing memory pages…
1 Like
OpenCL maybe? That’s what’s used to run the C66X DSP cores from Linux on the TI AM5728.
This was exactly what i was thinking of. I know that it’s impossible to actually run Linux or any application on it. But reserving some memory, placing appropriate code there, and get it running could be fun 
That sounds like more than I can do
My first thought was to use the S7 as a trusted element, but it seems that it has no private memory. Having to share the peripherals with the main OS is also a bit limiting.
Linux’s remoteproc API might be useful here. It offers a basic abstraction for using heterogeneous cores, such as allocating contiguous communication buffers, firmware uploading, invocation.
1 Like
I thought DTIM is private to S7, but I could be wrong.
The documentation doesn’t directly say either way, but the DTIM is included in the main memory map.
Perhaps it needs to be a full GC core, but perhaps offloaded eBPF? Or some sort of lowRISC style “minion core” to do memory tagging?
1 Like
That’s what PMP is for.
Ohhhh … that’s very interesting.
That is true. I had only skimmed the PMP section, and had missed that locked entries also affect M-mode. There’s still the question of external bus masters (and probably a ton of other things for something that would be actually secure.)
The only way to be sure would be to try (at a sufficient privilege level), but from my reading of the FU740-C000 manual I think the DTIM is local to the S7 core-
- 1.1 Figure 1 groups a “SRAM” with the S7 core, my only possible interpretation of this is that the “DTIM” is meant here.
- 3.4 “Data Memory Subsystem” mentions that “A design cannot have both data cache and DTIM”. I would surmise “design” refers to the individual core design here. Only the S7 doesn’t have a data cache.
- 3.4.1 “Data Tightly-Integrated Memory (DTIM)” is only mentioned in the S7 chapter
- 4.4 “Data Memory Subsystem” for U74 doesn’t mention DTIM at all. It does again mention that a design cannot have both DTIM and data cache. The U74 does have a data cache.
There are also references to an ITIM but these seem to be leftover from the Unleashed manual. However, it is mentioned in 3.4.1 that it is possible to execute instructions from the DTIM. But storing both code along with private keys in 8kB is going to be somewhat cramped.