[U-Boot] Minutes from the U-Boot Mini Summit 2013
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
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
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
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.
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
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
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
participants (5)
-
Detlev Zundel -
Dirk Behme -
Nobuhiro Iwamatsu -
Stephen Warren -
Wolfgang Denk