This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM3874: Data abort and MMU configuration

Part Number: AM3874

Hi,

My customer using AM3874 reported an issue related MMU and data access.
When 4bytes access is made for non-4bytes aligned address, Data abort happens.
It depends on MMU configuration.

MMU configuration is below:

-> vmContextShow

VIRTUAL ADDR  BLOCK LENGTH  PHYSICAL ADDR  PROT (S/U)  CACHE     SPECIAL

------------      ------------       -------------      ----------     --------     ------------

0x89607000      0x041f9000       0x89607000       RWX / ---   CB-/--/-    --/S3

0x8d800000      0x02555000       0x8d800000      RWX / ---    OFF/--/-   --

0x8fd55000       0x00601000      0x8fd55000       RWX / ---    CB-/--/-   --/S3

Access protection is Read/Write/eXecute enabled.
Cache CB means Copy Back, OFF means Cache disabled.

Data abort happens only when 0x8d800000 to 0x8fd54FFFF region is accessed.
Why?
And what “SPECIAL” attributes mean here ?

Thanks and regards,
Koichiro Tashiro

  • Hi Koichiro Tashiro,

    Typically if the cache is disabled, data will directly read from memory or written to memory. If the cache is enabled, it will make sure read and write is aligned. 

    I am not sure if direct access can cause abort, atleast i have not seen. Are you sure that abort is because of unaligned access? If you do aligned access, does it working fine? 

    Regards,

    Brijesh

  • Hi Brijesh,

    I am not sure if direct access can cause abort, atleast i have not seen. Are you sure that abort is because of unaligned access? If you do aligned access, does it working fine? 

    Yes. Customer confirmed below points;
    - Unaligned accesses cause aborts.
    - Aligned accesses do no cause aborts.
    - These aborts happens at 0x8d800000 to 0x8fd54FFFF only.

    Thanks and regards,
    Koichiro Tashiro

  • Hi Koichiro,

    It is bit difficult to say, Is it possible to keep the address to be aligned?

    Regards,

    Brijesh

  • Hi Brijesh,

    Could you clarify what attribute "S3" means in "SPECIAL"?

    Thanks and regards,
    Koichiro Tashiro

  • Hello Tashiro-san,

    I was asked to review this.  Your customer's MMU decode is not precise enough for an answer.  It does not using the ARM Ltd ARMv7 TRM MMU attribute names and it is missing critical attribute modifiers.   That said, if I 'guess' "OFF" means "DEVICE (shared or non-shared) or Strongly-Ordered" as the non-cached attirbute, than an abort is 'very likely' using those versions of non-cached MMU mappings.  The ARCH behavior for a non-aligned accesses to a "non-normal" type memory is undefined.  The same goes for executing VFP/NEON instructions in or targeting DEVICE/SO memory.   It used to be common for people to get such aborts when porting code into a bootloader or with bare metal code when the MMU is OFF or with illegal usage of attributes.

    If the user re-defines their non-cached access to the "normal-non-cached" type, they should be able to make non-aligned accesses provided the CP15.CR settings are setup not enforce strict alignment checking.

    This information can all be found in the ARMv7 TRM.   I have often seen folks porting code in from older ARM code bases hit issues here as pre-ARMv7, the MMU setup was much simpler and software didn't need to be and was not as precise in usage.  Our own A8 initial bring up had these issues long back.  Non-cached's meaning in older ARMs is simple and not nuanced.  With older ARMs a programmer could often violate the specification with no penalty.  On most modern ARMs, this is not the case, and aborts and hangs are the common for not following the architecture rules.

    Regards,

    Richard W.