Hi Andrew and Andreas,
Thanks for taking this request seriously.
Let me assure you that both U-Boot and Linux are much less formal than FSF and require no paperwork to be signed first.
The formalism they both employ is this Signed-off-by or short Sob (see the DCO link above for details). The executive summary is, it records through whose hands a patch went and everyone along the chain certifying that they did not steal the code from some proprietary code base but either wrote it themselves or received it from a person that certified the same.
https://github.com/parallella/parallell ... lella-gen1https://github.com/parallella/parallell ... xcomm_zynqare lacking such
Signed-off-by: Name <email> lines, so that I can't take them, rebase them and submit them upstream, as I can't certify myself how those patches were created; and a patch without any Signed-off-by will be rejected.
I believe that Andreas as CEO or the respective commit authors could retroactively declare those changes to be signed off via a textual reply, e.g. here, with the line to be used in a submission process by external people such as me. An alternative would be for you to rewrite Git history using
git rebase -i and rewording each of your commit messages to end in such a line (not necessary if they rewrite patches against upstream changes on a different branch themselves anyway). For new commits your employees should please use
git commit -s to automate adding the Signed-off-by line to the commit message; and if people send you patches or pull requests you should keep an eye on them carrying a Signed-off-by - otherwise you will start facing this same issue yourself.
Personally I am still waiting for my pre-order, so I can't test beyond compilation at this point, and I have no previous experiences with other Zynq-based boards (it has been a stony path for the Raspberry Pi among others, trying to spare you that!). Both U-Boot and Linux have a tree-like maintenance model, i.e. to submit your
Linux fdt/config changes you would rebase them onto the Zynq maintainer's tree, send them via git-format-patch and/or git-send-email to the indicated person and mailing list (quoted from MAINTAINERS file above); the Zynq maintainer will review and, possibly after requesting cleanups, apply them to his tree and send a pull request to the ARM SoC tree at some point, from where its maintainer will send a pull request to Linus when the next merge window opens. Your job in that process is done once the first maintainer accepts your patches.
For
U-Boot, Custodians and trees are listed on their . I spot no Zynq/Xilinx-specific tree there, so that would probably mean using the generic ARM tree. Cf.
http://www.denx.de/wiki/U-Boot/PatchesI do not know which exactly are your dependencies in the ADI/Xilinx Linux trees, but I would hope that Xilinx changes are in the Zynq staging tree and on their way upstream (if not, remind the Xilinx guys like I reminded you!). There is no requirement for patches to be feature-complete with regards to hardware support, so you could split the device tree patch into an upstream-ready and an ADI-dependent part if necessary (hint:
git checkout -p). That will be easier to discuss looking at actual code rather than theory though. One difference I spotted between your Linux tree and Linus' one is that a zynq-7000.dtsi file is now being used for the SoC itself so that the board .dts file itself just has to indicate which of the chipset features are actually soldered to connectors, etc. and what external components are on the board (cf. zynq-zed.dts), making it even smaller and thus less code duplication to maintain long-term.
I just replied to Graham and will be looking forward to meeting you in Nuremberg.
Cheers,
Andreas
by afy » Sun Feb 09, 2014 12:42 am 
