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 5EF5FC433F5 for ; Thu, 20 Jan 2022 23:23:13 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 4711483890; Fri, 21 Jan 2022 00:23:11 +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="tD1BcjR0"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 88314838DA; Fri, 21 Jan 2022 00:23:09 +0100 (CET) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (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 BA9D98378B for ; Fri, 21 Jan 2022 00:23:06 +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-xf35.google.com with SMTP id a7so8548918qvl.1 for ; Thu, 20 Jan 2022 15:23:06 -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=PuL72U4joxXcXsMTZWGRTS+JOT6+bz83QOJgd21xkWI=; b=tD1BcjR0LGyLFIq35Nr9QkNa6Wez31EXY/AIGvU8ZHjW8uy0I5AZNaziLHzF0nNol5 O5gx6sQKk7GcaJxWWS9GfLkqHk2aXOhEsmnmWFWT/SKFFVCvLPaVQO9+/LjRRrxbAxYk 6R6ua++nX6CMbqKhRzNCnhCRK9rRBVHwhkuWU= 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=PuL72U4joxXcXsMTZWGRTS+JOT6+bz83QOJgd21xkWI=; b=CxD9G9ZNPXjqVeg3uPWN7XHPiOD5b22rAa3mZ932kvGEyLoE/odD58LB/K+1mpPYNF iQTYGS3EX4MIPTU/w5YtwoGP+ob7b7RJxce0PKurtQst3u56lWRokBmyk5mhx/N4WgaZ GVYuYpRWr+E6N9K9zdqFqjRF7cZgqvIAIH5nUP8cfhyJSq+W//v3iV/Sm8E/Hg92PNN/ +WVR//PXL+ZA/XTzIEIRragq3GdDsIrCoGrNZcCEOoowszeI1dBMRNZJ4hrv3fop1K/h jfOP1mcuxvwUsF0AJhLzIyoHO9JDC4LZRjoy0yzgi/9F9GCbwiqwShgRnVWBnI3yrOcM 32IQ== X-Gm-Message-State: AOAM532sZHOOTCsLicyHZ/L9lOFzVfJpADRXurUgltiMMq79A3XYxRpQ g+NuheZKdrLWDCtVIp5wzKPa8A== X-Google-Smtp-Source: ABdhPJziXQufJfC+IyJzG1mtRLrfoMBeS0jVd0LLVT5U7LzS066LAEDQ0L7Bsrf9Pgne91xztjPDuw== X-Received: by 2002:a05:6214:242d:: with SMTP id gy13mr1322641qvb.121.1642720985571; Thu, 20 Jan 2022 15:23:05 -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 de15sm2184821qkb.4.2022.01.20.15.23.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Jan 2022 15:23:04 -0800 (PST) Date: Thu, 20 Jan 2022 18:23:03 -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: <20220120232303.GO7004@bill-the-cat> References: <20220120083544.2964521-1-michael@walle.cc> <20220120183047.GJ7004@bill-the-cat> <20220120200851.GM7004@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VB1oQhYtJt8uuzk+" 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 --VB1oQhYtJt8uuzk+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 20, 2022 at 01:47:41PM -0700, Simon Glass wrote: > Hi Tom, >=20 > 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 assumed = 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 for a > > > > > > > board should depend on what is available on board (or on the > > > > > > > carrier board) and what is pluggable. I doubt there can 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 problem is her= e? If > > > > > the board does not have a device then it will not exist in 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 board can s= till > > > > define the default probe order via environment. But pick any rando= m 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 same chip. > > > > > > > > That's what I think Mark is getting at with it not really making se= nse > > > > to just rely on probe order as what to try. > > > > > > Doesn't the 'non-removable' flag describe this feature of the hardwar= e? > > > > > > 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 more > > like last resort, imho. >=20 > Well the boot_targets var is implemented in this series. >=20 > 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 Tom --VB1oQhYtJt8uuzk+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmHp7tYACgkQFHw5/5Y0 tyxrpgv+IGjj0BVFwCCPVc9AdQm1UhAHra6/a/KtQVYFLMU5oB2h644ADB4kTl84 3RFyFqniJOb8BBhZSX0PIGOQzn6NbcbKo3rFUEjOzCuT0NNc9YsySQRi3dwHAUty Q1VQ/JxHHzZiAzo9YsY5MhDOtIVKwmVA4L/4Ge3XvxGwS0dHD4oM8KH/qGdk2XjC XUTRaW7VTaMuAP4bu1xkhVlR2oClbvVWgNSPBjGIwA7HrA3RB5+kDp90qqk8+F/M gGbPxj/8TdrrxRfQwScECdVYp30/0nEKFoko2lxHNWvCbSrCAZfCjtxB4Oke9J0z puX0uZcrPSOIxO4yTAUcyjXlTupH3600uRByPbjSNWm8+f0NC7x6nRRxjLf6gd9i gEulthNLzAFHDJb258cs1kj/qzz/o3HTkUvsEVrG7uFZhld9qOJ49zKWDrFfTtM3 C96R9UNBreJC/E8Qvcon8WlLsV1fi9gRcHdxlZD2UEaGsf8N1uF0suGN4SjTF8Y6 DbyIW9kM =XANI -----END PGP SIGNATURE----- --VB1oQhYtJt8uuzk+--