Hi,
I have a kernel call that starts RISC OS, and uses psci. I wonder , where should I put that very aarch64 dependent code. I somehow need to be able to call it from userspace.
Regarding kernel calls in general , what is the best way of calling them? Right now I do "MOV x0,#number ; SVC" , probably not very Genode style! :)
Hi Michael,
I'm not that much into the discussion, but I assume you are using the base-hw kernel. In this kernel, public kernel calls (allowed in userland) are located in [1]. If you don't have more than 5 arguments and 1 return value to your call, you can simply use the same generic 'Kernel::call' function as in the other kernel calls. The RISCV back end of this is located in [2] with the most interesting part being the CALL_1_SWI define.
Does this help?
Cheers, Martin
[1] repos/base-hw/include/kernel/interface.h [2] repos/base-hw/src/core/spec/riscv/kernel/interface.cc
On 03.03.21 23:22, Michael Grunditz wrote:
Hi,
I have a kernel call that starts RISC OS, and uses psci. I wonder , where should I put that very aarch64 dependent code. I somehow need to be able to call it from userspace.
Regarding kernel calls in general , what is the best way of calling them? Right now I do "MOV x0,#number ; SVC" , probably not very Genode style! :)
... I forgot to mention that you have to introduce a new unique ID for your call in [1] like:
! constexpr Call_arg call_id_my_command() { return 21; }
The ID should be above 20 (0..20 are existing user syscalls) and below 100 (the core syscalls start there). Best practice would be using the lowest free user syscall ID (21).
Cheers
[1] repos/base-hw/include/kernel/interface.h
On 04.03.21 10:10, Martin Stein wrote:
Hi Michael,
I'm not that much into the discussion, but I assume you are using the base-hw kernel. In this kernel, public kernel calls (allowed in userland) are located in [1]. If you don't have more than 5 arguments and 1 return value to your call, you can simply use the same generic 'Kernel::call' function as in the other kernel calls. The RISCV back end of this is located in [2] with the most interesting part being the CALL_1_SWI define.
Does this help?
Cheers, Martin
[1] repos/base-hw/include/kernel/interface.h [2] repos/base-hw/src/core/spec/riscv/kernel/interface.cc
Hello Michael,
On Wed, Mar 03, 2021 at 11:22:33PM +0100, Michael Grunditz wrote:
Hi,
I have a kernel call that starts RISC OS, and uses psci. I wonder , where should I put that very aarch64 dependent code. I somehow need to be able to call it from userspace.
Regarding kernel calls in general , what is the best way of calling them? Right now I do "MOV x0,#number ; SVC" , probably not very Genode style! :)
Actually, there is already support for what you are looking for, I think. As far as I understood it correctly, you want to wake up the Cortex-M4 (side-) processor, after you've prepared RiscOS to run on top of it?
Of course, you should not just add a system call that can be executed by every component to do something like this ;-). But we already had similar needs, when doing power control inside of the platform driver for i.MX 8M. There are some GPC controls that are done by the ARM Trusted firmware. Therefore we extended a previously existent privilege to the so called "managing_system" privilege that can be given when creating a new PD resp. component. This privilege is typically given only to the platform driver. With it a component can do a "managing_system(State&)" call on its PD session. This call transfers registers (State == Cpu_state) to core, which on will do a "secure monitor call" with the given registers (at least on ARMv8). For further understanding, please grep for "managing_system" inside base and base-hw.
To sum it up, you could define a specific "Power_domain" for the M4 in the platform driver of your board, and then do the corresponding SMC call therein using the managing_system call. Your application doing the RiscOS loading just needs to acquire the device with the M4 Power_domain from the platform driver at the point where you want to power it, and release it again when you want to power it off.
This way, you will have a secure and sane integration of the M4 handling.
I hope I could somehow express myself comprehensivly.
Best regards Stefan
-- Michael Grunditz Sent from my RISC OS workstation..
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
You can't run riscos on a m4, I am running on a53 core1. I will reply better later today.
Den fre 5 mars 2021 12:08Stefan Kalkowski stefan.kalkowski@genode-labs.com skrev:
Hello Michael,
On Wed, Mar 03, 2021 at 11:22:33PM +0100, Michael Grunditz wrote:
Hi,
I have a kernel call that starts RISC OS, and uses psci. I wonder ,
where
should I put that very aarch64 dependent code. I somehow need to be able to call it from userspace.
Regarding kernel calls in general , what is the best way of calling
them?
Right now I do "MOV x0,#number ; SVC" , probably not very Genode style!
:)
Actually, there is already support for what you are looking for, I think. As far as I understood it correctly, you want to wake up the Cortex-M4 (side-) processor, after you've prepared RiscOS to run on top of it?
Of course, you should not just add a system call that can be executed by every component to do something like this ;-). But we already had similar needs, when doing power control inside of the platform driver for i.MX 8M. There are some GPC controls that are done by the ARM Trusted firmware. Therefore we extended a previously existent privilege to the so called "managing_system" privilege that can be given when creating a new PD resp. component. This privilege is typically given only to the platform driver. With it a component can do a "managing_system(State&)" call on its PD session. This call transfers registers (State == Cpu_state) to core, which on will do a "secure monitor call" with the given registers (at least on ARMv8). For further understanding, please grep for "managing_system" inside base and base-hw.
To sum it up, you could define a specific "Power_domain" for the M4 in the platform driver of your board, and then do the corresponding SMC call therein using the managing_system call. Your application doing the RiscOS loading just needs to acquire the device with the M4 Power_domain from the platform driver at the point where you want to power it, and release it again when you want to power it off.
This way, you will have a secure and sane integration of the M4 handling.
I hope I could somehow express myself comprehensivly.
Best regards Stefan
-- Michael Grunditz Sent from my RISC OS workstation..
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
-- Stefan Kalkowski Genode labs
https://github.com/skalk | https://genode.org
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
In message 20210305110844.dl5rao6mntiugjc5@genode-labs.com Stefan Kalkowski stefan.kalkowski@genode-labs.com wrote:
Hello Michael,
On Wed, Mar 03, 2021 at 11:22:33PM +0100, Michael Grunditz wrote:
Hi,
I have a kernel call that starts RISC OS, and uses psci. I wonder , where should I put that very aarch64 dependent code. I somehow need to be able to call it from userspace.
Regarding kernel calls in general , what is the best way of calling them? Right now I do "MOV x0,#number ; SVC" , probably not very Genode style! :)
Actually, there is already support for what you are looking for, I think. As far as I understood it correctly, you want to wake up the Cortex-M4 (side-) processor, after you've prepared RiscOS to run on top of it?
RISC OS doesn't run on a M4, it is a desktop OS. Even if it is very light and no overhead, it needs a proper cpu
Of course, you should not just add a system call that can be executed by every component to do something like this ;-). But we already had similar needs, when doing power control inside of the platform driver for i.MX 8M. There are some GPC controls that are done by the ARM Trusted firmware. Therefore we extended a previously existent privilege to the so called "managing_system" privilege that can be given when creating a new PD resp. component. This privilege is typically given only to the platform driver. With it a component can do a "managing_system(State&)" call on its PD session. This call transfers registers (State == Cpu_state) to core, which on will do a "secure monitor call" with the given registers (at least on ARMv8). For further understanding, please grep for "managing_system" inside base and base-hw.
I think that the startup call , and possible restart needs to be in a driver. I think that what you did wrote is about that, but I need to explore the sources to fully understand. I also need a interrupthandler for the MU. I just poll the Message Unit now ,which is fine for serial output from RISC OS. But I have started with a filing system, which probably would be good if it was interrupt driven. Yet a lot to decide ...
To sum it up, you could define a specific "Power_domain" for the M4 in the platform driver of your board, and then do the corresponding SMC call therein using the managing_system call. Your application doing the RiscOS loading just needs to acquire the device with the M4 Power_domain from the platform driver at the point where you want to power it, and release it again when you want to power it off.
This way, you will have a secure and sane integration of the M4 handling.
Thanks! Can this Power_domain thing also work for A53?
Michael
Hello Michael,
On Fri, Mar 05, 2021 at 12:54:14PM +0100, Michael Grunditz wrote:
In message 20210305110844.dl5rao6mntiugjc5@genode-labs.com Stefan Kalkowski stefan.kalkowski@genode-labs.com wrote:
Hello Michael,
On Wed, Mar 03, 2021 at 11:22:33PM +0100, Michael Grunditz wrote:
Hi,
I have a kernel call that starts RISC OS, and uses psci. I wonder , where should I put that very aarch64 dependent code. I somehow need to be able to call it from userspace.
Regarding kernel calls in general , what is the best way of calling them? Right now I do "MOV x0,#number ; SVC" , probably not very Genode style! :)
Actually, there is already support for what you are looking for, I think. As far as I understood it correctly, you want to wake up the Cortex-M4 (side-) processor, after you've prepared RiscOS to run on top of it?
RISC OS doesn't run on a M4, it is a desktop OS. Even if it is very light and no overhead, it needs a proper cpu
Ah ok sorry, I've misunderstood that.
Of course, you should not just add a system call that can be executed by every component to do something like this ;-). But we already had similar needs, when doing power control inside of the platform driver for i.MX 8M. There are some GPC controls that are done by the ARM Trusted firmware. Therefore we extended a previously existent privilege to the so called "managing_system" privilege that can be given when creating a new PD resp. component. This privilege is typically given only to the platform driver. With it a component can do a "managing_system(State&)" call on its PD session. This call transfers registers (State == Cpu_state) to core, which on will do a "secure monitor call" with the given registers (at least on ARMv8). For further understanding, please grep for "managing_system" inside base and base-hw.
I think that the startup call , and possible restart needs to be in a driver. I think that what you did wrote is about that, but I need to explore the sources to fully understand. I also need a interrupthandler for the MU. I just poll the Message Unit now ,which is fine for serial output from RISC OS. But I have started with a filing system, which probably would be good if it was interrupt driven. Yet a lot to decide ...
To sum it up, you could define a specific "Power_domain" for the M4 in the platform driver of your board, and then do the corresponding SMC call therein using the managing_system call. Your application doing the RiscOS loading just needs to acquire the device with the M4 Power_domain from the platform driver at the point where you want to power it, and release it again when you want to power it off.
This way, you will have a secure and sane integration of the M4 handling.
Thanks! Can this Power_domain thing also work for A53?
In general yes, I do not see what should stay against this. You still need an adapted version of the platform_driver for your specific setup, which implements the A53 Power_domain by using the "managing_system" so-to-say "SMC wrapper".
Regards Stefan
Michael
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
-
Martin Stein -
Michael Grunditz -
Stefan Kalkowski