Single zImage at Linaro Connect
nicolas.pitre at linaro.org
Fri Jul 29 17:51:42 UTC 2011
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:
Will try to have a look.
More information about the linaro-kernel