On Wed, Mar 9, 2011 at 10:57 AM, Andy Green andy@warmcat.com wrote:
On 03/09/2011 08:51 AM, Somebody in the thread at some point said:
Hi -
Panda is OMAP4 and the other two are OMAP3 AIUI, I am aware they are all under "OMAP2+" in the kernel, but there are really significant differences from configuration point of view like SMP or not.
How is that handled with the same config?
One can build a single kernel binary that runs on OMAP2/3/4 platforms from the mainline kernel. That has been the main requirement from the maintainer to add new board support. Everything under mach-omap2 and plat-omap is written for runtime detection of features.
I know it well. However -->
However, last I looked, there were problems with the ARM locking primitives being patched at runtime. So it prevented SMP-on-UP kernels, that is, SMP had to be turned off. But that will eventually get fixed so you could have a SMP kernel running on a UP system. This is how x86 does it today.
I take it this magic of SMP or not is hidden in this config layering scheme you mentioned and it isn't really using the same config for say igep0020 and
No, it is in the black depths of ARM assembly and TBH, it is voodoo to me. Nothing to do with kernel config as such. The SMP kernel, at runtime, (binary) patches itself to convert locking primitives to no-ops in the UP case. Or something to the effect.
Panda. In any event, there's a performance tradeoff running SMP kernel on uniprocessor to consider too.
Apparently, with this one-time patching (per boot) there isn't such a tradeoff.
Absolutely that's the future... in fact the bootloader should work the same way with one per-arch bootloader that detects what it is running on at runtime, and at that point device-specific point hwpacks become very thin or non-existent and there's an epic reduction in how many different binaries are needed to support many boards.
I can hear the collective sighs of appreciation from distribution maintainers :)