Transwitch A2000 Development Board
This is a PRIVATE guide for how to use the A2000 board in a comfortable and productive Development environment. If something doesn't work or isn't covered in this guide, please keep the discussion limited to involved parties. Access to the git repositories is limited and being monitored; unauthorized access is a felony and will be prosecuted.
NEWS:
Some general notes on these instructions:
- They are a work in progress, though virtually complete. Just needs to have an a another engineer at Tensilica run through this procedure and make sure that we haven't missed anything.
- The following was tested on x86 machines running RedHat Fedora Core 5 and Fedora Core 9. Test done while using the Fedora 9 based kernel and the stable branch of the Xtensa kernel appear, so far, to be a bit better. Not seeing any compile errors while stressing the system with LTP, two compiles, two mplayers, hifitest, top, pstree, and top for the
first 18 hours; appears to be running perfect till then. No gcc commands or ssh sessions getting killed until almost a day of testing. Only the Unaligned memory access warning on gethostid01 that a staff engineer diagnosed as being a mistake in the gethostid01 LTP test program.
- NOTES for Tensilica and Transwitch Developers:
- [To be provided in the future]
Introduction
This document is addressed to developers who have received an A2000 prototyping board from Transwitch for Linux development and testing.
This document goes over the steps needed to set up the A2000 board for Linux development. To summarize:
- Setup the board. It likely comes with U-boot and a flash version of Linux pre-installed, ready to mount a linux root filesystem via NFS.
- Install git.
- Download buildroot and linux kernel trees, pre-configured and built for A2000 development.
- Setup a TFTP server to provide the linux kernel to U-Boot.
- Setup an NFS server to export a linux root file system.
- Setup the Linux kernel to boot from the root file system provided by the NFS server.
- Suggests a possible way to tailor the board for easy software development just before booting.
Once the development board is up and running, this document:
- Demonstrates two procedures for compiling, linking, and debugging applications in a productive development environment.
- Suggest how developers can add their code to buildroot and come up again with their same development environment.
All development is expected to be done on a Linux host. (One can in principle use Windows to develop target libraries. However, linking and subsequent steps need to be done in Linux.)
Downloading the Latest A2000 Buildroot and Kernel Snapshots
The A2000 development environment is maintained here in a source code version control system named 'git'. The git tools are useful when working with this development environment, though they are not strictly necessary. This document generally assumes the use of git, which provides more opportunities for modifying this environment as needed (e.g. building more optional buildroot packages). But points out alternatives to allow getting up and running without having to set it up.
Installing git
On Fedora git is usually available as a RPM and can be easily installed with YUM:
$ yum install git
$ yum install git-gui
$ yum install qgit
Alternatively, you should always be able to install git, by downloading a recent tarball from the official site. For example, cd to a location with enough disk space, and do:
$ wget http://www.kernel.org/pub/software/scm/git/git-1.6.5.tar.gz
Unpack the tarball, and make and install it. Here we show how to install it to your ~/bin directory:
$ gunzip git-1.6.5.tar.gz
$ tar xf git-1.6.5.tar
$ cd git-1.6.5
$ make
$ make install
The git makefile can be instructed to install git to /usr/local/bin as root for system wide access:
$ cp git-1.6.5.tar.gz /tmp
$ su
Password:
# cd /usr/local/src/
# mkdir git
# cd git
# cp /tmp/git-1.6.5.tar.gz .
# gunzip git-1.6.5.tar.gz
# tar xf git-1.6.5.tar
# cd git-1.6.5
# make prefix=/usr/local
# make install
See the 'INSTALL instruction at the top of the git src directory for details.
Using git provides easy access to the binaries used to bring up the A2000 development environment, and leaves in place the infrastructure to modify and build this environment should you wish to. Any changes to git-managed source trees are easily observed with the git tools.
Installing the Buildroot Snapshot
Note: The A2000 snapshot is in the process of being made and is only available to a few Tensilica and Transwitch Developers. You must use your linux-xtensa.org login user name and password and be in the txcc user group. If you don't have an account, and need one, write to:
- Pete Delaney> <piet@tensilica.com>,
- Marc Gauthier <marc@tensilica.com>,
- Suresh Kadavath <Suresh.Kadavath@transwitch.com>,
- Shimon Edelhaus <Shimon.Edelhaus@transwitch.com>, and
- Prasanna Rao <Prasanna.Rao@transwitch.com>
to receive a login user-name and initial password.
To install the buildroot environment (toolchain and root filesystem), cd to a location with a few GB of available disk space. It's recommended to keep the git repo's used for A2000 development together on a filesystem that is exported with NFS write permission. For this A2000 board wiki page we will use /exports/src/Transswitch/Development and set a tcsh environment variable 'A2000_ROOT' to refer to it. In this case you would do the following:
$ setenv A2000_ROOT /exports/src/Transswitch/Development $ mkdir -r $A2000_ROOT $ cd $A2000_ROOT $ git clone ssh+git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa-HiFi2-Snapshot.git
or
$ git clone ssh+git://user@git.linux-xtensa.org/git/buildroot/buildroot-xtensa-HiFi2-Snapshot.git
Ex:
$ git clone ssh+git://piet@git.linux-xtensa.org/git/buildroot/buildroot-xtensa-HiFi2-Snapshot.git $ git clone ssh+git://txcc@git.linux-xtensa.org/git/buildroot/buildroot-xtensa-HiFi2-Snapshot.git $ git clone ssh+git://ksuresh@git.linux-xtensa.org/git/buildroot/buildroot-xtensa-HiFi2-Snapshot.git $ git clone ssh+git://sunal@git.linux-xtensa.org/git/buildroot/buildroot-xtensa-HiFi2-Snapshot.git
$ ln -s buildroot-xtensa-HiFi2-Snapshot buildroot
$ cd buildroot
$ git branch --track TXCC_A2000_Stable origin/TXCC_A2000_Stable [NOTE: TXCC_A2000 Branch isn't currently booting, module problem with ttys]
$ git checkout TXCC_A2000_Stable
The last two lines checkout the latest branch (preconfigured for Development on the A2000 board). Outside of Tensilica this will take a rather long time due to the current limitation of using a single T1 line. Subsequent updates can be downloaded quickly using git-pull.
You can examine the tree (git repository) and its history visually using git gui. The git GUI is a faster and more convenient method for checking out the HiFi-2 snapshot. To check out the snapshot_2+SMP branch simply run the command 'git gui' and then pull down the branch->create menu. Next select <>Match Tracking Branch Name and click on origin/snapshot_2+SMP. Finally hit the Create Button.
$ git gui
[Branch] -> Create...
<> Match Tracking Branch Name
<> Tracking Branch
origin/TXCC-A2000_Stable [NOTE: TXCC_A2000 Branch isn't currently booting, module problem with ttys]
[Create]
[Repository]--> Quit
WARNING Currently it seems to be necessary for their to exist a symbolic pointer at /opt/buildroot to the location of the buildroot that your going to used. Packages like openssl have "/opt/buildroot" explicitly in the TXCC a2000_src. It's also convenient to have a symlink to the name of the git repo checked out to buildroot which we snuck in above.
$ cd $A2000_ROOT
$ ln -s buildroot-xtensa-HiFi2-Snapshot buildroot [Also done above when you checked out the git repo]
$ ln -s $TXCC_ROOT/buildroot /opt/buildroot
Your symlinks will end up looking like this:
$ cd /opt
$ ls -l buildroot
buildroot -> /exports/src/Transswitch/Development/buildroot-xtensa-HiFi2-Snapshot
$ cd $A2000_ROOT
$ ls -l buildroot
buildroot -> buildroot-xtensa-HiFi2-Snapshot
The following packages/utilities are needed on the Host machine for the build process. Please make sure that they are installed before proceeding further.
- help2man ---> use 'yum install help2man' to install. - automake ---> use 'yum install automake' to install.
Now is likely a good time to start your buildroot building, it will take a quite a while. We recommend starting with the default configurations and modifying them if need in the menuconfig menus.
Currently uClibc isn't adding -g to the uClibc compile options, so you likely want to do that one for now while initializing the menus:
$ cd $A2000_ROOT/buildroot
$ make menuconfig
$ make uclibc-menuconfig
uClibc development/debugging options --->
() Enter any extra CFLAGS to use to build uClibc
-g
(-g) Enter any extra CFLAGS to use to build uClibc
uClibc development/debugging options --->
Exit
yes
$ make busybox-menuconfig
Next fire off the buildroot build:
$ make |& tee Make.log
That could take a few hours to build, so now lets move on to the other git repos.
Installing and Building the Linux Kernel Snapshot (Not Locked)
To install the Linux kernel environment (kernel src, config, and HiFi-2 kernel U-Boot image), cd to a location with a few GB of available disk space. We recomend currently keeping all of the git repos together at the root of your TXCC workspace, TXCC_ROOT, and do:
$ cd $A2000_ROOT $ git clone git+ssh://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp-txcc.git
or
$ git clone git+ssh://user@git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp-txcc.git
$ cd xtensa-2.6.29-smp-txcc
$ git branch --track A2000 origin/A2000 $ git checkout A2000
As in the build root case, you can also checkout the branch easily from via git gui using the same procedure mentioned above.
NOTE: On some system, like Fedora Core 9, the tftpboot directory has been moved to /var/lib/tftpboot.
In this case we recommend that you just added a symbolic pointer from /etc to /var/lib/tftpboot:
$ su
# cd /etc
# ln -s /var/lib/tftpboot/ tftpboot
# ls -ld tftpboot
lrwxrwxrwx 1 root root 18 2009-11-23 21:14 tftpboot -> /var/lib/tftpboot/
#
Setting up a TFTP Server to provide the Linux kernel to U-Boot
The TFTP service is part of the xinetd and is installed on Fedora workstations. You can see that it's installed with the check config command which manages the /etc/rc.d/init.d startup scripts and with the yum search command:
$ chkconfig --list
NetworkManager 0:off 1:off 2:off 3:off 4:off 5:off 6:off
NetworkManagerDispatcher 0:off 1:off 2:off 3:off 4:off 5:off 6:off
acpid 0:off 1:off 2:off 3:on 4:on 5:on 6:off
.
.
.
xfs 0:off 1:off 2:on 3:on 4:on 5:on 6:off
xinetd 0:off 1:off 2:off 3:on 4:on 5:on 6:off
ypbind 0:off 1:off 2:off 3:on 4:on 5:on 6:off
yum 0:off 1:off 2:off 3:off 4:off 5:off 6:off
xinetd based services:
amanda: off
auth: off
.
.
.
rsync: off
tftp: on [NOTE that tftp is enabled]
time: off
time-udp: off
uucp: off
$
$
$
$ yum search tftp-server
Loading "installonlyn" plugin
Searching Packages:
.
.
.
Reading repository metadata in from local files
.
.
.
tftp-server.i386 0.41-1.2.1 installed [NOTE that tftp server is installed as part of the inet daemon]
Matched from:
tftp-server
The Trivial File Transfer Protocol (TFTP) is normally used only for
booting diskless workstations. The tftp-server package provides the
server for TFTP, which allows users to transfer files to and from a
remote machine. TFTP provides very little security, and should not be
enabled unless it is expressly needed. The TFTP server is run from
/etc/xinetd.d/tftp, and is disabled by default on Red Hat Linux systems.
$
TFTP is not normally enabled, to enable it just edit the file /etc/xinetd.d/tftp
and change the disable field to no:
# default: off
# description: The tftp server serves files using the trivial file transfer \
# protocol. The tftp protocol is often used to boot diskless \
# workstations, download configuration files to network-aware printers, \
# and to start the installation process for some operating systems.
service tftp
{
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd [NOTE: /var/lib/tftpboot on Fedora Core 9]
server_args = -s /tftpboot
disable = no
per_source = 11
cps = 100 2
flags = IPv4
}
Setting up an NFS Server to export the Root Filesystem
The A2000 board running Linux can mount its root file-system from flash or over NFS. Both file system were built using buildroot but a complete development filesystem is available for developers in a compressed cpio format file, and left in:
buildroot-xtensa-HiFi2-Snapshot/buildroot-xtensa-smp/binaries/HiFi-2/rootfs.xtensa_test_mmuhifi_c3.cpio.gz
We will also be adding two additional small files-systems to make your development environment more comfortable and less time consuming to get started:
/usr/default [Home Directory for user 'default'] /usr/local [File system to place enhancements not done by buildroot]
Pick a place on your workstation to export your boards file-systems and unpack the cpio and tar files.
For example here we will export three files-systems in /export:
/exports/a2000_root /exports/hifi-2_home_default /exports/hifi-2_usr_local
Here's and example of unpacking the three files-systems:
$ cd buildroot-xtensa-HiFi2-Snapshot/buildroot-xtensa-smp/binaries/HiFi-2 [Getting binary files in buildroot git repository] $ $ gunzip rootfs.xtensa_test_mmuhifi_c3.cpio.gz [Uncompressing file-system cpio file] $ gunzip a2000_home_default.tar.gz [Uncompress /home/default tar ball] $ gunzip a2000_usr_local.tar.gz [Uncompress /usr/local tar ball] $ $ WHERE=$PWD $ mkdir -p /exports/LINUX_ROOT.HiFi-2 $ $ cd /exports/a2000_root $ cpio -i < $WHERE/rootfs.xtensa_test_mmuhifi_c3.cpio $ $ cd /export $ tar xf a2000_home_default.tar [Tar in boards /home/default for export] $ tar xf a2000_usr_local.tar [Tar in boards /usr/local for export]
Next add two lines to /etc/exports:
/exports *(rw,no_root_squash,sync,no_wdelay) [Boards File-systems] /export *(rw,no_root_squash,sync,no_wdelay) [Buildroot source code]
and restart you nfs services:
$ /etc/rc.d/init.d/nfs restart
or
$ /sbin/chkconfig nfs on
The showmount command should show your NFS file systems now being exported:
$ showmount -e
Export list for mylinuxsystem.foobar.com:
/export *
/exports *
$
Configuring U-Boot to Boot Linux [Needs to be Updated for A2000 [Suresh?]
Your A2000 board should have arrived with U-Boot installed in the flash ready to use. If it fails to boot U-Boot or you happen to have a board without it there are instructions at http://wiki.linux-xtensa.org/index.php/Setting_up_U-Boot to make it easy to instal
Next, connect a serial interface to a text based terminal emulation program, set to 38400 bps, no parity, 1 stop bit, no handshaking. For an example of setting minicom for this, see here.
When you initially power on your LX200 board it will come with a very long wait period before booting and will be waiting to be configured. You can also hit one of the blue buttons next to the blue LED that's next to the PCI connector to reset the board.
The minicom session should look like the following:
U-Boot 1.4 (Mar 14 2010 - 15:44:29)
Board: A2000 CPU: Xtensa C1_LX21M_V2 at 400.00 MHz
SysRAM: 128 MB
1st DATAFLASH INFORMATION
DataFlash:MX25L12845E
Nb pages: 65536
Page Size: 256
Size=16777216 bytes
Logical address: 0x00000000
Nb Erase Blocks: 256
Erase Block Size: 65536
Area 0: 00000000 to 0007FFFF
Area 1: 00080000 to 00E7FFFF
Area 2: 00E80000 to 00FBFFFF
Area 3: 00FC0000 to 00FFFFFF
2nd DATAFLASH INFORMATION
DataFlash:MX25L12845E
Nb pages: 65536
Page Size: 256
Size=16777216 bytes
Logical address: 0x01000000
Nb Erase Blocks: 256
Erase Block Size: 65536
Area 0: 01000000 to 01FFFFFF
crc matched
In: serial
Out: serial
Err: serial
MAC 0: 00:22:33:44:55:66
IP: 192.168.11.237
GMAC0
Ethernet Link UP, Link Speed 1Gbps
Hit any key to stop autoboot: 0
U-Boot> printenv
bootcmd=fsload ${SPLoadAddr} /boot/linux_sp.elf;fsload ${NPLoadAddr} /boot/roses_np.bin; bootelf ${SPLoadAddr}
update_uboot=tftpboot ${UBootLoadAddr} ${uboot_img};erase ${UBootStart} ${UBootEnd};cp.b ${UBootLoadAddr} ${UBootStart} ${UBootSize};erase ${UBootCfgStart} ${UBoot}
bootdelay=5
baudrate=38400
ethaddr=00:22:33:44:55:66
netmask=255.255.255.0
uboot_img=boot_sflash.bin
fw_img=a2000_jffs
cmbd_img=refmta
cfg_img=a2000_config
sp_img=linux_sp.elf
np_img=roses_np.bin
resv2_img=flash2_image
resv3_img=flash3_or_flash4_image
resv4_img=flash3_or_flash4_image
tmpLoadAddr=0xD7000000
UBootLoadAddr=0xD6000000
SPLoadAddr=0xD5000000
NPLoadAddr=0xD7000000
UBootStart=0x00000000
UBootEnd=0x0007FFFF
UBootSize=0x00080000
FwStart=0x00080000
FwEnd=0x00E7FFFF
FwSize=0x00E00000
FwCfgStart=0x00E80000
FwCfgEnd=0x00FBFFFF
FwCfgSize=0x00140000
UBootCfgStart=0x00FC0000
UBootCfgEnd=0x00FFFFFF
UBootCfgSize=0x00040000
CmbdStart=0x00080000
CmbdEnd=0x00FBFFFF
CmbdSize=0x00F40000
Resv2Start=0x01000000
Resv2End=0x01FFFFFF
Resv3Start=0x02000000
Resv3End=0x02FFFFFF
Resv4Start=0x03000000
Resv4End=0x03FFFFFF
ResvSize=0x01000000
progjffs=tftp
imget=tftp
config=tftp
progjffs2=tftp
progjffs3=tftp
progjffs4=tftp
nwboot=tftp
ethact=GMAC0
gmac0_addr=00:22:33:44:55:66
gmac1_addr=00:22:33:44:55:67
gmac2_addr=00:22:33:44:55:68
ipaddr=192.168.11.237
serverip=192.168.11.55
bootargs=debug
stdin=serial
stdout=serial
stderr=serial
ver=U-Boot
Environment
U-Boot>
Here's how to configure U-Boot to automatically boot the Linux kernel on power-up (using the root file system exported over NFS as described further above).
You need to configure UBoot with the IP addresses that are practical in your environment. When using BOOTP or DHCP many of the IP addresses are in the DHCP
config file. Here we first present the simple case where all of the addresses are provided in the U-Boot environment variables:
U-Boot> setenv serverip 192.168.11.55 [TFTP server IP Address: My Workstation]
U-Boot> setenv nfsroot_server 192.168.11.55 [Root NFS Servers IP Address: My Workstation]
U-Boot> setenv ipaddr 192.168.11.237 [BOARD/TARGET IP address]
U-Boot> setenv netmask 255.255.255.0 [Network Mask for a Internet Class C local network]
U-Boot> setenv gatewayip 192.168.11.1 [Gateway address for default route]
U-Boot> setenv bootfile uImage.xtensa-2.6.29-smp.test_mmuhifi_c3 [File to fetch with TFTP and pass to bootm]
U-Boot> setenv root-path /export2/Transwitch/LINUX_ROOT [Location of root filesystem on NFS Server; Limit ~50 bytes]
U-Boot> setenv nfs_boot_args root=/dev/nfs rw nfsroot=${nfsroot_server}:${root-path} [NFS Args used in bootargs]
U-Boot> setenv hostname HiFi-2 [Hostname]
U-Boot> setenv nfsaddrs ${ipaddr}:${nfsroot_server}:${gatewayip}:${netmask}:${hostname} [IP addresses needed by NFS when not using DHCP or BOOTP]
U-Boot> setenv misc_boot_args debug coredump_filter=0xff [Enable kernel debug messages and core files on a SEGV sig]
U-boot> setenv bootargs console=ttyS0,38400 ip=${nfsaddrs} ${nfs_boot_args} ${misc_boot_args} [Args passed to Linux while booting with DHCP proto]
U-boot> setenv bootcmd tftpboot\; bootm [Boot Linux after fetching it with TFTP]
U-Boot> setenv bootdelay 5 [Delay 5 seconds before booting automatically]
U-Boot> setenv autostart yes [Boot automatically on power-up/reset]
U-Boot>
You can also set up your dhcp server with your domain information and boot with much less information and it's no longer necessary to edit the targets /etc/resolve.conf with your domain server information:
U-Boot> setenv bootargs_using_bootp console=ttyS0,38400 ip=bootp root=nfs coredump_filter=0xff [Args passed to Linux while booting with BOOTP proto] U-Boot> setenv bootargs_using_bootp console=ttyS0,38400 ip=dhcp root=nfs coredump_filter=0xff [Args passed to Linux while booting with DHCP proto]
If you want to boot with bootp or dhcp you may want your /etc/dhcp.conf file to look something like this:
allow bootp;
boot-unknown-clients off;
ignore unknown-clients;
not authoritative;
ddns-update-style ad-hoc;
option domain-name "hq.tensilica.com";
subnet 192.168.11.0 netmask 255.255.255.0 {
default-lease-time 2592000; # 30 days
max-lease-time 31557600; # 1 year
next-server = option dhcp-server-identifier;
option routers 192.168.11.1;
group {
use-host-decl-names on;
##
## RTOS13 192.168.11.105: HelloSoft LX200 SMP Board on Piet's Desk
## DIP Swithes for MAC: 1 2 3 4 5 6 7 8 ethaddr=00:50:C2:13:6f:0F
## Little Endian: 1 1 1 1 0 0 * *
## Running HiFi-2
##
## hifi2.hq.tensilica.com:192.168.11.105::0x9b0ba8c0
host hifi2 {
hardware ethernet 00:50:c2:13:6f:07;
fixed-address hifi2.hq.tensilica.com;
next-server pdelaney_fc5.hq.tensilica.com;
option root-path "/exports/LINUX_ROOT.HiFi-2
option domain-name "hq.tensilica.com";
option domain-name-servers 192.168.15.20,192.168.15.21;
}
}
}
For more information on setting up the Linux Kernel boot parameters see the http://www.linuxdocs.org/HOWTOs/BootPrompt-HOWTO-3.html webpage.
Tailoring your system prior to Booting
There are a few tweaks we mentioned that developers have found convenient to add to the the root file-system before booting. As an initial environment for developing we are suggesting to mounting /home/default and /usr/local files-systems which have a number of files useful for getting started.
$ cd /export/a2000_home_default $ ls -l drwxrwxrwx 12 root root 4096 Dec 1 23:33 Audio_Tests/ drwxr-xr-x 2 default default 4096 Oct 28 17:46 Files/ drwxr-xr-x 6 root root 4096 Dec 2 02:46 LTP_Test/ drwxr-xr-x 2 root root 4096 Nov 20 15:13 Music/ -rw-r--r-- 1 10415 10000 841 Nov 20 01:18 SSH_Keys drwxr-xr-x 2 root root 4096 Nov 13 12:14 Tests/ drwxr-xr-x 2 10415 10000 4096 Nov 19 23:23 hifitest/ drwxr-xr-x 5 root root 4096 Dec 2 05:33 mplayer_packages/ -rwxr-xr-x 1 10415 10000 544 Dec 2 03:01 save_root_files* -rw-r--r-- 1 root root 37888 Dec 2 03:13 saved_root_files.tar
Notice a file tar ball in the /home/default file system called saved_root_files.tar.
This is a tar file of files that developers have found convenient to add and replace on the root file system after
adding a new buildroot file system. Here is a list of the files and a brief explanation on why it's convenient to add or replace them:
root/.bash_profile [added 'ulimit -c unlimited to allow core dumps to be created]
root/.bashrc
etc/profile [added 'ulimit -c unlimited to allow core dumps to be created]
etc/fstab [Tells the system how to mount extra NFS file systems like /home/default]
etc/init.d/S90local [Mounts /home/default]
etc/resolv.conf [Your locations of DNS servers; used when your not using DHCP to boot the kernel]
[NOTE: restore symlink /etc/resolv.conf -> /proc/net/pnp if using DHCP]
etc/TZ [Your time zone, currently set to California TZ]
etc/dropbear/dropbear_rsa_host_key [Old DropBrer keys, useful if you prefer Dropbear of sshd]
etc/dropbear/dropbear_dss_host_key [Old DropBrer keys, useful if you prefer Dropbear of sshd]
etc/ssh_config [Typically tailored with things like allowing root logins via ssh]
etc/ssh_host_dsa_key [sshd keys - Takes 30 minutes to generate, saves time on initial boot]
etc/ssh_host_dsa_key.pub [sshd keys - Takes 30 minutes to generate, saves time on initial boot]
etc/ssh_host_key
etc/ssh_host_key.pub
etc/ssh_host_rsa_key
etc/ssh_host_rsa_key.pub
etc/sshd_config [Typically tailored with things like allowing root logins via ssh]
etc/rndc.key
etc/random-seed [Generated during 1st boot]
etc/passwd [Changed root and default user's shell to bash; runs std bash RC files to set ulimits; adds /usr/local/bin to search path]
etc/shadow [Changed default and root users login password to 'linux1', needed to ssh to the board]
exports/ [The path to where the board can mount extra file systems like /home/default.
usr/local [Makes /usr/local so it can be mounted on; it has local additions, including /usr/local/src]
codecs [Makes /codecs for a NFS partition with Tensilica HiFi-2 Codecs to be mounted; the file-system should contain ...
... /codecs/xa_hifi2_l32r_LE5_pic_mp3_dec_lib_3_1_api_1_15_lib.tgz
... /codecs/xa_hifi2_l32r_LE5_pic_aacplus_v2_dec_lib_2_2_api_1_15_lib.tgz ]
Now lets assume your going to stay with mosts of these changes and modify a few of them after tar'ing in these changes to the root file-system. So here we add the tar ball files to the boards root filesystem.
$ cd /exports/a2000_root $ tar xf /exports/a2000_home_default/saved_root_files.tar
This is a good time to edit a few files on the boards file system before booting it.
$ cd /exports/a2000_root
$ vi etc/resolv.conf [Place your domain information if not using a DHCP boot]
[Restore symlink resolv.conf -> /proc/net/pnp if using DHCP]
$ vi etc/fstab [Change fstab entry for boards root filesystem, and others to your taste]
$ vi etc/init.d/S90local [You might want to disable mounting of non-root NFS file systems ...
... on the 1st Boot and add this once you try it manually]
Booting Linux for the 1st Time
We should now be ready to boot linux on your A2000. You have exported the root file-system and made the kernel available to a TFTP server. Now let's start with hitting the reset button on the A2000 and it should auto-boot the kernel, resulting in output such as this example log.
Tailoring your system prior to developing for A2000
To make your experience more pleasant we suggest you tailoring your environment. Here are some of the changes that we have found helpful and provided in the saved_root_files:
1. Added a root password to that you can login with ssh.
2. Running rdate with an ntp server on booting.
3. Adding NFS mounts to /etc/fstab for your code and buildroot code.
4. Copy in previous ssh server encryption keys to /etc/dropbear to speed up your initial boot.
5. Mount a 'default' user home directory with:
a. Linux Test Suite pre-patch to test the system
b. Audio test example files
c. Copies of Mplayer and its Plug-in build environment from Buildroot modified slightly to make installation easy.
d. Misc audio test programs.
6. Mounting Tensilica HiFi-2 Codecs to easily get mplayer working with HiFi-2 TIE instructions.
Building Linux Applications
Building Linux Applications Using GCC on the Host
You can use the open source toolchain included in the buildroot tree.
Given the location of the buildroot tree and the name of the core:
$ setenv BUILDROOT_DIR /export/src/HiFi-2_DemoBoard/buildroot-xtensa-HiFi2-Snapshot.12 $ setenv CORENAME centillium_c1p600
You can either set the PATH and invoke tools prefixed with xtensa_${CORENAME}-linux- :
$ setenv PATH ${BUILDROOT_DIR}/build_xtensa_${CORENAME}/staging_dir/usr/bin:${PATH}
$ xtensa_test_mmuhifi_c3-linux-gcc -g hello.c -o hello
$ xtensa_test_mmuhifi_c3-linux-gdb hello
or alternatively invoke the tools with absolute paths:
$ ${BUILDROOT_DIR}/build_xtensa_test_mmuhifi_c3/staging_dir/usr/bin/xtensa_test_mmuhifi_c3-linux-gcc -g hello.c -o hello
$ ${BUILDROOT_DIR}/build_xtensa_test_mmuhifi_c3/staging_dir/usr/bin/xtensa_test_mmuhifi_c3-linux-gdb hello
Building Linux Applications Using GCC on the Target
This is the simplest. (Much slower of course at 45 MHz across a slow Ethernet link than on a workstation, but very convenient.) Just login to the target system and use the native gcc.
Building Linux Applications Using XCC (Xtensa Tools)
There are two approaches to compiling with Tensilica's XCC compiler (part of Xtensa Tools). The normal one, described below, is to initially setup a virtual core that has built-in references to the library and include files for the target Linux system. Alternatively, one could skip this initial setup and just use Xtensa Tools to create object files and link them using host or target GCC tools. However, such objects must be built without dependencies on such things as the C library, which can be harder than it sounds (for example, flags and structures, such as open()'s O_EXCL and stat()'s struct stat, must be avoided because their definitions likely differ between the Xtensa Tools' default C library and the Linux uClibc library). (Note: Code written in C with TIE extensions and can only be compiled with XCC.)
Section 4.3 of the latest Xtensa OSKit Guide (from Tensilica's
RC-2009.0 release) describes how to setup XCC to compile Linux applications.
For full details, see the guide. A summary follows.
Initial Setup
The XTENSA_TOOLS_ROOT, XTENSA_ROOT, BUILDROOT_DIR, and TARGET_SYSROOT environment variables must be set according to where things were installed; values shown here are for illustration only. The CORENAME variable, set correctly below for this board, reflects the name of the core as known to open source tools (as opposed to XTENSA_CORE which is the core name as known to Xtensa Tools; both happen to match here).
$ setenv USER someuser
$ setenv XTENSA_ROOT /home/${USER}/Xplorer/XtDevTools/install/builds/RC-2009.0-linux/test_mmuhifi_c3
$ setenv XTENSA_TOOLS_ROOT /home/${USER}/Xplorer/XtDevTools/install/tools/RC-2009.0-linux/XtensaTools
$ setenv TARGET_SYSROOT /exports/LINUX_ROOT.HiFi-2
$ setenv BUILDROOT_DIR /export/src/HiFi-2_DemoBoard/buildroot-xtensa-HiFi2-Snapshot
$ setenv CORENAME centillium_c1p600
$ cd ${BUILDROOT_DIR}
$ ${XTENSA_ROOT}/xtensa-elf/src/linux/bin/xt-xcc-linux-install \
--sysroot=./build_xtensa_${CORENAME}/staging_dir \
--linux-gcc=./build_xtensa_${CORENAME}/staging_dir/usr/bin/xtensa_${CORENAME}-linux-gcc
Regular Use
Assuming the above completed successfully, you can now build applications using Xtensa Tools. First set the usual environment variables (assuming values of XTENSA_ROOT and XTENSA_TOOLS_ROOT used earlier):
$ setenv XTENSA_CORE default
$ setenv XTENSA_SYSTEM ${XTENSA_ROOT}-linux/config
$ setenv PATH ${XTENSA_TOOLS_ROOT}/bin:${PATH}
Now you can use Xtensa Tools to assemble, compile, and link applications for the Linux target specified during setup. For example:
$ echo '#include <stdio.h>' > hello.c
$ echo 'int main() {printf("Hello!\\n");return 0;}' >> hello.c
$ xt-xcc -g hello.c -o hello
Then copy it where the target can see it:
$ cp hello ${TARGET_SYSROOT}/root [NOTE: This step isn't necessary if your src file system is mounted on the targer; Ex: /export]
And run it on the target:
[root@hifi ~]# /root/hello Hello! [root@hifi ~]#
Here's a more interesting example that uses Tensilica TIE features. [NOTE: WE need a FLIX example] (This cannot be compiled using GCC.)
$ cd ${TARGET_SYSROOT}/home/default/Audio_Tests
$ xt-xcc -g hifitest.c -o hifitest
In a ssh termulator window on the board you can now run hifitest:
[root@hifi ~]# cd /home/default/Audio_Tests/ [root@hifi Audio_Tests]# ./hifitest cnt:0x0, pid:23178; Eatting cpu; time:0 <control-C> [root@hifi Audio_Tests]#
Here is the source code for the hifitest.c source file used above.
Limited (No Setup) Use of Xtensa Tools for Linux Targets
Below we illustrate compiling a simple audio test program on a workstation. We start by referring to the XTENSA tools build by Xplorer, putting XCC into our search path and set the standard XTENSA_* environment variables. For example:
setenv XTENSA_CORE centillium_c1p600
setenv XTENSA_ROOT /home/pdelaney/Xplorer/XtDevTools/install/builds/RC-2009.0-linux/centillium_c1p600
setenv XTENSA_SYSTEM /home/pdelaney/Xplorer/XtDevTools/install/builds/RC-2009.0-linux/centillium_c1p600/config
setenv XTENSA_TOOLS /home/pdelaney/Xplorer/XtDevTools/install/tools/RC-2009.0-linux/XtensaTools/bin
setenv PATH ${XTENSA_TOOLS}:${PATH}
[piet@fc9desktop Tests] $ cd /exports/hifi-2_home_default/Audio_Tests [NOTE: This is being done on a Workstation]
[piet@fc9desktop Audio_Tests]$ xt-xcc -g3 -O0 -fPIC -c hifitest.c
Next we link the object on the LX200 board and run gdb on the TIE enhanced code:
[root@hifi Audio_Tests]# gcc -g hifitest.o -o hifitest [REMIND: Replace with a FLIX Example Test]
[root@hifi Audio_Tests]# ./hifitest
cnt:0x0, pid:4640; Eatting cpu; time:0
cnt:0x0, pid:4640; Eating Tie; time:7
^C
[root@hifi Audio_Tests]# gdb ./hifitest [NOTE: This is being done on the A2000 board; REMIND: update to a pthreads example]
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "xtensa_test_mmuhifi_c3-linux-uclibc"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) break main
Breakpoint 1 at 0x400401: file /exports/default/Audio_Tests/hifitest.c, line 20.
(gdb) run
Starting program: /home/default/Audio_Tests/hifitest
Breakpoint 1, main (argc=1, argv=0x3fb3fab4)
at /exports/default/Audio_Tests/hifitest.c:20
20 time_t time0 = time(NULL);
(gdb) step
21 time_t time1 = time(NULL);
Compiling Generic GPL Packages
For your development you may want to add a few GPL packages that you find helpful. This can be done on the LX200 just as you would on a normal workstation, though much slower. For example here we configure and build a few common GPL packages with the standard:
$ ssh root@hifi [root@hifi ~] # cd /usr/local/src [root@hifi src] # mkdir <package> [root@hifi src] # wget <url_to_package> [root@hifi src] # gunzip <package.tgz> [root@hifi src] # cd package [root@hifi <package> ] # .configure [root@hifi <package> ] # make [root@hifi <package> ] # make install
Here are two examples, the invaluable strace and vim GPL packages:
Building the Strace Package
Building the vim Package
This can be a useful effort prior to adding a package to buildroot or for compiling packages with debug enabled. For example on of our developers compiled uClibc with -g to debug problems in this package.
Adding Packages to Buildroot
Xtensa developers provide detailed instructions on building the root filesystem and the Linux kernel.
Building a comprehensive development environment with buildroot can be a challenging experience and worthy of providing some tips on process. Here are notes of the configs used for the three menuconfigs in this 2nd snapshot provided with SMP additions:
$ make menuconfig $ make uclibc-menuconfig $ make busybox-menuconfig
[TO BE DONE - making a new tar ball of saved files, building buildroot, ...]
Known Problems being investigated, suggested that you know about and possibly avoid
1. Using NFS mounts with default parameters causes memory congestion. Use these mount options:
vers=2,rsize=4096,wsize=4096,hard,nointr,nolock,nolock,timeo=11,retrans=3,noauto
this is extremely important to add to your /etc/fstab on the target.
2. Can't swap over NFS yet, under extreme conditions memory can get tight and cause application to be killed.
a. We will be trying procedure documented in U-Boot Manual to swap over NFS.
i) See Section [TBD]
3. Building the complete C development with X11 doesn't work with buildroot.
4. Though Mplayer plug-in can be compiled, Mplayer can be compiled but still has a few issues:
a. Can't be compiled -O0 due to limited memory while compiling one file,
b. Compiler was crashing and make had to be restarted.
We are not seeing this problem with root build on Fedore Core 9.
Perhaps this was caused by debug kernel being enabled or LTP using all of the memory.
5. U-boot has flash problems:
a. Sectors marked Read-Only come up Writeable after a reset/reboot.
b. Flashing a large number of sectors (like the kernel) sometimes
results in an Error (Ex: Vcc) and had to be retried.
c. We saw environment variables trashed on reset/reboot once.
It's possible that U-boot in flash could get whacked
and the board will need to be re-flashed. During weeks
of testing we haven't seen the U-Boot environment getting whacked.
6. gdb appears to be crashing on target when debugging
on latest root with uclibc left unstriped and with debug;
core dump sent to maxim.
7. U-Boot was hanging periodically when loading the kernel with
tftp; appears to have be worse when network activity is high.
This problem also seems to have gone away in the past few weeks.
It may have been a duplication with MAC addresses.
8. 'top' command only shows all cpu's or cpu0; cpu 1 and 2 missing.
9. Program dore dump require ulimit -c to be set but root uses /bin/sh
which is a link to bash but causes it to skip running the bash
startup scripts. Changing root to /bin/bash seems to mess up
ssh logins.
10. For kernel to be compiled on the LX200 (for self checking:
a. Xtensa makefile needs to be fixed:
CC init/do_mounts.o
LD init/mounts.o
/bin/sh: xtensa_test_mmuhifi_c3-linux-uclibc-ld: command not found
make[1]: *** [init/mounts.o] Error 127
b. Need to add ncurses-devel package for 'make menuconfig'
11. The busybox vesion of vi doesn't work very good, we are using symbolic pointer
/usr/local/bin/vi ---> /usr/local/bin/vim
/usr/local/bin is searched first via bash profile and rc.
The vim version works great and doesn't seem to use very much memory.
12. mplayer codecs by default install to /usr/local/lib but
the ldconfig config file needs to be updated to search /usr/local/lib.
Ex:
/etc/ld.so.conf:
# /usr/local/src/faad2-2.7/:
# libfaad.a libfaad.la libfaad.so@
# libfaad.so.2@ libfaad.so.2.0.0* libmp4ff.a
#
/usr/local/lib
/etc/ld.so.conf.d exist but is being ignored by ldconfig even if included via ld.so.conf:
include ld.so.conf.d/*.conf
REMIND: update /home/default/save_root_files
Further reading
Some Notable Xtensa Linux and Transwitch resources are:
- Transwitch A2000
- Transwitch Support
- Linux/Xtensa Wiki
- Buildroot Build Instructions
- Kernel Build Instructions
- Setting up U-Boot
- Linux/Xtensa Mailing List
- http://git.linux-xtensa.org/cgi-bin/git.cgi GIT Repositories]
Maintained by
- piet
- marc ?
- suresh ?