| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <b983267d05f4acefb2a37f2ab8dd5d5a1742d9ff.camel@icenowy.me>
Date: Wed, 13 Jul 2022 23:26:41 +0800
From: Icenowy Zheng <uwu@...nowy.me>
To: Conor.Dooley@...rochip.com, kernel@...il.dk, robh+dt@...nel.org,
krzysztof.kozlowski+dt@...aro.org, paul.walmsley@...ive.com,
palmer@...belt.com, aou@...s.berkeley.edu, anup@...infault.org
Cc: devicetree@...r.kernel.org, linux-riscv@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 2/2] riscv: dts: starfive: add the missing monitor
core
在 2022-07-13星期三的 15:21 +0000，Conor.Dooley@...rochip.com写道：
> On 13/07/2022 16:12, Icenowy Zheng wrote:
> > 在 2022-07-13星期三的 15:09 +0000，Conor.Dooley@...rochip.com写道：
> > >
> > >
> > > On 13/07/2022 16:02, Icenowy Zheng wrote:
> > > > 在 2022-07-13星期三的 14:55 +0000，Conor.Dooley@...rochip.com写道：
> > > > > On 13/07/2022 15:26, Icenowy Zheng wrote:
> > > > > >
> > > > > > 在 2022-07-11星期一的 19:43 +0100，Conor Dooley写道：
> > > > > > > From: Conor Dooley <conor.dooley@...rochip.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@...rochip.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>;
> > > };
> > > };
> > > };
> >
> > 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.
>
> >
> > 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.
Powered by blists - more mailing lists