Development Guide A basic understanding of Git is required. The notes referenced in the LSI wikis, [[Git Notes|Git]], are only quick notes, not an overview of Git. If you see anything that needs to be updated, send email to [email protected]

U-Boot Branches and Targets lsi-v2010.03 This is the branch for PowerPC support (3400 and 3500). All changes should build and boot Linux on all the targets described in the wiki (https://github.com/lsigithub/lsi_axxia_uboot/wiki/Readme_lsi-v2010.03). lsi-v2013.01.01 This is the branch for ARM support (5500). All changes should build and boot Linux on all the targets described in the wiki (https://github.com/lsigithub/lsi_axxia_uboot/wiki/Readme_lsiv2013.01.01).

Linux 3.4 Branches and Targets standard/lsi/base This is the branch for all Axxia support, PowerPC and ARM. All changes should build and boot on all supported targets. standard/preempt-rt/lsi/base Do not check anything in on this branch. You need to verify that the changes on standard/lsi/base merge cleanly and that once merged, the preempt-rt branch builds and boots on all supported targets. The default configurations for preempt-rt (arch/powerpc/configs/lsi_rt_defconfig and arch/arm/configs/lsi_rt_defconfig) is part of the standard/lsi/base branch. If the default configurations need to be changed, check the changes into the standard/lsi/base branch, not standard/lsi/preempt-rt/base.

1

Linux 3.10 Branches and Targets standard/lsi/base This is the branch for all Axxia support, PowerPC and ARM. All changes should build and boot on all supported targets. standard/preempt-rt/lsi/base Do not check anything in on this branch. You need to verify that the changes on standard/lsi/base merge cleanly and that once merged, the preempt-rt branch builds and boots on all supported targets. The default configurations for preempt-rt (arch/powerpc/configs/lsi_rt_defconfig and arch/arm/configs/lsi_rt_defconfig) is part of the standard/lsi/base branch. If the default configurations need to be changed, check the changes into the standard/lsi/base branch, not standard/lsi/preempt-rt/base.

Making Changes

1. Make all changes on a separate branch, never on one of the main branches. 2. Keep the separate branch up to date. There should be no conflicts or automatic merges required to merge the changes back to the main branch. ‘git rebase’ is useful here. 3. For all commits in the U-Boot, Linux, or Yocto trees, add the “–signoff” option and following the guidlines at http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelin 4. Follow the Linux coding style, https://www.kernel.org/doc/Documentation/CodingStyle or in your Linux source tree, Documentation/CodingStyle, for Linux and U-Boot. 5. Run scripts/checkpatch.pl (Linux) or tools/checkpatch.pl (U-Boot) before pushing. Note that checkpatch.pl requires a fairly recent version of perl, so you may have to use one of the newer hosts. • First make sure the files that you’re about to change are clean. Since we weren’t doing this initially, some cleanup may be required. Use “checkpatch.pl –file ” and clean up any errors or warnings. Check in these changes as a separate commit. • Make the changes needed and commit in logical units. 6. Make sure that, for all supported targets, the changes build and boot. 7. Push the branch to the repository and inform the gatekeeper when done.

2

Gatekeeper For a particular repository, at a particular time, someone will be the gatekeeper. Merging changes into one of the main branches should always be done by the gatekeeper.

An Example 1. Make the changes on a branch based on the branch the changes should eventually be merged into. 2. Run scripts/checkpatch.pl (Linux) or tools/checkpatch.pl (U-Boot). There should be no errors and few, if any, warnings. 3. Check that modified branch builds and boots on all supported targets. 4. Push the modified branch to the repository, and send the gatekeeper a merge request. 5. Once the changes have been merged, delete the modified branch both locally and remotely.

Document Version $Revision: 1.2 $ $Date: 2014/04/18 14:39:15 $

3

Development Guide - GitHub

Development Guide. A basic understanding of Git is required ... (3400 and 3500). All changes should build and boot Linux on all the targets described in the wiki.

125KB Sizes 5 Downloads 136 Views

Recommend Documents

Development manual - GitHub
BUSMASTER is located in a Git repository on the open source hosting platform ... version of the installer, e.g. Git-1.7.7-preview20111014.exe (as of 2011-10-26).

Nipype Beginner's Guide - GitHub
Aug 23, 2017 - 10. 11. #Specify experiment specifc parameters. 12 experiment_dir .... For a full list of software interfaces supported by Nipype go here ...... (http://www.fil.ion.ucl.ac.uk/spm/software/spm12/SPM12_Release_Notes.pdf) mention some im-

Modern OpenGL Guide - GitHub
There is no best library out there, because everyone has different needs .... Page 10 ... Building. After you've downloaded the GLFW binaries package from the website or ... Here is a simple snippet of code to check your build configuration:.

MultiMarkdown User's Guide - GitHub
Nov 9, 2010 - best description of what Markdown is comes from John Gruber's Markdown web site: ... including complete XHTML documents, LaTeX, PDF, RTF, or even (shudder) Microsoft ... In a blosxom8, Movable Type9, Oddmuse10, or other web site ......

Pawn Implementor's Guide - GitHub
or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA. ...... 3. call the public function with the "AMX address" */.

MIOpen Porting Guide - GitHub
cudnnCreateFilterDescriptor ( substituted by the respective. cudnnFilterDescriptor_t. TensorDescriptor APIs. * filterDesc). cudnnStatus t miopenstatus t. cudnnCreateConvolutionDescriptor (c miopenCreateConvolutionDescriptor. udnnConvolutionDescriptor

MultiMarkdown User's Guide - GitHub
Nov 9, 2010 - for Markdown's syntax is the format of plain text email. [1] ... including complete XHTML documents, LaTeX, PDF, RTF, or even (shudder) Microsoft ... Also, you can check out the MultiMarkdown discussion list: ...... At this time, Scrive

porting guide - GitHub
Mar 22, 2011 - This document describes the process of porting applications from ... Our development philosophy with BamTools so far has been to ... bool LocateIndex(const BamIndex::IndexType& preferredType = BamIndex::STANDARD);.