commit e27bddff4b97 ("imx8m: Restrict usable memory to space below 4G boundary")
tried to adjust the usable memory limits on a 4GB boundary.
ram_top is described as 'top address of RAM used by U-Boot' and we want
to preserve that. This is defined as a phys_addr_t and unfortunately
its size differs across architectures. This has lead us to a weird
state where 32bit boards define it 'SZ_4GB - 1' and 64bit boards as
'SZ_4GB' unless it was otherwise defined.
With some recent LMB changes and specifically
commit 1a48b0be93d4 ("lmb: prohibit allocations above ram_top even from same bank")
the board fails to boot properly although the commit above is correct
since it's making sure that no memory above ram_top is usable -- but
added to our memory map so EFI can hand it over to the booted OS.
The reason for that is that during the LMB init we add all usable memory
in lmb_add_memory(). In that function any memory above ram_top gets added
as 'reserved' for LMB. With the current values tha's set to 0xFFFF_FFFF
for this board. Later LMB is trying to protect the memory area U-Boot lives
in with lmb_reserve_common(). The latter fails though since it tries to
add U-Boot top (which is 0xFFFF_FFFF as well) to U-Boot 'bottom'. This call
will fail since 1 byte of that memory range is already marked as 'reserved'.
Since we are close to the release, LMB seems to assume that the address
is rounded up and is the 'next address' and so does parsing and adding
memory ranges from DT files, bump the ram_top of the board by 1byte.
In the long run we should change all of the above and have 32b and 64b
platforms define ram_top identically.
Add a Fixes tag although the commit is correct, so people can figure out
the broken scenarios in the future.
Suggested-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Fixes: commit 1a48b0be93d4 ("lmb: prohibit allocations above ram_top even from same bank")
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reported-by: João Paulo Gonçalves <jpaulo.silvagoncalves@gmail.com>
Closes: https://lore.kernel.org/all/20241216114231.qpfwug3zfqkxn3d5@joaog-nb.corp.toradex.com/
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Fixes: 74f88b72219e ("ARM: imx: imx8m: Fix board_get_usable_ram_top()")
Set correct CPU and GPU frequencies for the industrial i.MX8 SoC
variant.
Ensure that the CPU and GPU frequencies are properly configured for the
industrial variant of the SoC. According to the "i.MX 8QuadMax
Industrial Applications Processors" datasheet, the frequency limits for
this variant are as follows:
- Cortex-A72: 1.296 GHz
- Cortex-A53: 1.104 GHz
- GPU core: 625 MHz
- GPU shader: 625 MHz
The CPU clock is enforced by the System Controller Firmware (SCFW), but
the cpufreq driver is unaware of this enforcement. By removing
unsupported frequencies from the operating points, we ensure that the
cpufreq driver aligns correctly with the SCFW's settings.
The GPU frequency, on the other hand, is not enforced by the SCFW. As a
result, the GPU could potentially be overclocked. To prevent this, we
set the correct clock frequency and update the operating points
accordingly, ensuring compliance with the datasheet specifications.
Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
iMX91 is reduced part from iMX93 with part number: i.MX9131/11/01
It removed A55_1, M33, MIPI DSI, LVDS, etc.
i.MX9131:
- Support 2.4GT/s DDR and HWFFC at 1.2GT/s
i.MX9121:
- A55 at 800Mhz and DDR at 1600MTS, with low drive mode.
i.MX9111:
- Support 1.6GT/s DDR and HWFFC at 800MT/s
i.MX9101:
- Support 800Mhz ARM clock
- Support 1.6GT/s DDR and HWFFC at 800MT/s
- No parallel display, eQOS, flexcan
Updated Clock/Container/CPU and etc for i.MX91
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
According to iMX93 fuse burn plan, all 9x9 parts will have USB2,
ENET1 (FEC), LVDS1, CSI1 and DSI1 disabled. The codes missed ENET1
fuse when detecting 9x9. Although it still can detect 9x9 correctly,
we add the ENET1 fuse to the check to be more accurate.
Fixes: 58da865e27f ("imx9: add i.MX93 variants support")
Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Replace '#if DEBUG' with '#ifdef DEBUG', otherwise '#define DEBUG 1'
should be used and conflict with '#define DEBUG' in include/log.h
Fixes: 5fda95fb944 ("imx: imx9: Add TRDC driver for TRDC init")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The phyCORE-i.MX 93 is available in various variants. Relevant variant
options for the spl/u-boot are:
- with or without HS400 support for the eMMC
- with 1GB ram chip, or 2GB ram chip
The phyCORE's eeprom contains all information about the existing variant
options. Add evaluation of the eeprom data to the spl/u-boot to
enable/disable HS400 and to select the appropriate ram configuration at
startup.
Signed-off-by: Christoph Stoidner <c.stoidner@phytec.de>
Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Reviewed-by: Yannic Moog <y.moog@phytec.de>
Tested-by: Primoz Fiser <primoz.fiser@norik.com>
We have many HW with capricorn i.MX8X boards. The difference in u-boot is
at all by the display of the LEDs.
* put upstream a reference project & board for DT and defconfig
* use the capricorn prefix outside the board/siemens/capricorn folder
Signed-off-by: Enrico Leto <enrico.leto@siemens.com>
Signed-off-by: Heiko Schocher <hs@denx.de>
Fix the critical thermal threshold for i.MX processors, this was changed
while moving the code from imx8m/imx9 directories into a shared place.
There is no need to keep the critical threshold 5 degrees less than the
SoC maximum temperature threshold, what is actually going to happen in
practice is that we are going to power-off the board when the SoC is
still within its working temperature range.
In addition to that this is a change in the actual behavior, that is
introducing a regression to users, and it was hidden within a software
refactoring.
Fixes: d0fe80890ab1 ("imx: Generalize fixup_thermal_trips")
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Working with HAB on the i.MX8MP we've encountered a case where a board
that successfully authenticates u-boot when booting Linux subsequently
fails to properly bring up the RTC.
The RTC registers live in the low-power block of the Secure Non-Volatile
Storage (SNVS) block.
The root cause of the error has been traced to the HAB handing off the
SNVS-RTC in a state where HPCOMR::NPSWA_EN = 0 in other words where the
Non-Privileged Software Access Enable bit is zero.
Configure SNVS to allow unpriv access to SNVS LP for imx8m and imx8mp.
This commit generalizes 723f8359c1 ("imx: mx7: snvs: Add an SNVS init
routine") to also be used on i.MX8M SoCs, and was testeed on i.MX8MP.
Signed-off-by: Ian Ray <ian.ray@gehealthcare.com>
Commit 723f8359c1 ("imx: mx7: snvs: Add an SNVS init routine") noted
that the init_snvs() call likely applies to other i.MX processors, and
this has been found to be true for i.MX8MP.
Move snvs module for future re-use.
Signed-off-by: Ian Ray <ian.ray@gehealthcare.com>
Improve "mmcautodetect=yes" boot mode autodetection to able to use it
if CONFIG_ENV_IS_NOWHERE=y is used for i.MX9 SoCs and i.MX93 EVK board.
If both CONFIG_ENV_IS_IN_MMC=y and CONFIG_ENV_IS_NOWHERE=y are in the
defconfig, CONFIG_ENV_IS_IN_MMC=y will be overiden default
CONFIG_ENV_IS_NOWHERE settings.
Goal is in this patch to able to use the boot mode autodetection
if defconfig use only CONFIG_ENV_IS_NOWHERE=y option
(without CONFIG_ENV_IS_IN_MMC) for any i.MX9 SoC.
Signed-off-by: Benjamin Szőke <egyszeregy@freemail.hu>
The decision on whether HAB is enabled is solely based on the SEC_CONFIG
fuse. The HAB FIELD_RETURN feature is able to permanently disable HAB on
a CPU, after which it is able to boot unsigned firmware. U-Boot however
does not take into account the FIELD_RETURN mode, and refuses to boot
unsigned software when the feature is enabled.
Also take the FIELD_RETURN fuse into account when deciding whether HAB
is enabled. When The FIELD_RETURN fuse is blown, HAB is not enabled.
Tested on i.MX8M Mini, i.MX8M Plus, i.MX8M Nano and i.MX6ULL
Signed-off-by: Paul Geurts <paul.geurts@prodrive-technologies.com>
The imx_sec_config_fuse_t structure is not specific to the sec_config
fuse, but can be used for all fuse words.
Rename the structure to a more generic name to be reused for other
fuses.
Signed-off-by: Paul Geurts <paul.geurts@prodrive-technologies.com>
The Emcraft Systems NavQ+ kit is a mobile robotics platform
based on NXP i.MX8 MPlus SoC.
The following interfaces and devices are enabled:
- eMMC
- Gigabit Ethernet (through eQOS interface)
- SD-Card
- UART console
The device tree file is taken from upstream Linux Kernel
through OF_UPSTREAM
Signed-off-by: Gilles Talis <gilles.talis@gmail.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Move i.MX7 TEXT_BASE/SPL_TEXT_BASE to Kconfig and common/spl/Kconfig
which is the best practice.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Device tree for this board can be deleted. Device tree location
now points to the freescale/ directory.
Use absolute path to PMIC node entry and its regulators as
device tree in kernel does not provide corresponding labels
Signed-off-by: Gilles Talis <gilles.talis@gmail.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
The SCU API alreay has been converted to return Linux error code,
using SCU error code is not correct here, although SC_ERR_NONE is value
as 0.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Simon Glass <sjg@chromium.org> says:
When the SPL build-phase was first created it was designed to solve a
particular problem (the need to init SDRAM so that U-Boot proper could
be loaded). It has since expanded to become an important part of U-Boot,
with three phases now present: TPL, VPL and SPL
Due to this history, the term 'SPL' is used to mean both a particular
phase (the one before U-Boot proper) and all the non-proper phases.
This has become confusing.
For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL'
phases, not just SPL. So code which can only be compiled for actual SPL,
for example, must use something like this:
#if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD)
In Makefiles we have similar issues. SPL_ has been used as a variable
which expands to either SPL_ or nothing, to chose between options like
CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable
was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was
updated to support 'VPL_' as well.
This series starts a change in terminology and usage to resolve the
above issues:
- The word 'xPL' is used instead of 'SPL' to mean a non-proper build
- A new CONFIG_XPL_BUILD define indicates that the current build is an
'xPL' build
- The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now
defined for TPL and VPL phases
- The existing SPL_ Makefile variable is renamed to SPL_
- The existing SPL_TPL Makefile variable is renamed to PHASE_
It should be noted that xpl_phase() can generally be used instead of
the above CONFIGs without a code-space or run-time penalty.
This series does not attempt to convert all of U-Boot to use this new
terminology but it makes a start. In particular, renaming spl.h and
common/spl seems like a bridge too far at this point.
The series is fully bisectable. It has also been checked to ensure there
are no code-size changes on any commit.
This shows up in 'help' output and introduces bogus gap:
"
mfgprot - Manufacturing Protection
mii - MII utility commands
"
Drop the newline to fix this.
Signed-off-by: Marek Vasut <marex@denx.de>
Acked-by: Peng Fan <peng.fan@nxp.com>
With the introduction of downstream Linux 6.6, the iMX8MP VPU block
control node in DTS was renamed "blk-ctl@38330000" and will not match
the ones found in `node_path_imx8mp` resulting in the node not being
disabled on the VPU-less variants.
Add an extra node_path entry for imx8mp VPU block control that match
with downstream Linux.
Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Add support for the Comvetia i.MX6Q LXR2 board, which is
uses the Phytec PFLA02 SoM.
Based on the original work from Stefano Babic <sbabic@denx.de>.
The Phytec PFLA02 devicetrees are taken from kernel 6.11-rc7.
The imx6q-lxr.dts has been submitted upstream:
https://lore.kernel.org/linux-devicetree/20240913200906.1753458-3-festevam@gmail.com/
After it gets accepted in mainline (most likely in kernel 6.13),
the lxr2 board can then be switched to OF_UPSTREAM and these device trees
can be removed from U-Boot.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Remove unused CONFIG_IMX9_LOW_DRIVE_MODE kconfig and
imx93_11x11_evk_ld_defconfig.
Remove the ld timing file.
The LD mode support will be added back with runtime detection later.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Add trdc_mbc_blk_num to get num blks in a MBC mem slot, then drop
the hardcoded value '40' for NIC OCRAM configuration.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
i.MX8M and i.MX9 have duplicated fixup_thermal_trips, so move it
to arch/arm/mach-imx/fdt.c to avoid duplicated code.
The critial temperature point for i.MX9 set to "maxc - 5" back to give
some margin.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Add support for iMX93 low performance parts 9302 and 9301 which
restrict to low drive voltage only.
The parts run A55 max speed at 900Mhz and M33 at 133Mhz, have NPU
and A55 core1 (9301) disabled.
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
disable_cpu_nodes could be reused by i.MX9, so move disable_cpu_nodes
out from mach-imx/imx8m/soc.c to mach-imx/fdt.c and update
disable_cpu_nodes to make it easy to support different socs.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
i.MX8M use PPI for PMU interrupts, there is no reason to update
interrupt-affinity for PMU even interrupt-affinity was wrongly added
to device tree before.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
To support 1.866GTS LPDDR4x timing script, need to add 233Mhz freq
to DDR PLL for second mission point at 933MTS. Otherwise DDR training
will fail.
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Normally, the wdog will be used for trigger external PMIC reset
through the WDOG_ANY pin. If the PMIC chip has debounce logic for
the reset signal, in some corner case the wdog can NOT trigger
external PMIC reset if the SoC has been reset internal before the
PMIC captures the WDOG_ANY pin reset, so need to keep the WDOG3-5
reset masked in the SRC to let the PMIC to do the reset safely.
Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Since we use SPEED GRADE fuse to set A55 frequency, remove the
set_arm_core_low_drive_clk function which has hard coded frequency.
And adjust clock_init called sequence and split it to early and late
functions.
Set the authen register in early function, because CCF driver checks
NS bit.
Set bus and core clock in late function, because the fuse read and
SoC type/rev depend on ELE.
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Replace the static CONFIG_IMX9_LOW_DRIVE_MODE with runtime target
voltage mode by checking the part's SPEED GRADE fuse.
SPL will configure to highest A55 speed which is indicated by the SPEED
fuse and select corresponding voltage mode.
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The boot image includes Edgelock Enclave(ELE) Firmware. Print the
information out to let user know which version firmware is being used.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The second Ethernet MAC (eQOS) fuse layout is changed since i.MX93 A1
following other i.MX platforms, for example i.MX8MP.
Order for A0:
MAC1_ADDR[15:0]
MAC1_ADDR[31:16]
MAC1_ADDR[47:32]
MAC2_ADDR[47:32]
MAC2_ADDR[15:0]
MAC2_ADDR[31:16]
Order since A1:
MAC1_ADDR[15:0]
MAC1_ADDR[31:16]
MAC1_ADDR[47:32]
MAC2_ADDR[15:0]
MAC2_ADDR[31:16]
MAC2_ADDR[47:32]
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
To support OSCCA enabled part which has disabled FSB access from SOC,
change directly read from FSB to use fuse_read API.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Print UID in big endian format and as one buffer of bytes, so customer
can directly use it for EdgeLock 2GO.
Before:
UID: 0xf6c8ae93 0x0f46b326 0x10d61eb3 0x0583c2d2
Become:
UID: 93aec8f626b3460fb31ed610d2c28305
Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
ROM use UID[0] and UID[1] as serial number with big endian when usb serial
download.
After update this, uuu(>1.6) can use below command to filter out devices
when multi boards connected.
uuu -ms <serial#> ...
[sudo] uuu -lsusb can list known devices with serial# informaiton.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
On OSCCA part, M33 TCM is used for ROM PATCH and protected by ELE ROM.
So after release TRDC, we need to configure TRDC for M33 TCM,
otherwise A55 can't access the TCM.
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Ye Li <ye.li@nxp.com>
SSAR handshake done means power on finished, not ISO done. so correct
the waiting mask.
Fixes: 0256577a83b ("imx: imx9: Add MIX power init")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Enable MMU and caches very early on in the boot process on i.MX8M
in U-Boot proper. This allows board_init_f to run with icache and
dcache enabled, which saves some 700 milliseconds of boot time on
i.MX8M Plus based device.
The 'bootstage report' output is below:
Before:
```
Timer summary in microseconds (8 records):
Mark Elapsed Stage
0 0 reset
961,363 961,363 board_init_f
1,818,874 857,511 board_init_r
1,921,474 102,600 eth_common_init
2,013,702 92,228 eth_initialize
2,015,238 1,536 main_loop
Accumulated time:
32,775 dm_r
289,165 dm_f
```
After:
```
Timer summary in microseconds (8 records):
Mark Elapsed Stage
0 0 reset
989,466 989,466 board_init_f
1,179,100 189,634 board_init_r
1,281,456 102,356 eth_common_init
1,373,857 92,401 eth_initialize
1,375,396 1,539 main_loop
Accumulated time:
12,630 dm_f
32,635 dm_r
```
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
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.
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>
CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/22211
- Enable SPI NOR flash support and MTD partitions for phycore_imx8mp.
- Convert mx6slevk to OF_UPSTREAM and watchdog DM.
- Cleanup some mx5/mx6 USB options.
- Make PLL settings configurable at board level.
- Set CONFIG_SPL_LOAD_FIT_ADDRESS for verdin-imx8m/p.
- Make the mxc-gpio reading state of GPIO pins in output mode to be
consistent with the Linux kernel.
- Add HUK derivation support for ELE AHAB.
