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=-7.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 E4E7EC4338F for ; Tue, 27 Jul 2021 13:07:52 +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 10F41610D0 for ; Tue, 27 Jul 2021 13:07:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 10F41610D0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 68A46832FD; Tue, 27 Jul 2021 15:07:49 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (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="eWWURjHW"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 3521D83431; Tue, 27 Jul 2021 15:07:47 +0200 (CEST) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 6DFA9832F3 for ; Tue, 27 Jul 2021 15:07:42 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qv1-xf2b.google.com with SMTP id o61so4242435qvo.1 for ; Tue, 27 Jul 2021 06:07:42 -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:user-agent; bh=b1TPsiwsPltPiqIOEU6wRDfv7jkHtV97m5Vbu0A7FfU=; b=eWWURjHWwE6jeaUJqcl9zm8BpqT9mxSRwHFQyl/cbPlTO7XLnDA89ooLAxHDGSjDGo /jvLMquQiPFkD7G2a01EPzltd2NMQ/i683/22f0y6KbzznJihvRBqPgTqJsCleDSPJCL KCPnQQDJkeX7uq35Gbc8QCxJzWUbAt2veqL+k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=b1TPsiwsPltPiqIOEU6wRDfv7jkHtV97m5Vbu0A7FfU=; b=WH+gzdq5zCkNAFeIHOERgGSKgBOJVe3nM7+LdWJy9AdA/L51etgf4iw/457QdOGBTY 9/w3rZE/R4VFU3nC3tHrv/alacb1Vl81ZAUtRUEAPTWPAPihIQD7ErPNOvEe48/aa89d E8L3+oIj9CnO25tz8098ybsTbPEvBKjFEReV7SJNTtJB9PD7KurZHy2jTG4f0kxI2JBM T0O8GzBZDkOLWjQKEfJELq2f08XYlYmPWYsghzgMiBsSPZFBfc03/OC2qE6NYJQEiXMc 0R7z5+zM5DN8ikCBRnmZLHI1/bCmFUzdDjueTrZAcUO/V7x4UQtV7i0CDAkFfhYiX0cf cH7A== X-Gm-Message-State: AOAM531j/r41lnsdToeaUZ+LszQrc8VoGcLdIDi+nWftW54JGBt36jrZ GXTsTmxPANxN89vK3lGwIT61gg== X-Google-Smtp-Source: ABdhPJwvgYh01iw0NasdOfdPxj/o61Qf6/IdFhedb4sPkBDreeU7PFcj3/4enfGptqxx9b7fzRcpQQ== X-Received: by 2002:a0c:d44e:: with SMTP id r14mr19483284qvh.61.1627391261225; Tue, 27 Jul 2021 06:07:41 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-f53f-8332-072c-4f35.res6.spectrum.com. [2603:6081:7b01:cbda:f53f:8332:72c:4f35]) by smtp.gmail.com with ESMTPSA id n25sm1666787qkh.21.2021.07.27.06.07.39 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 27 Jul 2021 06:07:40 -0700 (PDT) Date: Tue, 27 Jul 2021 09:07:38 -0400 From: Tom Rini To: "Z.Q. Hou" Cc: Michael Walle , Heinrich Schuchardt , "u-boot@lists.denx.de" , Priyanka Jain Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature Message-ID: <20210727130738.GF9379@bill-the-cat> References: <20210722062559.21188-1-Zhiqiang.Hou@nxp.com> <20210722152622.GY9379@bill-the-cat> <20890af388806b4bead24e9a10532305@walle.cc> <0d468c9131a730ce473df4b6324385ec@walle.cc> <20210726122836.GM9379@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="53h0S5Wmpfquw9J4" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.9.4 (2018-02-28) 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 --53h0S5Wmpfquw9J4 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 27, 2021 at 05:42:51AM +0000, Z.Q. Hou wrote: > Hi Tom, >=20 > > -----Original Message----- > > From: Tom Rini > > Sent: 2021=E5=B9=B47=E6=9C=8826=E6=97=A5 20:29 > > To: Z.Q. Hou > > Cc: Michael Walle ; Heinrich Schuchardt > > ; u-boot@lists.denx.de; Priyanka Jain > > > > Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature > >=20 > > On Mon, Jul 26, 2021 at 07:37:53AM +0000, Z.Q. Hou wrote: > > > Hi Micheal, > > > > > > > -----Original Message----- > > > > From: Michael Walle > > > > Sent: 2021=E5=B9=B47=E6=9C=8826=E6=97=A5 15:13 > > > > To: Z.Q. Hou > > > > Cc: Tom Rini ; Heinrich Schuchardt > > > > ; u-boot@lists.denx.de; Priyanka Jain > > > > > > > > Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER > > > > feature > > > > > > > > Am 2021-07-26 09:01, schrieb Z.Q. Hou: > > > > > Hi Michael, > > > > > > > > > >> -----Original Message----- > > > > >> From: Michael Walle > > > > >> Sent: 2021=E5=B9=B47=E6=9C=8823=E6=97=A5 1:01 > > > > >> To: Tom Rini > > > > >> Cc: Z.Q. Hou ; Heinrich Schuchardt > > > > >> ; u-boot@lists.denx.de; Priyanka Jain > > > > >> > > > > >> Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER > > > > >> feature > > > > >> > > > > >> Am 2021-07-22 17:26, schrieb Tom Rini: > > > > >> > On Thu, Jul 22, 2021 at 02:25:59PM +0800, Zhiqiang Hou wrote: > > > > >> > > > > > >> >> From: Hou Zhiqiang > > > > >> >> > > > > >> >> The feature BOOTENV_SHARED_EFI is not supported on layerscape > > > > >> boards, > > > > >> >> it didn't result kernel boot crash previously since there > > > > >> >> isn't the efi/boot/"BOOTEFI_NAME" and it skip calling of > > 'boot_efi_binary'. > > > > >> >> > > > > >> >> But since the commit f3866909e350 ("distro_bootcmd: call EFI > > > > >> >> bootmgr even without having /EFI/boot"), it will cause kernel > > > > >> >> boot crash as there isn't a valid fdt_addr and it finially > > > > >> >> uses the device tree blob of U-Boot and further cause errors. > > > > >> >> > > > > >> >> As this feature is enabled by default for armv7 and armv8, so > > > > >> >> disable it explicitly to avoid calling the 'scan_dev_for_efi'. > > > > >> > > > > > >> > I'm not thrilled with this. Why isn't the solution to get and > > > > >> > keep in sync the device trees, so that the tree U-Boot has is > > > > >> > valid for the kernel? I'm also open to discussing f3866909e350 > > > > >> > more. But I'm really opposed to disabling EFI_LOADER on modern > > > > >> > platforms as that will make adoption of U-Boot in device harde= r I > > feel. > > > > >> > > > > >> I don't know whats going on with the NXP boards, but the sl28 is > > > > >> a layerscape board it is working pretty well with EFI boot. > > > > > > > > > > Do you mean the EFI boot work well on sl28? > > > > This, for example, I can boot the debian installer out-of-the-box, > > > > given that the fdtfile variable is set correctly. > > > > > > Oh, we are talking on different case. > > > > > > > > > > > > Or the EFI boot doesn't break other boot ways? > > > > > > > > > > In my case, there are 4 MMC partitions and a boot script with boot > > > > > images in the 2nd partition, while nothing in the 1st partition. > > > > > So the expected boot flow is the 'bootcmd_mmc0' scan the 1st > > > > > partition and find it's not bootable and then the 2nd partition > > > > > and boot with the script. But actually the 'scan_dev_for_efi' got > > > > > problem when scan the 1st partition, as the u-boot DTB is used in > > > > > 'bootefi bootmgr' and result in some error related to the DTB. > > > > > > > > As mentioned in the other mail, I'm not sure why "bootefi bootmgr" > > > > does something at all, because AFAIK it needs the BootOrder/BootNext > > > > variables. Heinrich, please correct me if I'm wrong. > > > > > > I'm not familiar with EFI boot, In this case, the 'scan_dev_for_efi' = calls 'run > > boot_efi_bootmgr' then 'bootefi bootmgr', seems it doesn't check if the > > needed components exist. > > > Is the cmd 'scan_dev_for_efi' wrong? > >=20 > > I'll let Heinrich comment on this part. > >=20 > > > > > Actually, if give a readable but invalid 'fdt_addr' in env, the > > > > > EFI boot can also be skipped during the scan of the 1st partition. > > > > > Actually on some Layerscape boards the provided env 'fdt_addr' > > > > > with a non-readable address, and on other boards a readable > > > > > 'fdt_addr'. Seems the patch author copy them from somewhere but > > > > > didn't cause issue that time. But this is just a workaround, the > > > > > EFI boot should not cause problem during the scan phase when there > > > > > isn't needed components in one of these partitions. > > > > > > > > What exactly is going wrong? Is linux booting at all? Or does the > > > > bootloader abort? > > > > > > Pasted the log below, the direct cause seems the u-boot DTB doesn't h= ave > > /cpus node. > > > > > > =3D> run bootcmd_mmc0 > > > switch to partitions #0, OK > > > mmc0 is current device > > > Scanning mmc 0:1... > > > libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disk > > > esdhc@1560000.blk... > > > Found 5 disks > > > No EFI system partition > > > couldn't find /cpus > > > "Synchronous Abort" handler, esr 0x96000006 > > > elr: 0000000082004a6c lr : 0000000082004a30 (reloc) > > > elr: 00000000fbd25a6c lr : 00000000fbd25a30 > > > x0 : 0000000087f00a88 x1 : 000000001cfbfd5e > > > x2 : efbeaddeefbeadde x3 : 00000000efbeadde > > > x4 : 00000000fffffffc x5 : 0000000087f037d2 > > > x6 : 0000000000000a58 x7 : 0000000000000003 > > > x8 : 0000000087f00000 x9 : 0000000000000008 > > > x10: 0000000000000a44 x11: 00000000fbc17c6c > > > x12: 00000000000009e4 x13: 0000000000000000 > > > x14: 0000000087f00000 x15: 00000000fbc180d8 > > > x16: 00000000fbd742d0 x17: 0000000000000000 > > > x18: 00000000fbc1cdb0 x19: 00000000000009e4 > > > x20: 0000000087f00000 x21: 00000000fbdb3404 > > > x22: 00000000fbdb4a97 x23: 0000000000000018 > > > x24: 00000000fbde5d44 x25: 0000000000000000 > > > x26: 0000000000000000 x27: 0000000000000000 > > > x28: 00000000fbc5ba60 x29: 00000000fbc17d30 > > > > > > Code: a94153f3 a9425bf5 a8c47bfd d65f03c0 (b8617803) Resetting CPU ... > > > > > > > > > > > > > > And why don't you fix the fdt_addr then? Shouldn't it be unset if t= here is > > no > > > > actual device tree present in a ROM section? (I don't say there isn= 't > > another > > > > underlying problem when you use an invalid fdt_addr). > > > > > > The problem shown in above log is triggered when unset the fdt_addr. > >=20 > > OK, so that shows a problem to fix. If there's not a valid device tree > > found, that error needs to be handled and not ignored. >=20 > Drop this patch if the problem can be fix. Yes, it certainly seems like this should be fixed? Are you going to investigate? --=20 Tom --53h0S5Wmpfquw9J4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmEABRYACgkQFHw5/5Y0 tyzLvAv+Pl0WWM5HGaNALfQvMI0lriFK+tjJHO/zuqCgUgpRh59ZFuwKZZI77m1A qAUqO3SjLaEt8RN5q+SHAI1GL3P26ATb/bIqpYpw5k88ufwo6ns0HoRBPMlFl3NG fWJ/SUVJbBQCrhwXsIQ5hBb5rsD3tfIID6h1yG6fGtVXNPstkK/SNqMzF96ZjDt7 ZwoAwOotLR1w5rVmQLyCXqJMCCi5A1frnUXPbSUwxsnZOgGMZ+uoetQnqZhSXDWd A7CA12DTS/RQhk5e4sIY9hvaNCGkf9s0bL5D9iDfGPGD6r3q4IWUrpE3PqcyunAV dsQcPV2ujIg07svQTBkqB2ZxzxAnVt0MZSuVnjSm83Hu8IATsr6AFLx/h1prE3uE wdP3/3N2hyN/eR9qFoA8l0NVEjjgFno5OglU1802GwS/8h0SByNN1UCe+bivZVtx 2RCOgjq3F7F+v/M0MmJFz5OqRo9UPxtScsDqDurPttYivVVUAZ3HaVszV72xwL1t JYnGOK3m =nqrT -----END PGP SIGNATURE----- --53h0S5Wmpfquw9J4--