Single zImage at Linaro Connect
dave.martin at linaro.org
Thu Jul 28 11:50:57 UTC 2011
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
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:
> 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:
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?
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.
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?
I think this is probably out of scope for now, becuase it could
end up being contraversial if trying to support both of these
touches arch-independent code. Also, for reasons which should be
obvious, LPAE is not too useful without HIGHMEM turned on.
(LPAE is the large physical address extension, which adds the new
3-level page-table format for accessing physical memory > 4GB on
Catalin's LPAE patches are still not upsteam, since Russell has a few
outstandig issues with them.
Anyone interested can take a look at:
(which is my merge of the AEL patches on top of the current linaro tree)
Note that so long as hardware designers are sensible and keep their
peripherals < 4GB, it's possible to run a non-LPAE kernel on a
Cortex-A15 platform; but the implication is that you will probably
lose access to a lot of RAM.
> 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:
> 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.
> 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
Neither of these is needed for single zImage to work though, so as you
suggest it may be best to postpone these until later.
> 3) Change thes to the build system
One other change I think we'll eventually want is the ability to discard
all the unused parts of the kernel at runtime, after the platform has
If we build many platforms into a single zImage, we potentially end up
with rather a lot unused code when booting the kernel on any specific
platform; this applies to any board support code as well as built-in
drivers for hardware which is only applicable to a cartain board family.
We ought to think about the implications of this, and what metadata
would be needed in order for the kernel to work out what can be
This also feels like something we can consider later though; it isn't
required for single zImage to work.
More information about the linaro-kernel