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 9E384C636CC for ; Sun, 19 Feb 2023 19:52:18 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 4107E85778; Sun, 19 Feb 2023 20:52:16 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=xs4all.nl 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; secure) header.d=xs4all.nl header.i=@xs4all.nl header.b="KG5gkowJ"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 1B62B857E3; Sun, 19 Feb 2023 20:52:13 +0100 (CET) Received: from ewsoutbound.kpnmail.nl (ewsoutbound.kpnmail.nl [195.121.94.167]) (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 821E58576A for ; Sun, 19 Feb 2023 20:52:06 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=xs4all.nl Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=mark.kettenis@xs4all.nl X-KPN-MessageId: e0e631f5-b08e-11ed-b20d-005056abbe64 Received: from smtp.kpnmail.nl (unknown [10.31.155.38]) by ewsoutbound.so.kpn.org (Halon) with ESMTPS id e0e631f5-b08e-11ed-b20d-005056abbe64; Sun, 19 Feb 2023 20:52:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xs4all.nl; s=xs4all01; h=subject:to:from:message-id:date; bh=6JDO8BEr31MLr12ADq4LAAmNyEL6ZGD5gOLGeh1tvBo=; b=KG5gkowJp2/BDgTxOd5+x1B/orhEhSyIgIdEE4pAmjlIQxf77p3DwtNjn10JKdyHB13xQIc2YtPLX 5wdvzlRfOFFylkckLZlNIXCWuEinBCDfB55qj8XGhKOaVMrlusk61Dqr/I/H/9afnsiOrxfNyhQKVG e3wby3CT7262rOwfg9TFN9hLZrynTrSRXqaBiZBQ3vUfEgjOBTbpA8E1TfHlI+xL7VHyIEL/0HuWDx DPX7bcvXM6uxUPDcA3BcHhhi3jJwDE2IjlybNb1WrSOaEvdC33V+nuWMrIj1rkHhLaWREhBF15WUSG rxPczY+6UsB/q1WxXl7pKpaVz/91YLA== X-KPN-MID: 33|KUQz9m5NIB5ZCd5nFM7XZlC2LByDdpMiYN1mVpM/u/WqokHkVUkO32NucnOApOe S0MeQwXqHzKmaagLwhoO9AA== X-KPN-VerifiedSender: Yes X-CMASSUN: 33|skXSfYaTOa/06rE3Q3hAzthYnwS7bJo5NhJRl4LMzT8WZdnvHxsFlU5JXuXr/z6 KyVpFSh/ZzfLbztkblZDa2Q== X-Originating-IP: 80.61.163.207 Received: from bloch.sibelius.xs4all.nl (80-61-163-207.fixed.kpn.net [80.61.163.207]) by smtp.xs4all.nl (Halon) with ESMTPSA id e1d03bcb-b08e-11ed-97f1-005056abf0db; Sun, 19 Feb 2023 20:52:04 +0100 (CET) Date: Sun, 19 Feb 2023 20:52:03 +0100 Message-Id: <87h6vhtov0.fsf@bloch.sibelius.xs4all.nl> From: Mark Kettenis To: Heinrich Schuchardt Cc: sjg@chromium.org, trini@konsulko.com, yanhong.wang@starfivetech.com, afd@ti.com, alpernebiyasak@gmail.com, sr@denx.de, andre.przywara@arm.com, cJ-uboot@zougloub.eu, hws@denx.de, u-boot@lists.denx.de In-Reply-To: <855b2923-d6ad-674f-ef7f-e31c9502d539@canonical.com> (message from Heinrich Schuchardt on Fri, 17 Feb 2023 12:06:40 +0100) Subject: Re: [PATCH v2 1/1] spl: allow loading via partition type GUID References: <20230216152956.130038-1-heinrich.schuchardt@canonical.com> <39edd2e5-47fd-485f-7ce4-ad708667dfa2@canonical.com> <87r0uotwbk.fsf@bloch.sibelius.xs4all.nl> <855b2923-d6ad-674f-ef7f-e31c9502d539@canonical.com> 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.6 at phobos.denx.de X-Virus-Status: Clean > Date: Fri, 17 Feb 2023 12:06:40 +0100 > From: Heinrich Schuchardt > > On 2/17/23 11:34, Mark Kettenis wrote: > >> Date: Fri, 17 Feb 2023 07:55:58 +0100 > >> From: Heinrich Schuchardt > >> > >>> I'm not sure, but at some point this is all going to get out of hand. > >>> Already we have these options: > >>> > >>> common/spl/Kconfig:config SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR > >>> common/spl/Kconfig:config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR > >>> common/spl/Kconfig:config SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET > >>> common/spl/Kconfig:config SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION > >>> common/spl/Kconfig:config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION > >>> common/spl/Kconfig:config SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE > >>> common/spl/Kconfig:config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE > >>> common/spl/Kconfig:config SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION > >>> common/spl/Kconfig:config SYS_MMCSD_FS_BOOT_PARTITION > >>> common/spl/Kconfig:config SYS_MMCSD_RAW_MODE_KERNEL_SECTOR > >>> common/spl/Kconfig:config SYS_MMCSD_RAW_MODE_ARGS_SECTOR > >>> common/spl/Kconfig:config SYS_MMCSD_RAW_MODE_ARGS_SECTORS > >>> > >>> That is just for MMC raw mode. > >>> > >>> For environment we have SYS_MMC_ENV_DEV and _PART. If you look around > >>> you'll see loads of these options. > >>> > >>> I see that rockchip uses u-boot,spl-boot-order as a way to determine > >>> the boot order. This makes it configurable without rebuilding > >>> U-Boot...although I don't think we need to make the MMC stuff > >>> configurable, since I am assuming that the boot ROM determines at > >>> least some of it...? > >> > >> This patch is about SPL loading main U-Boot. So the boot ROM is not > >> involved. > > > > But in that case we surely want to have a single board and SoC > > independent partition GUID? > > > > No. I want to create one installation image which runs on multiple > boards, e.g. > > part 1, GUID 8300, /boot > part 2, GUID 8300, / > part 15, GUID EF00, /boot/efi > part 20, GUID SPL 1, SPL for board 1 > part 21, GUID U-Boot 2, U-Boot for board 1 > ... > part 127, GUID SPL 54, SPL for board 54 > part 128, GUID U-Boot 54, U-Boot for board 54 Interesting idea. However, if you rely on the SoC bootrom to boot from a partition with a specific GUID, you probably can't have separate SPL partitions for each board; you'd just have one for each SoC. And that in turn means that you can't really have a separate U-Boot partition for each board unless you have board-detection code in SPL. But in that case you'd probably be better off with putting that board detection code in U-Boot itself and bundle U-Boot together with the supported board device trees in a FIT. > >>> It seems that the whole thing is crying out for a bit of organisation > >>> and a proper schema. > >> > >> The discussion was about hard-coding the values vs configuration. > >> > >> OS distributions should have enough flexibility to deliver an > >> installation image with U-Boot for multiple boards on the same medium. > >> For the build process it is preferable to use different configurations > >> instead of patching source code per U-Boot which might be required if > >> hard-coded values for partition GUIDs in the device-trees are used. > > > > Well, yes, but it would be even more helpful to have a single > > well-known partition GUID such that the OS partitioning tools can > > recognize the U-Boot partition. If you make it configurable and every > > contributed board uses a different GUID that will be impractical. > > The OS partitioning tools simply shouldn't touch partitions with GUIDs > that they don't know. Well, that makes it hard to "recycle" disks that have been partitioned before. Partition tools will have the ability to delete partitions to make that possible. In that case it is useful for users to be able to determine the purpose of a partition. By the way, you probably should set Bit 0 in the partition table entry Attributes field for these partitions to indicate that a partition should not be deleted. > >> I think Tom's approach is right. The U-Boot documentation should give > >> guidance on how new boards should find U-Boot SPL and main U-Boot. > >> > >> Best regards > >> > >> Heinrich > >> > >