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 D436BC433F5 for ; Wed, 9 Mar 2022 05:07:55 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id CCF7D8398A; Wed, 9 Mar 2022 06:07:52 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org 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=linaro.org header.i=@linaro.org header.b="gnT/MVqm"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id DF03D83984; Wed, 9 Mar 2022 06:07:50 +0100 (CET) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (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 ECAB383995 for ; Wed, 9 Mar 2022 06:07:41 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=takahiro.akashi@linaro.org Received: by mail-pj1-x1030.google.com with SMTP id kx6-20020a17090b228600b001bf859159bfso4198562pjb.1 for ; Tue, 08 Mar 2022 21:07:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=lp9el0+7cjBBnc4DHLvsBo3uBs+7DJFMGbhNBynla0M=; b=gnT/MVqm6A2eEXY2sCRp7tWaSAiLt/jyWiV5OaFAVN8GYQW2jUkz5oIn5QKK7k0x/D S2IIpGRSSTOJIS0Y4DjQfRUllTzXU5FVYMWWFBm4jFxM1k/n1f8R+uAz4efiqBXghuoD WocJYGrDeedemXHZp+hPdGcXatAIC9TgNmP/ZtaDCRcwpO5HY/onSqpLkZP5DR984rjE HhVX19FcUXkJS/2VHsNC4G0KqaYwJTpPuF6C1LBQhFCzZcH7o0Dhk5QL71wyqzWx97/k sWxRLs/1v9oTL6GltLiHaZe3/GhecWpmd/zmhE0JI2xPW7NVBySUZvvC9Zd8rn89z4xJ bTiw== 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 :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=lp9el0+7cjBBnc4DHLvsBo3uBs+7DJFMGbhNBynla0M=; b=SD1v+TFFvpW1Rask7/33R3Ev5ILxJEe+9dF4Cg+AclbjnaSfb/mStiz/x22Edh3T4J bgAPe+DgZuVVBQlNJNQSM6k2yqz8pNiwFegAKZg09pDp1vwpf3FiVAleGl07eLlOsaWN s8XbbFfz2402CTBB/xNPhNwc4pLMlREq/m8tRpZZXm9l++zwjwTG8mjpL3PzaPrl/Ecr AWXA8oWIJbVVhA0syaNTfAO4yEX31eeSP6c+eSl2rU2t94d3OCS5wvqfrYGqi9hyEeQ2 ZZMIacdJwmPBDBTMiewwTR9W+8vClc5CnVasEAI0pmBwL+B/p/oXAo9DhjFfKHA1FRjm HO/A== X-Gm-Message-State: AOAM532KF13hDvDzEHMLaWcPCtwj1QkBJ+Xam7Ed48SQG1t32JKuaBCI JE88cu0P/ZPg+DsbGwHEXF1GjQ== X-Google-Smtp-Source: ABdhPJzbg1MOzmHLdoy6L03d1z6B1CzUwd4ri0GDjwKaJ3CuIeXqPgXc42+UrP1Us9k3MmoUZjBQIw== X-Received: by 2002:a17:902:f70c:b0:14e:f1a4:d894 with SMTP id h12-20020a170902f70c00b0014ef1a4d894mr21107542plo.65.1646802459898; Tue, 08 Mar 2022 21:07:39 -0800 (PST) Received: from laputa ([2400:4050:c3e1:100:2d45:59c2:b66a:384a]) by smtp.gmail.com with ESMTPSA id j22-20020a17090a7e9600b001bc67215a52sm781831pjl.56.2022.03.08.21.07.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Mar 2022 21:07:39 -0800 (PST) Date: Wed, 9 Mar 2022 14:07:34 +0900 From: AKASHI Takahiro To: Simon Glass Cc: Heinrich Schuchardt , Masami Hiramatsu , U-Boot Mailing List , Lukasz Majewski , Peng Fan , Bin Meng , Jaehoon Chung , Stefan Roese , Ilias Apalodimas Subject: Re: [PATCH v3 00/19] efi_loader: more tightly integrate UEFI disks to driver model Message-ID: <20220309050734.GD136899@laputa> Mail-Followup-To: AKASHI Takahiro , Simon Glass , Heinrich Schuchardt , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 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 probing. > > > > > > (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/11197 > > > > > > > > > > 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 solution: > > > > > > > > ===8<=== > > > > Issues: > > > > ======= > > > > * 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=3770&view=results > > > > ===>8=== > > > > > > > > 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: > > > > ===8<=== > > > > ... > > > > MKIMAGE u-boot.img > > > > u-boot.img exceeds file size limit: > > > > limit: 0x100000 bytes > > > > actual: 0x100036 bytes > > > > excess: 0x36 bytes > > > > ===>8=== > > > > > > > > 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. > > > > This can happen because, with static bindings, efi's callback function > > (efi_disk_probe) is unconditionally called even when UEFI subsystem has > > 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 bit but doesn't help well enough overall. FYI, adding dev_read/write(udev) interfaces costs another 0x1df. -Takahiro Akashi > Regards, > Simon