u-boot.git/board/storopack, branch master

Kconfig: Move CONFIG_BOOTCOUNT_ALTBOOTCMD to Kconfig

2025-02-14T16:19:24+00:00

Add CONFIG_BOOTCOUNT_ALTBOOTCMD so the developer is able to add
custom altbootcmd via Kconfig when they enable BOOTCOUNT. With this now
in Kconfig, we need to move it from environment files / config.h files
and in to the defconfig file.

This was done by generating u-boot-initial-env for all platforms before
the Kconfig change, to extract altbootcmd values and then again after to
compare the result.

[trini: Perform migration to defconfigs, reword commit message]
Signed-off-by: Tom Rini

Merge patch series "provide names for emmc hardware partitions"

2024-09-05T18:13:24+00:00

Tim Harvey  says:

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.

mmc: use an enumerated type to represent PARTITION_CONFIG fields

2024-09-05T18:12:51+00:00

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:

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 which is also the value used to specify the
hardware partition of 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.

This represents no code changes.

Signed-off-by: Tim Harvey

Restore patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"

2024-05-20T19:35:03+00:00

As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.

Reported-by: Jonas Karlman 
Signed-off-by: Tom Rini

Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet""

2024-05-19T14:16:36+00:00

When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.

This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.

Reported-by: Jonas Karlman 
Signed-off-by: Tom Rini

board: storopack: Remove and add needed includes

2024-05-07T14:00:40+00:00

Remove  from this board vendor directory and when needed
add missing include files directly.

Signed-off-by: Tom Rini

smegw01: Remove misuse of CONFIG_ENV_IS_NOWHERE

2023-10-16T06:46:01+00:00

When using a list of writeable variables, the initial values come
from the built-in default environment since commit 5ab81058364b ("env:
Complete generic support for writable list").

Remove unnecessary misuse of CONFIG_ENV_IS_NOWHERE as default environment.

Based on the fix done by commit b16fd7f75f6d ("imx6q: acc: Remove misuse
of env is nowhere driver").

Signed-off-by: Eduard Strehlau 
Signed-off-by: Fabio Estevam

smegw01: Fix inverted CONFIG_SYS_BOOT_LOCKED logic

2023-09-28T20:31:43+00:00

CONFIG_SYS_BOOT_LOCKED means that a restricted boot environment will
be used. In this case, hab_auth_img_or_fail should be called to prevent
U-Boot to continue running when the fitImage authentication fails.

Fix the logic accordingly.

Additionally, select CONFIG_SYS_BOOT_LOCKED by default.

Signed-off-by: Eduard Strehlau 
Signed-off-by: Fabio Estevam

smegw01: Use CONFIG_SYS_LOAD_ADDR for loading fitImage

2023-09-23T16:45:34+00:00

Set CONFIG_SYS_LOAD_ADDR=0x88000000 and use this address for
loading fitImage.

Also pass the standard CONFIG_BOOTFILE option to indicate
the fitImage file.

Signed-off-by: Eduard Strehlau 
Signed-off-by: Fabio Estevam

smegw01: Fix wrong symbol override

2023-06-29T13:55:50+00:00

board_mmc_get_env_part() is not called as the default implementation
of mmc_get_env_part() is used.

Fix this problem by directly calling mmc_get_env_part() instead.

Signed-off-by: Eduard Strehlau 
Signed-off-by: Fabio Estevam