What kind of CPU state shall be assigned to the remote core in a homogenous system?

[cnnblike]

Hi,
I'm looking into write set up a OpenAMP style Linux-RTOS on a quad core A35 SoC (RK3308, general with GIC-v2).
I'm now writing a rather generic driver for this use case, while the manufacturer of RK3308 don't have remoteproc driver eligible for use.
Ideally this will help OpenAMP greatly in ease of usage.

I want to make the system rather hot-plug-able, thus, without this .ko, linux can fully utilize all 4 cores, after an dt overlay with "homo-remoteproc" applied (and the specific core removed from cpu tree), this ko would start that core and boot the RTOS side.

I really want to reuse the cpuhp_hp_states and cpuhp_state for such scenario, but don't find a right state for this.

1. if I put an CPUHP_ONLINE, then Linux would schedule process on the RTOS core right.
2. CPUHP_OFFLINE also don't quite make sense, that means I have to handle all these "power up PPL, re-configure power domain" etc dirty work.

So I think maybe this is the correct place to ask: What kind of state do you assign to the remote core in a homogenous system?

[arnopo]

Hello,
Not sure to well understand your use case, but do have a look to virtual machines? they should address such use case?

[cnnblike]

Hi,
Arnopo, thanks a lot for the response.
I actually have a look at the VM solution before posting this - actually there are a few, Jailhouse, Bao-project etc.

There are quite a few paper[1][2] around the pros and cons of OpenAMP and Jailhouse, but most of them don't include data around homogenous OpenAMP style thing.

I'm on my way evaluating both of them.
Actually, I found really interesting solution on https://gitee.com/phytium_embedded/phytium-linux-kernel/blob/linux-5.10/drivers/remoteproc/homo_remoteproc.c, which, from my perspective, should be an-easy-to-adopt way to test out the OpenAMP route. it's the added CPUHP_AP_HOMO_RPROC_STARTING fell like the LCM part of remoteproc is actually missing (from my understanding).

reference:
[1] https://www.mdpi.com/2079-9292/13/9/1626
[2] https://arxiv.org/pdf/2303.11186

[cnnblike]

I got the idea of homogenous OpenAMP from https://bootlin.com/pub/conferences/2022/lee/clement-AMP-on-Cortex-A9/clement-AMP-on-Cortex-A9.pdf which is interesting but seemingly outdated.

[edmooring]

Hi, I'm looking into write set up a OpenAMP style Linux-RTOS on a quad core A35 SoC (RK3308, general with GIC-v2). I'm now writing a rather generic driver for this use case, while the manufacturer of RK3308 don't have remoteproc driver eligible for use. Ideally this will help OpenAMP greatly in ease of usage.

I want to make the system rather hot-plug-able, thus, without this .ko, linux can fully utilize all 4 cores, after an dt overlay with "homo-remoteproc" applied (and the specific core removed from cpu tree), this ko would start that core and boot the RTOS side.

I really want to reuse the cpuhp_hp_states and cpuhp_state for such scenario, but don't find a right state for this.

1. if I put an CPUHP_ONLINE, then Linux would schedule process on the RTOS core right.
2. CPUHP_OFFLINE also don't quite make sense, that means I have to handle all these "power up PPL, re-configure power domain" etc dirty work.

So I think maybe this is the correct place to ask: What kind of state do you assign to the remote core in a homogenous system?

You might take a look at how Xilinx/AMD handled this for the Zynq7. It had two Cortex A-9 cores. https://github.com/Xilinx/linux-xlnx/blob/master/drivers/remoteproc/zynq_remoteproc.c