[U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12

[Detlev Zundel]

Hi,

as promised, here are my expanded notes from the BoF meeting at LSM2012
last week.  It was a pleasure to get some core developers into one room
at the same time and discuss controversial topics without the health of
any one attendant being in jeopardy at any time, so thanks again to
everybody for making this meeting as successful as it was!

[Note that this text expresses my understanding of the topics and thus
may sometimes be slightly imprecise or bluntly wrong, so feel free to
correct me where due :) ]


* Tips on how to use JTAG to debug custom hardware that does
  not boot

Some experiences on how to recover bricked hardware with the help of
JTAG debuggers were exchanged.  Some recurring problems one should be
aware of in this area are:

 - Breakpoints on unintialized RAM
 - How to cope with relocation (e.g. reload symbols in gdb with an
   offset to the ELF symbol table as described in the Wiki)
 - Different system architectures, with different responsibilities to
   setup RAM
 - What is BootROM doing before U-Boot is running?  Analyze the system
   at hand with respect to its expected boot sequence before hooking
   into it with a debugger.

General rules seem to be hard to find for details as the early phases of
booting vary greatly over the range of supported hardware in U-Boot.


* U-Boot History visualized

The history of the U-Boot repository was shown visualized with the help
of the gource tool:

http://code.google.com/p/gource/

Unfortunately the movie shown was 2.4GiB in size and found to be
unsuitable for putting up on our webspace.  We will look into producing
a smaller version to publish.

It is visually clear from the short movie, that the U-Boot community and
the amount of interaction has grown substantially over time.  The sheer
amount of source files also grew in relation to that ;)

* Patman

As Simon Glass, the author of the 'patman' tool, was physically present,
he agreed to give a short introduction to this tool recently added to
the U-Boot repository:

http://git.denx.de/?p=u-boot.git;a=tree;f=tools/patman

In short, this tool allows to elegantly manage entire patch series over
multiple iterations and easily send them to the mailing list.
Controlled through meta-data included (but stripped from submission) in
the git commit messages, it helps formally verifying patch series with
checkpatch, tracking inter-submission changes and addressing the
relevant mail recipients.

It was agreed that the help to be gained from the tool was substantial
and that it should get more exhibition in the documentation and among
contributors.


* Conflict resolution: setting up a moderator procedure for
  unhappy submitters

A recent occurence on the mailing list where contributers were sent
through multiple rounds of patch submissions for non-obvious reasons was
used as a ground for discussing non-technical aspects of patch
submissions.  It was especially discussed that the privilege of being a
custodian in U-Boot also brings obligations that should be defined more
clearly.  Essentially we would like to see somewhat "enforceable" rights
for the "motor" of the project, i.e. for patch submitters.

For this we should extend our documentation to clearly cover
responsibility of custodiands.  Require making constructive (testable)
suggestions on how to get patch accepted when nak-ing patches for
example.  This can also be enforced by patch submitters by waiting for
clear and precise suggestions for re-work.

It was also found to be a good idea to document people willing to act as
"moderators" for unhappy contributers, i.e. who can look into problems
and try to moderate.  (I would volunteer to be such a moderator).

Currently the lack of any reaction whatsoever was identified to be a
very discouraging sign for contributors. One thing we could do is to
declare a "soft" time-limit (two weeks) that patches need to be looked
at.  After this time-limit, one could declare "backup-custodians" to
push patches to or merge patches into some "-staging" branch.  (What to
do with that branch then?) For this to work, custodians would need to
announce "off-times" which currently is not general consensus.


* Patchwork pros / cons

While talking about the patch submission process it became clear that
the handling through patchwork still has some unsolved problems, the
most obvious being the large backlog of patches in the archieve.

It was agreed that automatic marking of changes as accepted when changes
hit mainline would be a good thing.  There is some info on our wiki
available, although it is not clear who uses them:

http://www.denx.de/wiki/view/U-Boot/Patches#pwclient and
http://www.mail-archive.com/patchwork@lists.ozlabs.org/msg00057.html

A tool to automatically mark patches as superceded on newer versions
was also suggested to be very valuable.  

