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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B29C1C433F5 for ; Wed, 29 Sep 2021 09:02:29 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id BB18D610C8 for ; Wed, 29 Sep 2021 09:02:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org BB18D610C8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id DDF148296F; Wed, 29 Sep 2021 11:02:25 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org 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=linaro.org header.i=@linaro.org header.b="uUnZfETR"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 8379682DC1; Wed, 29 Sep 2021 11:02:23 +0200 (CEST) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 6C9CA8281E for ; Wed, 29 Sep 2021 11:02:20 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=ilias.apalodimas@linaro.org Received: by mail-ed1-x52d.google.com with SMTP id l8so5966166edw.2 for ; Wed, 29 Sep 2021 02:02:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=b/RPg0zxuSgpUg8DQ7fwkSbwTNjcyzlRW0eGOkGN/3o=; b=uUnZfETRWdvYioAk1vbjKOwg3g5rDChBJU/9FeDdulV0sY7Z3c+/xNq11MzeT1TxAU fqTrcoGlO2/ScRqOLra7lZOX9JZ+WRfTdKOA4/HsfFlR7ri8Mrn44ZNSTVu4Gtg1mHRi QOLV7945INk3iPT+0Z8cPYImTKuS5CrNW2E73giuYU19no8inN8gKcUJ3WypLOUmBpGV +QrwLFbUk9320LJ2dMll7qDsprvJXRg4ed96qYL3nXDP6dX8U4Sq2VgHjwLEHWgw1agS n8xX/1qNDF5LKV6/Nk1elJ4J7Tv6KegFrjXH64dpY2sJ5h5Dq75Tdo5xLk1J4NIHVush rExw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=b/RPg0zxuSgpUg8DQ7fwkSbwTNjcyzlRW0eGOkGN/3o=; b=jPOKSWt2kBMr+9CGrEGvmQuQft2b5rFJdXBg9Nt4cfKfj/bmUtPxGKsB2nO6zPC5pK 1mgiS3F/0LGk2UGmJkeHO8ewmgvmS08xIEVXinVhAj3HDTH4lSuRaCt+zxOnerDAXr5y R9lIbS/xuMZeQPGtYgpkcrN+YnOuFRHf3/1fRoHV2Dk8Xv46Zohb+bEY4pyylobuizF/ a4jk+zkINzaQf9r3qkqG5YNVSLAAaQ8GQ38+ZOy1UsiQ9BAtwukhrCjvnsC1Oaud2XRQ vrQeAKI9nuiCbG/8C++LNB3cYGdm5AUKAB85jdNG6vC7iSct+zznO2DIxJeNn/xtM5RT Cz6Q== X-Gm-Message-State: AOAM531nuH8uEcGY+ObBDN7IDEddBazmvll1wvrURvbV4w7dxiX8fUMG Q2ERQ+R23OMUTkYBo1Hew+HuUQ== X-Google-Smtp-Source: ABdhPJyqt3bKle/O76i3qo5b35Z00yjD80lCqBcsZvRcS5puXJvNghPZoOmpPvFVF/FD+EjQUIXffQ== X-Received: by 2002:a17:906:7fc4:: with SMTP id r4mr12572311ejs.75.1632906139860; Wed, 29 Sep 2021 02:02:19 -0700 (PDT) Received: from apalos.home (ppp-94-66-220-209.home.otenet.gr. [94.66.220.209]) by smtp.gmail.com with ESMTPSA id v10sm1086240edt.24.2021.09.29.02.02.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Sep 2021 02:02:19 -0700 (PDT) Date: Wed, 29 Sep 2021 12:02:16 +0300 From: Ilias Apalodimas To: Zong Li Cc: trini@konsulko.com, mark.kettenis@xs4all.nl, Bharat Gooty , Rayagonda Kokatanur , Rick Chen , Leo , Thomas Fitzsimmons , Simon Glass , Bin Meng , Marek =?iso-8859-1?Q?Beh=FAn?= , Green Wan , Sean Anderson , Lukas Auer , Brad Kim , Heinrich Schuchardt , David Abdurachmanov , Dimitri John Ledkov , U-Boot Mailing List Subject: Re: [PATCH 1/3] treewide: Remove OF_PRIOR_STAGE from RISC-V boards Message-ID: References: <20210927064751.78591-1-ilias.apalodimas@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 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.2 at phobos.denx.de X-Virus-Status: Clean Hi Zong, [...] > > diff --git a/board/sifive/unleashed/unleashed.c b/board/sifive/unleashed/unleashed.c > > index 8cd514df3005..7e89c3f740a7 100644 > > --- a/board/sifive/unleashed/unleashed.c > > +++ b/board/sifive/unleashed/unleashed.c > > @@ -116,12 +116,10 @@ int misc_init_r(void) > > > > void *board_fdt_blob_setup(void) > > { > > - if (IS_ENABLED(CONFIG_OF_SEPARATE)) { > > - if (gd->arch.firmware_fdt_addr) > > - return (ulong *)gd->arch.firmware_fdt_addr; > > - else > > - return (ulong *)&_end; > > - } > > + if (gd->arch.firmware_fdt_addr) > > + return (void *)gd->arch.firmware_fdt_addr; > > + else > > + return (void *)&_end; > > } > > I was wondering if we need to check CONFIG_OF_BOARD here? I'm not sure > whether we should distinguish the value of a1 register which is > meaningless. It means that if we don't expect the device tree to be > passed by prior stage, then the a1 register might be a trash value at > the beginning, so it would still return the arch.firmware_fdt_addr > here, rather than _end. I thought about it as well. Those boards were configured up to now with 'CONFIG_OF_SEPARATE'. Which means we are looking at an existing issue? IOW the device tree was passed as part of U-Boot, which would mean a1 would have had thrash as well. Maybe a1 always has a valid DT on those boards so we never noticed? > And do you think that we should enable the > CONFIG_OF_BOARD for unmatched and unleashed? Because it seems to me > that we actually pass the device tree by prior stage (i.e. OpenSBI). Yes in that case what you request makes sense for unmatched/unleashed. Return gd->arch.firmware_fdt_addr in OF_BOARD is selected otherwise return _end (instead of the current check). If that sounds good to you I'll send a v2 [...] Regards /Ilias