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 3B48EEB64D8 for ; Wed, 14 Jun 2023 15:40:26 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id AD72C86180; Wed, 14 Jun 2023 17:40:23 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=collabora.com 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=collabora.com header.i=@collabora.com header.b="ibutljzu"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 9D01086181; Wed, 14 Jun 2023 17:40:21 +0200 (CEST) Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) (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 2B40686146 for ; Wed, 14 Jun 2023 17:40:19 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=collabora.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=detlev.casanova@collabora.com Received: from arisu.localnet (mtl.collabora.ca [66.171.169.34]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: detlev) by madras.collabora.co.uk (Postfix) with ESMTPSA id 411616606F4F; Wed, 14 Jun 2023 16:40:18 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1686757218; bh=EAkboDJMGhsDrNdx8gsQC3DJfJPMyyUvaqZ6VE0EB4I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ibutljzuGGcZ5vZKMjjEK4pZ/d2/MjlkW56D35JpV22A6edCdvUOrXHDeQGUhWRzK 1LhdSy7w/+BDBRUKP51Wzs/E/d2Yx3Lm1h/A4KESFuNUTA3YkRx3RO1YTOLajLIYfq +k1RyK23lrwRvmQrEKuRxkKKB3OSFlAn/wvhPqrSMXfYYpW/JdTCIxVbD8rjIBKjmN 8p0iv4FXvuwVHf7naYB3ix+woYAS8GW8ul+mt0mpUvJnOLgy1DNZ44jshStxlWl9B6 H6gmd5CnDeAnhhS6qAq58WMGshDLjIF3gOClLKvC6qWGkhNvkEPNf5o5+jjaPGNmt2 9DDN9sm0pw8wQ== From: Detlev Casanova To: u-boot@lists.denx.de, Marek Vasut Cc: Marek Vasut , Hai Pham , Tam Nguyen Subject: Re: [PATCH v2 3/3] renesas: rcar3: Load the correct device tree Date: Wed, 14 Jun 2023 11:40:23 -0400 Message-ID: <2286001.ElGaqSPkdT@arisu> In-Reply-To: <300e3a86-345e-a82f-d40c-557517063255@mailbox.org> References: <20230612195107.171748-1-detlev.casanova@collabora.com> <5942794.lOV4Wx5bFT@arisu> <300e3a86-345e-a82f-d40c-557517063255@mailbox.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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.8 at phobos.denx.de X-Virus-Status: Clean On Wednesday, June 14, 2023 11:32:31 A.M. EDT Marek Vasut wrote: > On 6/14/23 17:10, Detlev Casanova wrote: > > On Wednesday, June 14, 2023 9:53:14 A.M. EDT Marek Vasut wrote: > >> On 6/12/23 21:51, Detlev Casanova wrote: > >>> The Renesas R-Car Gen3 boards use different device trees than > >>> the default one. > >>> > >>> This commit uses the sysinfo's board id and revision > >>> > >>> to determine which linux device tree to load: > >>> * H3 (Starter Kit Premier v2.0): renesas/r8a77951-ulcb.dtb > >>> * H3e (Starter Kit Premier v2.1): renesas/r8a779m1-ulcb.dtb > >> > >> This is not about loading DTs (as the subject would suggest), this is > >> about setting the correct default DT name in environment. > >> > >>> Signed-off-by: Detlev Casanova > >>> --- > >>> > >>> board/renesas/ulcb/ulcb.c | 59 > >>> ++++++++++++++++++++++++++++++++++++ > >>> configs/rcar3_ulcb_defconfig | 1 + > >>> 2 files changed, 60 insertions(+) > >>> > >>> diff --git a/board/renesas/ulcb/ulcb.c b/board/renesas/ulcb/ulcb.c > >>> index 1477750f921..cc78e0952b6 100644 > >>> --- a/board/renesas/ulcb/ulcb.c > >>> +++ b/board/renesas/ulcb/ulcb.c > >>> @@ -27,6 +27,7 @@ > >>> > >>> #include > >>> #include > >>> #include > >>> > >>> +#include > >>> > >>> DECLARE_GLOBAL_DATA_PTR; > >>> > >>> @@ -65,6 +66,64 @@ int board_init(void) > >>> > >>> return 0; > >>> > >>> } > >>> > >>> +int misc_init_r(void) > >>> +{ > >>> + struct udevice *dev; > >>> + int board_id; > >>> + int rev_major, rev_minor; > >>> + int ret = sysinfo_get(&dev); > >>> + > >>> + if (ret) { > >>> + debug("Cannot get sysinfo: %d\n", ret); > >>> + return 0; > >> > >> Why do we ignore errors here ? > >> > >>> + } > >>> + > >>> + ret = sysinfo_detect(dev); > >>> + if (ret) { > >>> + debug("Cannot detect sysinfo: %d\n", ret); > >>> + return 0; > >>> + } > >> > >> Looking at all this, I really have to wonder, wouldn't it be nicer to > >> introduce a 'sysinfo' command which provides interface to obtain the > >> different properties (like board name, id, revision ...) from U-Boot > >> command line, and then script the DT selection in U-Boot shell ? > > > > Yes, that could be a good option. This is more based on how raspberry pis > > are selecting the correct devicetree in `board/raspberrypi/rpi/rpi.c`. It > > is either about having simple shell scripts that are similar between > > devices and the implementation is "hidden" in C for each platform (maybe > > easier to use but less flexible). Or more complex shell scripts with > > simpler C implementation (more flexible but having to modify a boot > > script can become complicated for users) > > > > Has this direction choice been discussed in the past already ? > > The less hard-coded board code (which cannot be updated by the user > easily), the better. Scripts can be updated in deployment far easier > than the bootloader itself. Hence the push for scripts over custom C code. That makes sense. I'll create a new command for this then and use it to select the dtb in the ulcb boards script.