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 56EFAC636D4 for ; Fri, 17 Feb 2023 11:06:53 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 62F7D85C0C; Fri, 17 Feb 2023 12:06:50 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=canonical.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=canonical.com header.i=@canonical.com header.b="UduTiuZd"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 94C6B85C13; Fri, 17 Feb 2023 12:06:47 +0100 (CET) Received: from smtp-relay-internal-0.canonical.com (smtp-relay-internal-0.canonical.com [185.125.188.122]) (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 6AE46855D9 for ; Fri, 17 Feb 2023 12:06:43 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=canonical.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=heinrich.schuchardt@canonical.com Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id 733D53F4A6 for ; Fri, 17 Feb 2023 11:06:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1676632002; bh=fXMqmtCAeGuZVplguERNhLfmMW0Yu3bt+v7I5vgrluM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=UduTiuZdFGAFtjNrKGRuWJWIvu4W0fYIwqevkQEczM/QB9sbkHdFUEbq6UiLf522U d/+y+BwTWCpF9PwKcnehmmgw6CNYgYpK402lAgMYByWr7FjF7MpjUxpUsOLwH5EgqA EsYVtqplBjkAQDg8f7PuuedsinRwbZpaCp47Y5ZwuGNtpoYziFQO8xrnQxbeCe0B35 1XOd8Tf88Ntm7HZ5foGSjTChpCkR73Ojjtk07n9vA4QVoBErH/QkFlYUYlveRG+qEs a/2gvfX1Ng7LIg7xfAKs020c1kTRUayDiloKTq82wkSguuUdcOqi4pdF8jK1nBx6Z1 vx2UUr4GTRSDA== Received: by mail-wm1-f72.google.com with SMTP id k2-20020a05600c1c8200b003e209b61ebbso506593wms.3 for ; Fri, 17 Feb 2023 03:06:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=fXMqmtCAeGuZVplguERNhLfmMW0Yu3bt+v7I5vgrluM=; b=5pb1aWlSEkTnhZiOdNTu7P20SdJ/LR7Zdaalqvm1zvl629xIMc+Maw/CCafXi3eOZy NKqvcWWPIDg1MQdsKB0Zw/rSUoD1yUJXGdoSsGbxuBTRkkil5Xt+i+FT3mmaVD7lNMy4 uwVPOyTvHmn02tJZPV/ZvSudGtH5XlwdSzDOtV63sTVTxQAyvJFIRZr94am+nTJI/bfO zo78dl5B+xklyaVfMZgWML8CdeGKixSHdA02nKwxTXH8FFkz9NalPZ3bPSwZxYEslUOp G8mrBCrOJ7wM1H8H4kZOjhrfDZoU0l4DgO7c4+FlX4HY0ggPfpbxTAY0NI0/+CvwCuTD 9o+A== X-Gm-Message-State: AO0yUKXCxgH59Wbb7xh1y2heg6CRE6Ceo4OVKCquo9yeOEeUQymIUY0u 6g7iGHY0e6O3m9cgMP6LQTGDBk0ldc+5Cce20QoWQvSzHmETllSLJv21y6HbZ7mOprvMmSfWeXC Vk1bByLGca5nBwQ3AFBeQi9bfxatKXFI= X-Received: by 2002:a05:600c:44c9:b0:3e2:185d:7d1e with SMTP id f9-20020a05600c44c900b003e2185d7d1emr2895276wmo.11.1676632002109; Fri, 17 Feb 2023 03:06:42 -0800 (PST) X-Google-Smtp-Source: AK7set/e1v2XKSrFzTMEZ6zEsHAvNwMbq3YytXxsnHOFDZq8olNOXeoWQ7ihH95RR1cViAO6NxXP1g== X-Received: by 2002:a05:600c:44c9:b0:3e2:185d:7d1e with SMTP id f9-20020a05600c44c900b003e2185d7d1emr2895252wmo.11.1676632001697; Fri, 17 Feb 2023 03:06:41 -0800 (PST) Received: from [192.168.123.67] (ip-088-152-145-137.um26.pools.vodafone-ip.de. [88.152.145.137]) by smtp.gmail.com with ESMTPSA id o2-20020a05600c378200b003dfe5190376sm4701821wmr.35.2023.02.17.03.06.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Feb 2023 03:06:41 -0800 (PST) Message-ID: <855b2923-d6ad-674f-ef7f-e31c9502d539@canonical.com> Date: Fri, 17 Feb 2023 12:06:40 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH v2 1/1] spl: allow loading via partition type GUID To: Mark Kettenis 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 References: <20230216152956.130038-1-heinrich.schuchardt@canonical.com> <39edd2e5-47fd-485f-7ce4-ad708667dfa2@canonical.com> <87r0uotwbk.fsf@bloch.sibelius.xs4all.nl> Content-Language: en-US From: Heinrich Schuchardt In-Reply-To: <87r0uotwbk.fsf@bloch.sibelius.xs4all.nl> Content-Type: text/plain; charset=UTF-8; format=flowed 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.6 at phobos.denx.de X-Virus-Status: Clean 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 >>> 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. Best regards Heinrich > >> 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 >>