On Tue, 2011-03-29 at 12:03 -0400, omalleys(a)msu.edu wrote:
Quoting Gordan Bobic <gordan(a)bobich.net>:
> It'd have to be more finely grained than sub-architecture since a kernel
> for one target won't necessarily work on other CPU of the same
> sub-architecture (e.g. a Kirkwood kernel won't work on all ARMv5
> processors).
Is there a way around this? I mean like being able to make a
megakernal with a ton of modules that has support for every board and
autodetects hardware?
Kind of. There is something called Flattened Device Tree (an improvement
over older ATAGS) that is making its way into upstream and into U-Boot.
My intention is build upon this, to have a kernel that can get all kinds
of platform information from U-Boot and flexibly load modules or quirks
for various boards. It won't get you completely away from having
multiple kernels for different arch rev optimizations, but it will
improve the situation. Right now, the kernel does get a machine ID
passed into it from the bootloader, and does a bunch of fixups, but this
can be taken a lot further and made a lot more generic.
Doing broken out modules for multi-arch isn't going to be possible. But
that's ok. We can pick a low common denominator kernel for e.g. ARMv5
and have an ARMv7 kernel and try to make as much else flexible at run
time as possible. I will post some comments and followup as we begin
poking at the device tree bits and considering what we can do.
Jon.