First partition (root) starts at 64k.
Writing the environnement at this place breaks it.
64k is now the top boundary of the environnement.
BugzID: 57825
When probing soft_spi the result of dev_get_parent_priv(dev) in probe
function is null ptr because the spi is on the ahb bus which has
per_child_auto_alloc_size set to 0. Therefore it would generate an Ooops
messages when accessing spi_slave structure.
The fix consist of updating the soft_spi_platdata flags inside the
.set_mode.
Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
initialize potential uninitialized variable with the type of"char*" to
be NULL in AVB. That "hashtree_error_mode" in code is manually specified
with a known value, the cases listed cover all potential value of
"hashtree_error_mode"
explicitly do a type cast for memcpy parameters.
Change-Id: Ie5d234422a273d6dab75585bd0d8eb81583707ca
Signed-off-by: faqiang.zhu <faqiang.zhu@nxp.com>
* The default configuration (via resistor stuffing) is DFP (host). This
means that on Type-C hosts fastboot won't work.
* Set to UFP to ensure fastboot works properly.
Change-Id: I2b63d95e08df70da43dee1f8f7bb59d1863943f4
* There is an enumeration problem when using superspeed.
* This doesn't fix it with all hubs, but can enable fastboot to work on
some 3.0 hosts.
Change-Id: If4a603126b945bd8f84c3d6e975e1185530eb193
* Bucks 1-4 will be reconfigured via DVS in the kernel.
* Buck 5 is explicitly set to 1.0V
* Regulator lock/unlock is added, this ensures that in warm or cold
reset the values will be set.
Change-Id: I8d8be74bddbbd081030fe1762b9f9c6534c7fb77
The blob command is not working on i.MX7D, i.MX8MQ and i.MX8MM
devices.
Due to different cache management it's necessary to flush dcache
range for destination address so data can be available in memory.
Add necessary operations in blob_encap() and blob_decap() functions.
Signed-off-by: Breno Lima <breno.lima@nxp.com>
Reviewed-by: Ye Li <ye.li@nxp.com>
(cherry picked from commit 639e5c15816c3eea0d4904a72ad175627be043d8)
The HABv4 implementation in ROM checks if HAB major version
in IVT header is 4.x.
The current implementation in hab.c code is only validating
HAB v4.0 and HAB v4.1 and may be incompatible with newer
HABv4 versions.
Modify verify_ivt_header() function to align with HABv4
implementation in ROM code.
Signed-off-by: Breno Lima <breno.lima@nxp.com>
Reviewed-by: Ye Li <ye.li@nxp.com>
(cherry picked from commit 33f51b401dffa393274a28f9d49a87af3eb02fe0)
The csf_additional_images.txt example should match with
mx6_mx7_secure_boot.txt guide.
Fix addresses provided in csf_additional_images.txt CSF
example.
Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Breno Lima <breno.lima@nxp.com>
(cherry picked from commit 17c3af7a1935a40057c01459766d41ff0a19723b)
When building 32-bit targets with CONFIG_SECURE_BOOT and DEBUG enabled
the following warnings are displayed:
arch/arm/mach-imx/hab.c:840:41: warning: format '%lx' expects argument \
of type 'long unsigned int', but argument 3 has type 'uint32_t \
{aka unsigned int}' [-Wformat=]
printf("HAB check target 0x%08x-0x%08lx fail\n",
~~~~^
%08x
ddr_start, ddr_start + bytes);
arch/arm/mach-imx/hab.c:845:45: warning: format '%x' expects argument \
of type 'unsigned int', but argument 3 has type 'ulong \
{aka long unsigned int}' [-Wformat=]
printf("\nivt_offset = 0x%x, ivt addr = 0x%x\n", ivt_offset, ivt_addr);
~^
%lx
Fix warnings by providing the correct data type.
Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Breno Lima <breno.lima@nxp.com>
(cherry picked from commit 050beb8ee3fc4c690c9ce7c4f47adfc6f48dccdf)
When booting in low power or dual boot modes the M4 binary is
authenticated by the M4 ROM code.
Add an option in hab_status command so users can retrieve M4 HAB
failure and warning events.
=> hab_status m4
Secure boot disabled
HAB Configuration: 0xf0, HAB State: 0x66
No HAB Events Found!
Add command documentation in mx6_mx7_secure_boot.txt guide.
As HAB M4 API cannot be called from A7 core the code is parsing
the M4 HAB persistent memory region. The HAB persistent memory
stores HAB events, public keys and others HAB related information.
The HAB persistent memory region addresses and sizes can be found
in AN12263 "HABv4 RVT Guidelines and Recommendations".
Reviewed-by: Utkarsh Gupta <utkarsh.gupta@nxp.com>
Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Breno Lima <breno.lima@nxp.com>
(cherry picked from commit 0efff16579fabcf57acb9c8857afac8fb58de355)
Enable fastboot configurations in mx6solo sabresd and sabreauto
defconfigs to support UUU. Since the DDR size on mx6solo sabre
boards is smaller, also change the fastboot buffer to 256MB.
Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
(cherry picked from commit c482755fb22fa1a459927ed9aadf2477c42b1a59)
Commit 22191ac353 ("drivers/crypto/fsl: assign job-rings to
non-TrustZone") breaks HABv4 encrypted boot support in the
following i.MX devices:
- i.MX6UL
- i.MX7S
- i.MX7D
- i.MX7ULP
For preparing a HABv4 encrypted boot image it's necessary to
encapsulated the generated DEK in a blob. The blob generation
function takes into consideration the Job Ring TrustZone
ownership configuration (JROWN_NS) and can be only decapsulated
by the same configuration.
The ROM code expects DEK blobs encapsulated by the Secure World
environments which commonly have JROWN_NS = 0.
As U-Boot is running in Secure World we must have JROWN_NS=0
so the blobs generated by dek_blob tool can be decapsulated
by the ROM code.
As NXP BSP does not requires all job-rings assigned to
non-Secure world this commit can be safely reverted.
This reverts commit 22191ac353.
Reviewed-by: Silvano Di Ninno <silvano.dininno@nxp.com>
Signed-off-by: Breno Lima <breno.lima@nxp.com>
(cherry picked from commit 3eebc76f5571f7ce74d385235019e8eb4a6718f6)
As the M4 use different DDR memory size in normal android/car2 and car
image, use different defconfig for car2 to decrease DDR memory
reservation. So memory reserved for each M4 core is 8MB in car2 and
normal android image. it's 32MB for car image.
Change-Id: Idf608f539cd614a154c78e3a1af28eff1da5c1f2
Signed-off-by: Zhang Bo <bo.zhang@nxp.com>
Add support for DVT AIY 1G board, distinguish the board type
with the board id.
TYPE: ID:
Micron 1G 0x5
HYNIX 1G 0x3
Micron 3G 0x1
Test: Boot on AIY 1G/3G ddr board.
Change-Id: I3c7b6ebe8bc5d4e59917fcc3947e9ebfefc940da
Signed-off-by: Ji Luo <ji.luo@nxp.com>
When booting dual linux with jailhouse, inmate linux will use
the 2nd uart, so not restrict access the uart for jailhouse case.
The best solution would be using SIP call to ATF, for simplicity,
directly modify the RDC register.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
previous setting can NOT meet the USB stream mode performance settting.
So use the default QoS setting on the i.MX8MM DDR4.
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Reviewed-by: Ye Li <ye.li@nxp.com>
(cherry picked from commit dc9b5e2ffb1d74477c7ec766c6312f9e98afa64c)
The sec_in32 preprocessor is defined as follows in include/fsl_sec.h file:
When address "a" is calculated using math for ex: addition of base address and an offset, then casting is applied only to the first address which in this example is base address.
caam_ccbvid_reg = sec_in32(CONFIG_SYS_FSL_SEC_ADDR + CAAM_CCBVID_OFFSET)
resolves to:
caam_ccbvid_reg = in_le32((ulong *)(ulong)CONFIG_SYS_FSL_SEC_ADDR + CAAM_CCBVID_OFFSET)
instead it should resolve to:
caam_ccbvid_reg = in_le32((ulong *)(ulong)(CONFIG_SYS_FSL_SEC_ADDR + CAAM_CCBVID_OFFSET))
Thus add parenthesis around the address "a" so that however the address is calculated, the casting is applied to the final calculated address.
Bug introduced by commit 79e90af14a ("MLK-18044-2: crypto: caam: Fix build warnings pointer casting").
Signed-off-by: Utkarsh Gupta <utkarsh.gupta@nxp.com>
Reviewed-by: Horia Geanta <horia.geanta@nxp.com>
Reviewed-by: Ye Li <ye.li@nxp.com>
(cherry picked from commit 5d10d1cab052f8af4fd00640e09642aa0a596922)
The boota command boots an Android already written to mmc/emmc.
It calls get_boot_device() to figure out where to look for Android;
but when a board is booted over serial, get_boot_device() returns
an invalid boot mode.
Explicitly setting the storage_type will enable boota on
a board booted over serial.
FB: ucmd setenv storage_type emmc
FB: ucmd boota
Signed-off-by: Adrian Negreanu <adrian.negreanu@nxp.com>
After the commit b9a2a0e2e9 ("mmc: Add support for downgrading
HS200/HS400 to HS mode"), it add a parameter in mmc_set_card_speed()
which indicates that the HS200/HS400 to HS downgrade is happening.
During the HS400 initialization, first select to HS200, and config
the related clock rate, then downgrade to HS mode. So here also need
to config the downgrade value to be true, make sure in the function
mmc_set_card_speed(), after switch to HS mode, first config the
clock rate, then read the EXT_CSD. Otherwise read EXT_CSD in HS mode
at wrong clock rate, e.g. 200MHz, may lead to uncertain result.
Test on i.MX8QM MEK board, some Micron eMMC will stuck in transfer
mode in this case, and USDHC will never get data transfer complete
status, cause the uboot hang.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
(cherry picked from commit 0ba8e1c6efa2e9c34c9b54105d6c50ee293ec1d7)
When using CMD6 to switch eMMC card timing from HS200/HS400 to HS/legacy,
do not poll for the completion status using CMD13, but rather wait 50mS.
Once the card receives the CMD6 and starts executing it, the bus is in
undefined state until both the card finishes executing the command and
until the controller switches the bus to matching timing configuration.
During this time, it is not possible to transport any commands or data
across the bus, which includes the CMD13.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
(cherry picked from commit 5dbade95cb7ebc1f3a309b00430ebf2b466d7aba)
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
The mmc_select_mode_and_width() function can be called while the card
is in HS200/HS400 mode and can be used to downgrade the card to lower
mode, e.g. HS. This is used for example by mmc_boot_part_access_chk()
which cannot access the card in HS200/HS400 mode and which is in turn
called by saveenv if env is in the MMC.
In such case, forcing the card clock to legacy frequency cannot work.
Instead, the card must be switched to HS mode first, from which it can
then be reprogrammed as needed.
However, this procedure needs additional code changes, since the current
implementation checks whether the card correctly switched to HS mode in
mmc_set_card_speed(). The check only expects that the card will be going
to HS mode from lower modes, not from higher modes, hence add a parameter
which indicates that the HS200/HS400 to HS downgrade is happening. This
makes the code send the switch command first, reconfigure the controller
next and finally perform the EXT_CSD readback check. The last two steps
cannot be done in reverse order as the card is already in HS mode when
the clock are being switched on the controller side.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
(cherry picked from commit 523f613609545252f08f01f346ba4b0403f78b7c)
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Update the lpddr4 timing config to align with the ddr tool
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Reviewed-by: Ye Li <ye.li@nxp.com>
(cherry picked from commit a1433dec3a03a6c944b61600e7b317e2a83f2981)
The normal ready time of M4 side is less than 1s, so we can use
2s as the timeout of connection. The current value is 10s, which seems
a little long if M4 SRTM service does not run.
Signed-off-by: Ye Li <ye.li@nxp.com>
Acked-by: Peng Fan <peng.fan@nxp.com>
(cherry picked from commit 4792d8967d3c631d055c133303bb6385b822a3ca)
There are two LPCG HW issues reported in TKT322331. Add workaround
for them in u-boot.
1. Back to back LPCG write access must have 4x DSC cycle interval.
2. When DSC clock is gated, LPCG write access may be missed due to
the edge detect is not see by DSC. Two writes shall be performed
to re-enable the clock if DSC clock is gated
Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
(cherry picked from commit 96186ca0048e6ae261176e5f3ebf02be09bacb08)