Linux + baremetal

Do you want to run bare metal instead of Linux? That is possible to do. I assume your Linux is running on ARM of some sort. There is freeRTOS that could run instead of Linux. Another possibility is running Damn Small Linux(DSL) which will come up in a flash. May need to create an ARM binary. Another one is http://archlinuxarm.org/.

Clem

Hi clem

I want to run a bare metal application on one core and linux on the other cores. And i want the bare metal application to start as soon as the sbc is powered up (i.e. before linux boots)

I was studying the application note whose link i posted in my original post and trying to understand if i can move the initiinitialization code in uboot

@amgalbu

So you want this http://www.wiki.xilinx.com/Multi-OS+Support+%28AMP+%26+Hypervisor%29

Clem

Or just how to program on bare metal like this https://balau82.wordpress.com/2010/02/14/simplest-bare-metal-program-for-arm/

Yes this is the link where i found the application note. The problem is the bare metal applivations starts agter uboot so there is a delay ffrom when the sbc the is powered up to the moment when the bare metal application starts

No this solution does not include linux

No matter how many processors, only one starts in uboot and later the others start when they have been setup for either Linux or bare metal. The delay should be short. If you need logic at immediate start, you may need external digital logic gates for desired output/inputs. One other choice is use PSoC 4 since it has configurable logic on the processor that will be ready at power up. If the hardware already selected, I could conceive of a bare metal approach that "Kick starts" the Linux later on. The Arduino Yun board: Atmel side starts almost instantaneously while the Linux side takes a solid couple of minutes.

Current solution is based on an external logic, but in order to reduce board size and cost, we are trying to embed everything in a single CPU.

What is not clear up to now is whether uboot uses MMU or not. If it is not using MMU, I forcefully have to wait until uboot passes control to Linux kernel. Otherwise I can try to launch the bare metal application directly from uboot...

Thanks for your time and for your answers!

@amgalbu

  I think what you want to do is possible. How much programming in ARM assembler can you handle? The trick is to switch CPU1 with CP0. But then you MUST handle the CPU0 tasks in the bare metal code.Here are some of the trickier pieces:

Examples of some of the shared resources are:

• Interrupt control distributor (ICD)

• DDR memory

  On-chip memory (OCM)

• Global timer • Snoop control unit (SCU) and L2 cache

In this example, CPU0 is treated as the master and controls the shared resources. If CPU1 were to require control of a shared resource, it would have to communicate the request to CPU0 and let CPU0 control the resource. To keep the complexity of this reference design to a minimum, the bare-metal application running on CPU1 has been modified to limit access to the shared resources. OCM is used by both processors to communicate to each other. When compared to DDR memory, OCM provides very high performance and low latency access from both processors. Deterministic access is further assured by disabling cache access to the OCM from both processors. Actions taken by this design to prevent problems with the shared resources include: 1. DDR memory: Linux has only been made aware of memory at 0x00000000 to 0x2FFFFFFF. CPU1 uses memory from 0x30000000 to 0x3FFFFFFF for its bare-metal application. 2. L2 Cache: CPU1 does not use L2 cache. 3. ICD: Interrupts from the core in PL are routed to the PPI controller for CPU1. By using the PPI, CPU1 has the freedom to service interrupts without requiring access to the ICD. 4. Timer: CPU1 uses the private timer for the heart beat. 5. OCM: Accesses to OCM are handled very carefully by each CPU to prevent contention. In the case of the heart beat, only CPU1 writes the location and CPU0 reads the location. When data is sent from CPU1 to CPU0, only CPU1 writes the data value, then CPU1 sends a flag by setting a different address location in OCM. CPU0 in turn detects the flag, reads the data, and then clears the flag. Only CPU1 can set the flag, and only CPU0 can clear the flag.

  Basically it boils down to controlling shared resources until Linux can take over... Finally you would kick off linux like this:

CPU0 (running Linux) starts CPU1 (running bare-metal) by writing the value of 0x30000000 to address 0xFFFFFFF0 using the included rwmem application. Normally, CPU0 would need to run a set event (SEV) command to wake up CPU1. Because Linux, running on CPU0, is constantly servicing interrupts (another source of events), an SEV command is not necessary. When CPU1 wakes up, it reads the value 0x30000000 from address 0xFFFFFFF0 (written using the rwmem command) and then jumps to address 0x30000000. Note that the FSBL placed CPU1’s ELF at 0x30000000.

Tricky, but certainly possible,

Clem

@amgalbu

  I think what you want to do is possible. How much programming in ARM assembler can you handle? The trick is to switch CPU1 with CP0. But then you MUST handle the CPU0 tasks in the bare metal code.Here are some of the trickier pieces:

Examples of some of the shared resources are:

• Interrupt control distributor (ICD)

• DDR memory

  On-chip memory (OCM)

• Global timer • Snoop control unit (SCU) and L2 cache

In this example, CPU0 is treated as the master and controls the shared resources. If CPU1 were to require control of a shared resource, it would have to communicate the request to CPU0 and let CPU0 control the resource. To keep the complexity of this reference design to a minimum, the bare-metal application running on CPU1 has been modified to limit access to the shared resources. OCM is used by both processors to communicate to each other. When compared to DDR memory, OCM provides very high performance and low latency access from both processors. Deterministic access is further assured by disabling cache access to the OCM from both processors. Actions taken by this design to prevent problems with the shared resources include: 1. DDR memory: Linux has only been made aware of memory at 0x00000000 to 0x2FFFFFFF. CPU1 uses memory from 0x30000000 to 0x3FFFFFFF for its bare-metal application. 2. L2 Cache: CPU1 does not use L2 cache. 3. ICD: Interrupts from the core in PL are routed to the PPI controller for CPU1. By using the PPI, CPU1 has the freedom to service interrupts without requiring access to the ICD. 4. Timer: CPU1 uses the private timer for the heart beat. 5. OCM: Accesses to OCM are handled very carefully by each CPU to prevent contention. In the case of the heart beat, only CPU1 writes the location and CPU0 reads the location. When data is sent from CPU1 to CPU0, only CPU1 writes the data value, then CPU1 sends a flag by setting a different address location in OCM. CPU0 in turn detects the flag, reads the data, and then clears the flag. Only CPU1 can set the flag, and only CPU0 can clear the flag.

  Basically it boils down to controlling shared resources until Linux can take over... Finally you would kick off linux like this:

CPU0 (running Linux) starts CPU1 (running bare-metal) by writing the value of 0x30000000 to address 0xFFFFFFF0 using the included rwmem application. Normally, CPU0 would need to run a set event (SEV) command to wake up CPU1. Because Linux, running on CPU0, is constantly servicing interrupts (another source of events), an SEV command is not necessary. When CPU1 wakes up, it reads the value 0x30000000 from address 0xFFFFFFF0 (written using the rwmem command) and then jumps to address 0x30000000. Note that the FSBL placed CPU1’s ELF at 0x30000000.

Tricky, but certainly possible,

Clem