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 27648C433F5 for ; Tue, 15 Feb 2022 13:28:06 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 0864781F4D; Tue, 15 Feb 2022 14:28:04 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=foundries.io 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=foundries.io header.i=@foundries.io header.b="O8kWmj4T"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id EBDEC81FC6; Tue, 15 Feb 2022 14:28:00 +0100 (CET) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 DBD3F8009D for ; Tue, 15 Feb 2022 14:27:56 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=foundries.io Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=jorge@foundries.io Received: by mail-wr1-x432.google.com with SMTP id u1so18363767wrg.11 for ; Tue, 15 Feb 2022 05:27:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foundries.io; s=google; h=from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=uuH2WPyWiaXHzVdcHDy43OscpIHGDFcZ+oPQlAGFBEU=; b=O8kWmj4TBcWtTz69ZcDItbxzkNyvAc99I992GJgv+Bmbd++MZcCJDvtbdiWzPsdiwQ A5vxi5wR9bs/iS9E+fudPtWUc3ePMRCAXJOKObCVEPvF3G+4pLfSKujFsMauLn9ow7Ea l18YQLP74jD62rMS3ZipFbikhMQklk7tUTrbN6vkctMTdcjKPSPOHvxMtgLpr55PplDb DcU3Z1GFxW8m7OXYqs93AkiaNO7/PDE8L3kgKqgpG8l5vv0EzAHwY5zk61bkoqKJLB8e lspuYmKI7rD3/SzT2goPx2rcfVOWjnqEVteQmlKCglIqRLi3qRqkMwiVG3L9Lvl98Swg 7qoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=uuH2WPyWiaXHzVdcHDy43OscpIHGDFcZ+oPQlAGFBEU=; b=K3Im1fSEl4GIPs4hYCu5BGh24gaEbS6pRuMnq1sp+YGp4OckSz7LGHLoUzmAD9NvPO 2E1IShogCmSrW/Du+rR1+pyLtD+lA0xEUpBGvs28eO9i7UxTKbaKPDk7ZoCtGJXGLMc8 4vOjS8tcFDKhFZHLZoUxKtgmd1aA/nCvlZQnrufx+x0fTidj1EBNubW6vIx/PoRg1omS KkEUXlzedQQtomANDgOt+VSCFRfvAnNq0l3qC6c6fXx+k73i3NCTOB3PzKaz+Cheg1cs oLf+vFEgPrXbXbX5tb7fkgK6iP/qxJ/EfXmWF/FZy8mIEFd0Tf49iJ5CA+9ECUMuOruj MHrA== X-Gm-Message-State: AOAM531s4Ih3MAz8mfqNyW1VLf/kGXwCZbrHdapdtp1wYikMDo7H85Go htpp+yk98dXL1Y3fq+WHzcIwNg== X-Google-Smtp-Source: ABdhPJyvq37xk+xWcROgcey0duy1tWnBz5GoMRvj95vlvSuXNz6F1vyhXsUA0gQfXoAqSiuiD17tfw== X-Received: by 2002:a5d:6382:: with SMTP id p2mr3264442wru.548.1644931676388; Tue, 15 Feb 2022 05:27:56 -0800 (PST) Received: from trex (94.red-80-26-192.dynamicip.rima-tde.net. [80.26.192.94]) by smtp.gmail.com with ESMTPSA id g4sm7543959wri.88.2022.02.15.05.27.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Feb 2022 05:27:55 -0800 (PST) From: "Jorge Ramirez-Ortiz, Foundries" X-Google-Original-From: "Jorge Ramirez-Ortiz, Foundries" Date: Tue, 15 Feb 2022 14:27:54 +0100 To: Michal Simek Cc: Ricardo Salveti , u-boot@lists.denx.de, Jorge Ramirez , Igor Opaniuk , Oleksandr Suvorov Subject: Re: Unable to select a different ENV location due env_get_location on zynqmp Message-ID: <20220215132754.GA317538@trex> References: 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.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.5 at phobos.denx.de X-Virus-Status: Clean On 15/02/22, Michal Simek wrote: > Hi, > > On 2/14/22 21:10, Ricardo Salveti wrote: > > Hi Michal, > > > > This is a bit similar to the issue raised on iMX8-based targets a few > > days ago, which is forcing the environment location based on the boot > > mode and not allowing the user to use a different option via other > > CONFIG options. > > > > Should we really force the env location based on boot mode? Currently > > there is no way to boot out of QSPI and save the environment on > > emmc/fat/ext4, and removing CONFIG_ENV_IS_IN_SPI_FLASH causes the env > > location to be set as ENVL_NOWHERE, which is not ideal, especially > > when other env target locations are available at build time. > > > > diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c > > index f0be9c022a7..08afb49570a 100644 > > --- a/board/xilinx/zynqmp/zynqmp.c > > +++ b/board/xilinx/zynqmp/zynqmp.c > > @@ -969,6 +969,10 @@ enum env_location env_get_location(enum > > env_operation op, int prio) > > case QSPI_MODE_32BIT: > > if (IS_ENABLED(CONFIG_ENV_IS_IN_SPI_FLASH)) > > return ENVL_SPI_FLASH; > > + if (IS_ENABLED(CONFIG_ENV_IS_IN_FAT)) > > + return ENVL_FAT; > > + if (IS_ENABLED(CONFIG_ENV_IS_IN_EXT4)) > > + return ENVL_EXT4; > > return ENVL_NOWHERE; > > case JTAG_MODE: > > default: > > > > A change like this one would allow other locations to be set, and just > > use the boot mode to assign the priority instead. > > > > Since I couldn't really find out what is the expected behavior on > > functions defined at soc/board level (env.c sets based on priority, > > depending on what is enabled at build time), I was wondering if we > > shouldn't just drop this function entirely. > > > > While I agree the board should have a set of defaults, not allowing > > the user to change something like env location via CONFIGs seems wrong > > to me. > > > > Let me know what you think. > > Default location is setup based on how Xilinx sees where that variables > should be saved for the most cases that's why that function was done like > this. > That's why I think that it is very reasonable default setup. I disagree. I see no actual need to hardcode the environment location the way it is done. It serves no purpose. > And as is hopefully known we are using pretty generic u-boot which should > work on all configurations it means default defconfig have all options > enabled. > > Does it make sense to have an option to change it to any configuration? > Definitely. > > How to do it? > DT is for us source of truth that's why I prefer to have DT description > which is providing all information. It means say where variables should be > stored, where redundant variables should be stored. IIRC as of today I think > they have to be on the same device which can be also more flexible. You can > specify different start/end in qspis, etc. > > What has to happen? > Someone has to take a lead and come up with generic universal DT binding to > be able describe it. Some days ago linaro had similar issue with DT in > connection to A/B update via GPT partition. And description for it should be > pretty much the same as is for variables. are you saying that unless you have a DT change you wont let the user choose where the place the environment? if so, I'd like to undestand why. As I said, it seems biased and unreasoanble hence why I think it deserves further justification. > > Thanks, > Michal