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 96B45E6BF20 for ; Fri, 30 Jan 2026 16:35:56 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 15059844F4; Fri, 30 Jan 2026 17:35:55 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=kernel.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=kernel.org header.i=@kernel.org header.b="CjiWocgr"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id A799284500; Fri, 30 Jan 2026 17:35:53 +0100 (CET) Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) (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 AF832844F1 for ; Fri, 30 Jan 2026 17:35:50 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=mkorpershoek@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id CEF4743BB7; Fri, 30 Jan 2026 16:35:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 19AA5C4CEF7; Fri, 30 Jan 2026 16:35:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769790948; bh=n3W63bHha/kGlNnmMOseeEAWuyzWr32sOlGnQKcXL/4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=CjiWocgr5EvPexZJTK8WvjP89Dlr8rSg3h4PVKHuSkXJ6NBm2/MPfoYXfQdZprpLB kx0S7xf2DiNqwU6GJGCJdwhsC6EPMy3ZMBaMgohueaojBDbzc0GO+4lB3GsnHYuHrt zzk7ODjGzoRXYMBDAHHaFGj23VAj7qEFfVbeOz3xwZf0C/QAPRrpL/AqiKdfLiUABz h4V+Bu52tRgzI4DeBNMpWw2qt09CfcPBTjfDoX/7aFSzfHHmewE5yRv3bkjm1X5U8y JllL03B+6PWnkdZDThkbzkvjJkqCgS/yMYUSCjDbOUauPm7L5UCte6y0WcevF1g8EJ jggS+EnUQhxiA== From: Mattijs Korpershoek To: Mattijs Korpershoek , Heiko Schocher , Mattijs Korpershoek , U-Boot Mailing List Cc: Adrian Freihofer , Dmitrii Merkurev , Fabio Estevam , Marek Vasut , "NXP i.MX U-Boot Team" , Neil Armstrong , Stefano Babic , Tom Rini Subject: Re: [PATCH v1 0/2] fastboot: mmc: fix bootloader offset In-Reply-To: <87zf5wmrxk.fsf@kernel.org> References: <20260124054712.7939-1-hs@nabladev.com> <87y0lkogbt.fsf@kernel.org> <875x8kohmf.fsf@kernel.org> <7d9a3b43-7a6c-dc97-69ad-b71acd062538@nabladev.com> <87zf5wmrxk.fsf@kernel.org> Date: Fri, 30 Jan 2026 17:35:45 +0100 Message-ID: <877bszm526.fsf@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 Hey Heiko, On Thu, Jan 29, 2026 at 15:09, Mattijs Korpershoek wrote: > On Thu, Jan 29, 2026 at 11:41, Heiko Schocher wrote: > >> Hello Mattijs, >> >> On 29.01.26 11:09, Mattijs Korpershoek wrote: >>> On Mon, Jan 26, 2026 at 16:46, Heiko Schocher wrote: >>>=20 >>>> Hello Mattijs, >>>> >>>> On 26.01.26 10:48, Mattijs Korpershoek wrote: >>>>> Hi Heiko, >>>>> >>>>> Thank you for the patch. >>>> >>>> You are welcome! >>>> >>>>> >>>>> On Sat, Jan 24, 2026 at 06:47, Heiko Schocher wrote: >>>>> >>>>>> Not for all SoCs the bootloader start at offset 0x0, >>>>>> in a hardware partition of an emmc. So we need the possibility to >>>>>> set the correct offset, where bootloader starts. >>>>>> >>>>>> Example: >>>>>> >>>>>> imx8qxp revision C0 emmc Partition layout >>>>>> >>>>>> | eMMC block / partition | Offset | Size | Purpose = | >>>>>> | ---------------------- | ---------- | ----- | --------------------= ---------- | >>>>>> | /dev/mmcblk0boot0 | 0x0 | 2MB | imx-boot-container A= | >>>>>> | | 0x00220000 | 128kB | secure boot signatur= e rootfs A | >>>>>> | /dev/mmcblk0boot1 | 0x0 | 2MB | imx-boot-container B= | >>>>>> | | 0x00200000 | 8kB | U-Boot env 0 = | >>>>>> | | 0x00202000 | 8kB | U-Boot env 1 = | >>>>>> | | 0x00220000 | 128kB | secure boot signatur= e rootfs B | >>>>>> >>>>>> imx8qxp rev B0 emmc Partition layout >>>>>> >>>>>> | eMMC block / partition | Offset | Size | Purpose = | >>>>>> | ---------------------- | ---------- | ----- | --------------------= ---------- | >>>>>> | /dev/mmcblk0boot0 | 0x00008000 | 2MB | imx-boot-container A= | >>>>>> | | 0x00220000 | 128kB | secure boot signatur= e rootfs A | >>>>>> | /dev/mmcblk0boot1 | 0x0 | 8kB | U-Boot env 0 = | >>>>>> | | 0x00002000 | 8kB | U-Boot env 1 = | >>>>>> | | 0x00008000 | 2MB | imx-boot-container B= | >>>>>> >>>>> >>>>> Why can't we use raw partition descriptors for this? >>>>> >>>>> See: >>>>> https://docs.u-boot.org/en/latest/android/fastboot.html#raw-partition= -descriptors >>>> >>>> Thanks for this hint! >>>> >>>> Possible yes ( I must try)... but this will lead in adding >>>> complexity to scripts people use all over there and needs >>>> to adapt CI setups, as siemens has B0 and C0 variants. >>>=20 >>> If you try, please let me know. >> >> I am sorry, did not find time yet... sorry. >> >>> Do the same boards (as in U-Boot board definition) have multiple SoC >>> variants (B0 and C0) ? >> >> Yes there is the capricorn board in U-Boot and it have different >> variants (not all mainlined yet) with B0 and C0 variants... >> number of boardvariants grown over the years, started even with A0 SoCs >> (IIRC)... >> >>> In that case I understand it's a pain to add more script complexity. >> >> It is. and U-Boot could easily detect the SoC revision... and it is >> fix ... so no need for having this configurable and making mistakes... > > I agree. > >> >>>> If we introduce this series, user has nothing to know about >>>> offsets for different CPU modules as no change in API for >>>> them... >>>=20 >>> I understand, and I do like this approach as well. I just don't like >>> having 2 code paths/approaches for the "same thing". >> >> Hmm... understandable... >> >>>=20 >>> I am not saying that this is a NAK, but i'd like to iterate a bit to see >>> if we can either deprecated raw partition descriptors (and migrate >>> existing boards) or use that everywhere. >> >> No idea if this is possible for all boards? >> >> May user want to write "some data" to an offset... which is not >> SoC/board dependent... >> >> "flash bootloader" is well defined -> flash the bootloader, so I argue >> that this should simply burn the bootloader to the correct offset... >> >> "raw" interface -> do what you think you need write to wherever you want= ... >> >>> I will try to use this series on VIM3 to see how it behaves. It will >>> take some time though. >> >> VIM3 ? Is this a imx8qxp based hardware? > > No VIM3 is a board made by Khadas that has an Amlogic SoC. But they use > the raw partition description for bootloader offset: > > include/configs/khadas-vim3_android.h > 52: "fastboot_raw_partition_bootloader=3D0x1 0xfff mmcpart 1\0" \ > 53: "fastboot_raw_partition_bootenv=3D0x0 0xfff mmcpart 2\0" \ > > So i'm wondering if this series can be useful to the VIM3 (so that we > could drop the fastboot_raw_partition_* from khadas-vim3_android.h) With some hacking around, I could drop both above fastboot_raw_* from the vim3 environment and use fb_mmc_get_boot_offset() instead. The issue I have is that fb_mmc_get_boot_offset() will return the same offset for both BOOT1 and BOOT2. I'd like to pass a struct blk_desc* to fb_mmc_get_boot_offset() so that I can specify the offset based on desc->hwpart. Do you think that's reasonable? I won't ask you to do this in this series. This will be work I'll do after this is merged. > > >> >> Thanks for your time! >> >> bye, >> Heiko >>>=20 >>> Thanks >>> Mattijs >>>=20 >>>> >>>> bye, >>>> Heiko >>>> --=20 >>>> Nabla Software Engineering >>>> HRB 40522 Augsburg >>>> Phone: +49 821 45592596 >>>> E-Mail: office@nabladev.com >>>> Gesch=C3=A4ftsf=C3=BChrer : Stefano Babic >> >> --=20 >> Nabla Software Engineering >> HRB 40522 Augsburg >> Phone: +49 821 45592596 >> E-Mail: office@nabladev.com >> Gesch=C3=A4ftsf=C3=BChrer : Stefano Babic