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

[Nobuhiro Iwamatsu]

Hi,

I add more infomation about CI.

2013/10/28 Detlev Zundel <dzu at denx.de>:
> 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?

Site of kernel-next is
  http://kisskb.ellerman.id.au/kisskb/matrix/

We can see the results that auto-builder built the linux-next  and
linus/master every day on this site.
And m68k does not seem dead yet. Development for m68k have been made
yet in Debian, and it
will continue still the development of compiler and kernel, I think.

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

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6