[Ksummit-2013-discuss] [ARM ATTEND] DT maintainer
Rob Herring
robherring2 at gmail.com
Sat Aug 17 12:24:13 EDT 2013
On Thu, Aug 15, 2013 at 11:06 AM, Catalin Marinas
<catalin.marinas at arm.com> wrote:
> On Tue, Aug 13, 2013 at 02:11:06PM +0100, Rob Herring wrote:
>> Other topics I'd like to discuss:
>> What's left for ARM consolidation work? What further work needed to
>> avoid arm64 duplication?
>
> We'll have a better idea once we see more arm64 hardware. In the
> meantime, what I know for sure is that we need a PCIe implementation
> that is able to share drivers/host/* code between arm and arm64 (and
> possibly other architectures). We had some attempts for more unification
> between arm64, powerpc, microblaze, mips
> (http://lkml.indiana.edu/hypermail/linux/kernel/1304.3/00698.html,
> http://www.linux-mips.org/archives/linux-mips/2013-07/msg00031.html) and
> work is ongoing.
>
>> Now that we are moving from just compiling multiple platforms together
>> to actually running them, what problems have been run into? Are there
>> issues around multi-platform kernels such as kernel size or need for
>> additional run-time patching?
>
> If size becomes an issue, the next step for multi-platform could be
> compiling as much SoC-related code as possible into loadable modules
> that can go into initramfs.
Yes, that is the obvious and easy first step. The challenge here are
the many inter-dependencies of modules needed at boot time like i2c,
gpio, regulators, pmic's, etc. Perhaps having something like
preloaded/built-in modules which are available at boot time, but could
be unloaded after boot if not needed. Special per machine linker
sections which could be freed are another option, but the trend seems
to be moving away from special sections like __devinit,
Rob
More information about the linux-arm-kernel
mailing list