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 A2DA3CD6E43 for ; Fri, 29 May 2026 10:53:37 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id E9E9D84671; Fri, 29 May 2026 12:53:35 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=reject dis=none) header.from=nabladev.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=nabladev.com header.i=@nabladev.com header.b="kQfzOVnG"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id E27D7846A3; Fri, 29 May 2026 12:53:34 +0200 (CEST) Received: from mx.nabladev.com (mx.nabladev.com [IPv6:2a00:f820:417:0:178:251:229:89]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 049C5844CF for ; Fri, 29 May 2026 12:53:33 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=reject dis=none) header.from=nabladev.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=marex@nabladev.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 46CF110A1C5; Fri, 29 May 2026 12:53:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nabladev.com; s=dkim; t=1780052011; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:content-language:in-reply-to:references; bh=cOYn4RVXDSlEZwXarnfpeLdaPdrXoQjKguUKpzppdGk=; b=kQfzOVnG7d2W6pY5+DJtS8u+cYjot9SKdtEvICup7xiT1NdZiohNkSQaNKqmMe5Shge0Kq qHwKWHmPWiDz3mTs6H0B7o8g5QGetByRfMe/+vE/rKIflNkiUV87UBBnN1/vsIbOf9M4WZ CiqwIDxuRrfKhi6O6tAH15pCXkg52t+HDAdVKIUMRZjktTZ2dYB04NAXVy7KdCHHcXiKYr 3i1J8KWLCQPoifiuPPT3p8DNST3g7dj2xygK+r/2N7BYmiOWYY9ye6CLjblR2ZZiqWJrVA Q95ktjJK+Fx09z2ZFuErGfZwHJRw1Vazz8BBq9OfUzkeekIsw9Jf8/d1rDzONg== Message-ID: <0777b89b-86af-4f4a-ade0-d2ffc66bfa4e@nabladev.com> Date: Fri, 29 May 2026 12:53:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/3] binman: imx8mimage: Handle nxp,boot-from = "fspi" To: Fabio Estevam Cc: u-boot@lists.denx.de, "NXP i.MX U-Boot Team" , Adam Ford , Alexander Koch , Peng Fan , Simon Glass , Tom Rini References: <20260525235155.96167-1-marex@nabladev.com> Content-Language: en-US From: Marek Vasut In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Last-TLS-Session-Version: TLSv1.3 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.8 at phobos.denx.de X-Virus-Status: Clean On 5/28/26 2:43 PM, Fabio Estevam wrote: > Hi Marek, > > On Mon, May 25, 2026 at 8:52 PM Marek Vasut wrote: >> >> Boot from FSPI requires additional 448 Byte long header, with U-Boot SPL >> starting at offset 0x1000. Currently, both i.MX8MM and i.MX8MN attempt >> to generate this header using fspi_conf_block with filename pointing at >> CONFIG_FSPI_CONF_FILE file. This does not work, for two reasons. >> >> First, the CONFIG_FSPI_CONF_FILE is generated by mkimage -T imx8mimage >> and may not be available yet when the fspi_conf_block is evaluated. That >> leads to a race condition where highly parallel builds fail to find the >> CONFIG_FSPI_CONF_FILE, which is usually called fspi_header.bin, on first >> build attempt. >> >> Second, binman gets confused and patches incorrect offset of DDR PHY >> firmware blobs into U-Boot SPL, the offset is incremented by exactly >> 0x1000 which is the size of fspi_conf_block. >> >> Fix both problems at once, make imx8mimage handle the generated FSPI >> header and prepend it in front of the imx8mimage processed data. This >> way, the race condition is solved, because the data generated by the >> imx8mimage are surely combined only after mkimage -T imx8mimage ran. >> The binman offset calculation is also solved, because there is no >> fspi_conf_block node in the DT anymore. >> >> Signed-off-by: Marek Vasut > > Is this series 2026.07 material, or can it wait until 2026.10? > > Alexander, if possible, please test this series and reply with your > Tested-by tag. This should have been 2024.07 material, but I had no hardware to debug this on, so 2026.07 will do.