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