Session topics for Linaro connect
dave.martin at linaro.org
Thu Sep 22 17:44:28 UTC 2011
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.
More information about the linaro-kernel