Usage of riscv proxy kernel in deeply embedded systems

[Isuru Madhusanka Rathnayaka]

I've read a significant amount on riscv compilation modes. But I'm still not clear about the usage of riscv proxy kernel in embedded systems. As far as I understand, codes compiled with Newlib (targeting embedded systems) are run on top of riscv-pk which provides an execution environment for the code.

If that is so, what is the case for deeply embedded systems. Are those systems too supposed to run riscv-pk, or is it preferred to run the code bare metal (which I understand as harder)?

I couldn't find a clear answer anywhere.

[Stefan O'Rear]

On Tue, Dec 13, 2016 at 10:21 PM, Isuru Madhusanka Rathnayaka
<isurura...@gmail.com> wrote:
> I've read a significant amount on riscv compilation modes. But I'm still not
> clear about the usage of riscv proxy kernel in embedded systems. As far as I
> understand, codes compiled with Newlib (targeting embedded systems) are run
> on top of riscv-pk which provides an execution environment for the code.

The proxy kernel is not a production system. It is a testing aid
which allows POSIX user code to be run on a very slow or otherwise
limited device, like a Verilog simulator (booting Linux on a netlist
simulation would take far too long).

As the name Proxy Kernel implies pk requires a connection to a host
system to function, and system calls are proxied to the host. Right
now this is MMIO but you could implement a UART version if you needed
for some project.

You could use newlib with a real (not pk) OS; the newlib project
appears to support real systems.

> If that is so, what is the case for deeply embedded systems. Are those
> systems too supposed to run riscv-pk, or is it preferred to run the code
> bare metal (which I understand as harder)?

Don't use pk. "deeply embedded" means different things to different
people, and there is a lot of unexplored territory here, but you could
try using the RTEMS port, or add a newlib BSP for your environment, or
something?

-s