[RESEND PATCH v4 0/3] provide names for emmc hardware partitions

Tue Jul 2 21:02:18 CEST 2024

On Tue, Jul 2, 2024 at 11:25 AM Dragan Simic <dsimic at manjaro.org> wrote:
>
> Hello Tim,
>
> On 2024-07-02 20:14, Tim Harvey wrote:
> > On Fri, May 31, 2024 at 8:36 AM Tim Harvey <tharvey at 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(-)
> >
> > Is there any feedback on this series? I got feedback from several
> > people on my first attempt (cc'd) but nothing on this version.
>
> Any chances, please, to provide links to each of the patch and series
> versions on https://lore.kernel.org/u-boot/ , together with a brief
> changelog and history?  I'm having troubles refreshing my memory on
> what patches were actually pulled into what series.
>
> My guess is that other people would also benefit from such a refresher.

Hi Dragan,

Yes, I should have done that. Here are the references:
- latest v4 series:
https://patchwork.ozlabs.org/project/uboot/list/?series=409052
(combined two patches into series)
- v3: https://patchwork.ozlabs.org/project/uboot/patch/20240427001157.1460302-1-tharvey@gateworks.com/
- v2: https://patchwork.ozlabs.org/project/uboot/patch/20240426171205.1382212-1-tharvey@gateworks.com/
- v1: https://patchwork.ozlabs.org/project/uboot/patch/20240426001419.1210364-1-tharvey@gateworks.com/
- https://patchwork.ozlabs.org/project/uboot/patch/20240426165554.1376497-1-tharvey@gateworks.com/
- display emmc hardware partition for venice

Best Regards,

Tim