Single zImage at Linaro Connect

[Nicolas Pitre]

On Fri, 29 Jul 2011, Rob Herring wrote:

> On 07/29/2011 07:40 AM, Nicolas Pitre wrote:
> > On Fri, 29 Jul 2011, Dave Martin wrote:
> > 
> >> On Thu, Jul 28, 2011 at 02:44:17PM -0400, Nicolas Pitre wrote:
> >>> On Thu, 28 Jul 2011, Dave Martin wrote:
> >>
> >>>> 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?
> > 
> > Euh...  I meant "himem".  No idea how my fingers turned that into 
> > "home".
> > 
> >>>> 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...
> > 
> > What might be done is to describe the data FIFO register location, and 
> > the FIFO full bit mask, and the FIFO empty bit mask.  That's all we need 
> > really.
> > 
> Except for RPC which outputs to video memory. We don't care about that
> one for single kernel, but that may limit a new common solution.

There will always be exceptions.  Since RPC is so different and unique, 
it better be left alone and we should not try to find a solution that 
covers it as well.

I doubt it will ever use DT either.

> BTW, I did implement a conversion to use debug macro code for
> uncompress, but it doesn't work for RPC, OMAP and Davinci. So while it
> shrinks the the code by over 2K lines, we probably need a new approach
> like you suggest. The patches are here if you want to take a look:
> 
> git://git.jdl.com/software/linux-3.0.git
> http://git.jdl.com/gitweb/?p=linux-3.0.git;a=shortlog;h=refs/heads/uncompress

Will try to have a look.


Nicolas