AMP for the masses
Looking for a performance upgrade for my "ARM based 6510 ICE" I decided to use a Raspberry Pi bare metal app. I started reading excellent Brian's tutorials and making some tests. But SD card swaping between PC and RASPi did not suit me for a development process. Searching for a bootloader I found David's one and tested it with a homemade serial level adapter (using CH340 from a dead Arduino Nano board). That was a better development mechanism, but also tedious.
Thinking about a better option, AMP comes to my mind: If RasPi has 4 ARM cores why not use only one core for bare metal and remainings for development.
The idea was to boot Linux with Cores 0,1,2 and half RAM (lower 512Mb), leaving Core 3 and upper 512Mb for bare-metal. Compilation and linking will be done in Linux (no more cross compiling!) and a loader app (also Linux) will put the binary image in the upper memory used by bare-metal core. Then Core 3 must start the execution of that binary.
In this post you have simple instructions to obtain a working AMP system.
Read the following posts for details about each step involved:
About AMP
Looking for a performance upgrade for my "ARM based 6510 ICE" I decided to use a Raspberry Pi bare metal app. I started reading excellent Brian's tutorials and making some tests. But SD card swaping between PC and RASPi did not suit me for a development process. Searching for a bootloader I found David's one and tested it with a homemade serial level adapter (using CH340 from a dead Arduino Nano board). That was a better development mechanism, but also tedious.
Thinking about a better option, AMP comes to my mind: If RasPi has 4 ARM cores why not use only one core for bare metal and remainings for development.
The idea was to boot Linux with Cores 0,1,2 and half RAM (lower 512Mb), leaving Core 3 and upper 512Mb for bare-metal. Compilation and linking will be done in Linux (no more cross compiling!) and a loader app (also Linux) will put the binary image in the upper memory used by bare-metal core. Then Core 3 must start the execution of that binary.
In this post you have simple instructions to obtain a working AMP system.
Read the following posts for details about each step involved:
- Step 1: Booting RasPi Linux with 3 cores and partial RAM
- Step 2: Compiling, Linking and Loading from Linux the bare-metal executables (locables in upper memory)
- Step 3:Start and stop bare-metal execution with Core 3 (LCM: Life Control Mangement in AMP terminology)
- Step 4: Share some memory areas for send and receive data between Linux and the bare-metal app (remote process)
- Example
About AMP
Asymmetric Multi Processing (AMP) refers to heterogeneous cores, heterogeneous software for each core or both. A Multi Core system has multiple CPUs, each of which may be a different architecture (heterogeneous multicore) or can be the same (homogeneous multicore).
Also, each core in a multicore system can run the same or different software. If cores are different (heterogeneous) software will be different too, resulting in Asymmetric Multi Processing (AMP).
Most homogeneous systems use an Symmetric Multi Processing (SMP) software architecture, where a single operating system instance treats all processors equally, but an AMP architecture is also possible using heterogeneous software.
In many cases an AMP system is dessirable to get a real time (deterministic) operation without losing the benefits of an OS, for example: bare-metal or RTOS apps running on same cores and remainig cores running Linux.An AMP system involves:
- Multicore system (homogeneous or heterogeneous)
- Heterogeneous software
- Separate address space (program and data)
- Communication facility between the CPUs
Read more about Asymmetric Multi Processing (AMP):
OpenAMP
http://www.multicore-association.org/workgroup/oamp.php
ToDo
In an AMP system shared resources are bottlenecks, in my examples bare-metal apps only use a GPIO port and Linux all other reources, avoiding access conflicts. In more complex aplications a beter resource access must be implemented.
Look at OpenAMP for an standard framework for LCM, IPC and resource sharing.
Life Cycle Management for bare metal must be improved, an idea is to use a no returning interrupt like reset. It needs MMU management in order to remap individual Core exception vectors.
Cross debug is also desirable, like to use OpenOCD from Linux to contact a remote gdb stub on bare-metal. May use rpi_stub, replacing UART comms with mailboxes or shared memory IPC.
ToDo
In an AMP system shared resources are bottlenecks, in my examples bare-metal apps only use a GPIO port and Linux all other reources, avoiding access conflicts. In more complex aplications a beter resource access must be implemented.
Look at OpenAMP for an standard framework for LCM, IPC and resource sharing.
Life Cycle Management for bare metal must be improved, an idea is to use a no returning interrupt like reset. It needs MMU management in order to remap individual Core exception vectors.
Cross debug is also desirable, like to use OpenOCD from Linux to contact a remote gdb stub on bare-metal. May use rpi_stub, replacing UART comms with mailboxes or shared memory IPC.
No hay comentarios:
Publicar un comentario