[U-Boot] Issue with ALLOC_CACHE_ALIGN_BUFFER in env_relocate_spec and
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
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@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
participants (1)
-
Vincent