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=-9.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 541FEC4338F for ; Tue, 24 Aug 2021 20:30:16 +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 350E161139 for ; Tue, 24 Aug 2021 20:30:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 350E161139 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.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 715A982C90; Tue, 24 Aug 2021 22:30:12 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com 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=gmail.com header.i=@gmail.com header.b="GOUkj9ej"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 52D8982D95; Tue, 24 Aug 2021 22:30:10 +0200 (CEST) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 0D6A881BC0 for ; Tue, 24 Aug 2021 22:30:06 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=mr.nuke.me@gmail.com Received: by mail-ot1-x32f.google.com with SMTP id o16-20020a9d2210000000b0051b1e56c98fso34642952ota.8 for ; Tue, 24 Aug 2021 13:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=SiQ4N8gpP/tTSLgBQi/7TB9n12z3N14JyDEX1ng6swE=; b=GOUkj9ejaBAeeYuEnyX9UIMp7H77GfV78TcV+ztXT29g93JtURlxKltRothYcMtZ/C H5gdy3Ry398eN2kXXCeIcrUfzy+hIu5weU4BLUSTkfm61R78qiibz+7mL626Xw5ZeyjZ wMijSTisqs8nXYJSfPCW1gu+uKMS2s2wgkM5QMhaunq8Ag7e9yU7KrsgviQtNat3onJ/ eTV+dsoqXk0zH+LlzeKw7tTAjoqNoM2c48wenhVl9lzsswZk5uQTHMXFxqaLTocQmL1z 7KAQRNIq/mx+UcILPYgCTaFeXRuxoeCYsrZguG/clMQvKjgjdrNUPzNAbaUM7imzQMzJ 3doQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=SiQ4N8gpP/tTSLgBQi/7TB9n12z3N14JyDEX1ng6swE=; b=Jfhtc1bIBxLmJsgxWswKUUA4kJnfaNwYruBdC3eTthdKd7M4EAM8CLkOCEDLqqGvWy fuXO28fHtis2aYg8s1hsgm5SOn1NQCHOKA8ya82S4dl1UeQIom5Ak39hLFRSp+4HQQke yFxMulB9e4+QPlxt689j9QH4Oxj63sz40SK9qFjYCH6nkbWEjM92NfQoo1g2FRSyokWx Y4mCfp37fYu9ZGbgr5RwcKQ5pdNBK87OiJfhIvwnTWlCzEvsAeTyjgaV1khiXHA+IUgj rr11GMtHgOmtmXzsou7Fc6dDNcAHORLUgi8HNb3PFQR7xw2W+7t1jNFZLcV9c+ArRBsp nelQ== X-Gm-Message-State: AOAM532wTdfi7UZej9INkFUyMNaz1dXUMdoUUqaaO+SBZ7ktYLI9X5Z3 iAfhasMgHZBETTWFi1S/PXcMJ9OJGVk= X-Google-Smtp-Source: ABdhPJxuGZz60IrlvLpWzGrdf3BlTxyLZyGIn9GrspHaUs46XC9vRQjLEYtYaQQUQbxz/IkUR++w8g== X-Received: by 2002:a05:6808:21a0:: with SMTP id be32mr4133080oib.148.1629837004486; Tue, 24 Aug 2021 13:30:04 -0700 (PDT) Received: from nuclearis3.gtech (c-98-195-139-126.hsd1.tx.comcast.net. [98.195.139.126]) by smtp.gmail.com with ESMTPSA id q22sm4818839ots.64.2021.08.24.13.30.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Aug 2021 13:30:03 -0700 (PDT) From: "Alex G." Subject: Massive stm32mp1 breakage with v2021.10-rc2 To: Patrick DELAUNAY , "u-boot@lists.denx.de" Cc: Marek Vasut Message-ID: <966fc974-8331-aeac-ba15-5b2ab19c0eaf@gmail.com> Date: Tue, 24 Aug 2021 15:30:03 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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 Hi Patrick, I'm having issues with some of the recent changes centered around FIP support and CONFIG_STM32MP15x_STM32IMAGE. and commit f91783edf224 ("arm: stm32mp: handle the OP-TEE nodes in DT with FIP support") ## Problem description > +#ifdef CONFIG_STM32MP15x_STM32IMAGE > + /* only needed for boot with TF-A, witout FIP support */ > firmware { > optee { > compatible = "linaro,optee-tz"; > @@ -33,6 +35,7 @@ > no-map; > }; > }; > +#endif This removes the "optee" and "reserved-memory" nodes. These nodes are required by SPL for setting up TZC memory regions, as introduced in commit 8533263c8512 ("stm32mp1: spl: Configure TrustZone controller for OP-TEE"). ## Further details We now have several boot flows: 1) BL1 -> SPL -> u-boot 2) BL1 -> SPL -> OP-TEE (this path is now broken) 3) BL1 -> TF-A -> u-boot (use case for STM32IMAGE) 4) BL1 -> TF-A -> OP-TEE (use case for STM32IMAGE) 5) BL1 -> TF-A -> FIP container So it seems that STM32IMAGE only makes sense for (3) and (4), but shouldn't affect the others. The fact that OP-TEE is mixed into this is the first red flag. > INPUTS-$(CONFIG_STM32MP15x_STM32IMAGE) += u-boot.stm32 > MKIMAGEFLAGS_u-boot.stm32 = -T stm32image ... This tells me we use _STM32IMAGE just to enable another output image format. The build could give me both u-boot.img, and u-boot.stm32, and I would use the correct file. SO in this case, I would expect _STM32IMAGE to not change the code behavior. This is the second red flag. > $ git grep -c 'ifdef CONFIG_STM32MP15x_STM32IMAGE' > arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c:1 > arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c:2 > arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h:1 > arch/arm/mach-stm32mp/include/mach/stm32prog.h:1 We're actually trying to move away from ifdefs, so this intense reliance on _STM32IMAGE raises the third red flag. > board/st/common/stm32mp_mtdparts.c:9 I'm not sure I fully understand why there are so many ifdefs in mtdparts.c. MTD layout seems to me like something that is intended to be devicetree-driven. This is the fourth red flag. Let's take a deeper look at one of those: > stm32mp_mtdparts.c:#ifdef CONFIG_STM32MP15x_STM32IMAGE > stm32mp_mtdparts.c: tee = > stm32prog_get_tee_partitions(); > stm32mp_mtdparts.c-#endif This makes no sense to me. What does OP-TEE presence have to do with the image format of u-boot? If TF-A requires a different layout in FIP vs non-FIP mode, then it's the responsibility of TF-A to supply a corrected devicetree to u-boot. It's not u-boot's role. ## Proposal I propose we remove CONFIG_STM32MP15x_STM32IMAGE. Always build u-boot.stm32, and don't mix it with code behavior. Alex