| Message ID | 20240531153635.246154-1-tharvey@gateworks.com |
|---|---|
| Headers | show |
| Series | provide names for emmc hardware partitions | expand |
On Fri, May 31, 2024 at 8:36 AM Tim Harvey <tharvey@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
Hello Tim, On 2024-07-02 20:14, Tim Harvey wrote: > On Fri, May 31, 2024 at 8:36 AM Tim Harvey <tharvey@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.
On Tue, Jul 2, 2024 at 11:25 AM Dragan Simic <dsimic@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@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
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@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.
On Tue, Jul 2, 2024 at 12:23 PM Tom Rini <trini@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@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
On Mon, Aug 12, 2024 at 12:25 PM Tim Harvey <tharvey@gateworks.com> wrote: > > On Tue, Jul 2, 2024 at 12:23 PM Tom Rini <trini@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@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. Best Regards, Tim
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@gateworks.com> wrote: > > > > On Tue, Jul 2, 2024 at 12:23 PM Tom Rini <trini@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@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.
On Fri, 31 May 2024 08:36:32 -0700, Tim Harvey 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 > > [...] Applied to u-boot/next, thanks!