Session topics for Linaro connect

[Dave Martin]

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 at 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