Hi,
Used board : Freescale SABRE SD board with iMX6Q (A9 processor).
Using Bare-metal code.
Using ARM DS-5 stream to load the binary while u-boot is running.
When I download the binary using the DS-5 debugger the MMU is enabled before launching the application!
It seems the MMU is enabled even before the binary loading as the binary is stored using the Virtual Addresses.
In addition, the Virtual to Physical Address mapping in the page Table (located at 0x4FFF0000 that corresponds to TLB address used by u-boot) always changes and rarely is the flat VA=PA mapping. As the downloaded code at very beginning configures the page Table before assuming that CPU resets with the MMU disabled (so with a flat mapping) the code branches to a random address when applying the new page Table.
Note when I download the binary using tftp on u-boot the code starts with the MMU disabled and runs correctly.
Why is the MMU enabled when downloading the binary (the MMU is supposed to be disabled after a reset) ?
May the DS-5 debugger enable the MMU ?
Thanks in advance for your help.
The debugger shouldn't turn on the MMU when you connect to your target, and even if it did (perhaps to do a physical memory read) it should return the MMU state to what it was before the connection was made. Thus the MMU state upon connection would depend on the behavior of the board after reset (or more correctly before the connection). In my experience u-boot turns on the MMU, and it's conceivable that it could turn it off before running your application.
In DS-5 you can force the MMU off by toggling the M bit in the CP15 System control register. For example by using the registers view, or with the command "set var $CP15::$System::$SCTLR.M = 0".
Hi Lukas,
thanks for the clue. It fixed the issue.
I agree the debugger should not modify the MMU.
I just expected the debugger (actualy the download feature of the debugger) to set the system after dowloading the binary at a state similar to the one after a reset, so with MMU disabled.