On Fri, May 31, 2024 at 8:36 AM Tim Harvey <thar...@gateworks.com> wrote: > > Modern eMMC v4+ devices have multiple hardware partitions per the JEDEC > specification described as: > Boot Area Partition 1 > Boot Area Partition 2 > RPMB Partition > General Purpose Partition 1 > General Purpose Partition 2 > General Purpose Partition 3 > General Purpose Partition 4 > User Data Area > > These are referenced by fields in the PARTITION_CONFIG register > (Extended CSD Register 179) which is defined as: > bit 7: reserved > bit 6: BOOT_ACK > 0x0: No boot acknowledge sent (default > 0x1: Boot acknowledge sent during boot operation Bit > bit 5:3: BOOT_PARTITION_ENABLE > 0x0: Device not boot enabled (default) > 0x1: Boot Area partition 1 enabled for boot > 0x2: Boot Area partition 2 enabled for boot > 0x3-0x6: Reserved > 0x7: User area enabled for boot > bit 2:0 PARTITION_ACCESS > 0x0: No access to boot partition (default) > 0x1: Boot Area partition 1 > 0x2: Boot Area partition 2 > 0x3: Replay Protected Memory Block (RPMB) > 0x4: Access to General Purpose partition 1 > 0x5: Access to General Purpose partition 2 > 0x6: Access to General Purpose partition 3 > 0x7: Access to General Purpose partition 4 > > Note that setting PARTITION_ACCESS to 0x0 results in selecting the User > Data Area partition. > > You can see above that the two fields BOOT_PARTITION_ENABLE and > PARTITION_ACCESS do not use the same enumerated values. > > U-Boot uses a set of macros to access fields of the PARTITION_CONFIG > register: > EXT_CSD_BOOT_ACK_ENABLE (1 << 6) > EXT_CSD_BOOT_PARTITION_ENABLE (1 << 3) > EXT_CSD_PARTITION_ACCESS_ENABLE (1 << 0) > EXT_CSD_PARTITION_ACCESS_DISABLE (0 << 0) > > EXT_CSD_BOOT_ACK(x) (x << 6) > EXT_CSD_BOOT_PART_NUM(x) (x << 3) > EXT_CSD_PARTITION_ACCESS(x) (x << 0) > > EXT_CSD_EXTRACT_BOOT_ACK(x) (((x) >> 6) & 0x1) > EXT_CSD_EXTRACT_BOOT_PART(x) (((x) >> 3) & 0x7) > EXT_CSD_EXTRACT_PARTITION_ACCESS(x) ((x) & 0x7) > > There are various places in U-Boot where the BOOT_PARTITION_ENABLE field > is accessed via EXT_CSD_EXTRACT_PARTITION_ACCESS and converted to a > hardware partition consistent with the definition of the > PARTITION_ACCESS field used by the various mmc_switch incarnations. > > To add some sanity to the distinction between BOOT_PARTITION_ENABLE > (used to specify the active device on power-cycle) and PARTITION_ACCESS > (used to switch between hardware partitions) create two enumerated types > and use them wherever struct mmc * part_config is used or the above > macros are used. > > Additionally provide arrays of the field names and allow those to be > used in the 'mmc partconf' command and in board support files. > > The first patch adds enumerated types and makes use of them which > represents no compiled code change. > > The 2nd patch adds the array of names and uses them in the 'mmc > partconf' command. > > The 3rd patch uses the array of hardware partition names in a board > support file to show what emmc hardware partition U-Boot is being loaded > from. > > I'm sending this as a series this time around as previously it was > repsented as two different patches. > > Tim Harvey (3): > mmc: use an enumerated type to represent PARTITION_CONFIG fields > mmc: allow use of hardware partition names for mmc partconf > venice: show emmc boot hardware partition > > arch/arm/mach-imx/image-container.c | 10 ++++----- > arch/arm/mach-sunxi/board.c | 2 +- > board/gateworks/venice/spl.c | 20 ++++++++++++----- > board/gateworks/venice/venice.c | 22 +++++++++--------- > board/purism/librem5/librem5.c | 4 ++-- > board/storopack/smegw01/smegw01.c | 4 ++-- > cmd/mmc.c | 27 ++++++++++++++++++---- > cmd/mvebu/bubt.c | 4 ++-- > common/spl/spl_mmc.c | 4 ++-- > drivers/mmc/mmc.c | 35 +++++++++++++++++++++++++++++ > include/mmc.h | 26 +++++++++++++++++++++ > 11 files changed, 123 insertions(+), 35 deletions(-) > > -- > 2.25.1 >
Greetings, Is there any feedback on this series? I got feedback from several people on my first attempt (cc'd) but nothing on this version. Best Regards, Tim
