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 3352DC433F5 for ; Wed, 20 Apr 2022 13:46:00 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 9C54483DFE; Wed, 20 Apr 2022 15:45:57 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (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="k7htsvvA"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 49FC883E04; Wed, 20 Apr 2022 15:45:55 +0200 (CEST) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 2AAB183DD3 for ; Wed, 20 Apr 2022 15:45:52 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qt1-x833.google.com with SMTP id x12so949829qtp.9 for ; Wed, 20 Apr 2022 06:45:52 -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=DuY0CuXMt04tb7QMth035Xe6XwEojEJ+qKdGDen3mNg=; b=k7htsvvAopr2EQ1U4CSSiMzL58F4a5cov4S8+ni/6EpH1zSf385Zo5gYy6B4/CLxHJ GHgzv+Xx5QMq0VfOYV3wmjRbim4zYdEfxxXf3MnKMyJJio1DsZNqATT+CA4IAZnCZrzZ cdClr7WfpZF1rTyXVM0l+u0XHbQh9smbm6ggk= 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=DuY0CuXMt04tb7QMth035Xe6XwEojEJ+qKdGDen3mNg=; b=niXNVlJEB54hE3oJYQ5eUGQnrrv61BbRilJnP+RGD7AW8X7cmeKLa2GpI9czwEeHub 9/dQen8JUUrUHd0SK7K9+dhgHyxex8giAVdCgrd08Z4C4v3QrQ+C74pu3WFpwpvhTjt+ qNznleKQeufJABfrh0b8Au6WPZ859+UTpvo1IXrd6fW9N8y6/letj3rT8ysC9yfhjAqK wChlgkF9EGquimp7epI7OBrPyLR2vi2Tazv96AFaflrVMB7VAPWqZwb6JXvVY62mMpPM YkLl62qxxS4Iy02Evz3ZBWqgyNEI3T+hpnH6PR20EiMNgJt+uZcd32w2ngNv6P6bqoeR u02Q== X-Gm-Message-State: AOAM533mowgucrb5KX4D2GIJpRxglNcPuMK3qhJ2+ILVcT9U5O7FwC3z 5FAwMg19vE3hvN43hwl90NZMBA== X-Google-Smtp-Source: ABdhPJxxZNQYUn6h8eLNPD57M+XGq4HfxRQkkyMvfDGIe48gskxuO7AcObFSdo4LNaaqhIedSJ7VCQ== X-Received: by 2002:ac8:5c14:0:b0:2f2:121:66d4 with SMTP id i20-20020ac85c14000000b002f2012166d4mr9046051qti.675.1650462350928; Wed, 20 Apr 2022 06:45:50 -0700 (PDT) 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 f19-20020a05620a409300b00680c933fb1csm1790514qko.20.2022.04.20.06.45.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Apr 2022 06:45:50 -0700 (PDT) Date: Wed, 20 Apr 2022 09:45:48 -0400 From: Tom Rini To: Heinrich Schuchardt Cc: Simon Glass , u-boot@lists.denx.de Subject: Re: [PATCH 1/1] drivers: add memory disk support Message-ID: <20220420134548.GM3045430@bill-the-cat> References: <20220419211641.316935-1-heinrich.schuchardt@canonical.com> <20220419212651.GS3045430@bill-the-cat> <14f67fd8-623a-2054-e995-73d54898b886@canonical.com> <20220419225941.GW3045430@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6ZcLte273om6Oiqd" 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.5 at phobos.denx.de X-Virus-Status: Clean --6ZcLte273om6Oiqd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 20, 2022 at 08:58:25AM +0200, Heinrich Schuchardt wrote: >=20 >=20 > On 4/20/22 00:59, Tom Rini wrote: > > On Tue, Apr 19, 2022 at 11:55:00PM +0200, Heinrich Schuchardt wrote: > > > On 4/19/22 23:26, Tom Rini wrote: > > > > On Tue, Apr 19, 2022 at 11:16:41PM +0200, Heinrich Schuchardt wrote: > > > >=20 > > > > > In some scenarios it is desirable to package U-Boot with other fi= les into > > > > > a single blob. This patch allows to embed a memory disk into the = U-Boot > > > > > binary. This memory disk can be accessed like any other block > > > > > device as 'mem 0'. > > > > >=20 > > > > > Signed-off-by: Heinrich Schuchardt > > > >=20 > > > > What's the use case for this, which isn't covered by some combinati= on of > > > > U-Boot being in a FIT image and the "load a firmware blob" that we = have > > > > today? Thanks! > > >=20 > > > "U-Boot being in a FIT image" requires a loader that understands FIT. > >=20 > > Fortunately, that's U-Boot. >=20 > U-Boot can load FIT images. But other firmware cannot load a U-Boot which= is > inside a FIT image. That's not how this works? Please look at the platforms today which make use of U-Boot and a FIT image for U-Boot. > > > "load a firmware blob" requires a block device or a network file syst= em. > >=20 > > No, we have various cases where we bundle inside of the image various > > black boxes, in various ways. > >=20 > > > If you put U-Boot's payload into the U-Boot blob, you need neither a > > > separate block device nor a network file system. > >=20 > > What is the use case for this? > >=20 > > > Packaging into U-Boot makes most sense where follow-up binaries are t= ightly > > > integrated: > > [re-ordering this list, sorry] > > > * delivering device-trees > >=20 > > Yes, we can do that today, select the right one at run time, and even > > pass that along to EFI via the appropriate config table entry. >=20 > If you want add an arbitrary device-tree that you want to pass to Linux y= ou > ave to patch a lot of code. U-Boot passes the running device tree via EFI to the next stage out of the box right now. We can be given a device tree to use by a prior stage, or we can use one of N that we were bundled with, right now. > > > * adding iPXE > >=20 > > Rather than fetching this from the network, to continue to fetch and > > load applications from the network? >=20 > U-Boot only offers insecure and unreliable protocols like tftp and NFS. Then we should verify the payload we download before using it. We support that already. > > > * adding a custom graphical boot manager as EFI application > >=20 > > Why can't this be loaded from the disk? >=20 > Disks drives are often loaded by other entities then firmware. The whole > point of the patch is providing files without relying on a disk. I'm not sure I get why, however. We get tons of feedback along the lines of "U-Boot is TOO BIG" and "I don't want to have to package U-Boot for my distro, I want it to be on there and just work". This feels like taking both things in the other direction, without a clear use case for who is going to use it, for what, and why what we have today is insufficient. --=20 Tom --6ZcLte273om6Oiqd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmJgDosACgkQFHw5/5Y0 tyy1cwv/WBtvHdUMoDypPkhKb+ouGfb9PzYza8H/aBIdqrUd5kwkVZ5eKtPqLOs5 Q99xsluWcLUnz+UwxyCWzlC0nEYUorTFok3jUv+BVDroqkbcnYopGmUB6l6BmGHm hICgB86MfciEcLj9+9p1dnKd/v5e9ZceDHoZgAfIBbkHGDHEEIEVs4DinCdQRdaL 4TEV0Z8acbmnawsJReCyD0sCsdZO9NGuP+vprdxXgkS2BS6L92nwkrqM+5eCaCEg gzMdBOCQATnOTmtNHsNIG8BRJgHkqO9TIx+aPerOsk8rewaMBsMpffiV5a+zO6ZT OcHZByvFPAhLmBAN5fAbCD0CVA6Q9TT6SX6e+XoQAyHJxbill73f6qtPQGjGFkmL MUJD+jXTOeyOtfEMd0S8VXBy4dMNlMPxyB82E9It26FpopjBGzccvOwByfs24FsC HE7bnyElSDOB2lvIKRiQ3tRdU0xdnH10H8Wqledz8WnSviAQM7+SAxpvk4CClYE4 7I6lC2DZ =0dnY -----END PGP SIGNATURE----- --6ZcLte273om6Oiqd--