Single zImage at Linaro Connect
dave.martin at linaro.org
Fri Jul 29 09:24:23 UTC 2011
On Thu, Jul 28, 2011 at 02:44:17PM -0400, Nicolas Pitre wrote:
> On Thu, 28 Jul 2011, Dave Martin wrote:
> > Currently, device tree is not fully supported upstream for vexpress.
> > Lorenzo Pieralisi wrote some patches, but there were a few outstanding
> > issues and these weren't merged yet.
> > It could make sense for me to take a look at this, since vexpress is
> > also the base for our initial Cortex-A15 refernece platform. With
> > the right people around next week, we have a chance to get any issues
> > thrashed out more quickly.
> > Is this a good idea for next week, or should we be focusing more on
> > core issues?
> DT enablement will also be an important topic next week. I'm sure
> you'll be appreciated whatever you work on.
OK, I may spend some time on that then. Lorenzo will be around for some
of the time too.
> > Some more thoughts:
> > > 1.1.5) Other weird things
> > >
> > > Some machines have non linear memory maps or bus address translations,
> > > sparsemem, etc. Examples of that are:
> > >
> > > arch/arm/mach-realview/include/mach/memory.h
> > > arch/arm/mach-integrator/include/mach/memory.h
> > >
> > > I think solving this is out of scope for this round. Deleting
> > > arch/arm/mach-*/include/mach/memory.h can't be done universally. So a
> > > new Kconfig symbol (NO_MACH_MEMORY_H) is introduced to indicate which
> > > machine class has its legacy <mach/memory.h> file removed. The single
> > > zImage for multiple targets will be restricted, amongst other things, to
> > > those machines or SOCs with that symbol selected. Partial result here:
> > > http://git.linaro.org/gitweb?p=people/nico/linux.git;a=shortlog;h=refs/heads/redux
> > One possibility here is to enable any non-sparsemem platform to be
> > built with sparsemem enabled by just defining a single memory block
> > in this case to encompass the platform's RAM. I believe that platforms
> > which have small I/O holes in their memory maps can continue to use
> > memblock_reserve techniques as before -- there's no need to represent
> > the holes via sparsemem (which would be expensive)
> > Having talked to Will Deacon about this, it sounds like the feasibiltiy
> > and performance impact may depend on how often things like pfn_valid get
> > called when sparsemem is enabled.
> > Is this worth looking into?
> Certainly, especially given your bias. ;-)
> The sparsemem might get pretty inefficient if the build time constants
> such as SECTION_SIZE_BITS can't be relied upon though.
I will try and take a look.
We may find that a lot of platforms can be supported with a single, sane
definition of SECTION_SIZE_BITS. If they can't all be supported by the
same definition, this at least grows the single zImage kernel scope to
include more platforms.
> > I have a slightly biased interest in this, since ARM seems to like
> > funky memory maps for many of its newer boards, and it would be
> > unfortunate for these to get left out of the whole single effort.
> > Of course we could include those platforms in non-sparsemem kernels,
> > but since that will often mean sacrificing half the RAM, this is
> > far from ideal.
> Maybe that half could simply be pushed to home.
> > LPAE (Seems to fit neatly under "weird things" for now ;)
> > Do we care strongly about supporting LPAE and non-LPAE platforms
> > in a single kernel?
> No. I think that would be rather insane. The page table definitions
> have deep repercussions all over the place, often in performance critical
> paths down in core kernel code. Trying to introduce variable elements
> which are otherwise build time optimized constants is probably not going
> to find many followers.
Subtle hint taken ;)
> > We could even embed the printch() function body into the DT if we
> > wanted to make the kernel's job even simpler. Realistic implementations
> > of this function are tiny, so this shouldn't be too cumbersome.
> > That really seems an abuse of the DT though, since this goes beyond
> > just describing the hardware.
> Well... I'm not entirely against the idea. This could be seen as the
> most efficient way to describe how to output a character over some
> serial device for the given hardware. The danger is that some vendors
> might be tempted to abuse that idea by stuffing BIOS-like services in
> there that the kernel would have to cope with.
See my reply to Arnd...
It's not high priority anyway.
More information about the linaro-kernel