LS1021a: SMMU/MMC configuration issue

[vsiles]

Hi,

I'm currently using NXP SDK 1.9 on a LS1021a board. U-boot from the SDK is built using CONFIG_SPL, and both SPL and u-boot are run in secure mode. The switch to normal world is triggered just priori to jumping to Linux.

My current goal is to run u-boot in normal mode (SPL is still secure). I already patched a couple of locations (e.g. access to CNTFREQ secure registers) so that u-boot can run, but I get an issue while reading the SD card:

- In the SPL, everything is normal, I can issue MMC_CMD_READ_SINGLE_BLOCK and actually read the information from the SD card

- In u-boot, the same action does not read anything.

I inspected a couple of locations, and the following pattern applies all the time:

1) allocate a buffer to read data from SD card

2) write a dummy info inside the buffer

3) issue a block read to the SD card in the buffer

4) read back the buffer: nothing as changed, dummy info hasn't been overwritten by the SD access.

I checked the cpu MMU: no issue here, I can access the buffer and memory mapped registers without any trouble (mapping is 1:1 for the RAM).

TZASC is bypassed (CSU_SA0 and CSU_SA1 are all zeroes). So I guess the SMMU is denying me access to the SD card in the normal world ? I think the 4 SMMU are bypassed by default (CLIENTPD is 1 in CR0/SCR0) but I might miss something.

1) How do I make sure that the SMMU is not enabled ?

2) Is there any other component I might have overlooked that might explain this behavior ?

3) Could it be an alignment issue ? 1 bis) What is the correct alignment requirement for DMA ?

EDIT: I did a few tests by moving the buffer where data are written to different location. It seems that moving the buffer from stack to heap helps and I can read the correct data from SD card. Here is an example of output I get from u-boot. Both stack and heap addresses are aligned to 64.

Reading from stack: dev 0 start 0 count 1 to beee35c0...
[mmc_bread] dev 0 start 0 count 1 dst beee35c0
CMD_SEND:16
                ARG                      0x00000200
                MMC_RSP_R1,5,6,7         0x00000900 
[mmc_read_blocks] mmc bef04008 dst beee35c0 start 0 count 1
CMD_SEND:17
                ARG                      0x00000000
                MMC_RSP_R1,5,6,7         0x00000900 
# Incorrect Data:
34 32 7d 01 00 00 00 00 
fa 00 00 00 00 00 00 00 
ff ff ff ff eb 36 ee be 
04 36 ee be 02 00 00 00 
Reading from heap: dev 0 start 0 count 1 to bffb8e00...
[mmc_bread] dev 0 start 0 count 1 dst bffb8e00
CMD_SEND:16
                ARG                      0x00000200
                MMC_RSP_R1,5,6,7         0x00000900 
[mmc_read_blocks] mmc bef04008 dst bffb8e00 start 0 count 1
CMD_SEND:17
                ARG                      0x00000000
                MMC_RSP_R1,5,6,7         0x00000900 
# Correct Data
fa b8 00 10 8e d0 bc 00 
b0 b8 00 00 8e d8 8e c0 
fb be 00 7c bf 00 06 b9 
00 02 f3 a4 ea 21 06 00 

Best regards,

Vincent

[vsiles]

Further work on the issue makes me think that this is not SMMU related, but only MMU related. Here is another failure scenario:

1) SPL (in secure mode) copies u-boot and my secure blob in RAM

2) jump to my secure blob

3) first thing I do is enabling MMU (short descriptors with AFE/TRE bit set) 1:1 mapping

4) jump back to u-boot (*still* in secure mode) with a patch to disable mmu in start.S

5) u-boot activates its mmu correctly, but MMC read fails

I'm only modifying SCTLR (which I completely restore), TTBCR, TTBR0/1, PRRR and NMRR, all are overwritten by the mmu_setup function.

So I'm still lost  :smileyhappy:

V.

[vsiles · Accepted solution]

Hi ! In the end the issue was not at all a SMMU/MMC issue: my kernel (which is running in between SPL and u-boot, as secure), was setting the ACTLR.SMP bit, to enable caching. With ACTLR.SMP bit set to 1, u-boot doesn't seem to work properly.

For now, I just leave it that way, I'll investigate why later.