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 5EB2FC433EF for ; Tue, 7 Jun 2022 20:54:32 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 3E46E83F41; Tue, 7 Jun 2022 22:54:30 +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="MhufIbyG"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id D630E842C4; Tue, 7 Jun 2022 22:54:28 +0200 (CEST) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 D6C0B83678 for ; Tue, 7 Jun 2022 22:54:25 +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=alpernebiyasak@gmail.com Received: by mail-ed1-x534.google.com with SMTP id x5so19447882edi.2 for ; Tue, 07 Jun 2022 13:54:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=E0+zaqurrAibQLEVGSvdTQTYcBbK5XNR1taPazeqpTo=; b=MhufIbyGgtwJBqBiXtuk5Dpz6UOwgmHDHb4EztJbBz2x9Ec+6iNxZysNZ1SQjgv6Cn Z/0qVZ9uj4hNUhjM1Gv5URCs4UaG18M0Nq2h9AGdR4/SOP5kxR36O2IJHykMOO/9Set6 b6oL2JDGScVSGdE52ea3OXpS0VDo4539mCha6NY+uiS6u+3npzz6WOfDnCLK74RupMde WF6KRekWAqa8oAabdMV5VMOkMZT/JX6gvWcXH2biRosin3eHHMZrlaxppdh58puv6Oif hzhiYqyqEKGRMBU9Kf/W51lfBRzWDcfObKo6GXERikF7ocMDKGCF2rVJDaneDZqxvKMJ Qj/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=E0+zaqurrAibQLEVGSvdTQTYcBbK5XNR1taPazeqpTo=; b=EgZtHzhatCIEx3fLTwzfOcX2EFebHtF31B3fi5j1HEyaL+JCM0cMiJKnLhZNzxHOcG 34h6tXgUrs+XpE49nbtjpfNwovCZeQ1LhzSLMGDzw1jYUvRr8k451f9X9RzBTeTbcb0c ZKQzwdMieUIZfLfPVRtnV/lyAPQV8AmCcpdQjqPNRUvXWMRhb3xQ+TFLFZus5FYqIuc8 8Djok0n/MNz9wR5TEj5xk5zA0qLxnyfDFtMHlWh1gun3K56HyVK/fRLQ1cps581OmYiT AjR6QuxHLVg3CWRb2ji3kHpru5Xk0qbESpJ2vcRL67br7mu/lxW+eewNRz39WcTQOBe8 AzEw== X-Gm-Message-State: AOAM532bKhtzh6ofS+E0++QHs2l/ODMiVtyBhOZLGGK83SW33Mpzox+7 rSo+HkkwFThHpqz0SAyLTi4= X-Google-Smtp-Source: ABdhPJw4S1K1B3W5HDO0n8KTGDeo06UxsDdTOAQEyKwD07flErn5fYDMdMx+CUiWsmn/WrbceLVslw== X-Received: by 2002:a05:6402:322a:b0:42e:1778:1f1f with SMTP id g42-20020a056402322a00b0042e17781f1fmr33159471eda.115.1654635265309; Tue, 07 Jun 2022 13:54:25 -0700 (PDT) Received: from [192.168.0.74] ([178.233.178.185]) by smtp.gmail.com with ESMTPSA id h22-20020aa7c616000000b0042ab2127051sm10767054edq.64.2022.06.07.13.54.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Jun 2022 13:54:24 -0700 (PDT) Message-ID: <0b62a04b-8472-8f49-82ca-d1ba684d2e16@gmail.com> Date: Tue, 7 Jun 2022 23:54:20 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH 2/8] configs: imx8mm_data_modul_edm_sbc: not select SPL_RAM_DEVICE Content-Language: en-US To: Marek Vasut Cc: u-boot@lists.denx.de, Peng Fan , "Peng Fan (OSS)" , sbabic@denx.de, festevam@gmail.com, trini@konsulko.com References: <20220603071715.15212-1-peng.fan@oss.nxp.com> <20220603071715.15212-3-peng.fan@oss.nxp.com> <652ebe3d-48a3-9c70-a21a-739541a73803@denx.de> From: Alper Nebi Yasak In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 07/06/2022 21:11, Marek Vasut wrote: > On 6/7/22 19:26, Alper Nebi Yasak wrote: >> On 06/06/2022 17:07, Marek Vasut wrote: >>> On 6/3/22 09:17, Peng Fan (OSS) wrote: >>>> From: Peng Fan >>>> >>>> i.MX8M use FIT image, not RAW image. And to support binman symbols, >>>> u_boot_any could be optimized if RAW image is not selected, otherwise >>>> there will be build failure. So not select SPL_RAW_DEVICE >>> >>> Is it RAW device/image or RAM device/image ? There seem to be some >>> confusion here. It also seems this might break start of U-Boot by JTAG >>> upload, right ? >> >> The previous patch disables SPL_RAW_IMAGE_SUPPORT for i.MX8M boards >> (already disabled for this), this one disables SPL_RAM_DEVICE (was only >> enabled for this). Both need to be disabled for this series in its >> current form to avoid a binman symbol-related error, but this commit >> message suffers from being copy-paste of the previous one. > > OK, I am really confused now. What binman symbol error ? When BINMAN_SYMBOLS is enabled, some binman 'u_boot_any' symbols are declared in common/spl/spl.c. They are marked as 'unused', but if anything actually uses them they survive optimization and show up in the spl/u-boot-spl ELF file. When binman is building an image including a 'u-boot-spl' entry, it sees these symbols and tries to fill them in with appropriate values about 'u-boot'-like entries. If there is no such entry in the same image as the 'u-boot-spl', binman raises an error about this. In this case, SPL_RAW_IMAGE_SUPPORT and SPL_RAM_DEVICE both enable code that uses the 'u_boot_any' symbols. However, the i.MX8M binman image descriptions try to specify the binman images in a modular way, and one of the images has a 'u-boot-spl' without any 'u-boot'-like entries. Which means enabling the configs ends up triggering the error above. See my reply to an earlier version [1] (this is actually v6 of this series) about what could be done to solve this properly. Also see previous discussions [2][3] for more info. [1] Re: [PATCH V4 1/8] spl: guard u_boot_any with X86 https://lore.kernel.org/u-boot/334898af-f495-acb5-0c5a-1f4a9acce66e@gmail.com/ [2] using binman fails boot https://lore.kernel.org/u-boot/CAJ+vNU0BZDr2q0ZPQkoQBP1eBhbYmQfJMYraSgOvWXwZ=yFReQ@mail.gmail.com/T/#u [3] imx8: ls1028a: Drop raw image support https://lore.kernel.org/u-boot/20210801205951.2202789-1-sjg@chromium.org/T/#u > Is this some attempt at papering over a bug ? Simon recommended disabling SPL_RAW_IMAGE_SUPPORT to resolve this error in the previous discussions [3]. But I'm leaning towards saying yes here, I think it's a workaround to something that should change on the binman side. I'm not exactly sure what or how. Just now I thought maybe we could add a BINMAN_SYMBOLS_FOR_NEXT_PHASE config or so, which would enable the 'u_boot_any' etc. symbols instead of BINMAN_SYMBOLS. Regardless, I think this version is a good enough step in the right direction and more changes can still be done afterwards, so I'm not asking for a new version.