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

[Tim Harvey]

On Tue, Jul 2, 2024 at 12:23 PM Tom Rini <trini at konsulko.com> wrote:
>
> On Tue, Jul 02, 2024 at 11:14:15AM -0700, 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(-)
> > >
> > > --
> > > 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.
>
> Jaehoon, will you have time to review and pick this up, now that the
> merge window is open? Thanks.
>

Hi Tom,

I have not seen any emails from Jaehoon on mainline lists since early May.

Best Regards,

Tim