01 > ȸҰ
회사소개
|
제품쇼핑구매
|
자료실
|
고객지원
회사소개
|
회사개요
|
찾아오시는길
FPGA/CPLD
|
DSP/ARM
|
Others
|
부품
|
산업용보드
일반자료실
|
DSP/ARM
|
FPGA/CPLD
|
부품
|
산업용보드
공지사항
|
질문답변
|
구매안내
로그인
|
회원가입
|
장바구니
(0)
|
주문조회
|
마이페이지
:: 글답변 ::
이 름
패스워드
이메일
홈페이지
옵 션
html
제 목
> > > Xilinx maintains a public Git tree for each of its open source projects.This page will give you the information you need to start using those trees. The Git project is exquisitely documented. The online Git book is a must-read for any new user. You can find that documentation on Git's homepage here: > http://git-scm.com/documentation > > Installing Git > Binaries for all common operating systems and sources can be downloaded from the Git homepage. Alternatively your distribution may provide packages through its packet manager. > On Ubuntu, Git can be installed through > > apt-get install git git-email > > > Or, on Fedora run > > yum install git git-email > > > Git Repository Conventions > The repository system is divided into server/repository/branch. Each branch is designed to serve a particular community of interest. The community contains developers and testers. Interest is based on the needs of the group members. Device driver developers, for example, will be most interested in the latest development branch. Developers of user software and TRDs will want something that is more tested. This document should help you understand what branch you should be using for your work. It will also tell you how that branch will change over time. > > Branch Types > To pursue a common language to describe branches this document specifies type names that will help users distinguish between the branches in a repository. The type names will help indicate what community your work belongs to. The graphic shows the relationship between branch types. > > Development > A development branch is an integration area for a team of developers. Developers commit new code for features and bug fixes into development branches. The intended audience is developers. Development branch may have bugs but are expected to work. Since the development branch is the leading branch it's best to use it if you are interested in adding new work to the project. > > Stable > Stable branches are snapshots in time of development branches that are taken when the development branch is considered good. The intended audience of a stable branch is broader than the development branch. The stable branch should be used by those seeking cutting edge source who have projects that need good quality code. The stable repository exists to promote testing in a broader community with broader applications. > > Release > Release branches are snapshots in time of stable branches. Release branches represent Xilinx's best effort to provide high quality software. Release branches have the largest possible audience and are the place where most people should seek source from. > > Purpose > These branches belong to teams or individuals and are not managed explicitly in this system. While the main branches will march from development to release, purpose branches are not required to. In order for code developed in a purpose repository to be released it must be integrated into a development repository and go through the testing process. This work is left to the owner of the purpose branch. > > Xilinx Git Trees > Xilinx's Git trees can be browsed at http://git.xilinx.com. The two primary projects covered on this wiki are Linux and U-boot. Those projects contain two branches each. > > master Branch > The master branch is the name for the stable branch. The master branch is updated at the same time as the Xilinx CAD tools, four times per year. There may be exceptions when a bug is found that needs to be fixed outside of the normal release window. > > master-next Branch > The master-next branch is the name for the development branch. This branch is updated on a continuous basis. The version of software in the master-next branch is usually newer than the one in master. Though, for stability reasons the software version in master-next may not be the "latest and greatest" in the upstream projects. > > PetaLinux Branches > PetaLinux is Xilinx's commercial Linux distribution. If all of this talk about Git has made your head hurt, it's best you take a look at PetaLinux. PetaLinux makes it easy to use Linux on Xilinx technology and can be found on the web here. The PetaLinux branches are release branches. There is one PetaLinux branch for each release of PetaLinux. > > Tags > Git tags are a way to name a branch at a particular place in time. At Xilinx we tag the master branch each time a CAD software release is done. The tags correspond to the name of the CAD release. This is helpful for recreating instructions that came with the Xilinx software you are using. Say, for example, you are using an older version of the tools and you want to get the kernel that was released alongside that version; you would get the kernel with a tag that matched your release version. > > Fetching Source via HTTP > You don't need to have Git installed to get the source. If you would like the source of a snapshot as a zip file you can find direct download links on http://git.xilinx.com > > Fetching Source with Git > Fetching the whole source repository transfers the entire state of the project to your computer. Once complete you have all the source and complete history of the project. This requires much more bandwidth than a snapshot but is crucial for developers to be able to work. In most cases you will be able to get our Linux kernel by simply doing this: > > git clone git://git.xilinx.com/linux-xlnx.git > > You may run into issues if (like many of us) you're behind a corporate firewall. In that case you can try to fetch the sources using the http:// protocol. > > git clone http://git.xilinx.com/linux-xlnx.git > > If neither git:// nor http:// works, you may have to use a proxy to access an external Git server (see next section). > > Using Git through a Proxy > Corporate firewalls typically block the port that Git uses. Since many open source software developers work for a corporation Git has been designed to be easily proxied. When the Git git program sees that the environment variable GIT_PROXY_COMMAND is set it will make no attempt to communicate with the remote server. Instead it will launch the command in that variable and use that program's STDIN and STDOUT instead of a network socket. Programs like Netcat and Corkscrew can help Git with your proxy. > > Example: > > Place the following code into a script (be sure to make the script executable). > > #! /bin/bash > exec nc -5 -S <socks_proxy>:<port> $* > > > Now set the GIT_PROXY_COMMAND to point to your script: > > $ export GIT_PROXY_COMMAND=</path/to/script> > $ git clone git://git.xilinx.com/linux-xlnx.git > > > Creating A Git Patch > 1. Make a branch in the repository for the change you desire which is based on one of the original branches in the repository you cloned. This command creates the branch and makes it the active branch. Unless you plan to provide a hot-fix for a current release or stable version you should use the development branch (master-next) as base for your patch. > > git checkout –b <my_change> <branch base> > > Make the changes to any files or add new files and do your testing. > > 2. Set your email and your name for commit messages. Git creates a .gitconfig file in the directory specified by the HOME environment variable such that this only has to be done once. > > git config --global user.email johndoe@example.com > git config --global user.name 'John Doe' > > > 3. Add any modified files to your patch. > > git add <file> > > > 4. Review the changes that will be committed on the next commit command. In case something is wrong, like adding a wrong file, git status also provides hints on how to resolve issues. > > git status > > > 5. Commit the files that were changed and added into your local branch of your local repository. A commit should be done when a change is ready to be put in the repository. Keep the granularity of each commit small (a single functional change) as each commit will become a separate patch. > > git commit --signoff > > > You will be put into an editor to enter your commit message. There is a specific format that should be followed and illustrated below. > > In the following text, “[ ]” denotes a required field and “< >” is an optional field. > > [system]: [subsystem]: <descriptor>: [short summary] > blank line > Several lines: describing the specifics of the change > blank line > Signed-off-by: [your name] [<youremail@somewhere.com>] > > > Where: > > system = powerpc, microblaze, arm > subsystem = zynq > descriptor = the driver name, BSP, etc… > short summary = a short text summary of the change > Signed-off-by is the person making change (commit). This line is created automatically if the --signoff option is passed to 'git commit' and uses the identity configured in your .gitconfig. > > > Examine other commit messages to get an idea what may be appropriate values for the commit message fields of your patch. > > git log <path> > > > 6. Review the last commit. > > git show > > > 7. Generate patches for each commit in your branch. A patch file, named *.patch, is generated in the current directory. The following command generates a patch for each commit your commits. > > git format-patch <branch base> > > > 8. Send the email patch to git@xilinx.com for review and incorporation back into the Git tree. Using Git to send the email will ensure that it’s format is not altered by email clients such as Outlook. > > git send-email --to git@xilinx.com *.patch >
링크 #1
링크 #2
파일첨부
왼쪽의 글자를 입력하세요.