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 A988AC433EF for ; Wed, 9 Mar 2022 02:10:29 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 4BDA983937; Wed, 9 Mar 2022 03:10:26 +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="oXtX5dxg"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 3EE14808BA; Wed, 9 Mar 2022 03:10:24 +0100 (CET) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 ED5A583938 for ; Wed, 9 Mar 2022 03:10:13 +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-pf1-x436.google.com with SMTP id t5so992657pfg.4 for ; Tue, 08 Mar 2022 18:10:13 -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=LoSTT5VSMx/3tkM9BJu/qh5jtDBY31eWMkAkG1vLxA4=; b=oXtX5dxgkp9ULOvzX/NuhVrW0BTS3LzoxGt5PfPwUXhtrLm1O2jiqh5OdL3FrkCD/X 5nfHn12exFAtZxtirXCrxAZAogVhqZmMvolgUtXvh+cPVrUF/3/az58Qi0nmoKr7sWYT 2OQIkZXRuwkgYhzIoFqQzBStYWBMUKyunVckv8M5/V+5dTBkWqN2Z4NdCOACfWxIAjr0 l+u9NtNzijmHii/Csck5L7IogIHdz/qIjGrlO26sDwdCDxsh15uzPnNjsdTR+R0tTTRN nuVlh7oSSVQVKbzI11kpx5Vdqxr+s9w8/9PEMi29FiPvqYz27aPnrdpzKfnijNmeLLPM aP+A== 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=LoSTT5VSMx/3tkM9BJu/qh5jtDBY31eWMkAkG1vLxA4=; b=Esepnf8J1lH94kc46HX0wd2Z+YnKg45pr08lsOKf1/BSG6fgFcstJo+haWJdBxGFa0 aG5vQjZDLl9QcFIhNU8GiFfmFLj+kL4lEgi0R7b9wQ2IhTL0Q6X45T5HMsYdpH9KHkQu 9HaLDxjanTqGCMWvpSYaFsoNFeBKAQaAas6akJY9QCyCyCUlqf3d/Zkpk7lpIQNkJ12M Ixy7OiHt37de6/CB+9aXd+EYF+M6uMzpALiumtqa7x6TSb/T2vj3DbdGQdug1o/TdN2j tIDSsr86/SWoZbY0JxSSOVV6mN3CNoDnnu2bRc6gJouBw6AP8X2icemq6qjIdKFSHDCh qCQw== X-Gm-Message-State: AOAM530hTvE73pQpNbFKI6kFTabF4QgCc24eo3KW9+J7J4dUiY4ylm98 i61AtW5kM5Ac6eLRE5CyCdF2RQ== X-Google-Smtp-Source: ABdhPJwvdBDbsS1wKDedXTt23MHv8P9rg+19twhS8sahDjY6gRyqQSfmvyyq3xB7wOe9EtfK+94saQ== X-Received: by 2002:a63:224a:0:b0:368:e837:3262 with SMTP id t10-20020a63224a000000b00368e8373262mr16488856pgm.546.1646791811767; Tue, 08 Mar 2022 18:10:11 -0800 (PST) Received: from laputa ([2400:4050:c3e1:100:2d45:59c2:b66a:384a]) by smtp.gmail.com with ESMTPSA id y10-20020a63b50a000000b0038088a28ec0sm380523pge.22.2022.03.08.18.10.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Mar 2022 18:10:11 -0800 (PST) Date: Wed, 9 Mar 2022 11:10:06 +0900 From: AKASHI Takahiro To: Heinrich Schuchardt Cc: sjg@chromium.org, masami.hiramatsu@linaro.org, u-boot@lists.denx.de, lukma@denx.de, peng.fan@nxp.com, bmeng.cn@gmail.com, jh80.chung@samsung.com, sr@denx.de, ilias.apalodimas@linaro.org Subject: Re: [PATCH v3 00/19] efi_loader: more tightly integrate UEFI disks to driver model Message-ID: <20220309021006.GA136899@laputa> Mail-Followup-To: AKASHI Takahiro , Heinrich Schuchardt , sjg@chromium.org, masami.hiramatsu@linaro.org, u-boot@lists.denx.de, lukma@denx.de, peng.fan@nxp.com, bmeng.cn@gmail.com, jh80.chung@samsung.com, sr@denx.de, ilias.apalodimas@linaro.org References: <20220308113657.221101-1-takahiro.akashi@linaro.org> <82d88a69-159a-257d-2fcb-b6226bff6fe4@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82d88a69-159a-257d-2fcb-b6226bff6fe4@gmx.de> 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 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. -Takahiro Akashi > Best regards > > Heinrich