> > Will that work on a core that's offline? > > Nope. Only with an online core controlled by the Linux scheduler. > If you do end up trying to get AMP working, you need to plumbing > to load the other OS/kernel in a reserved memory location, set the > program counter and start the OS. > > But that secondary OS has to know how to behave in a system that > it doesn't control, and you'll need ways to communicate with it > from Linux. > > remoteproc/rpmsg can solve some of the issues that I mention, but > it is far from out of the box. > > That's why there's more interest in running a single task with > exclusive CPU in userspace. The work and scaffolding required to > get an AMP system up and running is non trivial.
I kinda thought so, but I was hopeful. After speaking with some co-workers, I have a new perspective on these delays: yes, we are trying to do a 10us control loop, but if we miss a step or two occasionally we can accept that. And looking online I see people indicating context switch times well below 10us (Core-i cpus), which is better than I had anticipated, and should be workable. So I'm going to approach this problem by just trying to squeeze the kernel as much as I can. Some things that I see to squeeze are /dev/cpu_dma_latency (should be 0) or max_cstate (should be as low as possible (0, maybe 1)), possibly idle=poll. Are there other kernel parameters that can minimize kernel interference/time? And perhaps hints about how to set them in Yocto or menuconfig? Thanks! Dave _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
