[U-Boot] Issue with ALLOC_CACHE_ALIGN_BUFFER in env_relocate_spec and

[Vincent]

Hi,
In the end, it seems that the issue is neither MMC nor Normal/Secure
world related, but cache related. Between SPL and u-boot, I run a
small piece of secure software, which turns on the ACTLR.SMP bit.
According to cortex a7 TRM, this is mandatory to enable caching.
Setting the MMU is not enough.

With ACTLR.SMP bit set to 1, I get strange behavior in several places
in u-boot (I can witness CAAM & MMC at least).
Could it be that u-boot was running without cache on cortex-a7 and
activating this bit made cache related issues arise ?

Best,
Vincent

2016-03-25 18:33 GMT+01:00 Vincent <vincent.siles+uboot at gmail.com>:
> Hi,
> I am having some issue with several instances of
> ALLOC_CACHE_ALIGN_BUFFER in (at least):
> - common/env_mmc: env_relocate_spec
> - disk/part_dos: test_part_dos
>
> U-boot (ls1021atwr) is build in SPL mode, SPL part is in Secure World,
> u-boot is in Normal World.
> In the SPL part, there is no problem, MMC access are fine. In the
> normal world, I experience what I think is stack corruption:
>
> At these locations, calls to the MMC to read partition info mostly
> read 0 or garbages. Garbage looks like stack overflow/corruption. For
> example, in the first function, checking the CRC of u-boot's env
> stored in the MMC fails because the buffer is correct until the last
> kb where there is values instead of zeroes, which looks like RAM
> addresses and data.
>
> I tried several fix, but I still don't understand what's happening:
> - I tried to allocate the buffer where MMC data is read into the head
> -> it works fine
> - I tried to allocate more room to these buffer on the stack ->
> sometimes it works, but not always.
>
> Maybe it's my compiler (NXP's SDK 1.9, based on yocto) which is buggy,
> I don't know.
> I can provide some custom dump of memory if necessary, but the buffers
> at these locations are quite huge I'm afraid.
>
> Best regards,
> Vincent