soc.lore.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Bert Vermeulen <bert@biot.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Arnd Bergmann <arnd@arndb.de>, Olof Johansson <olof@lixom.net>,
	SoC Team <soc@kernel.org>, Rob Herring <robh+dt@kernel.org>,
	John Crispin <john@phrozen.org>, Felix Fietkau <nbd@nbd.name>
Subject: Re: [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523
Date: Sun, 01 Aug 2021 10:50:00 +0100	[thread overview]
Message-ID: <87r1fd1ol3.wl-maz@kernel.org> (raw)
Message-ID: <20210801095000.zCnXLD8tcR0sgyQMKn5JgNttxiiiil6qYsagJlXsQh4@z> (raw)
In-Reply-To: <0fe113c6-4160-fd3c-488d-53d40b6043ee@biot.com>

On Sun, 01 Aug 2021 10:07:48 +0100,
Bert Vermeulen <bert@biot.com> wrote:
> 
> On 7/30/21 4:53 PM, Marc Zyngier wrote:
> > On Fri, 30 Jul 2021 15:31:36 +0100,
> > Linus Walleij <linus.walleij@linaro.org> wrote:
> >> 
> >> Paging Marc Z and Catalin just so they can see this:
> >> 
> >> On Fri, Jul 30, 2021 at 3:49 PM Bert Vermeulen <bert@biot.com> wrote:
> >> 
> >> > From: John Crispin <john@phrozen.org>
> >> >
> >> > Add basic support for EcoNet EN7523, enough for booting to console.
> >> >
> >> > The UART is basically 8250-compatible, except for the clock selection.
> >> > A clock-frequency value is synthesized to get this to run at 115200 bps.
> >> >
> >> > Signed-off-by: John Crispin <john@phrozen.org>
> >> > Signed-off-by: Bert Vermeulen <bert@biot.com>
> >> (...)
> >> > +       gic: interrupt-controller@09000000 {
> >> > +               compatible = "arm,gic-v3";
> >> > +               interrupt-controller;
> >> > +               #interrupt-cells = <3>;
> >> > +               #address-cells = <1>;
> >> > +               #size-cells = <1>;
> >> > +               reg = <0x09000000 0x20000>,
> >> > +                         <0x09080000 0x80000>;
> >> > +               interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_LOW>;
> >> > +
> >> > +               its: gic-its@09020000 {
> >> > +                       compatible = "arm,gic-v3-its";
> >> > +                       msi-controller;
> >> > +                       #msi-cell = <1>;
> >> > +                       reg = <0x090200000 0x20000>;
> >> > +               };
> >> > +       };
> >> 
> >> Yup GICv3 on ARM32-only silicon.
> > 
> > Hey, why not. But that's very unlikely, as Cortex-A7 doesn't have a
> > GICv3 CPU interface built in (it only has the memory mapped version),
> > and A53/57 were the first CPUs to ever support GICv3. I don't believe
> > the description of the CPU in the DT is accurate.
> > 
> > Bert, please send a kernel boot log.
> 
> At the bottom of this mail.
> 
> >> > +       timer {
> >> > +               compatible = "arm,armv8-timer";
> >> > +               interrupt-parent = <&gic>;
> >> > +               interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> >> > +                            <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> >> > +                            <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> >> > +                            <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
> > 
> > Copy paste bug. These are not valid intspecs for GICv3.
> 
> FWIW all these were taken verbatim from the vendor's SDK. Not that
> this makes them necessarily correct :)

Please, never copy anything verbatim from an existing DT, specially
not a vendor pile of crap.

Most integrators only cherry-picking DT random fragments without
trying to understand what they imply, beat them together until there
is a sign of life, and end-up with a monster that bears no resemblance
with reality.

Take an existing DT as a hint of what *could* be there, and work out
from first principles what actually makes sense. Yes, it is a lot of
work and involves reading specs, TRMs and whatnot. But at least it
will be correct, which is the standard that upstream is supposed to
uphold.

A shining example is what is below:

> 
> >> > +               clock-frequency = <25000000>;
> >> > +       };
> >> 
> >> Also arm,armv8-timer on ARM32-only silicon.
> > 
> > Probably because that's not what it actually is. My bet is on A53 with
> > a crippled firmware.
> 
> kernel boot log:
> 
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 5.14.0-rc3-00042-g3af70c6f8e95-dirty
> (bert@sumner) (arm-linux-gnueabi-gcc (Ubuntu 9.3.0-17ubuntu1~20.04)
> 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #392 SMP Sun Aug 1
> 10:28:13 CEST 2021
> [    0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d

As expected: 410fd034 = Cortex-A53 r0p4. Pretty far from a Cortex-A7,
isn't it?

> [    0.000000] CPU: div instructions available: patching division code
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> instruction cache
> [    0.000000] OF: fdt: Machine model: econet,en7523
> [    0.000000] earlycon: uart8250 at MMIO32 0x1fbf0000 (options '')
> [    0.000000] printk: bootconsole [uart8250] enabled
> [    0.000000] Memory policy: Data cache writealloc
> [    0.000000] Zone ranges:
> [    0.000000]   Normal   [mem 0x0000000080000000-0x000000009fffffff]
> [    0.000000]   HighMem  empty
> [    0.000000] Movable zone start for each node
> [    0.000000] Early memory node ranges
> [    0.000000]   node   0: [mem 0x0000000080000000-0x0000000083ffffff]
> [    0.000000]   node   0: [mem 0x0000000084000000-0x00000000849fffff]
> [    0.000000]   node   0: [mem 0x0000000084a00000-0x0000000084afffff]
> [    0.000000]   node   0: [mem 0x0000000084b00000-0x0000000084bfffff]
> [    0.000000]   node   0: [mem 0x0000000084c00000-0x0000000084ffffff]
> [    0.000000]   node   0: [mem 0x0000000085000000-0x00000000869fffff]
> [    0.000000]   node   0: [mem 0x0000000086a00000-0x0000000086afffff]
> [    0.000000]   node   0: [mem 0x0000000086b00000-0x0000000086bfffff]
> [    0.000000]   node   0: [mem 0x0000000086c00000-0x0000000086cfffff]
> [    0.000000]   node   0: [mem 0x0000000086d00000-0x0000000086dfffff]
> [    0.000000]   node   0: [mem 0x0000000086e00000-0x000000009fffffff]
> [    0.000000] Initmem setup node 0 [mem 0x0000000080000000-0x000000009fffffff]
> [    0.000000] percpu: Embedded 15 pages/cpu s30604 r8192 d22644 u61440
> [    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 129920
> [    0.000000] Kernel command line:
> earlycon=uart8250,mmio32,0x1fbf0000 console=ttyS0,115200
> [    0.000000] Dentry cache hash table entries: 65536 (order: 6,
> 262144 bytes, linear)
> [    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072
> bytes, linear)
> [    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
> [    0.000000] Memory: 461316K/524288K available (7168K kernel code,
> 312K rwdata, 1488K rodata, 8192K init, 142K bss, 62972K reserved, 0K
> cma-reserved, 0K highmem)
> [    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
> [    0.000000] rcu: Hierarchical RCU implementation.
> [    0.000000] rcu: RCU calculated value of scheduler-enlistment delay
> is 10 jiffies.
> [    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
> [    0.000000] GICv3: 256 SPIs implemented
> [    0.000000] GICv3: 0 Extended SPIs implemented
> [    0.000000] GICv3: Distributor has no Range Selector support
> [    0.000000] GICv3: 16 PPIs implemented
> [    0.000000] GICv3: CPU0: found redistributor 0 region 0:0x09080000

Interestingly, we don't program the property/pending tables for the
RD. Which means this SoC doesn't support LPIs, and thus *does not*
have an ITS, despite what you advertise.

> [    0.000000] random: get_random_bytes called from
> start_kernel+0x484/0x628 with crng_init=0
> [    0.000000] arch_timer: cp15 timer(s) running at 25.00MHz (virt).
> [    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff
> max_cycles: 0x5c40939b5, max_idle_ns: 440795202646 ns
> [    0.000000] sched_clock: 56 bits at 25MHz, resolution 40ns, wraps
> every 4398046511100ns
> [    0.008791] Switching to timer-based delay loop, resolution 40ns
> [    0.015454] Calibrating delay loop (skipped), value calculated
> using timer frequency.. 50.00 BogoMIPS (lpj=250000)
> [    0.026833] pid_max: default: 32768 minimum: 301
> [    0.032013] Mount-cache hash table entries: 1024 (order: 0, 4096
> bytes, linear)
> [    0.040047] Mountpoint-cache hash table entries: 1024 (order: 0,
> 4096 bytes, linear)
> [    0.049172] CPU: Testing write buffer coherency: ok
> [    0.054780] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
> [    0.061362] Setting up static identity map for 0x80100000 - 0x80100060
> [    0.068667] rcu: Hierarchical SRCU implementation.
> [    0.074290] gic-its@09020000: unable to locate ITS domain

Confirmed. No LPI support, no ITS.

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2021-08-01  9:52 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210730134552.853350-1-bert@biot.com>
2021-07-30 13:45 ` [PATCH 3/5] ARM: dts: Add basic support for EcoNet EN7523 Bert Vermeulen
2021-07-30 13:45   ` Bert Vermeulen
2021-07-30 14:31   ` Linus Walleij
2021-07-30 14:31     ` Linus Walleij
2021-07-30 14:31     ` Linus Walleij
2021-07-30 14:53     ` Marc Zyngier
2021-07-30 14:53       ` Marc Zyngier
2021-08-01  9:07       ` Bert Vermeulen
2021-08-01  9:07         ` Bert Vermeulen
2021-08-01  9:07         ` Bert Vermeulen
2021-08-01  9:40         ` Arnd Bergmann
2021-08-01  9:40           ` Arnd Bergmann
2021-08-01  9:40           ` Arnd Bergmann
2021-08-01  9:50         ` Marc Zyngier [this message]
2021-08-01  9:50           ` Marc Zyngier
2021-07-30 14:45   ` Daniel Palmer
2021-07-30 14:45     ` Daniel Palmer
2021-07-30 14:45     ` Daniel Palmer
2021-07-30 14:46   ` Mark Rutland
2021-07-30 14:46     ` Mark Rutland
2021-08-04 16:41     ` Bert Vermeulen
2021-08-04 16:41       ` Bert Vermeulen
2021-08-06 20:59       ` Rob Herring
2021-08-06 20:59         ` Rob Herring
2021-07-30 14:59   ` Mark Rutland
2021-07-30 14:59     ` Mark Rutland
2021-08-06 20:52     ` Rob Herring
2021-08-06 20:52       ` Rob Herring
2021-07-30 16:47   ` Andre Przywara
2021-07-30 16:47     ` Andre Przywara
2021-07-30 17:23     ` Marc Zyngier
2021-07-30 17:23       ` Marc Zyngier

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=87r1fd1ol3.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=arnd@arndb.de \
    --cc=bert@biot.com \
    --cc=catalin.marinas@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=john@phrozen.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nbd@nbd.name \
    --cc=olof@lixom.net \
    --cc=robh+dt@kernel.org \
    --cc=soc@kernel.org \
    /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).