[U-Boot] Minutes from the U-Boot Mini Summit 2013

[Detlev Zundel]

Hi,

it was a real pleasure to meet up with so many people on the ELCE in
Edinburgh the last few days.  Those of you who could not make it should
look out for the Embedded Linux Conference Europe in 2014.  Although not
yet finalized, we are optimistic to have the second U-Boot Mini Summit
there.

This years installation went very well and the very interesting
presentations sparked a lot of fruitful discussion extending into a very
intense session somewhat exceeding the official schedule.

As a base for further discussion on this list, as promised here are the
minutes recorded during that session (only slightly edited):

* Roadmap
- A consensus was reached to tackle these four major projects in the
  following order:

  Kconfig
  Driver Model
  Using Device tree more
  KBuild

** Kconfig (w/o KBuild)
- Change Makefiles to use KConfig
- What is the timeline for it?

** Driver model
- Introduce the driver model without changing all drivers at once
- At a certain stage require new drivers to adhere to the driver model
- What is the overhead of the driver model for SPL?
- SPL can use the driver model without device tree by binding devices
  to platform data, so SPL does not require device trees.
- U-Boot itself can also use platform data not only device trees to
  bind to devices, so device tree support is not mandatory
- Merge as soon as possible to be the first step

** Configuring U-Boot through device tree
- _What_ should be configured?
- Google requires every new U-Boot driver to be configured through
  device tree in U-Boot
- Configuring U-Boot through device trees shall aim for using the
  exact same tree from the Linux kernel.
- It is ok to keep a snapshot for the installed U-Boot
- dts files are kept within U-Boot repository

** SPL
- What minimal requirements do we want to support for SPL?
- FIT Support can be configured into SPL (can pretty sure be optimized)
- Enable device tree support in SPL?

** Misc
- Be more aggressive about removing unsupported/unused configurations
- Remove architectures where no uptodate toolchains are available
- Allow one experimental branch probably breaking configurations to try
  out new ideas
- Using LLVM should be fine after some compatible changes
- We want a way of assigning maintainership on a directory basis
  comparable to Linux kernel
- Encourage custodians to delegate separable parts to new custodians
  (Lukasz volunteered for USB DFU)
- Do we have a tool problem?  Yes, patchwork is a problem
- What are the perceived problems?
  - The "bundling" of patches is tedious or not workable.  
  - It is very hard to see changes late in a revision series (v8 vs. v9)
- Is there any existing tool that we can adopt?
- Is gerrit the solution to all our problems? No, it does not
  integrate bidirectional with the mailing list, i.e. gerrit sends
  mails to the ML and follow-ups from the ML are being picked up by gerrit.
- A "mythical non-existant" bidirectional gerrit seems to solve most problems
- Can patman be extended to support the review process?
- Can gerrit be used as an interim?  Patches originating in gerrit
  will send mails but followups cannot be picked up automatically and
  have to be processed manually.
- Vadim volunteered to send a How-To on gerrit usage to the ML
- If not, can we write one?
- UEFI support is not considered to be relevant now

** CI
- Adopt kernel toolchains used to build kernel-next for reference
  builds. What about OpenRISC? m68k?


A big thanks again to all participants of the discussion and I'm looking
forward to the followup threads ;)

Cheers
  Detlev

-- 
There are two hard things in computer science: cache invalidation,
naming things, and off-by-one errors.
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de