Hi,
On Thu, 28 Oct 2021 at 04:47, Heinrich Schuchardt <xypron.g...@gmx.de> wrote:
>
>
>
> On 10/28/21 10:52, AKASHI Takahiro wrote:
> > Hi Simon,
> >
> > I'd like to resume this discussion.
> >
> > On Thu, Oct 14, 2021 at 02:55:36PM -0600, Simon Glass wrote:
> >> Hi Takahiro,
> >>
> >> On Thu, 14 Oct 2021 at 02:03, AKASHI Takahiro
> >> <takahiro.aka...@linaro.org> wrote:
> >>>
> >>> Simon,
> >>>
> >>> On Wed, Oct 13, 2021 at 12:05:58PM -0600, Simon Glass wrote:
> >>>> Hi Takahiro,
> >>>>
> >>>> On Tue, 12 Oct 2021 at 19:32, AKASHI Takahiro
> >>>> <takahiro.aka...@linaro.org> wrote:
> >>>>>
> >>>>> On Tue, Oct 12, 2021 at 11:14:17AM -0400, Tom Rini wrote:
> >>>>>> On Mon, Oct 11, 2021 at 10:14:00AM -0600, Simon Glass wrote:
> >>>>>>> Hi Heinrich,
> >>>>>>>
> >>>>>>> On Mon, 11 Oct 2021 at 09:02, Heinrich Schuchardt
> >>>>>>> <xypron.g...@gmx.de> wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 10/11/21 16:54, Simon Glass wrote:
> >>>>>>>>> Hi Takahiro,
> >>>>>>>>>
> >>>>>>>>> On Sun, 10 Oct 2021 at 20:29, AKASHI Takahiro
> >>>>>>>>> <takahiro.aka...@linaro.org> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Heinrich,
> >>>>>>>>>>
> >>>>>>>>>> On Fri, Oct 08, 2021 at 10:23:52AM +0200, Heinrich Schuchardt
> >>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On 10/8/21 02:51, AKASHI Takahiro wrote:
> >>>>>>>>>>>> On Mon, Oct 04, 2021 at 12:27:59PM +0900, AKASHI Takahiro wrote:
> >>>>>>>>>>>>> On Fri, Oct 01, 2021 at 11:30:37AM +0200, Heinrich Schuchardt
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 10/1/21 07:01, AKASHI Takahiro wrote:
> >>>>>>>>>>>>>>> UCLASS_PARTITION device will be created as a child node of
> >>>>>>>>>>>>>>> UCLASS_BLK device.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Signed-off-by: AKASHI Takahiro <takahiro.aka...@linaro.org>
> >>>>>>>>>>>>>>> ---
> >>>>>>>>>>>>>>> drivers/block/blk-uclass.c | 111
> >>>>>>>>>>>>>>> +++++++++++++++++++++++++++++++++++++
> >>>>>>>>>>>>>>> include/blk.h | 9 +++
> >>>>>>>>>>>>>>> include/dm/uclass-id.h | 1 +
> >>>>>>>>>>>>>>> 3 files changed, 121 insertions(+)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> diff --git a/drivers/block/blk-uclass.c
> >>>>>>>>>>>>>>> b/drivers/block/blk-uclass.c
> >>>>>>>>>>>>>>> index 83682dcc181a..dd7f3c0fe31e 100644
> >>>>>>>>>>>>>>> --- a/drivers/block/blk-uclass.c
> >>>>>>>>>>>>>>> +++ b/drivers/block/blk-uclass.c
> >>>>>>>>>>>>>>> @@ -12,6 +12,7 @@
> >>>>>>>>>>>>>>> #include <log.h>
> >>>>>>>>>>>>>>> #include <malloc.h>
> >>>>>>>>>>>>>>> #include <part.h>
> >>>>>>>>>>>>>>> +#include <string.h>
> >>>>>>>>>>>>>>> #include <dm/device-internal.h>
> >>>>>>>>>>>>>>> #include <dm/lists.h>
> >>>>>>>>>>>>>>> #include <dm/uclass-internal.h>
> >>>>>>>>>>>>>>> @@ -695,6 +696,44 @@ int blk_unbind_all(int if_type)
> >>>>>>>>>>>>>>> return 0;
> >>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> +int blk_create_partitions(struct udevice *parent)
> >>>>>>>>>>>>>>> +{
> >>>>>>>>>>>>>>> + int part, count;
> >>>>>>>>>>>>>>> + struct blk_desc *desc = dev_get_uclass_plat(parent);
> >>>>>>>>>>>>>>> + struct disk_partition info;
> >>>>>>>>>>>>>>> + struct disk_part *part_data;
> >>>>>>>>>>>>>>> + char devname[32];
> >>>>>>>>>>>>>>> + struct udevice *dev;
> >>>>>>>>>>>>>>> + int ret;
> >>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>> + if (!CONFIG_IS_ENABLED(PARTITIONS) ||
> >>>>>>>>>>>>>>> + !CONFIG_IS_ENABLED(HAVE_BLOCK_DEVICE))
> >>>>>>>>>>>>>>> + return 0;
> >>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>> + /* Add devices for each partition */
> >>>>>>>>>>>>>>> + for (count = 0, part = 1; part <=
> >>>>>>>>>>>>>>> MAX_SEARCH_PARTITIONS; part++) {
> >>>>>>>>>>>>>>> + if (part_get_info(desc, part, &info))
> >>>>>>>>>>>>>>> + continue;
> >>>>>>>>>>>>>>> + snprintf(devname, sizeof(devname), "%s:%d",
> >>>>>>>>>>>>>>> parent->name,
> >>>>>>>>>>>>>>> + part);
> >>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>> + ret = device_bind_driver(parent,
> >>>>>>>>>>>>>>> "blk_partition",
> >>>>>>>>>>>>>>> + strdup(devname), &dev);
> >>>>>>>>>>>>>>> + if (ret)
> >>>>>>>>>>>>>>> + return ret;
> >>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>> + part_data = dev_get_uclass_plat(dev);
> >>>>>>>>>>>>>>> + part_data->partnum = part;
> >>>>>>>>>>>>>>> + part_data->gpt_part_info = info;
> >>>>>>>>>>>>>>> + count++;
> >>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>> + device_probe(dev);
> >>>>>>>>>>>>>>> + }
> >>>>>>>>>>>>>>> + debug("%s: %d partitions found in %s\n", __func__,
> >>>>>>>>>>>>>>> count, parent->name);
> >>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>> + return 0;
> >>>>>>>>>>>>>>> +}
> >>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>> static int blk_post_probe(struct udevice *dev)
> >>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>> if (IS_ENABLED(CONFIG_PARTITIONS) &&
> >>>>>>>>>>>>>>> @@ -713,3 +752,75 @@ UCLASS_DRIVER(blk) = {
> >>>>>>>>>>>>>>> .post_probe = blk_post_probe,
> >>>>>>>>>>>>>>> .per_device_plat_auto = sizeof(struct blk_desc),
> >>>>>>>>>>>>>>> };
> >>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>> +static ulong blk_part_read(struct udevice *dev, lbaint_t
> >>>>>>>>>>>>>>> start,
> >>>>>>>>>>>>>>> + lbaint_t blkcnt, void *buffer)
> >>>>>>>>>>>>>>> +{
> >>>>>>>>>>>>>>> + struct udevice *parent;
> >>>>>>>>>>>>>>> + struct disk_part *part;
> >>>>>>>>>>>>>>> + const struct blk_ops *ops;
> >>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>> + parent = dev_get_parent(dev);
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> What device type will the parent have if it is a eMMC hardware
> >>>>>>>>>>>>>> partition?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> + ops = blk_get_ops(parent);
> >>>>>>>>>>>>>>> + if (!ops->read)
> >>>>>>>>>>>>>>> + return -ENOSYS;
> >>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>> + part = dev_get_uclass_plat(dev);
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> You should check that we do not access the block device past
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>> partition end:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Yes, I will fix all of checks.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> struct blk_desc *desc = dev_get_uclass_plat(parent);
> >>>>>>>>>>>>>> if ((start + blkcnt) * desc->blksz < part->gpt_part_info.blksz)
> >>>>>>>>>>>>>> return -EFAULT.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> + start += part->gpt_part_info.start;
> >>>>>>>>>>>>
> >>>>>>>>>>>> A better solution is:
> >>>>>>>>>>>> if (start >= part->gpt_part_info.size)
> >>>>>>>>>>>> return 0;
> >>>>>>>>>>>>
> >>>>>>>>>>>> if ((start + blkcnt) > part->gpt_part_info.size)
> >>>>>>>>>>>> blkcnt = part->gpt_part_info.size - start;
> >>>>>>>>>>>> start += part->gpt_part_info.start;
> >>>>>>>>>>>> instead of returning -EFAULT.
> >>>>>>>>>>>> (note that start and blkcnt are in "block".)
> >>>>>>>>>>>
> >>>>>>>>>>> What is your motivation to support an illegal access?
> >>>>>>>>>>>
> >>>>>>>>>>> We will implement the EFI_BLOCK_IO_PROTOCOL based on this
> >>>>>>>>>>> function. The
> >>>>>>>>>>> ReadBlocks() and WriteBlocks() services must return
> >>>>>>>>>>> EFI_INVALID_PARAMETER if the read request contains LBAs that are
> >>>>>>>>>>> not
> >>>>>>>>>>> valid.
> >>>>>>>>>>
> >>>>>>>>>> I interpreted that 'LBA' was the third parameter to ReadBlocks API,
> >>>>>>>>>> and that if the starting block is out of partition region, we
> >>>>>>>>>> should
> >>>>>>>>>> return an error (and if not, we still want to trim IO request to
> >>>>>>>>>> fit
> >>>>>>>>>> into partition size as other OS's API like linux does).
> >>>>>>>>>> Do you think it's incorrect?
> >>>>>>>>>
> >>>>>>>>> [..]
> >>>>>>>>>
> >>>>>>>>> Related to this patch I think that the partition type should be
> >>>>>>>>> really
> >>>>>>>>> be a child of the media device:
> >>>>>>>>>
> >>>>>>>>> - MMC
> >>>>>>>>> |- BLK
> >>>>>>>>> |- PARTITION
> >>>>>>>>> |- BLK
> >>>>>>>>> |- PARTITION
> >>>>>>>>> |- BLK
> >>>>>>>>> |- PARTITION
> >>>>>>>>> |- BLK
> >>>>>>>>>
> >>>>>>>>> It seems more natural to me that putting the partitions under the
> >>>>>>>>> top-level BLK device, so that BLK remains a 'terminal' device.
> >>>>>>>>>
> >>>>>>>>> The partition uclass is different from BLK, of course. It could
> >>>>>>>>> contain information about the partition such as its partition number
> >>>>>>>>> and UUID.
> >>>>>>>>
> >>>>>>>> Do you mean hardware partition here? Otherwise I would not know what
> >>>>>>>> BLK
> >>>>>>>> should model.
> >>>>>>>
> >>>>>>> I mean that (I think) we should not use BLK to model partitions. A BLK
> >>>>>>> should just be a block device.
> >>>>>>>
> >>>>>>> I don't see any difference between a partition and a hardware
> >>>>>>> partition. We presumably end up with a hierarchy though. Do we need a
> >>>>>>> HWPARTITION uclass so we can handle the hardware partitions
> >>>>>>> differently?
> >>>>>>
> >>>>>> Note that for eMMC devices, hardware partitions are different from
> >>>>>> partition-table partitions. If you boot a system with an eMMC device
> >>>>>> up
> >>>>>> in Linux you typically get mmcblkN, mmcblkNboot0, mmcblkNboot1 and
> >>>>>> mmcblkNrpmb, each of which are hardware partitions. It gets tricky in
> >>>>>> U-Boot in that you can access each of these with 'mmc dev N M' where M
> >>>>>> defaults to 0 and is the user partition (mmcblkN), 1/2 are boot0/boot1
> >>>>>> and 3 is the rpmb area. The 'mmc' command also allows, when possible
> >>>>>> and implemented, configuring these partitions, again to the extent
> >>>>>> allowed, documented and implemented.
> >>>>>
> >>>>> Thank you. That is exactly what I tried to mention in my reply
> >>>>> at "part: call part_init() in blk_get_device_by_str() only for MMC"
> >>>>
> >>>> OK so it sounds like we agree that hwpartition and partition are
> >>>> different things.
> >>>
> >>> Yes.
> >>> Please note, IIUC, that
> >>> * MMC hw partitions on a device are mapped to one udevice, differentiating
> >>> them by blk_desc->hwpart.
> >>> * Each NVME namespace on a device is mapped to a different udevice with
> >>> a different blk_desc->devnum (and nvme_dev->ns_id).
> >>> * Each UFS partition (or which is, I suppose, equivalent to scsi LUN) on
> >>> a device is mapped to a different udevice with a different
> >>> blk_desc->devnum
> >>> (and blk_desc->lun).
> >>>
> >>> So even though those type of devices have some kind of hardware
> >>> partitions,
> >>> they are modelled differently in U-Boot.
> >>> (Obviously, I might be wrong here as I'm not quite familiar yet.)
> >>>
> >>>>>
> >>>>> ---8<---
> >>>>> # On the other hand, we have to explicitly switch "hw partitions"
> >>>>> # with blk_select_hwpart_devnum() on MMC devices even though we use
> >>>>> # the *same* udevice(blk_desc).
> >>>>> --->8---
> >>>>>
> >>>>> The problem with the current U-Boot driver model is that all of
> >>>>> "mmcblkN,
> >>>>> mmcblkNboot0, mmcblkNboot1 and mmcblkNrpmb" will be linked to the same
> >>>>> udevice. We have to do "mmc dev N M" or call
> >>>>> blk_select_hwpart[_devnum]()
> >>>>> to distinguish them.
> >>>>
> >>>> Here's our chance to rethink this. What should the device hierarchy be
> >>>> for an MMC device? I made a proposal further up the thread.
> >>>
> >>> Well,
> >>>
> >>> On Mon, Oct 11, 2021 at 11:41:02AM -0600, Simon Glass wrote:
> >>>> On Mon, 11 Oct 2021 at 10:53, Heinrich Schuchardt <xypron.g...@gmx.de>
> >>>> wrote:
> >>>
> >>>>>>>> [..]
> >>>
> >>>>>>>> Related to this patch I think that the partition type should be
> >>>>>>>> really
> >>>>>>>> be a child of the media device:
> >>>>>>>>
> >>>>>>>> - MMC
> >>>>>>>> |- BLK
> >>>>>>>> |- PARTITION
> >>>>>>>> |- BLK
> >>>>>>>> |- PARTITION
> >>>>>>>> |- BLK
> >>>>>>>> |- PARTITION
> >>>>>>>> |- BLK
> >>>>>>>>
> >>>>>>>> It seems more natural to me that putting the partitions under the
> >>>>>>>> top-level BLK device, so that BLK remains a 'terminal' device.
> >>>>>>>>
> >>>>>>>> The partition uclass is different from BLK, of course. It could
> >>>>>>>> contain information about the partition such as its partition number
> >>>>>>>> and UUID.
> >>>
> >>> Yeah, but there is always 1-to-1 mapping between a partition and
> >>> a block (for a partition), so I still wonder whether it makes sense
> >>> to model partitions in the way above.
> >>>
> >>> Alternatively, the following hierarchy also makes some sense.
> >>> (This is not what I have in my RFC though.)
> >>> - MMC
> >>> |- BLK (whole disk with part=0)
> >>> |- BLK (partition 1)
> >>> |- BLK (partition 2)
> >>> |- BLK (partition 3)
> >>>
> >>> or
> >>>
> >>> - MMC
> >>> |- DISK (whole disk)
> >>> ||- BLK (partition 0)
> >>> ||- BLK (partition 1)
> >>> ||- BLK (partition 2)
> >>> ||- BLK (partition 3)
> >>>
> >>> Here
> >>> MMC: provides read/write operations (via blk_ops)
> >>> DISK: holds a geometry of a whole disk and other info
> >>> BLK: partition info (+ blk_ops + geo) (part=0 means a while disk)
> >>
> >> Where does this leave hwpart? Are we giving up on that?
> >
> > No, not at all :)
> > I'm thinking of dealing with hw partitions as independent BLK devices.
> > This is already true for NVME (namespaces) and UFS (LUNs)(not sure, though).
> > For MMC, struct blk_desc has 'hwpart' field to indicate a hw partition and
> > Apparently, it will be easy to have different BLK devices with
> > different hwpart's.
> > (Then we will have to add a probe function for hw partitions.)
> >
> >> Both of these make some sense to me, although I'm not sure what the
> >> second one buys us. Can you explain that? Is it to deal with hwpart?
> >
> > So,
> >
> > - MMC (bus controller)
> > |- BLK (device/hw partition:user data)
> > ||- DISK (partition 0 == a whole device)
> > ||- DISK (partition 1)
> > ||- DISK (partition 2)
> > ||- DISK (partition 3)
> > |- BLK (device/hw partition:boot0)
> > ||- DISK (partition 0 == a whole device)
> > |- BLK (device/hw partition:boot0)
> > ||- DISK (partition 0 == a whole device)
> > |- BLK (device/hw partition:rpmb) -- this is NOT a 'block' device, though.
> > ||- DISK (partition 0 == a whole device)
> >
> > MMC: provides access methods (via blk_ops)
> > BLK: represents a physical device and holds a geometry of the whole
> > device and other info
> > DISK: block-access entities with partition info
> > (part=0 means a while disk)
> >
> > (MMC, BLK are of current implementation.)
I agree with Heinrich that we are better to leave BLK as it is, both
in name and meaning. I think maybe I am missing the gist of your
argument.
If we use UCLASS_PART, for example, can we have that refer to both s/w
and h/w partitions, as Herinch seems to allude to below? What would
the picture look like the, and would it get us closer to agreement?
- Simon
>
> Could you, please, add the path from the root, devices without hardware
> partitions (e.g. IDE, SATA), and devices with LUNs (SCSI) to the tree.
> Please, also add the device-tree nodes. This will allow us to see the
> whole picture, and observe how UEFI device paths and the DM tree are
> matched.
>
> >
> > To avoid confusion, UCLASS_PARTITION is renamed to UCLASS_DISK with
> > a little modified semantics. The name can be seen aligned with 'disk/'
>
> Renaming UCLASS_PARTITION to UCLASS_DISK is very confusing. A disk to me
> is a block device which may have partitions.
>
> > directory for sw partitions.
> > Partition 0 expectedly behaves in the same way as an existing BLK.
>
> It will expose block IO and it may expose a file system.
> The same is valid for the true partitions.
>
> A block device does not expose a file system.
>
> So partition 0 just behaves at it always did in U-Boot.
>
>
> >
> > With this scheme, I assume that we should thoroughly use new interfaces
> > dev_read(struct udevice *dev, lbaint_t start,
> > lbaint_t blkcnt, void *buffer);
> > dev_write(struct udevice *dev, lbaint_t start,
> > lbaint_t blkcnt, void *buffer);
> > for block-level operations with DISK devices.
> > ^^^^
> >
> > The legacy interfaces with blk_desc's in BLK devices:
> > blk_dread(struct blk_desc *block_dev, lbaint_t start,
> > lbaint_t blkcnt, void *buffer)
> > blk_dwrite(struct blk_desc *block_dev, lbaint_t start,
> > lbaint_t blkcnt, void *buffer)l
> > are to be retained, at least, during the transition period
> > (mostly for existing filesystems and commands).
> >
> >> The name 'disk' is pretty awful though, these days.
> >
> > Think so?
> > Honestly, I'd like to rename BLK to DISK (or BLK_MEDIA) and
> > rename DISK to BLK to reflect their rolls :)
>
> Block devices are not necessarily disks. Think of a tape device for
> instance or a RAM based block device. So renaming BLK to DISK is confusing.
>
> >
> >> If we want to iterate through all the partition tables across all
> >> devices, we could do that with a partition uclass. We could support
> >> different types of partition (s/w and h/w) with the same device
> >> driver.
>
> Why? You can simply traverse the list of udevices of type SW_PARTITION.
> There is not need to walk the tree.
>
> In the tree above you made them HW and SW partions different uclasses.
> For each uclass create a separate driver.
>
> Best regards
>
> Heinrich
>
> >>
> >> I think conceptually it is cleaner to have a partition uclass but I do
> >> agree that it corresponds 100% to BLK, so maybe there is little value
> >> in practice. But which device holds the partition table in its
> >> dev_get_priv()?
> >
> > Do you think that some device should have "partition table" info
> > in its inner data structure of udevice?
> > BLK-DISK relationship can represent a partition table in some way,
> > and MMC-BLK can model hw partitioning.
> >
> > Thanks,
> > -Takahiro Akashi
> >
> >>>
> >>>>>>> Do you mean hardware partition here? Otherwise I would not know what
> >>>>>>> BLK
> >>>>>>> should model.
> >>>>>>
> >>>>>> I mean that (I think) we should not use BLK to model partitions. A BLK
> >>>>>> should just be a block device.
> >>>>>
> >>>>> That is fine. But this implies that a software partition is the child of
> >>>>> a block partition and not the other way round. So the tree should like:
> >>>>>
> >>>>> MMC
> >>>>> |- BLK (user hardware partition)
> >>>>> ||- PARTITION 1 (software partition)
> >>>>> ||- PARTITION 2 (software partition)
> >>>>> |...
> >>>>> ||- PARTITION n (software partition)
> >>>>> |- BLK (rpmb hardware partition)
> >>>>> |- BLK (boot0 hardware partition)
> >>>>> |- BLK (boot1 hardware partition)
> >>>>
> >>>> I presume you meant to include a BLK device under each PARTITION?
> >>>>
> >>>> But anyway, I was more thinking of this:
> >>>>
> >>>> MMC
> >>>> | HWPARTITION rpmb
> >>>> || BLK whole rpmb
> >>>> || PARTITION 1
> >>>> ||| BLK
> >>>> || PARTITION 2
> >>>> ||| BLK
> >>>> || PARTITION 3
> >>>
> >>> Do we have any reason to model a RPMB partition as a block device?
> >>> For linux, at least, mmcblkrpmb looks to be a character device.
> >>>
> >>>> ||| BLK
> >>>> | HWPARTITION boot0
> >>>> || BLK
> >>>> (maybe have PARTITION in here too?
> >>>
> >>> I don't know how boot partitions are used on a production system.
> >>> It's unlikely to have partitions on them given the purpose of "boot"
> >>> partitions?
> >>
> >> That's true. So likely they will not be used.
> >>
> >>>
> >>>> | HWPARTITION boot1
> >>>> (maybe have PARTITION in here too?
> >>>> || BLK
> >>>>
> >>>>>
> >>>>>>
> >>>>>> I don't see any difference between a partition and a hardware
> >>>>>> partition. We presumably end up with a hierarchy though. Do we need a
> >>>>>> HWPARTITION uclass so we can handle the hardware partitions
> >>>>>> differently?
> >>>>>
> >>>>> Software partitions are defined and discovered via partition tables.
> >>>>> Hardware partitions are defined in a hardware specific way.
> >>>>>
> >>>>> All software partitions map to HD() device tree nodes in UEFI.
> >>>>> An MMC device maps to an eMMC() node
> >>>>> MMC hardware partitions are mapped to Ctrl() nodes by EDK II. We should
> >>>>> do the same in U-Boot.
> >>>>> An SD-card maps to an SD() node.
> >>>>> An NVMe namespace maps to a NVMe() node.
> >>>>> An SCSI LUN maps to a Scsi() node.
> >>>>> SCSI channels of multiple channel controllers are mapped to Ctrl()
> >>>>> nodes.
> >>>>
> >>>> I'm not quite sure about the terminology here. I'm not even talking
> >>>> about UEFI, really, just how best to model this stuff in U-Boot.
> >>>
> >>> In UEFI world, each efi_disk has its own device path to identify the
> >>> device.
> >>> For example, here is a text representation of device path for a scsi disk
> >>> partition:
> >>>
> >>> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(0,0)/HD(1,GPT,ce86c5a7-b32a-488f-a346-88fe698e0edc,0x22,0x4c2a)
> >>>
> >>> which is set to be created from a corresponding udevice (more strictly
> >>> blkc_desc + part).
> >>>
> >>> So the issue Heinrich raised here is a matter of implementation of
> >>> this conversion (software partitions, and SCSI channels?) as well as
> >>> a modeling for some device type on U-Boot, i.e. MMC hardware partitions.
> >>
> >> Yes I see that. It's just that we should get our house in order first,
> >> since these discussions didn't happen when the EFI layer was written 6
> >> years ago. If we have a good model for partitions (not just block
> >> devices) in U-Boot then it should be easier to map EFI onto it.
> >>
> >> Regards,
> >> Simon
> >>
> >>
> >>>
> >>> -Takahiro Akashi
> >>>
> >>>> In U-Boot, UCLASS_SCSI should be a SCSI controller, not a device,
> >>>> right? I'm a little worried it is not modelled correctly. After all,
> >>>> what is the parent of a SCSI device?
> >>>>
> >>>>>
> >>>>> The simple file protocol is only provided by HD() nodes and not by nodes
> >>>>> representing hardware partitions. If the whole hardware partition is
> >>>>> formatted as a file system you would still create a HD() node with
> >>>>> partition number 0.
> >>>>
> >>>> Regards,
> >>>> Simon
> >>> ---
> >>>>
> >>>>>
> >>>>> When it comes to UEFI, I hope we can currently support hw partitions
> >>>>> in this way:
> >>>>> => efidebug add boot -b 1 FOO mmc 0.1 /foo.bin ""
> >>>>> (".1" is a key, I have never tried this syntax though.)
> >>>>>
> >>>>> But probably its device path won't be properly formatted
> >>>>> as expected as Heinrich suggested.
> >>>>>
> >>>>> -Takahiro Akashi
> >>>>>
> >>>>>
> >>>>>> In terms of modeling, this is akin to how if you use a USB card reader
> >>>>>> that supports 4 different form-factor cards, you can end up with 4
> >>>>>> different devices showing up in Linux (if you have one of the nice card
> >>>>>> readers that supports multiple cards at once).
> >>>>>>
> >>>>>> --
> >>>>>> Tom
> >>>>>
> >>>>>
> >>>>
> >>>> Regards,
> >>>> Simon
