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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3A6D0C433F5 for ; Mon, 4 Oct 2021 03:14:19 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 600D76124F for ; Mon, 4 Oct 2021 03:14:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 600D76124F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 65391834C5; Mon, 4 Oct 2021 05:14:16 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.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=linaro.org header.i=@linaro.org header.b="U5ujg99V"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 9D0C6834EC; Mon, 4 Oct 2021 05:14:14 +0200 (CEST) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 295BF834BF for ; Mon, 4 Oct 2021 05:14:06 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=takahiro.akashi@linaro.org Received: by mail-pj1-x1036.google.com with SMTP id k23-20020a17090a591700b001976d2db364so11106078pji.2 for ; Sun, 03 Oct 2021 20:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=XNRkpi/qyC4YO1qb3nwuiOa1PO4flwXqZXdRySJnwiY=; b=U5ujg99VR3oA+fU9sFXUU1aP3sZAnSH8t/K1Ie9GyZaijfLpSsik9ASvGgXB6O40f6 gHFO4uFWKz2f9T/XKVZnL0Kjy+yMgLl96FvHBWCU5ax47P/mv/2ZJKAsZQD0U767r8fA vhUB3kFQEaDXPGFjJhRRMCdMSlX1kwQY9IxPql+AT0Wo8iuFt0EDPne7cjrbgJZAfx4G 7/lKzfki88X1CJQ2MFt4wit7ciIA151CTEIqVvY5yD+9pQCQ0M5+53GzDkaNhBmjOvvv NuYEqGImRE4UA5tk3BB7+Ej4Pch9ULOfWjH+0vUhiYUgl04vW46UNCJUmZxKDmc//z2C 6nsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=XNRkpi/qyC4YO1qb3nwuiOa1PO4flwXqZXdRySJnwiY=; b=XfH55XQpZkLiO1B3s02kDWTvPxEuguYgVf08/rsOmPzV1kbnNmxYINjQeZW3Xj+xsY vCa08XYNNWuLRvAHN6aoo/deMBkWKIFiY6vTdGkies475HhWVz5EhcJdfBQ/ENf9A1+W 0RyrhXeSnP1jcSXrS/vrbH9XQAmfGOo7G93p4Zy7MjuTa9LHrG9sVzXvtcR/EiRZYKR1 Wh+N7cm80Bed0n0a5ufWdmP3GrrL54UQt+KTXOVInO9G47bMY4C7Zrj57anfQOB84ArR eWx/YRRZol5oTX0cYcBh9xBl/CIvUYGRTaZKOjxJB4y0gw2VlTquVa+74wpbJvyEqOR1 +00g== X-Gm-Message-State: AOAM530yWDZ7oB8FU0LcuemTZHYd1yM1GLxip4rmEbMQvd0DpIjyg9hV ACdLOLpGGy0l0hwVqgKNgM7cGA== X-Google-Smtp-Source: ABdhPJypwL6X4n688fb0dBO1yi/E5YLu0x9SMztc/suU3XWP+PclObXjsC/62+XsgqQZb0Wbe1j6nA== X-Received: by 2002:a17:902:7144:b0:13c:8d49:fc46 with SMTP id u4-20020a170902714400b0013c8d49fc46mr20857007plm.45.1633317244298; Sun, 03 Oct 2021 20:14:04 -0700 (PDT) Received: from laputa (61-205-96-147m5.grp4.mineo.jp. [61.205.96.147]) by smtp.gmail.com with ESMTPSA id t8sm13172139pjt.39.2021.10.03.20.14.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 Oct 2021 20:14:03 -0700 (PDT) Date: Mon, 4 Oct 2021 12:13:57 +0900 From: AKASHI Takahiro To: Heinrich Schuchardt Cc: u-boot@lists.denx.de, agraf@csgraf.de, sjg@chromium.org, ilias.apalodimas@linaro.org Subject: Re: [RFC 01/22] part: call part_init() in blk_get_device_by_str() only for MMC Message-ID: <20211004031357.GA39720@laputa> Mail-Followup-To: AKASHI Takahiro , Heinrich Schuchardt , u-boot@lists.denx.de, agraf@csgraf.de, sjg@chromium.org, ilias.apalodimas@linaro.org References: <20211001050228.55183-1-takahiro.akashi@linaro.org> <20211001050228.55183-2-takahiro.akashi@linaro.org> <5fcb7f04-a1e5-ed16-b785-e624a74e5e11@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5fcb7f04-a1e5-ed16-b785-e624a74e5e11@gmx.de> X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 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.2 at phobos.denx.de X-Virus-Status: Clean Heinrich, On Fri, Oct 01, 2021 at 08:41:52AM +0200, Heinrich Schuchardt wrote: > > > On 10/1/21 7:01 AM, AKASHI Takahiro wrote: > > In blk_get_device_by_str(), the comment says: "Updates the partition table > > for the specified hw partition." > > Since hw partition is supported only on MMC, it makes no sense to do so > > for other devices. > > > > Signed-off-by: AKASHI Takahiro > > --- > > disk/part.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/disk/part.c b/disk/part.c > > index a6a8f7052bd3..b330103a5bc0 100644 > > --- a/disk/part.c > > +++ b/disk/part.c > > @@ -427,7 +427,8 @@ int blk_get_device_by_str(const char *ifname, const char *dev_hwpart_str, > > * Always should be done, otherwise hw partition 0 will return stale > > * data after displaying a non-zero hw partition. > > */ > > - part_init(*dev_desc); > > + if ((*dev_desc)->if_type == IF_TYPE_MMC) > > + part_init(*dev_desc); > > For an eMMC the following logical levels exist: > > * device > * hardware partition > * software partition > > Linux might show the following: > > /dev/mmcblk0 - user data area > /dev/mmcblk0boot0 - boot hardware partition 0 > /dev/mmcblk0boot1 - boot hardware partition 1 > /dev/mmcblk0rpmb - replay protected memory block > > How are the different hardware partition modeled in the UEFI device path? > Should each hardware partition be a separate udevice? > > For NOR flash we also have an extra level: > > => setenv mtdparts > mtdparts=30bb0000.qspi:1m(U-Boot),512k(Env),512k(DTB),2m(User_FS),12m(Data_FS),4m(Factory_FS),34m(Ramdisk),10m(Linux) > => mtd > > device nor0 <30bb0000.qspi>, # parts = 8 > #: name size offset mask_flags > 0: U-Boot 0x00100000 0x00000000 0 > 1: Env 0x00080000 0x00100000 0 > 2: DTB 0x00080000 0x00180000 0 > 3: User_FS 0x00200000 0x00200000 0 > 4: Data_FS 0x00c00000 0x00400000 0 > 5: Factory_FS 0x00400000 0x01000000 0 > 6: Ramdisk 0x02200000 0x01400000 0 > 7: Linux 0x00a00000 0x03600000 0 > > active partition: nor0,0 - (U-Boot) 0x00100000 @ 0x00000000 > > Has part_info() to be called here too? What is the if_type? > What are the devicepaths for these partitions? You have good points. MMC's hw partitions and mtd's "environment variable-based" partitions are quite different from the rest of table-based software partitions in terms of U-Boot block device implementation. Both neither are handled by part_info() (under disk/* framework) nor have dedicated "if_type's". Even if we might have to address those issues at the end, I would like to keep them out of my scope for now as it requires a lot of extra work. # I wonder if we should support mtdparts partitions on U-Boot UEFI # as it is a quite U-Boot specific feature. -Takahiro Akashi > Best regards > > Heinrich > > > #endif > > > > cleanup: > >