On Thu, Sep 22, 2011 at 07:55:37AM -0600, Grant Likely wrote:
On Thu, Sep 22, 2011 at 7:21 AM, Dave Martin dave.martin@linaro.org wrote:
On Wed, Sep 21, 2011 at 04:09:19PM -0400, Nicolas Pitre wrote:
On Wed, 21 Sep 2011, Deepak Saxena wrote:
I'd like to gather a list of topics from everyone so that I can start creating the session blueprints that will be used by the scheduler and the notetaking system. My current list of topics:
- Single zImage (2 sessions?)
- Device Tree (2 sessions?)
- Blueprint/Work Item process
- eMMC 4.5/UFS
- Flash storage optimizations (follow up from last connect)
- Android Upstreaming
- Kernel CI Loop
Please provide any other ideas you may have.
UEFI / boot architecture, secure services API, etc.
Neon assisted in-kernel algorithms (CRC32, crypto, etc)
Early serial output facility (separate from CONFIG_DEBUG_LL)
[this may or may not be related to single zImage]
Should we add "early FDT parser" to that?
The current fact that we have a hardware description which is opaque to the early boot process seems to be a recurring problem for us, affecting zImage, low-level debug and some early board init code.
My idea would be to have a malloc-less parser which can pull individual nodes and properties out of the fdt blob, and resolve physical addresses. I feel that the amount of functionality required in order to make this useful is really quite modest.
We already have this for the zImage wrapper. The dtb append patches pull in libfdt which does what you're suggesting. However, we do need to add some parsing code for physical addresses.
Fair enough -- so there is work needed, but it is already partly done.
Cheers ---Dave