From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5B1E0C7619A for ; Wed, 12 Apr 2023 17:51:11 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 5972685F85; Wed, 12 Apr 2023 19:51:08 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id E809A85F95; Wed, 12 Apr 2023 19:51:06 +0200 (CEST) Received: from verein.lst.de (verein.lst.de [213.95.11.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id DB17985D94 for ; Wed, 12 Apr 2023 19:51:03 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: phobos.denx.de; spf=none smtp.mailfrom=duwe@lst.de Received: by verein.lst.de (Postfix, from userid 107) id 14EC668BFE; Wed, 12 Apr 2023 19:51:02 +0200 (CEST) Received: from blackhole.lan (p5b2ecf4b.dip0.t-ipconnect.de [91.46.207.75]) by verein.lst.de (Postfix) with ESMTPSA id 4837A67328; Wed, 12 Apr 2023 19:50:52 +0200 (CEST) Date: Wed, 12 Apr 2023 19:50:47 +0200 From: Torsten Duwe To: yanhong wang Cc: , Rick Chen , Leo , Lukasz Majewski , Sean Anderson , Lee Kuan Lim , "Jianlong Huang" , Emil Renner Berthing Subject: Re: [PATCH v5 00/17] Basic StarFive JH7110 RISC-V SoC support Message-ID: <20230412195047.60243174@blackhole.lan> In-Reply-To: References: <20230329034224.26545-1-yanhong.wang@starfivetech.com> <20230329114138.3458974f@blackhole.lan> Organization: LST e.V. X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.34; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.8 at phobos.denx.de X-Virus-Status: Clean On Wed, 29 Mar 2023 18:16:20 +0800 yanhong wang wrote: >=20 >=20 > On 2023/3/29 17:41, Torsten Duwe wrote: > > On Wed, 29 Mar 2023 11:42:07 +0800 > > Yanhong Wang wrote: > >=20 > >> v5: > > [...] > >> - Splitted starfive_visionfive2_defconfig into starfive_visionfive2_12= a_defconfig > >> and starfive_visionfive2_13b_defconfig. > >=20 > > Is this really necessary? It puts another burden on people building U-B= oot, > > distribution networks, and last but not least users, who will need to p= ick the > > correct binary blob, after trying to find out which board they actually= have. > >=20 > > Even past versions can detect the installed RAM correctly and will modi= fy > > the DT accordingly, I assume? Why not make an inquiry on GMAC1_MDIO to = tell > > whether it's a YT8512C (->v1.2A) or another YT8531C (->v1.3B), in the e= thernet > > patch set, and likewise update the device tree dynamically then? At a second look, this is a bit tricky: a device tree is already needed for= the network initialisation. That one would need to be good enough to get at the PHYs, a= nd flexible enough to be patched into shape later. But see below... =20 > There is only one defconfig in V4, and dts is separate for versions 1.2a = and 1.3b. > Andreas Schwab suggested that defconfig is also defined separately, so th= e definition=20 > of defconfig in V5 is also separated.=20 >=20 > The discussion process as follows: >=20 > https://patchwork.ozlabs.org/project/uboot/patch/20230316025332.3297-18-y= anhong.wang@starfivetech.com/ >=20 > Do you have any better suggestion on whether defconfig is defined separat= ely? Andreas' concern is the match between the device tree and the actual hardwa= re, as far as it matters for (driver) software. So, different hardware =3D> dif= ferent DT. However, AFAICT there is no difference until network comes into play, right= ? And even then, it is only the types of PHYs and their wiring, correct? =46rom the other thread: can we enable the EEPROM reading code first, to get = the proper MAC addresses for the hardware, and also read the board revision, similar to get_pcb_revision_from_eeprom() from the HiFive unmatched? And then use fixu= p functions from common/fdt_support.c to adapt the device tree details to the detected = board? Torsten