My list of topics/tasks for Linaro 11.11 cycle

[Grant Likely]

Hey Paul,

As promised, here is my list of topics, tasks and priorities for the
11.11 cycle.  It's a bit of a rough list, but I'll refine it as we get
closer to UDS

Boot Architecture
- Refine UEFI position paper (draft of position paper will be prepared
before UDS)
- Refine boot architecture technical recommendations paper (draft will
be prepared before UDS)
  - must include reference implementation (based on existing u-boot;
not talking about writing something new here)
  - Upgrade procedure for OS
  - Upgrade procedure for Firmware
  - Security concerns?
  - Must guarantee reliability (no bricked boards).
- Discuss kexec bootloader, possibly implement for 11.11 cycle
- Implement appending of device tree and initrd to zImage
  - To support minimal bootloader and kexec bootloaders.
  - Simplify the process of installing a boot image.
- Implement device tree bindings to describing boot method
  - So that Linux knows how to upgrade the kernel and possibly the bootloader.
    - SDcard?  NAND?  NOR?  Which partition?  etc.
I've got a lot of topics on boot architecture.  Most of the needed
technology is in place, but I think it is needed to document best
practices and methods that should be used when designing a system.
What technologies, why, how to put them together, and how to
maintain/support them.  It's important to get the guidelines out onto
paper instead of as 'tribal knowledge'

Device Tree
- device tree board description and implementations for:
  - The omap3 boards are the priority since there are numerous
expansion boards that can be described (Zippy, trainer, etc) which is
an excellent use-case.
  - mx51 & mx53 eval and efika boards
  - samsung eval boards
  - OMAP3 BeagleBoard, Overo and IGEP boards.
- device tree SoC descriptions for SoCs
  - A lot of work has already been done for Samsung and Freescale
SoCs.  It would be very interesting to converting an entire SoC over
to use device tree with dtb linked into the kernel for bootloaders
that cannot pass a dtb blob.  That would eliminate the problem of
duplicate setup paths
  - Would also need task to support linking multiple .dtbs into the kernel
- Complete clock bindings - mostly depends on common clock framework
- Complete virq implementation - **critical task**

Linux ARM Maintainership/Vision
- Full multiplatform - Support multiple SoC families with a single kernel
  - to avoid either/or decisions when adding new features to the kernel
  - have guidelines for how new interfaces should be defined.
Example: right now struct clk has a different implementation for every
SoC, and only one can be compiled in at a time.  New interfaces should
be runtime pluggable wherever possible
  - to increase code coverage for allyesconfig/allmodconfig.
- Document best practices for Linux driver model
  - Where does data come from (probed, device tree, platform_data)
  - How to generalize as much device registration as possible
  - How to get away from big lists of devices in board-*.c files.
  - How to reduce code duplication.
Basically, I'd like to encourage embedded Linux engineers to think
about the wider scope for the code that they write.  To ask themselves
if the work they are doing could be useful to the wider ARM Linux
infrastructure.  I'm not sure how to translate the above items into
blueprints, but I think the tasks resolve to writing a lot of
documentation and articles, and probably reviewing a lot of code.

You can probably take the first level bullet points in each category
as names for blueprints.  My priorities are to make sure at least one
platform has a 100% complete device tree implementation by the 11.11
release, and that there is a good set of documentation to go with it
covering both boot architecture and device tree.  I'd actually like to
see 2 or 3 platforms with a complete implementation, but I'd rather
see 1 platform will a full solution than 3 half baked ones.  Close
second is the boot architecture documentation and any associated
sample implementation.

Loïc, David, I'm sure I've missed some of the topics we've talked
about.  Is there anything else you can think of that should be added
to this list?

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.