Open main menu

DAVE Developer's Wiki β

Changes

no edit summary
[[Category:Software]]
[[Category:Real-time]]
[[Category:MISC-AN-TN]]
[[Category:MISC-TN]]
 
__FORCETOC__
== History ==
|-
|1.0.0
|November 2016January 2017
|First public release
|}
[[File:SoloX-AMP.png|thumb|center|600px400px|Simplified block diagram of the AMP configuration]]
*GPT (General Purpose Timer), including associated I/Os
*some additional GPIOs.
It is also required that :*M4 firmware is booted before the Linux kernel and that the [2]*The Linux kernel has exclusive control of some other GPIOSGPIOs.  Satisfying the first requirement has been the trickiest challenge because, by default, U-Boot and Linux kernel make use of GPT timer, as per official BSP released by NXP. This is not a big deal for U-Boot, because it just uses this timer to handle timeouts and to measure time intervals. The things are more complicated with regard to the Linux, because GPT is used as kernel's clock source. As such, it is involved in the scheduling process and it is dynamically reconfigured over the time, depending on power saving policies. To solve this issue, both U-Boot and Linux kernel have been modified, in order to use EPIT timer instead. In spite of this modification, we have been able to preserve Linux's power saving mechanisms.
Satisfying In order to protect the peripherals that have to be under the exclusive control of the first requirement M4 core, RDC has been configured accordingly. For example, the trickiest challenge becausememory area in which GPT registers are mapped, is accessible by default, U-Boot and Linux kernel make use of GPT timer, as per official BSP released the M4 core only. RDC initialization is performed by NXPM4 itself. This It is worth remembering that the its granularity is not a big deal an important factor that has to be taken in consideration. In this application, for U-Bootexample, because it just uses this timer has had to handle timeouts choose different GPIO banks for M4 and to measure time intervalsA9. The things are more complicated with regard In case the same bank was chosen, it would have been impossible to partition GPIOs across the Linux kerneltwo cores, because GPT is used as clock source. As such, it is involved in some resources are shared among all of the GPIOs belonging to the same bank (for example the scheduling process and it is dynamically reconfigured over clocks feeding the timeGPIO module). For this reason, depending on power saving policiestwo different banks have been chosen.
To solve this issue, both U-Boot and Linux kernel have been modified, in order to use EPIT timer instead. In spite of this modification, we have been able to preserve power saving mechanisms.
In order to protect the peripherals that have to be under the exclusive control of the M4 core, RDC has been configured accordingly. For example, the memory area in which GPT registers are mapped, is accessible by the M4 core only. RDC initialization is performed by M4 itself. It is worth remembering that the its granularity is an important factor that has to be taken in consideration. In this application, for example, it has had to choose different GPIO banks for M4 and A9. In case the same bank was chosen, it would have been impossible to partition GPIOs across the two cores, because some resources are shared among all of the GPIOs belonging to the same bank (for example the clocks feeding the functional block). For this reason, two different banks have been chosen.
About boot requirements, U[1] For more details please refer to the [http://www.nxp.com/pages/i.mx-6solox-processors-heterogeneous-processing-with-arm-cortex-a9-and-cortex-m4-cores:i.MX6SX?tab=Design_Tools_Tab FreeRTOS™ BSP for the i.MX 6SoloX ARM® Cortex®-Boot has been configured in order to get M4 core]. [2] Following is the following complete bootstrap sequence:
#A9 core
#*comes out of reset
#*executes bootrom
#*perform performs basic hardware initializations
#*fetches U-Boot bootloader from flash memory and copies it in SDRAM
#*executes U-Boot from SDRAM
#in In turn, U-Boot
#*fetches M4 firmware from flash
#*starts M4 core
#*fetches Linux kernel and DTB from flash and copies them in SDRAM
#*starts Linux kernel on Cortex-A9 core.
#once Once Linux kernel has completed the bootstrap process, a user space application establishes a communication channel with M4 core, through [https://www.kernel.org/doc/Documentation/remoteproc.txt RPMsg].      [1] For more details please refer to the [http://www.nxp.com/pages/i.mx-6solox-processors-heterogeneous-processing-with-arm-cortex-a9-and-cortex-m4-cores:i.MX6SX?tab=Design_Tools_Tab FreeRTOS™ BSP for the i.MX 6SoloX ARM® Cortex®-M4 core].
4,650
edits