You can subscribe to this list here.
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(10) |
Oct
(29) |
Nov
(11) |
Dec
(9) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2014 |
Jan
|
Feb
|
Mar
(8) |
Apr
(2) |
May
(6) |
Jun
(5) |
Jul
(16) |
Aug
(6) |
Sep
(8) |
Oct
(6) |
Nov
|
Dec
|
| 2015 |
Jan
(1) |
Feb
(4) |
Mar
|
Apr
(5) |
May
(3) |
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(11) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: aaronwu1 <no...@do...> - 2013-11-28 03:48:53
|
New Revision: http://docs.blackfin.uclinux.org/doku.php?id=mcapi_bmp2jpg _demo Old Revision: http://docs.blackfin.uclinux.org/doku.php?id=mcapi_bmp2jpg _demo&rev=1385610113 Edit Summary: [Test method] @@ -3,11 +3,10 @@ This is a MCAPI dual core communication demo case for bf609. With the he lp of MCAPI, we can run general task on coreA with Linux, and run other CP U consuming tasks on coreB bear_metal environment. In this demo, coreA ope n a bmp file, which is captured from the USB camera, pass it to coreB to d ecode into jpeg. Once the encoding work is done, coreA get notified and co ntinue to save it as a jpeg file. This feature is available since 2013 rel ease. ===== Test method===== - First configure the kernel and buildroot distribution as other general M CAPI test case, as described in https://docs.blackfin.uclinux.org/doku.php ?id=test_icc + First configure the kernel and buildroot distribution as other general M CAPI test case, as described in https://docs.blackfin.uclinux.org/doku.php ?id=test_icc, configure to enable the USB camera following http://docs.b lackfin.uclinux.org/doku.php?id=linux-kernel:drivers:usb_video_device_cl ass, and select to enable the ffmpeg. - Then put a BMP file of 24bpp(or use this one directly: {{:test.zip|}})un der /bin of your target board, run following: load icc server to slave core <code> root:/> cd bin @@ -23,5 +22,5 @@ <code> root:/bin> bmp2jpg </code> - When the above is done, you should have a test.jpg file created in root directory of your target board. + When the above is done, you should have a test.jpg file created in /bin of your target board. |
|
From: aaronwu1 <no...@do...> - 2013-11-28 03:42:02
|
New Revision: http://docs.blackfin.uclinux.org/doku.php?id=mcapi_bmp2jpg _demo Old Revision: http://docs.blackfin.uclinux.org/doku.php?id=mcapi_bmp2jpg _demo&rev=1370504713 Edit Summary: [Brief introduction] @@ -1,7 +1,7 @@ ===== Brief introduction===== - This is a MCAPI dual core communication demo case for bf609. With the he lp of MCAPI, we can run general task on coreA with Linux, and run other CP U consuming tasks on coreB bear_metal environment. In this demo, coreA ope n a bmp file, and "through" it to coreB to decoding into jpeg, once the en coding work is done, coreA get notified and continue to save it as a jpeg file. This feature is available since July 2013 on buildroot trunk. + This is a MCAPI dual core communication demo case for bf609. With the he lp of MCAPI, we can run general task on coreA with Linux, and run other CP U consuming tasks on coreB bear_metal environment. In this demo, coreA ope n a bmp file, which is captured from the USB camera, pass it to coreB to d ecode into jpeg. Once the encoding work is done, coreA get notified and co ntinue to save it as a jpeg file. This feature is available since 2013 rel ease. ===== Test method===== First configure the kernel and buildroot distribution as other general M CAPI test case, as described in https://docs.blackfin.uclinux.org/doku.php ?id=test_icc |
|
From: grace <no...@19...> - 2013-11-18 08:46:45
|
New Revision: https://195.170.124.222/doku.php?id=bootloaders:u-boot:tes
ting
Old Revision: https://195.170.124.222/doku.php?id=bootloaders:u-boot:tes
ting&rev=1341993425
Edit Summary: [Added Feature Tests] update serial test for uboot
@@ -138,10 +138,10 @@
stamp> md.b 0x1000090</code>
- **Passing parameters from U-Boot to kernel**
* Passing parameters, such as root filesystem, ip address, from U-
Boot to kernel make it possible to dynamically switch the root file syste
m when boot the kernel without reconfiguration and rebuilding the linux im
age.
* Set the environment param bootargs of U-Boot to a new value. Boot
up to the linux kernel, and then execute cat /proc/cmdline to see if it i
s the value previously set. If so, it means the param has been passed by U
-Boot to kernel. Otherwise the case fails. The commands are (at U-Boot Pro
mpt):<code> stamp> set bootargs root=/dev/mtdblock0 rw ip=10.100.4.60
</code> At kernel prompt:<code> root> cat /proc/cmdline</code>
- - **Boot kernel uImage from serial port**(for BF537 board only)
- * To have kernel uImage downloaded from serial port /dev/ttyS0, whic
h supports BF534 board to boot up kernel.
+ - **Boot kernel uImage from serial port**
+ * To have kernel uImage downloaded from serial port /dev/ttyS0. Plea
se switch the start mode to the appropriate status.
* Start kermit, connect to target board, input loadb at U-boot promp
t, and then get back to kermit prompt by entering Ctrl-\ followed by C. Ty
pe send command with the linux uImage name. The serial transfer begins. It
normally lasts 4 minutes or so for 1.5M kernel uImage. The commands are(a
t shell prompt): <code>
root:~> kermit</code> There is kermit prompt now. At this kermit prompt:
<code>kermit> connect</code> Then it comes to target board u-boot prompt:
<code>stamp> loadb</code> Get back kermit by Ctrl-\ and C and enter <code>
kermit> send /tftpboot/uImage-beta</code>
- **Early Printk**
* Enable macro: #define CONFIG_DEBUG_EARLY_SERIAL.
|
|
From: grace <no...@19...> - 2013-11-18 08:39:48
|
New Revision: https://195.170.124.222/doku.php?id=linux-kernel:testing
Old Revision: https://195.170.124.222/doku.php?id=linux-kernel:testing&r
ev=1384761475
Edit Summary: [Kernel Function test] update icc/mcapi link
@@ -707,14 +707,14 @@
}</code>
- **Core B code loader**
* Use the utility corebld to load the binary to memory and start cor
e B for execution. Both C and C++ programs are tested.
* For details, please refer to the doc: [[:load_application_running_
in_bf561_core_b#load_standalone_program_to_core_b_in_uclinux|Load standalo
ne program to Core B in uClinux]]
- - **Intercore communication protocol on bf561 test**
- *Use the utility icc_loader to load the binary to core B, and run ap
p on coreA to communication with coreB via ICC
- *For details, please refer to the doc:[[:test_icc_on_bf561|test_icc_
on_bf561]]
- - **MCAPI on bf561 test**
- *MCAPI on top of icc implementation
- *For details, please refer to the doc:[[:test_mcapi_on_bf561|test_mc
api_on_bf561]]
+ - **Intercore communication protocol test**
+ *Use the utility icc_loader to load the binary to core B, and run ap
p on coreA to communication with coreB via ICC. This test is running on bf
561/bf609.
+ *For details, please refer to the doc:[[:test_icc|test_icc]]
+ - **MCAPI test**
+ *MCAPI on top of icc implementation for both bf561/bf609.
+ *For details, please refer to the doc:[[:test_mcapi|test_mcapi]]
- **Configurable kernel boot address**
* Give an option to set the user defined boot address in case there
is different sram settings.<code>
under Customize Kernel Settings
== Select Board customizations ==
|
|
From: grace <no...@19...> - 2013-11-18 07:58:03
|
New Revision: https://195.170.124.222/doku.php?id=linux-kernel:testing Old Revision: https://195.170.124.222/doku.php?id=linux-kernel:testing&r ev=1384760614 Edit Summary: [LTP test(WT,WB)] update ltp version @@ -19,11 +19,11 @@ You can get LTP source code from LTP website or get from our Linux svn. There are several versions of ltp source code in svn. Please checkout out the latested one. <code> svn ls svn://firewall-sources.blackfin.uclinux.org:80/svn/ltp/trunk - svn co svn://firewall-sources.blackfin.uclinux.org:80/svn/ltp/trunk/ltp- full-20071031 ltp-full-20071031 + svn co svn://firewall-sources.blackfin.uclinux.org:80/svn/ltp/trunk/ltp- full-20120903 ltp-full-20071031 </code> Enter the folder named ltp, there is a prog directory which is p orted for our blackfin testing. <code> - cd ltp-full-20071031/ + cd ltp-full-20120903/ make uclinux make uclinux_install </code> |
|
From: grace <no...@19...> - 2013-11-18 07:43:43
|
New Revision: https://195.170.124.222/doku.php?id=linux-kernel:testing Old Revision: https://195.170.124.222/doku.php?id=linux-kernel:testing&r ev=1366278404 Edit Summary: [Overview] update toolchain info @@ -4,11 +4,11 @@ ===== Overview===== To test the Linux kernel, a host system and Blackfin target are required . The host system is where the Linux source code is downloaded and built. The Blackfin target enables tests to be run on the real processor platform ensuring that the Linux kernel image can take control from uboot, initial ize the processor and peripherals, and operate the whole system properly. For now, the following types of target boards covered in this test: BF533- STAMP, BF537-STAMP, BF533-EZKIT, BF561-EZKIT, BF548-EZKIT, BF527-EZKIT, BF 538-EZKIT,BF526-EZBRD, BF518-EZBRD, BF609-EZKIT. For the detailed coverage info, see [[linux-kernel:testing:coverage|Linux_test_coverage]]. - Besides, in current release there are two versions of toolchain released , and each of it support compiling both elf and flat format applications. As a result, four kinds of kernel image could be generated in the host env ironment of Suse linux, flat format image by 4.1 toolchain, flat format im age by 4.3 toolchain, elf format image by 4.1 toolchain, elf format image by 4.3 toolchain. Also it needs to test the linux image built in the host environment of COLINUX. + Besides, in current release the 4.3 toolchain supports compiling both el f and flat format applications. As a result, two kinds of kernel image cou ld be generated in the host environment of Suse linux, flat format image b y 4.3 toolchain, elf format image by 4.3 toolchain. - The tests below would been carried out on kernel built by either 4.1 or 4.3 toolchain with various kernel configuration(flat format application). As to the elf toolchain, since the format just referrs to applications, on ly application related testcases would be executed. + The tests below would been carried out on kernel built by 4.3 toolchain with various kernel configuration(flat format application). As to the elf toolchain, since the format just referrs to applications, only application related testcases would be executed. And there is also some difference for certain cases to run on different boards, the following part would describe in detailed ways. In order to secure the kernel performance at all the working frequencies , the Linux kernel testing is needed to take at various system clock and c ore clock. The working range for the boards is about 30~120Mhz System Cloc k and 30~600Mhz Core Clock. |
|
From: sonicz <no...@bl...> - 2013-11-18 05:48:18
|
New Revision: https://blackfin.cosmocode.de/doku.php?id=main Old Revision: https://blackfin.cosmocode.de/doku.php?id=main&rev=13812 21307 Edit Summary: [Analog Devices Open Source Projects] @@ -9,9 +9,9 @@ ^Project ^Download ^Documentation ^Source ^Support ^Trackers ^ |[[sf>toolchain|GNU Toolchain]] |[[sf>toolchain/files|Releases]] |[[main #Analog Devices Open Source Document|Wiki]] |[[sfp>toolchain/blackfin|GIT] ] |[[ez>gnu-toolchain-blackfin|Help]] [[sfp>toolchain/mailman|Lists]] [[ht tp://ez.analog.com/community/dsp/software-and-development-tools/gnu-toolch ain-blackfin/gnu-toolchain-forum-archive|Legacy Forum]] |[[sfp>toolchain/t asks|Tasks]] [[sfp>toolchain/bugs|Bugs]] [[http://ez.analog.com/community/ dsp/software-and-development-tools/gnu-toolchain-blackfin/gnu-toolchain-bu g-archive|Legacy Bugs]] | |[[sf>linux|Linux Kernel]] | |[[main#Analog Devices Open Source Document |Wiki]] |[[sfp>linux/code|GIT]] |[[ez>linux-blackfin|Help]] [[sfp>buildroo t/mailman|Lists]] [[http://ez.analog.com/community/dsp/software-and-devel opment-tools/linux-blackfin/linux-forum-archive|Legacy Forum]] |[[sfp>buil droot/tasks|Tasks]] [[sfp>buildroot/bugs|Bugs]] [[http://ez.analog.com/com munity/dsp/software-and-development-tools/linux-blackfin/linux-bug-archive |Legacy Bugs]] | |[[sf>buildroot|Buildroot Distribution]] |[[sf>buildroot/files|Releases] ] |[[main#Analog Devices Open Source Document|Wiki]] [[presentations|Prese ntations]] |[[sfp>buildroot/code|GIT]] |[[ez>linux-blackfin|Help]] [[sfp>b uildroot/mailman|Lists]] [[http://ez.analog.com/community/dsp/software-and -development-tools/linux-blackfin/linux-forum-archive|Legacy Forum]] |[[sf p>buildroot/tasks|Tasks]] [[sfp>buildroot/bugs|Bugs]] [[http://ez.analog.c om/community/dsp/software-and-development-tools/linux-blackfin/linux-bug-a rchive|Legacy Bugs]]| - |[[sf>u-boot|Das U-boot]] |[[sf>u-boot/files|Releases]] |[[main#Analog D evices Open Source Document|Wiki]] |[[sfp>-u-boot/code|GIT]] |[[ez>uboot-b lackfin|Help]] [[sfp>u-boot/mailman|Lists]] [[http://ez.analog.com/communi ty/dsp/software-and-development-tools/uboot-blackfin/uboot-forum-archive|L egacy Forum]] |[[sfp>u-boot/tasks|Tasks]] [[sfp>u-boot/bugs|Bugs]] [[http: //ez.analog.com/community/dsp/software-and-development-tools/uboot-blackfi n/uboot-bug-archive|Legacy Bugs]]| + |[[sf>u-boot|Das U-boot]] |[[sf>u-boot/files|Releases]] |[[main#Analog D evices Open Source Document|Wiki]] |[[sfp>u-boot/code|GIT]] |[[ez>uboot-bl ackfin|Help]] [[sfp>u-boot/mailman|Lists]] [[http://ez.analog.com/communit y/dsp/software-and-development-tools/uboot-blackfin/uboot-forum-archive|Le gacy Forum]] |[[sfp>u-boot/tasks|Tasks]] [[sfp>u-boot/bugs|Bugs]] [[http:/ /ez.analog.com/community/dsp/software-and-development-tools/uboot-blackfin /uboot-bug-archive|Legacy Bugs]]| |[[http://sourceforge.net/projects/adiopshw|Hardware]] |[[http://sourcef orge.net/projects/adiopshw/files|Releases]] |[[main#Analog Devices Open So urce Document|Wiki]] [[buy_stuff|Purchase]] | |[[http://ez.analog.com/comm unity/dsp/blackfin-processors|Help]] | | |**uClinux Distribution is replaced by Buildroot Distribution since 2012 R2**|[[sf>buildroot/files/Legacy%20distribution%20with%20uClinux/|Releases ]] |[[uclinux_on_blackfin|Wiki]] | |[[http://ez.analog.com/community/dsp/s oftware-and-development-tools/linux-blackfin/legacy-forum-archive|Legacy F orum]] [[sfp>buildroot/mailman|Lists]] |[[http://ez.analog.com/community/d sp/software-and-development-tools/linux-blackfin/legacy-bugs-archive|Legac y Bugs]] | In order to get the most out of the new projects, you'll need to registe r a user account on sourceforge.net. This will allow you to participate fu lly in all we have to offer. You may of course browse these new projects w ithout registering, but will not have access to participate fully. |
|
From: sonicz <no...@bl...> - 2013-11-12 09:50:27
|
New Revision: https://blackfin.cosmocode.de/doku.php?id=version_control_ systems Old Revision: https://blackfin.cosmocode.de/doku.php?id=version_control_ systems&rev=1358434104 Edit Summary: Remove obsolete document @@ -1,7 +1,24 @@ ====== Version Control Systems ====== - The Blackfin open source project keeps its main project in Subversion (S VN). Some older projects may use CVS instead. + The ADI specific GNU toolchain, u-boot and buildroot Lniux distribution projects keep their source code in GIT. While the ADI specific Linux libra ries, applications and test suites are kept in Subversion (SVN). + + + ===== git ===== + + [[http://git.or.cz/|git]] is a fast distributed scm that is used in many open source projects but most notably, the Linux kernel. Unlike SVN/CVS, it has no centralized repository. + + All of the blackfin Linux projects except for the obsolete uClinux-dist switched to the new GIT repositories at [[http://blackfin.uclinux.org/]] f rom the SVN repositories. + + ==== Check out the ADI Linux projects ==== + + The sub directory will be called "u-boot": + + <xterm>$ **git clone git:%%//%%git.code.sf.net/p/adi-toolchain/blackfin toolchain**</xterm> + <xterm>$ **git clone git:%%//%%git.code.sf.net/p/adi-u-boot/code u-boot* *</xterm> + <xterm>$ **git clone git:%%//%%git.code.sf.net/p/adi-buildroot/code buil droot**</xterm> + + ===== Subversion ===== Subversion is touted as a replacement for **CVS**. @@ -15,50 +32,8 @@ * True version History An online book is available [[http://svnbook.red-bean.com]]. - ==== Firewalls ==== - - If you are behind a firewall, and can not access the subversion port, yo u can replace all the below instructions with a different machine name/por t. To test if this will be in the situation you are in - this is a direct connection to the internet (no firewall): - - <xterm>$ **telnet sources.blackfin.uclinux.org 3690** - Trying 204.50.165.247... - Connected to sources.blackfin.uclinux.org. - Escape character is '^]'. - ( success ( 1 2 ( ANONYMOUS ) ( edit-pipeline svndiff1 absent-entries ) ) ) Connection closed by foreign host.</xterm> - - This is the same with a firewall: - <xterm>$ **telnet sources.blackfin.uclinux.org 3690** - Trying 204.50.165.247...</xterm> - - By replacing the ''sources.blackfin.uclinux.org'' with ''firewall-source s.blackfin.uclinux.org:80'' the following command should work: - - <xterm>$ **svn checkout svn:%%//%%firewall-sources.blackfin.uclinux.org: 80/svn/u-boot/trunk u-boot**</xterm> - - And here is telnet with the proper firewall address (behind the firewall ): - <xterm>$ **telnet firewall-sources.blackfin.uclinux.org 80** - Trying 204.50.165.246... - Connected to firewall-sources.blackfin.uclinux.org. - Escape character is '^]'. - ( success ( 1 2 ( ANONYMOUS ) ( edit-pipeline svndiff1 absent-entries ) ) ) Connection closed by foreign host.</xterm> - - Some firewalls do content checking rather than simple port filtering. I f that's the case, then attempts to do svn over port 80 will probably fail . The firewall may let through encrypted traffic on port 443 though. - <xterm>$ **telnet firewall-sources.blackfin.uclinux.org 443** - Trying 204.50.165.246... - Connected to firewall-sources.blackfin.uclinux.org. - Escape character is '^]'. - SSH-2.0-OpenSSH_3.9p1</xterm> - - If you see the SSH version string (exact version information may differ) , then you can probably access via the anonymous user (password is ''anony mous'') and SSH. You will need to create an entry in your ~/.ssh/config f ile so it knows to go to port 443. - <xterm>$ **svn checkout svn+ssh:%%//%%anonymous@firewall-sources.blackfi n.uclinux.org/svn/u-boot/trunk u-boot**</xterm> - - Example ''~/.ssh/config'' entry: - <code> - Host firewall-sources.blackfin.uclinux.org - Port 443 - </code> - - If all of these methods fail, then sorry, there isn't anything we can do to help you. Complain to your IT department. ==== Packages ==== The source code for subversion itself is found at its homepage [[http:// subversion.tigris.org]]. @@ -66,23 +41,18 @@ Most popular distributions already have packages available for you. ==== Quick Start ==== - === Check out a Project === + === Check out the ADI open application project === - The sub directory will be called "u-boot": - - <xterm>$ **svn checkout svn:%%//%%firewall-sources.blackfin.uclinux.org: 80/svn/u-boot/trunk u-boot**</xterm> - - or + <xterm>$ **svn checkout svn:%%//%%svn.code.sf.net/p/adi-openapp/code/tru nk adi-open-app**</xterm> - <xterm>$ **svn checkout svn:%%//%%sources.blackfin.uclinux.org/svn/u-boo t/trunk u-boot**</xterm> === Initial actions === * find out what version you have checked out:<xterm>$ **svn info**</xt erm> - * find out what version upstream is at:<xterm>$ **svn info svn:%%//%%f irewall-sources.blackfin.uclinux.org:80/svn/linux-kernel/branches/2008R1** </xterm> - * look at the files that were updated upstream:<xterm>$ **svn log -v s vn:%%//%%firewall-sources.blackfin.uclinux.org:80/svn/linux-kernel/branche s/2008R1 | less**</xterm> + * find out what version upstream is at:<xterm>$ **svn info svn:%%//%%s vn.code.sf.net/p/adi-openapp/code/branch/2008R1**</xterm> + * look at the files that were updated upstream:<xterm>$ **svn log -v s vn:%%//%%svn.code.sf.net/p/adi-openapp/code/branches/2008R1 | less**</xter m> * bring your working copy up-to-date with the repository<xterm>$ **svn update**</xterm> * bring your working copy up-to-date with a specific revision in the r epository (this can upgrade or downgrade, depending on the revision you gi ve):<xterm>$ **svn update -r 5316**</xterm> * check the status of your local copy:<xterm>$ **svn st** 'A' Added @@ -114,170 +84,19 @@ While CVS requires you to use magic commands to create tags and branches , SVN has actual directories in the top level. So to create a branch in svn, you would: <code> - $ svn cp trunk branch/branch_R07R1 - $ svn commit -m 'add new 2007R1 branch' branch/branch_R07R1 + $ svn cp trunk branch/2013R1 + $ svn commit -m 'add new 2013R1 branch' branch/2013R1 </code> And to tag a release: <code> - $ svn cp branch/branch_R07R1 tags/R07R1-RC1 - $ svn commit -m 'tag new R07R1-RC1 release' tags/R07R1-RC1 + $ svn cp branch/2013R1 tags/2013R1-RC1 + $ svn commit -m 'tag new 2013R1-RC1 release' tags/2013R1-RC1 </code> - ==== Mirroring ==== - - Since the svn connection from ''blackfin.uclinux.org'' can be slow at ti mes, the best way of speeding this connection up, is to use a local mirror . To set up a local mirror, you can use [[http://rsync.samba.org/|rsync]]. This will provide you a local copy of the entire repository, which you ca n access much faster than ''blackfin.uclinux.org''. This is the recommende d way of doing things, as it puts less stress on the server, and will decr ease the overall bandwidth requirements. - - <note warning> The following instructions set up what some would call no t very secure - and it is not. These instructions are best suited for some thing that is not sitting on the internet, and only allow people that you are know and trust access.</note> - - To set up a local repository, do the following: - - Check to ensure you can talk to the rsync server on blackfin.uclinux .org<code> - $ rsync blackfin.uclinux.org:: - toolchain - jtag - ltp - multimedia - u-boot - uclinux-dist - linux-kernel - xmame - dokuwiki - </code>If port 873 is blocked on your firewall, there is no way to conne ct to the rsync server. - - Do an initial rsync the projects you are going to create local repos itories of -- remember that you only need to mirror the projects you actua lly care about. The first time that this is done, it can take a over two h ours per repository.<code> - /usr/bin/rsync -azv --delete --force blackfin.uclinux.org::u-boot /svnro ot/u-boot - /usr/bin/rsync -azv --delete --force blackfin.uclinux.org::toolchain /sv nroot/toolchain - /usr/bin/rsync -azv --delete --force blackfin.uclinux.org::jtag /svnroot /jtag - /usr/bin/rsync -azv --delete --force blackfin.uclinux.org::ltp /svnroot/ ltp - /usr/bin/rsync -azv --delete --force blackfin.uclinux.org::multimedia /s vnroot/multimedia - /usr/bin/rsync -azv --delete --force blackfin.uclinux.org::u-boot /svnro ot/u-boot - /usr/bin/rsync -azv --delete --force blackfin.uclinux.org::uclinux-dist /svnroot/uclinux-dist - /usr/bin/rsync -azv --delete --force blackfin.uclinux.org::linux-kernel /svnroot/linux-kernel - /usr/bin/rsync -azv --delete --force blackfin.uclinux.org::xmame /svnroo t/xmame - /usr/bin/rsync -azv --delete --force blackfin.uclinux.org::dokuwiki /svn root/dokuwiki - </code> - - after this is complete, you can check out code on the local machine with<code> - svn -q checkout file:///svnroot/toolchain/trunk toolchain - </code>Doing this will take less than 3 minutes, 38 seconds (on my machi ne, which uses RAID0), but it is **much** faster than downloading over the network. - <note tip> - This will only work if you use the same version of SVN as the server. C urrent version is 1.4.3 - </note> - - If you want to set svn up to give people local access to the reposit ory via a ''svn:'' protocol you must set up svn as a deamon to listen on y our network.<code> - svnserve -d -r /svnroot/ -R - </code> This causes ''svnserve'' to run in daemon (''-d'') mode (in the background) this will accept TCP/IP connections on the svn port (3690, by default - since 3690 is not a secure port, it does not need to be started as root) with the virtual root (''-r /svnroot/'') for repositories served by svnserve to be set to ''/svnroot'' (pathnames in URLs provided by the client will be interpreted relative to this root, and will not be allowed to escape this root), and to be read-only (''-R'') forcing all write opera tions to be forbidden (afterall it is a mirror). - - This allows checkouts to be done with <code> - svn -q checkout svn://192.168.0.4/toolchain/trunk toolchain - </code>Doing this will take less than 3 minutes, 25 seconds, showing the re is no appreciable difference between network, and local file access. If it is possible to check out a local mirror, please do so. - - - To keep rsync up to date, you can run this script. \\ Because rysnc can sometimes take over 60 minutes to complete, and we don't want to be ru nning more than one rsync at a time, this small shell script will make sur e that this is the only rsync connecting to a site with "blackfin" in the name (to make sure that the network does not become congested) before star ting the network transfer. It times out in 59 minutes, as we will be start ing it every 60 minutes with a cron job. Make a new file ''/usr/local/bin/ blackfin_rsync''<code> - #!/bin/sh - # This needs 1 argument - if [ $# -ne 1 ]; then - echo 1>&2 Usage: $0 repository_name - exit - fi - - # Set initial variables to zero - I=0 - - # This checks to see if rsync is running. - # $RUN will be set to 0 if it is not running - # - RUN=`/bin/ps -C rsync | grep -v PID | wc -l` - while [ "$RUN" -gt 0 ] - do - # This will put all the rsync process ID into a tmp file - # This assumes that the first parameter from ps is the PID - # - /bin/ps -C rsync | grep -v PID | awk '{print $1}' > /tmp/tmp_file - - # This will read the file into the pid[] array - typeset -i cnt=0 - while read line - do - pid[$cnt]=$line - ((cnt = cnt + 1 )) - done < /tmp/tmp_file - - typeset -i temp=0 - - # This checks to see if the rsync is running is going to a site - # with 'blackfin' in the address. If so, wait. Otherwise, skip it. - while [ "$temp" -ne "$cnt" ] - do - RUN=`ps ${pid[$temp]} | grep -v PID | grep blackfin | wc -l` - if [ "$RUN" -gt 0 ] ; then - break - fi - ((temp = temp + 1)) - done - - # Wait 1 minute - sleep 60 - I=$[I+1] - if [ "$I" -gt 59 ] ; then - # If waiting 59 minutes stop - rm /tmp/tmp_file - exit - fi - done - - rsync -az --delete --force blackfin.uclinux.org::$1 /svnroot/$1 - # rsync options are: - # -a archive mode, equivalent to -rlptgoD - # -r recurse into directories - # -l copy symlinks as symlinks - # -p preserve permissions - # -t preserve times - # -g preserve group - # -o preserve owner - # -D preserve devices - # -z compress file data - # --delete delete files that don't exist on sender - # --force force deletion of dirs even if not empty - </code>Ensure that this file has execute permissions with ''chmod +x /us r/local/bin/blackfin_rsync'' - - Add to the crontab, with ''crontab -e''. The following lines should be in your crontab file:<code> - #min hour day month dayofweek command - #0-59 0-23 1-32 1-12 0-7 - 0 * * * * /usr/local/bin/blackfin_rsync jtag - 10 * * * * /usr/local/bin/blackfin_rsync jtagto ols - 20 * * * * /usr/local/bin/blackfin_rsync uboot5 33 - 30 * * * * /usr/local/bin/blackfin_rsync uclinu x533 - 45 * * * * /usr/local/bin/blackfin_rsync gcc3 - </code>To reduce load on the server - use different times than this. If everyone uses the same times, it will have periods of intense activity (an d be slow for everyone), and then periods where it is sitting idle. - - Now your localhost mirror should be set up, so you can replace ''bla ckfin.uclinux.org'' with ''localhost''. Not only can this be used for a lo cal mirror, but you now can tell other people on the same subnet as you, t hat they can use your server to pull from. This will increase their bandwi dth, and reduce the overall load on the main server. - - You should use this script to checkout from your local lan:<code> - #!/bin/sh - - #Home - CVSSERVER=192.168.0.4 - - CHECKOUT=~/blackfin/trunk - mkdir -p $CHECKOUT - - DIST=uClinux-dist - KERNEL=$DIST/linux-2.6.x - UBOOT=u-boot - TOOLCHAIN=toolchain - - cd $CHECKOUT - - rm -rf $CHECKOUT/$DIST $CHECKOUT/$UBOOT $CHECKOUT/$TOOLCHAIN - - svn checkout --ignore-externals svn://$CVSSERVER/uclinux-dist/trunk $CHE CKOUT/$DIST - svn checkout svn://$CVSSERVER/linux-kernel/trunk $CHECKOUT/$KERNEL - svn checkout svn://$CVSSERVER/toolchain/trunk $CHECKOUT/$TOOLCHAIN - svn checkout svn://$CVSSERVER/u-boot/trunk $CHECKOUT/$UBOOT - - $CHECKOUT/$TOOLCHAIN/buildscript/BuildToolChain -s $CHECKOUT/$TOOLCHAIN -k $CHECKOUT/$KERNEL -u $CHECKOUT/$UBOOT/u-boot-1.1.6 -o $CHECKOUT/gcc4 -b $CHECKOUT/gcc-build -c 4.1 - </code>The ''--ignore-externals'' flag will ensure that the kernel repos itory at ''http://blackfin.uclinux.org'' will not used, but the local vers ion will be checked out, and put in the proper place. - - ===== git ===== - - [[http://git.or.cz/|git]] is a fast distributed scm that is used in many open source projects but most notably, the Linux kernel. Unlike SVN/CVS, it has no centralized repository. - All of the blackfin projects except for the uClinux-dist have switched t o GIT repository from the SVN repository at [[https://blackfin.uclinux.org /git/]]. ===== Quick References ===== Here's a quick reference for common commands and their counterparts in C VS, SVN, and git. Most commands are (purposefully) pretty much the same, but the little details are what nag you. |
|
From: jiez <no...@do...> - 2013-09-09 05:27:38
|
New Revision: http://docs.blackfin.uclinux.org/doku.php?id=hw:jtag:ice100b Old Revision: http://docs.blackfin.uclinux.org/doku.php?id=hw:jtag:ice100b&rev=1332448532 Edit Summary: [Upgrading firmware] @@ -13,9 +13,9 @@ In order to work with the open source tools, your ICE has to have a firmware version of at least ''1.0.7''. The firmware can be upgraded by using VisualDSP 5.0 update 8 or greater on a Windows machine or through latest UrJTAG. <note warning>The update takes about 3 minutes. After updating, the ICE-100B cable needs to be unplugged and reconnected to finish the updating process.</note> - Download the latest firmware for ICE-100B {{:hw:jtag:ice100b_firmware_2_0_7.zip|ice100b_firmware_2_0_7.zip}} and unzip it. + Download the latest firmware for ICE-100B {{:hw:jtag:ice100b_firmware_2_0_8.zip|ice100b_firmware_2_0_8.zip}} and unzip it. ==== Using VisualDSP ==== * Once installed, connect the ICE-100b via USB to the PC and install the device driver. * Open the VisualDSP++ Configurator and click the Test button. |
