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 ED515C433F5 for ; Fri, 21 Jan 2022 15:05:59 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 1FBEA819D3; Fri, 21 Jan 2022 16:05:58 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=konsulko.com header.i=@konsulko.com header.b="AgjiPVM9"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id F3B9A81B53; Fri, 21 Jan 2022 16:05:56 +0100 (CET) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (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 0A7D381426 for ; Fri, 21 Jan 2022 16:05:54 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qv1-xf31.google.com with SMTP id hu2so10657479qvb.8 for ; Fri, 21 Jan 2022 07:05:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Dza5tMElxLjlRnNat2dzA56w3Qp1BcGC1GF36WIiSis=; b=AgjiPVM9hprOR2adzrjaiK5HSXWvdMk3EfDhgNJoJgYPZ+z91lwH2OYF6CyJHl8b+S oEJ1dfgNBT54xRPQffL2S9zX2A/v/Wnu8nUbmpra5Y+E0r+9sFR/mKidZ2/d7MwUSklO ihcJLE7+MqZbVPBzLls1KOQihT0XUya8y+bMI= 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=Dza5tMElxLjlRnNat2dzA56w3Qp1BcGC1GF36WIiSis=; b=rxb51cB3Q3+mBArcpST3wDqDQYVpNbK/rxtE9ee33YsLiXb8Yxlc3Ti8dxw31M1M7h +Rhi20swCFciiksnws1euBTXCWLn/JLpzk7G46mB/qY15urBDs0t/513VtNC0lV/WYWw 4i2a6Kb75h76ZjUkr9u5c43beKuKwOeMEH6Qlol7j//5zh3dzxi18eQRWZ9xLfk26V/E avOUBUUiVreGyAMu0C6JexqfWe5i0rPQ9MKQTi0LuYSRsfGS/n1DEzO5Rh/BDG2005U9 KIv5wH0XztfTr5imnT+Bh4t7JlD6qpoBpoEOWSDsTMRS+vZg/avM7263FdvXjWaFh5Eb AxrQ== X-Gm-Message-State: AOAM533cDXJNr65tuCF5uZBUfjxMacQl35kGBs/SUtMGMWTfnw7B3uIb o9XEIBy5DyYn7TK2ZzWU8jNN7Ue4D4/pMQ== X-Google-Smtp-Source: ABdhPJyPAMVo4lza/Hp3Y9umNdFVycrtjOBx81+2CEbiPYYnIqTaYly6bolHivvUtf1/SOKP2ytLyQ== X-Received: by 2002:a05:6214:1d27:: with SMTP id f7mr3853515qvd.107.1642777552648; Fri, 21 Jan 2022 07:05:52 -0800 (PST) Received: from bill-the-cat (2603-6081-7b01-cbda-2ef0-5dff-fedb-a8ba.res6.spectrum.com. [2603:6081:7b01:cbda:2ef0:5dff:fedb:a8ba]) by smtp.gmail.com with ESMTPSA id m20sm3578213qkn.6.2022.01.21.07.05.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Jan 2022 07:05:51 -0800 (PST) Date: Fri, 21 Jan 2022 10:05:49 -0500 From: Tom Rini To: Simon Glass Cc: Mark Kettenis , Michael Walle , Daniel Schwierzeck , Dennis Gilmore , Ilias Apalodimas , Steffen Jaeckel , Lukas Auer , Michal Simek , U-Boot Mailing List , Heinrich Schuchardt Subject: Re: [PATCH v3 31/31] RFC: Switch rpi over to use bootstd Message-ID: <20220121150549.GS7004@bill-the-cat> References: <20220120183047.GJ7004@bill-the-cat> <20220120200851.GM7004@bill-the-cat> <20220120232303.GO7004@bill-the-cat> <20220121010823.GP7004@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Po3hG7FLjYU3tiSY" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett 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 --Po3hG7FLjYU3tiSY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 20, 2022 at 08:12:41PM -0700, Simon Glass wrote: > Hi Tom, >=20 > On Thu, 20 Jan 2022 at 18:08, Tom Rini wrote: > > > > On Thu, Jan 20, 2022 at 05:59:53PM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 20 Jan 2022 at 16:23, Tom Rini wrote: > > > > > > > > On Thu, Jan 20, 2022 at 01:47:41PM -0700, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 20 Jan 2022 at 13:08, Tom Rini wrote: > > > > > > > > > > > > On Thu, Jan 20, 2022 at 12:56:55PM -0700, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Thu, 20 Jan 2022 at 11:30, Tom Rini w= rote: > > > > > > > > > > > > > > > > On Thu, Jan 20, 2022 at 11:16:35AM -0700, Simon Glass wrote: > > > > > > > > > Hi Mark, > > > > > > > > > > > > > > > > > > On Thu, 20 Jan 2022 at 03:29, Mark Kettenis wrote: > > > > > > > > > > > > > > > > > > > > > From: Michael Walle > > > > > > > > > > > Date: Thu, 20 Jan 2022 09:35:44 +0100 > > > > > > > > > > > > > > > > > > > > > > > The bootdevs have a natural priority, based on the = assumed speed of > > > > > > > > > > > > the device, so the board would only need to interve= ne (with an env var > > > > > > > > > > > > or a devicetree property) when that is wrong. > > > > > > > > > > > > > > > > > > > > > > Does this make sense in general? The default boot ord= er for a > > > > > > > > > > > board should depend on what is available on board (or= on the > > > > > > > > > > > carrier board) and what is pluggable. I doubt there c= an be a sane > > > > > > > > > > > default, so almost all boards will have to define its= own > > > > > > > > > > > boot order anyway. > > > > > > > > > > > > > > > > > > Please can you be more specific about what you the proble= m is here? If > > > > > > > > > the board does not have a device then it will not exist i= n driver > > > > > > > > > model (or will not probe) and it won't have a bootdev (or= it won't > > > > > > > > > probe). That seems to be equivalent to me. > > > > > > > > > > > > > > > > So, I'm not sure how much of a problem it is, since the boa= rd can still > > > > > > > > define the default probe order via environment. But pick a= ny random SoC > > > > > > > > with more than 1 SD/MMC set of lines on the chip. Youboard= may put the > > > > > > > > first as SD slot and second as eMMC and Myboard may do the = opposite and > > > > > > > > both are going to probe in the same order since it's the sa= me chip. > > > > > > > > > > > > > > > > That's what I think Mark is getting at with it not really m= aking sense > > > > > > > > to just rely on probe order as what to try. > > > > > > > > > > > > > > Doesn't the 'non-removable' flag describe this feature of the= hardware? > > > > > > > > > > > > > > If you don't want to rely on the normal ordering, you can set= the > > > > > > > boot_targets variable. I'd just like to avoid that being requ= ired for > > > > > > > 'normal' boards and situations. > > > > > > > > > > > > I think setting things via the environment to have correct defa= ults is a > > > > > > must. I mean, yes, OK, if there's some device tree binding tha= t we can > > > > > > use that describes this, sure, that's choice A. But choice B w= ould > > > > > > probably be environment strings. Probe and hope is choice C, o= r more > > > > > > like last resort, imho. > > > > > > > > > > Well the boot_targets var is implemented in this series. > > > > > > > > > > The question is whether we force platforms to define it, or have = a way > > > > > to handle things gracefully by default. > > > > > > > > I think we need to force it to be defined until / unless there's so= me > > > > agreed on standard to provide that information at run time. > > > > > > Well we can do that with a cut-down distro header with some macros, I= suppose? > > > > Sorry? I mean, when I said standard above, and since you had mentioned > > from the device tree before (I thought..) I mean get some property > > defined and accepted and use that for first best path. Then keep using >=20 > I think this discussion is a bit beyond the scope of this series. You > are talking about the policy for the bootdev selection. So far, > implemented in this series, we have, in order of preference: I still owe comments on the concept, but I want to make sure we don't end up in another case where we ad-hoc something for device tree and keep building off of it without it being made official. --=20 Tom --Po3hG7FLjYU3tiSY Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmHqy80ACgkQFHw5/5Y0 tyyviAv9G1Lu46lCZ1ebSujHiq3liUf1nl/U19GLACrI6bmXCyCRAY9jT1vlu4JJ 0I9E4ggbLSYxCtiPR0yIQvyWhQa5imIErsrHeMgNJsajW6fInaQQtr2urQv61Hdg KyXNuNtMl/RBTzJCgMy5266vBb4jq8NEPPO3J873Cbj+8QT/DCzUC4k1ykjI/erO ey7wL9ni9BsM1zisFC/cS63swfXqJ6TJKN2GKxGacjDzNFbinUXpC6jSggTAZf0z +8bP6+iloxEmbg+h0u3MnB71aSDS7YVEXT2j1mD8G+aRFbkOBmaZwoLjqI3yXAfb dmuKVyMlsJRgMbZ4OlMaDJUllW75dTCTjmntfqp1cYWsKFheq11GXW0fI+Y9j8R7 E2371AqIPx5Kph561mxmbP31R9C6ApLFrds/2QwUisTThaSq3b/LwIFHse6kHuzl NsDbQ3oVQe7NEuqaCIo4sSmj2b1n1P8x6iiAeOu9RXw3r4Bij8w5epjltVjjUixf liKe+tM3 =dfUy -----END PGP SIGNATURE----- --Po3hG7FLjYU3tiSY--