LS1021a: SMMU/MMC configuration issue

vsiles — Tue, 29 Mar 2016 12:20:39 GMT

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

Re: LS1021a: SMMU/MMC configuration issue

vsiles — Wed, 30 Mar 2016 08:53:15 GMT

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:

Re: LS1021a: SMMU/MMC configuration issue

vsiles — Wed, 30 Mar 2016 12:28:48 GMT

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.

topic LS1021a: SMMU/MMC configuration issue in Layerscape

LS1021a: SMMU/MMC configuration issue

Re: LS1021a: SMMU/MMC configuration issue

Re: LS1021a: SMMU/MMC configuration issue