imx6ULL memcpy issue in RTEMS 5

Ian Caddy ianc at goanna.iinet.net.au
Wed Sep 5 03:07:22 UTC 2018



On 4/09/2018 6:24 PM, Chris Johns wrote:
> On 4/9/18 6:13 pm, Ian Caddy wrote:
>> I pretty much copied the build tree, from the imx BSP (which is based on an imx7
>> I think from memory) as the imx6ULL is a Cortex-A7 single core proceessor, using
>> the ARMv7-A architecture.
>>
>> Some places have been saying that I need to check whether or not the particular
>> processor support non-aligned access, but the imx documentation is not that
>> great and points to the ARM documentation which is more generalised.
> I assume your set up is happening here ...
>
> https://git.rtems.org/rtems/tree/bsps/arm/imx/start/bspstarthooks.c#n32
>
> The arm_cp15_start_setup_mmu_and_cache call returns the CPSR on entry and that
> is passed to the arm_cp15_start_setup_translation_table_and_enable_mmu_and_cache
> call.
>
> If your BSP set up code does not set the A bit in the CPSR it will not be set
> when RTEMS runs and newlib needs the A bit set in the CPSR.
>
Thanks for the information.  I did not realise the A bit was modified in 
that section of code.  The A bit is actually cleared in the SCTLR in 
that code.

It turns out that u-boot is setting this A bit, which is cleared on 
power up.

The problem for me was that once the domain access control is set, I 
lose access to the memory, and without having to get to the bottom of 
it, I disabled this function, thinking I would come back to it. Since 
the function is called:

setup_mmu_and_cache

I assumed I could get by to start with without mmu or cache enabled.  I 
probably still can, but I need to leave part of the code in, the bit 
that clears the A bit and sets the AFE and Z bits of the control 
register to see if I can get past the startup code.  Then I will go back 
and look at the domain stuff.

Thanks for the help.

regards,

Ian Caddy





More information about the users mailing list