On Tue, 2011-03-29 at 12:03 -0400, omalleys@xxxxxxx wrote: > Quoting Gordan Bobic <gordan@xxxxxxxxxx>: > > > 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. _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm