Would this group be able to answer some multi arm core and boot loader questions that we have ?
Well like stackoverflow you'll find people willing to give your questions a try, which is as much as you'll get anywhere outside of paying for a contract with someone. Like it says on Wikipedia for new editors, be bold. Just ask your questions. You can see here the sorts of things other people have asked.
OK here are my questions:
1. "All cores need some memory structure to function whether it is a ROM/RAM or main memory."
2. "All Cortex cores can run from off-chip memory, whether it is ROM, Flash, or DDR".
OK for point 1. what is the correlation of ROM area and the core ? Would this be for a dedicated ROM boot loader for the core ? Also same question for RAM ? Is the purpose of RAM is for the core to execute user application code or for a device OS ?
OK for point 2. what does this mean ? Would this mean that the core can be powered on and made active by way of a ROM boot loader or user application or the device's OS stored on flash or DDR (if non-volatile) ?
I can only give you some general-knowledge answers.
To me, it seems like the question is mostly Cortex-A specific (but I think it could be applied to Cortex-R and Cortex-M).
For #1: If you have a program, yes, it needs to be able to run from some kind of memory.
If you have a multicore system, the cores can run code from the same memory; they do not need separate memories in order to function.
It would be possible to design a system with 4 cores, so it has 5 different memory sections, where each core has a section that is intended to be used with that particular core.
Generally speaking : This is not how it's usually done, though. Normally a multicore system shares all the memory available (except for private caches).
#2: Usually, yes.
For booting up, each Cortex-A core has an identifier (a core ID), which can be found by looking in the special purpose registers.
You would be able to use this ID to make sure that your bootloader would start up as expected, until you've set up everything.
(eg. for safety, you could "park"/"sleep" 3 cores, while the first core is preparing the system for running full-core).
-So yes, you have full control over the boot process; it's not an unpredictable event.
Maybe peterharris or mweidmann would find this conversation interesting too.
See also:
How to switch off 2nd core for Cortex-A9
OK for point 1. what is the correlation of ROM area and the core? Would this be for a dedicated ROM boot loader for the core ? Also same question for RAM ? Is the purpose of RAM is for the core to execute user application code or for a device OS ?
ROM bootloaders (commonly called level 1 boot) normally contains the simplest possible bootloader whose sole job it to initialize enough of the system - turn on and configure DDR and Flash controlers for example - to fetch a more fully featured bootloader and get it running.
The ROM bootloader itself is outside of the ARM core, so how big / complex the ROM bootloader is can vary depending on what our silicon partners implement. ARM license the Cortex-A core designs to other companies who can integrate them into a full chip design - which will include supplying the ROM bootloader - so YMMV ...
2. "All Cortex cores can run from off-chip memory, whether it is ROM, Flash, or DDR".OK for point 2. what does this mean ? Would this mean that the core can be powered on and made active by way of a ROM boot loader or user application or the device's OS stored on flash or DDR (if non-volatile) ?
The ROM is on-chip. That is its main value (it's inside the chip and so can run before the chip is configured to talk to the outside world). Other than that, you're basically along the right lines. The basic flow
ROM Loader -> Initialize IO -> Load Level 2 Loader from Flash into RAM -> Run L2 Loader -> Load OS from Flash in RAM -> OS Boot -> Load Applications from Flash.
Replace flash with hard disk / network / tape storage or whatever physical storage is used - anything is possible. Note that some types of flash allow you to execute in place, so you don't need to copy out the code in to RAM to execute it; these can be quite common for storing the Level 2 bootloader, but generally lack capacity for a large OS filesystem such as Linux.
HTHPete