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 62175C61DA4 for ; Thu, 16 Feb 2023 21:32:01 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id BAEB7854E2; Thu, 16 Feb 2023 22:31:58 +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="MwFUIVOZ"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id B84948574F; Thu, 16 Feb 2023 22:31:57 +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 B5DD98537F for ; Thu, 16 Feb 2023 22:31:54 +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-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (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 B177C3F4A8 for ; Thu, 16 Feb 2023 21:31:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1676583111; bh=JfFtyVZbAAVj1U1ZQ/bz/DpYP8hN6slaEIpzSGor6fk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=MwFUIVOZS7wOr47ZEx0kpsAuH2UwT/qbAtCoz/ERX0Mzt3AjSmiUq6YuJKAl4Sope YSdykwdcwjxxXhGIxanh787tp63CF44gerfcTqNPHqG17qsMJxxmfoZWXfzSHIUHhi cNKQE0r11pVzR4Hr894Cus9wSNPbwG+dXtx7mtXyPPFsjhFFPVHr9uwmbLFgyPekM0 AMwlTBQyxlRpsykXGpgSBj2Ojf9Dhrjuxt3AF0Ch9zCoLa/mMUkEXO/Q9NIOxMn0v7 h6Zk1DNXguHDyqj2zrz5pcOnvBCnVgkVg5H1QNO6NtFKnO4BmFHVVI0kLDPpIxFL/+ 4LGPeBn9GlwAw== Received: by mail-wm1-f70.google.com with SMTP id j40-20020a05600c1c2800b003e2036a1516so3525363wms.7 for ; Thu, 16 Feb 2023 13:31:51 -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:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=JfFtyVZbAAVj1U1ZQ/bz/DpYP8hN6slaEIpzSGor6fk=; b=BJM9ztyv6gTy0N6gYBSWTSiWLiASPB35HaL8mHmv7wbtbX+DPxh80hSFANsjjooJtc K8MnD1ORHrXfDDUPoe4bXDa1JGonaDm4auA6RvzR3ndo8Hgvvqv04nF6l8VliR2+ew7L SQEV2bJRya+z3j6cwF8/g42A36dY9vYmdypCwpI2BOLNC8RoKcVdVMISe+eQ9tJkdUl2 xqVX1MTe+zap/nnquqpqsPjJ+7Q4Oi+71+QlLwVHuc6bSypFExlI/2sZAEcANDy4HkOV Im7AwYfWSvCOIp6zIF7sXffwxCQeNImH2kUW6VQxwJgN+A1UZtLaUwKWZ3tLhDUXErmG LDMw== X-Gm-Message-State: AO0yUKXKV72BGEpvT5y5/ARx8lGRrD99kiDZdxd087JX1JePSGmGg7Ix yyQLx2P5gdktImSGqLBRnFAZmhzuOw785c87mQErPyAu5EdnuTuhl2R/TufIbwgKR08AoEt0sOA 4QuhuOB15U5sigIVaptwvuAfk5Ow7+yM= X-Received: by 2002:a05:600c:4d8a:b0:3e2:115f:4052 with SMTP id v10-20020a05600c4d8a00b003e2115f4052mr2411493wmp.17.1676583111352; Thu, 16 Feb 2023 13:31:51 -0800 (PST) X-Google-Smtp-Source: AK7set8HPvaFnKhq5SGJn20OtjdgaamHMQBT2LJ0B7f9XUNqrtndVW5j44mc1teBTCEWIHgnwcUHRA== X-Received: by 2002:a05:600c:4d8a:b0:3e2:115f:4052 with SMTP id v10-20020a05600c4d8a00b003e2115f4052mr2411478wmp.17.1676583110832; Thu, 16 Feb 2023 13:31:50 -0800 (PST) Received: from [192.168.123.94] (ip-088-152-145-137.um26.pools.vodafone-ip.de. [88.152.145.137]) by smtp.gmail.com with ESMTPSA id u1-20020a7bc041000000b003d1d5a83b2esm6605636wmc.35.2023.02.16.13.31.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Feb 2023 13:31:50 -0800 (PST) Message-ID: Date: Thu, 16 Feb 2023 22:31:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Subject: Re: [PATCH v2 1/1] spl: allow loading via partition type GUID Content-Language: en-US To: Simon Glass Cc: Tom Rini , Yanhong Wang , Andrew Davis , Alper Nebi Yasak , Stefan Roese , Andre Przywara , =?UTF-8?B?SsOpcsO0bWUgQ2FycmV0ZXJv?= , Harald Seiler , u-boot@lists.denx.de References: <20230216152956.130038-1-heinrich.schuchardt@canonical.com> From: Heinrich Schuchardt In-Reply-To: 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/16/23 21:17, Simon Glass wrote: > Hi Heinrich, > > On Thu, 16 Feb 2023 at 08:30, Heinrich Schuchardt > wrote: >> >> Some boards provide main U-Boot as a dedicated partition to SPL. >> Currently we can define either a fixed partition number or an MBR >> partition type to define which partition is to be used. >> >> Partition numbers tend to conflict with established partitioning schemes >> of Linux distros. MBR partitioning is more and more replaced by GPT >> partitioning. >> >> Allow defining a partition type GUID identifying the partition to load >> main U-Boot from. >> >> Signed-off-by: Heinrich Schuchardt >> --- >> v2: >> avoid if/endif in Kconfig >> --- >> common/spl/Kconfig | 27 ++++++++++++++++++++++----- >> common/spl/spl_mmc.c | 13 +++++++++++++ >> 2 files changed, 35 insertions(+), 5 deletions(-) >> >> diff --git a/common/spl/Kconfig b/common/spl/Kconfig >> index 3c2af453ab..9d12b48297 100644 >> --- a/common/spl/Kconfig >> +++ b/common/spl/Kconfig >> @@ -514,19 +514,36 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION >> used in raw mode >> >> config SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE >> - bool "MMC raw mode: by partition type" >> + bool "MMC raw mode: by MBR partition type" >> depends on DOS_PARTITION && SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION >> help >> - Use partition type for specifying U-Boot partition on MMC/SD in >> + Use MBR partition type for specifying U-Boot partition on MMC/SD in >> raw mode. U-Boot will be loaded from the first partition of this >> type to be found. >> >> config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE >> - hex "Partition Type on the MMC to load U-Boot from" >> + hex "MBR Partition Type on the MMC to load U-Boot from" >> depends on SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE >> help >> - Partition Type on the MMC to load U-Boot from, when the MMC is being >> - used in raw mode. >> + MBR Partition Type on the MMC to load U-Boot from, when the MMC is >> + being used in raw mode. >> + >> +config SYS_MMCSD_RAW_MODE_U_BOOT_USE_GPT_PARTITION_TYPE >> + bool "MMC raw mode: GPT by partition type" >> + depends on PARTITION_TYPE_GUID && SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION >> + help >> + Use GPT partition type for specifying U-Boot partition on MMC/SD in >> + raw mode. U-Boot will be loaded from the first partition of this >> + type to be found. >> + >> +config SYS_MMCSD_RAW_MODE_U_BOOT_GPT_PARTITION_TYPE >> + string "GPT Partition Type on the MMC to load U-Boot from" >> + depends on SYS_MMCSD_RAW_MODE_U_BOOT_USE_GPT_PARTITION_TYPE >> + default d2f002f8-e4e7-4269-b8ac-3bb6fabeaff6 > > What is this? Can we have a register of these hideous things and call > them by name? > >> + help >> + GPT Partition Type on the MMC to load U-Boot from, when the MMC is >> + being used in raw mode. The GUID must be lower case, low endian, >> + and formatted like d2f002f8-e4e7-4269-b8ac-3bb6fabeaff6. >> >> config SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG >> bool "Override eMMC EXT_CSC_PART_CONFIG by user defined partition" >> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c >> index e4135b2048..69bf1d6e98 100644 >> --- a/common/spl/spl_mmc.c >> +++ b/common/spl/spl_mmc.c >> @@ -191,6 +191,19 @@ static int mmc_load_image_raw_partition(struct spl_image_info *spl_image, >> struct disk_partition info; >> int err; >> >> +#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_GPT_PARTITION_TYPE >> + for (int i = 1; i <= MAX_SEARCH_PARTITIONS; ++i) { >> + err = part_get_info(mmc_get_blk_desc(mmc), i, &info); >> + if (err) >> + continue; >> + if (!strncmp(info.type_guid, >> + CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_GPT_PARTITION_TYPE, >> + UUID_STR_LEN)) { >> + partition = i; >> + break; >> + } >> + } >> +#endif >> #ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE >> int type_part; >> /* Only support MBR so DOS_ENTRY_NUMBERS */ >> -- >> 2.38.1 >> > > Is it possible to avoid using #ifdef here? Unfortunately not. Field 'type_guid' is restricted by an #ifdef. So unconditional compilation would fail. > > Longer term, I wonder if we can add a DT schema for all of > this...these CONFIG options for boot selection seem to be getting out > of hand! Tom just moved a lot of constants hard coded in C code to Kconfig with a big effort. Now you want to move Kconfig values to hard coded constants in device-tree. Running in circles does not sound like a winning strategy. Best regards Heinrich > > Regards, > Simon