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 35479C7619A for ; Thu, 13 Apr 2023 02:05:44 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id C73678589F; Thu, 13 Apr 2023 04:05:41 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=starfivetech.com 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 B99548574A; Thu, 13 Apr 2023 04:05:39 +0200 (CEST) Received: from fd01.gateway.ufhost.com (fd01.gateway.ufhost.com [61.152.239.71]) by phobos.denx.de (Postfix) with ESMTP id B69528574A for ; Thu, 13 Apr 2023 04:05:34 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=starfivetech.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=yanhong.wang@starfivetech.com Received: from EXMBX165.cuchost.com (unknown [175.102.18.54]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "EXMBX165", Issuer "EXMBX165" (not verified)) by fd01.gateway.ufhost.com (Postfix) with ESMTP id 200FE806C; Thu, 13 Apr 2023 10:05:31 +0800 (CST) Received: from EXMBX073.cuchost.com (172.16.6.83) by EXMBX165.cuchost.com (172.16.6.75) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Thu, 13 Apr 2023 10:05:31 +0800 Received: from [192.168.120.49] (171.223.208.138) by EXMBX073.cuchost.com (172.16.6.83) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Thu, 13 Apr 2023 10:05:30 +0800 Message-ID: Date: Thu, 13 Apr 2023 10:05:28 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: [PATCH v5 00/17] Basic StarFive JH7110 RISC-V SoC support To: Torsten Duwe CC: , Rick Chen , Leo , Lukasz Majewski , Sean Anderson , Lee Kuan Lim , "Jianlong Huang" , Emil Renner Berthing References: <20230329034224.26545-1-yanhong.wang@starfivetech.com> <20230329114138.3458974f@blackhole.lan> <20230412195047.60243174@blackhole.lan> Content-Language: en-US From: yanhong wang In-Reply-To: <20230412195047.60243174@blackhole.lan> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [171.223.208.138] X-ClientProxiedBy: EXCAS066.cuchost.com (172.16.6.26) To EXMBX073.cuchost.com (172.16.6.83) X-YovoleRuleAgent: yovoleflag 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 2023/4/13 1:50, Torsten Duwe wrote: > On Wed, 29 Mar 2023 18:16:20 +0800 > yanhong wang wrote: > >> >> >> On 2023/3/29 17:41, Torsten Duwe wrote: >> > On Wed, 29 Mar 2023 11:42:07 +0800 >> > Yanhong Wang wrote: >> > >> >> v5: >> > [...] >> >> - Splitted starfive_visionfive2_defconfig into starfive_visionfive2_12a_defconfig >> >> and starfive_visionfive2_13b_defconfig. >> > >> > Is this really necessary? It puts another burden on people building U-Boot, >> > distribution networks, and last but not least users, who will need to pick the >> > correct binary blob, after trying to find out which board they actually have. >> > >> > Even past versions can detect the installed RAM correctly and will modify >> > 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 ethernet >> > 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, and flexible > enough to be patched into shape later. But see below... > >> 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 the definition >> of defconfig in V5 is also separated. >> >> The discussion process as follows: >> >> https://patchwork.ozlabs.org/project/uboot/patch/20230316025332.3297-18-yanhong.wang@starfivetech.com/ >> >> Do you have any better suggestion on whether defconfig is defined separately? > > Andreas' concern is the match between the device tree and the actual hardware, > as far as it matters for (driver) software. So, different hardware => different 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? > Yes, before gmac and phy were added, everything was the same except for 'model', but the definition of DT refers to Linux and is consistent with the definition framework of Linux. The difference between 1.2A and 1.3B is the PHY type and phy clock delay configuration, which are reflected in DT, and the difference in defconfig is the configuration of the DT file. Is defconfig defined separately or merged? > From 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 fixup functions > from common/fdt_support.c to adapt the device tree details to the detected board? > The EEPROM is being prepared and will be submitted as soon as possible. Is it necessary to incorporate EEPROM into this submission? When eeprom is supported, the MAC address will be read from eeprom. The board reversion can be read from eeprom, but phy clock delay configuration cannot be read from eeprom, only in DT. > Torsten