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 takahiro.akashi@linaro.org
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: