This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Multi Core and Boot Loader

Would this group be able to answer some multi arm core and boot loader questions that we have ?

Parents
  • 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.

    HTH
    Pete

Reply
  • 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.

    HTH
    Pete

Children
No data