Single zImage at Linaro Connect
nicolas.pitre at linaro.org
Thu Jul 28 18:44:17 UTC 2011
On Thu, 28 Jul 2011, Dave Martin wrote:
> On Wed, Jul 27, 2011 at 10:58:36PM -0400, Nicolas Pitre wrote:
> > To everyone, and especially to those who are expected to work on this
> > topic next week, please find below a list of tasks that needs to be
> > investigated and/or accomplished. I'll coordinate the work and collect
> > patches for the team.
> > If you have comments on this, or if you know about some omissions,
> > please feel free to provide them as a reply to this message.
> > I'd like to know if people are particularly interested in one (or more :-))
> > items they would like to work on. If so please say so as well.
> 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.
> 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 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.
> > 1.10) mach/debug-macro.S
> > This is used when CONFIG_DEBUG_LL is set. Supporting that option with a
> > single kernel image might prove very difficult with a rapidly
> > diminishing return on the investment.
> > This code is in need of some refactoring already:
> > http://article.gmane.org/gmane.linux.ports.arm.kernel/118525
> > To still benefit from the most likely needed debugging aid, we might
> > consider the ability to still allow the selection of one amongst the
> > existing implementation when building a kernel with many SOC support.
> > Obviously that would only work on the one hardware platform for which the selected printch implementation was
> > designed, but that should be good enough for debugging purposes.
> DT is precisely for solving this kind of problem...
> We would be dependent on examining the device tree very earlier, however.
> It looks like the code in drivers/of/ won't work in the zImage loader
> environment without a lot of modifications; so we might need to create
> a separate, very minimal lightweight parser for this.
> Then we can build all the relevant printch() implementations into the kernel
> and also into the zImage loader, and pick the right one based on the DT?
> The DT could define a special alias for the UART available for low-level
> 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.
> > 1.12) mach/uncompress.h
> > This is used to define per SOC methods to output some progress feedback
> > from the kernel decompressor over a serial port. Once again, supporting
> > this with a single kernel image might prove very difficult with a
> > rapidly diminishing return on the investment. So it is probably best to
> > simply use generic empty stubs whenever more than one SOC family is
> > configured in a common kernel image.
> Is this a separate problem from low-level debug? It feels like if we solve
> one problem, we'll have created all the infrastructure to solve the other
> problem trivially.
> Neither of these is needed for single zImage to work though, so as you
> suggest it may be best to postpone these until later.
Right. For now we should be realistic and simply do the ground work to
simply be able to produce a common binary for more than two platforms.
Achieving only that is already hard enough even if we sidestep a couple
non-critical issues. Once the basic concept is workable, refinements
will come naturally afterward.
More information about the linaro-kernel