All of lore.kernel.org
 help / color / mirror / Atom feed
From: <Conor.Dooley@microchip.com>
To: <uwu@icenowy.me>, <Conor.Dooley@microchip.com>, <kernel@esmil.dk>,
	<robh+dt@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>,
	<paul.walmsley@sifive.com>, <palmer@dabbelt.com>,
	<aou@eecs.berkeley.edu>, <anup@brainfault.org>
Cc: <devicetree@vger.kernel.org>, <linux-riscv@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1 2/2] riscv: dts: starfive: add the missing monitor core
Date: Wed, 13 Jul 2022 15:09:51 +0000	[thread overview]
Message-ID: <6f6fae32-e3dc-4b9b-21b1-cc2ab0c67de6@microchip.com> (raw)
In-Reply-To: <822ceff8a6e7f41179abde307ce59c2120684294.camel@icenowy.me>



On 13/07/2022 16:02, Icenowy Zheng wrote:
> 在 2022-07-13星期三的 14:55 +0000,Conor.Dooley@microchip.com写道:
>> On 13/07/2022 15:26, Icenowy Zheng wrote:
>>>
>>> 在 2022-07-11星期一的 19:43 +0100,Conor Dooley写道:
>>>> From: Conor Dooley <conor.dooley@microchip.com>
>>>>
>>>> The JH7100 has a 32 bit monitor core that is missing from the
>>>> device
>>>> tree. Add it (and its cpu-map entry) to more accurately reflect
>>>> the
>>>> actual topology of the SoC.
>>>>
>>>> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
>>>> ---
>>>>  arch/riscv/boot/dts/starfive/jh7100.dtsi | 21
>>>> +++++++++++++++++++++
>>>>  1 file changed, 21 insertions(+)
>>>>
>>>> diff --git a/arch/riscv/boot/dts/starfive/jh7100.dtsi
>>>> b/arch/riscv/boot/dts/starfive/jh7100.dtsi
>>>> index c617a61e26e2..92fce5b66d3d 100644
>>>> --- a/arch/riscv/boot/dts/starfive/jh7100.dtsi
>>>> +++ b/arch/riscv/boot/dts/starfive/jh7100.dtsi
>>>> @@ -67,6 +67,23 @@ cpu1_intc: interrupt-controller {
>>>>                         };
>>>>                 };
>>>>
>>>> +               E24: cpu@2 {
>>>> +                       compatible = "sifive,e24", "riscv";
>>>> +                       reg = <2>;
>>>> +                       device_type = "cpu";
>>>> +                       i-cache-block-size = <32>;
>>>> +                       i-cache-sets = <256>;
>>>> +                       i-cache-size = <16384>;
>>>> +                       riscv,isa = "rv32imafc";
>>>> +                       status = "disabled";
>>>> +
>>>> +                       cpu2_intc: interrupt-controller {
>>>> +                               compatible = "riscv,cpu-intc";
>>>> +                               interrupt-controller;
>>>> +                               #interrupt-cells = <1>;
>>>> +                       };
>>>> +               };
>>>> +
>>>>                 cpu-map {
>>>>                         cluster0 {
>>>>                                 core0 {
>>>> @@ -76,6 +93,10 @@ core0 {
>>>>                                 core1 {
>>>>                                         cpu = <&U74_1>;
>>>>                                 };
>>>> +
>>>> +                               core2 {
>>>> +                                       cpu = <&E24>;
>>>> +                               };
>>>
>>> Sorry but I think this change makes the topology more inaccurate.
>>>
>>> The E24 core is very independent, just another CPU core connected
>>> the
>>> same bus -- even no coherency (E24 takes AHB, which is not
>>> coherency-
>>> sensible). Even the TAP of it is independent with the U74 TAP.
>>>
>>> And by default it does not boot any proper code (if a debugger is
>>> attached, it will discover that the E24 is in consistently fault at
>>> 0x0
>>> (mtvec is 0x0 and when fault it jumps to 0x0 and fault again),
>>> until
>>> its clock is just shutdown by Linux cleaning up unused clocks.)
>>>
>>> Personally I think it should be implemented as a remoteproc
>>> instead.
>>
>> Maybe I am missing something, but I don't quite get what the detail
>> of how we access this in code has to do with the devicetree?
>> It is added here in a disabled state, and will not be used by Linux.
>> The various SiFive SoCs & SiFive corecomplex users that have a hart
>> not capable of running Linux also have that hart documented in the
>> devicetree.
>> To me, what we are choosing to do with this hart does not really
>> matter very much, since this is a description of what the hardware
>> actually looks like.
> 
> The E24 is not in the core complex at all. It's just a dedicate CPU
> connected to another bus (well as I saw the document says the E24 bus
> is maximum 2G, I doubt whether it's the same bus with the U74 one).
> 
> The U74 MC only allows S5 management cores to be part of it, not E24.

So is the correct topology more like:
cpu-map {
        cluster0 {
                core0 {
                        cpu = <&U74_0>;
                };
                core1 {
                        cpu = <&U74_1>;
                };
        };
        cluster1 {
                core0 {
                        cpu = <&E24>;
                };
        };
};
 
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: <Conor.Dooley@microchip.com>
To: <uwu@icenowy.me>, <Conor.Dooley@microchip.com>, <kernel@esmil.dk>,
	<robh+dt@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>,
	<paul.walmsley@sifive.com>, <palmer@dabbelt.com>,
	<aou@eecs.berkeley.edu>, <anup@brainfault.org>
Cc: <devicetree@vger.kernel.org>, <linux-riscv@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1 2/2] riscv: dts: starfive: add the missing monitor core
Date: Wed, 13 Jul 2022 15:09:51 +0000	[thread overview]
Message-ID: <6f6fae32-e3dc-4b9b-21b1-cc2ab0c67de6@microchip.com> (raw)
In-Reply-To: <822ceff8a6e7f41179abde307ce59c2120684294.camel@icenowy.me>



On 13/07/2022 16:02, Icenowy Zheng wrote:
> 在 2022-07-13星期三的 14:55 +0000,Conor.Dooley@microchip.com写道:
>> On 13/07/2022 15:26, Icenowy Zheng wrote:
>>>
>>> 在 2022-07-11星期一的 19:43 +0100,Conor Dooley写道:
>>>> From: Conor Dooley <conor.dooley@microchip.com>
>>>>
>>>> The JH7100 has a 32 bit monitor core that is missing from the
>>>> device
>>>> tree. Add it (and its cpu-map entry) to more accurately reflect
>>>> the
>>>> actual topology of the SoC.
>>>>
>>>> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
>>>> ---
>>>>  arch/riscv/boot/dts/starfive/jh7100.dtsi | 21
>>>> +++++++++++++++++++++
>>>>  1 file changed, 21 insertions(+)
>>>>
>>>> diff --git a/arch/riscv/boot/dts/starfive/jh7100.dtsi
>>>> b/arch/riscv/boot/dts/starfive/jh7100.dtsi
>>>> index c617a61e26e2..92fce5b66d3d 100644
>>>> --- a/arch/riscv/boot/dts/starfive/jh7100.dtsi
>>>> +++ b/arch/riscv/boot/dts/starfive/jh7100.dtsi
>>>> @@ -67,6 +67,23 @@ cpu1_intc: interrupt-controller {
>>>>                         };
>>>>                 };
>>>>
>>>> +               E24: cpu@2 {
>>>> +                       compatible = "sifive,e24", "riscv";
>>>> +                       reg = <2>;
>>>> +                       device_type = "cpu";
>>>> +                       i-cache-block-size = <32>;
>>>> +                       i-cache-sets = <256>;
>>>> +                       i-cache-size = <16384>;
>>>> +                       riscv,isa = "rv32imafc";
>>>> +                       status = "disabled";
>>>> +
>>>> +                       cpu2_intc: interrupt-controller {
>>>> +                               compatible = "riscv,cpu-intc";
>>>> +                               interrupt-controller;
>>>> +                               #interrupt-cells = <1>;
>>>> +                       };
>>>> +               };
>>>> +
>>>>                 cpu-map {
>>>>                         cluster0 {
>>>>                                 core0 {
>>>> @@ -76,6 +93,10 @@ core0 {
>>>>                                 core1 {
>>>>                                         cpu = <&U74_1>;
>>>>                                 };
>>>> +
>>>> +                               core2 {
>>>> +                                       cpu = <&E24>;
>>>> +                               };
>>>
>>> Sorry but I think this change makes the topology more inaccurate.
>>>
>>> The E24 core is very independent, just another CPU core connected
>>> the
>>> same bus -- even no coherency (E24 takes AHB, which is not
>>> coherency-
>>> sensible). Even the TAP of it is independent with the U74 TAP.
>>>
>>> And by default it does not boot any proper code (if a debugger is
>>> attached, it will discover that the E24 is in consistently fault at
>>> 0x0
>>> (mtvec is 0x0 and when fault it jumps to 0x0 and fault again),
>>> until
>>> its clock is just shutdown by Linux cleaning up unused clocks.)
>>>
>>> Personally I think it should be implemented as a remoteproc
>>> instead.
>>
>> Maybe I am missing something, but I don't quite get what the detail
>> of how we access this in code has to do with the devicetree?
>> It is added here in a disabled state, and will not be used by Linux.
>> The various SiFive SoCs & SiFive corecomplex users that have a hart
>> not capable of running Linux also have that hart documented in the
>> devicetree.
>> To me, what we are choosing to do with this hart does not really
>> matter very much, since this is a description of what the hardware
>> actually looks like.
> 
> The E24 is not in the core complex at all. It's just a dedicate CPU
> connected to another bus (well as I saw the document says the E24 bus
> is maximum 2G, I doubt whether it's the same bus with the U74 one).
> 
> The U74 MC only allows S5 management cores to be part of it, not E24.

So is the correct topology more like:
cpu-map {
        cluster0 {
                core0 {
                        cpu = <&U74_0>;
                };
                core1 {
                        cpu = <&U74_1>;
                };
        };
        cluster1 {
                core0 {
                        cpu = <&E24>;
                };
        };
};
 

  reply	other threads:[~2022-07-13 15:10 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-11 18:43 [PATCH v1 0/2] Add the JH7100's Monitor Core Conor Dooley
2022-07-11 18:43 ` Conor Dooley
2022-07-11 18:43 ` [PATCH v1 1/2] dt-bindings: riscv: document the sifive e24 Conor Dooley
2022-07-11 18:43   ` Conor Dooley
2022-07-12  8:08   ` Krzysztof Kozlowski
2022-07-12  8:08     ` Krzysztof Kozlowski
2022-07-11 18:43 ` [PATCH v1 2/2] riscv: dts: starfive: add the missing monitor core Conor Dooley
2022-07-11 18:43   ` Conor Dooley
2022-07-12 10:06   ` Emil Renner Berthing
2022-07-12 10:06     ` Emil Renner Berthing
2022-07-13 14:26   ` Icenowy Zheng
2022-07-13 14:26     ` Icenowy Zheng
2022-07-13 14:55     ` Conor.Dooley
2022-07-13 14:55       ` Conor.Dooley
2022-07-13 15:02       ` Icenowy Zheng
2022-07-13 15:02         ` Icenowy Zheng
2022-07-13 15:09         ` Conor.Dooley [this message]
2022-07-13 15:09           ` Conor.Dooley
2022-07-13 15:12           ` Icenowy Zheng
2022-07-13 15:12             ` Icenowy Zheng
2022-07-13 15:21             ` Conor.Dooley
2022-07-13 15:21               ` Conor.Dooley
2022-07-13 15:26               ` Icenowy Zheng
2022-07-13 15:26                 ` Icenowy Zheng
2022-07-13 15:36                 ` Conor.Dooley
2022-07-13 15:36                   ` Conor.Dooley
2022-07-13 15:15   ` Icenowy Zheng
2022-07-13 15:15     ` Icenowy Zheng
2022-07-13 15:16     ` Conor.Dooley
2022-07-13 15:16       ` Conor.Dooley
2022-07-13 15:20       ` Icenowy Zheng
2022-07-13 15:20         ` Icenowy Zheng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6f6fae32-e3dc-4b9b-21b1-cc2ab0c67de6@microchip.com \
    --to=conor.dooley@microchip.com \
    --cc=anup@brainfault.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=devicetree@vger.kernel.org \
    --cc=kernel@esmil.dk \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=robh+dt@kernel.org \
    --cc=uwu@icenowy.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.