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 03424C433F5 for ; Thu, 20 Jan 2022 08:36:02 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 10D4E83325; Thu, 20 Jan 2022 09:36:00 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=walle.cc 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; secure) header.d=walle.cc header.i=@walle.cc header.b="Wc2Lcl1q"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id D4B0E832CD; Thu, 20 Jan 2022 09:35:58 +0100 (CET) Received: from ssl.serverraum.org (ssl.serverraum.org [IPv6:2a01:4f8:151:8464::1:2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 7404583388 for ; Thu, 20 Jan 2022 09:35:56 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=walle.cc Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=michael@walle.cc Received: from mwalle01.kontron.local. (unknown [213.135.10.150]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ssl.serverraum.org (Postfix) with ESMTPSA id A15D522247; Thu, 20 Jan 2022 09:35:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2016061301; t=1642667754; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=n0SzgCIv6yroluVfbAVsZrjDqNTCeXfGAQXh2UwY0Vg=; b=Wc2Lcl1qVQK7eZyWEU7z88za2YBq74aqcMBcwIAduM9HwBsCEvy7RtIyatNEW9goJfi080 zdfZwtIHHuWhNZ4RTQmRdnRDjO7B0CaZ2SmuAxiawtFcaK+zp6XJhZHa1DswSRnmPXRqh2 wbcLuIxu2KC4HFdBoRNt92qjhdUTTnk= From: Michael Walle To: sjg@chromium.org Cc: daniel.schwierzeck@gmail.com, dennis@ausil.us, ilias.apalodimas@linaro.org, jaeckel-floss@eyet-services.de, lukas.auer@aisec.fraunhofer.de, mark.kettenis@xs4all.nl, michal.simek@xilinx.com, trini@konsulko.com, u-boot@lists.denx.de, xypron.glpk@gmx.de, Michael Walle Subject: Re: [PATCH v3 31/31] RFC: Switch rpi over to use bootstd Date: Thu, 20 Jan 2022 09:35:44 +0100 Message-Id: <20220120083544.2964521-1-michael@walle.cc> X-Mailer: git-send-email 2.30.2 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 > 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. So it doesn't really matter how the general list is sorted, but sorting by the speed of the interface sounds.. strange. -michael