From: <Conor.Dooley@microchip.com>
To: <uwu@icenowy.me>, <kernel@esmil.dk>, <robh+dt@kernel.org>,
<krzysztof.kozlowski+dt@linaro.org>
Cc: <aou@eecs.berkeley.edu>, <paul.walmsley@sifive.com>,
<devicetree@vger.kernel.org>, <palmer@dabbelt.com>,
<linux-riscv@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
<anup@brainfault.org>
Subject: Re: [PATCH v1 2/2] riscv: dts: starfive: add the missing monitor core
Date: Wed, 13 Jul 2022 15:36:11 +0000 [thread overview]
Message-ID: <83f6eb6e-2f3d-cc65-da94-43879ed3eaad@microchip.com> (raw)
In-Reply-To: <b983267d05f4acefb2a37f2ab8dd5d5a1742d9ff.camel@icenowy.me>
Rob/Krzk,
Got a question about how to represent one of the cpu cores on
this SoC at the end of the mail
On 13/07/2022 16:26, Icenowy Zheng wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> 在 2022-07-13星期三的 15:21 +0000,Conor.Dooley@microchip.com写道:
>> On 13/07/2022 16:12, Icenowy Zheng wrote:
>>> 在 2022-07-13星期三的 15:09 +0000,Conor.Dooley@microchip.com写道:
>>>>
>>>>
>>>> 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:
>>>>>>> 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.
>>>>
---8<---
>>>
>>> Considering E24 seems to see a total different bus connected to it,
>>> I
>>> don't think it even proper to add it to cpus node.
>>
>> Well, it is a CPU is it not? How one is supposed to document that a
>> CPU is not attached to the same buses I do not know however.
>
> I don't think this kind of CPUs should exist in /cpus, they should just
> be seen as peripherals as the main system. The speciality of FU[57]40's
> management core is that they're in the same core complex with the CPU
> cores that run Linux, just cores with a different capability that we
> could not expand Linux to them.
Maybe Rob or Krzysztof can shed some light on what would be the correct
way to depict this cpu.
>
>>
>>>
>>> And I don't think it has a hart id of 2, as your node describes.
>>
>> Do you have any idea what it would be then?
>
> As I asked one of my friend who has JTAG access to JH7110, the hart id
> is 0, the same with the first hart in U74-MC.
Hmm, my understanding is that the regs property needs to be unique, so
it'd have to stay as 2.
Thanks,
Conor.
next prev parent reply other threads:[~2022-07-13 15:36 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
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 [this message]
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=83f6eb6e-2f3d-cc65-da94-43879ed3eaad@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).