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 X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4D3A3C11F66 for ; Tue, 29 Jun 2021 14:01:59 +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 8F7EA61DB4 for ; Tue, 29 Jun 2021 14:01:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8F7EA61DB4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmx.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 92CA1831AA; Tue, 29 Jun 2021 16:01:56 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=gmx.de 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=gmx.net header.i=@gmx.net header.b="S7XS2pm/"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 1A97982E17; Tue, 29 Jun 2021 16:01:55 +0200 (CEST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 CB9A082E17 for ; Tue, 29 Jun 2021 16:01:47 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=xypron.glpk@gmx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1624975300; bh=d6nhAQ52iE5xsyDaXsozavNgp6jzaTdeG1vWHlQ0D8Q=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=S7XS2pm/agSx0tOlOUBVJG+EMSw7tg/elQTRx6IbpfVHmPxwDV81NSjIbZn66P4bO UvxjxBQ6Pdy8WClPnQ2ceUxya0WD2xcuq16GfdThEYYDW1fY461ysLUEHqEtbwKUjN QUWdSVBlL7kh6B8aqr9PrJyawPLtaM4vYjKqAuYs= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.123.35] ([88.152.144.157]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MlNtF-1lWYw51V9B-00lnIh; Tue, 29 Jun 2021 16:01:40 +0200 Subject: Re: [PATCH 0/7] efi: Various tidy-ups and drop the default To: AKASHI Takahiro , Simon Glass , Tom Rini , Mark Kettenis , U-Boot Mailing List , Pali Roh??r , Ilias Apalodimas , Alex Graf , Masahiro Yamada References: <20210628014841.501036-1-sjg@chromium.org> <5613706c36261e2a@bloch.sibelius.xs4all.nl> <20210628133711.GY9516@bill-the-cat> <5a197768-3d0a-3b3b-5897-ed28d4e0f566@gmx.de> <20210628172744.GQ9516@bill-the-cat> <20210629125613.GA48515@laputa> From: Heinrich Schuchardt Message-ID: <5a2667b1-7a65-cd73-652a-a3be2d508ffe@gmx.de> Date: Tue, 29 Jun 2021 16:01:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210629125613.GA48515@laputa> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:qGrOTE1PVesMHVJynqoACLAX7NGV838Uebu5UgOvXNcgXobhG/E MQf6bIJzTC4MYBdfYJMcjABIYvnI1EO8Smf6pvQGccIxtmV2IfAOfAxSRTwo7ywOuoheZGF 3VGYhK0feTYnHAtqvHh+0xpcpMntiAbaKRQmAyuIWkRipP1DMrlRU/HU0mMWRG0u0ZjHqBv wcaQkDJf5YRNd2Keh7Zcg== X-UI-Out-Filterresults: notjunk:1;V03:K0:RF1FoDxHl5s=:vSVrcYQQT6NBFdBZl1GTWe W+DuteOj1li7oWsAJ17gbirg/LYza0uYg57jrMTE4vqyugpCqndvO26RZ/qTcX98Ksc0rH/e6 Y/sMpH7J1e8CgcUusV4zOUbN1GnCTpN8/QbWo3zE47Fi6zmKg+8ZOua1PjK2d5XXJWEdCQFo6 JalAQhDoA4Uk5GOQUyqLUrDLBjGWiQCVHDKZ8pNk+0sKP3t6a8yO4IVZ8YooDyaRxJ0DP4d2P hpn+V27u5nBE35Kz1oBW8v/0I0K0qkwCrpXGdT0IdxduhcAy2nkvmDiGHlqstqhlc9wtdwTRI ci12cAS2YTPd6dklpME/ofb1YP9f/I0s4UHVJujjfVYnybeTHYDPmQ8/kp29Jw0QAysW0eygH 8rH5cXUwIF9IlEQircGe6e/Bk42aEHK82a6GyjCg2f2gxaPIeie9icu+n23QM4rNg8Oi+QA9b DJ0aylvI0K/jWm8jL+UEvrevbcajE+zl9Nw6iMkV4KfQ9ZtCkc/NWuc3K4B07cRMI0Pa9jSSI ZF9sFeLHzpQLxEVexCgUxxdwggxEjumJz9HBI4AwqTyOElIxX4nHS3Md9/s5qri+xigNC8baf g9YpUDhfFw+DMS95njLhhk9cZ7q8Y4zIZEg1RdF+zBvUmE+M+ya2AXKXr2SK6Yga1L2+vRFaq HA6n/YjRagpiNwzXgNNZtiAB8oSusl86A97GjcLMwtbjVkVL8mOhPWNhIDdXJIgGLffwaD4Tr SeRTjDBwmOz5i09IxfKSToXJG7DtckSHMoyCShOybt1r0eTx/nL6xBS3Munht2TfS7HwZ1345 hq4kyUXWGlBTdYEKfJyAb+grOrQOLQpnuGOum9qpu1IOOYrROVjV2tCvC54uFafoJlfRjUEZa Bxixv1ugyFAkMEyTCK6vGeZiFavXVl5/AAWZQbVvURgwZkW2ArWZhsKs8LPlCkrj39Rb4vWlc 8ddZAVbB+Lw4D6fam1fMvZ85PRjwYN/P0dJRiIpKxqbacQn5gdaAVZhQ+Hpy9SBv6eiZP18Z8 VXYwftJPS3cdnokWdBnS7WGOPXurzMTdD9JZAEQBzhlVnm7JqNXNS7yA+IsS972VcxqhmFgN+ /OPh6q4J2PFuPHyl2bjsSyVNYTpcrZLghfo 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 On 6/29/21 2:56 PM, AKASHI Takahiro wrote: > On Mon, Jun 28, 2021 at 12:08:27PM -0600, Simon Glass wrote: >> Hi Tom, >> >> On Mon, 28 Jun 2021 at 11:27, Tom Rini wrote: >>> >>> On Mon, Jun 28, 2021 at 10:26:35AM -0600, Simon Glass wrote: >>>> Hi Heinrich, >>>> >>>> On Mon, 28 Jun 2021 at 09:20, Heinrich Schuchardt wrote: >>>>> >>>>> On 6/28/21 4:18 PM, Simon Glass wrote: >>>>>> Hi Tom, Mark, >>>>>> >>>>>> On Mon, 28 Jun 2021 at 07:37, Tom Rini wrote: >>>>>>> >>>>>>> On Mon, Jun 28, 2021 at 10:38:50AM +0200, Mark Kettenis wrote: >>>>>>>>> From: Simon Glass >>>>>>>>> Date: Sun, 27 Jun 2021 19:48:34 -0600 >>>>>>>>> >>>>>>>>> It has come to light that EFI_LOADER adds an extraordinary amoun= t of >>>>>>>>> code to U-Boot. For example, with nokia_rx51 the size delta is a= bout >>>>>>>>> 90KB. About 170 boards explicitly disable the option, but is is = clear >>>>>>>>> that many more could, thus saving image size and boot time. >>>>>>>> >>>>>>>> EFI_LOADER used to be a lot smaller. It is great to see that ove= r the >>>>>>>> years UEFI support has become more complete, but a lot of that ne= w >>>>>>>> code implements features that are not at all essential for just >>>>>>>> booting an OS from storage. If that growth leads to the suggesti= on to >>>>>>>> disable EFI_LOADER completely by default, we're putting the cart >>>>>>>> before the horse. >>>>>>> >>>>>>> Well, I see I forgot to prefix my patch with RFC, but I hadn't fou= nd >>>>>>> EFI_LOADER being used in the wild on armv7, but wasn't sure about = the >>>>>>> BSD families. I did see that Debian doesn't use it, and that Armb= ian >>>>>>> doesn't even use it on aarch64. >>>>>>> >>>>>>>>> The current situation is affecting U-Boot's image as a svelt boo= tloader. >>>>>>>> >>>>>>>> Really? I know UEFI has a bad reputation in the Open Source worl= d, >>>>>>>> and some of its Microsoft-isms are really annoying (yay UCS-2). = But >>>>>>>> it works, it provides a standardized approach across several plat= forms >>>>>>>> (ARMv7, AMRv8, RISC-V) and the industry seems to like it. Person= ally >>>>>>>> I'd wish the industry had standardized on Open Firmware instead, = but >>>>>>>> that ship sailed a long time ago... >>>>>>>> >>>>>>>> I find it hard to imagine that 90k is a serious amount of storage= for >>>>>>>> something that is going to include a multi-MB Linux kernel. This >>>>>>>> isn't code that lives in SPL or TPL where severe size restriction= s >>>>>>>> apply. >>>>>>> >>>>>>> In one of those cases where I need to pop back in to the other (No= kia >>>>>>> N900 specific) thread and see if the big size reduction really was= just >>>>>>> disabling EFI_LOADER, it's perhaps just one of those "fun" things = about >>>>>>> Kconfig and anything other than "make oldconfig" for spotting new = config >>>>>>> options that default to enabled. >>>>>> >>>>>> Yes it will be interesting to see what you find there. My results o= n >>>>>> nokia_rx51 were something like this: >>>>>> >>>>>> default >>>>>> arm: (for 1/1 boards) all +129370.0 bss +1136.0 data +7399= .0 >>>>>> rodata +10989.0 text +109846.0 >>>>>> >>>>>> without ebbr >>>>>> arm: (for 1/1 boards) all +38460.0 bss +1040.0 data +2375.0 >>>>>> rodata +5333.0 text +29712.0 >>>>>> >>>>>> with various other things: >>>>>> CONFIG_OF_LIBFDT_ASSUME_MASK=3D7 >>>>>> # CONFIG_OF_TRANSLATE is not set >>>>>> # CONFIG_SIMPLE_BUS is not set >>>>>> # CONFIG_TI_SYSC is not set >>>>>> # CONFIG_CMD_FDT is not set >>>>>> >>>>>> arm: (for 1/1 boards) all +19170.0 bss -16.0 data +360.0 ro= data >>>>>> +3274.0 text +15552.0 >>>>>> >>>>>> (Mark, in the same email:) >>>>>>>> FIT simply isn't fit for purpose (pun intended). It only really = works >>>>>>>> for booting Linux, and forces people to combine u-boot, kernel, >>>>>>>> initial ramdisk and other firmware components into a single image= . >>>>>>>> That is really undesirable as: >>>>>>>> - This makes it sigificantly harder to update individual componen= ts of >>>>>>>> such an image. Making it hard to update a kernel is obviously= a >>>>>>>> serious security risk. >>>>>>>> - This makes it impossible to build an OS install image that work= s om >>>>>>>> multiple boards/SoCs. >>>>>> >>>>>> >>>>>> I would really like to understand this better. The whole thing is a >>>>>> complete mystery to me. >>>>>> >>>>>> Firstly I have sometimes fiddled with booting other OSes using FIT.= It >>>>>> seemed OK. I can't see why it only works with Linux. >>>>>> >>>>>> Secondly, I don't expect that U-Boot itself would be in the FIT. >>>>>> >>>>>> Thirdly, do you really want the kernel and initrd to be separate? A= t >>>>>> least in the systems I have used, they are built together, even hav= ing >>>>>> the same name, e.g.: >>>>>> >>>>>> initrd.img-5.10.40-1rodete1-amd64 >>>>>> System.map-5.10.40-1rodete1-amd64 >>>>>> vmlinuz-5.10.28-1rodete2-amd64 >>>>> >>>>> I have not hit any distro that builds FIT images. All install vmlinu= x >>>>> and initrd as separate files. >>>>> >>>>> Why would you want to change that? >>>> >>>> Well there is no point in having two files if one will do. Also it >>>> allows for a hash / signature check. >>> >>> The question of "how great would it be and how many problems would it >>> have solved if FIT images had become popular" is one for another time. >>> It will always have its use cases and users but never the broad adopti= on >>> many of us felt it should have. Bringing it up in this context won't >>> change that. >> >> I see Peter's reply below so will make time to dig into this and >> understand the problems with FIT better. I feel that EFI comes with >> all sorts of problems so I'm far from convinced, at this point. Sorry. > > It seems to me that we are discussing three different things: > - the code size increase by enabling UEFI interfaces > - how the UEFI interface be implemented on U-Boot > - The primary (or default/standard) boot mechanism in the future > > I don't think they are totally independent, but we'd better > distinguish them some how in the following discussions. > >>> >>> I'm saying this because I think there are some important technical >>> questions within U-Boot to resolve because the EFI loader part of U-Bo= ot >>> is critical to our long term future. And DM is an important part of o= ur >>> internal design and we're (probably later than I should have) pulling >>> out the parts that haven't been updated so that we can deliver on some >>> of the overall promise of DM better, too. >> >> Yes, migration has certainly been slow. As you know I mostly stopped >> pushing it a few years back when I saw all the reluctance. I'm very >> pleased you are taking that on and I think it will help a lot. > > I posted this patch[1] two years ago and I thought that we had had > some sort of consensus that UEFI interfaces be integrated more elegantly > with DM in the future. > > So I was a bit surprised with Heinrich's recent patch. > > In [1], I was trying to define all the UEFI handles, including some > protocols?, as DM objects. > I thought that it was the best way for unifying the two worlds even if > there are no corresponding *notions* in the existing DM objects. > > [1] https://lists.denx.de/pipermail/u-boot/2019-February/357923.html > > -Takahiro Akashi You wrote yourself: "bootefi doesn't work with this patch set yet". Your series completely disregarded UEFI and DM logic, e.g. you defined DM devices per protocol. You tried to integrate UEFI and DM world at an inappropriate level: Instead of changing DM block device uclass you touched individual drivers like USB and SCSI completely disregarding all other block device classes. Best regards Heinrich > > >> If what you say comes to pass, it is even more important that EFI is >> more integrated, rather than being a bolt on. Thanks largely to >> Heinrich, the tests are in quite good shape, so refactoring should be >> feasible. >> >> Regards, >> Simon