Hi Device Tree engineers,
Recently I have ported Xen on Cortex-R52 (AArch32-V8R processor) for our
AMD platform.
I was discussing with xen-devel community about how we can properly
support smpboot when I was suggested that this might be the correct
forum for discussion.
Please refer
https://lists.xenproject.org/archives/html/xen-devel/2023-05/msg00224.html
and the follow-ups for context.
The way smpboot works on our platform is as follows:-
1. core0 writes to register (say regA) the address of the secondary core
initialization routine.
2. core0 writes to another register (say regB) the value "0x1" to put
the secondary core in reset mode.
3. core0 writes to regB the value "0x0" to pull the secondary core out
of reset mode.
regA, regB will differ for core1, core2, core3 and so on.
Currently, I am trying to bringup core1 only.
I am thinking to use "enable-method=spin-table" in the cpu node for
core1. So that I can use "cpu-release-address" for regA.
For regB, I am thinking of introducing a new property
"amd-cpu-reset-addr" in the cpu node.
Please let me know your thoughts on this approach. I am also open to any
alternative suggestions.
Also I see that in
https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/devicetree/bindings/arm/cpus.yaml#L87
, "arm,cortex-r52" is missing.
Can I submit a patch (a one line change) to add this ?
Kind regards,
Ayan
On 11/05/2023 11:35, Ayan Kumar Halder wrote:
> Hi Device Tree engineers,
>
>
> Recently I have ported Xen on Cortex-R52 (AArch32-V8R processor) for our
> AMD platform.
>
> I was discussing with xen-devel community about how we can properly
> support smpboot when I was suggested that this might be the correct
> forum for discussion.
>
> Please refer
> https://lists.xenproject.org/archives/html/xen-devel/2023-05/msg00224.html
> and the follow-ups for context.
>
>
> The way smpboot works on our platform is as follows:-
>
> 1. core0 writes to register (say regA) the address of the secondary core
> initialization routine.
>
> 2. core0 writes to another register (say regB) the value "0x1" to put
> the secondary core in reset mode.
>
> 3. core0 writes to regB the value "0x0" to pull the secondary core out
> of reset mode.
>
> regA, regB will differ for core1, core2, core3 and so on.
>
>
> Currently, I am trying to bringup core1 only.
>
>
> I am thinking to use "enable-method=spin-table" in the cpu node for
> core1. So that I can use "cpu-release-address" for regA.
>
> For regB, I am thinking of introducing a new property
> "amd-cpu-reset-addr" in the cpu node.
Propose a patch, that's how we discuss. Anyway as this is arm then you
have a machine for your platform right? The address is not fixed?
If the the regb is not a pen release-like, so you cannot use
secondary-boot-reg, then check how other machines are doing it.
Best regards,
Krzysztof
On Thu, May 11, 2023 at 10:35:37AM +0100, Ayan Kumar Halder wrote:
> Hi Device Tree engineers,
>
> Recently I have ported Xen on Cortex-R52 (AArch32-V8R processor) for our AMD
> platform.
>
I remember that there was some exploration on feasibility of using PSCI
here. What happened to that ? Any summary why that was dropped ?
> I was discussing with xen-devel community about how we can properly support
> smpboot when I was suggested that this might be the correct forum for
> discussion.
>
> Please refer
> https://lists.xenproject.org/archives/html/xen-devel/2023-05/msg00224.html
> and the follow-ups for context.
>
>
> The way smpboot works on our platform is as follows:-
>
> 1. core0 writes to register (say regA) the address of the secondary core
> initialization routine.
>
> 2. core0 writes to another register (say regB) the value "0x1" to put the
> secondary core in reset mode.
>
> 3. core0 writes to regB the value "0x0" to pull the secondary core out of
> reset mode.
>
> regA, regB will differ for core1, core2, core3 and so on.
>
Sounds OK but will you ever need to support power management on these cores ?
If so, just start with PSCI or provide reasons as why it doesn't fit well
before exploring and extending the existing spin table bindings.
>
> Currently, I am trying to bringup core1 only.
>
>
> I am thinking to use "enable-method=spin-table" in the cpu node for core1.?
> So that I can use "cpu-release-address" for regA.
>
> For regB, I am thinking of introducing a new property "amd-cpu-reset-addr"
> in the cpu node.
>
> Please let me know your thoughts on this approach. I am also open to any
> alternative suggestions.
>
>
> Also I see that in https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/devicetree/bindings/arm/cpus.yaml#L87
> , "arm,cortex-r52" is missing.
>
Yes that should be fine IMO.
> Can I submit a patch (a one line change) to add this ?
>
Of course, it makes it easy to accept or reject rather than this question
hidden as part of other discussion.
--
Regards,
Sudeep
Hi Sudeep,
On 15/05/2023 11:08, Sudeep Holla wrote:
> On Thu, May 11, 2023 at 10:35:37AM +0100, Ayan Kumar Halder wrote:
>> Hi Device Tree engineers,
>>
>> Recently I have ported Xen on Cortex-R52 (AArch32-V8R processor) for our AMD
>> platform.
>>
> I remember that there was some exploration on feasibility of using PSCI
> here. What happened to that ? Any summary why that was dropped ?
We are discussing internally with other Xilinx/AMD engineers about this.
>
>> I was discussing with xen-devel community about how we can properly support
>> smpboot when I was suggested that this might be the correct forum for
>> discussion.
>>
>> Please refer
>> https://lists.xenproject.org/archives/html/xen-devel/2023-05/msg00224.html
>> and the follow-ups for context.
>>
>>
>> The way smpboot works on our platform is as follows:-
>>
>> 1. core0 writes to register (say regA) the address of the secondary core
>> initialization routine.
>>
>> 2. core0 writes to another register (say regB) the value "0x1" to put the
>> secondary core in reset mode.
>>
>> 3. core0 writes to regB the value "0x0" to pull the secondary core out of
>> reset mode.
>>
>> regA, regB will differ for core1, core2, core3 and so on.
>>
> Sounds OK but will you ever need to support power management on these cores ?
> If so, just start with PSCI or provide reasons as why it doesn't fit well
> before exploring and extending the existing spin table bindings.
Power management is not in scope.
About PSCI, we are discussing internally.
>
>> Currently, I am trying to bringup core1 only.
>>
>>
>> I am thinking to use "enable-method=spin-table" in the cpu node for core1.
>> So that I can use "cpu-release-address" for regA.
>>
>> For regB, I am thinking of introducing a new property "amd-cpu-reset-addr"
>> in the cpu node.
>>
>> Please let me know your thoughts on this approach. I am also open to any
>> alternative suggestions.
>>
>>
>> Also I see that in https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/devicetree/bindings/arm/cpus.yaml#L87
>> , "arm,cortex-r52" is missing.
>>
> Yes that should be fine IMO.
>
>> Can I submit a patch (a one line change) to add this ?
>>
> Of course, it makes it easy to accept or reject rather than this question
> hidden as part of other discussion.
I have submitted a patch for this.
https://archive.armlinux.org.uk/lurker/message/20230518.152730.c91cc994.en.html
- Ayan
>
> --
> Regards,
> Sudeep