Bounty proposal - Multicore/node support

Does the system allow to have some area of memory that are available to several cores ?

Yes, you can hardwire or block some memory space for specific use. Or – IMHO – simply use a dynamic area. You create it, get its physical address and use it to configure the second processor.

The thing that need to be though of, is that multi media application in general are like their name indicate multi media, and often will have to use several controllers in the same time

With AMP, if core 0 makes SATA, core 1 cannot. That’s not such a big deal since one core can saturate the bandwidth of almost all I/O. But, yes, it’s a limit. BTW, some people suggest for example to dedicate one core to GPIO, just to get rid of interrupts problems with slow I/O. Good idea.

The difference between AMP and SMP is the same as with CMT VS PMT. The application must know what it does, since multicore is not automatic. It can be automatic for things like light threads, but not for threads with full I/O access.

I understand that to ask core 1 to do multimedia decoding is a problem, if it’s core 0 that accesses the screen. Too much data transfers. But, it’s the same with SMP. You have the illusion that I/O are shared between all cores. But it’s not the case, and the processor needs to deal with this. And he runs into problems (that’s why I always use light threads). With AMP, you see the problem and you must solve it (since AMP will not try to solve it for you, as SMP does). Just see AMP as a cluster of independent computers.

The thing i wonder with this approach is for all hardware access, because if you have one full os running on each core, or for the cpu and memory they can be independant, but for everything linked to hardware access, they can’t be independant from each other

They are in an AMP system. But to avoid crashes, one system only should manage the I/O (or you can make something more clever, as “all I/O but video and GPIO” on core 0, video for core 1 [dedicated to software graphic acceleration], GPIO for core 2 [dedicated to GPIO], nothing for core 3 [dedicated only to light – or I/O less – threads])

IMHO, AMP approach is much more RISCOSish. We don’t fix rules. We provide tools, and you’re free to use them… or not. OSes are controllers. RISC OS is a toolbox.

aaaaa

Lots on supporting multi-core CPUs on here

Ahora, el spam en Español? Gracias!

It’s worth noting, regarding the “use MPCore to implement whole core dedicated virtualization” idea…

http://blog.flexvdi.es/2015/02/25/enabling-hyp-mode-on-the-raspberry-pi-2/

The BCM2836 actually supports virtualization natively.

The BCM2836 actually supports virtualization natively.

Yep, but Linux guys can’t make dedication of core: it’s patented on SMP systems :)