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 B7306C433EF for ; Fri, 21 Jan 2022 01:08:35 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 77EE883864; Fri, 21 Jan 2022 02:08:33 +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="mHJNKjGs"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 8FD3983890; Fri, 21 Jan 2022 02:08:31 +0100 (CET) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 9B0968383F for ; Fri, 21 Jan 2022 02:08:27 +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-qk1-x736.google.com with SMTP id p9so8235221qkh.3 for ; Thu, 20 Jan 2022 17:08:27 -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=JcQKxAcf73f1MiJrjdu/hWEKtRD9maAMeH4K//ue8eQ=; b=mHJNKjGsj3xQt+PI1PjmKCt1XrRXNvP9T+4dR5aj0xT23/3olckIuw7SkZRgHuGJ0P IjM/EHpzxxkuXfb1DM0Dgkfv8WeyUah7iUxvt+GRdJk8VDppHs8PLaoL5UeGS/vhejtW cjWB5tT5PUVsO0Ok1uno2FMI5l8M/F3WYCGUo= 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=JcQKxAcf73f1MiJrjdu/hWEKtRD9maAMeH4K//ue8eQ=; b=5HErmjaOguw/fg2ykbHfsjIr4w8IEMGNsDxR/b0VOza2iUTC6iKpqOs3HK/nbbVLAl UBldE3qcaFLT2jbouqoEBFuCh7ASbuEqECuuAGo59+r75p6UBNQabK+7+ha50Ddcp/Np iuSziyqgWk+lmtkHie6P3bTiHE4hJQF18SqA2KJx9YOLtOlKkfePKr/UG+98xRdwNWXq VkDmQLtIsiwJYAGiarpySdU4fNTE7l9OfwNi6mrp51/rAw1PwgRejgV6ro6eggm142fi G8DJpai5E06Jy3CreMKojZ1N+WmVEgw+WfV3Lz1Qw9jbP0RbHj157OAXJ5v3Vw+wNLAt p8MA== X-Gm-Message-State: AOAM533e8OF9plJ0X6PQE6Cgk002wdpUlXx7D8jZAf/DI2JIKXPxkgl7 vnx4/LZRI2Zglq5fNCBaJEZWuQ== X-Google-Smtp-Source: ABdhPJwxdL+qaM0VtySZQhNnb+qAwEkrvvFeWwjSOkuyRRiWwm68zs3RWnxV/6P3I3KQFZ6tDQ496A== X-Received: by 2002:a05:620a:254a:: with SMTP id s10mr1221773qko.654.1642727306181; Thu, 20 Jan 2022 17:08:26 -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 s7sm55238qki.20.2022.01.20.17.08.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Jan 2022 17:08:25 -0800 (PST) Date: Thu, 20 Jan 2022 20:08:23 -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: <20220121010823.GP7004@bill-the-cat> References: <20220120083544.2964521-1-michael@walle.cc> <20220120183047.GJ7004@bill-the-cat> <20220120200851.GM7004@bill-the-cat> <20220120232303.GO7004@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tfmLD+Hxjexp/STe" 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.2 at phobos.denx.de X-Virus-Status: Clean --tfmLD+Hxjexp/STe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 20, 2022 at 05:59:53PM -0700, Simon Glass wrote: > Hi Tom, >=20 > 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 wrote: > > > > > > > > > > > > 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 assu= med speed of > > > > > > > > > > the device, so the board would only need to intervene (= with an env var > > > > > > > > > > or a devicetree property) when that is wrong. > > > > > > > > > > > > > > > > > > Does this make sense in general? The default boot order f= or a > > > > > > > > > board should depend on what is available on board (or on = the > > > > > > > > > carrier board) and what is pluggable. I doubt there can b= e 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 problem is= here? If > > > > > > > the board does not have a device then it will not exist in dr= iver > > > > > > > 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 board c= an still > > > > > > define the default probe order via environment. But pick any r= andom 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 oppo= site and > > > > > > both are going to probe in the same order since it's the same c= hip. > > > > > > > > > > > > That's what I think Mark is getting at with it not really makin= g sense > > > > > > to just rely on probe order as what to try. > > > > > > > > > > Doesn't the 'non-removable' flag describe this feature of the har= dware? > > > > > > > > > > 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 required= for > > > > > 'normal' boards and situations. > > > > > > > > I think setting things via the environment to have correct defaults= is a > > > > must. I mean, yes, OK, if there's some device tree binding that we= can > > > > use that describes this, sure, that's choice A. But choice B would > > > > probably be environment strings. Probe and hope is choice C, or mo= re > > > > 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 some > > agreed on standard to provide that information at run time. >=20 > Well we can do that with a cut-down distro header with some macros, I sup= pose? Sorry? I mean, when I said standard above, and since you had mentioned =66rom the device tree before (I thought..) I mean get some property defined and accepted and use that for first best path. Then keep using boot_targets and make sure it's documented (and in help, etc) that boards should define that in their default environment for a preferred fallback default boot order. The final fall back of "probe and guess" might need an off switch for securing systems, I'm not sure. --=20 Tom --tfmLD+Hxjexp/STe Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmHqB4QACgkQFHw5/5Y0 tywrZAv8CNisbvph+N8fsJ/2+Jf5eeOhcQZ+y7d8diQ0FoEdqYrFV6MmY7NqhUaz jrll2xhqAjnC2tgX+ckETHzaqUEf5JOAGR7X28Va6M4adO0YnlqJNqtBrjJkwAyx m+sUDv37ZDGQSak4K0pnrU4X6LfG8k85FFgpTe8BS8caOz2SoNuWE+6T2wwuh5ni xdPJ2q11DuDGyrDebbBx5pmMyPVeJbixKrBeYYT2rIf0XdQKMpmGHBnMXsD/ZeUi O59FbiJjFEHzZhNEq9/4ElMlqNYKTzDt2IBYxmPAzRGSR6c+wJ683hy1AYsViPPY zmmQDgH7oYGiMMzIhQgA0jFFzouTNYQ+yEMitjsVIivA/Kqt3n7duzC+v1u+H10x YJRiKmuDy6F0KzAy1J1Cy5mFUsu2iyOOv9Qp+rhphRhwpR8aPTdAjhPlbjvAB6CO I5BlvnmiKcPJscgg5cx6FjzNX9LzItMXAHzo7GJrdQP3468WlPFWyYlzkv90YwPn VbKZSFxW =qeJH -----END PGP SIGNATURE----- --tfmLD+Hxjexp/STe--