Unanswered questions:

- What can patman do automatically?
- Can gerrit help the workflow?

During the discussion it showed that many people believe that patches
outside the "regular" merge window are handled in-efficiently ending up
as large piles in patchwork.  It was agreed that rather then being a
"accept / don't accept" division, it should be a "accept into mainline /
accept into -next branches" split hopefully keeping the flow of incoming
patches more uninterrupted.  For this to work, every custodian would
open his own "-next" branch and start merging patches from the mailing
list resulting in patchwork becoming cleaner during "bug fix" phases.

It was discussed whether to do some "automatic" merging of these
per-custodian trees into a central next, but majority of people believed
that the patch handling process should remain as unchanged as possible
in sync with the "principle of least surprise".


* Continuous integration

Discussing such automatic merges, the need for continous integration
became apparant.  As mid- to longterm goals we would like to see
automatic builds shifting the requirement to "do MAKEALL" from
individual posters to (cheap) machine time.  One obstacle on this way is
the complexity of automatic builds for different architectures,
i.e. which toolchain to use and how to use them correctly.

It was agreed to be a good thing to collect Mike's cross-toolchains on
denx.de and ease running MAKEALL.  Especially add more switches to
MAKEALL for toolchain selection, log-, build- directories.  Turn
interpretation of environment variables into switches to be more in line
with "good unix practice".

Simon Glass mentioned that he is working on "buildman" which he will
present on the mailing list in due time.

(Probably I forgot to mention the eldk-switch tool explicitely that also
has a "database" to setup the ELDK environment for known targets:

http://git.denx.de/?p=eldk-switch.git;a=summary

Maybe it should be extended to cover other tool-chains also?)


* Sandbox

For people not being aware of the "user-space U-Boot", i.e. the sandbox
configuration, Simon Glass described actual use cases for it in his
work.  He used it as an excellent test bed for generic code and tests
not easy to setup on real hardware.  During the discussion it became
obvious that it may be a very good enabling tool for the "driver model"
changes to come.  It was also found to be a worthwhile aim to integrate
it into the DUTS framework. (I will look into that when time allows).


* U-Boot driver model

Having some more time on our hands, Marek Vasut was asked to
interactively present some aspects of his and his teams work for a
driver model.  Additional to the key concepts shown in his presentation
on thursday, it became clear that it would be extremely helpful if the
Linux and U-Boot driver model would be as close as possible to ease
porting _and_ maintenance of drivers from the former to the latter.  It
appears that the Linux driver model lacks the late initialization needed
by the U-Boot "initialize hardware only when needed" design goal.
Achieving it was one motivation to not simply "clone" the Linux driver
model.  Although this and other details were discussed very intensly, it
was more than obvious that a lot of current problems and limits of
scalability of our code base can be alleviated with a solid driver
model.  All participants agreed to more closely review the documents
available in Mareks git Repo:

git://git.denx.de/u-boot-marex.git (dm branch, doc/driver-model/)

Discussion of the driver model currently is hosted at a separate mailing list:

http://lists.denx.de/mailman/listinfo/u-boot-dm

Maybe the discussion should be moved completely to the "regular" users
mailing list.


* Followup Meetings

Most participants expressed interest into further meetings of the U-Boot
developers in the future, probably once a year.  We will actively look
for occassions more closely tied to the embedded community for this.

Ok, this was actually agreed on after the first couple of beers, but
still I believe it fits in here nicely ;)


* Organizational info

Attendants (in alphebetical order of first names)

Anatolij Gustschin
Detlev Zundel
Fabio Estevam
François Revol (Haiku project)
Marek Vasut
Mike Frysinger
Simon Glass
Stefan Roese
Stefano Babic
Tom Rini
Wolfgang Grandegger

I'm sorry that I missed the name of one other participant who uses
U-Boot on a re-implemented Atari ST (Hatari?) project and gave some
interesting "user" feedback on several topics.

Cheers
  Detlev

-- 
A language that doesn't affect the way you think about programming, is
not worth knowing.             -- Alan Perlis, Epigrams on Programming
--
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