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 D81F6C433EF for ; Wed, 9 Mar 2022 11:52:51 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 0A30783829; Wed, 9 Mar 2022 12:52:48 +0100 (CET) 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="leacRBNB"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 80FC48392C; Wed, 9 Mar 2022 12:52:45 +0100 (CET) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 8E99D837DE for ; Wed, 9 Mar 2022 12:52:40 +0100 (CET) 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=1646826753; bh=xRLzfMB/vaEm9LSOvbUsxz5jo0cDRxyD6balqRdVacE=; h=X-UI-Sender-Class:Date:Subject:To:References:From:In-Reply-To; b=leacRBNB1ja13YCoVwnMA1voJtyDWxRHyZPxMceISy3iEPMewEs0KbnuwhdWrCr7W SxB9Q6K9R4fsFniR9T8UEbnjLjqDndHVpB9Ygrusm1Gh4p3fhmmpOvxDHTDPdH1bK/ Kdc1Ul25WcR1NN5tObwVXV+YaN4jiZh3eD62d+n0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.123.94] ([88.152.144.107]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N2mFY-1o8mh21vTA-0139dR; Wed, 09 Mar 2022 12:52:32 +0100 Message-ID: <54cc7cc5-4dcd-ea30-6221-489efde116fb@gmx.de> Date: Wed, 9 Mar 2022 12:52:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.2 Subject: Re: [PATCH v3 00/19] efi_loader: more tightly integrate UEFI disks to driver model Content-Language: en-US To: AKASHI Takahiro , Simon Glass , Masami Hiramatsu , U-Boot Mailing List , Lukasz Majewski , Peng Fan , Bin Meng , Jaehoon Chung , Stefan Roese , Ilias Apalodimas References: <20220308113657.221101-1-takahiro.akashi@linaro.org> <82d88a69-159a-257d-2fcb-b6226bff6fe4@gmx.de> <20220309021006.GA136899@laputa> <20220309024839.GC136899@laputa> <20220309050734.GD136899@laputa> From: Heinrich Schuchardt In-Reply-To: <20220309050734.GD136899@laputa> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:SXXF4jx374M/CDAHkAsp/A/VIHqHFQ1C3x/dV8RNlhNzN+BvOVa lE1e5fFbZCTld/SAPZ/VFNG+V3QU5lLW1hGe4z5gccssVpehUA1W0kzIyIB2jdsAlYz7A+7 TDEDwwagKzQIFs39fGaQnpNCPnXUtH3efGUDg60x4j8qK0t4ccrRFk7Gal/PzPOjNuxZsdX iB9Uwf7xTeo/CUvv2zPDA== X-UI-Out-Filterresults: notjunk:1;V03:K0:60diSkm4mgU=:wD3n1GxSQt4lFF1ZcMtvHq MH/vbiMkMb4TTDPP3BpdjC0ZvSJuNKArgsfK9zlRZawlFiy+FEgiY88tivAKJMLyAcJIggCkJ /hXY+OXptsRH3/1K/XLzg4S14f9mAJ3mc8GTb00ceD6MRNFpNEjSik4iO7gjT5Sl9o7IUb7pU 8+d0yq+yJ2pc7q6+VElBJLUdqLAQj/TOQwxmot9wwgO8jVER7+PH/EFrjr0UXlMBIOrwjiCWL fcxk0Nlg6LbuhIFMpV59hzulrmLw6P2o29D86numctfxe/0XMUgxGlNMNwMRwC3QgKRaVfR7o WlpLPAINoAk3GDtoJKBc3gAfFuyymZcWj30SrGKP2EAS3x4msgJf9PbdX/e22PnwbGbXTXDXO Qj5kPeGzwO9nxjXiHWTQY+ctn+PVj64SrT7TjwnRXvyUwjsGtIr/wuCsr/4q+DDOq55dE81/G 0z3LLmSAD0THPHFChSlh6DuUkXVGoHzlKp4GwEuob/euDdWDwIAF3rOL0/zLkkq5iWinAetVn 8dddUGCZYC1EpwqgQMi64TX2wyJ6Nm/niTubWKO1pgtcdNKDqX6j20PHy9POqaup6EEui2elT Cs6kURqfigcIwYZrPPtHO2gbCwf7O/C4wMjRusTC+991/V6UjPMiSO3F2K6Eaa8gOXUA36/VU jWpwUpLu95py1PGY9WDFKd0g/okKhW2AfqjqRNfUPUTbXxo/dB9RC9Qo+AZHhzxi32kkrXD3Z KtmWPguXxHFeR9zmazE9jsFh4Bs5Jtx/AXtpQi4DC0td9o4c0Whu53UOyP+SEXu78CJp/6UnC 6X6WxltAlux+yfqZKbIRQEA9zxAOySukljxFY3N1cSefV8k0rM= 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 On 3/9/22 06:07, AKASHI Takahiro wrote: > On Tue, Mar 08, 2022 at 08:10:01PM -0700, Simon Glass wrote: >> Hi Takahiro, >> >> On Tue, 8 Mar 2022 at 19:48, AKASHI Takahiro wrote: >>> >>> Hi Simon, >>> >>> On Tue, Mar 08, 2022 at 07:34:15PM -0700, Simon Glass wrote: >>>> Hi Takahiro, >>>> >>>> On Tue, 8 Mar 2022 at 19:10, AKASHI Takahiro wrote: >>>>> >>>>> Heinrich, Simon, >>>>> >>>>> On Tue, Mar 08, 2022 at 05:49:13PM +0100, Heinrich Schuchardt wrote: >>>>>> On 3/8/22 12:36, AKASHI Takahiro wrote: >>>>>>> With this patch set[1] applied, UEFI subsystem maintains a list of= its >>>>>>> disk objects dynamically at runtime based on block device's probin= g. >>>>>>> (See "issues" below.) >>>>>>> >>>>>>> [1]https://github.com/t-akashi/u-boot/tree/efi/dm_disk >>>>>> >>>>>> This series together with Simon's series breaks multiple boards due= to >>>>>> size constraints: >>>>>> >>>>>> https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/111= 97 >>>>>> >>>>>> Please, investigate how to work around this issue. >>>>> >>>>> I have already mentioned this size issue in my cover-letter >>>>> in order to let reviewers aware of it and discuss a possible solutio= n: >>>>> >>>>> =3D=3D=3D8<=3D=3D=3D >>>>> Issues: >>>>> =3D=3D=3D=3D=3D=3D=3D >>>>> * The image size of U-Boot may increase. CI build test complains, >>>>> for instance, >>>>> rcar3_salvator-x: >>>>> "u-boot.img exceeds file size limit: ... excess: 0x79c bytes" >>>>> phycore-rk3288: >>>>> "SPL image is too large (size 0x8800 than 0x8000)" >>>>> >>>>> See [2]. >>>>> >>>>> [2] https://dev.azure.com/u-boot/u-boot/_build/results?buildId=3D377= 0&view=3Dresults >>>>> =3D=3D=3D>8=3D=3D=3D >>>>> >>>>> I have dug into rcar3_salvator-x case; I removed *all* the commits >>>>> in this series and yet enabled CONFIG_EVENT, CONFIG_EVENT_DYNAMIC >>>>> and CONFIG_DM_EVENT, which are all required for enabling my patch, >>>>> with Simon's patch applied on top of v2022.04-rc3. >>>>> >>>>> Then I still see this size problem: >>>>> =3D=3D=3D8<=3D=3D=3D >>>>> ... >>>>> MKIMAGE u-boot.img >>>>> u-boot.img exceeds file size limit: >>>>> limit: 0x100000 bytes >>>>> actual: 0x100036 bytes >>>>> excess: 0x36 bytes >>>>> =3D=3D=3D>8=3D=3D=3D >>>>> >>>>> So I have no way to deal with it. >>>>> >>>>> FYI, the combination of EVENT, EVENT_DYNAMIC and DM_EVENT will >>>>> increase the binary size by up to 0x1b2 for rcar3_salvator-x and >>>>> it seems the binary has almost already reached its maximum size >>>>> even now. >>>> >>>> So you do need EVENT_DYNAMIC? >>> >>> Unfortunately, yes. >>> When I rebased my patch set to your v2, I tried to use *static* >>> bindings, but some of ut tests, including dm_test_blk_base and >>> dm_test_blk_usb, failed. >> >> OK. Well maybe there is a filesystem in there that is not needed? 1MB >> is a huge size! Can we disable EFI_LOADER on that board? > > Well, EFI_LOADER is by default 'y' for arm64. > Basically, I doubt that this default is reasonable. All major distros support booting via UEFI. Fedora and Suse have specifically opted to make this the preferred way to boot on ARM. Same is true for BSD. So why do you have doubts? Best regards Heinrich > >>> >>> This can happen because, with static bindings, efi's callback function >>> (efi_disk_probe) is unconditionally called even when UEFI subsystem ha= s >>> not been initialized yet. >> >> Yes, I have seen things like that too. >> >>> >>> -Takahiro Akashi >>> >>>> Does it make sense to make enabling the partition support an option, >>>> instead of mandatory? >> >> What about this one? ^^ > > First of all, according to my rough attempt, > the patches for adding efi_disk callback functions may increase > the binary size by 0x31c, while the patches for adding UCLASS_PARTITION > adds another 0x3ba. > This means that "enabling the partition support an option" can help a bi= t > but doesn't help well enough overall. > > FYI, adding dev_read/write(udev) interfaces costs another 0x1df. > > -Takahiro Akashi > >> Regards, >> Simon