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

[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

[U-Boot] Configuring U-Boot through device tree (was: Minutes from the U-Boot Mini Summit 2013)

[Dirk Behme]

Am 27.10.2013 18:07, schrieb Detlev Zundel:
...
> ** 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.

At ELCE, I attended the Barebox presentation. One Barebox feature 
presented there was "Configure Barbox through device tree". So the 
Barebox people seem to have this already running for some selected 
boards. After their presentation I asked them "how do you decide which 
parts are configured in the boot loader, and which in the kernel, 
then?". And got the quick answer "in doubt, the configuration is done 
two times".

Do we really want this?

If we use the same device tree for U-Boot and the Linux kernel (which 
most probably makes sense) do we really want to do the initialization 
part we do already in U-Boot again in the kernel?

I'm thinking about pin mux or clock settings described in the device 
tree, which are need to get the U-Boot drivers working. If these are 
done two times, then, what's about the risk of clock or pin glitches 
doing the same configuration in the kernel a second time?

Do we need a mechanism to do some configuration only at one place? Or 
isn't there any risk and we can do the same configuration two times? 
What do you think?

Best regards

Dirk

[U-Boot] Configuring U-Boot through device tree (was: Minutes from the U-Boot Mini Summit 2013)

[Wolfgang Denk]

Dear Dirk,

In message <526E9740.3070204@gmail.com> you wrote:
>
> At ELCE, I attended the Barebox presentation. One Barebox feature 
> presented there was "Configure Barbox through device tree". So the 
> Barebox people seem to have this already running for some selected 
> boards. After their presentation I asked them "how do you decide which 
> parts are configured in the boot loader, and which in the kernel, 
> then?". And got the quick answer "in doubt, the configuration is done 
> two times".
> 
> Do we really want this?

Well, basically yes, we have to do this.

> If we use the same device tree for U-Boot and the Linux kernel (which 
> most probably makes sense) do we really want to do the initialization 
> part we do already in U-Boot again in the kernel?

We may not want to do it, but in general there is no way around it if
you do not want to establish strong interdependencies of a kernel port
for some hardware and a specific boot loader for that system - which
is generally considered a bad idea.

It has always been a good idea for a device driver to not make any
assumptions about the previous state of the hardware, and to perform
all required initializations.  In some cases this may be redundant
overhead, in other cases it may be mandatory.  We have seen cases (in
real life) where certain pieces of the hardware have been used in
different, incompatible configurations (say, the SCC port on a
PowerQUICC CPU first as a serial port, then as an Ethenret port, and
then again as serial) by using loadable modules.  In such cases you
cannot rely on any previous settings being passed on by the boot
loader.  Today, where even the hardware can be reconfigured under your
feet (see for example Altera's SOCFPGA or Xilinx' Zynq) this may
become even more important.

Also, I still believe it is a Good Thing (TM) for a boot loader to
only initialize such hardware that it actually uses itself (the reasons
have been discussed often before).   One more reason for Linux drivers
not to assume that all necessary initialization was already done.

Actually the same is true vice versa: the boot loader cannot know
which drivers the Linux kernel will be running.  We cannot simply turn
on clocks in U-Boot based on the hope they might be useful for Linux,
while the system will actually be running an application profile tuned
for lowest possible power consumption, so we ruin their setup, or
force re-init anyway.

> I'm thinking about pin mux or clock settings described in the device 
> tree, which are need to get the U-Boot drivers working. If these are 
> done two times, then, what's about the risk of clock or pin glitches 
> doing the same configuration in the kernel a second time?

I agree that such things need to be done really carefully to avoid
such problems - but actually these are not really new.  You have to
apply the same care for the initialization already now.

> Do we need a mechanism to do some configuration only at one place? Or 
> isn't there any risk and we can do the same configuration two times? 
> What do you think?

I think any such discussion depends on the answer of a few other
questions:

* Will the Linux kernel accept to depend on specific features of a
  specific boot loader?

* Who is reponsible to define the interface between the kernel and the
  boot loader, i. e. for the decision which interfaces shall be
  initialized, and how?

* What is the API for such communication between Linux and U-Boot?
  Do we have a way to tell Linux about already initiualized interfaces
  (and eventually even as important: about their state)?  How do we
  pass error status information to Linux?


Hm... while writing this my feeling that this will simply not work
deepens.  I guess, if you want to minimize overlap of activities, you
will probably head for setups like SPL in Falcon Mode, where (in
production mode) the overlap is at least minimized.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Boss, n.: According to the Oxford English Dictionary, in  the  Middle
Ages  the  words  "boss"  and "botch" were largely synonymous, except
that boss, in addition to meaning  "a  supervisor  of  workers"  also
meant "an ornamental stud."

[U-Boot] Configuring U-Boot through device tree

[Stephen Warren]

On 10/28/2013 10:56 AM, Dirk Behme wrote:
> Am 27.10.2013 18:07, schrieb Detlev Zundel:
> ...
>> ** 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.
> 
> At ELCE, I attended the Barebox presentation. One Barebox feature
> presented there was "Configure Barbox through device tree". So the
> Barebox people seem to have this already running for some selected
> boards. After their presentation I asked them "how do you decide which
> parts are configured in the boot loader, and which in the kernel,
> then?". And got the quick answer "in doubt, the configuration is done
> two times".
> 
> Do we really want this?
> 
> If we use the same device tree for U-Boot and the Linux kernel (which
> most probably makes sense)

If the same DT (schema at least) isn't used for all SW running on the
HW, then you aren't doing DT, but simply something that looks like it.

> do we really want to do the initialization
> part we do already in U-Boot again in the kernel?

It's possible to put all the e.g. one-time pinmux setup into the U-Boot
DT and strip it out of the kernel DT. This would prevent it being
applied twice. Of course, you can only do this once you're sure that
U-Boot is actually parsing the pinmux from DT and applying it, which
isn't the case yet. And since that requires a newer U-Boot, you probably
don't want to assume this by default in the kernel DTs; leave this to
people to do locally if they care about the extra few micro seconds.

The important thing is to use the same schema for all DTs, more than use
the exact same DT binary. For example, the kernel might have more
devices/nodes present if you want to enable more functionality, but you
might want to strip down the set of devices that are enabled in U-Boot
for simplicity.

[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@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

[U-Boot] U-Boot Mini Summit slides [was: Minutes from the U-Boot Mini Summit 2013]

[Detlev Zundel]

Hi,

[...]

> 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.

All slides have now been uploaded to our wiki area:

http://www.denx.de/wiki/U-Boot/MiniSummitELCE2013

Enjoy!
  Detlev

-- 
Do not add new functionality unless an implementor cannot complete a
real application without it.
                            -- principles of X Window System
--
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

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

[Detlev Zundel]

Hi,

[...]

> - Encourage custodians to delegate separable parts to new custodians
>   (Lukasz volunteered for USB DFU)

In the meantime we have setup a new repo for this custodianship[1] and
are happy that Lukasz takes on this new responsibility.

As discussed the other custodians are invited to propose comparable
split-offs to get the work into more manageable areas of
responsibility.

Cheers
  Detlev

[1] http://git.denx.de/?p=u-boot/u-boot-dfu.git;a=summary
-- 
Another helpful hint for successful MIME processing:

application/msword; rm -f %s; description="MS Word Text";
--
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