[RESEND PATCH v4 0/3] provide names for emmc hardware partitions
Tom Rini
trini at konsulko.com
Thu Sep 5 20:14:34 CEST 2024
On Thu, Sep 05, 2024 at 11:11:10AM -0700, Tim Harvey wrote:
> On Mon, Aug 12, 2024 at 12:25 PM Tim Harvey <tharvey at gateworks.com> wrote:
> >
> > 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
>
> Hi Tom,
>
> gentle ping here... not sure what you want me to do with this series.
OK, thanks for pinging, again. I'm taking a look at taking this to -next
now. Sorry for the delay and thanks again for your patience and
persistence.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20240905/e7d30852/attachment.sig>
More information about the U-Boot
mailing list