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? 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? 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 Cortex-A15) Catalin's LPAE patches are still not upsteam, since Russell has a few outstandig issues with them. Anyone interested can take a look at: http://git.kernel.org/?p=linux/kernel/git/maz/ael-kernel.git;a=shortlog;h=refs/heads/ael-11.06 or http://git.linaro.org/gitweb?p=people/dmart/linux-2.6-arm.git;a=shortlog;h=refs/heads/arm/linux-linaro-3.0%2Bael (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: > 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 debug. 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 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. [...] > 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 been identified. 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 discarded. This also feels like something we can consider later though; it isn't required for single zImage to work. Cheers ---Dave _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
