devicetree.vger.kernel.org archive mirror
 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>;
                };
        };
};
 

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

Thread overview: 16+ 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 ` [PATCH v1 1/2] dt-bindings: riscv: document the sifive e24 Conor Dooley
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-12 10:06   ` Emil Renner Berthing
2022-07-13 14:26   ` Icenowy Zheng
2022-07-13 14:55     ` Conor.Dooley
2022-07-13 15:02       ` Icenowy Zheng
2022-07-13 15:09         ` Conor.Dooley [this message]
2022-07-13 15:12           ` Icenowy Zheng
2022-07-13 15:21             ` Conor.Dooley
2022-07-13 15:26               ` Icenowy Zheng
2022-07-13 15:36                 ` Conor.Dooley
2022-07-13 15:15   ` Icenowy Zheng
2022-07-13 15:16     ` Conor.Dooley
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).