Single zImage at Linaro Connect

[Dave Martin]

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.

Eh?

> > 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.

Cheers
---Dave