u-boot.git/board/purism/librem5/librem5.c, branch next Unnamed repository; edit this file 'description' to name the repository. librem5: Drop unnecessary BOARD_EARLY_INIT_F usage 2026-04-02T12:10:40+00:00 Tom Rini trini@konsulko.com 2026-03-25T19:00:47+00:00 bc7a0494a7b3bf7c7b190596409081febf4e582c This platform enables CONFIG_BOARD_EARLY_INIT_F and then has a do-nothing board_early_init_f function. Change to not enabling the option and so not needing an empty function. Signed-off-by: Tom Rini <trini@konsulko.com> 
This platform enables CONFIG_BOARD_EARLY_INIT_F and then has a
do-nothing board_early_init_f function. Change to not enabling the
option and so not needing an empty function.

Signed-off-by: Tom Rini <trini@konsulko.com>
treewide: Clean up DECLARE_GLOBAL_DATA_PTR usage 2026-02-17T19:50:22+00:00 Peng Fan peng.fan@nxp.com 2026-02-09T01:30:18+00:00 0f90b1e715f8abe41b0875752eb184f46032ff11 Remove DECLARE_GLOBAL_DATA_PTR from files where gd is not used, and drop the unnecessary inclusion of asm/global_data.h. Headers should be included directly by the files that need them, rather than indirectly via global_data.h. Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> #STMicroelectronics boards and STM32MP1 ram test driver Tested-by: Anshul Dalal <anshuld@ti.com> #TI boards Acked-by: Yao Zi <me@ziyao.cc> #TH1520 Signed-off-by: Peng Fan <peng.fan@nxp.com> 
Remove DECLARE_GLOBAL_DATA_PTR from files where gd is not used, and
drop the unnecessary inclusion of asm/global_data.h.

Headers should be included directly by the files that need them,
rather than indirectly via global_data.h.

Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> #STMicroelectronics boards and STM32MP1 ram test driver
Tested-by: Anshul Dalal <anshuld@ti.com> #TI boards
Acked-by: Yao Zi <me@ziyao.cc> #TH1520
Signed-off-by: Peng Fan <peng.fan@nxp.com>
global: Avoid indirect inclusion of <env.h> from <net.h> 2025-05-29T14:30:25+00:00 Tom Rini trini@konsulko.com 2025-05-15T23:31:50+00:00 ae9ff5ae6f579f321a1b695c82453b67ec1bf6db Now that env_get_ip() has been removed, the include file <net.h> does not need anything from <env.h>. Furthermore, include/env.h itself includes other headers which can lead to longer indirect inclusion paths. To prepare to remove <env.h> from <net.h> fix all of the remaining places which had relied on this indirect inclusion to instead include <env.h> directly. Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org> # net/lwip Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Martyn Welch <martyn.welch@collabora.com> Signed-off-by: Tom Rini <trini@konsulko.com> 
Now that env_get_ip() has been removed, the include file <net.h> does
not need anything from <env.h>. Furthermore, include/env.h itself
includes other headers which can lead to longer indirect inclusion
paths. To prepare to remove <env.h> from <net.h> fix all of the
remaining places which had relied on this indirect inclusion to instead
include <env.h> directly.

Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org> # net/lwip
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Martyn Welch <martyn.welch@collabora.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Merge patch series "provide names for emmc hardware partitions" 2024-09-05T18:13:24+00:00 Tom Rini trini@konsulko.com 2024-09-05T18:13:24+00:00 208fc7a9f9022240e47ae4969227f60d2b84dbb9 Tim Harvey <tharvey@gateworks.com> 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. 
Tim Harvey <tharvey@gateworks.com> 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 Tim Harvey tharvey@gateworks.com 2024-05-31T15:36:33+00:00 8746aa0f5da740c593cef95b7c28386716f128d6 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 <tharvey@gateworks.com> 
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 <tharvey@gateworks.com>
Restore patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet" 2024-05-20T19:35:03+00:00 Tom Rini trini@konsulko.com 2024-05-20T19:35:03+00:00 03de305ec48b0bb28554372abb40ccd46dbe0bf9 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 <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com> 
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 <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"" 2024-05-19T14:16:36+00:00 Tom Rini trini@konsulko.com 2024-05-19T02:20:43+00:00 d678a59d2d719da9e807495b4b021501f2836ca5 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 <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com> 
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 <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
board: purism: Remove <common.h> and add needed includes 2024-05-07T14:00:37+00:00 Tom Rini trini@konsulko.com 2024-05-01T02:42:33+00:00 024b3c82cd66885ec004369995ac682db0ed9b7b Remove <common.h> from this board vendor directory and when needed add missing include files directly. Signed-off-by: Tom Rini <trini@konsulko.com> 
Remove <common.h> from this board vendor directory and when needed
add missing include files directly.

Signed-off-by: Tom Rini <trini@konsulko.com>
librem5: properly set the `fdtfile` env variable 2023-12-13T13:00:43+00:00 Arnaud Ferraris arnaud.ferraris@collabora.com 2023-10-27T13:40:44+00:00 4ae3fcdf7b5cb9625e78110183392d0d4e8fe783 In order to use the generic "distro boot" using an extlinux.conf file, the `fdtfile` environment variable is mandatory. This commit ensure this variable is properly constructed based on the detected board revision. Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com> 
In order to use the generic "distro boot" using an extlinux.conf file,
the `fdtfile` environment variable is mandatory. This commit ensure this
variable is properly constructed based on the detected board revision.

Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com>
mmc: Use EXT_CSD_EXTRACT_BOOT_PART() macro for extracting boot part 2023-04-10T03:18:17+00:00 Pali Rohár pali@kernel.org 2023-03-11T10:44:27+00:00 8b8820669646ceb08d6ceed4181b53042639f3ab Mask macro PART_ACCESS_MASK filter out access bits of emmc register and macro EXT_CSD_EXTRACT_BOOT_PART() extracts boot part bits of emmc register. So use EXT_CSD_EXTRACT_BOOT_PART() when extracting boot partition. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Simon Glass <sjg@chromium.org> 
Mask macro PART_ACCESS_MASK filter out access bits of emmc register and
macro EXT_CSD_EXTRACT_BOOT_PART() extracts boot part bits of emmc register.
So use EXT_CSD_EXTRACT_BOOT_PART() when extracting boot partition.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>