Patches and Feature Requests

Before you begin to implement any new ideas or concepts it is always a good idea to present your plans on the u-boot-users mailing list. U-Boot supports a huge amount of very different systems, and it is often impossible for the individual developer to oversee the consequences of a specific change to all architectures. Discussing concepts early can help you to avoid spending effort on code which, when submitted as a patch, might be rejected and/or will need lots of rework because it does not fit for some reason. Early peer review is an important resource - use it.

A good introduction how to prepare for submitting patches can be found in the LWN article How to Get Your Change Into the Linux Kernel - the same rules apply to U-Boot, too:

• All patches must be sent to the u-boot@lists.denx.de mailing list.
• Patches should always contain exactly one complete logical change, i. e.
  • Changes that contain different, unrelated modifications shall be submitted as separate patches, one patch per changeset.
  • If one logical set of modifications affects or creates several files, all these changes shall be submitted in a single patch.
• Send your patches as plain text messages: no HTML, no MIME, no links, no compression, no attachments. Just plain text.
  The best way the generate patches is by using the "git format-patch" command.
  Please use the "master" branch of the mainline U-Boot git repository (git://git.denx.de/u-boot.git) as reference, unless (usually late in a release cycle) there has been an announcement to use the "next" branch of this repository instead.
• Make sure that your mailer does not mangle the patch by automatic changes like wrapping of longer lines etc.
  The best way to send patches is by not using your regular mail tool, but by using the "git send-email" command instead.
• Chose a meaningful Subject: - keep in mind that the Subject will also be visible as headline of your commit message. Make sure the subject does not exceed 60 characters or so.
• Include the string "PATCH" in the Subject: line of your message.
• In the message body, include a description of your changes.
  • For bug fixes: a description of the bug and how your patch fixes this bug. Please try to include a way of demonstrating that the patch actually fixes something.
  • For new features: a description of the feature and your implementation.
• If your description gets too long, that's a strong indication that you should split up your patch.
• Remember that there is a size limit of 100 kB on the mailing list. In most cases, you did something wrong if your patch exceeds this limit. Think again if you should not split it into separate logical parts. If your patch, uncompressed, exceeds this limit, and you are absolutely sure that you should not split it, then provide a URL (link) pointing to your patch instead. Make sure that the URL remains valid for a long time (i. e. years); using some "pastebin" etc. is not sufficient.
• Sign your changes, i. e. add a "Signed-off-by:" line to the message body.

If you have problems with your e-mail client, for example because it mangles white space or wraps long lines, then please read this article about Email Clients and Patches .

Note:

U-Boot is Free Software that can redistributed and/or modified under the terms of the GNU General Public License (GPL). Currently (July 2009) version 2 of the GPL applies. There are plans to move later versions of U-Boot to version 3 of the GPL, thus all new code that gets added to U-Boot shall use GPLv3-compatible licensing, for example using the common "GPL, either version 2, or (at your option) any later version" phrase.

Note 2:

All code must follow the U-Boot Coding Style requirements.

Note 3:

Before sending the patch, you must run the MAKEALL script on your patched source tree and make sure that no errors or warnings are reported for any of the boards. Well, at least not any more warnings than without your patch.

It is strongly recommended to verify that out-of-tree building (with "-O" -make_ option resp. "BUILD_DIR" environment variable) is still working. For example, run:

$ BUILD_DIR=/tmp/u-boot-build ./MAKEALL

Please also run MAKEALL for at least one other architecture than the one you made your modifications in.

Note 4:

If you modify existing code, make sure that your new code does not add to the memory footprint of the code. Remember: Small is beautiful! When adding new features, these should compile conditionally only (using the configuration system resp. #ifdef), and the resulting code with the new feature disabled must not need more memory than the old code without your modification.