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