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 7D3D3C77B6E for ; Fri, 14 Apr 2023 15:05:33 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id A9EFD85CD4; Fri, 14 Apr 2023 17:05:30 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="jmuuva2+"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 8803185C49; Fri, 14 Apr 2023 17:05:28 +0200 (CEST) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 5E4D585D28 for ; Fri, 14 Apr 2023 17:05:23 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=matthias.bgg@gmail.com Received: by mail-wr1-x42d.google.com with SMTP id e16so4561817wra.6 for ; Fri, 14 Apr 2023 08:05:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681484723; x=1684076723; h=content-transfer-encoding:in-reply-to:subject:from:content-language :references:cc:to:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=244oejoqjkMNJX6rte8kSXcTGlLKBwJ5joK6b5OudXc=; b=jmuuva2+IKJO1Skbns/EvPgYi7XVoObV5jRkQljmugd3PV8fwTkfj38q2oPztNaE9f 5eebIGpebDnEvDuPc3K5v6VxJawuZms7eoM4pvoGzDhh49aMEvHB3ieXXoSCqir0JLKo bqPCY0+93dsiAg8krMJinV4Rq/Qio7Y8iLTZzXTRHDHkyqIXVeJL8F5XBfALP2KnPnWX v1tvpwbmrwfxcp7FxEERm3V5Y7WlSPcOYK5wti2gfBCsAe21Asr7L9boTsRY+R4YCZUu h0zclqVkBRHrZjoCwZ0/IkI3Rc7rg3Plq879eobJszKIl556PCZVPCJknRFhkUKNBMZR xa7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681484723; x=1684076723; h=content-transfer-encoding:in-reply-to:subject:from:content-language :references:cc:to:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=244oejoqjkMNJX6rte8kSXcTGlLKBwJ5joK6b5OudXc=; b=h6jx46m2yYwbNKD3Z3hv6DMQ/VfuK/gSD4wmRtj1jAvFZ4RcVPD1ifFvZ+GE7z7Hr2 hd8a/hiEqjPFjhsyNCe0g0T32uJ4CYLMoldNv97V7wJlLLsaY1mxP2K4Gd1MztJ3/jyW jMB8IOEqOqCqkzWyqQc3AvENiXHGnGkERjbaaDVtEbw+t2N+H98sW0t2Rz+pDjRVuwOb Y0f/LIZOE/xraXsUi0qrfSz4Ag6zFA9y4orYCmY3Jzu02wqbysN/phWubuBRK9wypiQd fXwuB18HVeLZ8yQ+CngQx0eKvlrpH3Rjv0moQR1JrKmIpIeCVImb3j+FJV/hbLnEmfSD S7hw== X-Gm-Message-State: AAQBX9e12Fv+04f/nx8R8CQOoEc6es71kWF+5O7W4GUK2d7GB/nA9jC+ fWZ40Hom0m3CkuxitWLvljE= X-Google-Smtp-Source: AKy350ao33eS+g7W8z0NCkA+lO18vopRP+DJEP7phRby67fi5BbSkGwVqVmZNKO9H6Qrj1BGqgE12Q== X-Received: by 2002:a5d:438f:0:b0:2f2:783f:ae4a with SMTP id i15-20020a5d438f000000b002f2783fae4amr4380255wrq.32.1681484722426; Fri, 14 Apr 2023 08:05:22 -0700 (PDT) Received: from [192.168.1.135] ([207.188.167.132]) by smtp.gmail.com with ESMTPSA id l42-20020a05600c1d2a00b003ef6988e54csm8226667wms.15.2023.04.14.08.05.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Apr 2023 08:05:21 -0700 (PDT) Message-ID: <230f4552-0e89-438e-c9b7-e8b8061713ba@gmail.com> Date: Fri, 14 Apr 2023 17:05:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 To: yanhong wang , Torsten Duwe Cc: u-boot@lists.denx.de, 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> <20230413110317.42581eaa@blackhole.lan> Content-Language: en-US From: Matthias Brugger Subject: Re: [PATCH v5 00/17] Basic StarFive JH7110 RISC-V SoC support In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 13/04/2023 12:05, yanhong wang wrote: > > > On 2023/4/13 17:03, Torsten Duwe wrote: >> On Thu, 13 Apr 2023 10:05:28 +0800 >> yanhong wang wrote: >> >>> the definition of DT refers to Linux and is consistent with the definition framework of Linux. >> >> This is one of the desired goals, to avoid confusion, usually. But note there are already the >> -u-boot.dtsi files; in this case it would be vice-versa: U-Boot could be simple, the kernel >> required a different treatment. As long as the resulting tree matches the hardware! >> >>> 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? >> >> You are the implementer, this is your decision. You make a proposal, and it will get accepted >> or not. We only make suggestions, with the intention to improve the code. >> > > Thanks. A defconfig matches a piece of hardware, which is more developer-friendly and less confusing, > so defconfig is better defined separately. > My opinion isIn my opinion user-friendlyness is more important then developer friendly that from an end-user point of view it's much easier to have one binary that works on all different board versions. If not users will have to know which board version they have to flash the correct U-Boot. For the RaspberryPi we even went further and put effort into U-Boot development to have one U-Boot binary which can boot RPi3 and RPi4 boards. In that sense I would advise you to revisit your decision to put a developer-friendly approach over an end-user-friendly one. As Torsten said, it shouldn't be too difficult to update the device-tree at boot time to fit the actual board you are running U-Boot on. Just my thoughts about the issue :) Best regards, Matthias >>> 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. >> >> But the board revision number in EEPROM can be used to differentiate between 1.2 and 1.3, right? >> > > Yes, board reversion read from eeprom can distinguish between 1.2A and 1.3B. > > 1.2A and 1.3B are two sets of hardware, and the differences between the hardware are defined > by DT, which is more concise and clear. > >> When I look at the code and my test results, this is my proposal to pull this in, in order to >> simplify things and avoid duplication. Whether you do so is up to you, see above. Let me recap: >> >> * the device tree *must* match the hardware at hand. >> >> * the differences are minor and could be patched, Copy&Waste is error prone and causes extra work. >> >> It is my firm conviction that this patch set does not introduce hardware variants, and it would be >> the task of the ethernet driver patch set to split the code (DT+defconfig) OR to provide a patching >> method. Maybe I find a few cycles to look at the EEPROM. >> >> Torsten