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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZokfBzjvwN0IUQIX@xhacker>
Date: Sat, 6 Jul 2024 18:40:07 +0800
From: Jisheng Zhang <jszhang@...nel.org>
To: Yixun Lan <dlan@...too.org>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, Conor Dooley <conor@...nel.org>,
	Paul Walmsley <paul.walmsley@...ive.com>,
	Palmer Dabbelt <palmer@...belt.com>,
	Albert Ou <aou@...s.berkeley.edu>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Samuel Holland <samuel.holland@...ive.com>,
	Anup Patel <anup@...infault.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jirislaby@...nel.org>, Lubomir Rintel <lkundrak@...sk>,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	Yangyu Chen <cyy@...self.name>,
	Inochi Amaoto <inochiama@...look.com>, linux-serial@...r.kernel.org,
	linux-riscv@...ts.infradead.org,
	Meng Zhang <zhangmeng.kevin@...cemit.com>
Subject: Re: [PATCH v3 08/11] riscv: dts: add initial SpacemiT K1 SoC device
 tree

On Sat, Jul 06, 2024 at 05:05:56AM +0000, Yixun Lan wrote:
> 
> On 12:12 Sat 06 Jul     , Jisheng Zhang wrote:
> > On Fri, Jul 05, 2024 at 06:38:39AM +0000, Yixun Lan wrote:
> > > 
> > > On 21:46 Thu 04 Jul     , Jisheng Zhang wrote:
> > > > On Wed, Jul 03, 2024 at 02:55:11PM +0000, Yixun Lan wrote:
> > > > > From: Yangyu Chen <cyy@...self.name>
> > > > > 
> > > > > Banana Pi BPI-F3 motherboard is powered by SpacemiT K1[1].
> > > > > 
> > > > > Key features:
> > > > > - 4 cores per cluster, 2 clusters on chip
> > > > > - UART IP is Intel XScale UART
> > > > > 
> > > > > Some key considerations:
> > > > > - ISA string is inferred from vendor documentation[2]
> > > > > - Cluster topology is inferred from datasheet[1] and L2 in vendor dts[3]
> > > > > - No coherent DMA on this board
> > > > >     Inferred by taking vendor ethernet and MMC drivers to the mainline
> > > > >     kernel. Without dma-noncoherent in soc node, the driver fails.
> > > > > - No cache nodes now
> > > > >     The parameters from vendor dts are likely to be wrong. It has 512
> > > > >     sets for a 32KiB L1 Cache. In this case, each set is 64B in size.
> > > > >     When the size of the cache line is 64B, it is a directly mapped
> > > > >     cache rather than a set-associative cache, the latter is commonly
> > > > >     used. Thus, I didn't use the parameters from vendor dts.
> > > > > 
> > > > > Currently only support booting into console with only uart, other
> > > > > features will be added soon later.
> > > > > 
> > > > > Link: https://docs.banana-pi.org/en/BPI-F3/SpacemiT_K1_datasheet [1]
> > > > > Link: https://developer.spacemit.com/#/documentation?token=BWbGwbx7liGW21kq9lucSA6Vnpb [2]
> > > > > Link: https://gitee.com/bianbu-linux/linux-6.1/blob/bl-v1.0.y/arch/riscv/boot/dts/spacemit/k1-x.dtsi [3]
> > > > > Signed-off-by: Yangyu Chen <cyy@...self.name>
> > > > > Signed-off-by: Yixun Lan <dlan@...too.org>
> > > > > ---
> > > > >  arch/riscv/boot/dts/spacemit/k1.dtsi | 376 +++++++++++++++++++++++++++++++++++
> > > > >  1 file changed, 376 insertions(+)
> > > > > 
> > > > > diff --git a/arch/riscv/boot/dts/spacemit/k1.dtsi b/arch/riscv/boot/dts/spacemit/k1.dtsi
> > > > > new file mode 100644
> > > > > index 0000000000000..a076e35855a2e
> > > > > --- /dev/null
> > > > > +++ b/arch/riscv/boot/dts/spacemit/k1.dtsi
> > > > > @@ -0,0 +1,376 @@
> > > > > +// SPDX-License-Identifier: GPL-2.0 OR MIT
> > > > > +/*
> > > > > + * Copyright (C) 2024 Yangyu Chen <cyy@...self.name>
> > > > > + */
> > > > > +
> > > > > +/dts-v1/;
> > > > > +/ {
> > > > > +	#address-cells = <2>;
> > > > > +	#size-cells = <2>;
> > > > > +	model = "SpacemiT K1";
> > > > > +	compatible = "spacemit,k1";
> > > > > +
> > > > > +
...
> > > > > +	soc {
> > > > > +		compatible = "simple-bus";
> > > > > +		interrupt-parent = <&plic>;
> > > > > +		#address-cells = <2>;
> > > > > +		#size-cells = <2>;
> > > > > +		dma-noncoherent;
> > > > > +		ranges;
> > > > > +
> > > > > +		uart0: serial@...17000 {
> > > > > +			compatible = "spacemit,k1-uart", "intel,xscale-uart";
> > > > 
> > > > no, this is not a correct hw modeling. The doc on spacemit says
> > > > all the uart support 64 bytes FIFO, declaring xscale only makes
> > > > use of 32 bytes FIFO.
> > > yes, I also noticed it's 64 bytes FIFO
> > > 
> > > > 
> > > > IIRC, 8250_pxa is a xscale uart with 64 bytes FIFO, so this should be
> > > > "mrvl,pxa-uart" or "mrvl,mmp-uart"
> > > 
> > > 
> > > for mrvl,pxa-uart, I think you imply to use drivers/tty/serial/8250/8250_pxa.c,
> > > which turn out doesn't work on k1 SoC, for the record, we need to adjust
> > 
> > Really? I just tried "mrvl,pxa-uart" with rc6, it works perfectly, and the FIFO
> > in the driver logic is 64bytes now. Am I misssing something or you never tried it?
> > 
> Ok, I realised it's the clock issue
> 
> still, I'm not fully convinced about using "mrvl,pxa-uart",
> e.g this driver hardcoded tz_loadsz to 32, not sure if K1 suffer same problem
> 5208e7ced520 ("serial: 8250_pxa: Configure tx_loadsz to match FIFO IRQ level")

I believe the problem commit 5208e7ced520 tries to solve is: the
mmp|pxa-uart only support threshold up to 32Bytes, tz_loadsz will be
fifo size by default, this will cause probleme with 64Bytes FIFO.

> 
> also, what's the preference when choosing driver between 8250_pxa.c vs 8250_of.c?

Good question. I have no preference. But there are two problems with
8250_of, I have sent out patches[1][2] to address them.

After these two patches, both the earlycon and uart FIFO logic work too
with below dts properties:
		uart0: serial@...17000 {
			compatible = "mrvl,mmp-uart";
			...
                        reg-shift = <2>;
                        reg-io-width = <4>;
                        tx-threshold = <32>;
                        fifo-size = <64>;
                        no-loopback-test;
			...
		}

Link: https://lore.kernel.org/linux-riscv/20240706082928.2238-1-jszhang@kernel.org/ [1]
Link: https://lore.kernel.org/linux-riscv/20240706101856.3077-1-jszhang@kernel.org/ [2]

> it occur to me that 8250_pxa.c is more specially tailored for pxa hardware, while
> 8250_of.c is more generic.. besides, should we consider one more step if we want to

there's a work around for Erratum #74 in 8250_pxa, while I believe the
Errata doesn't exisit in K1, so from this PoV it seems 8250_of is
better, no?

> support DMA mode in the future (vendor uart driver has DMA support)?

Adding dma engine support to 8250_of is doable.

> 
> 
> > >  drivers/tty/serial/8250/Kconfig to enable the driver for ARCH_SPACEMIT,
> > >  and change uart compatible to "spacemit,k1-uart", "mrvl,pxa-uart"
> > > 
> > > for mrvl,mmp-uart, I see two choices, one using 8250_pxa.c which has same result
> > > as mrvl,pxa-uart, another choice would using the driver of 8250_of.c 
> > > and it work as same as "intel,xscale-uart", I don't see any difference..
> > > 
> > > P.S: there is possibly a side problem that "mrvl,mmp-uart" from 8250_of.c doesn't 
> > > really compatile with "mrvl,mmp-uart" from 8250_pxa.c, but I think it's another story
> 
> -- 
> Yixun Lan (dlan)
> Gentoo Linux Developer
> GPG Key ID AABEFD55

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