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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 54067C433EF for ; Fri, 5 Nov 2021 20:02:42 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id C58F860EC0 for ; Fri, 5 Nov 2021 20:02:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org C58F860EC0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id E316083726; Fri, 5 Nov 2021 21:02:39 +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="aOQlQBJf"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id AD49E83726; Fri, 5 Nov 2021 21:02:37 +0100 (CET) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 EB0B883724 for ; Fri, 5 Nov 2021 21:02:32 +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-x72d.google.com with SMTP id bi29so9783733qkb.5 for ; Fri, 05 Nov 2021 13:02:32 -0700 (PDT) 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=9Ou+QY9nVDBi8gPrY5g9xVQewXJoxlMu/yGAoGvAAVc=; b=aOQlQBJftNwzoKmYC5UvD7a9RSpiF1eF0tLfHlGGnFsjcwMU7bQey4Zc3I10n7ieL4 Nft9YUG0l1TT2DkkMiFikTu6r3SAcTgGcagT79Uv7oHQK/YCot7axZSIuGwc6OMvrRQk l2QNJFB2hmpTHrS408N8Dtkb/waVgoprAh/0g= 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=9Ou+QY9nVDBi8gPrY5g9xVQewXJoxlMu/yGAoGvAAVc=; b=IEvmaijldlmLt2TlXBUylHyPn9u4mRmIYgP35eIfQ1FWB4XzP5ZzMJTh6KBlE4xqZT cHT7Un4Si87k0CNpwctg/n2UGdwl1uqWSZFMKG/D6whxSM3RRUI+asqkifyWyjYs7nb3 2B9H2TrdMaO+cxwkD3sGgng3ftAxKFTn3IoiGZmXvtFP9D94tkVhL2hYJs/Smyootp97 h2RC8dYsTEFjZBCI+JEgFuWNIue7I88T1eOXBWX3Q+BWvrMPnZTQDQ4ggxSd+SXuXQkH QAFBgW0qtF7BrcDt4ydrf7E21a6Z3uaQ6YBtOW0ADwIwvzX5Vf8qlD15aCgIiHiFK5sD Tt5A== X-Gm-Message-State: AOAM533iMrXFDxES79CwYAF6zJEm3r2NYYNl97o0M9mbZ5Pt+eD6ZiC0 0JXVpmGftN5mWhpYqOjK928rnwEMsutqWA== X-Google-Smtp-Source: ABdhPJx0e31glLwmJgSWO6gaW2TnTZxUOz12yVbNI7NUvrbDw8agluLlfYLCEZspxUi/zXwHG3gDaQ== X-Received: by 2002:a05:620a:c4a:: with SMTP id u10mr47676733qki.69.1636142551692; Fri, 05 Nov 2021 13:02:31 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-dcf7-3600-6b4c-294c.res6.spectrum.com. [2603:6081:7b01:cbda:dcf7:3600:6b4c:294c]) by smtp.gmail.com with ESMTPSA id u26sm1530175qtc.70.2021.11.05.13.02.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Nov 2021 13:02:30 -0700 (PDT) Date: Fri, 5 Nov 2021 16:02:29 -0400 From: Tom Rini To: Pali =?iso-8859-1?Q?Roh=E1r?= Cc: Stefan Roese , Marek =?iso-8859-1?Q?Beh=FAn?= , u-boot@lists.denx.de Subject: Re: Booting zImage with appended DTB without ATAGs support Message-ID: <20211105200229.GI24579@bill-the-cat> References: <20211011142548.35wvxhrvhiafghar@pali> <20211011143222.GE7964@bill-the-cat> <20211011143344.vyngtyi2h4dp6dvi@pali> <20211011144544.GF7964@bill-the-cat> <20211011154905.wuqf3rzpwkouucwx@pali> <20211105113821.4cb2kbaqysouy7pl@pali> <20211105143510.GT24579@bill-the-cat> <20211105151646.fgu42idv2esf6rcv@pali> <20211105152001.GV24579@bill-the-cat> <20211105154731.qsckprgirfhn5rc5@pali> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="YAj7lmX6LWC3Cn8z" Content-Disposition: inline In-Reply-To: <20211105154731.qsckprgirfhn5rc5@pali> X-Clacks-Overhead: GNU Terry Pratchett X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 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 --YAj7lmX6LWC3Cn8z Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 05, 2021 at 04:47:31PM +0100, Pali Roh=E1r wrote: > On Friday 05 November 2021 11:20:01 Tom Rini wrote: > > On Fri, Nov 05, 2021 at 04:16:46PM +0100, Pali Roh=E1r wrote: > > > So now I have a question: Do we want to support booting zImage with > > > appended DTB in U-Boot when ATAGs support is now disabled by default? > >=20 > > Based on your experience, yes, there are use cases for appended dtb > > booting still. So it should be at least documented what you need to do > > where in order for that to work, and perhaps some platforms will want to > > enable it by default. >=20 > What could be implemented in U-Boot is extracting DTB from zImage+DTB > binary and boot it like if user supply separate zImage and separate DTB > files. With this approach there is no need to have ATAGs support > enabled. It would mean that kernel's code for using attached DTB would > not be used anymore as DTB would be passed to kernel separately, like > any modern boot setup. >=20 > Main issue with this approach is that if you load zImage+DTB binary from > disk or UART into memory then you loose information about total binary > size. And if you examine memory after the zImage, you cannot be sure if > data were loaded by previous command (disk read, UART transfer) or if is > just some garbage in RAM. So you can have false-positive detection that > DTB was appended. >=20 > This issue does not happen in case of booting zImage+DTB encapsulated in > uImage format, as in uImage is stored total size of that concatenated > binary. So booting via bootm should be fine. IIRC zImage+DTB-in-uImage > via bootm is used for booting new kernels on Nokia N900. >=20 > Currently affected by this issue is bootz command, which takes only > start address of the zImage binary and total size is not specified. > Command bootz takes third argument which specifies location of DTB in > memory and understand special value "-" which says to atags booting. > I'm thinking here... what about adding a new special value e.g. "+" > which would mean that DTB is attached to zImage? This could issue that > automatic detection of attached DTB into zImage is not reliable. >=20 > Any opinion? >=20 > Another approach instead of extracting DTB from zImage+DTB binary could > be to teach U-Boot to provide some simple minimalistic ATAGs and then > boot those zImage+DTB binaries like before with minimalistic ATAGs... So, there's certainly still valid reasons and times to boot an appended DTB. It's just not a generally common case I think. But it does show that ATAGs were getting a bit more use still than I had expected. I think we should update the help / prompt on SUPPORT_PASSING_ATAGS to make it clear this is needed for appended dtb booting and if I followed you right, CMDLINE should at least also be enabled for that case, and maybe also update something under doc/. I don't think we should put too much effort in to making us find and pass the appended dtb for what is an otherwise niche case. --=20 Tom --YAj7lmX6LWC3Cn8z Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmGFjcsACgkQFHw5/5Y0 tyxekwv8D3Ot4Z1KdHuynmSeFkxOjRoccNZyz2tGhXr+UXWsRTQbR/eD3mGuXDgz Vju7qninaSsyUDp7N+5+42SlxDMZx8tX/uvbhTB4IW/YAt4pULmfQbiIcXycFzrC /Dpwo+xDAS9HA6pz54YA2c/qOifuMGqPLdhfRdYi8zotqopXSGWoRRndhb91wZOJ YQWFMqlsOZu3jJj96XJlJOd7Wi8+zSOr+Kq7ffcKUURfgdi9BsfRw33IoJK2kagP Kj96PuliR1de5K4xWzaKRyMaEz5SdcMyR3k9nX7ihNRym0J+DeP4cQ3UeAJS9iOz m580yaB4phx7fZRIiEvm6IYDJBA+Qj1RK3PkFHPiCO/Zl9/MYwQwEAc7gv5VlpSM iEsF85c+LDKSidNpxMuV09yacTafr10RAueXAp2q9FlE49rjv3S+jsrQQ63kS8sJ W4rUQaGs1NZFrSH598zl+mEvzqWkcwJN/Z4QMEkL7wb6Wac3208zlo2tqm9gU4jN FQrJWn8F =G+wF -----END PGP SIGNATURE----- --YAj7lmX6LWC3Cn8z--