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.