Linux/Xtensa - User contributions [en]

SMP HiFi 2 Development Board

2012-03-21T05:52:16Z

Piet: /* Configuring U-Boot to Boot Linux */

This is a "community" guide for how to use the LX200 board based 3-core SMP HiFi-2 Development environment.
If something doesn't work or isn't covered in this guide, please feel free to ask at the [http://lists.linux-xtensa.org/mailman/listinfo Linux/Xtensa Mailing List].

<div style="margin:0; margin-top:10px; margin-right:10px; border:1px solid #dfdfdf; padding:0 1em 1em 1em; background-color:#ffffcc; align:right; ">
'''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.

* NOTE for Internal Tensilica pre-release Testers:
** Codecs available at /fac/vol6/audio/release/bin/l32r_LE5_pic.
** LX200 bitstream available at /home/marc/XTAV200/test_mmuhifi_c3.3core.
** Instructions to install and set up U-Boot available at http://wiki.linux-xtensa.org/index.php/Setting_up_U-Boot.
*** Checkout the snapshot_2+SMP branch of the U-Boot git repo for pre-built binaries.

</div>

== Introduction ==

This document is addressed to someone who received an LX200 board setup by Tensilica
for HiFi2 development.

This document goes over the steps needed to set up the LX200 board for HiFi2 development.
To summarize:
* Setup the board. It likely comes with U-boot pre-installed, ready to boot a linux kernel.
* Install '''git'''.
* Download buildroot and linux kernel trees, pre-configured and built for HiFi-2 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 codec development just before booting.

Once the development board is up and running, this document:
* Shows how to add the Tensilica provided codec packages to the Mplayer packages used by Buildroot, including building and installing.
* Demonstrates two procedures for compiling, linking, and debugging codecs.
* Suggest how to 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 HiFi-2 Buildroot and Kernel Snapshots ==

The HiFi-2 development environment is maintained 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 ===

To install '''git''', download a recent tarball from the [http://www.kernel.org/pub/software/scm/git/ official site]. For example, <tt>cd</tt> 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 <tt>/usr/local/bin</tt> 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 codec 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 HiFi-2 snapshot is in the process of being made.''

To install the buildroot environment (toolchain and root filesystem), <tt>cd</tt> to a location with a few GB of available disk space, and do:

$ '''git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa-HiFi2-Snapshot.git'''
$ '''cd buildroot-xtensa-HiFi2-Snapshot'''
$ '''git branch --track snapshot_2+SMP origin/snapshot_2+SMP'''
$ '''git checkout snapshot_2+SMP'''

The last two lines checkout the latest branch (preconfigured for the 3-core HiFi2 on the LX200).

You can examine the tree (git repository) and its history visually using <tt>git gui</tt>.
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/snapshot_2+SMP
[Create]
[Reposirory]--> Quit

If there are issues installing '''git''', as a last resort, an alternative is ftp (may not always get updated, is currently our of date, waste disk space, so may be dropped at some point):

http://www.linux-xtensa.org/pub/snapshots/buildroot-xtensa-smp.2-Nov-2009.tar.gz [NOTE: TO BE UPDATED]

=== Installing the Linux Kernel Snapshot ===

To install the Linux kernel environment (kernel src, config, and HiFi-2 kernel U-Boot image), <tt>cd</tt> to a location with a few GB of available disk space, and do:

$ '''git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git'''
$ '''cd kernel/xtensa-2.6.29-smp'''

$ '''git branch --track snapshot_2+SMP origin/snapshot_2+SMP''' [NOTE: The snapshot_2+SMP-stable so far appears to be a bit better]
$ '''git checkout snapshot_2+SMP'''

The last two lines checkout the latest branch (preconfigured for the 3-core HiFi2 on the LX200).
There is also a more up-to-date branch named '''snapshot_2+SMP-stable''' that has more recent kernel bug-fixes from kernel.org
but it hasn't been tested as extensively but so far may be show to be a bit more stable than the well tested snapshot_2+SMP branch
when memory gets tight under very heavy loads. This preconfigured 3-core HiFi2 branch has a few NFS bug fixes but nothing that immediately appears to have been a
problem in this environment. Test up to now appear to be a bit better under heavy memory congestion. If you want to use this branch use the following git commands:

$ '''git branch --track snapshot_2+SMP-stable origin/snapshot_2+SMP-stable'''
$ '''git checkout snapshot_2+SMP-stable'''

As in the build root case, you can also checkout the branch easily from via '''git gui''' using the same procedure
mentioned above.

Now, assuming we are still in the kernel '''xtensa-2.6.29-smp''' directory
copy the kernel U-Boot Image ('''uImage''') to the tftp directory; Ex:

$ '''cp arch/xtensa/boot/uImage /tftpboot/uImage.xtensa-2.6.29-smp.test_mmuhifi_c3''' [Note: You may have to make dir /tftpboot]

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 LX200 board running Linux needs to mount its root file-system over NFS.
This file system was built using buildroot into 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/LINUX_ROOT.HiFi-2_DemoBoard.buildroot-xtensa-smp'''
'''/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 hifi-2_home_default.tar.gz''' [Uncompress /home/default tar ball]
$ '''gunzip hifi-2_usr_local.tar.gz''' [Uncompress /usr/local tar ball]
$
$ '''WHERE=$PWD'''
$ '''mkdir -p /exports/LINUX_ROOT.HiFi-2'''
$
$ '''cd /exports/LINUX_ROOT.HiFi-2'''
$ '''cpio -i < $WHERE/rootfs.xtensa_test_mmuhifi_c3.cpio'''
$
$ '''cd /export'''
$ '''tar xf hifi-2_home_default.tar''' [Tar in boards /home/default for export]
$ '''tar xf hifi-2_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 mypc.foobar.com:
/export *
/exports *
$

== Configuring U-Boot to Boot Linux ==

Your LX200 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 install.

The board has a DIP switch (next to the power on/off switch) that provides the 6 LSBs
of the Ethernet MAC, in switch positions 1 thru 6.

DIP Swithes for MAC: 1 2 3 4 5 6 7 8 ethaddr=00:50:C2:13:6f:0a
Little Endian: 0 1 0 1 0 0 * *
^
|
+------ Enables booting U-Boot from Flash

DIP switch 8 should be shipped in the ON position to enable U-Boot booting from flash.
See Sections 4.2.3 and 4.2.4 of the '''Tensilica Avnet (XT-AV200) Board User's Guide'''
for details. Make sure to select a unique MAC address for you board.

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 [http://en.wikipedia.org/wiki/Minicom minicom]
for this, see [[minicom_xtboard_setup|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 2009.08 (Nov 15 2009 - 22:03:26)

CPU: Xtensa test_mmuhifi_c3 at 41.6777 MHz
Board: XT-AV200: Avnet board + Xilinx LX200 FPGA + Tensilica bitstream
SysRAM: 96 MB
Flash: 16 MB
In: serial
Out: serial
Err: serial
MAC: 00:50:C2:13:6f:07
IP: 192.168.11.105
open_ethernet
Autobooting in 999999 seconds, press <SPACE> to stop '''<SPACE>'''

U-Boot> '''printenv'''
baudrate=38400
ethaddr=00:50:C2:13:6f:07
ethact=open_ethernet
serverip=192.168.11.55
nfsroot_server=192.168.11.55
root-path=/exports/LINUX_ROOT.HiFi-2
bootargs_using_bootp=console=ttyS0,38400 ip=bootp root=nfs coredump_filter=0xff
bootcmd=tftpboot; bootm
netmask=255.255.255.0
gatewayip=192.168.11.1
nfs_boot_args=root=/dev/nfs rw nfsroot=192.168.11.55:/exports/LINUX_ROOT.HiFi-2
bootfile=uImage.xtensa-2.6.29-smp.test_mmuhifi_c3-stable
autostart=no
bootdelay=999999
ipaddr=192.168.11.105
misc_boot_args=debug coredump_filter=0xff
hostname=HiFi-2
nfsaddrs=192.168.11.105:192.168.11.55:192.168.11.1:255.255.255.0:HiFi-2
bootargs=console=ttyS0,38400 ip=192.168.11.105:192.168.11.55:192.168.11.1:255.255.255.0:HiFi-2 root=/dev/nfs rw nfsroot=192.168.11.55:/exports/LINUX_ROOT.HiFi-2 debug coredump_filter=0xff
stdin=serial
stdout=serial
stderr=serial
ver=U-Boot 2009.08 (Nov 15 2009 - 22:03:26)

Environment size: 788/131068 bytes
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.105''' [HOST 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/DC_B_330HiFi_3Core_MMU/LINUX_ROOT.HiFi-2''' [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_NFS_Based''' [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>

Alternatively, if you don't feel like setting up an NFS exports you can could use a root filesystem simply located in the kernel RAM.
In this case only TFTP will be used on the local Ethernet to load the kernel. This could be set up with these commands:

U-Boot> '''setenv serverip 192.168.11.55''' [TFTP server IP Address: My Workstation]
U-Boot> '''setenv ipaddr 192.168.11.105''' [HOST 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.ramfs''' [File to fetch with TFTP and pass to bootm]
U-Boot> '''setenv root-path /export2/DC_B_330HiFi_3Core_MMU/LINUX_ROOT.HiFi-2''' [Location of root filesystem on NFS Server; Limit ~50 bytes]
U-Boot> '''setenv ramfs_boot_args root=/dev/ramfs''' [RAMFS Args used in bootargs]
U-Boot> '''setenv hostname HiFi-2_RamFS_Based''' [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} ${ramfs_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/hifi-2_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/LINUX_ROOT.HiFi-2'''
$ '''tar xf /exports/hifi-2_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/LINUX_ROOT.HiFi-2'''
$ '''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 LX200. 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 LX200 and it should
auto-boot the kernel, resulting in output such as [[HiFi2_Board_Example_Linux_Boot_Log|this example log]].

== Tailoring your system prior to developing for HiFi 2 ==

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 test_mmuhifi_c3'''

You can either set the PATH and invoke tools prefixed with <tt>xtensa_${CORENAME}-linux-</tt> :

$ '''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 <tt>gcc</tt>.

=== 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 <tt>open()</tt>'s <tt>O_EXCL</tt>
and <tt>stat()</tt>'s <tt>struct stat</tt>, must be avoided because their definitions likely differ between the
Xtensa Tools' default C library and the Linux uClibc library).
''('''Note''': Codecs such as MP3 and AAC are typically 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 test_mmuhifi_c3

$ '''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.
(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|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 test_mmuhifi_c3'''
'''setenv XTENSA_ROOT /home/pdelaney/Xplorer/XtDevTools/install/builds/RC-2009.0-linux/test_mmuhifi_c3'''
'''setenv XTENSA_SYSTEM /home/pdelaney/Xplorer/XtDevTools/install/builds/RC-2009.0-linux/test_mmuhifi_c3/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'''
[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 LX200 board]
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.

== Compiling the Mplayer Plugins and linking them with MPEG-1 Audio Layer 3 (MP3) and MPEG-4 AAC Codecs ==

Mplayer is provided as an example environment for developing and testing Codecs and HiFi 2 software. There
are two ways to build Mplayer and the plug-in modules that use the codecs. The buildroot
tree (pulled with git) has a copy of mplayer and the plugins that can be built in the
snapshot via 'make menuconfig'. This is a good environment to use once codecs are
developed and debugged.

To facilitate development the mplayer packages can be copied to your NFS mounted development
environment. From there you can just configure mplayer to compile on the board and debug
mplayer and your codecs with gdb locally.

In the default user home directory we have a directory /home/default/buildroot_mplayer_stuff
with a copy of three of the mplayer packages:

[root@hifi buildroot_mplayer_stuff]# '''ls -l'''
drwxr-xr-x 34 root root 4096 Nov 10 05:01 MPlayer-1.0rc2/
drwxr-xr-x 4 root root 4096 Nov 10 01:36 mplayer_hifi2_aacplus_v2_plugin/
drwxr-xr-x 3 root root 4096 Nov 10 00:57 mplayer_hifi2_mp3_plugin/

they were simply copied from the buildroot-xtensa-HiFi2-Snapshot.2/package directory.

To get your development environment ready to compile the mplayer plug-ins you need
to configure Mplayer to use the local C compiler and linker:

# '''cd /home/default/buildroot_mplayer_stuff/MPlayer-1.0rc2/'''
# '''CFLAGS="-g3" ./configure'''

This will take about 15 minutes to configure. After that you can build the
plugins or mplayer. If you want to recompile mplayer it's likely best/necessary
to use the same args to .configure as used by buildroot:

.CFLAGS="-g3" ./configure \
--prefix=/usr \
--confdir=/etc/mplayer \
--with-extraincdir=/usr/include \
--with-extralibdir=/lib \
--disable-gui \
--enable-mad \
--enable-fbdev \
--disable-mencoder \
--disable-dvdnav \
--disable-dvdread \
--disable-dvdread-internal \
--disable-libdvdcss-internal \
--disable-big-endian \
--disable-nemesi \
--disable-tv \
--enable-dynamic-plugins

We are currently able to compile mplayer on the LX200 but
due to space limitations it's not possible to compile it -O0.

Now, let's focus on compiling linking the plugins. They are a nice
example of compiling an audio application on the LX200.

We modified the plugin Makefile slightly, and they are available in /home/default/mplayer_packages.
These additions just instruct make how to fetch the codecs and build and install the plugins as explained
in the Chapter 7 of the Linux HiFi application note. With these Makefile additions and the Tensilica
codecs available in the /plugins directory is very easy.

For example the mp3 plugin has this addition:

# We assume Tensilica Codecs have been mounted at /codecs
# via /etc/fstab during boot.
#
CODEC_PACKAGE=xa_hifi2_l32r_LE5_pic_mp3_dec_lib_3_1_api_1_15_lib
CODEC_PACKAGE_LOCATION=/codecs
MPLAYER_DEVEL_LOCATION=/home/default/buildroot_mplayer_stuff

all: '''$(XA_CODEC_NAME)''' $(SLIBNAME) $(XA_CODEC_NAME).so
.
.
.
$(CODEC_PACKAGE).tgz:
cp $(CODEC_PACKAGE_LOCATION)/$(CODEC_PACKAGE).tgz .

$(CODEC_PACKAGE).tar:: $(CODEC_PACKAGE).tgz
gunzip $(CODEC_PACKAGE).tgz

$(XA_CODEC_NAME):: $(CODEC_PACKAGE).tar
tar xf $(CODEC_PACKAGE).tar

install::
@-mkdir /etc/mplayer
cp codecs.conf /etc/mplayer
@-mkdir /usr/lib/mplayer
cp ad_xa_mp3_dec.so /usr/lib/mplayer/
cp xa_mp3_dec.so /usr/lib/mplayer
chmod 755 /usr/lib/mplayer/ad_xa_mp3_dec.so
chmod 755 /usr/lib/mplayer/xa_mp3_dec.so

The make file will be just providing a codec config file for mplayer at '''/etc/mplayer/codecs.conf''' and
copying the plug-in to '''/usr/lib/mplayer'''. To install the mp3 codec plugin and mplayer
config file just copy your codec that was compiled with '''xcc''' to the directory, compile it,
and install. To add mp3 and aac plugins to mplayer you just type '''make''' followed by '''make install''':

[root@hifi mplayer_hifi2_mp3_plugin]# '''make'''
cp /codecs/xa_hifi2_l32r_LE5_pic_mp3_dec_lib_3_1_api_1_15_lib.tgz .
gunzip xa_hifi2_l32r_LE5_pic_mp3_dec_lib_3_1_api_1_15_lib.tgz
tar xf xa_hifi2_l32r_LE5_pic_mp3_dec_lib_3_1_api_1_15_lib.tar
cc -I../libavcodec -I../libavformat -I. -I.. -I../libavutil -W -Wall -O2 -pipe -g3 -D_REENTRANT -DHAVE_CONFIG_H -I/usr/include -DNDEBUG -fvisibility=hidden -Ixa_mp3_dec/include -I../MPlayer-1.0rc2 -Ic
xa_mp3_dec_sample_testbench.c: In function 'xa_mp3_decode_frame':
xa_mp3_dec_sample_testbench.c:185: warning: pointer targets in passing argument 1 of 'xa_mp3_audio_read' differ in signedness
xa_mp3_dec_sample_testbench.c:163: warning: unused variable 'j'
xa_mp3_dec_sample_testbench.c: In function 'mp3_codec_init':
xa_mp3_dec_sample_testbench.c:517: warning: pointer targets in passing argument 1 of 'xa_mp3_audio_read' differ in signedness
xa_mp3_dec_sample_testbench.c: At top level:
xa_mp3_dec_sample_testbench.c:112: warning: 'pack_32_to_24_bits' defined but not used
cc -I../libavcodec -I../libavformat -I. -I.. -I../libavutil -W -Wall -O2 -pipe -g3 -D_REENTRANT -DHAVE_CONFIG_H -I/usr/include -DNDEBUG -fvisibility=hidden -Ixa_mp3_dec/include -I../MPlayer-1.0rc2 -Ic
ad_xa_mp3_dec.c: In function 'xa_mp3_audio_read':
ad_xa_mp3_dec.c:26: warning: pointer targets in passing argument 2 of 'demux_read_data' differ in signedness
ad_xa_mp3_dec.c: In function 'init':
ad_xa_mp3_dec.c:42: warning: pointer targets in passing argument 1 of 'xa_mp3_decode_frame' differ in signedness
ad_xa_mp3_dec.c: At top level:
ad_xa_mp3_dec.c:52: warning: unused parameter 'sh'
ad_xa_mp3_dec.c:56: warning: unused parameter 'arg'
ad_xa_mp3_dec.c:78: warning: unused parameter 'sh_audio'
cc -I../libavcodec -I../libavformat -I. -I.. -I../libavutil -W -Wall -O2 -pipe -g3 -D_REENTRANT -DHAVE_CONFIG_H -I/usr/include -DNDEBUG -fvisibility=hidden -Ixa_mp3_dec/include -I../MPlayer-1.0rc2 -Im
cc -I../libavcodec -I../libavformat -I. -I.. -I../libavutil -W -Wall -O2 -pipe -g3 -D_REENTRANT -DHAVE_CONFIG_H -I/usr/include -DNDEBUG -fvisibility=hidden -Ixa_mp3_dec/include -I../MPlayer-1.0rc2 -Ie
[root@hifi mplayer_hifi2_mp3_plugin]#

[root@hifi mplayer_hifi2_mp3_plugin]# '''make install'''
mkdir: cannot create directory '/etc/mplayer': File exists
make: [install] Error 1 (ignored)
cp codecs.conf /etc/mplayer
mkdir: cannot create directory '/usr/lib/mplayer': File exists
make: [install] Error 1 (ignored)
cp ad_xa_mp3_dec.so /usr/lib/mplayer/
cp xa_mp3_dec.so /usr/lib/mplayer
chmod 755 /usr/lib/mplayer/ad_xa_mp3_dec.so
chmod 755 /usr/lib/mplayer/xa_mp3_dec.so
[root@hifi mplayer_hifi2_mp3_plugin]#

The makefile unpacked of the Tensilica mp3 codec tarball will installed the following files:

xa_mp3_dec/
xa_mp3_dec/README
xa_mp3_dec/include/
xa_mp3_dec/include/mp3_dec/
xa_mp3_dec/include/mp3_dec/xa_mp3_dec_api.h
xa_mp3_dec/include/xa_apicmd_standards.h
xa_mp3_dec/include/xa_error_handler.h
xa_mp3_dec/include/xa_error_standards.h
xa_mp3_dec/include/xa_memory_standards.h
xa_mp3_dec/include/xa_type_def.h
xa_mp3_dec/test/
xa_mp3_dec/test/build/
xa_mp3_dec/test/build/ldscript_stream_data.txt
xa_mp3_dec/test/build/makefile_testbench_sample
xa_mp3_dec/test/build/paramfilesimple.txt
xa_mp3_dec/test/include/
xa_mp3_dec/test/include/id3_tag_decode.h
xa_mp3_dec/test/src/
xa_mp3_dec/test/src/xa_mp3_dec_sample_testbench.c
xa_mp3_dec/test/src/id3_tag_decode.c
xa_mp3_dec/test/src/stream_data.c
xa_mp3_dec/test/src/xa_mp3_dec_error_handler.c
xa_mp3_dec/test/test_inp/
xa_mp3_dec/test/test_inp/compl.mp3
xa_mp3_dec/test/test_inp/hihat.mp3
xa_mp3_dec/test/test_out/
xa_mp3_dec/test/test_out/force_mkdir.txt
xa_mp3_dec/test/test_ref/
xa_mp3_dec/test/test_ref/compl_24bit.wav
xa_mp3_dec/test/test_ref/hihat_16bit.wav
xa_mp3_dec/lib/
xa_mp3_dec/lib/xa_mp3_dec.a
xa_mp3_dec/doc/
xa_mp3_dec/doc/HiFi2-MP3-DecoderProgrammersGuide.pdf

Now, having built and installed the mp3 plugin, do the same for the AAC codec.

[root@hifi ~]# cd /home/default/mplayer_packages/mplayer_hifi2_aacplus_v2_plugin/
[root@hifi mplayer_hifi2_aacplus_v2_plugin]# '''make'''
[root@hifi mplayer_hifi2_aacplus_v2_plugin]# '''make install'''

Additional codecs can be downloaded from the mplayer web site, configured,
compiled and can be installed as usual.

http://www.mplayerhq.hu/DOCS/HTML/en/codec-installation.html

[opencore-amr | opencore-amr]

opencore-amr builds fine and the x264-snapshot compiles completely
but the Makefile and code needs to be set up for ARCH xtensa. The
GPL AAC decoder, faad, has out of date autoconf files, config.sub
and config.guess, need to be updated for Xtensa. This can be easily
done by copying config.sub and config.guess from the x264-snapshot
which had up to date versions recognizing xtensa correctly.

Add on codec install by default to /usr/local/lib and the ldconfig
config file /etc/ld.so.conf needs to have /usr/local/lib added.

Lots of opportunity likely exists for optimizing these codec for
Xtensa extensibility.

[TO BE DONE - Add missing C file, make clean deletes it!]

The xa_mp3_dec.a archive will be used by the Makefile in
the mplayer_hifi2_mp3_plugin directory to make the mplayer plug-in.
Section 6 of the '''Using Tensilica HiFi 2 Codec on Xtensa Linux with MPlayer'' Application Note
has a detailed description of the encapsulation process used by the plug-ins.

== Adding Packages and/or Codec to Buildroot ==

Xtensa developers provide detailed instructions on building the root filesystem and the Linux kernel.
* [[Buildroot_Build_Instructions|Instructions for building and booting Linux (buildroot)]].

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 [[HiFi-2 snapshot_2 SMP Snapshot menuconfig | menuconfig]]'''
$ '''make [[HiFi-2 snapshot_2 SMP uclibc-menuconfig | uclibc-menuconfig]]'''
$ '''make [[HiFi-2 snapshot_2 SMP busybox-menuconfig | 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.

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=

Main Xtensa Linux resources are:

* [http://linux-xtensa.org/ Linux/Xtensa Wiki]
* [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions Buildroot Build Instructions]
* [http://wiki.linux-xtensa.org/index.php/Kernel_Build_Instructions Kernel Build Instructions]
* [http://wiki.linux-xtensa.org/index.php/Setting_up_U-Boot Setting up U-Boot]
* [http://lists.linux-xtensa.org/mailman/listinfo Linux/Xtensa Mailing List]
* http://git.linux-xtensa.org/cgi-bin/git.cgi GIT Repositories]

=Thanks to=

* piet
* marc
* dan
* maxim

And the rest of the people in the Linux-Xtensa mailing list, if you cannot go through some of the steps, don't hesitate to ask on the mailing list, there's always somebody willing to help you!

SMP HiFi 2 Development Board

2012-03-21T05:50:01Z

Piet: /* Configuring U-Boot to Boot Linux */

This is a "community" guide for how to use the LX200 board based 3-core SMP HiFi-2 Development environment.
If something doesn't work or isn't covered in this guide, please feel free to ask at the [http://lists.linux-xtensa.org/mailman/listinfo Linux/Xtensa Mailing List].

<div style="margin:0; margin-top:10px; margin-right:10px; border:1px solid #dfdfdf; padding:0 1em 1em 1em; background-color:#ffffcc; align:right; ">
'''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.

* NOTE for Internal Tensilica pre-release Testers:
** Codecs available at /fac/vol6/audio/release/bin/l32r_LE5_pic.
** LX200 bitstream available at /home/marc/XTAV200/test_mmuhifi_c3.3core.
** Instructions to install and set up U-Boot available at http://wiki.linux-xtensa.org/index.php/Setting_up_U-Boot.
*** Checkout the snapshot_2+SMP branch of the U-Boot git repo for pre-built binaries.

</div>

== Introduction ==

This document is addressed to someone who received an LX200 board setup by Tensilica
for HiFi2 development.

This document goes over the steps needed to set up the LX200 board for HiFi2 development.
To summarize:
* Setup the board. It likely comes with U-boot pre-installed, ready to boot a linux kernel.
* Install '''git'''.
* Download buildroot and linux kernel trees, pre-configured and built for HiFi-2 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 codec development just before booting.

Once the development board is up and running, this document:
* Shows how to add the Tensilica provided codec packages to the Mplayer packages used by Buildroot, including building and installing.
* Demonstrates two procedures for compiling, linking, and debugging codecs.
* Suggest how to 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 HiFi-2 Buildroot and Kernel Snapshots ==

The HiFi-2 development environment is maintained 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 ===

To install '''git''', download a recent tarball from the [http://www.kernel.org/pub/software/scm/git/ official site]. For example, <tt>cd</tt> 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 <tt>/usr/local/bin</tt> 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 codec 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 HiFi-2 snapshot is in the process of being made.''

To install the buildroot environment (toolchain and root filesystem), <tt>cd</tt> to a location with a few GB of available disk space, and do:

$ '''git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa-HiFi2-Snapshot.git'''
$ '''cd buildroot-xtensa-HiFi2-Snapshot'''
$ '''git branch --track snapshot_2+SMP origin/snapshot_2+SMP'''
$ '''git checkout snapshot_2+SMP'''

The last two lines checkout the latest branch (preconfigured for the 3-core HiFi2 on the LX200).

You can examine the tree (git repository) and its history visually using <tt>git gui</tt>.
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/snapshot_2+SMP
[Create]
[Reposirory]--> Quit

If there are issues installing '''git''', as a last resort, an alternative is ftp (may not always get updated, is currently our of date, waste disk space, so may be dropped at some point):

http://www.linux-xtensa.org/pub/snapshots/buildroot-xtensa-smp.2-Nov-2009.tar.gz [NOTE: TO BE UPDATED]

=== Installing the Linux Kernel Snapshot ===

To install the Linux kernel environment (kernel src, config, and HiFi-2 kernel U-Boot image), <tt>cd</tt> to a location with a few GB of available disk space, and do:

$ '''git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git'''
$ '''cd kernel/xtensa-2.6.29-smp'''

$ '''git branch --track snapshot_2+SMP origin/snapshot_2+SMP''' [NOTE: The snapshot_2+SMP-stable so far appears to be a bit better]
$ '''git checkout snapshot_2+SMP'''

The last two lines checkout the latest branch (preconfigured for the 3-core HiFi2 on the LX200).
There is also a more up-to-date branch named '''snapshot_2+SMP-stable''' that has more recent kernel bug-fixes from kernel.org
but it hasn't been tested as extensively but so far may be show to be a bit more stable than the well tested snapshot_2+SMP branch
when memory gets tight under very heavy loads. This preconfigured 3-core HiFi2 branch has a few NFS bug fixes but nothing that immediately appears to have been a
problem in this environment. Test up to now appear to be a bit better under heavy memory congestion. If you want to use this branch use the following git commands:

$ '''git branch --track snapshot_2+SMP-stable origin/snapshot_2+SMP-stable'''
$ '''git checkout snapshot_2+SMP-stable'''

As in the build root case, you can also checkout the branch easily from via '''git gui''' using the same procedure
mentioned above.

Now, assuming we are still in the kernel '''xtensa-2.6.29-smp''' directory
copy the kernel U-Boot Image ('''uImage''') to the tftp directory; Ex:

$ '''cp arch/xtensa/boot/uImage /tftpboot/uImage.xtensa-2.6.29-smp.test_mmuhifi_c3''' [Note: You may have to make dir /tftpboot]

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 LX200 board running Linux needs to mount its root file-system over NFS.
This file system was built using buildroot into 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/LINUX_ROOT.HiFi-2_DemoBoard.buildroot-xtensa-smp'''
'''/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 hifi-2_home_default.tar.gz''' [Uncompress /home/default tar ball]
$ '''gunzip hifi-2_usr_local.tar.gz''' [Uncompress /usr/local tar ball]
$
$ '''WHERE=$PWD'''
$ '''mkdir -p /exports/LINUX_ROOT.HiFi-2'''
$
$ '''cd /exports/LINUX_ROOT.HiFi-2'''
$ '''cpio -i < $WHERE/rootfs.xtensa_test_mmuhifi_c3.cpio'''
$
$ '''cd /export'''
$ '''tar xf hifi-2_home_default.tar''' [Tar in boards /home/default for export]
$ '''tar xf hifi-2_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 mypc.foobar.com:
/export *
/exports *
$

== Configuring U-Boot to Boot Linux ==

Your LX200 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 install.

The board has a DIP switch (next to the power on/off switch) that provides the 6 LSBs
of the Ethernet MAC, in switch positions 1 thru 6.

DIP Swithes for MAC: 1 2 3 4 5 6 7 8 ethaddr=00:50:C2:13:6f:0a
Little Endian: 0 1 0 1 0 0 * *
^
|
+------ Enables booting U-Boot from Flash

DIP switch 8 should be shipped in the ON position to enable U-Boot booting from flash.
See Sections 4.2.3 and 4.2.4 of the '''Tensilica Avnet (XT-AV200) Board User's Guide'''
for details. Make sure to select a unique MAC address for you board.

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 [http://en.wikipedia.org/wiki/Minicom minicom]
for this, see [[minicom_xtboard_setup|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 2009.08 (Nov 15 2009 - 22:03:26)

CPU: Xtensa test_mmuhifi_c3 at 41.6777 MHz
Board: XT-AV200: Avnet board + Xilinx LX200 FPGA + Tensilica bitstream
SysRAM: 96 MB
Flash: 16 MB
In: serial
Out: serial
Err: serial
MAC: 00:50:C2:13:6f:07
IP: 192.168.11.105
open_ethernet
Autobooting in 999999 seconds, press <SPACE> to stop '''<SPACE>'''

U-Boot> '''printenv'''
baudrate=38400
ethaddr=00:50:C2:13:6f:07
ethact=open_ethernet
serverip=192.168.11.55
nfsroot_server=192.168.11.55
root-path=/exports/LINUX_ROOT.HiFi-2
bootargs_using_bootp=console=ttyS0,38400 ip=bootp root=nfs coredump_filter=0xff
bootcmd=tftpboot; bootm
netmask=255.255.255.0
gatewayip=192.168.11.1
nfs_boot_args=root=/dev/nfs rw nfsroot=192.168.11.55:/exports/LINUX_ROOT.HiFi-2
bootfile=uImage.xtensa-2.6.29-smp.test_mmuhifi_c3-stable
autostart=no
bootdelay=999999
ipaddr=192.168.11.105
misc_boot_args=debug coredump_filter=0xff
hostname=HiFi-2
nfsaddrs=192.168.11.105:192.168.11.55:192.168.11.1:255.255.255.0:HiFi-2
bootargs=console=ttyS0,38400 ip=192.168.11.105:192.168.11.55:192.168.11.1:255.255.255.0:HiFi-2 root=/dev/nfs rw nfsroot=192.168.11.55:/exports/LINUX_ROOT.HiFi-2 debug coredump_filter=0xff
stdin=serial
stdout=serial
stderr=serial
ver=U-Boot 2009.08 (Nov 15 2009 - 22:03:26)

Environment size: 788/131068 bytes
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.105''' [HOST 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 /exports/LINUX_ROOT.HiFi-2''' [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_NFS_Based''' [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>

Alternatively, if you don't feel like setting up an NFS exports you can could use a root filesystem simply located in the kernel RAM.
In this case only TFTP will be used on the local Ethernet to load the kernel. This could be set up with these commands:

U-Boot> '''setenv serverip 192.168.11.55''' [TFTP server IP Address: My Workstation]
U-Boot> '''setenv ipaddr 192.168.11.105''' [HOST 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.ramfs''' [File to fetch with TFTP and pass to bootm]
U-Boot> '''setenv root-path /export2/DC_B_330HiFi_3Core_MMU/LINUX_ROOT.HiFi-2''' [Location of root filesystem on NFS Server; Limit ~50 bytes]
U-Boot> '''setenv ramfs_boot_args root=/dev/ramfs''' [RAMFS Args used in bootargs]
U-Boot> '''setenv hostname HiFi-2_RamFS_Based''' [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} ${ramfs_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/hifi-2_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/LINUX_ROOT.HiFi-2'''
$ '''tar xf /exports/hifi-2_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/LINUX_ROOT.HiFi-2'''
$ '''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 LX200. 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 LX200 and it should
auto-boot the kernel, resulting in output such as [[HiFi2_Board_Example_Linux_Boot_Log|this example log]].

== Tailoring your system prior to developing for HiFi 2 ==

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 test_mmuhifi_c3'''

You can either set the PATH and invoke tools prefixed with <tt>xtensa_${CORENAME}-linux-</tt> :

$ '''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 <tt>gcc</tt>.

=== 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 <tt>open()</tt>'s <tt>O_EXCL</tt>
and <tt>stat()</tt>'s <tt>struct stat</tt>, must be avoided because their definitions likely differ between the
Xtensa Tools' default C library and the Linux uClibc library).
''('''Note''': Codecs such as MP3 and AAC are typically 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 test_mmuhifi_c3

$ '''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.
(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|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 test_mmuhifi_c3'''
'''setenv XTENSA_ROOT /home/pdelaney/Xplorer/XtDevTools/install/builds/RC-2009.0-linux/test_mmuhifi_c3'''
'''setenv XTENSA_SYSTEM /home/pdelaney/Xplorer/XtDevTools/install/builds/RC-2009.0-linux/test_mmuhifi_c3/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'''
[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 LX200 board]
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.

== Compiling the Mplayer Plugins and linking them with MPEG-1 Audio Layer 3 (MP3) and MPEG-4 AAC Codecs ==

Mplayer is provided as an example environment for developing and testing Codecs and HiFi 2 software. There
are two ways to build Mplayer and the plug-in modules that use the codecs. The buildroot
tree (pulled with git) has a copy of mplayer and the plugins that can be built in the
snapshot via 'make menuconfig'. This is a good environment to use once codecs are
developed and debugged.

To facilitate development the mplayer packages can be copied to your NFS mounted development
environment. From there you can just configure mplayer to compile on the board and debug
mplayer and your codecs with gdb locally.

In the default user home directory we have a directory /home/default/buildroot_mplayer_stuff
with a copy of three of the mplayer packages:

[root@hifi buildroot_mplayer_stuff]# '''ls -l'''
drwxr-xr-x 34 root root 4096 Nov 10 05:01 MPlayer-1.0rc2/
drwxr-xr-x 4 root root 4096 Nov 10 01:36 mplayer_hifi2_aacplus_v2_plugin/
drwxr-xr-x 3 root root 4096 Nov 10 00:57 mplayer_hifi2_mp3_plugin/

they were simply copied from the buildroot-xtensa-HiFi2-Snapshot.2/package directory.

To get your development environment ready to compile the mplayer plug-ins you need
to configure Mplayer to use the local C compiler and linker:

# '''cd /home/default/buildroot_mplayer_stuff/MPlayer-1.0rc2/'''
# '''CFLAGS="-g3" ./configure'''

This will take about 15 minutes to configure. After that you can build the
plugins or mplayer. If you want to recompile mplayer it's likely best/necessary
to use the same args to .configure as used by buildroot:

.CFLAGS="-g3" ./configure \
--prefix=/usr \
--confdir=/etc/mplayer \
--with-extraincdir=/usr/include \
--with-extralibdir=/lib \
--disable-gui \
--enable-mad \
--enable-fbdev \
--disable-mencoder \
--disable-dvdnav \
--disable-dvdread \
--disable-dvdread-internal \
--disable-libdvdcss-internal \
--disable-big-endian \
--disable-nemesi \
--disable-tv \
--enable-dynamic-plugins

We are currently able to compile mplayer on the LX200 but
due to space limitations it's not possible to compile it -O0.

Now, let's focus on compiling linking the plugins. They are a nice
example of compiling an audio application on the LX200.

We modified the plugin Makefile slightly, and they are available in /home/default/mplayer_packages.
These additions just instruct make how to fetch the codecs and build and install the plugins as explained
in the Chapter 7 of the Linux HiFi application note. With these Makefile additions and the Tensilica
codecs available in the /plugins directory is very easy.

For example the mp3 plugin has this addition:

# We assume Tensilica Codecs have been mounted at /codecs
# via /etc/fstab during boot.
#
CODEC_PACKAGE=xa_hifi2_l32r_LE5_pic_mp3_dec_lib_3_1_api_1_15_lib
CODEC_PACKAGE_LOCATION=/codecs
MPLAYER_DEVEL_LOCATION=/home/default/buildroot_mplayer_stuff

all: '''$(XA_CODEC_NAME)''' $(SLIBNAME) $(XA_CODEC_NAME).so
.
.
.
$(CODEC_PACKAGE).tgz:
cp $(CODEC_PACKAGE_LOCATION)/$(CODEC_PACKAGE).tgz .

$(CODEC_PACKAGE).tar:: $(CODEC_PACKAGE).tgz
gunzip $(CODEC_PACKAGE).tgz

$(XA_CODEC_NAME):: $(CODEC_PACKAGE).tar
tar xf $(CODEC_PACKAGE).tar

install::
@-mkdir /etc/mplayer
cp codecs.conf /etc/mplayer
@-mkdir /usr/lib/mplayer
cp ad_xa_mp3_dec.so /usr/lib/mplayer/
cp xa_mp3_dec.so /usr/lib/mplayer
chmod 755 /usr/lib/mplayer/ad_xa_mp3_dec.so
chmod 755 /usr/lib/mplayer/xa_mp3_dec.so

The make file will be just providing a codec config file for mplayer at '''/etc/mplayer/codecs.conf''' and
copying the plug-in to '''/usr/lib/mplayer'''. To install the mp3 codec plugin and mplayer
config file just copy your codec that was compiled with '''xcc''' to the directory, compile it,
and install. To add mp3 and aac plugins to mplayer you just type '''make''' followed by '''make install''':

[root@hifi mplayer_hifi2_mp3_plugin]# '''make'''
cp /codecs/xa_hifi2_l32r_LE5_pic_mp3_dec_lib_3_1_api_1_15_lib.tgz .
gunzip xa_hifi2_l32r_LE5_pic_mp3_dec_lib_3_1_api_1_15_lib.tgz
tar xf xa_hifi2_l32r_LE5_pic_mp3_dec_lib_3_1_api_1_15_lib.tar
cc -I../libavcodec -I../libavformat -I. -I.. -I../libavutil -W -Wall -O2 -pipe -g3 -D_REENTRANT -DHAVE_CONFIG_H -I/usr/include -DNDEBUG -fvisibility=hidden -Ixa_mp3_dec/include -I../MPlayer-1.0rc2 -Ic
xa_mp3_dec_sample_testbench.c: In function 'xa_mp3_decode_frame':
xa_mp3_dec_sample_testbench.c:185: warning: pointer targets in passing argument 1 of 'xa_mp3_audio_read' differ in signedness
xa_mp3_dec_sample_testbench.c:163: warning: unused variable 'j'
xa_mp3_dec_sample_testbench.c: In function 'mp3_codec_init':
xa_mp3_dec_sample_testbench.c:517: warning: pointer targets in passing argument 1 of 'xa_mp3_audio_read' differ in signedness
xa_mp3_dec_sample_testbench.c: At top level:
xa_mp3_dec_sample_testbench.c:112: warning: 'pack_32_to_24_bits' defined but not used
cc -I../libavcodec -I../libavformat -I. -I.. -I../libavutil -W -Wall -O2 -pipe -g3 -D_REENTRANT -DHAVE_CONFIG_H -I/usr/include -DNDEBUG -fvisibility=hidden -Ixa_mp3_dec/include -I../MPlayer-1.0rc2 -Ic
ad_xa_mp3_dec.c: In function 'xa_mp3_audio_read':
ad_xa_mp3_dec.c:26: warning: pointer targets in passing argument 2 of 'demux_read_data' differ in signedness
ad_xa_mp3_dec.c: In function 'init':
ad_xa_mp3_dec.c:42: warning: pointer targets in passing argument 1 of 'xa_mp3_decode_frame' differ in signedness
ad_xa_mp3_dec.c: At top level:
ad_xa_mp3_dec.c:52: warning: unused parameter 'sh'
ad_xa_mp3_dec.c:56: warning: unused parameter 'arg'
ad_xa_mp3_dec.c:78: warning: unused parameter 'sh_audio'
cc -I../libavcodec -I../libavformat -I. -I.. -I../libavutil -W -Wall -O2 -pipe -g3 -D_REENTRANT -DHAVE_CONFIG_H -I/usr/include -DNDEBUG -fvisibility=hidden -Ixa_mp3_dec/include -I../MPlayer-1.0rc2 -Im
cc -I../libavcodec -I../libavformat -I. -I.. -I../libavutil -W -Wall -O2 -pipe -g3 -D_REENTRANT -DHAVE_CONFIG_H -I/usr/include -DNDEBUG -fvisibility=hidden -Ixa_mp3_dec/include -I../MPlayer-1.0rc2 -Ie
[root@hifi mplayer_hifi2_mp3_plugin]#

[root@hifi mplayer_hifi2_mp3_plugin]# '''make install'''
mkdir: cannot create directory '/etc/mplayer': File exists
make: [install] Error 1 (ignored)
cp codecs.conf /etc/mplayer
mkdir: cannot create directory '/usr/lib/mplayer': File exists
make: [install] Error 1 (ignored)
cp ad_xa_mp3_dec.so /usr/lib/mplayer/
cp xa_mp3_dec.so /usr/lib/mplayer
chmod 755 /usr/lib/mplayer/ad_xa_mp3_dec.so
chmod 755 /usr/lib/mplayer/xa_mp3_dec.so
[root@hifi mplayer_hifi2_mp3_plugin]#

The makefile unpacked of the Tensilica mp3 codec tarball will installed the following files:

xa_mp3_dec/
xa_mp3_dec/README
xa_mp3_dec/include/
xa_mp3_dec/include/mp3_dec/
xa_mp3_dec/include/mp3_dec/xa_mp3_dec_api.h
xa_mp3_dec/include/xa_apicmd_standards.h
xa_mp3_dec/include/xa_error_handler.h
xa_mp3_dec/include/xa_error_standards.h
xa_mp3_dec/include/xa_memory_standards.h
xa_mp3_dec/include/xa_type_def.h
xa_mp3_dec/test/
xa_mp3_dec/test/build/
xa_mp3_dec/test/build/ldscript_stream_data.txt
xa_mp3_dec/test/build/makefile_testbench_sample
xa_mp3_dec/test/build/paramfilesimple.txt
xa_mp3_dec/test/include/
xa_mp3_dec/test/include/id3_tag_decode.h
xa_mp3_dec/test/src/
xa_mp3_dec/test/src/xa_mp3_dec_sample_testbench.c
xa_mp3_dec/test/src/id3_tag_decode.c
xa_mp3_dec/test/src/stream_data.c
xa_mp3_dec/test/src/xa_mp3_dec_error_handler.c
xa_mp3_dec/test/test_inp/
xa_mp3_dec/test/test_inp/compl.mp3
xa_mp3_dec/test/test_inp/hihat.mp3
xa_mp3_dec/test/test_out/
xa_mp3_dec/test/test_out/force_mkdir.txt
xa_mp3_dec/test/test_ref/
xa_mp3_dec/test/test_ref/compl_24bit.wav
xa_mp3_dec/test/test_ref/hihat_16bit.wav
xa_mp3_dec/lib/
xa_mp3_dec/lib/xa_mp3_dec.a
xa_mp3_dec/doc/
xa_mp3_dec/doc/HiFi2-MP3-DecoderProgrammersGuide.pdf

Now, having built and installed the mp3 plugin, do the same for the AAC codec.

[root@hifi ~]# cd /home/default/mplayer_packages/mplayer_hifi2_aacplus_v2_plugin/
[root@hifi mplayer_hifi2_aacplus_v2_plugin]# '''make'''
[root@hifi mplayer_hifi2_aacplus_v2_plugin]# '''make install'''

Additional codecs can be downloaded from the mplayer web site, configured,
compiled and can be installed as usual.

http://www.mplayerhq.hu/DOCS/HTML/en/codec-installation.html

[opencore-amr | opencore-amr]

opencore-amr builds fine and the x264-snapshot compiles completely
but the Makefile and code needs to be set up for ARCH xtensa. The
GPL AAC decoder, faad, has out of date autoconf files, config.sub
and config.guess, need to be updated for Xtensa. This can be easily
done by copying config.sub and config.guess from the x264-snapshot
which had up to date versions recognizing xtensa correctly.

Add on codec install by default to /usr/local/lib and the ldconfig
config file /etc/ld.so.conf needs to have /usr/local/lib added.

Lots of opportunity likely exists for optimizing these codec for
Xtensa extensibility.

[TO BE DONE - Add missing C file, make clean deletes it!]

The xa_mp3_dec.a archive will be used by the Makefile in
the mplayer_hifi2_mp3_plugin directory to make the mplayer plug-in.
Section 6 of the '''Using Tensilica HiFi 2 Codec on Xtensa Linux with MPlayer'' Application Note
has a detailed description of the encapsulation process used by the plug-ins.

== Adding Packages and/or Codec to Buildroot ==

Xtensa developers provide detailed instructions on building the root filesystem and the Linux kernel.
* [[Buildroot_Build_Instructions|Instructions for building and booting Linux (buildroot)]].

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 [[HiFi-2 snapshot_2 SMP Snapshot menuconfig | menuconfig]]'''
$ '''make [[HiFi-2 snapshot_2 SMP uclibc-menuconfig | uclibc-menuconfig]]'''
$ '''make [[HiFi-2 snapshot_2 SMP busybox-menuconfig | 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.

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=

Main Xtensa Linux resources are:

* [http://linux-xtensa.org/ Linux/Xtensa Wiki]
* [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions Buildroot Build Instructions]
* [http://wiki.linux-xtensa.org/index.php/Kernel_Build_Instructions Kernel Build Instructions]
* [http://wiki.linux-xtensa.org/index.php/Setting_up_U-Boot Setting up U-Boot]
* [http://lists.linux-xtensa.org/mailman/listinfo Linux/Xtensa Mailing List]
* http://git.linux-xtensa.org/cgi-bin/git.cgi GIT Repositories]

=Thanks to=

* piet
* marc
* dan
* maxim

And the rest of the people in the Linux-Xtensa mailing list, if you cannot go through some of the steps, don't hesitate to ask on the mailing list, there's always somebody willing to help you!

SMP HiFi 2 Development Board

2012-03-21T05:40:18Z

Piet: /* Configuring U-Boot to Boot Linux */

This is a "community" guide for how to use the LX200 board based 3-core SMP HiFi-2 Development environment.
If something doesn't work or isn't covered in this guide, please feel free to ask at the [http://lists.linux-xtensa.org/mailman/listinfo Linux/Xtensa Mailing List].

<div style="margin:0; margin-top:10px; margin-right:10px; border:1px solid #dfdfdf; padding:0 1em 1em 1em; background-color:#ffffcc; align:right; ">
'''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.

* NOTE for Internal Tensilica pre-release Testers:
** Codecs available at /fac/vol6/audio/release/bin/l32r_LE5_pic.
** LX200 bitstream available at /home/marc/XTAV200/test_mmuhifi_c3.3core.
** Instructions to install and set up U-Boot available at http://wiki.linux-xtensa.org/index.php/Setting_up_U-Boot.
*** Checkout the snapshot_2+SMP branch of the U-Boot git repo for pre-built binaries.

</div>

== Introduction ==

This document is addressed to someone who received an LX200 board setup by Tensilica
for HiFi2 development.

This document goes over the steps needed to set up the LX200 board for HiFi2 development.
To summarize:
* Setup the board. It likely comes with U-boot pre-installed, ready to boot a linux kernel.
* Install '''git'''.
* Download buildroot and linux kernel trees, pre-configured and built for HiFi-2 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 codec development just before booting.

Once the development board is up and running, this document:
* Shows how to add the Tensilica provided codec packages to the Mplayer packages used by Buildroot, including building and installing.
* Demonstrates two procedures for compiling, linking, and debugging codecs.
* Suggest how to 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 HiFi-2 Buildroot and Kernel Snapshots ==

The HiFi-2 development environment is maintained 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 ===

To install '''git''', download a recent tarball from the [http://www.kernel.org/pub/software/scm/git/ official site]. For example, <tt>cd</tt> 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 <tt>/usr/local/bin</tt> 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 codec 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 HiFi-2 snapshot is in the process of being made.''

To install the buildroot environment (toolchain and root filesystem), <tt>cd</tt> to a location with a few GB of available disk space, and do:

$ '''git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa-HiFi2-Snapshot.git'''
$ '''cd buildroot-xtensa-HiFi2-Snapshot'''
$ '''git branch --track snapshot_2+SMP origin/snapshot_2+SMP'''
$ '''git checkout snapshot_2+SMP'''

The last two lines checkout the latest branch (preconfigured for the 3-core HiFi2 on the LX200).

You can examine the tree (git repository) and its history visually using <tt>git gui</tt>.
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/snapshot_2+SMP
[Create]
[Reposirory]--> Quit

If there are issues installing '''git''', as a last resort, an alternative is ftp (may not always get updated, is currently our of date, waste disk space, so may be dropped at some point):

http://www.linux-xtensa.org/pub/snapshots/buildroot-xtensa-smp.2-Nov-2009.tar.gz [NOTE: TO BE UPDATED]

=== Installing the Linux Kernel Snapshot ===

To install the Linux kernel environment (kernel src, config, and HiFi-2 kernel U-Boot image), <tt>cd</tt> to a location with a few GB of available disk space, and do:

$ '''git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git'''
$ '''cd kernel/xtensa-2.6.29-smp'''

$ '''git branch --track snapshot_2+SMP origin/snapshot_2+SMP''' [NOTE: The snapshot_2+SMP-stable so far appears to be a bit better]
$ '''git checkout snapshot_2+SMP'''

The last two lines checkout the latest branch (preconfigured for the 3-core HiFi2 on the LX200).
There is also a more up-to-date branch named '''snapshot_2+SMP-stable''' that has more recent kernel bug-fixes from kernel.org
but it hasn't been tested as extensively but so far may be show to be a bit more stable than the well tested snapshot_2+SMP branch
when memory gets tight under very heavy loads. This preconfigured 3-core HiFi2 branch has a few NFS bug fixes but nothing that immediately appears to have been a
problem in this environment. Test up to now appear to be a bit better under heavy memory congestion. If you want to use this branch use the following git commands:

$ '''git branch --track snapshot_2+SMP-stable origin/snapshot_2+SMP-stable'''
$ '''git checkout snapshot_2+SMP-stable'''

As in the build root case, you can also checkout the branch easily from via '''git gui''' using the same procedure
mentioned above.

Now, assuming we are still in the kernel '''xtensa-2.6.29-smp''' directory
copy the kernel U-Boot Image ('''uImage''') to the tftp directory; Ex:

$ '''cp arch/xtensa/boot/uImage /tftpboot/uImage.xtensa-2.6.29-smp.test_mmuhifi_c3''' [Note: You may have to make dir /tftpboot]

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 LX200 board running Linux needs to mount its root file-system over NFS.
This file system was built using buildroot into 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/LINUX_ROOT.HiFi-2_DemoBoard.buildroot-xtensa-smp'''
'''/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 hifi-2_home_default.tar.gz''' [Uncompress /home/default tar ball]
$ '''gunzip hifi-2_usr_local.tar.gz''' [Uncompress /usr/local tar ball]
$
$ '''WHERE=$PWD'''
$ '''mkdir -p /exports/LINUX_ROOT.HiFi-2'''
$
$ '''cd /exports/LINUX_ROOT.HiFi-2'''
$ '''cpio -i < $WHERE/rootfs.xtensa_test_mmuhifi_c3.cpio'''
$
$ '''cd /export'''
$ '''tar xf hifi-2_home_default.tar''' [Tar in boards /home/default for export]
$ '''tar xf hifi-2_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 mypc.foobar.com:
/export *
/exports *
$

== Configuring U-Boot to Boot Linux ==

Your LX200 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 install.

The board has a DIP switch (next to the power on/off switch) that provides the 6 LSBs
of the Ethernet MAC, in switch positions 1 thru 6.

DIP Swithes for MAC: 1 2 3 4 5 6 7 8 ethaddr=00:50:C2:13:6f:0a
Little Endian: 0 1 0 1 0 0 * *
^
|
+------ Enables booting U-Boot from Flash

DIP switch 8 should be shipped in the ON position to enable U-Boot booting from flash.
See Sections 4.2.3 and 4.2.4 of the '''Tensilica Avnet (XT-AV200) Board User's Guide'''
for details. Make sure to select a unique MAC address for you board.

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 [http://en.wikipedia.org/wiki/Minicom minicom]
for this, see [[minicom_xtboard_setup|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 2009.08 (Nov 15 2009 - 22:03:26)

CPU: Xtensa test_mmuhifi_c3 at 41.6777 MHz
Board: XT-AV200: Avnet board + Xilinx LX200 FPGA + Tensilica bitstream
SysRAM: 96 MB
Flash: 16 MB
In: serial
Out: serial
Err: serial
MAC: 00:50:C2:13:6f:07
IP: 192.168.11.105
open_ethernet
Autobooting in 999999 seconds, press <SPACE> to stop '''<SPACE>'''

U-Boot> '''printenv'''
baudrate=38400
ethaddr=00:50:C2:13:6f:07
ethact=open_ethernet
serverip=192.168.11.55
nfsroot_server=192.168.11.55
root-path=/exports/LINUX_ROOT.HiFi-2
bootargs_using_bootp=console=ttyS0,38400 ip=bootp root=nfs coredump_filter=0xff
bootcmd=tftpboot; bootm
netmask=255.255.255.0
gatewayip=192.168.11.1
nfs_boot_args=root=/dev/nfs rw nfsroot=192.168.11.55:/exports/LINUX_ROOT.HiFi-2
bootfile=uImage.xtensa-2.6.29-smp.test_mmuhifi_c3-stable
autostart=no
bootdelay=999999
ipaddr=192.168.11.105
misc_boot_args=debug coredump_filter=0xff
hostname=HiFi-2
nfsaddrs=192.168.11.105:192.168.11.55:192.168.11.1:255.255.255.0:HiFi-2
bootargs=console=ttyS0,38400 ip=192.168.11.105:192.168.11.55:192.168.11.1:255.255.255.0:HiFi-2 root=/dev/nfs rw nfsroot=192.168.11.55:/exports/LINUX_ROOT.HiFi-2 debug coredump_filter=0xff
stdin=serial
stdout=serial
stderr=serial
ver=U-Boot 2009.08 (Nov 15 2009 - 22:03:26)

Environment size: 788/131068 bytes
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.105''' [HOST 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 /exports/LINUX_ROOT.HiFi-2''' [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_NFS Based''' [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>

Alternatively, if you don't feel like setting up an NFS exports you can could use a root filesystem simply located in the kernel RAM.
In this case only TFTP will be used on the local Ethernet to load the kernel. This could be set up with these commands:

U-Boot> '''setenv serverip 192.168.11.55''' [TFTP server IP Address: My Workstation]
U-Boot> '''setenv ipaddr 192.168.11.105''' [HOST 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.ramfs''' [File to fetch with TFTP and pass to bootm]
U-Boot> '''setenv root-path /export2/DC_B_330HiFi_3Core_MMU/LINUX_ROOT.HiFi-2''' [Location of root filesystem on NFS Server; Limit ~50 bytes]
U-Boot> '''setenv ramfs_boot_args root=/dev/ramfs''' [RAMFS Args used in bootargs]
U-Boot> '''setenv hostname HiFi-2_RamFS Based''' [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} ${ramfs_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/hifi-2_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/LINUX_ROOT.HiFi-2'''
$ '''tar xf /exports/hifi-2_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/LINUX_ROOT.HiFi-2'''
$ '''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 LX200. 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 LX200 and it should
auto-boot the kernel, resulting in output such as [[HiFi2_Board_Example_Linux_Boot_Log|this example log]].

== Tailoring your system prior to developing for HiFi 2 ==

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 test_mmuhifi_c3'''

You can either set the PATH and invoke tools prefixed with <tt>xtensa_${CORENAME}-linux-</tt> :

$ '''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 <tt>gcc</tt>.

=== 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 <tt>open()</tt>'s <tt>O_EXCL</tt>
and <tt>stat()</tt>'s <tt>struct stat</tt>, must be avoided because their definitions likely differ between the
Xtensa Tools' default C library and the Linux uClibc library).
''('''Note''': Codecs such as MP3 and AAC are typically 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 test_mmuhifi_c3

$ '''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.
(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|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 test_mmuhifi_c3'''
'''setenv XTENSA_ROOT /home/pdelaney/Xplorer/XtDevTools/install/builds/RC-2009.0-linux/test_mmuhifi_c3'''
'''setenv XTENSA_SYSTEM /home/pdelaney/Xplorer/XtDevTools/install/builds/RC-2009.0-linux/test_mmuhifi_c3/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'''
[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 LX200 board]
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.

== Compiling the Mplayer Plugins and linking them with MPEG-1 Audio Layer 3 (MP3) and MPEG-4 AAC Codecs ==

Mplayer is provided as an example environment for developing and testing Codecs and HiFi 2 software. There
are two ways to build Mplayer and the plug-in modules that use the codecs. The buildroot
tree (pulled with git) has a copy of mplayer and the plugins that can be built in the
snapshot via 'make menuconfig'. This is a good environment to use once codecs are
developed and debugged.

To facilitate development the mplayer packages can be copied to your NFS mounted development
environment. From there you can just configure mplayer to compile on the board and debug
mplayer and your codecs with gdb locally.

In the default user home directory we have a directory /home/default/buildroot_mplayer_stuff
with a copy of three of the mplayer packages:

[root@hifi buildroot_mplayer_stuff]# '''ls -l'''
drwxr-xr-x 34 root root 4096 Nov 10 05:01 MPlayer-1.0rc2/
drwxr-xr-x 4 root root 4096 Nov 10 01:36 mplayer_hifi2_aacplus_v2_plugin/
drwxr-xr-x 3 root root 4096 Nov 10 00:57 mplayer_hifi2_mp3_plugin/

they were simply copied from the buildroot-xtensa-HiFi2-Snapshot.2/package directory.

To get your development environment ready to compile the mplayer plug-ins you need
to configure Mplayer to use the local C compiler and linker:

# '''cd /home/default/buildroot_mplayer_stuff/MPlayer-1.0rc2/'''
# '''CFLAGS="-g3" ./configure'''

This will take about 15 minutes to configure. After that you can build the
plugins or mplayer. If you want to recompile mplayer it's likely best/necessary
to use the same args to .configure as used by buildroot:

.CFLAGS="-g3" ./configure \
--prefix=/usr \
--confdir=/etc/mplayer \
--with-extraincdir=/usr/include \
--with-extralibdir=/lib \
--disable-gui \
--enable-mad \
--enable-fbdev \
--disable-mencoder \
--disable-dvdnav \
--disable-dvdread \
--disable-dvdread-internal \
--disable-libdvdcss-internal \
--disable-big-endian \
--disable-nemesi \
--disable-tv \
--enable-dynamic-plugins

We are currently able to compile mplayer on the LX200 but
due to space limitations it's not possible to compile it -O0.

Now, let's focus on compiling linking the plugins. They are a nice
example of compiling an audio application on the LX200.

We modified the plugin Makefile slightly, and they are available in /home/default/mplayer_packages.
These additions just instruct make how to fetch the codecs and build and install the plugins as explained
in the Chapter 7 of the Linux HiFi application note. With these Makefile additions and the Tensilica
codecs available in the /plugins directory is very easy.

For example the mp3 plugin has this addition:

# We assume Tensilica Codecs have been mounted at /codecs
# via /etc/fstab during boot.
#
CODEC_PACKAGE=xa_hifi2_l32r_LE5_pic_mp3_dec_lib_3_1_api_1_15_lib
CODEC_PACKAGE_LOCATION=/codecs
MPLAYER_DEVEL_LOCATION=/home/default/buildroot_mplayer_stuff

all: '''$(XA_CODEC_NAME)''' $(SLIBNAME) $(XA_CODEC_NAME).so
.
.
.
$(CODEC_PACKAGE).tgz:
cp $(CODEC_PACKAGE_LOCATION)/$(CODEC_PACKAGE).tgz .

$(CODEC_PACKAGE).tar:: $(CODEC_PACKAGE).tgz
gunzip $(CODEC_PACKAGE).tgz

$(XA_CODEC_NAME):: $(CODEC_PACKAGE).tar
tar xf $(CODEC_PACKAGE).tar

install::
@-mkdir /etc/mplayer
cp codecs.conf /etc/mplayer
@-mkdir /usr/lib/mplayer
cp ad_xa_mp3_dec.so /usr/lib/mplayer/
cp xa_mp3_dec.so /usr/lib/mplayer
chmod 755 /usr/lib/mplayer/ad_xa_mp3_dec.so
chmod 755 /usr/lib/mplayer/xa_mp3_dec.so

The make file will be just providing a codec config file for mplayer at '''/etc/mplayer/codecs.conf''' and
copying the plug-in to '''/usr/lib/mplayer'''. To install the mp3 codec plugin and mplayer
config file just copy your codec that was compiled with '''xcc''' to the directory, compile it,
and install. To add mp3 and aac plugins to mplayer you just type '''make''' followed by '''make install''':

[root@hifi mplayer_hifi2_mp3_plugin]# '''make'''
cp /codecs/xa_hifi2_l32r_LE5_pic_mp3_dec_lib_3_1_api_1_15_lib.tgz .
gunzip xa_hifi2_l32r_LE5_pic_mp3_dec_lib_3_1_api_1_15_lib.tgz
tar xf xa_hifi2_l32r_LE5_pic_mp3_dec_lib_3_1_api_1_15_lib.tar
cc -I../libavcodec -I../libavformat -I. -I.. -I../libavutil -W -Wall -O2 -pipe -g3 -D_REENTRANT -DHAVE_CONFIG_H -I/usr/include -DNDEBUG -fvisibility=hidden -Ixa_mp3_dec/include -I../MPlayer-1.0rc2 -Ic
xa_mp3_dec_sample_testbench.c: In function 'xa_mp3_decode_frame':
xa_mp3_dec_sample_testbench.c:185: warning: pointer targets in passing argument 1 of 'xa_mp3_audio_read' differ in signedness
xa_mp3_dec_sample_testbench.c:163: warning: unused variable 'j'
xa_mp3_dec_sample_testbench.c: In function 'mp3_codec_init':
xa_mp3_dec_sample_testbench.c:517: warning: pointer targets in passing argument 1 of 'xa_mp3_audio_read' differ in signedness
xa_mp3_dec_sample_testbench.c: At top level:
xa_mp3_dec_sample_testbench.c:112: warning: 'pack_32_to_24_bits' defined but not used
cc -I../libavcodec -I../libavformat -I. -I.. -I../libavutil -W -Wall -O2 -pipe -g3 -D_REENTRANT -DHAVE_CONFIG_H -I/usr/include -DNDEBUG -fvisibility=hidden -Ixa_mp3_dec/include -I../MPlayer-1.0rc2 -Ic
ad_xa_mp3_dec.c: In function 'xa_mp3_audio_read':
ad_xa_mp3_dec.c:26: warning: pointer targets in passing argument 2 of 'demux_read_data' differ in signedness
ad_xa_mp3_dec.c: In function 'init':
ad_xa_mp3_dec.c:42: warning: pointer targets in passing argument 1 of 'xa_mp3_decode_frame' differ in signedness
ad_xa_mp3_dec.c: At top level:
ad_xa_mp3_dec.c:52: warning: unused parameter 'sh'
ad_xa_mp3_dec.c:56: warning: unused parameter 'arg'
ad_xa_mp3_dec.c:78: warning: unused parameter 'sh_audio'
cc -I../libavcodec -I../libavformat -I. -I.. -I../libavutil -W -Wall -O2 -pipe -g3 -D_REENTRANT -DHAVE_CONFIG_H -I/usr/include -DNDEBUG -fvisibility=hidden -Ixa_mp3_dec/include -I../MPlayer-1.0rc2 -Im
cc -I../libavcodec -I../libavformat -I. -I.. -I../libavutil -W -Wall -O2 -pipe -g3 -D_REENTRANT -DHAVE_CONFIG_H -I/usr/include -DNDEBUG -fvisibility=hidden -Ixa_mp3_dec/include -I../MPlayer-1.0rc2 -Ie
[root@hifi mplayer_hifi2_mp3_plugin]#

[root@hifi mplayer_hifi2_mp3_plugin]# '''make install'''
mkdir: cannot create directory '/etc/mplayer': File exists
make: [install] Error 1 (ignored)
cp codecs.conf /etc/mplayer
mkdir: cannot create directory '/usr/lib/mplayer': File exists
make: [install] Error 1 (ignored)
cp ad_xa_mp3_dec.so /usr/lib/mplayer/
cp xa_mp3_dec.so /usr/lib/mplayer
chmod 755 /usr/lib/mplayer/ad_xa_mp3_dec.so
chmod 755 /usr/lib/mplayer/xa_mp3_dec.so
[root@hifi mplayer_hifi2_mp3_plugin]#

The makefile unpacked of the Tensilica mp3 codec tarball will installed the following files:

xa_mp3_dec/
xa_mp3_dec/README
xa_mp3_dec/include/
xa_mp3_dec/include/mp3_dec/
xa_mp3_dec/include/mp3_dec/xa_mp3_dec_api.h
xa_mp3_dec/include/xa_apicmd_standards.h
xa_mp3_dec/include/xa_error_handler.h
xa_mp3_dec/include/xa_error_standards.h
xa_mp3_dec/include/xa_memory_standards.h
xa_mp3_dec/include/xa_type_def.h
xa_mp3_dec/test/
xa_mp3_dec/test/build/
xa_mp3_dec/test/build/ldscript_stream_data.txt
xa_mp3_dec/test/build/makefile_testbench_sample
xa_mp3_dec/test/build/paramfilesimple.txt
xa_mp3_dec/test/include/
xa_mp3_dec/test/include/id3_tag_decode.h
xa_mp3_dec/test/src/
xa_mp3_dec/test/src/xa_mp3_dec_sample_testbench.c
xa_mp3_dec/test/src/id3_tag_decode.c
xa_mp3_dec/test/src/stream_data.c
xa_mp3_dec/test/src/xa_mp3_dec_error_handler.c
xa_mp3_dec/test/test_inp/
xa_mp3_dec/test/test_inp/compl.mp3
xa_mp3_dec/test/test_inp/hihat.mp3
xa_mp3_dec/test/test_out/
xa_mp3_dec/test/test_out/force_mkdir.txt
xa_mp3_dec/test/test_ref/
xa_mp3_dec/test/test_ref/compl_24bit.wav
xa_mp3_dec/test/test_ref/hihat_16bit.wav
xa_mp3_dec/lib/
xa_mp3_dec/lib/xa_mp3_dec.a
xa_mp3_dec/doc/
xa_mp3_dec/doc/HiFi2-MP3-DecoderProgrammersGuide.pdf

Now, having built and installed the mp3 plugin, do the same for the AAC codec.

[root@hifi ~]# cd /home/default/mplayer_packages/mplayer_hifi2_aacplus_v2_plugin/
[root@hifi mplayer_hifi2_aacplus_v2_plugin]# '''make'''
[root@hifi mplayer_hifi2_aacplus_v2_plugin]# '''make install'''

Additional codecs can be downloaded from the mplayer web site, configured,
compiled and can be installed as usual.

http://www.mplayerhq.hu/DOCS/HTML/en/codec-installation.html

[opencore-amr | opencore-amr]

opencore-amr builds fine and the x264-snapshot compiles completely
but the Makefile and code needs to be set up for ARCH xtensa. The
GPL AAC decoder, faad, has out of date autoconf files, config.sub
and config.guess, need to be updated for Xtensa. This can be easily
done by copying config.sub and config.guess from the x264-snapshot
which had up to date versions recognizing xtensa correctly.

Add on codec install by default to /usr/local/lib and the ldconfig
config file /etc/ld.so.conf needs to have /usr/local/lib added.

Lots of opportunity likely exists for optimizing these codec for
Xtensa extensibility.

[TO BE DONE - Add missing C file, make clean deletes it!]

The xa_mp3_dec.a archive will be used by the Makefile in
the mplayer_hifi2_mp3_plugin directory to make the mplayer plug-in.
Section 6 of the '''Using Tensilica HiFi 2 Codec on Xtensa Linux with MPlayer'' Application Note
has a detailed description of the encapsulation process used by the plug-ins.

== Adding Packages and/or Codec to Buildroot ==

Xtensa developers provide detailed instructions on building the root filesystem and the Linux kernel.
* [[Buildroot_Build_Instructions|Instructions for building and booting Linux (buildroot)]].

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 [[HiFi-2 snapshot_2 SMP Snapshot menuconfig | menuconfig]]'''
$ '''make [[HiFi-2 snapshot_2 SMP uclibc-menuconfig | uclibc-menuconfig]]'''
$ '''make [[HiFi-2 snapshot_2 SMP busybox-menuconfig | 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.

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=

Main Xtensa Linux resources are:

* [http://linux-xtensa.org/ Linux/Xtensa Wiki]
* [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions Buildroot Build Instructions]
* [http://wiki.linux-xtensa.org/index.php/Kernel_Build_Instructions Kernel Build Instructions]
* [http://wiki.linux-xtensa.org/index.php/Setting_up_U-Boot Setting up U-Boot]
* [http://lists.linux-xtensa.org/mailman/listinfo Linux/Xtensa Mailing List]
* http://git.linux-xtensa.org/cgi-bin/git.cgi GIT Repositories]

=Thanks to=

* piet
* marc
* dan
* maxim

And the rest of the people in the Linux-Xtensa mailing list, if you cannot go through some of the steps, don't hesitate to ask on the mailing list, there's always somebody willing to help you!

Setting up U-Boot

2012-03-21T02:37:11Z

Piet: /* LX60 and LX200 U-Boot Installation (LX110 in Progress) */

== LX60 and LX200 U-Boot Installation (LX110 in Progress) ==

''('''News:''' U-Boot for the new DC233, with the V3 MMU, is now working fine and checked into the master branch. Work is almost complete with the Linux 2.6.29-smp kernel, with
Linux now booting from this updated U-Boot. The kernel on the 'Initialize_MMU_Inside_vmlinux' branch seems to be working fine, and has survived 14 hours of stress testing so far.
Plain is to merge this and a few additional branches to the master branch and then move forward to a newer version of the Linux kernel.
'''Summary:'''

[http://www.denx.de/wiki/UBoot U-Boot] is a very popular boot loader; especially within the [http://elinux.org/Bootloader Embedded Linux community].
The U-Boot loader runs on the FPGA boards which are equipped with a dip switch, number 8, which can select where the memory location for the reset
vector (0XFE00,0000) comes from. With switch number 8 off the board will map the memory at the reset vector to a small block of SRAM located in the
I/O block with the UART and Ethernet buffer memory. When switch number 8 is on the Avnet boards map the beginning of the Flash Memory at 0XF800,000
to the reset vector at 0xFE00,000.

What we are going to do here is build a version of U-Boot for your Avnet board and Variant, install that ELF file into memory
with xt-gdb and run U-Boot. Then we are going to download a another copy of this identical program with '''tftp'''. The version we
are going to download is just the ELF file with the headers and debug information removed. It's just the actual bits that get
loaded into memory. For the new V3 MMU the default '''loadaddr''' is typically 0x20,0000 and for the older V2 MMU this is in the
Linux mapping equivalent, 0xD0200,0000. The default location can be change by setting the U-Boot 'loadaddr' environment variable
or by changing the variable '''CONFIG_SYS_LOAD_ADDR''' in the boards U-Boot config file.

Once the virgin copy of the U-Boot program has been loaded into memory, the Flash memory is un-protected and errasd, then the
memory with the U-Boot program in it is copied to the flash memory and protected. Next you will set dip switch 8 on, recycle
power on the board, and U-Boot will be accessible via the serial UART at 38400 baud. U-Boot works without any MMU mapping,
and should be fine on configurations without an MMU. Only an ethernet and serial interface are required.

'''Proceedure:'''

A local port to the Xtensa architecture is now available at linux-xtensa.org. See [http://git.linux-xtensa.org/cgi-bin/git.cgi?p=u-boot/u-boot-xtensa.git;a=summary U-Boot Sources (GIT Summary)]. Or, to access this tree using <tt>git</tt> directly, use something like:

$ '''git clone git://git.linux-xtensa.org/git/u-boot/u-boot-xtensa.git u-boot'''
$ '''cd u-boot'''

''('''Note:''' This path is subject to change.)''

The U-Boot git repository has a branch with a HiFi 2 snapshot made for
the LX200 [[SMP HiFi 2 Development Board]]. With this branch you can simply check
out the snapshot_2+SMP branch which includes the binaries which are discussed below:

$ '''git clone git://git.linux-xtensa.org/git/u-boot/u-boot-xtensa.git u-boot'''
$ '''cd u-boot'''
$ '''git branch --track snapshot_2+SMP origin/snapshot_2+SMP'''
$ '''git checkout snapshot_2+SMP'''

$ '''ls -l u-boot u-boot.bin tools/mkimage'''
-rwxr-xr-x 1 piet tensilica 45016 2009-12-07 19:40 tools/mkimage [This is a small program you need to put in your search path to build kernel U-Boot images]
-rwxr-xr-x 1 piet tensilica 635339 2009-12-07 19:40 u-boot [Started with xt-gdb to bring up the 1st instance of a HiFi 2 U-Boot]
-rwxr-xr-x 1 piet tensilica 144944 2009-12-07 19:40 u-boot.bin [Loaded by the 1st instance of U-Boot, it's a HiFi2 version of u-boot that will be put in flash]
$

Unless you are using a U-Boot snapshot you need to build U-Boot for which you must have built the Buildroot toolchain for XTensa core.
Set your PATH to point to the toolchain built using buildroot. For example:

$ '''export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"'''

where '''<cname>''' is the name of the Xtensa core variant you wish to build for (e.g., <tt>dc232b</tt> <tt>dc233c</tt>).

To build U-Boot, use the cloned git tree pulled above, you should be at the top level of the tree in the '''u-boot''' directory , then configure it for your board and Xtensa core variant as follows:

make distclean
make <cname>'''_<board>_'''config
'dc232b'dc
This should only take a few seconds. For example, to build U-boot for the 'xtav60' board and the older 'dc232b' core with the V2 MMU type:

$ '''cd u-boot'''
$ '''make dc232b_xtav60_config'''

or for the new 'dc233c' core with the new V3 MMU type:

$ '''make dc233c_xtav60_config'''

or for a 'xtav200' board type with the new 'dc233c' core type:

$ '''make dc233c_xtav110_config'''

or for a 'xtav200' board type with the new 'dc233c' core type:

$ '''make dc233c_xtav200_config'''

or for the snapshot_2+SMP branch you can also build U-Boot for the HiFi 2 core:

$ '''make test_mmuhifi_c3_xtav200_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

Only boards and core variants currently supported in the tree can be built out of the box. Headers for supported cores can be found in the tree under <tt>include/asm-xtensa/variant-<cname></tt>. The core specific headers are described in the <tt>doc/README.xtensa</tt> file. To support a new core, these headers must be copied from the overlay in the same way as for the linux kernel.

After the configuration step, to actually build U-Boot, simply:

$ '''make all''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

This will take a quite a few minutes.

This is likely a good time to copy '''mkimage''' to your ${HOME}/bin directory
for later use while building the Linux kernel. The '''mkimage''' program was
just built in the tool directory by the above '''make all'''.

$ '''cd tools'''
$ '''cp mkimage ~/bin''' [NOTE: '''mkimage''' should be in your search PATH while building the Linux kernel]

Next, start xt-gdb and load u-boot from the top of the git repository:

$ '''xt-gdb -n''' [NOTE: Even with the HiFi 2 snapshot_2+SMP branch you still may have to put U-Boot on the board]
(xt-gdb) '''file u-boot'''
(xt-gdb) if V3_MMU
(xt-gdb) '''target remote localhost:20000 0'''
(xt-gdb) else
(xt-gdb) '''target remote localhost:20000 0XD0000000'''
(xt-gdb) end
(xt-gdb) '''reset'''
(xt-gdb) '''load'''
(xt-gdb) '''break panic'''
(xt-gdb) '''continue'''

Hopefully U-Boot will start, and display on the LCD in the case of a LX60.

U-Boot 50.00 Mhz

Often you will be starting with the boards flash in an unknown state and it's best to unprotect and erase the entire flash. Just type '''protect off all''' followed by '''erase all''':

U-Boot> '''protect off all'''
Un-Protect Flash Bank # 1
................................................................................................................................... done
U-Boot> '''erase all'''
Erase Flash Bank # 1
..........................................................................................................
Flash erase timeout at address f8d40000 da0
Flash erase error at address f8d40000
........................ done
U-Boot>

The timeout and error messages are likley just warning messages and you board has been errased. You can see that with the flash info command '''flinfo'''. Below is an example with a LX200 board, which has a much larger flash than the smaller LX60:

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
F8000000 E F8020000 E F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E F8FE0000 E F8FE8000 E F8FF0000 E
F8FF8000 E
U-Boot>

The new LX110 looks very similar to the LX200, also with with 16Mb of Flash:

U-Boot> flinfo

Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 32 bytes

Sector Start Addresses:
F8000000 E F8020000 E F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E F8FE0000 E

Now set your preliminary U-Boot environment variables to point to your TFTP server so we can download yet another copy of U-Boot. At Tensilica we use a machine in the RTOS group called rtos-lab2. Folks using the [[SMP HiFi 2 Development Board]] likely have set up their workstation with a TFTP server.

U-Boot> '''setenv serverip 192.168.11.78''' rtos-lab2
or
U-Boot> '''setenv serverip 192.168.11.55''' pdelaney_fc9

U-Boot> '''setenv ipaddr 192.168.11.95''' I/P address of RTOS5, Piet's LX60; MAC: 00:05:C2:13:6f:0a

U-Boot> '''setenv bootfile u-boot.bin'''
U-Boot> '''saveenv'''
Saving Environment to Flash...
.... done
Un-Protected 4 sectors
Erasing Flash...
.... done
Erased 4 sectors
Writing to Flash... done
.... done
Protected 4 sectors
U-Boot>

Next, download '''u-boot.bin''' from the tftp server using the info we just entered into U-Boot's enviroment variables.
Here for example is the case for a LX60 running the HiFi-2 Bitstream with the older V2 MMU. Note that it starts up
in the D-gazillion (0XD0000000) region:

U-Boot> '''tftpboot'''
TFTP from server 192.168.11.78; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0xd2000000
Loading: T ########
done
Bytes transferred = 107592 (1a448 hex)

For the V3 MMU U-Boot is loaded from host pdelaney_fc9 into memory with virtual == physical. Here is a DC233L, with V3 MMU, example:

U-Boot> '''tftpboot'''
Using open_ethernet device
TFTP from server 192.168.11.55; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: T ########
done
Bytes transferred = 109964 (1ad8c hex)
U-Boot>

Now things get a bit tricky here for the LX60. The FLASH has '''Two sizes of Flash Sectors'''.
The first 8 sectors are small 0x2000 (8KB) and apparently intended for parameters. The rest
of the 4MB flash is composed of larger 0x10000 (64KB) sectors. Our code doesn't differentiate
between the sectors and the LX60 hardware is going to map 0XF800,0000 to 0XFE00,0000 so this
makes us use of all 8 of the 8KB sectors and the 1st 64KB sector at F8010000. So we are going
to flash up to F801FFFF below.

On a LX200 we have much more space and can easily fit a version of U-boot that has been compiled without optimization, make debugging much easier.
So in this case the image is a bit larger, but relatively similar to the LX60 (2 sectors):

U-Boot> '''tftpboot'''
Using open_ethernet device
TFTP from server 192.168.11.78; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0xd2000000
Loading: ###############
done
Bytes transferred = 205852 (3241c hex)
U-Boot>

On a LX110 we have less memory than an LX60, but FLASH sectors like the LX200. It turns out that the u-boot image
compiled with optimization is just a bit larger than 1 sector, so like the LX200 we will need to write u-boot
into two sectors. Here's and example tftpboot of U-Bot for the LX110:

U-Boot> tftpboot
Using open_ethernet device
TFTP from server 192.168.11.55; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: ##########
done
Bytes transferred = 144956 (2363c hex)
U-Boot>

Note that for both the LX200 and the LX60 that the image size, '''(3241c hex)''' in this case, is a bit less than 0x40000 or 10 sectors,
so turn off protection on the 1st 11 sectors and
erase the current contents.

For the '''LX60''' you do this:

U-Boot> '''protect off F8000000 F801FFFF'''
... done
Un-Protected 9 sectors
U-Boot> '''erase F8000000 F801FFFF'''
erase F8000000 F801FFFF
... done
Erased 9 sectors
U-Boot>

For the '''LX200''' and the '''LX110''' the starting address '''(F8000000)''' is the same as with the LX60 but the last address '''(F803FFFF)''' is 'twice' as high:

U-Boot> '''protect off F8000000 F803FFFF'''
... done
Un-Protected 2 sectors
U-Boot> '''erase F8000000 F803FFFF'''
Erased 2 sectors
U-Boot>

Now copy the the image of u-boot.bin in memory to the flash. For the XL60 with the '''OLD''' V2 MMU you copy 0x20000
bytes from 0xd2000000 to 0XF8000000:

U-Boot> '''cp.b d2000000 F8000000 20000'''
Copy to Flash... done

For the LX60 with the '''NEW''' V3 MMU you copy 0x24000 bytes from 0x2000000 to F8000000:

U-Boot> '''cp.b 2000000 F8000000 20000'''
Copy to Flash... done

For the LX200 you copy 0x40000 bytes from 0xd2000000 to 0XF8000000...0XF803FFFF:

U-Boot> '''cp.b d2000000 F8000000 40000'''
Copy to Flash... done

For the LX110 with a V3-MMU you copy 0x40000 bytes from 0x2000000 to F8000000:
U-Boot> cp.b 2000000 F8000000 40000
Copy to Flash... done

Finally we protect these sectors so that U-Boot isn't easily erased by accident.
Below is what it looks like on a LX60 with the New V3 MMU with a subsequent display of the flash info:

U-Boot> '''cp.b 2000000 F8000000 2000'''
Copy to Flash... done
U-Boot> flinfo

Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x2257
Erase timeout: 8192 ms, write timeout: 1 ms

Sector Start Addresses:
'''F8000000 F8002000 F8004000 F8006000 F8008000'''
'''F800A000 F800C000 F800E000 F8010000 '''F8020000 E
F8030000 E F8040000 E F8050000 E F8060000 E F8070000 E
F8080000 E F8090000 E F80A0000 E F80B0000 E F80C0000 E
F80D0000 E F80E0000 E F80F0000 E F8100000 E F8110000 E
F8120000 E F8130000 E F8140000 E F8150000 E F8160000 E
F8170000 E F8180000 E F8190000 E F81A0000 E F81B0000 E
F81C0000 E F81D0000 E F81E0000 E F81F0000 E F8200000 E
F8210000 E F8220000 E F8230000 E F8240000 E F8250000 E
F8260000 E F8270000 E F8280000 E F8290000 E F82A0000 E
F82B0000 E F82C0000 E F82D0000 E F82E0000 E F82F0000 E
F8300000 E F8310000 E F8320000 E F8330000 E F8340000 E
F8350000 E F8360000 E F8370000 E F8380000 E F8390000 E
F83A0000 E F83B0000 E F83C0000 E F83D0000 E F83E0000
'''F83F0000 RO'''
U-Boot> '''protect on F8000000 F801FFFF'''
.......... done
Protected 9 sectors
U-Boot>

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x2257
Erase timeout: 8192 ms, write timeout: 1 ms

Sector Start Addresses:
'''F8000000 RO F8002000 RO F8004000 RO F8006000 RO F8008000 RO
F800A000 RO F800C000 RO F800E000 RO F8010000 RO''' F8020000 E
F8030000 E F8040000 E F8050000 E F8060000 E F8070000 E
F8080000 E F8090000 E F80A0000 E F80B0000 E F80C0000 E
F80D0000 E F80E0000 E F80F0000 E F8100000 E F8110000 E
F8120000 E F8130000 E F8140000 E F8150000 E F8160000 E
F8170000 E F8180000 E F8190000 E F81A0000 E F81B0000 E
F81C0000 E F81D0000 E F81E0000 E F81F0000 E F8200000 E
F8210000 E F8220000 E F8230000 E F8240000 E F8250000 E
F8260000 E F8270000 E F8280000 E F8290000 E F82A0000 E
F82B0000 E F82C0000 E F82D0000 E F82E0000 E F82F0000 E
F8300000 E F8310000 E F8320000 E F8330000 E F8340000 E
F8350000 E F8360000 E F8370000 E F8380000 E F8390000 E
F83A0000 E F83B0000 E F83C0000 E F83D0000 E F83E0000
'''F83F0000 RO'''
U-Boot>

For the '''LX110''' with the '''V3-MMU''' here's what the flash info looks like after we
protect the first two sectors with U-Boot copied to it:

U-Boot> '''protect on F8000000 F803FFFF'''
Protected 2 sectors
U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 32 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E '''F8FE0000 RO'''
U-Boot> help

Below is what it looks like on a '''LX200''' with the '''V2 MMU''' with a subsequent display of the flash info.
Notice that the Flash Sectors are 10X as large on the LX200:

U-Boot> '''protect on F8000000 F803FFFF'''
.. done
Protected 2 sectors
U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E '''F8FE0000 RO F8FE8000 RO F8FF0000 RO'''
'''F8FF8000 RO'''
U-Boot>

Note that the U-Boot '''saveenv''' command Erased and protected the last four sectors
of this LX200.

On both the LX60 and the LX200 now move DIP switch 8 to the ON position, on the LX110 move DIP switch 4 to the ON position.
Next, power cycle the board. On the LX60 you should see U-boot in the LCD display.

The '''LX60''' with the new '''V3 MMU''' the serial console should print something like the following:

U-Boot 2009.08-dirty (Sep 10 2010 - 18:23:26)

CPU: Xtensa dc233c at 50.00 MHz
Board: XT-AV60: Avnet board + Xilinx LX60 FPGA + Tensilica bitstream
SysRAM: 64 MB
Flash: 4 MB
In: serial
Out: serial
Err: serial
MAC: 00:50:C2:13:6f:0a
IP: 192.168.11.95
open_ethernet
U-Boot>

On the '''LX110''' with the new '''V3 MMU''' the serial console should print something like the following:

U-Boot 2009.08-dirty (Nov 15 2010 - 23:04:45)

CPU: Xtensa dc233c at 50.00 MHz
Board: XT-AV110: Avnet board + Xilinx LX110 FPGA + Tensilica bitstream
SysRAM: 48 MB
Flash: 16 MB
In: serial
Out: serial
Err: serial
MAC: 00:50:C2:13:6f:00
IP: 192.168.11.95
open_ethernet
U-Boot>

On the '''LX200''', shown below with the old V2 MMU, you should see something like the following. In this case we also show the flash info command, '''flinfo''', being invoked just after booting U-Boot:

U-Boot 2009.08-dirty (Nov 15 2010 - 23:04:45)

CPU: Xtensa test_mmuhifi_c3 at 41.6777 MHz
Board: XT-AV200: Avnet board + Xilinx LX200 FPGA + Tensilica bitstream
SysRAM: 96 MB
Flash: 16 MB
In: serial
Out: serial
Err: serial
MAC:
IP: 192.168.11.95
U-Boot>

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E RO F8060000 E RO F8080000 E RO
F80A0000 E RO F80C0000 E RO F80E0000 E RO F8100000 E RO F8120000 E RO
F8140000 E RO F8160000 E RO F8180000 E RO F81A0000 E RO F81C0000 E RO
F81E0000 E RO F8200000 E RO F8220000 E RO F8240000 E RO F8260000 E RO
F8280000 E RO F82A0000 E RO F82C0000 E RO F82E0000 E RO F8300000 E RO
F8320000 E RO F8340000 E RO F8360000 E RO F8380000 E RO F83A0000 E RO
F83C0000 E RO F83E0000 E RO F8400000 E RO F8420000 E RO F8440000 E RO
F8460000 E RO F8480000 E RO F84A0000 E RO F84C0000 E RO F84E0000 E RO
F8500000 E RO F8520000 E RO F8540000 E RO F8560000 E RO F8580000 E RO
F85A0000 E RO F85C0000 E RO F85E0000 E RO F8600000 E RO F8620000 E RO
F8640000 E RO F8660000 E RO F8680000 E RO F86A0000 E RO F86C0000 E RO
F86E0000 E RO F8700000 E RO F8720000 E RO F8740000 E RO F8760000 E RO
F8780000 E RO F87A0000 E RO F87C0000 E RO F87E0000 E RO F8800000 E RO
F8820000 E RO F8840000 E RO F8860000 E RO F8880000 E RO F88A0000 E RO
F88C0000 E RO F88E0000 E RO F8900000 E RO F8920000 E RO F8940000 E RO
F8960000 E RO F8980000 E RO F89A0000 E RO F89C0000 E RO F89E0000 E RO
F8A00000 E RO F8A20000 E RO F8A40000 E RO F8A60000 E RO F8A80000 E RO
F8AA0000 E RO F8AC0000 E RO F8AE0000 E RO F8B00000 E RO F8B20000 E RO
F8B40000 E RO F8B60000 E RO F8B80000 E RO F8BA0000 E RO F8BC0000 E RO
F8BE0000 E RO F8C00000 E RO F8C20000 E RO F8C40000 E RO F8C60000 E RO
F8C80000 E RO F8CA0000 E RO F8CC0000 E RO F8CE0000 E RO F8D00000 E RO
F8D20000 E RO F8D40000 E RO F8D60000 E RO F8D80000 E RO F8DA0000 E RO
F8DC0000 E RO F8DE0000 E RO F8E00000 E RO F8E20000 E RO F8E40000 E RO
F8E60000 E RO F8E80000 E RO F8EA0000 E RO F8EC0000 E RO F8EE0000 E RO
F8F00000 E RO F8F20000 E RO F8F40000 E RO F8F60000 E RO F8F80000 E RO
F8FA0000 E RO F8FC0000 E RO '''F8FE0000 RO F8FE8000 RO F8FF0000 RO'''
'''F8FF8000 RO'''
U-Boot>

Note that the 1st two sectors with U-Boot saved in them came up as not being erased ('''E''') but that all sectors came up Read Only ('''RO''').
Same with the last four sectors that the U-Boot '''saveenv''' command Erased. This is likely a '''bug''' on the LX200 boards with some preliminary investigation.
We will be discussing this with the U-Boot developers sometime in the future prior to pushing our U-boot changes upstream.

If U-Boot fails to boot ya might try making sure your U-Boot '''serverip''' environment variable matches the address of the tftp server where
you have copied your '''u-boot.bin''' file to and comparing the bits in the flash that got mapped to 0xfe00,0000 to what in the file:

u-boot]$ '''od -t x4 u-boot.bin | more'''
.0000000 00000206 fe000040 ffffffff a0fffe21
.0000020 00000002 fe01ad14 fe01ad8c 03f95030
.0000040 03f9aa78 04000000 00040003 03f8147c
.0000060 03f81418 00000000 00000000 00000000
.0000100 5300000c 13a00013 4800130c 13493013
.0000120 0c130200 13e62032 22002010 a03200a0
.0000140 1d837680 82037282 72822372 63728243
.0000160 72007272 72720872 18727210 2201d222
.0000200 020c80c2 3d80a032 1d8376f0 d20372d2
.0000220 72d22372 6372d243 f20072f2 72f20872
.0000240 1872f210 2201d222 200080c2 ffd92100
.0000260 37ffda31 02481d12 22681258 145722cb
.0000300 ee1467f1 664b0678 444b0479 06f43457
.0000320 0000fff8 31ffd221 4320ffd2 40443bc0
.0000340 84764142 4b020903 32020c22 837680a0
.0000360 04728211 82247282 72824472 01d22264
.0000400 1180c222 c821ffc8 13e620ff 41002010
.0000420 04d0ffc7 ffc64100 fffffd86 1049c500
.0000440 e52049d5 49f53049 00003400 00000000
.0000460 00000000 00000000 00000000 00000000
.
.(gdb) '''x/100x 0xfe000000'''
.0xfe000000 <_ResetVector>: 0x00000206 0xfe000040 0xffffffff 0xa0fffe21
.0xfe000010 <_ResetVector+16>: 0x00000002 0xfe01ad14 0xfe01ad8c 0x03f95030
.0xfe000020 <_ResetVector+32>: 0x03f9aa78 0x04000000 0x00040003 0x03f8147c
.0xfe000030 <_ResetVector+48>: 0x03f81418 0x00000000 0x00000000 0x00000000
.0xfe000040 <_start>: 0x5300000c 0x13a00013 0x4800130c 0x13493013
.0xfe000050 <_start+16>: 0x0c130200 0x13e62032 0x22002010 0xa03200a0
.0xfe000060 <_start+32>: 0x1d837680 0x82037282 0x72822372 0x63728243
.0xfe000070 <_start+48>: 0x72007272 0x72720872 0x18727210 0x2201d222
.0xfe000080 <_start+64>: 0x020c80c2 0x3d80a032 0x1d8376f0 0xd20372d2
.0xfe000090 <_start+80>: 0x72d22372 0x6372d243 0xf20072f2 0x72f20872
.0xfe0000a0 <_start+96>: 0x1872f210 0x2201d222 0x200080c2 0xffd92100
.0xfe0000b0 <_start+112>: 0x37ffda31 0x02481d12 0x22681258 0x145722cb
.0xfe0000c0 <_start+128>: 0xee1467f1 0x664b0678 0x444b0479 0x06f43457
.0xfe0000d0 <_start+144>: 0x0000fff8 0x31ffd221 0x4320ffd2 0x40443bc0
.0xfe0000e0 <_start+160>: 0x84764142 0x4b020903 0x32020c22 0x837680a0
.0xfe0000f0 <_start+176>: 0x04728211 0x82247282 0x72824472 0x01d22264
.0xfe000100 <_start+192>: 0x1180c222 0xc821ffc8 0x13e620ff 0x41002010
.0xfe000110 <_reset+1>: 0x04d0ffc7 0xffc64100 0x00fffd86 0x1049c500
.0xfe000120: 0xe52049d5 0x49f53049 0x00003400 0x00000000
.0xfe000130: 0x00000000 0x00000000 0x00000000 0x00000000
.(gdb)

Further details on U-Boot in general are in the generic <tt>README</tt> at the top of the U-Boot tree. Details specific to the Xtensa architecture are in <tt>doc/README.xtensa</tt>. Details specific to a board are in <tt>board[/<family>]/<board>/README</tt> (for example <tt>board/avnet/xtav60/README</tt>).

Setting up U-Boot

2012-03-21T02:34:10Z

Piet: /* LX60 and LX200 U-Boot Installation (LX110 in Progress) */

== LX60 and LX200 U-Boot Installation (LX110 in Progress) ==

''('''News:''' U-Boot for the new DC233, with the V3 MMU, is now working fine and checked into the master branch. Work is almost complete with the Linux 2.6.29-smp kernel, with
Linux now booting from this updated U-Boot. The kernel on the 'Initialize_MMU_Inside_vmlinux' branch seems to be working fine, and has survived 14 hours of stress testing so far.
Plain is to merge this and a few additional branches to the master branch and then move forward to a newer version of the Linux kernel.
'''Summary:'''

[http://www.denx.de/wiki/UBoot U-Boot] is a very popular boot loader; especially within the [http://elinux.org/Bootloader Embedded Linux community].
The U-Boot loader runs on the FPGA boards which are equipped with a dip switch, number 8, which can select where the memory location for the reset
vector (0XFE00,0000) comes from. With switch number 8 off the board will map the memory at the reset vector to a small block of SRAM located in the
I/O block with the UART and Ethernet buffer memory. When switch number 8 is on the Avnet boards map the beginning of the Flash Memory at 0XF800,000
to the reset vector at 0xFE00,000.

What we are going to do here is build a version of U-Boot for your Avnet board and Variant, install that ELF file into memory
with xt-gdb and run U-Boot. Then we are going to download a another copy of this identical program with '''tftp'''. The version we
are going to download is just the ELF file with the headers and debug information removed. It's just the actual bits that get
loaded into memory. For the new V3 MMU the default '''loadaddr''' is typically 0x20,0000 and for the older V2 MMU this is in the
Linux mapping equivalent, 0xD0200,0000. The default location can be change by setting the U-Boot 'loadaddr' environment variable
or by changing the variable '''CONFIG_SYS_LOAD_ADDR''' in the boards U-Boot config file.

Once the virgin copy of the U-Boot program has been loaded into memory, the Flash memory is un-protected and errasd, then the
memory with the U-Boot program in it is copied to the flash memory and protected. Next you will set dip switch 8 on, recycle
power on the board, and U-Boot will be accessible via the serial UART at 38400 baud. U-Boot works without any MMU mapping,
and should be fine on configurations without an MMU. Only an ethernet and serial interface are required.

'''Proceedure:'''

A local port to the Xtensa architecture is now available at linux-xtensa.org. See [http://git.linux-xtensa.org/cgi-bin/git.cgi?p=u-boot/u-boot-xtensa.git;a=summary U-Boot Sources (GIT Summary)]. Or, to access this tree using <tt>git</tt> directly, use something like:

$ '''git clone git://git.linux-xtensa.org/git/u-boot/u-boot-xtensa.git u-boot'''
$ '''cd u-boot'''

''('''Note:''' This path is subject to change.)''

The U-Boot git repository has a branch with a HiFi 2 snapshot made for
the LX200 [[SMP HiFi 2 Development Board]]. With this branch you can simply check
out the snapshot_2+SMP branch which includes the binaries which are discussed below:

$ '''git clone git://git.linux-xtensa.org/git/u-boot/u-boot-xtensa.git u-boot'''
$ '''cd u-boot'''
$ '''git branch --track snapshot_2+SMP origin/snapshot_2+SMP'''
$ '''git checkout snapshot_2+SMP'''

$ '''ls -l u-boot u-boot.bin tools/mkimage'''
-rwxr-xr-x 1 piet tensilica 45016 2009-12-07 19:40 tools/mkimage [This is a small program you need to put in your search path to build kernel U-Boot images]
-rwxr-xr-x 1 piet tensilica 635339 2009-12-07 19:40 u-boot [Started with xt-gdb to bring up the 1st instance of a HiFi 2 U-Boot]
-rwxr-xr-x 1 piet tensilica 144944 2009-12-07 19:40 u-boot.bin [Loaded by the 1st instance of U-Boot, it's a HiFi2 version of u-boot that will be put in flash]
$

Unless you are using a U-Boot snapshot you need to build U-Boot for which you must have built the Buildroot toolchain for XTensa core.
Set your PATH to point to the toolchain built using buildroot. For example:

$ '''export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"'''

where '''<cname>''' is the name of the Xtensa core variant you wish to build for (e.g., <tt>dc232b</tt> <tt>dc233c</tt>).

To build U-Boot, use the cloned git tree pulled above, you should be at the top level of the tree in the '''u-boot''' directory , then configure it for your board and Xtensa core variant as follows:

make distclean
make <cname>'''_<board>_'''config
'dc232b'dc
This should only take a few seconds. For example, to build U-boot for the 'xtav60' board and the older 'dc232b' core with the V2 MMU type:

$ '''cd u-boot'''
$ '''make dc232b_xtav60_config'''

or for the new 'dc233c' core with the new V3 MMU type:

$ '''make dc233c_xtav60_config'''

or for a 'xtav200' board type with the new 'dc233c' core type:

$ '''make dc233c_xtav110_config'''

or for a 'xtav200' board type with the new 'dc233c' core type:

$ '''make dc233c_xtav200_config'''

or for the snapshot_2+SMP branch you can also build U-Boot for the HiFi 2 core:

$ '''make test_mmuhifi_c3_xtav200_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

Only boards and core variants currently supported in the tree can be built out of the box. Headers for supported cores can be found in the tree under <tt>include/asm-xtensa/variant-<cname></tt>. The core specific headers are described in the <tt>doc/README.xtensa</tt> file. To support a new core, these headers must be copied from the overlay in the same way as for the linux kernel.

After the configuration step, to actually build U-Boot, simply:

$ '''make all''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

This will take a quite a few minutes.

This is likely a good time to copy '''mkimage''' to your ${HOME}/bin directory
for later use while building the Linux kernel. The '''mkimage''' program was
just built in the tool directory by the above '''make all'''.

$ '''cd tools'''
$ '''cp mkimage ~/bin''' [NOTE: '''mkimage''' should be in your search PATH while building the Linux kernel]

Next, start xt-gdb and load u-boot from the top of the git repository:

$ '''xt-gdb -n''' [NOTE: Even with the HiFi 2 snapshot_2+SMP branch you still may have to put U-Boot on the board]
(xt-gdb) '''file u-boot'''
if V3_MMU
(xt-gdb) '''target remote localhost:20000 0'''
else
(xt-gdb) '''target remote localhost:20000 0XD0000000'''
end
(xt-gdb) '''reset'''
(xt-gdb) '''load'''
(xt-gdb) '''break panic'''
(xt-gdb) '''continue'''

Hopefully U-Boot will start, and display on the LCD in the case of a LX60.

U-Boot 50.00 Mhz

Often you will be starting with the boards flash in an unknown state and it's best to unprotect and erase the entire flash. Just type '''protect off all''' followed by '''erase all''':

U-Boot> '''protect off all'''
Un-Protect Flash Bank # 1
................................................................................................................................... done
U-Boot> '''erase all'''
Erase Flash Bank # 1
..........................................................................................................
Flash erase timeout at address f8d40000 da0
Flash erase error at address f8d40000
........................ done
U-Boot>

The timeout and error messages are likley just warning messages and you board has been errased. You can see that with the flash info command '''flinfo'''. Below is an example with a LX200 board, which has a much larger flash than the smaller LX60:

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
F8000000 E F8020000 E F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E F8FE0000 E F8FE8000 E F8FF0000 E
F8FF8000 E
U-Boot>

The new LX110 looks very similar to the LX200, also with with 16Mb of Flash:

U-Boot> flinfo

Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 32 bytes

Sector Start Addresses:
F8000000 E F8020000 E F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E F8FE0000 E

Now set your preliminary U-Boot environment variables to point to your TFTP server so we can download yet another copy of U-Boot. At Tensilica we use a machine in the RTOS group called rtos-lab2. Folks using the [[SMP HiFi 2 Development Board]] likely have set up their workstation with a TFTP server.

U-Boot> '''setenv serverip 192.168.11.78''' rtos-lab2
or
U-Boot> '''setenv serverip 192.168.11.55''' pdelaney_fc9

U-Boot> '''setenv ipaddr 192.168.11.95''' I/P address of RTOS5, Piet's LX60; MAC: 00:05:C2:13:6f:0a

U-Boot> '''setenv bootfile u-boot.bin'''
U-Boot> '''saveenv'''
Saving Environment to Flash...
.... done
Un-Protected 4 sectors
Erasing Flash...
.... done
Erased 4 sectors
Writing to Flash... done
.... done
Protected 4 sectors
U-Boot>

Next, download '''u-boot.bin''' from the tftp server using the info we just entered into U-Boot's enviroment variables.
Here for example is the case for a LX60 running the HiFi-2 Bitstream with the older V2 MMU. Note that it starts up
in the D-gazillion (0XD0000000) region:

U-Boot> '''tftpboot'''
TFTP from server 192.168.11.78; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0xd2000000
Loading: T ########
done
Bytes transferred = 107592 (1a448 hex)

For the V3 MMU U-Boot is loaded from host pdelaney_fc9 into memory with virtual == physical. Here is a DC233L, with V3 MMU, example:

U-Boot> '''tftpboot'''
Using open_ethernet device
TFTP from server 192.168.11.55; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: T ########
done
Bytes transferred = 109964 (1ad8c hex)
U-Boot>

Now things get a bit tricky here for the LX60. The FLASH has '''Two sizes of Flash Sectors'''.
The first 8 sectors are small 0x2000 (8KB) and apparently intended for parameters. The rest
of the 4MB flash is composed of larger 0x10000 (64KB) sectors. Our code doesn't differentiate
between the sectors and the LX60 hardware is going to map 0XF800,0000 to 0XFE00,0000 so this
makes us use of all 8 of the 8KB sectors and the 1st 64KB sector at F8010000. So we are going
to flash up to F801FFFF below.

On a LX200 we have much more space and can easily fit a version of U-boot that has been compiled without optimization, make debugging much easier.
So in this case the image is a bit larger, but relatively similar to the LX60 (2 sectors):

U-Boot> '''tftpboot'''
Using open_ethernet device
TFTP from server 192.168.11.78; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0xd2000000
Loading: ###############
done
Bytes transferred = 205852 (3241c hex)
U-Boot>

On a LX110 we have less memory than an LX60, but FLASH sectors like the LX200. It turns out that the u-boot image
compiled with optimization is just a bit larger than 1 sector, so like the LX200 we will need to write u-boot
into two sectors. Here's and example tftpboot of U-Bot for the LX110:

U-Boot> tftpboot
Using open_ethernet device
TFTP from server 192.168.11.55; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: ##########
done
Bytes transferred = 144956 (2363c hex)
U-Boot>

Note that for both the LX200 and the LX60 that the image size, '''(3241c hex)''' in this case, is a bit less than 0x40000 or 10 sectors,
so turn off protection on the 1st 11 sectors and
erase the current contents.

For the '''LX60''' you do this:

U-Boot> '''protect off F8000000 F801FFFF'''
... done
Un-Protected 9 sectors
U-Boot> '''erase F8000000 F801FFFF'''
erase F8000000 F801FFFF
... done
Erased 9 sectors
U-Boot>

For the '''LX200''' and the '''LX110''' the starting address '''(F8000000)''' is the same as with the LX60 but the last address '''(F803FFFF)''' is 'twice' as high:

U-Boot> '''protect off F8000000 F803FFFF'''
... done
Un-Protected 2 sectors
U-Boot> '''erase F8000000 F803FFFF'''
Erased 2 sectors
U-Boot>

Now copy the the image of u-boot.bin in memory to the flash. For the XL60 with the '''OLD''' V2 MMU you copy 0x20000
bytes from 0xd2000000 to 0XF8000000:

U-Boot> '''cp.b d2000000 F8000000 20000'''
Copy to Flash... done

For the LX60 with the '''NEW''' V3 MMU you copy 0x24000 bytes from 0x2000000 to F8000000:

U-Boot> '''cp.b 2000000 F8000000 20000'''
Copy to Flash... done

For the LX200 you copy 0x40000 bytes from 0xd2000000 to 0XF8000000...0XF803FFFF:

U-Boot> '''cp.b d2000000 F8000000 40000'''
Copy to Flash... done

For the LX110 with a V3-MMU you copy 0x40000 bytes from 0x2000000 to F8000000:
U-Boot> cp.b 2000000 F8000000 40000
Copy to Flash... done

Finally we protect these sectors so that U-Boot isn't easily erased by accident.
Below is what it looks like on a LX60 with the New V3 MMU with a subsequent display of the flash info:

U-Boot> '''cp.b 2000000 F8000000 2000'''
Copy to Flash... done
U-Boot> flinfo

Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x2257
Erase timeout: 8192 ms, write timeout: 1 ms

Sector Start Addresses:
'''F8000000 F8002000 F8004000 F8006000 F8008000'''
'''F800A000 F800C000 F800E000 F8010000 '''F8020000 E
F8030000 E F8040000 E F8050000 E F8060000 E F8070000 E
F8080000 E F8090000 E F80A0000 E F80B0000 E F80C0000 E
F80D0000 E F80E0000 E F80F0000 E F8100000 E F8110000 E
F8120000 E F8130000 E F8140000 E F8150000 E F8160000 E
F8170000 E F8180000 E F8190000 E F81A0000 E F81B0000 E
F81C0000 E F81D0000 E F81E0000 E F81F0000 E F8200000 E
F8210000 E F8220000 E F8230000 E F8240000 E F8250000 E
F8260000 E F8270000 E F8280000 E F8290000 E F82A0000 E
F82B0000 E F82C0000 E F82D0000 E F82E0000 E F82F0000 E
F8300000 E F8310000 E F8320000 E F8330000 E F8340000 E
F8350000 E F8360000 E F8370000 E F8380000 E F8390000 E
F83A0000 E F83B0000 E F83C0000 E F83D0000 E F83E0000
'''F83F0000 RO'''
U-Boot> '''protect on F8000000 F801FFFF'''
.......... done
Protected 9 sectors
U-Boot>

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x2257
Erase timeout: 8192 ms, write timeout: 1 ms

Sector Start Addresses:
'''F8000000 RO F8002000 RO F8004000 RO F8006000 RO F8008000 RO
F800A000 RO F800C000 RO F800E000 RO F8010000 RO''' F8020000 E
F8030000 E F8040000 E F8050000 E F8060000 E F8070000 E
F8080000 E F8090000 E F80A0000 E F80B0000 E F80C0000 E
F80D0000 E F80E0000 E F80F0000 E F8100000 E F8110000 E
F8120000 E F8130000 E F8140000 E F8150000 E F8160000 E
F8170000 E F8180000 E F8190000 E F81A0000 E F81B0000 E
F81C0000 E F81D0000 E F81E0000 E F81F0000 E F8200000 E
F8210000 E F8220000 E F8230000 E F8240000 E F8250000 E
F8260000 E F8270000 E F8280000 E F8290000 E F82A0000 E
F82B0000 E F82C0000 E F82D0000 E F82E0000 E F82F0000 E
F8300000 E F8310000 E F8320000 E F8330000 E F8340000 E
F8350000 E F8360000 E F8370000 E F8380000 E F8390000 E
F83A0000 E F83B0000 E F83C0000 E F83D0000 E F83E0000
'''F83F0000 RO'''
U-Boot>

For the '''LX110''' with the '''V3-MMU''' here's what the flash info looks like after we
protect the first two sectors with U-Boot copied to it:

U-Boot> '''protect on F8000000 F803FFFF'''
Protected 2 sectors
U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 32 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E '''F8FE0000 RO'''
U-Boot> help

Below is what it looks like on a '''LX200''' with the '''V2 MMU''' with a subsequent display of the flash info.
Notice that the Flash Sectors are 10X as large on the LX200:

U-Boot> '''protect on F8000000 F803FFFF'''
.. done
Protected 2 sectors
U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E '''F8FE0000 RO F8FE8000 RO F8FF0000 RO'''
'''F8FF8000 RO'''
U-Boot>

Note that the U-Boot '''saveenv''' command Erased and protected the last four sectors
of this LX200.

On both the LX60 and the LX200 now move DIP switch 8 to the ON position, on the LX110 move DIP switch 4 to the ON position.
Next, power cycle the board. On the LX60 you should see U-boot in the LCD display.

The '''LX60''' with the new '''V3 MMU''' the serial console should print something like the following:

U-Boot 2009.08-dirty (Sep 10 2010 - 18:23:26)

CPU: Xtensa dc233c at 50.00 MHz
Board: XT-AV60: Avnet board + Xilinx LX60 FPGA + Tensilica bitstream
SysRAM: 64 MB
Flash: 4 MB
In: serial
Out: serial
Err: serial
MAC: 00:50:C2:13:6f:0a
IP: 192.168.11.95
open_ethernet
U-Boot>

On the '''LX110''' with the new '''V3 MMU''' the serial console should print something like the following:

U-Boot 2009.08-dirty (Nov 15 2010 - 23:04:45)

CPU: Xtensa dc233c at 50.00 MHz
Board: XT-AV110: Avnet board + Xilinx LX110 FPGA + Tensilica bitstream
SysRAM: 48 MB
Flash: 16 MB
In: serial
Out: serial
Err: serial
MAC: 00:50:C2:13:6f:00
IP: 192.168.11.95
open_ethernet
U-Boot>

On the '''LX200''', shown below with the old V2 MMU, you should see something like the following. In this case we also show the flash info command, '''flinfo''', being invoked just after booting U-Boot:

U-Boot 2009.08-dirty (Nov 15 2010 - 23:04:45)

CPU: Xtensa test_mmuhifi_c3 at 41.6777 MHz
Board: XT-AV200: Avnet board + Xilinx LX200 FPGA + Tensilica bitstream
SysRAM: 96 MB
Flash: 16 MB
In: serial
Out: serial
Err: serial
MAC:
IP: 192.168.11.95
U-Boot>

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E RO F8060000 E RO F8080000 E RO
F80A0000 E RO F80C0000 E RO F80E0000 E RO F8100000 E RO F8120000 E RO
F8140000 E RO F8160000 E RO F8180000 E RO F81A0000 E RO F81C0000 E RO
F81E0000 E RO F8200000 E RO F8220000 E RO F8240000 E RO F8260000 E RO
F8280000 E RO F82A0000 E RO F82C0000 E RO F82E0000 E RO F8300000 E RO
F8320000 E RO F8340000 E RO F8360000 E RO F8380000 E RO F83A0000 E RO
F83C0000 E RO F83E0000 E RO F8400000 E RO F8420000 E RO F8440000 E RO
F8460000 E RO F8480000 E RO F84A0000 E RO F84C0000 E RO F84E0000 E RO
F8500000 E RO F8520000 E RO F8540000 E RO F8560000 E RO F8580000 E RO
F85A0000 E RO F85C0000 E RO F85E0000 E RO F8600000 E RO F8620000 E RO
F8640000 E RO F8660000 E RO F8680000 E RO F86A0000 E RO F86C0000 E RO
F86E0000 E RO F8700000 E RO F8720000 E RO F8740000 E RO F8760000 E RO
F8780000 E RO F87A0000 E RO F87C0000 E RO F87E0000 E RO F8800000 E RO
F8820000 E RO F8840000 E RO F8860000 E RO F8880000 E RO F88A0000 E RO
F88C0000 E RO F88E0000 E RO F8900000 E RO F8920000 E RO F8940000 E RO
F8960000 E RO F8980000 E RO F89A0000 E RO F89C0000 E RO F89E0000 E RO
F8A00000 E RO F8A20000 E RO F8A40000 E RO F8A60000 E RO F8A80000 E RO
F8AA0000 E RO F8AC0000 E RO F8AE0000 E RO F8B00000 E RO F8B20000 E RO
F8B40000 E RO F8B60000 E RO F8B80000 E RO F8BA0000 E RO F8BC0000 E RO
F8BE0000 E RO F8C00000 E RO F8C20000 E RO F8C40000 E RO F8C60000 E RO
F8C80000 E RO F8CA0000 E RO F8CC0000 E RO F8CE0000 E RO F8D00000 E RO
F8D20000 E RO F8D40000 E RO F8D60000 E RO F8D80000 E RO F8DA0000 E RO
F8DC0000 E RO F8DE0000 E RO F8E00000 E RO F8E20000 E RO F8E40000 E RO
F8E60000 E RO F8E80000 E RO F8EA0000 E RO F8EC0000 E RO F8EE0000 E RO
F8F00000 E RO F8F20000 E RO F8F40000 E RO F8F60000 E RO F8F80000 E RO
F8FA0000 E RO F8FC0000 E RO '''F8FE0000 RO F8FE8000 RO F8FF0000 RO'''
'''F8FF8000 RO'''
U-Boot>

Note that the 1st two sectors with U-Boot saved in them came up as not being erased ('''E''') but that all sectors came up Read Only ('''RO''').
Same with the last four sectors that the U-Boot '''saveenv''' command Erased. This is likely a '''bug''' on the LX200 boards with some preliminary investigation.
We will be discussing this with the U-Boot developers sometime in the future prior to pushing our U-boot changes upstream.

If U-Boot fails to boot ya might try making sure your U-Boot '''serverip''' environment variable matches the address of the tftp server where
you have copied your '''u-boot.bin''' file to and comparing the bits in the flash that got mapped to 0xfe00,0000 to what in the file:

u-boot]$ '''od -t x4 u-boot.bin | more'''
.0000000 00000206 fe000040 ffffffff a0fffe21
.0000020 00000002 fe01ad14 fe01ad8c 03f95030
.0000040 03f9aa78 04000000 00040003 03f8147c
.0000060 03f81418 00000000 00000000 00000000
.0000100 5300000c 13a00013 4800130c 13493013
.0000120 0c130200 13e62032 22002010 a03200a0
.0000140 1d837680 82037282 72822372 63728243
.0000160 72007272 72720872 18727210 2201d222
.0000200 020c80c2 3d80a032 1d8376f0 d20372d2
.0000220 72d22372 6372d243 f20072f2 72f20872
.0000240 1872f210 2201d222 200080c2 ffd92100
.0000260 37ffda31 02481d12 22681258 145722cb
.0000300 ee1467f1 664b0678 444b0479 06f43457
.0000320 0000fff8 31ffd221 4320ffd2 40443bc0
.0000340 84764142 4b020903 32020c22 837680a0
.0000360 04728211 82247282 72824472 01d22264
.0000400 1180c222 c821ffc8 13e620ff 41002010
.0000420 04d0ffc7 ffc64100 fffffd86 1049c500
.0000440 e52049d5 49f53049 00003400 00000000
.0000460 00000000 00000000 00000000 00000000
.
.(gdb) '''x/100x 0xfe000000'''
.0xfe000000 <_ResetVector>: 0x00000206 0xfe000040 0xffffffff 0xa0fffe21
.0xfe000010 <_ResetVector+16>: 0x00000002 0xfe01ad14 0xfe01ad8c 0x03f95030
.0xfe000020 <_ResetVector+32>: 0x03f9aa78 0x04000000 0x00040003 0x03f8147c
.0xfe000030 <_ResetVector+48>: 0x03f81418 0x00000000 0x00000000 0x00000000
.0xfe000040 <_start>: 0x5300000c 0x13a00013 0x4800130c 0x13493013
.0xfe000050 <_start+16>: 0x0c130200 0x13e62032 0x22002010 0xa03200a0
.0xfe000060 <_start+32>: 0x1d837680 0x82037282 0x72822372 0x63728243
.0xfe000070 <_start+48>: 0x72007272 0x72720872 0x18727210 0x2201d222
.0xfe000080 <_start+64>: 0x020c80c2 0x3d80a032 0x1d8376f0 0xd20372d2
.0xfe000090 <_start+80>: 0x72d22372 0x6372d243 0xf20072f2 0x72f20872
.0xfe0000a0 <_start+96>: 0x1872f210 0x2201d222 0x200080c2 0xffd92100
.0xfe0000b0 <_start+112>: 0x37ffda31 0x02481d12 0x22681258 0x145722cb
.0xfe0000c0 <_start+128>: 0xee1467f1 0x664b0678 0x444b0479 0x06f43457
.0xfe0000d0 <_start+144>: 0x0000fff8 0x31ffd221 0x4320ffd2 0x40443bc0
.0xfe0000e0 <_start+160>: 0x84764142 0x4b020903 0x32020c22 0x837680a0
.0xfe0000f0 <_start+176>: 0x04728211 0x82247282 0x72824472 0x01d22264
.0xfe000100 <_start+192>: 0x1180c222 0xc821ffc8 0x13e620ff 0x41002010
.0xfe000110 <_reset+1>: 0x04d0ffc7 0xffc64100 0x00fffd86 0x1049c500
.0xfe000120: 0xe52049d5 0x49f53049 0x00003400 0x00000000
.0xfe000130: 0x00000000 0x00000000 0x00000000 0x00000000
.(gdb)

Further details on U-Boot in general are in the generic <tt>README</tt> at the top of the U-Boot tree. Details specific to the Xtensa architecture are in <tt>doc/README.xtensa</tt>. Details specific to a board are in <tt>board[/<family>]/<board>/README</tt> (for example <tt>board/avnet/xtav60/README</tt>).

Setting up U-Boot

2012-03-16T21:18:48Z

Piet: /* LX60 and LX200 U-Boot Installation (LX110 in Progress) */

== LX60 and LX200 U-Boot Installation (LX110 in Progress) ==

''('''News:''' U-Boot for the new DC233, with the V3 MMU, is now working fine and checked into the master branch. Work is almost complete with the Linux 2.6.29-smp kernel, with
Linux now booting from this updated U-Boot. The kernel on the 'Initialize_MMU_Inside_vmlinux' branch seems to be working fine, and has survived 14 hours of stress testing so far.
Plain is to merge this and a few additional branches to the master branch and then move forward to a newer version of the Linux kernel.
'''Summary:'''

[http://www.denx.de/wiki/UBoot U-Boot] is a very popular boot loader; especially within the [http://elinux.org/Bootloader Embedded Linux community].
The U-Boot loader runs on the FPGA boards which are equipped with a dip switch, number 8, which can select where the memory location for the reset
vector (0XFE00,0000) comes from. With switch number 8 off the board will map the memory at the reset vector to a small block of SRAM located in the
I/O block with the UART and Ethernet buffer memory. When switch number 8 is on the Avnet boards map the beginning of the Flash Memory at 0XF800,000
to the reset vector at 0xFE00,000.

What we are going to do here is build a version of U-Boot for your Avnet board and Variant, install that ELF file into memory
with xt-gdb and run U-Boot. Then we are going to download a another copy of this identical program with '''tftp'''. The version we
are going to download is just the ELF file with the headers and debug information removed. It's just the actual bits that get
loaded into memory. For the new V3 MMU the default '''loadaddr''' is typically 0x20,0000 and for the older V2 MMU this is in the
Linux mapping equivalent, 0xD0200,0000. The default location can be change by setting the U-Boot 'loadaddr' environment variable
or by changing the variable '''CONFIG_SYS_LOAD_ADDR''' in the boards U-Boot config file.

Once the virgin copy of the U-Boot program has been loaded into memory, the Flash memory is un-protected and errasd, then the
memory with the U-Boot program in it is copied to the flash memory and protected. Next you will set dip switch 8 on, recycle
power on the board, and U-Boot will be accessible via the serial UART at 38400 baud. U-Boot works without any MMU mapping,
and should be fine on configurations without an MMU. Only an ethernet and serial interface are required.

'''Proceedure:'''

A local port to the Xtensa architecture is now available at linux-xtensa.org. See [http://git.linux-xtensa.org/cgi-bin/git.cgi?p=u-boot/u-boot-xtensa.git;a=summary U-Boot Sources (GIT Summary)]. Or, to access this tree using <tt>git</tt> directly, use something like:

$ '''git clone git://git.linux-xtensa.org/git/u-boot/u-boot-xtensa.git u-boot'''
$ '''cd u-boot'''

''('''Note:''' This path is subject to change.)''

The U-Boot git repository has a branch with a HiFi 2 snapshot made for
the LX200 [[SMP HiFi 2 Development Board]]. With this branch you can simply check
out the snapshot_2+SMP branch which includes the binaries which are discussed below:

$ '''git clone git://git.linux-xtensa.org/git/u-boot/u-boot-xtensa.git u-boot'''
$ '''cd u-boot'''
$ '''git branch --track snapshot_2+SMP origin/snapshot_2+SMP'''
$ '''git checkout snapshot_2+SMP'''

$ '''ls -l u-boot u-boot.bin tools/mkimage'''
-rwxr-xr-x 1 piet tensilica 45016 2009-12-07 19:40 tools/mkimage [This is a small program you need to put in your search path to build kernel U-Boot images]
-rwxr-xr-x 1 piet tensilica 635339 2009-12-07 19:40 u-boot [Started with xt-gdb to bring up the 1st instance of a HiFi 2 U-Boot]
-rwxr-xr-x 1 piet tensilica 144944 2009-12-07 19:40 u-boot.bin [Loaded by the 1st instance of U-Boot, it's a HiFi2 version of u-boot that will be put in flash]
$

Unless you are using a U-Boot snapshot you need to build U-Boot for which you must have built the Buildroot toolchain for XTensa core.
Set your PATH to point to the toolchain built using buildroot. For example:

$ '''export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"'''

where '''<cname>''' is the name of the Xtensa core variant you wish to build for (e.g., <tt>dc232b</tt> <tt>dc233c</tt>).

To build U-Boot, use the cloned git tree pulled above, you should be at the top level of the tree in the '''u-boot''' directory , then configure it for your board and Xtensa core variant as follows:

make distclean
make <cname>'''_<board>_'''config
'dc232b'dc
This should only take a few seconds. For example, to build U-boot for the 'xtav60' board and the older 'dc232b' core with the V2 MMU type:

$ '''cd u-boot'''
$ '''make dc232b_xtav60_config'''

or for the new 'dc233c' core with the new V3 MMU type:

$ '''make dc233c_xtav60_config'''

or for a 'xtav200' board type with the new 'dc233c' core type:

$ '''make dc233c_xtav110_config'''

or for a 'xtav200' board type with the new 'dc233c' core type:

$ '''make dc233c_xtav200_config'''

or for the snapshot_2+SMP branch you can also build U-Boot for the HiFi 2 core:

$ '''make test_mmuhifi_c3_xtav200_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

Only boards and core variants currently supported in the tree can be built out of the box. Headers for supported cores can be found in the tree under <tt>include/asm-xtensa/variant-<cname></tt>. The core specific headers are described in the <tt>doc/README.xtensa</tt> file. To support a new core, these headers must be copied from the overlay in the same way as for the linux kernel.

After the configuration step, to actually build U-Boot, simply:

$ '''make all''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

This will take a quite a few minutes.

This is likely a good time to copy '''mkimage''' to your ${HOME}/bin directory
for later use while building the Linux kernel. The '''mkimage''' program was
just built in the tool directory by the above '''make all'''.

$ '''cd tools'''
$ '''cp mkimage ~/bin''' [NOTE: '''mkimage''' should be in your search PATH while building the Linux kernel]

Next, start xt-gdb and load u-boot from the top of the git repository:

$ '''xt-gdb -n''' [NOTE: Even with the HiFi 2 snapshot_2+SMP branch you still may have to put U-Boot on the board]
(xt-gdb) '''file u-boot'''
(xt-gdb) '''target remote localhost:20000 0'''
(xt-gdb) '''reset'''
(xt-gdb) '''load'''
(xt-gdb) '''break panic'''
(xt-gdb) '''continue'''

Hopefully U-Boot will start, and display on the LCD in the case of a LX60.

U-Boot 50.00 Mhz

Often you will be starting with the boards flash in an unknown state and it's best to unprotect and erase the entire flash. Just type '''protect off all''' followed by '''erase all''':

U-Boot> '''protect off all'''
Un-Protect Flash Bank # 1
................................................................................................................................... done
U-Boot> '''erase all'''
Erase Flash Bank # 1
..........................................................................................................
Flash erase timeout at address f8d40000 da0
Flash erase error at address f8d40000
........................ done
U-Boot>

The timeout and error messages are likley just warning messages and you board has been errased. You can see that with the flash info command '''flinfo'''. Below is an example with a LX200 board, which has a much larger flash than the smaller LX60:

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
F8000000 E F8020000 E F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E F8FE0000 E F8FE8000 E F8FF0000 E
F8FF8000 E
U-Boot>

The new LX110 looks very similar to the LX200, also with with 16Mb of Flash:

U-Boot> flinfo

Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 32 bytes

Sector Start Addresses:
F8000000 E F8020000 E F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E F8FE0000 E

Now set your preliminary U-Boot environment variables to point to your TFTP server so we can download yet another copy of U-Boot. At Tensilica we use a machine in the RTOS group called rtos-lab2. Folks using the [[SMP HiFi 2 Development Board]] likely have set up their workstation with a TFTP server.

U-Boot> '''setenv serverip 192.168.11.78''' rtos-lab2
or
U-Boot> '''setenv serverip 192.168.11.55''' pdelaney_fc9

U-Boot> '''setenv ipaddr 192.168.11.95''' I/P address of RTOS5, Piet's LX60; MAC: 00:05:C2:13:6f:0a

U-Boot> '''setenv bootfile u-boot.bin'''
U-Boot> '''saveenv'''
Saving Environment to Flash...
.... done
Un-Protected 4 sectors
Erasing Flash...
.... done
Erased 4 sectors
Writing to Flash... done
.... done
Protected 4 sectors
U-Boot>

Next, download '''u-boot.bin''' from the tftp server using the info we just entered into U-Boot's enviroment variables.
Here for example is the case for a LX60 running the HiFi-2 Bitstream with the older V2 MMU. Note that it starts up
in the D-gazillion (0XD0000000) region:

U-Boot> '''tftpboot'''
TFTP from server 192.168.11.78; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0xd2000000
Loading: T ########
done
Bytes transferred = 107592 (1a448 hex)

For the V3 MMU U-Boot is loaded from host pdelaney_fc9 into memory with virtual == physical. Here is a DC233L, with V3 MMU, example:

U-Boot> '''tftpboot'''
Using open_ethernet device
TFTP from server 192.168.11.55; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: T ########
done
Bytes transferred = 109964 (1ad8c hex)
U-Boot>

Now things get a bit tricky here for the LX60. The FLASH has '''Two sizes of Flash Sectors'''.
The first 8 sectors are small 0x2000 (8KB) and apparently intended for parameters. The rest
of the 4MB flash is composed of larger 0x10000 (64KB) sectors. Our code doesn't differentiate
between the sectors and the LX60 hardware is going to map 0XF800,0000 to 0XFE00,0000 so this
makes us use of all 8 of the 8KB sectors and the 1st 64KB sector at F8010000. So we are going
to flash up to F801FFFF below.

On a LX200 we have much more space and can easily fit a version of U-boot that has been compiled without optimization, make debugging much easier.
So in this case the image is a bit larger, but relatively similar to the LX60 (2 sectors):

U-Boot> '''tftpboot'''
Using open_ethernet device
TFTP from server 192.168.11.78; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0xd2000000
Loading: ###############
done
Bytes transferred = 205852 (3241c hex)
U-Boot>

On a LX110 we have less memory than an LX60, but FLASH sectors like the LX200. It turns out that the u-boot image
compiled with optimization is just a bit larger than 1 sector, so like the LX200 we will need to write u-boot
into two sectors. Here's and example tftpboot of U-Bot for the LX110:

U-Boot> tftpboot
Using open_ethernet device
TFTP from server 192.168.11.55; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: ##########
done
Bytes transferred = 144956 (2363c hex)
U-Boot>

Note that for both the LX200 and the LX60 that the image size, '''(3241c hex)''' in this case, is a bit less than 0x40000 or 10 sectors,
so turn off protection on the 1st 11 sectors and
erase the current contents.

For the '''LX60''' you do this:

U-Boot> '''protect off F8000000 F801FFFF'''
... done
Un-Protected 9 sectors
U-Boot> '''erase F8000000 F801FFFF'''
erase F8000000 F801FFFF
... done
Erased 9 sectors
U-Boot>

For the '''LX200''' and the '''LX110''' the starting address '''(F8000000)''' is the same as with the LX60 but the last address '''(F803FFFF)''' is 'twice' as high:

U-Boot> '''protect off F8000000 F803FFFF'''
... done
Un-Protected 2 sectors
U-Boot> '''erase F8000000 F803FFFF'''
Erased 2 sectors
U-Boot>

Now copy the the image of u-boot.bin in memory to the flash. For the XL60 with the '''OLD''' V2 MMU you copy 0x20000
bytes from 0xd2000000 to 0XF8000000:

U-Boot> '''cp.b d2000000 F8000000 20000'''
Copy to Flash... done

For the LX60 with the '''NEW''' V3 MMU you copy 0x24000 bytes from 0x2000000 to F8000000:

U-Boot> '''cp.b 2000000 F8000000 20000'''
Copy to Flash... done

For the LX200 you copy 0x40000 bytes from 0xd2000000 to 0XF8000000...0XF803FFFF:

U-Boot> '''cp.b d2000000 F8000000 40000'''
Copy to Flash... done

For the LX110 with a V3-MMU you copy 0x40000 bytes from 0x2000000 to F8000000:
U-Boot> cp.b 2000000 F8000000 40000
Copy to Flash... done

Finally we protect these sectors so that U-Boot isn't easily erased by accident.
Below is what it looks like on a LX60 with the New V3 MMU with a subsequent display of the flash info:

U-Boot> '''cp.b 2000000 F8000000 2000'''
Copy to Flash... done
U-Boot> flinfo

Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x2257
Erase timeout: 8192 ms, write timeout: 1 ms

Sector Start Addresses:
'''F8000000 F8002000 F8004000 F8006000 F8008000'''
'''F800A000 F800C000 F800E000 F8010000 '''F8020000 E
F8030000 E F8040000 E F8050000 E F8060000 E F8070000 E
F8080000 E F8090000 E F80A0000 E F80B0000 E F80C0000 E
F80D0000 E F80E0000 E F80F0000 E F8100000 E F8110000 E
F8120000 E F8130000 E F8140000 E F8150000 E F8160000 E
F8170000 E F8180000 E F8190000 E F81A0000 E F81B0000 E
F81C0000 E F81D0000 E F81E0000 E F81F0000 E F8200000 E
F8210000 E F8220000 E F8230000 E F8240000 E F8250000 E
F8260000 E F8270000 E F8280000 E F8290000 E F82A0000 E
F82B0000 E F82C0000 E F82D0000 E F82E0000 E F82F0000 E
F8300000 E F8310000 E F8320000 E F8330000 E F8340000 E
F8350000 E F8360000 E F8370000 E F8380000 E F8390000 E
F83A0000 E F83B0000 E F83C0000 E F83D0000 E F83E0000
'''F83F0000 RO'''
U-Boot> '''protect on F8000000 F801FFFF'''
.......... done
Protected 9 sectors
U-Boot>

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x2257
Erase timeout: 8192 ms, write timeout: 1 ms

Sector Start Addresses:
'''F8000000 RO F8002000 RO F8004000 RO F8006000 RO F8008000 RO
F800A000 RO F800C000 RO F800E000 RO F8010000 RO''' F8020000 E
F8030000 E F8040000 E F8050000 E F8060000 E F8070000 E
F8080000 E F8090000 E F80A0000 E F80B0000 E F80C0000 E
F80D0000 E F80E0000 E F80F0000 E F8100000 E F8110000 E
F8120000 E F8130000 E F8140000 E F8150000 E F8160000 E
F8170000 E F8180000 E F8190000 E F81A0000 E F81B0000 E
F81C0000 E F81D0000 E F81E0000 E F81F0000 E F8200000 E
F8210000 E F8220000 E F8230000 E F8240000 E F8250000 E
F8260000 E F8270000 E F8280000 E F8290000 E F82A0000 E
F82B0000 E F82C0000 E F82D0000 E F82E0000 E F82F0000 E
F8300000 E F8310000 E F8320000 E F8330000 E F8340000 E
F8350000 E F8360000 E F8370000 E F8380000 E F8390000 E
F83A0000 E F83B0000 E F83C0000 E F83D0000 E F83E0000
'''F83F0000 RO'''
U-Boot>

For the '''LX110''' with the '''V3-MMU''' here's what the flash info looks like after we
protect the first two sectors with U-Boot copied to it:

U-Boot> '''protect on F8000000 F803FFFF'''
Protected 2 sectors
U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 32 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E '''F8FE0000 RO'''
U-Boot> help

Below is what it looks like on a '''LX200''' with the '''V2 MMU''' with a subsequent display of the flash info.
Notice that the Flash Sectors are 10X as large on the LX200:

U-Boot> '''protect on F8000000 F803FFFF'''
.. done
Protected 2 sectors
U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E '''F8FE0000 RO F8FE8000 RO F8FF0000 RO'''
'''F8FF8000 RO'''
U-Boot>

Note that the U-Boot '''saveenv''' command Erased and protected the last four sectors
of this LX200.

On both the LX60 and the LX200 now move DIP switch 8 to the ON position, on the LX110 move DIP switch 4 to the ON position.
Next, power cycle the board. On the LX60 you should see U-boot in the LCD display.

The '''LX60''' with the new '''V3 MMU''' the serial console should print something like the following:

U-Boot 2009.08-dirty (Sep 10 2010 - 18:23:26)

CPU: Xtensa dc233c at 50.00 MHz
Board: XT-AV60: Avnet board + Xilinx LX60 FPGA + Tensilica bitstream
SysRAM: 64 MB
Flash: 4 MB
In: serial
Out: serial
Err: serial
MAC: 00:50:C2:13:6f:0a
IP: 192.168.11.95
open_ethernet
U-Boot>

On the '''LX110''' with the new '''V3 MMU''' the serial console should print something like the following:

U-Boot 2009.08-dirty (Nov 15 2010 - 23:04:45)

CPU: Xtensa dc233c at 50.00 MHz
Board: XT-AV110: Avnet board + Xilinx LX110 FPGA + Tensilica bitstream
SysRAM: 48 MB
Flash: 16 MB
In: serial
Out: serial
Err: serial
MAC: 00:50:C2:13:6f:00
IP: 192.168.11.95
open_ethernet
U-Boot>

On the '''LX200''', shown below with the old V2 MMU, you should see something like the following. In this case we also show the flash info command, '''flinfo''', being invoked just after booting U-Boot:

U-Boot 2009.08-dirty (Nov 15 2010 - 23:04:45)

CPU: Xtensa test_mmuhifi_c3 at 41.6777 MHz
Board: XT-AV200: Avnet board + Xilinx LX200 FPGA + Tensilica bitstream
SysRAM: 96 MB
Flash: 16 MB
In: serial
Out: serial
Err: serial
MAC:
IP: 192.168.11.95
U-Boot>

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E RO F8060000 E RO F8080000 E RO
F80A0000 E RO F80C0000 E RO F80E0000 E RO F8100000 E RO F8120000 E RO
F8140000 E RO F8160000 E RO F8180000 E RO F81A0000 E RO F81C0000 E RO
F81E0000 E RO F8200000 E RO F8220000 E RO F8240000 E RO F8260000 E RO
F8280000 E RO F82A0000 E RO F82C0000 E RO F82E0000 E RO F8300000 E RO
F8320000 E RO F8340000 E RO F8360000 E RO F8380000 E RO F83A0000 E RO
F83C0000 E RO F83E0000 E RO F8400000 E RO F8420000 E RO F8440000 E RO
F8460000 E RO F8480000 E RO F84A0000 E RO F84C0000 E RO F84E0000 E RO
F8500000 E RO F8520000 E RO F8540000 E RO F8560000 E RO F8580000 E RO
F85A0000 E RO F85C0000 E RO F85E0000 E RO F8600000 E RO F8620000 E RO
F8640000 E RO F8660000 E RO F8680000 E RO F86A0000 E RO F86C0000 E RO
F86E0000 E RO F8700000 E RO F8720000 E RO F8740000 E RO F8760000 E RO
F8780000 E RO F87A0000 E RO F87C0000 E RO F87E0000 E RO F8800000 E RO
F8820000 E RO F8840000 E RO F8860000 E RO F8880000 E RO F88A0000 E RO
F88C0000 E RO F88E0000 E RO F8900000 E RO F8920000 E RO F8940000 E RO
F8960000 E RO F8980000 E RO F89A0000 E RO F89C0000 E RO F89E0000 E RO
F8A00000 E RO F8A20000 E RO F8A40000 E RO F8A60000 E RO F8A80000 E RO
F8AA0000 E RO F8AC0000 E RO F8AE0000 E RO F8B00000 E RO F8B20000 E RO
F8B40000 E RO F8B60000 E RO F8B80000 E RO F8BA0000 E RO F8BC0000 E RO
F8BE0000 E RO F8C00000 E RO F8C20000 E RO F8C40000 E RO F8C60000 E RO
F8C80000 E RO F8CA0000 E RO F8CC0000 E RO F8CE0000 E RO F8D00000 E RO
F8D20000 E RO F8D40000 E RO F8D60000 E RO F8D80000 E RO F8DA0000 E RO
F8DC0000 E RO F8DE0000 E RO F8E00000 E RO F8E20000 E RO F8E40000 E RO
F8E60000 E RO F8E80000 E RO F8EA0000 E RO F8EC0000 E RO F8EE0000 E RO
F8F00000 E RO F8F20000 E RO F8F40000 E RO F8F60000 E RO F8F80000 E RO
F8FA0000 E RO F8FC0000 E RO '''F8FE0000 RO F8FE8000 RO F8FF0000 RO'''
'''F8FF8000 RO'''
U-Boot>

Note that the 1st two sectors with U-Boot saved in them came up as not being erased ('''E''') but that all sectors came up Read Only ('''RO''').
Same with the last four sectors that the U-Boot '''saveenv''' command Erased. This is likely a '''bug''' on the LX200 boards with some preliminary investigation.
We will be discussing this with the U-Boot developers sometime in the future prior to pushing our U-boot changes upstream.

If U-Boot fails to boot ya might try making sure your U-Boot '''serverip''' environment variable matches the address of the tftp server where
you have copied your '''u-boot.bin''' file to and comparing the bits in the flash that got mapped to 0xfe00,0000 to what in the file:

u-boot]$ '''od -t x4 u-boot.bin | more'''
.0000000 00000206 fe000040 ffffffff a0fffe21
.0000020 00000002 fe01ad14 fe01ad8c 03f95030
.0000040 03f9aa78 04000000 00040003 03f8147c
.0000060 03f81418 00000000 00000000 00000000
.0000100 5300000c 13a00013 4800130c 13493013
.0000120 0c130200 13e62032 22002010 a03200a0
.0000140 1d837680 82037282 72822372 63728243
.0000160 72007272 72720872 18727210 2201d222
.0000200 020c80c2 3d80a032 1d8376f0 d20372d2
.0000220 72d22372 6372d243 f20072f2 72f20872
.0000240 1872f210 2201d222 200080c2 ffd92100
.0000260 37ffda31 02481d12 22681258 145722cb
.0000300 ee1467f1 664b0678 444b0479 06f43457
.0000320 0000fff8 31ffd221 4320ffd2 40443bc0
.0000340 84764142 4b020903 32020c22 837680a0
.0000360 04728211 82247282 72824472 01d22264
.0000400 1180c222 c821ffc8 13e620ff 41002010
.0000420 04d0ffc7 ffc64100 fffffd86 1049c500
.0000440 e52049d5 49f53049 00003400 00000000
.0000460 00000000 00000000 00000000 00000000
.
.(gdb) '''x/100x 0xfe000000'''
.0xfe000000 <_ResetVector>: 0x00000206 0xfe000040 0xffffffff 0xa0fffe21
.0xfe000010 <_ResetVector+16>: 0x00000002 0xfe01ad14 0xfe01ad8c 0x03f95030
.0xfe000020 <_ResetVector+32>: 0x03f9aa78 0x04000000 0x00040003 0x03f8147c
.0xfe000030 <_ResetVector+48>: 0x03f81418 0x00000000 0x00000000 0x00000000
.0xfe000040 <_start>: 0x5300000c 0x13a00013 0x4800130c 0x13493013
.0xfe000050 <_start+16>: 0x0c130200 0x13e62032 0x22002010 0xa03200a0
.0xfe000060 <_start+32>: 0x1d837680 0x82037282 0x72822372 0x63728243
.0xfe000070 <_start+48>: 0x72007272 0x72720872 0x18727210 0x2201d222
.0xfe000080 <_start+64>: 0x020c80c2 0x3d80a032 0x1d8376f0 0xd20372d2
.0xfe000090 <_start+80>: 0x72d22372 0x6372d243 0xf20072f2 0x72f20872
.0xfe0000a0 <_start+96>: 0x1872f210 0x2201d222 0x200080c2 0xffd92100
.0xfe0000b0 <_start+112>: 0x37ffda31 0x02481d12 0x22681258 0x145722cb
.0xfe0000c0 <_start+128>: 0xee1467f1 0x664b0678 0x444b0479 0x06f43457
.0xfe0000d0 <_start+144>: 0x0000fff8 0x31ffd221 0x4320ffd2 0x40443bc0
.0xfe0000e0 <_start+160>: 0x84764142 0x4b020903 0x32020c22 0x837680a0
.0xfe0000f0 <_start+176>: 0x04728211 0x82247282 0x72824472 0x01d22264
.0xfe000100 <_start+192>: 0x1180c222 0xc821ffc8 0x13e620ff 0x41002010
.0xfe000110 <_reset+1>: 0x04d0ffc7 0xffc64100 0x00fffd86 0x1049c500
.0xfe000120: 0xe52049d5 0x49f53049 0x00003400 0x00000000
.0xfe000130: 0x00000000 0x00000000 0x00000000 0x00000000
.(gdb)

Further details on U-Boot in general are in the generic <tt>README</tt> at the top of the U-Boot tree. Details specific to the Xtensa architecture are in <tt>doc/README.xtensa</tt>. Details specific to a board are in <tt>board[/<family>]/<board>/README</tt> (for example <tt>board/avnet/xtav60/README</tt>).

Buildroot Snapshots

2011-06-22T07:22:32Z

Piet:

= Stable Snapshots of Buildroot and the Linux kernel [CURRENTLY OUT OF DATE] =

As an alternative to using the latest source files from GIT and Subversion, you can use one of the snapshot bundles available on the [http://www.linux-xtensa.org/download.html download page]. These snapshots include versions of the Linux kernel and the Buildroot files that have been tested to work together, as well as associated build documentation that matches those snapshots. Unfortunately the current snapshots are very old and need to be replaced with new versions. We currently recommend you clone git repositories and use stable branches/tags.

(If you want the latest sources instead, please refer to the
latest [[Buildroot_Build_Instructions]].)

Unofficial LTP test results are available in the [[LTP_Results| LTP Test Results]] page.

{| border=1 style="text-align:center" cellpadding=4 cellspacing=0
|+ '''List of GIT Commit Points for Each Snapshot and the Current Recommended Source Code'''
|-
! rowspan="2" | Snapshot
! colspan="2" | Linux Kernel
! colspan="2" | Buildroot
! rowspan="2" | Comments
|-
! GIT Tree !! Commit/Tag !! GIT Tree !! Commit/Tag/Branch
|-
| linux-xtensa-20080123.tar.gz || xtensa-2.6.24 || 50f17d5ba5d2 || buildroot-xtensa || dd6f0d70fb1f
| First snapshot [No Longer Supported]
|-
| linux-xtensa-20080711.tar.gz || xtensa-2.6.24 || ce5325b68b14 || buildroot-xtensa || 16f39dfdde4b
| Second snapshot [No Longer Supported]
|-
| || xtensa-2.6.29-smp || || buildroot-xtensa-HiFi2-Snapshot || snapshot_2+SMP
| Second snapshot + SMP [Only Available via GIT]

|-
|}

Instructions for building and booting Linux

2011-05-03T04:28:41Z

Piet: /* Download buildroot and the Linux kernel */

These instructions explain how to build a toolchain, root filesystem and kernel for Linux running on an Xtensa processor. These instructions apply specifically to the XTAV60 (LX60) board.

Some general notes on these instructions:

* They are a work in progress. If you are using the latest development sources, the build process may change, so you should be sure to get the latest version of this document at [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions]. If you are using one of the development snapshot releases, you should use the version of the build instructions included with that snapshot.

* The following was tested on x86 machines running RedHat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3). It is expected to work on newer Fedora releases (e.g., was tested on FC6) but to maintain host compatibility with Xtensa Tools, it is best to avoid Fedora releases beyond FC5. Other host distributions likely work but have not been tested.
** '''NOTE:''' this assumes the default selection of packages in buildroot. Selecting extra packages may require a more recent host OS or more recent version of certain tools. For example, the default version of <tt>find</tt> on RHEL4 is too old to allow building all X11 packages in buildroot, so it is necessary to upgrade the host version of <tt>findutils</tt> on RHEL4 to build these packages.

* Lines prefixed with "sudo" need to be executed as root. The rest is best executed as a non-root user. (It is possible to install <tt>git</tt> as a non-root user if root access is an issue. How to do this isn't shown here.)

* Lines that set environment variables assume a Bourne compatible shell (e.g., /bin/sh or bash), but are easily adapted to other shells.

* Instructions are assumed executed all in order (e.g., commands assume current directory and environment variables set earlier).

== Setup your host system ==

If you are using one of the snapshot releases, you can skip this step.

If you want to work with the latest development sources, you will need
[[Installing GIT|<tt>git</tt> installed on your system]].

== Download buildroot and the Linux kernel ==

The following section describes how to download the latest
versions of buildroot and of the Linux kernel.
Skip this step if you are using one of the
[http://wiki.linux-xtensa.org/index.php/Buildroot_Snapshots snapshot releases].

Adventurous users that want to use the '''bleeding edge''' code can execute the following:

'''$ cd <workdir>'''
'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa.git buildroot''' [NOT RECOMMENDED, NEWER PACKAGES BUT DEVELOPMENT ENVIRONMENT BROKEN]
'''$ git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git linux'''

where <tt><workdir></tt> is the path to an empty directory on a disk with
at least 4 GB available space. You end up with the following file structure,
which is assumed by the rest of this document:

<workdir>/
/buildroot
/linux

The MASTER branch of the buildroot repository is often is a state of development.
It's recommended to use the last snapshot for application developers. In the
case of the Avnet development boards a 'snapshot_2+SMP' branch is recommended
in the currently experimental SMP git repository:

'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa-HiFi2-Snapshot.git buildroot''' [RECOMEND YOU USE THIS GIT REPO]
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

If you happen to have write access to either repository you should change '''git:''' to '''git+ssh:'''
For Example:

'''$ git clone git+ssh://git.linux-xtensa.org/git/buildroot/buildroot-xtensa-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

For more details, see the [http://wiki.linux-xtensa.org/index.php/Repository_Access repository access] page.

== Install any required processor specific overlay ==

This step is required if you are targeting a custom Xtensa processor.
If you use a Diamond 232L Standard Core, you can skip this step.

To configure buildroot and the kernel to use a custom Xtensa processor
configuration, you need to overlay a set of files customized for your
processor configuration onto toolchain sources (gcc, binutils, gdb, etc)
and the Linux kernel. This process has been automated using a script
located in the buildroot source tree.
For usage information, you can invoke it without arguments:

'''$ cd <workdir>'''
'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install'''

which displays a help message similar to the following:

xt-buildroot-overlay-install version 1.3
Usage: xt-buildroot-overlay-install <parameters> [<options>]
Where <parameters> are:
-t file.tgz Specify path to the Xtensa Linux overlay tarball, typically
<xtensa_root>/src/xtensa-config-overlay.tar.gz
-b dir Path to the base of the buildroot source tree, in which
package specific overlay tarballs get installed.
-k dir Path to the base of the Linux kernel source tree, in which
the Linux kernel specific overlay gets installed.
-c config_name Name for the Xtensa processor configuration as it will be
known to the open source community. Must be a lowercase
identifier, starting with a letter, consisting of letters
and numbers and underscores, not ending with underscore
and not containing consecutive underscores. For examples:
dc232b , dc232b_be , mmubasele , fsf , s5000 .
-l long_name Long name for the Xtensa processor configuration, human-
readable with spaces etc allowed (must be quoted).
For example: 'Diamond 232L Standard Core Rev.B (LE)'
Try to keep it within approximately 40 characters.
And <options> are:
-f If package specific overlay tarballs already exist in
the destination source tree, overwrite them without asking.
--help Show this usage message.

Note that the Xtensa Linux overlay tarball MUST be obtained from an Xtensa
core package built using release RB-2008.3 or later.

Here is an example invocation of the overlay installation script:

'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install -t blinkcore-config-overlay.tar.gz''' \
'''-b ./buildroot -k ./linux -c superzip -l "ChipCorp SuperZIP Blink Accelerator Core"'''

The script extracts some relevant information from the overlay tarball,
presents it along with relevant parameters to the user, and prompts
for confirmation before proceeding.

The chosen processor name (-c option) must be unique among known Xtensa processors.
It is also probably wise to avoid names confusingly similar to other (non-Xtensa) processors.
If you expect at some point to contribute support for your custom processor to the
open-source community, this name will likely be long-lived.
(One way to contribute support for a custom processor might be to submit the overlay tarball
or files to the linux-xtensa.org maintainers.)

In the steps below, buildroot and the Linux kernel must be configured
(in their respective <code>''make menuconfig''</code> steps) to select
the <code>''custom''</code> Xtensa processor option.
This presents an extra configuration menu entry where you must provide
the name of the Xtensa processor. Set it to the same name
as was specified in the <code>-c</code> option above.

== Build a toolchain and root filesystem using buildroot ==

'''Note:''' for more details on generic buildroot topics not covered in this simple how-to,
see [http://buildroot.uclibc.org/ buildroot.uclibc.org].

=== Configure buildroot ===

The first time you configure buildroot, start with defaults for your Xtensa processor:

'''$ cd <workdir>/buildroot'''
'''$ ./target/xtensa/setup-config <corename>'''

where ''<corename>'' is the overlay name of your selected Xtensa or Diamond core
(e.g., '''dc233c'''). If you omit ''<corename>'', a help message and a list
of currently installed Tensilica core overlays is displayed.

Optionally, you can then customize your buildroot configuration, such as
selecting additional packages, setting various parameters, and so on.
The following make targets provide a ''curses'' (text-based graphical) interface
for configuring buildroot, the uClibc C library, and busybox, respectively.
('''Note:''' You need the <tt>TERM</tt> environment variable properly set for
these curses based tools to work.)

'''$ make menuconfig'''
'''$ make uclibc-menuconfig'''
'''$ make busybox-menuconfig'''

=== Build buildroot ===

Just type:

'''$ make'''

THIS WILL TAKE A LONG TIME (from about 30 minutes with defaults on a 3 GHz Pentium 4,
to perhaps an hour or many depending on your system and on whether
you enabled extra packages in your buildroot configuration).

Wait patiently for the build to complete. This builds an entire toolchain
as well as some basic packages, and constructs a root filesystem.
It might build many more packages if you selected them earlier with menuconfig.

==== If Something Goes Wrong ====

Perhaps you missed some step above and the build fails. Or you're just switching to a different processor configuration, or making some change with unknown dependencies. Either way, you'll probably need to fix the error and/or make the change, and redo the whole build. The above <tt>make</tt> command usually works fine if you
just added a package using menuconfig, but otherwise does not check many dependencies, so it will usually NOT rebuild things that depend on whatever you have fixed or changed. Here's one way to retry the make from scratch without having to wipe out the <tt>buildroot</tt> directory tree completely and start again from the git cloning.

$ '''rm -rf *build_xtensa* binaries'''
$ '''make'''

It is not necessary to empty the 'dl' subdirectory, which contains tarballs downloaded from the Internet, nor the .config file, which contains the buildroot configuration. Customizations to the uClibc and <tt>busybox</tt> configurations should have ended up getting saved in target/xtensa/uClibc.config and target/xtensa/busybox-config, respectively, so hopefully are preserved by the above sequence.

== Build and Run a Linux Kernel on the XTAV60, AXAV110, or XTAV200 Boards ==

References to the ''XTAV60 board'' refer to the combination of
the Avnet [http://www.em.avnet.com/tensilica1 LX60 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX60 (XT-AV60) Board User's Guide''.

Similarly, references to the ''XTAV200 board'' refers the combination of
the Avnet [http://www.em.avnet.com/tensilica2 LX200 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX200 (XT-AV200) Board User's Guide''.

=== Configure the kernel ===

The kernel build is a two-step process: configure the kernel, and build it.
First, before we can do anything with the kernel, set your PATH to
point to the toolchain built using buildroot.

$ '''export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"'''

where ''<cname>'' is the name of the Xtensa processor configuration you selected
when building the toolchain (e.g., <code>dc232b</code>).

Now setup a destination for kernel builds.
We usually like to have the build directory separate from
the source directory, so we use 'O=</destination/path>' in
kernel make commands. If you'll be routinely building multiple
configurations of the Linux kernel, it's good to have some
naming conventions for the build directory. For example,
to experiment with multiple target platforms but only one
processor configuration, we include just the platform name here:

$'''mkdir build-xtav60'''

Let's start with the default kernel configuration for the Avnet board
(which works on both XTAV60 (LX60), XTAV110 (LX110), and XTAV200 (LX200) boards)
as follows:

$ '''cd linux'''
$ '''make O=../build-xtav60 ARCH=xtensa KBUILD_DEFCONFIG=lx60_defconfig defconfig'''

This configures the kernel using the default configuration found in
'''arch/xtensa/configs/lx60_defconfig'''.

'''NOTE:''' This kernel configuration has nothing to do with Xtensa
processor configuration. That comes next.

Let's now customize this a little bit to select the correct Xtensa processor
configuration, and to bundle the root filesystem into the kernel:

$ '''make O=../build-xtav60 ARCH=xtensa menuconfig'''

Under '''General setup''',
make sure the '''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is enabled. Underneath that, edit '''Initramfs source file(s)''',
and enter the path to the cpio formatted root filesystem
generated by buildroot:

''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio.gz

(Don't forget to replace ''<workdir>'' with the appropriate full path
and ''<cname>'' with your Xtensa processor configuration name.)

Under '''Processor type and features''',
make sure the '''Xtensa Processor Configuration''' is correct and matches
the processor configuration name you used to build the toolchain with buildroot
(for example, ''dc232b'' for Diamond 232L Rev.B).
The kernel build selects a toolchain and processor variant specific headers
based on this selection.
If the desired processor configuration does not appear explicitly in the list,
simply select '''Custom Xtensa processor configuration''' and enter the
processor configuration name (all lowercase) into the next menu parameter,
'''Xtensa Processor Custom Variant Name'''.

Back in the main menu, under '''Platform options''', make sure the
'''CPU clock rate''' entry is set correctly according to the following table:

{| border="1" style="text-align:center; margin: 1em auto 1em auto"
|-
! Board !! Frequency selected in XPG (MHz) !! ''CPU clock rate'' setting (kHz)
|-
|rowspan="3"| XTAV60 (LX60)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV110 (LX110)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV200 (LX200)
| 30 || 31250
|-
| 40 || 41667
|-
| 50 || 50000
|-
|}

Exit menuconfig, saving your configuration changes.

Backup your configuration outside the build directory. For example:

$ '''cp ../build-xtav60/.config config.xtav60.saved'''

If you do a clean rebuild of the kernel (e.g., "rm -rf ../build-xtav60")
you can now configure it with simply:
$ '''mkdir ../build-xtav60 ; cp config.xtav60.saved ../build-xtav60/.config'''
Of course if you update the kernel, you'll probably again have to do:
$ '''make O=../build-xtav60 ARCH=xtensa menuconfig'''
and save a new copy of your configuration.

=== Build the kernel ===

$ '''make O=../build-xtav60 ARCH=xtensa'''

The build will issue a few warnings which are normal.
Once complete, the bootable image is in:
<workdir>/build-xtav60/arch/xtensa/boot/Image.elf
and the uncompressed ELF file containing kernel symbols is in:
<workdir>/build-xtav60/vmlinux
There is also a RedBoot bootable image (if you use RedBoot) in:
<workdir>/build-xtav60/arch/xtensa/boot/zImage.redboot

=== Install Xtensa Tools for the selected core ===

If you opt to download the kernel over OCD, you need <tt>xt-gdb</tt>
which is part of Tensilica's Xtensa Tools package. This must be obtained
from Tensilica, and is not the same toolchain as built by buildroot.
You also need to install the corresponding Tensilica core package,
so that the Xtensa Tools know about your particular configured
Tensilica core.

The toolchain built using buildroot can be configured to
include GDB, but that version of GDB does not support
communicating with Tensilica's Xtensa OCD Daemon, and
thus cannot be used to download the kernel over OCD.

In this example, it is assumed that the machine hosting the
Xtensa Tools has access to the <workdir> directory tree.

=== Install and setup the Xtensa OCD Daemon ===

Setup and connect your JTAG probe, etc.

=== Connect a terminal server ===

At 38400 bps 8N1 no flow control to the XTAV60 serial port.

=== Optionally, setup networking ===

This step is optional.

Setup the board's MAC address using dipswitches
(see XTAV60 or XTAV200 board docs as appropriate)
and connect the board to a network that has a
DHCP server that will respond to that MAC address.
If you don't do this step, you'll simply not have network
access, and the boot process will take a minute or so longer
while the kernel times out waiting for a BOOTP response.
You can edit the kernel configuration and rebuild the kernel
to avoid using bootp (in particular, remove "ip=bootp" from
the kernel cmdline).

=== Download and run the kernel ===

Reset the board (see board documentation).

Using Xtensa Tools, invoke:

$ '''xt-gdb <workdir>/build-xtav60/arch/xtensa/boot/Image.elf'''

'''(xt-gdb) target remote <ocdhost>:20000 0'''
'''(xt-gdb) reset'''
'''(xt-gdb) load'''
'''(xt-gdb) set $pc = &_ResetVector'''
'''(xt-gdb) symbol-file <workdir>/build-xtav60/vmlinux'''
'''(xt-gdb) c'''

where <ocdhost> is the IP address or DNS name of the machine
running the Xtensa OCD daemon. The Linux kernel should
start booting as soon as 'c' (continue) is executed.

You should eventually get a login prompt.
Just login as root (no password).

Try various Linux commands. Look at <tt>/bin</tt>,
<tt>/sbin</tt>, <tt>/usr/bin</tt>, etc to see what's available.

'''Note:''' no need to setup an NFS or TFTP server. The filesystem
is contained within the kernel image. You may be able to mount
other filesystems over NFS though, if you wish, after booting.

Recently the MMU was modified to come up uninitialized and it's
necessary for the Linux kernel to map the MMU prior to running.
This means you can't place breakpoints in the kernel until the
mapping has been completed. It's likely worth while looking
at the example .xt-gdbinit file in the Kernel Xtensa Documentation:

xtensa-2.6.29-smp-xcc-O3/Documentation/xtensa/gdbmacros/xt-gdbinit

When running on Avnet boards it's necessary to use a HardWare Breakpoint
at the kernel symbol '''set_breakpoints''' which is near ''' _startup'''
and set your early kernel breakpoints once you get to this hardware breakpoint.

With ISS simulation normal breakpoints must be used.

Below is an example snippet from the sample '''xt-gdbinit''' script:

if $debug_hw_breakpoints_supported
hbreak set_breakpoints
else
break set_breakpoints
end

set var $_startup = $bpnum
commands $_startup
set_breakpoints
delete $_startup
info breakpoints
set var $doing_commands = 0
end

=== Mounting the Root Filesystem Over NFS ===

If you build more than the minimal set of packages using
buildroot, the root filesystem can easily grow too large to
fit comfortably (or at all) inside the kernel. In this case,
rather than follow the instructions exactly as above,
you'll want to mount the root filesystem over NFS.

You may also want to mount the root filesystem over NFS to
make changes to the filesystem persistent across runs and
accessible from your development host.

First you need to install the root filesystem generated
using buildroot, to a machine that can serve it over NFS.
Assuming this machine runs Linux, one way to install it is
as follows:

$ '''mkdir ''<exportpath>'' '''
$ '''cd ''<exportpath>'' '''
$ '''sudo cpio -i -d -m -F ''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio --no-absolute-filenames '''

You then need to enable the NFS server on your system
(if not already active), and export this filesystem.
How you do this depends on your host Linux distribution.
For example, on some Fedora releases, one might:

* add the export path to <tt>/etc/exports</tt> using a line such as

''<exportpath>'' *(rw,sync,no_root_squash,no_all_squash,no_wdelay)

* turn on the NFS server if needed:

$ '''sudo /sbin/chkconfig nfs on'''

* tell the NFS server about the new exported filesystem

$ '''sudo /usr/sbin/exportfs -a'''
$ '''sudo /usr/sbin/exportfs -r'''

Second, follow the instructions in the previous sections,
then configure the kernel again as follows.

Under '''General setup''', make sure the
'''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is disabled (rather than enabled as done in previous sections).

Under '''Platform options''', under the line '''Default bootloader kernel arguments''',
select the boot parameters line and set it to something like this:

'''console=ttyS0,38400 ip=dhcp root=/dev/nfs rw nfsroot=''<server_ip>'':''<exportpath>'' '''

where ''<server_ip>'' is the IP address of your NFS server, and ''<exportpath>''
is the exported filesystem path.

Another approach is to just specify the ip addresses directly in the CMDLINE
'''CONFIG_CMDLINE="console=ttyS0,38400 ip=192.168.11.95:192.168.11.220:192.168.11.1:255.255.255.0:HiFi-2 root=/dev/nfs rw nfsroot=192.168.11.55:/exports/LINUX_ROOT.DC_C_233L debug coredump_filter=0xff" '''

Where the IP addresses are in the form:

'''${ipaddr}:${nfsroot_server}:${gatewayip}:${netmask}:${hostname}'''

Save this configuration, rebuild the kernel, and follow the
instructions in previous sections to download and run the kernel.
If everything goes well and is setup correctly, your kernel should
now boot with a root filesystem mounted over NFS.

== Build and Run a Linux Kernel on the Instruction Set Simulator (ISS) ==

You can build and run a Linux kernel in the Xtensa Instruction Set
Simulator (ISS). The following instructions have only been tried
with an ISS from the RB-2008.3 release of Xtensa Tools. Bear in
mind that the XTAV60 port is likely much more stable than the ISS port
of Linux at this point in time.

Note: Depending on your host OS version, you may need to install
Xtensa Tools on a separate machine.

=== Configure and Build the Kernel for ISS ===

Repeat all the same instructions as above for building the kernel for an
Avnet board, except that when initially configuring the kernel,
start from a ISS platform template instead. For example for the
DC233C Variant:

'''$ mkdir build-iss'''
'''$ cd linux'''
'''$ make O=../build-iss ARCH=xtensa KBUILD_DEFCONFIG=iss_dc233c_defconfig defconfig'''

The above make example configures the kernel using the default configuration found in
'''arch/xtensa/configs/iss_dc233_defconfig'''. Most important to note is that the
root file system mounted when Linux boots comes via the targets device '''/dev/simdisk0'''
which is defined in the kernel '''.config''' file. For example:

'''CONFIG_SIMDISK0_FILENAME="/export2/DC_C_233L/LINUX_ROOT.ext2"'''

The SIMDISK file name and VARIANT name are typically configured when running '''make menuconfig'''; Ex:

'''$ make O=../build-iss ARCH=xtensa menuconfig'''

and selecting

'''Xtensa Platform options''' ---> '''Host filename for a simulated device'''

and entering the pathname to the .ext2 file there. Ex: '''/export2/DC_C_233L/LINUX_ROOT.ext2'''

You often want to change the VARIANT to the one you desire, Ex: FSF. You do this via
the top level menu:

'''Xtensa Processor type and features ---> Xtensa Processor Custom Core Variant Name'''

With the new SIMDISK approach you copy the EXT2 Filesystem file generated by Buildroot
to a location to be accessed by Xtensa Linux. Ex:

'''$ cp /export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot/binaries/dc233c/rootfs.xtensa_dc233c.ext2 /export2/DC_C_233L/LINUX_ROOT.ext2'''

'''NOTE:''' There is an old '''iss_defconfig''' that tries to use a '''tuntap''' Ethernet
interface that currently isn't supported.
Previously with this old iss_defconfig using the '''tuntap''' Ethernet interface
it was suggested to set up the initramfs filesystem, and do the following.
Under '''Bus Options''', deselect '''PCI support'''.
Under '''Platform Options''', deselect '''Default bootloader kernel arguments'''.
Hopefully we will someday be able to support the use of a network interface with
ISS simulation and then be able to mount NFS root partitions again. So I'm leaving
this note for future exploration of this mechanism; Hope you don't mind the clutter.

Continue configuring and building the kernel as usual.

=== Run the Kernel on ISS ===

Using Xtensa Tools, invoke:

'''$ xt-gdb <workdir>/build-iss/arch/xtensa/boot/Image.elf'''
'''(xt-gdb) target sim --turbo --memlimit=128'''
'''(xt-gdb) symbol-file <workdir>/build-iss/vmlinux'''
'''(xt-gdb) run'''

Wait patiently while Linux boots ... (maybe a minute). The setting of the '''memlimit'''
needs to match the PLATFORM_DEFAULT_MEM_SIZE defined in /arch/xtensa/platforms/iss/include/platform/hardware.h.
Currently this limit us 128 MegaBytes:

#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000 /* 13,4217,728 128M */

and we will be extending this for the DC233L to take advantage of it's V3 MMU.

Login as root (no password).

'''Note:''' Input via ISS is cooked, so everything typed gets echoed.
Also, time as reported by the kernel does not progress
according to true wall-clock time: it currently depends on
a simulated processor clock, which advances at various speeds
according to load.

Instructions for building and booting Linux

2011-04-20T23:46:46Z

Piet:

These instructions explain how to build a toolchain, root filesystem and kernel for Linux running on an Xtensa processor. These instructions apply specifically to the XTAV60 (LX60) board.

Some general notes on these instructions:

* They are a work in progress. If you are using the latest development sources, the build process may change, so you should be sure to get the latest version of this document at [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions]. If you are using one of the development snapshot releases, you should use the version of the build instructions included with that snapshot.

* The following was tested on x86 machines running RedHat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3). It is expected to work on newer Fedora releases (e.g., was tested on FC6) but to maintain host compatibility with Xtensa Tools, it is best to avoid Fedora releases beyond FC5. Other host distributions likely work but have not been tested.
** '''NOTE:''' this assumes the default selection of packages in buildroot. Selecting extra packages may require a more recent host OS or more recent version of certain tools. For example, the default version of <tt>find</tt> on RHEL4 is too old to allow building all X11 packages in buildroot, so it is necessary to upgrade the host version of <tt>findutils</tt> on RHEL4 to build these packages.

* Lines prefixed with "sudo" need to be executed as root. The rest is best executed as a non-root user. (It is possible to install <tt>git</tt> as a non-root user if root access is an issue. How to do this isn't shown here.)

* Lines that set environment variables assume a Bourne compatible shell (e.g., /bin/sh or bash), but are easily adapted to other shells.

* Instructions are assumed executed all in order (e.g., commands assume current directory and environment variables set earlier).

== Setup your host system ==

If you are using one of the snapshot releases, you can skip this step.

If you want to work with the latest development sources, you will need
[[Installing GIT|<tt>git</tt> installed on your system]].

== Download buildroot and the Linux kernel ==

The following section describes how to download the latest
versions of buildroot and of the Linux kernel.
Skip this step if you are using one of the
[http://wiki.linux-xtensa.org/index.php/Buildroot_Snapshots snapshot releases].

Adventurous users that want to use the '''bleeding edge''' code can execute the following:

'''$ cd <workdir>'''
'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa.git buildroot''' [NOT RECOMMENDED, NEWER PACKAGES BUT DEVELOPMENT ENVIRONMENT BROKEN]
'''$ git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git linux'''

where <tt><workdir></tt> is the path to an empty directory on a disk with
at least 4 GB available space. You end up with the following file structure,
which is assumed by the rest of this document:

<workdir>/
/buildroot
/linux

The MASTER branch of the buildroot repository is often is a state of development.
It's recommended to use the last snapshot for application developers. In the
case of the Avnet development boards a 'snapshot_2+SMP' branch is recommended
in the currently experimental SMP git repository:

'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot''' [RECOMEND YOU USE THIS GIT REPO]
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

If you happen to have write access to either repository you should change '''git:''' to '''git+ssh:'''
For Example:

'''$ git clone git+ssh://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

For more details, see the [http://wiki.linux-xtensa.org/index.php/Repository_Access repository access] page.

== Install any required processor specific overlay ==

This step is required if you are targeting a custom Xtensa processor.
If you use a Diamond 232L Standard Core, you can skip this step.

To configure buildroot and the kernel to use a custom Xtensa processor
configuration, you need to overlay a set of files customized for your
processor configuration onto toolchain sources (gcc, binutils, gdb, etc)
and the Linux kernel. This process has been automated using a script
located in the buildroot source tree.
For usage information, you can invoke it without arguments:

'''$ cd <workdir>'''
'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install'''

which displays a help message similar to the following:

xt-buildroot-overlay-install version 1.3
Usage: xt-buildroot-overlay-install <parameters> [<options>]
Where <parameters> are:
-t file.tgz Specify path to the Xtensa Linux overlay tarball, typically
<xtensa_root>/src/xtensa-config-overlay.tar.gz
-b dir Path to the base of the buildroot source tree, in which
package specific overlay tarballs get installed.
-k dir Path to the base of the Linux kernel source tree, in which
the Linux kernel specific overlay gets installed.
-c config_name Name for the Xtensa processor configuration as it will be
known to the open source community. Must be a lowercase
identifier, starting with a letter, consisting of letters
and numbers and underscores, not ending with underscore
and not containing consecutive underscores. For examples:
dc232b , dc232b_be , mmubasele , fsf , s5000 .
-l long_name Long name for the Xtensa processor configuration, human-
readable with spaces etc allowed (must be quoted).
For example: 'Diamond 232L Standard Core Rev.B (LE)'
Try to keep it within approximately 40 characters.
And <options> are:
-f If package specific overlay tarballs already exist in
the destination source tree, overwrite them without asking.
--help Show this usage message.

Note that the Xtensa Linux overlay tarball MUST be obtained from an Xtensa
core package built using release RB-2008.3 or later.

Here is an example invocation of the overlay installation script:

'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install -t blinkcore-config-overlay.tar.gz''' \
'''-b ./buildroot -k ./linux -c superzip -l "ChipCorp SuperZIP Blink Accelerator Core"'''

The script extracts some relevant information from the overlay tarball,
presents it along with relevant parameters to the user, and prompts
for confirmation before proceeding.

The chosen processor name (-c option) must be unique among known Xtensa processors.
It is also probably wise to avoid names confusingly similar to other (non-Xtensa) processors.
If you expect at some point to contribute support for your custom processor to the
open-source community, this name will likely be long-lived.
(One way to contribute support for a custom processor might be to submit the overlay tarball
or files to the linux-xtensa.org maintainers.)

In the steps below, buildroot and the Linux kernel must be configured
(in their respective <code>''make menuconfig''</code> steps) to select
the <code>''custom''</code> Xtensa processor option.
This presents an extra configuration menu entry where you must provide
the name of the Xtensa processor. Set it to the same name
as was specified in the <code>-c</code> option above.

== Build a toolchain and root filesystem using buildroot ==

'''Note:''' for more details on generic buildroot topics not covered in this simple how-to,
see [http://buildroot.uclibc.org/ buildroot.uclibc.org].

=== Configure buildroot ===

The first time you configure buildroot, start with defaults for your Xtensa processor:

'''$ cd <workdir>/buildroot'''
'''$ ./target/xtensa/setup-config <corename>'''

where ''<corename>'' is the overlay name of your selected Xtensa or Diamond core
(e.g., '''dc233c'''). If you omit ''<corename>'', a help message and a list
of currently installed Tensilica core overlays is displayed.

Optionally, you can then customize your buildroot configuration, such as
selecting additional packages, setting various parameters, and so on.
The following make targets provide a ''curses'' (text-based graphical) interface
for configuring buildroot, the uClibc C library, and busybox, respectively.
('''Note:''' You need the <tt>TERM</tt> environment variable properly set for
these curses based tools to work.)

'''$ make menuconfig'''
'''$ make uclibc-menuconfig'''
'''$ make busybox-menuconfig'''

=== Build buildroot ===

Just type:

'''$ make'''

THIS WILL TAKE A LONG TIME (from about 30 minutes with defaults on a 3 GHz Pentium 4,
to perhaps an hour or many depending on your system and on whether
you enabled extra packages in your buildroot configuration).

Wait patiently for the build to complete. This builds an entire toolchain
as well as some basic packages, and constructs a root filesystem.
It might build many more packages if you selected them earlier with menuconfig.

==== If Something Goes Wrong ====

Perhaps you missed some step above and the build fails. Or you're just switching to a different processor configuration, or making some change with unknown dependencies. Either way, you'll probably need to fix the error and/or make the change, and redo the whole build. The above <tt>make</tt> command usually works fine if you
just added a package using menuconfig, but otherwise does not check many dependencies, so it will usually NOT rebuild things that depend on whatever you have fixed or changed. Here's one way to retry the make from scratch without having to wipe out the <tt>buildroot</tt> directory tree completely and start again from the git cloning.

$ '''rm -rf *build_xtensa* binaries'''
$ '''make'''

It is not necessary to empty the 'dl' subdirectory, which contains tarballs downloaded from the Internet, nor the .config file, which contains the buildroot configuration. Customizations to the uClibc and <tt>busybox</tt> configurations should have ended up getting saved in target/xtensa/uClibc.config and target/xtensa/busybox-config, respectively, so hopefully are preserved by the above sequence.

== Build and Run a Linux Kernel on the XTAV60, AXAV110, or XTAV200 Boards ==

References to the ''XTAV60 board'' refer to the combination of
the Avnet [http://www.em.avnet.com/tensilica1 LX60 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX60 (XT-AV60) Board User's Guide''.

Similarly, references to the ''XTAV200 board'' refers the combination of
the Avnet [http://www.em.avnet.com/tensilica2 LX200 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX200 (XT-AV200) Board User's Guide''.

=== Configure the kernel ===

The kernel build is a two-step process: configure the kernel, and build it.
First, before we can do anything with the kernel, set your PATH to
point to the toolchain built using buildroot.

$ '''export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"'''

where ''<cname>'' is the name of the Xtensa processor configuration you selected
when building the toolchain (e.g., <code>dc232b</code>).

Now setup a destination for kernel builds.
We usually like to have the build directory separate from
the source directory, so we use 'O=</destination/path>' in
kernel make commands. If you'll be routinely building multiple
configurations of the Linux kernel, it's good to have some
naming conventions for the build directory. For example,
to experiment with multiple target platforms but only one
processor configuration, we include just the platform name here:

$'''mkdir build-xtav60'''

Let's start with the default kernel configuration for the Avnet board
(which works on both XTAV60 (LX60), XTAV110 (LX110), and XTAV200 (LX200) boards)
as follows:

$ '''cd linux'''
$ '''make O=../build-xtav60 ARCH=xtensa KBUILD_DEFCONFIG=lx60_defconfig defconfig'''

This configures the kernel using the default configuration found in
'''arch/xtensa/configs/lx60_defconfig'''.

'''NOTE:''' This kernel configuration has nothing to do with Xtensa
processor configuration. That comes next.

Let's now customize this a little bit to select the correct Xtensa processor
configuration, and to bundle the root filesystem into the kernel:

$ '''make O=../build-xtav60 ARCH=xtensa menuconfig'''

Under '''General setup''',
make sure the '''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is enabled. Underneath that, edit '''Initramfs source file(s)''',
and enter the path to the cpio formatted root filesystem
generated by buildroot:

''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio.gz

(Don't forget to replace ''<workdir>'' with the appropriate full path
and ''<cname>'' with your Xtensa processor configuration name.)

Under '''Processor type and features''',
make sure the '''Xtensa Processor Configuration''' is correct and matches
the processor configuration name you used to build the toolchain with buildroot
(for example, ''dc232b'' for Diamond 232L Rev.B).
The kernel build selects a toolchain and processor variant specific headers
based on this selection.
If the desired processor configuration does not appear explicitly in the list,
simply select '''Custom Xtensa processor configuration''' and enter the
processor configuration name (all lowercase) into the next menu parameter,
'''Xtensa Processor Custom Variant Name'''.

Back in the main menu, under '''Platform options''', make sure the
'''CPU clock rate''' entry is set correctly according to the following table:

{| border="1" style="text-align:center; margin: 1em auto 1em auto"
|-
! Board !! Frequency selected in XPG (MHz) !! ''CPU clock rate'' setting (kHz)
|-
|rowspan="3"| XTAV60 (LX60)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV110 (LX110)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV200 (LX200)
| 30 || 31250
|-
| 40 || 41667
|-
| 50 || 50000
|-
|}

Exit menuconfig, saving your configuration changes.

Backup your configuration outside the build directory. For example:

$ '''cp ../build-xtav60/.config config.xtav60.saved'''

If you do a clean rebuild of the kernel (e.g., "rm -rf ../build-xtav60")
you can now configure it with simply:
$ '''mkdir ../build-xtav60 ; cp config.xtav60.saved ../build-xtav60/.config'''
Of course if you update the kernel, you'll probably again have to do:
$ '''make O=../build-xtav60 ARCH=xtensa menuconfig'''
and save a new copy of your configuration.

=== Build the kernel ===

$ '''make O=../build-xtav60 ARCH=xtensa'''

The build will issue a few warnings which are normal.
Once complete, the bootable image is in:
<workdir>/build-xtav60/arch/xtensa/boot/Image.elf
and the uncompressed ELF file containing kernel symbols is in:
<workdir>/build-xtav60/vmlinux
There is also a RedBoot bootable image (if you use RedBoot) in:
<workdir>/build-xtav60/arch/xtensa/boot/zImage.redboot

=== Install Xtensa Tools for the selected core ===

If you opt to download the kernel over OCD, you need <tt>xt-gdb</tt>
which is part of Tensilica's Xtensa Tools package. This must be obtained
from Tensilica, and is not the same toolchain as built by buildroot.
You also need to install the corresponding Tensilica core package,
so that the Xtensa Tools know about your particular configured
Tensilica core.

The toolchain built using buildroot can be configured to
include GDB, but that version of GDB does not support
communicating with Tensilica's Xtensa OCD Daemon, and
thus cannot be used to download the kernel over OCD.

In this example, it is assumed that the machine hosting the
Xtensa Tools has access to the <workdir> directory tree.

=== Install and setup the Xtensa OCD Daemon ===

Setup and connect your JTAG probe, etc.

=== Connect a terminal server ===

At 38400 bps 8N1 no flow control to the XTAV60 serial port.

=== Optionally, setup networking ===

This step is optional.

Setup the board's MAC address using dipswitches
(see XTAV60 or XTAV200 board docs as appropriate)
and connect the board to a network that has a
DHCP server that will respond to that MAC address.
If you don't do this step, you'll simply not have network
access, and the boot process will take a minute or so longer
while the kernel times out waiting for a BOOTP response.
You can edit the kernel configuration and rebuild the kernel
to avoid using bootp (in particular, remove "ip=bootp" from
the kernel cmdline).

=== Download and run the kernel ===

Reset the board (see board documentation).

Using Xtensa Tools, invoke:

$ '''xt-gdb <workdir>/build-xtav60/arch/xtensa/boot/Image.elf'''

'''(xt-gdb) target remote <ocdhost>:20000 0'''
'''(xt-gdb) reset'''
'''(xt-gdb) load'''
'''(xt-gdb) set $pc = &_ResetVector'''
'''(xt-gdb) symbol-file <workdir>/build-xtav60/vmlinux'''
'''(xt-gdb) c'''

where <ocdhost> is the IP address or DNS name of the machine
running the Xtensa OCD daemon. The Linux kernel should
start booting as soon as 'c' (continue) is executed.

You should eventually get a login prompt.
Just login as root (no password).

Try various Linux commands. Look at <tt>/bin</tt>,
<tt>/sbin</tt>, <tt>/usr/bin</tt>, etc to see what's available.

'''Note:''' no need to setup an NFS or TFTP server. The filesystem
is contained within the kernel image. You may be able to mount
other filesystems over NFS though, if you wish, after booting.

Recently the MMU was modified to come up uninitialized and it's
necessary for the Linux kernel to map the MMU prior to running.
This means you can't place breakpoints in the kernel until the
mapping has been completed. It's likely worth while looking
at the example .xt-gdbinit file in the Kernel Xtensa Documentation:

xtensa-2.6.29-smp-xcc-O3/Documentation/xtensa/gdbmacros/xt-gdbinit

When running on Avnet boards it's necessary to use a HardWare Breakpoint
at the kernel symbol '''set_breakpoints''' which is near ''' _startup'''
and set your early kernel breakpoints once you get to this hardware breakpoint.

With ISS simulation normal breakpoints must be used.

Below is an example snippet from the sample '''xt-gdbinit''' script:

if $debug_hw_breakpoints_supported
hbreak set_breakpoints
else
break set_breakpoints
end

set var $_startup = $bpnum
commands $_startup
set_breakpoints
delete $_startup
info breakpoints
set var $doing_commands = 0
end

=== Mounting the Root Filesystem Over NFS ===

If you build more than the minimal set of packages using
buildroot, the root filesystem can easily grow too large to
fit comfortably (or at all) inside the kernel. In this case,
rather than follow the instructions exactly as above,
you'll want to mount the root filesystem over NFS.

You may also want to mount the root filesystem over NFS to
make changes to the filesystem persistent across runs and
accessible from your development host.

First you need to install the root filesystem generated
using buildroot, to a machine that can serve it over NFS.
Assuming this machine runs Linux, one way to install it is
as follows:

$ '''mkdir ''<exportpath>'' '''
$ '''cd ''<exportpath>'' '''
$ '''sudo cpio -i -d -m -F ''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio --no-absolute-filenames '''

You then need to enable the NFS server on your system
(if not already active), and export this filesystem.
How you do this depends on your host Linux distribution.
For example, on some Fedora releases, one might:

* add the export path to <tt>/etc/exports</tt> using a line such as

''<exportpath>'' *(rw,sync,no_root_squash,no_all_squash,no_wdelay)

* turn on the NFS server if needed:

$ '''sudo /sbin/chkconfig nfs on'''

* tell the NFS server about the new exported filesystem

$ '''sudo /usr/sbin/exportfs -a'''
$ '''sudo /usr/sbin/exportfs -r'''

Second, follow the instructions in the previous sections,
then configure the kernel again as follows.

Under '''General setup''', make sure the
'''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is disabled (rather than enabled as done in previous sections).

Under '''Platform options''', under the line '''Default bootloader kernel arguments''',
select the boot parameters line and set it to something like this:

'''console=ttyS0,38400 ip=dhcp root=/dev/nfs rw nfsroot=''<server_ip>'':''<exportpath>'' '''

where ''<server_ip>'' is the IP address of your NFS server, and ''<exportpath>''
is the exported filesystem path.

Another approach is to just specify the ip addresses directly in the CMDLINE
'''CONFIG_CMDLINE="console=ttyS0,38400 ip=192.168.11.95:192.168.11.220:192.168.11.1:255.255.255.0:HiFi-2 root=/dev/nfs rw nfsroot=192.168.11.55:/exports/LINUX_ROOT.DC_C_233L debug coredump_filter=0xff" '''

Where the IP addresses are in the form:

'''${ipaddr}:${nfsroot_server}:${gatewayip}:${netmask}:${hostname}'''

Save this configuration, rebuild the kernel, and follow the
instructions in previous sections to download and run the kernel.
If everything goes well and is setup correctly, your kernel should
now boot with a root filesystem mounted over NFS.

== Build and Run a Linux Kernel on the Instruction Set Simulator (ISS) ==

You can build and run a Linux kernel in the Xtensa Instruction Set
Simulator (ISS). The following instructions have only been tried
with an ISS from the RB-2008.3 release of Xtensa Tools. Bear in
mind that the XTAV60 port is likely much more stable than the ISS port
of Linux at this point in time.

Note: Depending on your host OS version, you may need to install
Xtensa Tools on a separate machine.

=== Configure and Build the Kernel for ISS ===

Repeat all the same instructions as above for building the kernel for an
Avnet board, except that when initially configuring the kernel,
start from a ISS platform template instead. For example for the
DC233C Variant:

'''$ mkdir build-iss'''
'''$ cd linux'''
'''$ make O=../build-iss ARCH=xtensa KBUILD_DEFCONFIG=iss_dc233c_defconfig defconfig'''

The above make example configures the kernel using the default configuration found in
'''arch/xtensa/configs/iss_dc233_defconfig'''. Most important to note is that the
root file system mounted when Linux boots comes via the targets device '''/dev/simdisk0'''
which is defined in the kernel '''.config''' file. For example:

'''CONFIG_SIMDISK0_FILENAME="/export2/DC_C_233L/LINUX_ROOT.ext2"'''

The SIMDISK file name and VARIANT name are typically configured when running '''make menuconfig'''; Ex:

'''$ make O=../build-iss ARCH=xtensa menuconfig'''

and selecting

'''Xtensa Platform options''' ---> '''Host filename for a simulated device'''

and entering the pathname to the .ext2 file there. Ex: '''/export2/DC_C_233L/LINUX_ROOT.ext2'''

You often want to change the VARIANT to the one you desire, Ex: FSF. You do this via
the top level menu:

'''Xtensa Processor type and features ---> Xtensa Processor Custom Core Variant Name'''

With the new SIMDISK approach you copy the EXT2 Filesystem file generated by Buildroot
to a location to be accessed by Xtensa Linux. Ex:

'''$ cp /export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot/binaries/dc233c/rootfs.xtensa_dc233c.ext2 /export2/DC_C_233L/LINUX_ROOT.ext2'''

'''NOTE:''' There is an old '''iss_defconfig''' that tries to use a '''tuntap''' Ethernet
interface that currently isn't supported.
Previously with this old iss_defconfig using the '''tuntap''' Ethernet interface
it was suggested to set up the initramfs filesystem, and do the following.
Under '''Bus Options''', deselect '''PCI support'''.
Under '''Platform Options''', deselect '''Default bootloader kernel arguments'''.
Hopefully we will someday be able to support the use of a network interface with
ISS simulation and then be able to mount NFS root partitions again. So I'm leaving
this note for future exploration of this mechanism; Hope you don't mind the clutter.

Continue configuring and building the kernel as usual.

=== Run the Kernel on ISS ===

Using Xtensa Tools, invoke:

'''$ xt-gdb <workdir>/build-iss/arch/xtensa/boot/Image.elf'''
'''(xt-gdb) target sim --turbo --memlimit=128'''
'''(xt-gdb) symbol-file <workdir>/build-iss/vmlinux'''
'''(xt-gdb) run'''

Wait patiently while Linux boots ... (maybe a minute). The setting of the '''memlimit'''
needs to match the PLATFORM_DEFAULT_MEM_SIZE defined in /arch/xtensa/platforms/iss/include/platform/hardware.h.
Currently this limit us 128 MegaBytes:

#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000 /* 13,4217,728 128M */

and we will be extending this for the DC233L to take advantage of it's V3 MMU.

Login as root (no password).

'''Note:''' Input via ISS is cooked, so everything typed gets echoed.
Also, time as reported by the kernel does not progress
according to true wall-clock time: it currently depends on
a simulated processor clock, which advances at various speeds
according to load.

Transwitch A2000 Development Board

2011-03-12T02:05:05Z

Piet: /* Configuring U-Boot to Boot Linux [Needs to be Updated for A2000 [Suresh?] */

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.

<div style="margin:0; margin-top:10px; margin-right:10px; border:1px solid #dfdfdf; padding:0 1em 1em 1em; background-color:#ffffcc; align:right; ">
'''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]
</div>

== 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 [http://www.kernel.org/pub/software/scm/git/ official site].
For example, <tt>cd</tt> 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 <tt>/usr/local/bin</tt> 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), <tt>cd</tt> 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 [http://www.kernel.org/pub/software/scm/git/docs/git-pull.html git-pull].

You can examine the tree (git repository) and its history visually using <tt>git gui</tt>.
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 [[HiFi-2 snapshot_2 SMP Snapshot menuconfig | menuconfig]]'''
$ '''make [[HiFi-2 snapshot_2 SMP uclibc-menuconfig | 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 [[HiFi-2 snapshot_2 SMP busybox-menuconfig | 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), <tt>cd</tt> 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 [http://en.wikipedia.org/wiki/Minicom minicom]
for this, see [[minicom_xtboard_setup|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 [[HiFi2_Board_Example_Linux_Boot_Log|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 <tt>xtensa_${CORENAME}-linux-</tt> :

$ '''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 <tt>gcc</tt>.

=== 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 <tt>open()</tt>'s <tt>O_EXCL</tt>
and <tt>stat()</tt>'s <tt>struct stat</tt>, 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|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.
* [[Buildroot_Build_Instructions|Instructions for building and booting Linux (buildroot)]].

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 [[HiFi-2 snapshot_2 SMP Snapshot menuconfig | menuconfig]]'''
$ '''make [[HiFi-2 snapshot_2 SMP uclibc-menuconfig | uclibc-menuconfig]]'''
$ '''make [[HiFi-2 snapshot_2 SMP busybox-menuconfig | 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:

* [http://www.transwitch.com/products/product/page.jsp?product=190 Transwitch A2000]
* [http://www.transwitch.com/support/index.jsp Transwitch Support]
* [http://linux-xtensa.org/ Linux/Xtensa Wiki]
* [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions Buildroot Build Instructions]
* [http://wiki.linux-xtensa.org/index.php/Kernel_Build_Instructions Kernel Build Instructions]
* [http://wiki.linux-xtensa.org/index.php/Setting_up_U-Boot Setting up U-Boot]
* [http://lists.linux-xtensa.org/mailman/listinfo Linux/Xtensa Mailing List]
* http://git.linux-xtensa.org/cgi-bin/git.cgi GIT Repositories]

=Maintained by=

* piet
* marc ?
* suresh ?

Instructions for building and booting Linux

2011-01-06T06:07:44Z

Piet: /* Download and run the kernel */

These instructions explain how to build a toolchain, root filesystem and kernel for Linux running on an Xtensa processor. These instructions apply specifically to the XTAV60 (LX60) board.

Some general notes on these instructions:

* They are a work in progress. If you are using the latest development sources, the build process may change, so you should be sure to get the latest version of this document at [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions]. If you are using one of the development snapshot releases, you should use the version of the build instructions included with that snapshot.

* The following was tested on x86 machines running RedHat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3). It is expected to work on newer Fedora releases (e.g., was tested on FC6) but to maintain host compatibility with Xtensa Tools, it is best to avoid Fedora releases beyond FC5. Other host distributions likely work but have not been tested.
** '''NOTE:''' this assumes the default selection of packages in buildroot. Selecting extra packages may require a more recent host OS or more recent version of certain tools. For example, the default version of <tt>find</tt> on RHEL4 is too old to allow building all X11 packages in buildroot, so it is necessary to upgrade the host version of <tt>findutils</tt> on RHEL4 to build these packages.

* Lines prefixed with "sudo" need to be executed as root. The rest is best executed as a non-root user. (It is possible to install <tt>git</tt> as a non-root user if root access is an issue. How to do this isn't shown here.)

* Lines that set environment variables assume a Bourne compatible shell (e.g., /bin/sh or bash), but are easily adapted to other shells.

* Instructions are assumed executed all in order (e.g., commands assume current directory and environment variables set earlier).

== Setup your host system ==

If you are using one of the snapshot releases, you can skip this step.

If you want to work with the latest development sources, you will need
[[Installing GIT|<tt>git</tt> installed on your system]].

== Download buildroot and the Linux kernel ==

The following section describes how to download the latest
versions of buildroot and of the Linux kernel.
Skip this step if you are using one of the
[http://wiki.linux-xtensa.org/index.php/Buildroot_Snapshots snapshot releases].

Adventurous users that want to use the '''bleeding edge''' code can execute the following:

'''$ cd <workdir>'''
'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa.git buildroot'''
'''$ git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git linux'''

where <tt><workdir></tt> is the path to an empty directory on a disk with
at least 4 GB available space. You end up with the following file structure,
which is assumed by the rest of this document:

<workdir>/
/buildroot
/linux

The MASTER branch of the buildroot repository is often is a state of development.
It's recommended to use the last snapshot for application developers. In the
case of the Avnet development boards a 'snapshot_2+SMP' branch is recommended
in the currently experimental SMP git repository:

'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

If you happen to have write access to either repository you should change '''git:''' to '''git+ssh:'''
For Example:

'''$ git clone git+ssh://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

For more details, see the [http://wiki.linux-xtensa.org/index.php/Repository_Access repository access] page.

== Install any required processor specific overlay ==

This step is required if you are targeting a custom Xtensa processor.
If you use a Diamond 232L Standard Core, you can skip this step.

To configure buildroot and the kernel to use a custom Xtensa processor
configuration, you need to overlay a set of files customized for your
processor configuration onto toolchain sources (gcc, binutils, gdb, etc)
and the Linux kernel. This process has been automated using a script
located in the buildroot source tree.
For usage information, you can invoke it without arguments:

'''$ cd <workdir>'''
'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install'''

which displays a help message similar to the following:

xt-buildroot-overlay-install version 1.3
Usage: xt-buildroot-overlay-install <parameters> [<options>]
Where <parameters> are:
-t file.tgz Specify path to the Xtensa Linux overlay tarball, typically
<xtensa_root>/src/xtensa-config-overlay.tar.gz
-b dir Path to the base of the buildroot source tree, in which
package specific overlay tarballs get installed.
-k dir Path to the base of the Linux kernel source tree, in which
the Linux kernel specific overlay gets installed.
-c config_name Name for the Xtensa processor configuration as it will be
known to the open source community. Must be a lowercase
identifier, starting with a letter, consisting of letters
and numbers and underscores, not ending with underscore
and not containing consecutive underscores. For examples:
dc232b , dc232b_be , mmubasele , fsf , s5000 .
-l long_name Long name for the Xtensa processor configuration, human-
readable with spaces etc allowed (must be quoted).
For example: 'Diamond 232L Standard Core Rev.B (LE)'
Try to keep it within approximately 40 characters.
And <options> are:
-f If package specific overlay tarballs already exist in
the destination source tree, overwrite them without asking.
--help Show this usage message.

Note that the Xtensa Linux overlay tarball MUST be obtained from an Xtensa
core package built using release RB-2008.3 or later.

Here is an example invocation of the overlay installation script:

'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install -t blinkcore-config-overlay.tar.gz''' \
'''-b ./buildroot -k ./linux -c superzip -l "ChipCorp SuperZIP Blink Accelerator Core"'''

The script extracts some relevant information from the overlay tarball,
presents it along with relevant parameters to the user, and prompts
for confirmation before proceeding.

The chosen processor name (-c option) must be unique among known Xtensa processors.
It is also probably wise to avoid names confusingly similar to other (non-Xtensa) processors.
If you expect at some point to contribute support for your custom processor to the
open-source community, this name will likely be long-lived.
(One way to contribute support for a custom processor might be to submit the overlay tarball
or files to the linux-xtensa.org maintainers.)

In the steps below, buildroot and the Linux kernel must be configured
(in their respective <code>''make menuconfig''</code> steps) to select
the <code>''custom''</code> Xtensa processor option.
This presents an extra configuration menu entry where you must provide
the name of the Xtensa processor. Set it to the same name
as was specified in the <code>-c</code> option above.

== Build a toolchain and root filesystem using buildroot ==

'''Note:''' for more details on generic buildroot topics not covered in this simple how-to,
see [http://buildroot.uclibc.org/ buildroot.uclibc.org].

=== Configure buildroot ===

The first time you configure buildroot, start with defaults for your Xtensa processor:

'''$ cd <workdir>/buildroot'''
'''$ ./target/xtensa/setup-config <corename>'''

where ''<corename>'' is the overlay name of your selected Xtensa or Diamond core
(e.g., '''dc233c'''). If you omit ''<corename>'', a help message and a list
of currently installed Tensilica core overlays is displayed.

Optionally, you can then customize your buildroot configuration, such as
selecting additional packages, setting various parameters, and so on.
The following make targets provide a ''curses'' (text-based graphical) interface
for configuring buildroot, the uClibc C library, and busybox, respectively.
('''Note:''' You need the <tt>TERM</tt> environment variable properly set for
these curses based tools to work.)

'''$ make menuconfig'''
'''$ make uclibc-menuconfig'''
'''$ make busybox-menuconfig'''

=== Build buildroot ===

Just type:

'''$ make'''

THIS WILL TAKE A LONG TIME (from about 30 minutes with defaults on a 3 GHz Pentium 4,
to perhaps an hour or many depending on your system and on whether
you enabled extra packages in your buildroot configuration).

Wait patiently for the build to complete. This builds an entire toolchain
as well as some basic packages, and constructs a root filesystem.
It might build many more packages if you selected them earlier with menuconfig.

==== If Something Goes Wrong ====

Perhaps you missed some step above and the build fails. Or you're just switching to a different processor configuration, or making some change with unknown dependencies. Either way, you'll probably need to fix the error and/or make the change, and redo the whole build. The above <tt>make</tt> command usually works fine if you
just added a package using menuconfig, but otherwise does not check many dependencies, so it will usually NOT rebuild things that depend on whatever you have fixed or changed. Here's one way to retry the make from scratch without having to wipe out the <tt>buildroot</tt> directory tree completely and start again from the git cloning.

$ '''rm -rf *build_xtensa* binaries'''
$ '''make'''

It is not necessary to empty the 'dl' subdirectory, which contains tarballs downloaded from the Internet, nor the .config file, which contains the buildroot configuration. Customizations to the uClibc and <tt>busybox</tt> configurations should have ended up getting saved in target/xtensa/uClibc.config and target/xtensa/busybox-config, respectively, so hopefully are preserved by the above sequence.

== Build and Run a Linux Kernel on the XTAV60, AXAV110, or XTAV200 Boards ==

References to the ''XTAV60 board'' refer to the combination of
the Avnet [http://www.em.avnet.com/tensilica1 LX60 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX60 (XT-AV60) Board User's Guide''.

Similarly, references to the ''XTAV200 board'' refers the combination of
the Avnet [http://www.em.avnet.com/tensilica2 LX200 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX200 (XT-AV200) Board User's Guide''.

=== Configure the kernel ===

The kernel build is a two-step process: configure the kernel, and build it.
First, before we can do anything with the kernel, set your PATH to
point to the toolchain built using buildroot.

$ '''export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"'''

where ''<cname>'' is the name of the Xtensa processor configuration you selected
when building the toolchain (e.g., <code>dc232b</code>).

Now setup a destination for kernel builds.
We usually like to have the build directory separate from
the source directory, so we use 'O=</destination/path>' in
kernel make commands. If you'll be routinely building multiple
configurations of the Linux kernel, it's good to have some
naming conventions for the build directory. For example,
to experiment with multiple target platforms but only one
processor configuration, we include just the platform name here:

$'''mkdir build-xtav60'''

Let's start with the default kernel configuration for the Avnet board
(which works on both XTAV60 (LX60), XTAV110 (LX110), and XTAV200 (LX200) boards)
as follows:

$ '''cd linux'''
$ '''make O=../build-xtav60 ARCH=xtensa KBUILD_DEFCONFIG=lx60_defconfig defconfig'''

This configures the kernel using the default configuration found in
'''arch/xtensa/configs/lx60_defconfig'''.

'''NOTE:''' This kernel configuration has nothing to do with Xtensa
processor configuration. That comes next.

Let's now customize this a little bit to select the correct Xtensa processor
configuration, and to bundle the root filesystem into the kernel:

$ '''make O=../build-xtav60 ARCH=xtensa menuconfig'''

Under '''General setup''',
make sure the '''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is enabled. Underneath that, edit '''Initramfs source file(s)''',
and enter the path to the cpio formatted root filesystem
generated by buildroot:

''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio.gz

(Don't forget to replace ''<workdir>'' with the appropriate full path
and ''<cname>'' with your Xtensa processor configuration name.)

Under '''Processor type and features''',
make sure the '''Xtensa Processor Configuration''' is correct and matches
the processor configuration name you used to build the toolchain with buildroot
(for example, ''dc232b'' for Diamond 232L Rev.B).
The kernel build selects a toolchain and processor variant specific headers
based on this selection.
If the desired processor configuration does not appear explicitly in the list,
simply select '''Custom Xtensa processor configuration''' and enter the
processor configuration name (all lowercase) into the next menu parameter,
'''Xtensa Processor Custom Variant Name'''.

Back in the main menu, under '''Platform options''', make sure the
'''CPU clock rate''' entry is set correctly according to the following table:

{| border="1" style="text-align:center; margin: 1em auto 1em auto"
|-
! Board !! Frequency selected in XPG (MHz) !! ''CPU clock rate'' setting (kHz)
|-
|rowspan="3"| XTAV60 (LX60)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV110 (LX110)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV200 (LX200)
| 30 || 31250
|-
| 40 || 41667
|-
| 50 || 50000
|-
|}

Exit menuconfig, saving your configuration changes.

Backup your configuration outside the build directory. For example:

$ '''cp ../build-xtav60/.config config.xtav60.saved'''

If you do a clean rebuild of the kernel (e.g., "rm -rf ../build-xtav60")
you can now configure it with simply:
$ '''mkdir ../build-xtav60 ; cp config.xtav60.saved ../build-xtav60/.config'''
Of course if you update the kernel, you'll probably again have to do:
$ '''make O=../build-xtav60 ARCH=xtensa menuconfig'''
and save a new copy of your configuration.

=== Build the kernel ===

$ '''make O=../build-xtav60 ARCH=xtensa'''

The build will issue a few warnings which are normal.
Once complete, the bootable image is in:
<workdir>/build-xtav60/arch/xtensa/boot/Image.elf
and the uncompressed ELF file containing kernel symbols is in:
<workdir>/build-xtav60/vmlinux
There is also a RedBoot bootable image (if you use RedBoot) in:
<workdir>/build-xtav60/arch/xtensa/boot/zImage.redboot

=== Install Xtensa Tools for the selected core ===

If you opt to download the kernel over OCD, you need <tt>xt-gdb</tt>
which is part of Tensilica's Xtensa Tools package. This must be obtained
from Tensilica, and is not the same toolchain as built by buildroot.
You also need to install the corresponding Tensilica core package,
so that the Xtensa Tools know about your particular configured
Tensilica core.

The toolchain built using buildroot can be configured to
include GDB, but that version of GDB does not support
communicating with Tensilica's Xtensa OCD Daemon, and
thus cannot be used to download the kernel over OCD.

In this example, it is assumed that the machine hosting the
Xtensa Tools has access to the <workdir> directory tree.

=== Install and setup the Xtensa OCD Daemon ===

Setup and connect your JTAG probe, etc.

=== Connect a terminal server ===

At 38400 bps 8N1 no flow control to the XTAV60 serial port.

=== Optionally, setup networking ===

This step is optional.

Setup the board's MAC address using dipswitches
(see XTAV60 or XTAV200 board docs as appropriate)
and connect the board to a network that has a
DHCP server that will respond to that MAC address.
If you don't do this step, you'll simply not have network
access, and the boot process will take a minute or so longer
while the kernel times out waiting for a BOOTP response.
You can edit the kernel configuration and rebuild the kernel
to avoid using bootp (in particular, remove "ip=bootp" from
the kernel cmdline).

=== Download and run the kernel ===

Reset the board (see board documentation).

Using Xtensa Tools, invoke:

$ '''xt-gdb <workdir>/build-xtav60/arch/xtensa/boot/Image.elf'''

'''(xt-gdb) target remote <ocdhost>:20000 0'''
'''(xt-gdb) reset'''
'''(xt-gdb) load'''
'''(xt-gdb) set $pc = &_ResetVector'''
'''(xt-gdb) symbol-file <workdir>/build-xtav60/vmlinux'''
'''(xt-gdb) c'''

where <ocdhost> is the IP address or DNS name of the machine
running the Xtensa OCD daemon. The Linux kernel should
start booting as soon as 'c' (continue) is executed.

You should eventually get a login prompt.
Just login as root (no password).

Try various Linux commands. Look at <tt>/bin</tt>,
<tt>/sbin</tt>, <tt>/usr/bin</tt>, etc to see what's available.

'''Note:''' no need to setup an NFS or TFTP server. The filesystem
is contained within the kernel image. You may be able to mount
other filesystems over NFS though, if you wish, after booting.

Recently the MMU was modified to come up uninitialized and it's
necessary for the Linux kernel to map the MMU prior to running.
This means you can't place breakpoints in the kernel until the
mapping has been completed. It's likely worth while looking
at the example .xt-gdbinit file in the Kernel Xtensa Documentation:

xtensa-2.6.29-smp-xcc-O3/Documentation/xtensa/gdbmacros/xt-gdbinit

When running on Avnet boards it's necessary to use a HardWare Breakpoint
at the kernel symbol '''set_breakpoints''' which is near ''' _startup'''
and set your early kernel breakpoints once you get to this hardware breakpoint.

With ISS simulation normal breakpoints must be used.

Below is an example snippet from the sample '''xt-gdbinit''' script:

if $debug_hw_breakpoints_supported
hbreak set_breakpoints
else
break set_breakpoints
end

set var $_startup = $bpnum
commands $_startup
set_breakpoints
delete $_startup
info breakpoints
set var $doing_commands = 0
end

=== Mounting the Root Filesystem Over NFS ===

If you build more than the minimal set of packages using
buildroot, the root filesystem can easily grow too large to
fit comfortably (or at all) inside the kernel. In this case,
rather than follow the instructions exactly as above,
you'll want to mount the root filesystem over NFS.

You may also want to mount the root filesystem over NFS to
make changes to the filesystem persistent across runs and
accessible from your development host.

First you need to install the root filesystem generated
using buildroot, to a machine that can serve it over NFS.
Assuming this machine runs Linux, one way to install it is
as follows:

$ '''mkdir ''<exportpath>'' '''
$ '''cd ''<exportpath>'' '''
$ '''sudo cpio -i -d -m -F ''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio --no-absolute-filenames '''

You then need to enable the NFS server on your system
(if not already active), and export this filesystem.
How you do this depends on your host Linux distribution.
For example, on some Fedora releases, one might:

* add the export path to <tt>/etc/exports</tt> using a line such as

''<exportpath>'' *(rw,sync,no_root_squash,no_all_squash,no_wdelay)

* turn on the NFS server if needed:

$ '''sudo /sbin/chkconfig nfs on'''

* tell the NFS server about the new exported filesystem

$ '''sudo /usr/sbin/exportfs -a'''
$ '''sudo /usr/sbin/exportfs -r'''

Second, follow the instructions in the previous sections,
then configure the kernel again as follows.

Under '''General setup''', make sure the
'''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is disabled (rather than enabled as done in previous sections).

Under '''Platform options''', under the line '''Default bootloader kernel arguments''',
select the boot parameters line and set it to something like this:

'''console=ttyS0,38400 ip=dhcp root=/dev/nfs rw nfsroot=''<server_ip>'':''<exportpath>'' '''

where ''<server_ip>'' is the IP address of your NFS server, and ''<exportpath>''
is the exported filesystem path.

Another approach is to just specify the ip addresses directly in the CMDLINE
'''CONFIG_CMDLINE="console=ttyS0,38400 ip=192.168.11.95:192.168.11.220:192.168.11.1:255.255.255.0:HiFi-2 root=/dev/nfs rw nfsroot=192.168.11.55:/exports/LINUX_ROOT.DC_C_233L debug coredump_filter=0xff" '''

Where the IP addresses are in the form:

'''${ipaddr}:${nfsroot_server}:${gatewayip}:${netmask}:${hostname}'''

Save this configuration, rebuild the kernel, and follow the
instructions in previous sections to download and run the kernel.
If everything goes well and is setup correctly, your kernel should
now boot with a root filesystem mounted over NFS.

== Build and Run a Linux Kernel on the Instruction Set Simulator (ISS) ==

You can build and run a Linux kernel in the Xtensa Instruction Set
Simulator (ISS). The following instructions have only been tried
with an ISS from the RB-2008.3 release of Xtensa Tools. Bear in
mind that the XTAV60 port is likely much more stable than the ISS port
of Linux at this point in time.

Note: Depending on your host OS version, you may need to install
Xtensa Tools on a separate machine.

=== Configure and Build the Kernel for ISS ===

Repeat all the same instructions as above for building the kernel for an
Avnet board, except that when initially configuring the kernel,
start from a ISS platform template instead. For example for the
DC233C Variant:

'''$ mkdir build-iss'''
'''$ cd linux'''
'''$ make O=../build-iss ARCH=xtensa KBUILD_DEFCONFIG=iss_dc233c_defconfig defconfig'''

The above make example configures the kernel using the default configuration found in
'''arch/xtensa/configs/iss_dc233_defconfig'''. Most important to note is that the
root file system mounted when Linux boots comes via the targets device '''/dev/simdisk0'''
which is defined in the kernel '''.config''' file. For example:

'''CONFIG_SIMDISK0_FILENAME="/export2/DC_C_233L/LINUX_ROOT.ext2"'''

The SIMDISK file name and VARIANT name are typically configured when running '''make menuconfig'''; Ex:

'''$ make O=../build-iss ARCH=xtensa menuconfig'''

and selecting

'''Xtensa Platform options''' ---> '''Host filename for a simulated device'''

and entering the pathname to the .ext2 file there. Ex: '''/export2/DC_C_233L/LINUX_ROOT.ext2'''

You often want to change the VARIANT to the one you desire, Ex: FSF. You do this via
the top level menu:

'''Xtensa Processor type and features ---> Xtensa Processor Custom Core Variant Name'''

With the new SIMDISK approach you copy the EXT2 Filesystem file generated by Buildroot
to a location to be accessed by Xtensa Linux. Ex:

'''$ cp /export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot/binaries/dc233c/rootfs.xtensa_dc233c.ext2 /export2/DC_C_233L/LINUX_ROOT.ext2'''

'''NOTE:''' There is an old '''iss_defconfig''' that tries to use a '''tuntap''' Ethernet
interface that currently isn't supported.
Previously with this old iss_defconfig using the '''tuntap''' Ethernet interface
it was suggested to set up the initramfs filesystem, and do the following.
Under '''Bus Options''', deselect '''PCI support'''.
Under '''Platform Options''', deselect '''Default bootloader kernel arguments'''.
Hopefully we will someday be able to support the use of a network interface with
ISS simulation and then be able to mount NFS root partitions again. So I'm leaving
this note for future exploration of this mechanism; Hope you don't mind the clutter.

Continue configuring and building the kernel as usual.

=== Run the Kernel on ISS ===

Using Xtensa Tools, invoke:

'''$ xt-gdb <workdir>/build-iss/arch/xtensa/boot/Image.elf'''
'''(xt-gdb) target sim --turbo --memlimit=128'''
'''(xt-gdb) symbol-file <workdir>/build-iss/vmlinux'''
'''(xt-gdb) run'''

Wait patiently while Linux boots ... (maybe a minute). The setting of the '''memlimit'''
needs to match the PLATFORM_DEFAULT_MEM_SIZE defined in /arch/xtensa/platforms/iss/include/platform/hardware.h.
Currently this limit us 128 MegaBytes:

#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000 /* 13,4217,728 128M */

and we will be extending this for the DC233L to take advantage of it's V3 MMU.

Login as root (no password).

'''Note:''' Input via ISS is cooked, so everything typed gets echoed.
Also, time as reported by the kernel does not progress
according to true wall-clock time: it currently depends on
a simulated processor clock, which advances at various speeds
according to load.

Instructions for building and booting Linux

2011-01-06T05:51:15Z

Piet: /* Configure buildroot */

These instructions explain how to build a toolchain, root filesystem and kernel for Linux running on an Xtensa processor. These instructions apply specifically to the XTAV60 (LX60) board.

Some general notes on these instructions:

* They are a work in progress. If you are using the latest development sources, the build process may change, so you should be sure to get the latest version of this document at [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions]. If you are using one of the development snapshot releases, you should use the version of the build instructions included with that snapshot.

* The following was tested on x86 machines running RedHat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3). It is expected to work on newer Fedora releases (e.g., was tested on FC6) but to maintain host compatibility with Xtensa Tools, it is best to avoid Fedora releases beyond FC5. Other host distributions likely work but have not been tested.
** '''NOTE:''' this assumes the default selection of packages in buildroot. Selecting extra packages may require a more recent host OS or more recent version of certain tools. For example, the default version of <tt>find</tt> on RHEL4 is too old to allow building all X11 packages in buildroot, so it is necessary to upgrade the host version of <tt>findutils</tt> on RHEL4 to build these packages.

* Lines prefixed with "sudo" need to be executed as root. The rest is best executed as a non-root user. (It is possible to install <tt>git</tt> as a non-root user if root access is an issue. How to do this isn't shown here.)

* Lines that set environment variables assume a Bourne compatible shell (e.g., /bin/sh or bash), but are easily adapted to other shells.

* Instructions are assumed executed all in order (e.g., commands assume current directory and environment variables set earlier).

== Setup your host system ==

If you are using one of the snapshot releases, you can skip this step.

If you want to work with the latest development sources, you will need
[[Installing GIT|<tt>git</tt> installed on your system]].

== Download buildroot and the Linux kernel ==

The following section describes how to download the latest
versions of buildroot and of the Linux kernel.
Skip this step if you are using one of the
[http://wiki.linux-xtensa.org/index.php/Buildroot_Snapshots snapshot releases].

Adventurous users that want to use the '''bleeding edge''' code can execute the following:

'''$ cd <workdir>'''
'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa.git buildroot'''
'''$ git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git linux'''

where <tt><workdir></tt> is the path to an empty directory on a disk with
at least 4 GB available space. You end up with the following file structure,
which is assumed by the rest of this document:

<workdir>/
/buildroot
/linux

The MASTER branch of the buildroot repository is often is a state of development.
It's recommended to use the last snapshot for application developers. In the
case of the Avnet development boards a 'snapshot_2+SMP' branch is recommended
in the currently experimental SMP git repository:

'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

If you happen to have write access to either repository you should change '''git:''' to '''git+ssh:'''
For Example:

'''$ git clone git+ssh://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

For more details, see the [http://wiki.linux-xtensa.org/index.php/Repository_Access repository access] page.

== Install any required processor specific overlay ==

This step is required if you are targeting a custom Xtensa processor.
If you use a Diamond 232L Standard Core, you can skip this step.

To configure buildroot and the kernel to use a custom Xtensa processor
configuration, you need to overlay a set of files customized for your
processor configuration onto toolchain sources (gcc, binutils, gdb, etc)
and the Linux kernel. This process has been automated using a script
located in the buildroot source tree.
For usage information, you can invoke it without arguments:

'''$ cd <workdir>'''
'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install'''

which displays a help message similar to the following:

xt-buildroot-overlay-install version 1.3
Usage: xt-buildroot-overlay-install <parameters> [<options>]
Where <parameters> are:
-t file.tgz Specify path to the Xtensa Linux overlay tarball, typically
<xtensa_root>/src/xtensa-config-overlay.tar.gz
-b dir Path to the base of the buildroot source tree, in which
package specific overlay tarballs get installed.
-k dir Path to the base of the Linux kernel source tree, in which
the Linux kernel specific overlay gets installed.
-c config_name Name for the Xtensa processor configuration as it will be
known to the open source community. Must be a lowercase
identifier, starting with a letter, consisting of letters
and numbers and underscores, not ending with underscore
and not containing consecutive underscores. For examples:
dc232b , dc232b_be , mmubasele , fsf , s5000 .
-l long_name Long name for the Xtensa processor configuration, human-
readable with spaces etc allowed (must be quoted).
For example: 'Diamond 232L Standard Core Rev.B (LE)'
Try to keep it within approximately 40 characters.
And <options> are:
-f If package specific overlay tarballs already exist in
the destination source tree, overwrite them without asking.
--help Show this usage message.

Note that the Xtensa Linux overlay tarball MUST be obtained from an Xtensa
core package built using release RB-2008.3 or later.

Here is an example invocation of the overlay installation script:

'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install -t blinkcore-config-overlay.tar.gz''' \
'''-b ./buildroot -k ./linux -c superzip -l "ChipCorp SuperZIP Blink Accelerator Core"'''

The script extracts some relevant information from the overlay tarball,
presents it along with relevant parameters to the user, and prompts
for confirmation before proceeding.

The chosen processor name (-c option) must be unique among known Xtensa processors.
It is also probably wise to avoid names confusingly similar to other (non-Xtensa) processors.
If you expect at some point to contribute support for your custom processor to the
open-source community, this name will likely be long-lived.
(One way to contribute support for a custom processor might be to submit the overlay tarball
or files to the linux-xtensa.org maintainers.)

In the steps below, buildroot and the Linux kernel must be configured
(in their respective <code>''make menuconfig''</code> steps) to select
the <code>''custom''</code> Xtensa processor option.
This presents an extra configuration menu entry where you must provide
the name of the Xtensa processor. Set it to the same name
as was specified in the <code>-c</code> option above.

== Build a toolchain and root filesystem using buildroot ==

'''Note:''' for more details on generic buildroot topics not covered in this simple how-to,
see [http://buildroot.uclibc.org/ buildroot.uclibc.org].

=== Configure buildroot ===

The first time you configure buildroot, start with defaults for your Xtensa processor:

'''$ cd <workdir>/buildroot'''
'''$ ./target/xtensa/setup-config <corename>'''

where ''<corename>'' is the overlay name of your selected Xtensa or Diamond core
(e.g., '''dc233c'''). If you omit ''<corename>'', a help message and a list
of currently installed Tensilica core overlays is displayed.

Optionally, you can then customize your buildroot configuration, such as
selecting additional packages, setting various parameters, and so on.
The following make targets provide a ''curses'' (text-based graphical) interface
for configuring buildroot, the uClibc C library, and busybox, respectively.
('''Note:''' You need the <tt>TERM</tt> environment variable properly set for
these curses based tools to work.)

'''$ make menuconfig'''
'''$ make uclibc-menuconfig'''
'''$ make busybox-menuconfig'''

=== Build buildroot ===

Just type:

'''$ make'''

THIS WILL TAKE A LONG TIME (from about 30 minutes with defaults on a 3 GHz Pentium 4,
to perhaps an hour or many depending on your system and on whether
you enabled extra packages in your buildroot configuration).

Wait patiently for the build to complete. This builds an entire toolchain
as well as some basic packages, and constructs a root filesystem.
It might build many more packages if you selected them earlier with menuconfig.

==== If Something Goes Wrong ====

Perhaps you missed some step above and the build fails. Or you're just switching to a different processor configuration, or making some change with unknown dependencies. Either way, you'll probably need to fix the error and/or make the change, and redo the whole build. The above <tt>make</tt> command usually works fine if you
just added a package using menuconfig, but otherwise does not check many dependencies, so it will usually NOT rebuild things that depend on whatever you have fixed or changed. Here's one way to retry the make from scratch without having to wipe out the <tt>buildroot</tt> directory tree completely and start again from the git cloning.

$ '''rm -rf *build_xtensa* binaries'''
$ '''make'''

It is not necessary to empty the 'dl' subdirectory, which contains tarballs downloaded from the Internet, nor the .config file, which contains the buildroot configuration. Customizations to the uClibc and <tt>busybox</tt> configurations should have ended up getting saved in target/xtensa/uClibc.config and target/xtensa/busybox-config, respectively, so hopefully are preserved by the above sequence.

== Build and Run a Linux Kernel on the XTAV60, AXAV110, or XTAV200 Boards ==

References to the ''XTAV60 board'' refer to the combination of
the Avnet [http://www.em.avnet.com/tensilica1 LX60 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX60 (XT-AV60) Board User's Guide''.

Similarly, references to the ''XTAV200 board'' refers the combination of
the Avnet [http://www.em.avnet.com/tensilica2 LX200 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX200 (XT-AV200) Board User's Guide''.

=== Configure the kernel ===

The kernel build is a two-step process: configure the kernel, and build it.
First, before we can do anything with the kernel, set your PATH to
point to the toolchain built using buildroot.

$ '''export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"'''

where ''<cname>'' is the name of the Xtensa processor configuration you selected
when building the toolchain (e.g., <code>dc232b</code>).

Now setup a destination for kernel builds.
We usually like to have the build directory separate from
the source directory, so we use 'O=</destination/path>' in
kernel make commands. If you'll be routinely building multiple
configurations of the Linux kernel, it's good to have some
naming conventions for the build directory. For example,
to experiment with multiple target platforms but only one
processor configuration, we include just the platform name here:

$'''mkdir build-xtav60'''

Let's start with the default kernel configuration for the Avnet board
(which works on both XTAV60 (LX60), XTAV110 (LX110), and XTAV200 (LX200) boards)
as follows:

$ '''cd linux'''
$ '''make O=../build-xtav60 ARCH=xtensa KBUILD_DEFCONFIG=lx60_defconfig defconfig'''

This configures the kernel using the default configuration found in
'''arch/xtensa/configs/lx60_defconfig'''.

'''NOTE:''' This kernel configuration has nothing to do with Xtensa
processor configuration. That comes next.

Let's now customize this a little bit to select the correct Xtensa processor
configuration, and to bundle the root filesystem into the kernel:

$ '''make O=../build-xtav60 ARCH=xtensa menuconfig'''

Under '''General setup''',
make sure the '''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is enabled. Underneath that, edit '''Initramfs source file(s)''',
and enter the path to the cpio formatted root filesystem
generated by buildroot:

''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio.gz

(Don't forget to replace ''<workdir>'' with the appropriate full path
and ''<cname>'' with your Xtensa processor configuration name.)

Under '''Processor type and features''',
make sure the '''Xtensa Processor Configuration''' is correct and matches
the processor configuration name you used to build the toolchain with buildroot
(for example, ''dc232b'' for Diamond 232L Rev.B).
The kernel build selects a toolchain and processor variant specific headers
based on this selection.
If the desired processor configuration does not appear explicitly in the list,
simply select '''Custom Xtensa processor configuration''' and enter the
processor configuration name (all lowercase) into the next menu parameter,
'''Xtensa Processor Custom Variant Name'''.

Back in the main menu, under '''Platform options''', make sure the
'''CPU clock rate''' entry is set correctly according to the following table:

{| border="1" style="text-align:center; margin: 1em auto 1em auto"
|-
! Board !! Frequency selected in XPG (MHz) !! ''CPU clock rate'' setting (kHz)
|-
|rowspan="3"| XTAV60 (LX60)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV110 (LX110)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV200 (LX200)
| 30 || 31250
|-
| 40 || 41667
|-
| 50 || 50000
|-
|}

Exit menuconfig, saving your configuration changes.

Backup your configuration outside the build directory. For example:

$ '''cp ../build-xtav60/.config config.xtav60.saved'''

If you do a clean rebuild of the kernel (e.g., "rm -rf ../build-xtav60")
you can now configure it with simply:
$ '''mkdir ../build-xtav60 ; cp config.xtav60.saved ../build-xtav60/.config'''
Of course if you update the kernel, you'll probably again have to do:
$ '''make O=../build-xtav60 ARCH=xtensa menuconfig'''
and save a new copy of your configuration.

=== Build the kernel ===

$ '''make O=../build-xtav60 ARCH=xtensa'''

The build will issue a few warnings which are normal.
Once complete, the bootable image is in:
<workdir>/build-xtav60/arch/xtensa/boot/Image.elf
and the uncompressed ELF file containing kernel symbols is in:
<workdir>/build-xtav60/vmlinux
There is also a RedBoot bootable image (if you use RedBoot) in:
<workdir>/build-xtav60/arch/xtensa/boot/zImage.redboot

=== Install Xtensa Tools for the selected core ===

If you opt to download the kernel over OCD, you need <tt>xt-gdb</tt>
which is part of Tensilica's Xtensa Tools package. This must be obtained
from Tensilica, and is not the same toolchain as built by buildroot.
You also need to install the corresponding Tensilica core package,
so that the Xtensa Tools know about your particular configured
Tensilica core.

The toolchain built using buildroot can be configured to
include GDB, but that version of GDB does not support
communicating with Tensilica's Xtensa OCD Daemon, and
thus cannot be used to download the kernel over OCD.

In this example, it is assumed that the machine hosting the
Xtensa Tools has access to the <workdir> directory tree.

=== Install and setup the Xtensa OCD Daemon ===

Setup and connect your JTAG probe, etc.

=== Connect a terminal server ===

At 38400 bps 8N1 no flow control to the XTAV60 serial port.

=== Optionally, setup networking ===

This step is optional.

Setup the board's MAC address using dipswitches
(see XTAV60 or XTAV200 board docs as appropriate)
and connect the board to a network that has a
DHCP server that will respond to that MAC address.
If you don't do this step, you'll simply not have network
access, and the boot process will take a minute or so longer
while the kernel times out waiting for a BOOTP response.
You can edit the kernel configuration and rebuild the kernel
to avoid using bootp (in particular, remove "ip=bootp" from
the kernel cmdline).

=== Download and run the kernel ===

Reset the board (see board documentation).

Using Xtensa Tools, invoke:

$ '''xt-gdb <workdir>/build-xtav60/arch/xtensa/boot/Image.elf'''

'''(xt-gdb) target remote <ocdhost>:20000 0'''
'''(xt-gdb) reset'''
'''(xt-gdb) load'''
'''(xt-gdb) set $pc = &_ResetVector'''
'''(xt-gdb) symbol-file <workdir>/build-xtav60/vmlinux'''
'''(xt-gdb) c'''

where <ocdhost> is the IP address or DNS name of the machine
running the Xtensa OCD daemon. The Linux kernel should
start booting as soon as 'c' (continue) is executed.

You should eventually get a login prompt.
Just login as root (no password).

Try various Linux commands. Look at <tt>/bin</tt>,
<tt>/sbin</tt>, <tt>/usr/bin</tt>, etc to see what's available.

'''Note:''' no need to setup an NFS or TFTP server. The filesystem
is contained within the kernel image. You may be able to mount
other filesystems over NFS though, if you wish, after booting.

=== Mounting the Root Filesystem Over NFS ===

If you build more than the minimal set of packages using
buildroot, the root filesystem can easily grow too large to
fit comfortably (or at all) inside the kernel. In this case,
rather than follow the instructions exactly as above,
you'll want to mount the root filesystem over NFS.

You may also want to mount the root filesystem over NFS to
make changes to the filesystem persistent across runs and
accessible from your development host.

First you need to install the root filesystem generated
using buildroot, to a machine that can serve it over NFS.
Assuming this machine runs Linux, one way to install it is
as follows:

$ '''mkdir ''<exportpath>'' '''
$ '''cd ''<exportpath>'' '''
$ '''sudo cpio -i -d -m -F ''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio --no-absolute-filenames '''

You then need to enable the NFS server on your system
(if not already active), and export this filesystem.
How you do this depends on your host Linux distribution.
For example, on some Fedora releases, one might:

* add the export path to <tt>/etc/exports</tt> using a line such as

''<exportpath>'' *(rw,sync,no_root_squash,no_all_squash,no_wdelay)

* turn on the NFS server if needed:

$ '''sudo /sbin/chkconfig nfs on'''

* tell the NFS server about the new exported filesystem

$ '''sudo /usr/sbin/exportfs -a'''
$ '''sudo /usr/sbin/exportfs -r'''

Second, follow the instructions in the previous sections,
then configure the kernel again as follows.

Under '''General setup''', make sure the
'''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is disabled (rather than enabled as done in previous sections).

Under '''Platform options''', under the line '''Default bootloader kernel arguments''',
select the boot parameters line and set it to something like this:

'''console=ttyS0,38400 ip=dhcp root=/dev/nfs rw nfsroot=''<server_ip>'':''<exportpath>'' '''

where ''<server_ip>'' is the IP address of your NFS server, and ''<exportpath>''
is the exported filesystem path.

Another approach is to just specify the ip addresses directly in the CMDLINE
'''CONFIG_CMDLINE="console=ttyS0,38400 ip=192.168.11.95:192.168.11.220:192.168.11.1:255.255.255.0:HiFi-2 root=/dev/nfs rw nfsroot=192.168.11.55:/exports/LINUX_ROOT.DC_C_233L debug coredump_filter=0xff" '''

Where the IP addresses are in the form:

'''${ipaddr}:${nfsroot_server}:${gatewayip}:${netmask}:${hostname}'''

Save this configuration, rebuild the kernel, and follow the
instructions in previous sections to download and run the kernel.
If everything goes well and is setup correctly, your kernel should
now boot with a root filesystem mounted over NFS.

== Build and Run a Linux Kernel on the Instruction Set Simulator (ISS) ==

You can build and run a Linux kernel in the Xtensa Instruction Set
Simulator (ISS). The following instructions have only been tried
with an ISS from the RB-2008.3 release of Xtensa Tools. Bear in
mind that the XTAV60 port is likely much more stable than the ISS port
of Linux at this point in time.

Note: Depending on your host OS version, you may need to install
Xtensa Tools on a separate machine.

=== Configure and Build the Kernel for ISS ===

Repeat all the same instructions as above for building the kernel for an
Avnet board, except that when initially configuring the kernel,
start from a ISS platform template instead. For example for the
DC233C Variant:

'''$ mkdir build-iss'''
'''$ cd linux'''
'''$ make O=../build-iss ARCH=xtensa KBUILD_DEFCONFIG=iss_dc233c_defconfig defconfig'''

The above make example configures the kernel using the default configuration found in
'''arch/xtensa/configs/iss_dc233_defconfig'''. Most important to note is that the
root file system mounted when Linux boots comes via the targets device '''/dev/simdisk0'''
which is defined in the kernel '''.config''' file. For example:

'''CONFIG_SIMDISK0_FILENAME="/export2/DC_C_233L/LINUX_ROOT.ext2"'''

The SIMDISK file name and VARIANT name are typically configured when running '''make menuconfig'''; Ex:

'''$ make O=../build-iss ARCH=xtensa menuconfig'''

and selecting

'''Xtensa Platform options''' ---> '''Host filename for a simulated device'''

and entering the pathname to the .ext2 file there. Ex: '''/export2/DC_C_233L/LINUX_ROOT.ext2'''

You often want to change the VARIANT to the one you desire, Ex: FSF. You do this via
the top level menu:

'''Xtensa Processor type and features ---> Xtensa Processor Custom Core Variant Name'''

With the new SIMDISK approach you copy the EXT2 Filesystem file generated by Buildroot
to a location to be accessed by Xtensa Linux. Ex:

'''$ cp /export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot/binaries/dc233c/rootfs.xtensa_dc233c.ext2 /export2/DC_C_233L/LINUX_ROOT.ext2'''

'''NOTE:''' There is an old '''iss_defconfig''' that tries to use a '''tuntap''' Ethernet
interface that currently isn't supported.
Previously with this old iss_defconfig using the '''tuntap''' Ethernet interface
it was suggested to set up the initramfs filesystem, and do the following.
Under '''Bus Options''', deselect '''PCI support'''.
Under '''Platform Options''', deselect '''Default bootloader kernel arguments'''.
Hopefully we will someday be able to support the use of a network interface with
ISS simulation and then be able to mount NFS root partitions again. So I'm leaving
this note for future exploration of this mechanism; Hope you don't mind the clutter.

Continue configuring and building the kernel as usual.

=== Run the Kernel on ISS ===

Using Xtensa Tools, invoke:

'''$ xt-gdb <workdir>/build-iss/arch/xtensa/boot/Image.elf'''
'''(xt-gdb) target sim --turbo --memlimit=128'''
'''(xt-gdb) symbol-file <workdir>/build-iss/vmlinux'''
'''(xt-gdb) run'''

Wait patiently while Linux boots ... (maybe a minute). The setting of the '''memlimit'''
needs to match the PLATFORM_DEFAULT_MEM_SIZE defined in /arch/xtensa/platforms/iss/include/platform/hardware.h.
Currently this limit us 128 MegaBytes:

#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000 /* 13,4217,728 128M */

and we will be extending this for the DC233L to take advantage of it's V3 MMU.

Login as root (no password).

'''Note:''' Input via ISS is cooked, so everything typed gets echoed.
Also, time as reported by the kernel does not progress
according to true wall-clock time: it currently depends on
a simulated processor clock, which advances at various speeds
according to load.

Instructions for building and booting Linux

2011-01-06T05:48:50Z

Piet: /* Mounting the Root Filesystem Over NFS */

These instructions explain how to build a toolchain, root filesystem and kernel for Linux running on an Xtensa processor. These instructions apply specifically to the XTAV60 (LX60) board.

Some general notes on these instructions:

* They are a work in progress. If you are using the latest development sources, the build process may change, so you should be sure to get the latest version of this document at [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions]. If you are using one of the development snapshot releases, you should use the version of the build instructions included with that snapshot.

* The following was tested on x86 machines running RedHat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3). It is expected to work on newer Fedora releases (e.g., was tested on FC6) but to maintain host compatibility with Xtensa Tools, it is best to avoid Fedora releases beyond FC5. Other host distributions likely work but have not been tested.
** '''NOTE:''' this assumes the default selection of packages in buildroot. Selecting extra packages may require a more recent host OS or more recent version of certain tools. For example, the default version of <tt>find</tt> on RHEL4 is too old to allow building all X11 packages in buildroot, so it is necessary to upgrade the host version of <tt>findutils</tt> on RHEL4 to build these packages.

* Lines prefixed with "sudo" need to be executed as root. The rest is best executed as a non-root user. (It is possible to install <tt>git</tt> as a non-root user if root access is an issue. How to do this isn't shown here.)

* Lines that set environment variables assume a Bourne compatible shell (e.g., /bin/sh or bash), but are easily adapted to other shells.

* Instructions are assumed executed all in order (e.g., commands assume current directory and environment variables set earlier).

== Setup your host system ==

If you are using one of the snapshot releases, you can skip this step.

If you want to work with the latest development sources, you will need
[[Installing GIT|<tt>git</tt> installed on your system]].

== Download buildroot and the Linux kernel ==

The following section describes how to download the latest
versions of buildroot and of the Linux kernel.
Skip this step if you are using one of the
[http://wiki.linux-xtensa.org/index.php/Buildroot_Snapshots snapshot releases].

Adventurous users that want to use the '''bleeding edge''' code can execute the following:

'''$ cd <workdir>'''
'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa.git buildroot'''
'''$ git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git linux'''

where <tt><workdir></tt> is the path to an empty directory on a disk with
at least 4 GB available space. You end up with the following file structure,
which is assumed by the rest of this document:

<workdir>/
/buildroot
/linux

The MASTER branch of the buildroot repository is often is a state of development.
It's recommended to use the last snapshot for application developers. In the
case of the Avnet development boards a 'snapshot_2+SMP' branch is recommended
in the currently experimental SMP git repository:

'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

If you happen to have write access to either repository you should change '''git:''' to '''git+ssh:'''
For Example:

'''$ git clone git+ssh://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

For more details, see the [http://wiki.linux-xtensa.org/index.php/Repository_Access repository access] page.

== Install any required processor specific overlay ==

This step is required if you are targeting a custom Xtensa processor.
If you use a Diamond 232L Standard Core, you can skip this step.

To configure buildroot and the kernel to use a custom Xtensa processor
configuration, you need to overlay a set of files customized for your
processor configuration onto toolchain sources (gcc, binutils, gdb, etc)
and the Linux kernel. This process has been automated using a script
located in the buildroot source tree.
For usage information, you can invoke it without arguments:

'''$ cd <workdir>'''
'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install'''

which displays a help message similar to the following:

xt-buildroot-overlay-install version 1.3
Usage: xt-buildroot-overlay-install <parameters> [<options>]
Where <parameters> are:
-t file.tgz Specify path to the Xtensa Linux overlay tarball, typically
<xtensa_root>/src/xtensa-config-overlay.tar.gz
-b dir Path to the base of the buildroot source tree, in which
package specific overlay tarballs get installed.
-k dir Path to the base of the Linux kernel source tree, in which
the Linux kernel specific overlay gets installed.
-c config_name Name for the Xtensa processor configuration as it will be
known to the open source community. Must be a lowercase
identifier, starting with a letter, consisting of letters
and numbers and underscores, not ending with underscore
and not containing consecutive underscores. For examples:
dc232b , dc232b_be , mmubasele , fsf , s5000 .
-l long_name Long name for the Xtensa processor configuration, human-
readable with spaces etc allowed (must be quoted).
For example: 'Diamond 232L Standard Core Rev.B (LE)'
Try to keep it within approximately 40 characters.
And <options> are:
-f If package specific overlay tarballs already exist in
the destination source tree, overwrite them without asking.
--help Show this usage message.

Note that the Xtensa Linux overlay tarball MUST be obtained from an Xtensa
core package built using release RB-2008.3 or later.

Here is an example invocation of the overlay installation script:

'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install -t blinkcore-config-overlay.tar.gz''' \
'''-b ./buildroot -k ./linux -c superzip -l "ChipCorp SuperZIP Blink Accelerator Core"'''

The script extracts some relevant information from the overlay tarball,
presents it along with relevant parameters to the user, and prompts
for confirmation before proceeding.

The chosen processor name (-c option) must be unique among known Xtensa processors.
It is also probably wise to avoid names confusingly similar to other (non-Xtensa) processors.
If you expect at some point to contribute support for your custom processor to the
open-source community, this name will likely be long-lived.
(One way to contribute support for a custom processor might be to submit the overlay tarball
or files to the linux-xtensa.org maintainers.)

In the steps below, buildroot and the Linux kernel must be configured
(in their respective <code>''make menuconfig''</code> steps) to select
the <code>''custom''</code> Xtensa processor option.
This presents an extra configuration menu entry where you must provide
the name of the Xtensa processor. Set it to the same name
as was specified in the <code>-c</code> option above.

== Build a toolchain and root filesystem using buildroot ==

'''Note:''' for more details on generic buildroot topics not covered in this simple how-to,
see [http://buildroot.uclibc.org/ buildroot.uclibc.org].

=== Configure buildroot ===

The first time you configure buildroot, start with defaults for your Xtensa processor:

'''$ cd <workdir>/buildroot'''
'''$ ./target/xtensa/setup-config <corename>'''

where ''<corename>'' is the overlay name of your selected Xtensa or Diamond core
(e.g., '''dc232b'''). If you omit ''<corename>'', a help message and a list
of currently installed Tensilica core overlays is displayed.

Optionally, you can then customize your buildroot configuration, such as
selecting additional packages, setting various parameters, and so on.
The following make targets provide a ''curses'' (text-based graphical) interface
for configuring buildroot, the uClibc C library, and busybox, respectively.
('''Note:''' You need the <tt>TERM</tt> environment variable properly set for
these curses based tools to work.)

'''$ make menuconfig'''
'''$ make uclibc-menuconfig'''
'''$ make busybox-menuconfig'''

=== Build buildroot ===

Just type:

'''$ make'''

THIS WILL TAKE A LONG TIME (from about 30 minutes with defaults on a 3 GHz Pentium 4,
to perhaps an hour or many depending on your system and on whether
you enabled extra packages in your buildroot configuration).

Wait patiently for the build to complete. This builds an entire toolchain
as well as some basic packages, and constructs a root filesystem.
It might build many more packages if you selected them earlier with menuconfig.

==== If Something Goes Wrong ====

Perhaps you missed some step above and the build fails. Or you're just switching to a different processor configuration, or making some change with unknown dependencies. Either way, you'll probably need to fix the error and/or make the change, and redo the whole build. The above <tt>make</tt> command usually works fine if you
just added a package using menuconfig, but otherwise does not check many dependencies, so it will usually NOT rebuild things that depend on whatever you have fixed or changed. Here's one way to retry the make from scratch without having to wipe out the <tt>buildroot</tt> directory tree completely and start again from the git cloning.

$ '''rm -rf *build_xtensa* binaries'''
$ '''make'''

It is not necessary to empty the 'dl' subdirectory, which contains tarballs downloaded from the Internet, nor the .config file, which contains the buildroot configuration. Customizations to the uClibc and <tt>busybox</tt> configurations should have ended up getting saved in target/xtensa/uClibc.config and target/xtensa/busybox-config, respectively, so hopefully are preserved by the above sequence.

== Build and Run a Linux Kernel on the XTAV60, AXAV110, or XTAV200 Boards ==

References to the ''XTAV60 board'' refer to the combination of
the Avnet [http://www.em.avnet.com/tensilica1 LX60 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX60 (XT-AV60) Board User's Guide''.

Similarly, references to the ''XTAV200 board'' refers the combination of
the Avnet [http://www.em.avnet.com/tensilica2 LX200 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX200 (XT-AV200) Board User's Guide''.

=== Configure the kernel ===

The kernel build is a two-step process: configure the kernel, and build it.
First, before we can do anything with the kernel, set your PATH to
point to the toolchain built using buildroot.

$ '''export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"'''

where ''<cname>'' is the name of the Xtensa processor configuration you selected
when building the toolchain (e.g., <code>dc232b</code>).

Now setup a destination for kernel builds.
We usually like to have the build directory separate from
the source directory, so we use 'O=</destination/path>' in
kernel make commands. If you'll be routinely building multiple
configurations of the Linux kernel, it's good to have some
naming conventions for the build directory. For example,
to experiment with multiple target platforms but only one
processor configuration, we include just the platform name here:

$'''mkdir build-xtav60'''

Let's start with the default kernel configuration for the Avnet board
(which works on both XTAV60 (LX60), XTAV110 (LX110), and XTAV200 (LX200) boards)
as follows:

$ '''cd linux'''
$ '''make O=../build-xtav60 ARCH=xtensa KBUILD_DEFCONFIG=lx60_defconfig defconfig'''

This configures the kernel using the default configuration found in
'''arch/xtensa/configs/lx60_defconfig'''.

'''NOTE:''' This kernel configuration has nothing to do with Xtensa
processor configuration. That comes next.

Let's now customize this a little bit to select the correct Xtensa processor
configuration, and to bundle the root filesystem into the kernel:

$ '''make O=../build-xtav60 ARCH=xtensa menuconfig'''

Under '''General setup''',
make sure the '''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is enabled. Underneath that, edit '''Initramfs source file(s)''',
and enter the path to the cpio formatted root filesystem
generated by buildroot:

''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio.gz

(Don't forget to replace ''<workdir>'' with the appropriate full path
and ''<cname>'' with your Xtensa processor configuration name.)

Under '''Processor type and features''',
make sure the '''Xtensa Processor Configuration''' is correct and matches
the processor configuration name you used to build the toolchain with buildroot
(for example, ''dc232b'' for Diamond 232L Rev.B).
The kernel build selects a toolchain and processor variant specific headers
based on this selection.
If the desired processor configuration does not appear explicitly in the list,
simply select '''Custom Xtensa processor configuration''' and enter the
processor configuration name (all lowercase) into the next menu parameter,
'''Xtensa Processor Custom Variant Name'''.

Back in the main menu, under '''Platform options''', make sure the
'''CPU clock rate''' entry is set correctly according to the following table:

{| border="1" style="text-align:center; margin: 1em auto 1em auto"
|-
! Board !! Frequency selected in XPG (MHz) !! ''CPU clock rate'' setting (kHz)
|-
|rowspan="3"| XTAV60 (LX60)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV110 (LX110)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV200 (LX200)
| 30 || 31250
|-
| 40 || 41667
|-
| 50 || 50000
|-
|}

Exit menuconfig, saving your configuration changes.

Backup your configuration outside the build directory. For example:

$ '''cp ../build-xtav60/.config config.xtav60.saved'''

If you do a clean rebuild of the kernel (e.g., "rm -rf ../build-xtav60")
you can now configure it with simply:
$ '''mkdir ../build-xtav60 ; cp config.xtav60.saved ../build-xtav60/.config'''
Of course if you update the kernel, you'll probably again have to do:
$ '''make O=../build-xtav60 ARCH=xtensa menuconfig'''
and save a new copy of your configuration.

=== Build the kernel ===

$ '''make O=../build-xtav60 ARCH=xtensa'''

The build will issue a few warnings which are normal.
Once complete, the bootable image is in:
<workdir>/build-xtav60/arch/xtensa/boot/Image.elf
and the uncompressed ELF file containing kernel symbols is in:
<workdir>/build-xtav60/vmlinux
There is also a RedBoot bootable image (if you use RedBoot) in:
<workdir>/build-xtav60/arch/xtensa/boot/zImage.redboot

=== Install Xtensa Tools for the selected core ===

If you opt to download the kernel over OCD, you need <tt>xt-gdb</tt>
which is part of Tensilica's Xtensa Tools package. This must be obtained
from Tensilica, and is not the same toolchain as built by buildroot.
You also need to install the corresponding Tensilica core package,
so that the Xtensa Tools know about your particular configured
Tensilica core.

The toolchain built using buildroot can be configured to
include GDB, but that version of GDB does not support
communicating with Tensilica's Xtensa OCD Daemon, and
thus cannot be used to download the kernel over OCD.

In this example, it is assumed that the machine hosting the
Xtensa Tools has access to the <workdir> directory tree.

=== Install and setup the Xtensa OCD Daemon ===

Setup and connect your JTAG probe, etc.

=== Connect a terminal server ===

At 38400 bps 8N1 no flow control to the XTAV60 serial port.

=== Optionally, setup networking ===

This step is optional.

Setup the board's MAC address using dipswitches
(see XTAV60 or XTAV200 board docs as appropriate)
and connect the board to a network that has a
DHCP server that will respond to that MAC address.
If you don't do this step, you'll simply not have network
access, and the boot process will take a minute or so longer
while the kernel times out waiting for a BOOTP response.
You can edit the kernel configuration and rebuild the kernel
to avoid using bootp (in particular, remove "ip=bootp" from
the kernel cmdline).

=== Download and run the kernel ===

Reset the board (see board documentation).

Using Xtensa Tools, invoke:

$ '''xt-gdb <workdir>/build-xtav60/arch/xtensa/boot/Image.elf'''

'''(xt-gdb) target remote <ocdhost>:20000 0'''
'''(xt-gdb) reset'''
'''(xt-gdb) load'''
'''(xt-gdb) set $pc = &_ResetVector'''
'''(xt-gdb) symbol-file <workdir>/build-xtav60/vmlinux'''
'''(xt-gdb) c'''

where <ocdhost> is the IP address or DNS name of the machine
running the Xtensa OCD daemon. The Linux kernel should
start booting as soon as 'c' (continue) is executed.

You should eventually get a login prompt.
Just login as root (no password).

Try various Linux commands. Look at <tt>/bin</tt>,
<tt>/sbin</tt>, <tt>/usr/bin</tt>, etc to see what's available.

'''Note:''' no need to setup an NFS or TFTP server. The filesystem
is contained within the kernel image. You may be able to mount
other filesystems over NFS though, if you wish, after booting.

=== Mounting the Root Filesystem Over NFS ===

If you build more than the minimal set of packages using
buildroot, the root filesystem can easily grow too large to
fit comfortably (or at all) inside the kernel. In this case,
rather than follow the instructions exactly as above,
you'll want to mount the root filesystem over NFS.

You may also want to mount the root filesystem over NFS to
make changes to the filesystem persistent across runs and
accessible from your development host.

First you need to install the root filesystem generated
using buildroot, to a machine that can serve it over NFS.
Assuming this machine runs Linux, one way to install it is
as follows:

$ '''mkdir ''<exportpath>'' '''
$ '''cd ''<exportpath>'' '''
$ '''sudo cpio -i -d -m -F ''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio --no-absolute-filenames '''

You then need to enable the NFS server on your system
(if not already active), and export this filesystem.
How you do this depends on your host Linux distribution.
For example, on some Fedora releases, one might:

* add the export path to <tt>/etc/exports</tt> using a line such as

''<exportpath>'' *(rw,sync,no_root_squash,no_all_squash,no_wdelay)

* turn on the NFS server if needed:

$ '''sudo /sbin/chkconfig nfs on'''

* tell the NFS server about the new exported filesystem

$ '''sudo /usr/sbin/exportfs -a'''
$ '''sudo /usr/sbin/exportfs -r'''

Second, follow the instructions in the previous sections,
then configure the kernel again as follows.

Under '''General setup''', make sure the
'''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is disabled (rather than enabled as done in previous sections).

Under '''Platform options''', under the line '''Default bootloader kernel arguments''',
select the boot parameters line and set it to something like this:

'''console=ttyS0,38400 ip=dhcp root=/dev/nfs rw nfsroot=''<server_ip>'':''<exportpath>'' '''

where ''<server_ip>'' is the IP address of your NFS server, and ''<exportpath>''
is the exported filesystem path.

Another approach is to just specify the ip addresses directly in the CMDLINE
'''CONFIG_CMDLINE="console=ttyS0,38400 ip=192.168.11.95:192.168.11.220:192.168.11.1:255.255.255.0:HiFi-2 root=/dev/nfs rw nfsroot=192.168.11.55:/exports/LINUX_ROOT.DC_C_233L debug coredump_filter=0xff" '''

Where the IP addresses are in the form:

'''${ipaddr}:${nfsroot_server}:${gatewayip}:${netmask}:${hostname}'''

Save this configuration, rebuild the kernel, and follow the
instructions in previous sections to download and run the kernel.
If everything goes well and is setup correctly, your kernel should
now boot with a root filesystem mounted over NFS.

== Build and Run a Linux Kernel on the Instruction Set Simulator (ISS) ==

You can build and run a Linux kernel in the Xtensa Instruction Set
Simulator (ISS). The following instructions have only been tried
with an ISS from the RB-2008.3 release of Xtensa Tools. Bear in
mind that the XTAV60 port is likely much more stable than the ISS port
of Linux at this point in time.

Note: Depending on your host OS version, you may need to install
Xtensa Tools on a separate machine.

=== Configure and Build the Kernel for ISS ===

Repeat all the same instructions as above for building the kernel for an
Avnet board, except that when initially configuring the kernel,
start from a ISS platform template instead. For example for the
DC233C Variant:

'''$ mkdir build-iss'''
'''$ cd linux'''
'''$ make O=../build-iss ARCH=xtensa KBUILD_DEFCONFIG=iss_dc233c_defconfig defconfig'''

The above make example configures the kernel using the default configuration found in
'''arch/xtensa/configs/iss_dc233_defconfig'''. Most important to note is that the
root file system mounted when Linux boots comes via the targets device '''/dev/simdisk0'''
which is defined in the kernel '''.config''' file. For example:

'''CONFIG_SIMDISK0_FILENAME="/export2/DC_C_233L/LINUX_ROOT.ext2"'''

The SIMDISK file name and VARIANT name are typically configured when running '''make menuconfig'''; Ex:

'''$ make O=../build-iss ARCH=xtensa menuconfig'''

and selecting

'''Xtensa Platform options''' ---> '''Host filename for a simulated device'''

and entering the pathname to the .ext2 file there. Ex: '''/export2/DC_C_233L/LINUX_ROOT.ext2'''

You often want to change the VARIANT to the one you desire, Ex: FSF. You do this via
the top level menu:

'''Xtensa Processor type and features ---> Xtensa Processor Custom Core Variant Name'''

With the new SIMDISK approach you copy the EXT2 Filesystem file generated by Buildroot
to a location to be accessed by Xtensa Linux. Ex:

'''$ cp /export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot/binaries/dc233c/rootfs.xtensa_dc233c.ext2 /export2/DC_C_233L/LINUX_ROOT.ext2'''

'''NOTE:''' There is an old '''iss_defconfig''' that tries to use a '''tuntap''' Ethernet
interface that currently isn't supported.
Previously with this old iss_defconfig using the '''tuntap''' Ethernet interface
it was suggested to set up the initramfs filesystem, and do the following.
Under '''Bus Options''', deselect '''PCI support'''.
Under '''Platform Options''', deselect '''Default bootloader kernel arguments'''.
Hopefully we will someday be able to support the use of a network interface with
ISS simulation and then be able to mount NFS root partitions again. So I'm leaving
this note for future exploration of this mechanism; Hope you don't mind the clutter.

Continue configuring and building the kernel as usual.

=== Run the Kernel on ISS ===

Using Xtensa Tools, invoke:

'''$ xt-gdb <workdir>/build-iss/arch/xtensa/boot/Image.elf'''
'''(xt-gdb) target sim --turbo --memlimit=128'''
'''(xt-gdb) symbol-file <workdir>/build-iss/vmlinux'''
'''(xt-gdb) run'''

Wait patiently while Linux boots ... (maybe a minute). The setting of the '''memlimit'''
needs to match the PLATFORM_DEFAULT_MEM_SIZE defined in /arch/xtensa/platforms/iss/include/platform/hardware.h.
Currently this limit us 128 MegaBytes:

#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000 /* 13,4217,728 128M */

and we will be extending this for the DC233L to take advantage of it's V3 MMU.

Login as root (no password).

'''Note:''' Input via ISS is cooked, so everything typed gets echoed.
Also, time as reported by the kernel does not progress
according to true wall-clock time: it currently depends on
a simulated processor clock, which advances at various speeds
according to load.

Instructions for building and booting Linux

2011-01-06T05:46:01Z

Piet: /* Mounting the Root Filesystem Over NFS */

These instructions explain how to build a toolchain, root filesystem and kernel for Linux running on an Xtensa processor. These instructions apply specifically to the XTAV60 (LX60) board.

Some general notes on these instructions:

* They are a work in progress. If you are using the latest development sources, the build process may change, so you should be sure to get the latest version of this document at [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions]. If you are using one of the development snapshot releases, you should use the version of the build instructions included with that snapshot.

* The following was tested on x86 machines running RedHat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3). It is expected to work on newer Fedora releases (e.g., was tested on FC6) but to maintain host compatibility with Xtensa Tools, it is best to avoid Fedora releases beyond FC5. Other host distributions likely work but have not been tested.
** '''NOTE:''' this assumes the default selection of packages in buildroot. Selecting extra packages may require a more recent host OS or more recent version of certain tools. For example, the default version of <tt>find</tt> on RHEL4 is too old to allow building all X11 packages in buildroot, so it is necessary to upgrade the host version of <tt>findutils</tt> on RHEL4 to build these packages.

* Lines prefixed with "sudo" need to be executed as root. The rest is best executed as a non-root user. (It is possible to install <tt>git</tt> as a non-root user if root access is an issue. How to do this isn't shown here.)

* Lines that set environment variables assume a Bourne compatible shell (e.g., /bin/sh or bash), but are easily adapted to other shells.

* Instructions are assumed executed all in order (e.g., commands assume current directory and environment variables set earlier).

== Setup your host system ==

If you are using one of the snapshot releases, you can skip this step.

If you want to work with the latest development sources, you will need
[[Installing GIT|<tt>git</tt> installed on your system]].

== Download buildroot and the Linux kernel ==

The following section describes how to download the latest
versions of buildroot and of the Linux kernel.
Skip this step if you are using one of the
[http://wiki.linux-xtensa.org/index.php/Buildroot_Snapshots snapshot releases].

Adventurous users that want to use the '''bleeding edge''' code can execute the following:

'''$ cd <workdir>'''
'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa.git buildroot'''
'''$ git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git linux'''

where <tt><workdir></tt> is the path to an empty directory on a disk with
at least 4 GB available space. You end up with the following file structure,
which is assumed by the rest of this document:

<workdir>/
/buildroot
/linux

The MASTER branch of the buildroot repository is often is a state of development.
It's recommended to use the last snapshot for application developers. In the
case of the Avnet development boards a 'snapshot_2+SMP' branch is recommended
in the currently experimental SMP git repository:

'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

If you happen to have write access to either repository you should change '''git:''' to '''git+ssh:'''
For Example:

'''$ git clone git+ssh://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

For more details, see the [http://wiki.linux-xtensa.org/index.php/Repository_Access repository access] page.

== Install any required processor specific overlay ==

This step is required if you are targeting a custom Xtensa processor.
If you use a Diamond 232L Standard Core, you can skip this step.

To configure buildroot and the kernel to use a custom Xtensa processor
configuration, you need to overlay a set of files customized for your
processor configuration onto toolchain sources (gcc, binutils, gdb, etc)
and the Linux kernel. This process has been automated using a script
located in the buildroot source tree.
For usage information, you can invoke it without arguments:

'''$ cd <workdir>'''
'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install'''

which displays a help message similar to the following:

xt-buildroot-overlay-install version 1.3
Usage: xt-buildroot-overlay-install <parameters> [<options>]
Where <parameters> are:
-t file.tgz Specify path to the Xtensa Linux overlay tarball, typically
<xtensa_root>/src/xtensa-config-overlay.tar.gz
-b dir Path to the base of the buildroot source tree, in which
package specific overlay tarballs get installed.
-k dir Path to the base of the Linux kernel source tree, in which
the Linux kernel specific overlay gets installed.
-c config_name Name for the Xtensa processor configuration as it will be
known to the open source community. Must be a lowercase
identifier, starting with a letter, consisting of letters
and numbers and underscores, not ending with underscore
and not containing consecutive underscores. For examples:
dc232b , dc232b_be , mmubasele , fsf , s5000 .
-l long_name Long name for the Xtensa processor configuration, human-
readable with spaces etc allowed (must be quoted).
For example: 'Diamond 232L Standard Core Rev.B (LE)'
Try to keep it within approximately 40 characters.
And <options> are:
-f If package specific overlay tarballs already exist in
the destination source tree, overwrite them without asking.
--help Show this usage message.

Note that the Xtensa Linux overlay tarball MUST be obtained from an Xtensa
core package built using release RB-2008.3 or later.

Here is an example invocation of the overlay installation script:

'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install -t blinkcore-config-overlay.tar.gz''' \
'''-b ./buildroot -k ./linux -c superzip -l "ChipCorp SuperZIP Blink Accelerator Core"'''

The script extracts some relevant information from the overlay tarball,
presents it along with relevant parameters to the user, and prompts
for confirmation before proceeding.

The chosen processor name (-c option) must be unique among known Xtensa processors.
It is also probably wise to avoid names confusingly similar to other (non-Xtensa) processors.
If you expect at some point to contribute support for your custom processor to the
open-source community, this name will likely be long-lived.
(One way to contribute support for a custom processor might be to submit the overlay tarball
or files to the linux-xtensa.org maintainers.)

In the steps below, buildroot and the Linux kernel must be configured
(in their respective <code>''make menuconfig''</code> steps) to select
the <code>''custom''</code> Xtensa processor option.
This presents an extra configuration menu entry where you must provide
the name of the Xtensa processor. Set it to the same name
as was specified in the <code>-c</code> option above.

== Build a toolchain and root filesystem using buildroot ==

'''Note:''' for more details on generic buildroot topics not covered in this simple how-to,
see [http://buildroot.uclibc.org/ buildroot.uclibc.org].

=== Configure buildroot ===

The first time you configure buildroot, start with defaults for your Xtensa processor:

'''$ cd <workdir>/buildroot'''
'''$ ./target/xtensa/setup-config <corename>'''

where ''<corename>'' is the overlay name of your selected Xtensa or Diamond core
(e.g., '''dc232b'''). If you omit ''<corename>'', a help message and a list
of currently installed Tensilica core overlays is displayed.

Optionally, you can then customize your buildroot configuration, such as
selecting additional packages, setting various parameters, and so on.
The following make targets provide a ''curses'' (text-based graphical) interface
for configuring buildroot, the uClibc C library, and busybox, respectively.
('''Note:''' You need the <tt>TERM</tt> environment variable properly set for
these curses based tools to work.)

'''$ make menuconfig'''
'''$ make uclibc-menuconfig'''
'''$ make busybox-menuconfig'''

=== Build buildroot ===

Just type:

'''$ make'''

THIS WILL TAKE A LONG TIME (from about 30 minutes with defaults on a 3 GHz Pentium 4,
to perhaps an hour or many depending on your system and on whether
you enabled extra packages in your buildroot configuration).

Wait patiently for the build to complete. This builds an entire toolchain
as well as some basic packages, and constructs a root filesystem.
It might build many more packages if you selected them earlier with menuconfig.

==== If Something Goes Wrong ====

Perhaps you missed some step above and the build fails. Or you're just switching to a different processor configuration, or making some change with unknown dependencies. Either way, you'll probably need to fix the error and/or make the change, and redo the whole build. The above <tt>make</tt> command usually works fine if you
just added a package using menuconfig, but otherwise does not check many dependencies, so it will usually NOT rebuild things that depend on whatever you have fixed or changed. Here's one way to retry the make from scratch without having to wipe out the <tt>buildroot</tt> directory tree completely and start again from the git cloning.

$ '''rm -rf *build_xtensa* binaries'''
$ '''make'''

It is not necessary to empty the 'dl' subdirectory, which contains tarballs downloaded from the Internet, nor the .config file, which contains the buildroot configuration. Customizations to the uClibc and <tt>busybox</tt> configurations should have ended up getting saved in target/xtensa/uClibc.config and target/xtensa/busybox-config, respectively, so hopefully are preserved by the above sequence.

== Build and Run a Linux Kernel on the XTAV60, AXAV110, or XTAV200 Boards ==

References to the ''XTAV60 board'' refer to the combination of
the Avnet [http://www.em.avnet.com/tensilica1 LX60 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX60 (XT-AV60) Board User's Guide''.

Similarly, references to the ''XTAV200 board'' refers the combination of
the Avnet [http://www.em.avnet.com/tensilica2 LX200 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX200 (XT-AV200) Board User's Guide''.

=== Configure the kernel ===

The kernel build is a two-step process: configure the kernel, and build it.
First, before we can do anything with the kernel, set your PATH to
point to the toolchain built using buildroot.

$ '''export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"'''

where ''<cname>'' is the name of the Xtensa processor configuration you selected
when building the toolchain (e.g., <code>dc232b</code>).

Now setup a destination for kernel builds.
We usually like to have the build directory separate from
the source directory, so we use 'O=</destination/path>' in
kernel make commands. If you'll be routinely building multiple
configurations of the Linux kernel, it's good to have some
naming conventions for the build directory. For example,
to experiment with multiple target platforms but only one
processor configuration, we include just the platform name here:

$'''mkdir build-xtav60'''

Let's start with the default kernel configuration for the Avnet board
(which works on both XTAV60 (LX60), XTAV110 (LX110), and XTAV200 (LX200) boards)
as follows:

$ '''cd linux'''
$ '''make O=../build-xtav60 ARCH=xtensa KBUILD_DEFCONFIG=lx60_defconfig defconfig'''

This configures the kernel using the default configuration found in
'''arch/xtensa/configs/lx60_defconfig'''.

'''NOTE:''' This kernel configuration has nothing to do with Xtensa
processor configuration. That comes next.

Let's now customize this a little bit to select the correct Xtensa processor
configuration, and to bundle the root filesystem into the kernel:

$ '''make O=../build-xtav60 ARCH=xtensa menuconfig'''

Under '''General setup''',
make sure the '''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is enabled. Underneath that, edit '''Initramfs source file(s)''',
and enter the path to the cpio formatted root filesystem
generated by buildroot:

''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio.gz

(Don't forget to replace ''<workdir>'' with the appropriate full path
and ''<cname>'' with your Xtensa processor configuration name.)

Under '''Processor type and features''',
make sure the '''Xtensa Processor Configuration''' is correct and matches
the processor configuration name you used to build the toolchain with buildroot
(for example, ''dc232b'' for Diamond 232L Rev.B).
The kernel build selects a toolchain and processor variant specific headers
based on this selection.
If the desired processor configuration does not appear explicitly in the list,
simply select '''Custom Xtensa processor configuration''' and enter the
processor configuration name (all lowercase) into the next menu parameter,
'''Xtensa Processor Custom Variant Name'''.

Back in the main menu, under '''Platform options''', make sure the
'''CPU clock rate''' entry is set correctly according to the following table:

{| border="1" style="text-align:center; margin: 1em auto 1em auto"
|-
! Board !! Frequency selected in XPG (MHz) !! ''CPU clock rate'' setting (kHz)
|-
|rowspan="3"| XTAV60 (LX60)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV110 (LX110)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV200 (LX200)
| 30 || 31250
|-
| 40 || 41667
|-
| 50 || 50000
|-
|}

Exit menuconfig, saving your configuration changes.

Backup your configuration outside the build directory. For example:

$ '''cp ../build-xtav60/.config config.xtav60.saved'''

If you do a clean rebuild of the kernel (e.g., "rm -rf ../build-xtav60")
you can now configure it with simply:
$ '''mkdir ../build-xtav60 ; cp config.xtav60.saved ../build-xtav60/.config'''
Of course if you update the kernel, you'll probably again have to do:
$ '''make O=../build-xtav60 ARCH=xtensa menuconfig'''
and save a new copy of your configuration.

=== Build the kernel ===

$ '''make O=../build-xtav60 ARCH=xtensa'''

The build will issue a few warnings which are normal.
Once complete, the bootable image is in:
<workdir>/build-xtav60/arch/xtensa/boot/Image.elf
and the uncompressed ELF file containing kernel symbols is in:
<workdir>/build-xtav60/vmlinux
There is also a RedBoot bootable image (if you use RedBoot) in:
<workdir>/build-xtav60/arch/xtensa/boot/zImage.redboot

=== Install Xtensa Tools for the selected core ===

If you opt to download the kernel over OCD, you need <tt>xt-gdb</tt>
which is part of Tensilica's Xtensa Tools package. This must be obtained
from Tensilica, and is not the same toolchain as built by buildroot.
You also need to install the corresponding Tensilica core package,
so that the Xtensa Tools know about your particular configured
Tensilica core.

The toolchain built using buildroot can be configured to
include GDB, but that version of GDB does not support
communicating with Tensilica's Xtensa OCD Daemon, and
thus cannot be used to download the kernel over OCD.

In this example, it is assumed that the machine hosting the
Xtensa Tools has access to the <workdir> directory tree.

=== Install and setup the Xtensa OCD Daemon ===

Setup and connect your JTAG probe, etc.

=== Connect a terminal server ===

At 38400 bps 8N1 no flow control to the XTAV60 serial port.

=== Optionally, setup networking ===

This step is optional.

Setup the board's MAC address using dipswitches
(see XTAV60 or XTAV200 board docs as appropriate)
and connect the board to a network that has a
DHCP server that will respond to that MAC address.
If you don't do this step, you'll simply not have network
access, and the boot process will take a minute or so longer
while the kernel times out waiting for a BOOTP response.
You can edit the kernel configuration and rebuild the kernel
to avoid using bootp (in particular, remove "ip=bootp" from
the kernel cmdline).

=== Download and run the kernel ===

Reset the board (see board documentation).

Using Xtensa Tools, invoke:

$ '''xt-gdb <workdir>/build-xtav60/arch/xtensa/boot/Image.elf'''

'''(xt-gdb) target remote <ocdhost>:20000 0'''
'''(xt-gdb) reset'''
'''(xt-gdb) load'''
'''(xt-gdb) set $pc = &_ResetVector'''
'''(xt-gdb) symbol-file <workdir>/build-xtav60/vmlinux'''
'''(xt-gdb) c'''

where <ocdhost> is the IP address or DNS name of the machine
running the Xtensa OCD daemon. The Linux kernel should
start booting as soon as 'c' (continue) is executed.

You should eventually get a login prompt.
Just login as root (no password).

Try various Linux commands. Look at <tt>/bin</tt>,
<tt>/sbin</tt>, <tt>/usr/bin</tt>, etc to see what's available.

'''Note:''' no need to setup an NFS or TFTP server. The filesystem
is contained within the kernel image. You may be able to mount
other filesystems over NFS though, if you wish, after booting.

=== Mounting the Root Filesystem Over NFS ===

If you build more than the minimal set of packages using
buildroot, the root filesystem can easily grow too large to
fit comfortably (or at all) inside the kernel. In this case,
rather than follow the instructions exactly as above,
you'll want to mount the root filesystem over NFS.

You may also want to mount the root filesystem over NFS to
make changes to the filesystem persistent across runs and
accessible from your development host.

First you need to install the root filesystem generated
using buildroot, to a machine that can serve it over NFS.
Assuming this machine runs Linux, one way to install it is
as follows:

$ '''mkdir ''<exportpath>'' '''
$ '''cd ''<exportpath>'' '''
$ '''sudo cpio -i -d -m -F ''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio --no-absolute-filenames '''

You then need to enable the NFS server on your system
(if not already active), and export this filesystem.
How you do this depends on your host Linux distribution.
For example, on some Fedora releases, one might:

* add the export path to <tt>/etc/exports</tt> using a line such as

''<exportpath>'' *(rw,sync,no_root_squash,no_all_squash,no_wdelay)

* turn on the NFS server if needed:

$ '''sudo /sbin/chkconfig nfs on'''

* tell the NFS server about the new exported filesystem

$ '''sudo /usr/sbin/exportfs -a'''
$ '''sudo /usr/sbin/exportfs -r'''

Second, follow the instructions in the previous sections,
then configure the kernel again as follows.

Under '''General setup''', make sure the
'''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is disabled (rather than enabled as done in previous sections).

Under '''Platform options''', under the line '''Default bootloader kernel arguments''',
select the boot parameters line and set it to something like this:

'''console=ttyS0,38400 ip=dhcp root=/dev/nfs rw nfsroot=''<server_ip>'':''<exportpath>'' '''

where ''<server_ip>'' is the IP address of your NFS server, and ''<exportpath>''
is the exported filesystem path.

Another approach is to just specify the ip addresses directly in the CMDLINE
'''CONFIG_CMDLINE="console=ttyS0,38400 ip=192.168.11.95:192.168.11.220:192.168.11.1:255.255.255.0:HiFi-2 root=/dev/nfs rw nfsroot=192.168.11.55:/exports/LINUX_ROOT.DC_C_233L debug coredump_filter=0xff" '''${ipaddr}:${nfsroot_server}:${gatewayip}:${netmask}:${hostname}'''

Where the IP addresses are in the form:

'''${ipaddr}:${nfsroot_server}:${gatewayip}:${netmask}:${hostname}'''

Save this configuration, rebuild the kernel, and follow the
instructions in previous sections to download and run the kernel.
If everything goes well and is setup correctly, your kernel should
now boot with a root filesystem mounted over NFS.

== Build and Run a Linux Kernel on the Instruction Set Simulator (ISS) ==

You can build and run a Linux kernel in the Xtensa Instruction Set
Simulator (ISS). The following instructions have only been tried
with an ISS from the RB-2008.3 release of Xtensa Tools. Bear in
mind that the XTAV60 port is likely much more stable than the ISS port
of Linux at this point in time.

Note: Depending on your host OS version, you may need to install
Xtensa Tools on a separate machine.

=== Configure and Build the Kernel for ISS ===

Repeat all the same instructions as above for building the kernel for an
Avnet board, except that when initially configuring the kernel,
start from a ISS platform template instead. For example for the
DC233C Variant:

'''$ mkdir build-iss'''
'''$ cd linux'''
'''$ make O=../build-iss ARCH=xtensa KBUILD_DEFCONFIG=iss_dc233c_defconfig defconfig'''

The above make example configures the kernel using the default configuration found in
'''arch/xtensa/configs/iss_dc233_defconfig'''. Most important to note is that the
root file system mounted when Linux boots comes via the targets device '''/dev/simdisk0'''
which is defined in the kernel '''.config''' file. For example:

'''CONFIG_SIMDISK0_FILENAME="/export2/DC_C_233L/LINUX_ROOT.ext2"'''

The SIMDISK file name and VARIANT name are typically configured when running '''make menuconfig'''; Ex:

'''$ make O=../build-iss ARCH=xtensa menuconfig'''

and selecting

'''Xtensa Platform options''' ---> '''Host filename for a simulated device'''

and entering the pathname to the .ext2 file there. Ex: '''/export2/DC_C_233L/LINUX_ROOT.ext2'''

You often want to change the VARIANT to the one you desire, Ex: FSF. You do this via
the top level menu:

'''Xtensa Processor type and features ---> Xtensa Processor Custom Core Variant Name'''

With the new SIMDISK approach you copy the EXT2 Filesystem file generated by Buildroot
to a location to be accessed by Xtensa Linux. Ex:

'''$ cp /export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot/binaries/dc233c/rootfs.xtensa_dc233c.ext2 /export2/DC_C_233L/LINUX_ROOT.ext2'''

'''NOTE:''' There is an old '''iss_defconfig''' that tries to use a '''tuntap''' Ethernet
interface that currently isn't supported.
Previously with this old iss_defconfig using the '''tuntap''' Ethernet interface
it was suggested to set up the initramfs filesystem, and do the following.
Under '''Bus Options''', deselect '''PCI support'''.
Under '''Platform Options''', deselect '''Default bootloader kernel arguments'''.
Hopefully we will someday be able to support the use of a network interface with
ISS simulation and then be able to mount NFS root partitions again. So I'm leaving
this note for future exploration of this mechanism; Hope you don't mind the clutter.

Continue configuring and building the kernel as usual.

=== Run the Kernel on ISS ===

Using Xtensa Tools, invoke:

'''$ xt-gdb <workdir>/build-iss/arch/xtensa/boot/Image.elf'''
'''(xt-gdb) target sim --turbo --memlimit=128'''
'''(xt-gdb) symbol-file <workdir>/build-iss/vmlinux'''
'''(xt-gdb) run'''

Wait patiently while Linux boots ... (maybe a minute). The setting of the '''memlimit'''
needs to match the PLATFORM_DEFAULT_MEM_SIZE defined in /arch/xtensa/platforms/iss/include/platform/hardware.h.
Currently this limit us 128 MegaBytes:

#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000 /* 13,4217,728 128M */

and we will be extending this for the DC233L to take advantage of it's V3 MMU.

Login as root (no password).

'''Note:''' Input via ISS is cooked, so everything typed gets echoed.
Also, time as reported by the kernel does not progress
according to true wall-clock time: it currently depends on
a simulated processor clock, which advances at various speeds
according to load.

Instructions for building and booting Linux

2011-01-06T05:35:41Z

Piet: /* Download buildroot and the Linux kernel */

These instructions explain how to build a toolchain, root filesystem and kernel for Linux running on an Xtensa processor. These instructions apply specifically to the XTAV60 (LX60) board.

Some general notes on these instructions:

* They are a work in progress. If you are using the latest development sources, the build process may change, so you should be sure to get the latest version of this document at [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions]. If you are using one of the development snapshot releases, you should use the version of the build instructions included with that snapshot.

* The following was tested on x86 machines running RedHat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3). It is expected to work on newer Fedora releases (e.g., was tested on FC6) but to maintain host compatibility with Xtensa Tools, it is best to avoid Fedora releases beyond FC5. Other host distributions likely work but have not been tested.
** '''NOTE:''' this assumes the default selection of packages in buildroot. Selecting extra packages may require a more recent host OS or more recent version of certain tools. For example, the default version of <tt>find</tt> on RHEL4 is too old to allow building all X11 packages in buildroot, so it is necessary to upgrade the host version of <tt>findutils</tt> on RHEL4 to build these packages.

* Lines prefixed with "sudo" need to be executed as root. The rest is best executed as a non-root user. (It is possible to install <tt>git</tt> as a non-root user if root access is an issue. How to do this isn't shown here.)

* Lines that set environment variables assume a Bourne compatible shell (e.g., /bin/sh or bash), but are easily adapted to other shells.

* Instructions are assumed executed all in order (e.g., commands assume current directory and environment variables set earlier).

== Setup your host system ==

If you are using one of the snapshot releases, you can skip this step.

If you want to work with the latest development sources, you will need
[[Installing GIT|<tt>git</tt> installed on your system]].

== Download buildroot and the Linux kernel ==

The following section describes how to download the latest
versions of buildroot and of the Linux kernel.
Skip this step if you are using one of the
[http://wiki.linux-xtensa.org/index.php/Buildroot_Snapshots snapshot releases].

Adventurous users that want to use the '''bleeding edge''' code can execute the following:

'''$ cd <workdir>'''
'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa.git buildroot'''
'''$ git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git linux'''

where <tt><workdir></tt> is the path to an empty directory on a disk with
at least 4 GB available space. You end up with the following file structure,
which is assumed by the rest of this document:

<workdir>/
/buildroot
/linux

The MASTER branch of the buildroot repository is often is a state of development.
It's recommended to use the last snapshot for application developers. In the
case of the Avnet development boards a 'snapshot_2+SMP' branch is recommended
in the currently experimental SMP git repository:

'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

If you happen to have write access to either repository you should change '''git:''' to '''git+ssh:'''
For Example:

'''$ git clone git+ssh://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

For more details, see the [http://wiki.linux-xtensa.org/index.php/Repository_Access repository access] page.

== Install any required processor specific overlay ==

This step is required if you are targeting a custom Xtensa processor.
If you use a Diamond 232L Standard Core, you can skip this step.

To configure buildroot and the kernel to use a custom Xtensa processor
configuration, you need to overlay a set of files customized for your
processor configuration onto toolchain sources (gcc, binutils, gdb, etc)
and the Linux kernel. This process has been automated using a script
located in the buildroot source tree.
For usage information, you can invoke it without arguments:

'''$ cd <workdir>'''
'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install'''

which displays a help message similar to the following:

xt-buildroot-overlay-install version 1.3
Usage: xt-buildroot-overlay-install <parameters> [<options>]
Where <parameters> are:
-t file.tgz Specify path to the Xtensa Linux overlay tarball, typically
<xtensa_root>/src/xtensa-config-overlay.tar.gz
-b dir Path to the base of the buildroot source tree, in which
package specific overlay tarballs get installed.
-k dir Path to the base of the Linux kernel source tree, in which
the Linux kernel specific overlay gets installed.
-c config_name Name for the Xtensa processor configuration as it will be
known to the open source community. Must be a lowercase
identifier, starting with a letter, consisting of letters
and numbers and underscores, not ending with underscore
and not containing consecutive underscores. For examples:
dc232b , dc232b_be , mmubasele , fsf , s5000 .
-l long_name Long name for the Xtensa processor configuration, human-
readable with spaces etc allowed (must be quoted).
For example: 'Diamond 232L Standard Core Rev.B (LE)'
Try to keep it within approximately 40 characters.
And <options> are:
-f If package specific overlay tarballs already exist in
the destination source tree, overwrite them without asking.
--help Show this usage message.

Note that the Xtensa Linux overlay tarball MUST be obtained from an Xtensa
core package built using release RB-2008.3 or later.

Here is an example invocation of the overlay installation script:

'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install -t blinkcore-config-overlay.tar.gz''' \
'''-b ./buildroot -k ./linux -c superzip -l "ChipCorp SuperZIP Blink Accelerator Core"'''

The script extracts some relevant information from the overlay tarball,
presents it along with relevant parameters to the user, and prompts
for confirmation before proceeding.

The chosen processor name (-c option) must be unique among known Xtensa processors.
It is also probably wise to avoid names confusingly similar to other (non-Xtensa) processors.
If you expect at some point to contribute support for your custom processor to the
open-source community, this name will likely be long-lived.
(One way to contribute support for a custom processor might be to submit the overlay tarball
or files to the linux-xtensa.org maintainers.)

In the steps below, buildroot and the Linux kernel must be configured
(in their respective <code>''make menuconfig''</code> steps) to select
the <code>''custom''</code> Xtensa processor option.
This presents an extra configuration menu entry where you must provide
the name of the Xtensa processor. Set it to the same name
as was specified in the <code>-c</code> option above.

== Build a toolchain and root filesystem using buildroot ==

'''Note:''' for more details on generic buildroot topics not covered in this simple how-to,
see [http://buildroot.uclibc.org/ buildroot.uclibc.org].

=== Configure buildroot ===

The first time you configure buildroot, start with defaults for your Xtensa processor:

'''$ cd <workdir>/buildroot'''
'''$ ./target/xtensa/setup-config <corename>'''

where ''<corename>'' is the overlay name of your selected Xtensa or Diamond core
(e.g., '''dc232b'''). If you omit ''<corename>'', a help message and a list
of currently installed Tensilica core overlays is displayed.

Optionally, you can then customize your buildroot configuration, such as
selecting additional packages, setting various parameters, and so on.
The following make targets provide a ''curses'' (text-based graphical) interface
for configuring buildroot, the uClibc C library, and busybox, respectively.
('''Note:''' You need the <tt>TERM</tt> environment variable properly set for
these curses based tools to work.)

'''$ make menuconfig'''
'''$ make uclibc-menuconfig'''
'''$ make busybox-menuconfig'''

=== Build buildroot ===

Just type:

'''$ make'''

THIS WILL TAKE A LONG TIME (from about 30 minutes with defaults on a 3 GHz Pentium 4,
to perhaps an hour or many depending on your system and on whether
you enabled extra packages in your buildroot configuration).

Wait patiently for the build to complete. This builds an entire toolchain
as well as some basic packages, and constructs a root filesystem.
It might build many more packages if you selected them earlier with menuconfig.

==== If Something Goes Wrong ====

Perhaps you missed some step above and the build fails. Or you're just switching to a different processor configuration, or making some change with unknown dependencies. Either way, you'll probably need to fix the error and/or make the change, and redo the whole build. The above <tt>make</tt> command usually works fine if you
just added a package using menuconfig, but otherwise does not check many dependencies, so it will usually NOT rebuild things that depend on whatever you have fixed or changed. Here's one way to retry the make from scratch without having to wipe out the <tt>buildroot</tt> directory tree completely and start again from the git cloning.

$ '''rm -rf *build_xtensa* binaries'''
$ '''make'''

It is not necessary to empty the 'dl' subdirectory, which contains tarballs downloaded from the Internet, nor the .config file, which contains the buildroot configuration. Customizations to the uClibc and <tt>busybox</tt> configurations should have ended up getting saved in target/xtensa/uClibc.config and target/xtensa/busybox-config, respectively, so hopefully are preserved by the above sequence.

== Build and Run a Linux Kernel on the XTAV60, AXAV110, or XTAV200 Boards ==

References to the ''XTAV60 board'' refer to the combination of
the Avnet [http://www.em.avnet.com/tensilica1 LX60 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX60 (XT-AV60) Board User's Guide''.

Similarly, references to the ''XTAV200 board'' refers the combination of
the Avnet [http://www.em.avnet.com/tensilica2 LX200 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX200 (XT-AV200) Board User's Guide''.

=== Configure the kernel ===

The kernel build is a two-step process: configure the kernel, and build it.
First, before we can do anything with the kernel, set your PATH to
point to the toolchain built using buildroot.

$ '''export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"'''

where ''<cname>'' is the name of the Xtensa processor configuration you selected
when building the toolchain (e.g., <code>dc232b</code>).

Now setup a destination for kernel builds.
We usually like to have the build directory separate from
the source directory, so we use 'O=</destination/path>' in
kernel make commands. If you'll be routinely building multiple
configurations of the Linux kernel, it's good to have some
naming conventions for the build directory. For example,
to experiment with multiple target platforms but only one
processor configuration, we include just the platform name here:

$'''mkdir build-xtav60'''

Let's start with the default kernel configuration for the Avnet board
(which works on both XTAV60 (LX60), XTAV110 (LX110), and XTAV200 (LX200) boards)
as follows:

$ '''cd linux'''
$ '''make O=../build-xtav60 ARCH=xtensa KBUILD_DEFCONFIG=lx60_defconfig defconfig'''

This configures the kernel using the default configuration found in
'''arch/xtensa/configs/lx60_defconfig'''.

'''NOTE:''' This kernel configuration has nothing to do with Xtensa
processor configuration. That comes next.

Let's now customize this a little bit to select the correct Xtensa processor
configuration, and to bundle the root filesystem into the kernel:

$ '''make O=../build-xtav60 ARCH=xtensa menuconfig'''

Under '''General setup''',
make sure the '''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is enabled. Underneath that, edit '''Initramfs source file(s)''',
and enter the path to the cpio formatted root filesystem
generated by buildroot:

''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio.gz

(Don't forget to replace ''<workdir>'' with the appropriate full path
and ''<cname>'' with your Xtensa processor configuration name.)

Under '''Processor type and features''',
make sure the '''Xtensa Processor Configuration''' is correct and matches
the processor configuration name you used to build the toolchain with buildroot
(for example, ''dc232b'' for Diamond 232L Rev.B).
The kernel build selects a toolchain and processor variant specific headers
based on this selection.
If the desired processor configuration does not appear explicitly in the list,
simply select '''Custom Xtensa processor configuration''' and enter the
processor configuration name (all lowercase) into the next menu parameter,
'''Xtensa Processor Custom Variant Name'''.

Back in the main menu, under '''Platform options''', make sure the
'''CPU clock rate''' entry is set correctly according to the following table:

{| border="1" style="text-align:center; margin: 1em auto 1em auto"
|-
! Board !! Frequency selected in XPG (MHz) !! ''CPU clock rate'' setting (kHz)
|-
|rowspan="3"| XTAV60 (LX60)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV110 (LX110)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV200 (LX200)
| 30 || 31250
|-
| 40 || 41667
|-
| 50 || 50000
|-
|}

Exit menuconfig, saving your configuration changes.

Backup your configuration outside the build directory. For example:

$ '''cp ../build-xtav60/.config config.xtav60.saved'''

If you do a clean rebuild of the kernel (e.g., "rm -rf ../build-xtav60")
you can now configure it with simply:
$ '''mkdir ../build-xtav60 ; cp config.xtav60.saved ../build-xtav60/.config'''
Of course if you update the kernel, you'll probably again have to do:
$ '''make O=../build-xtav60 ARCH=xtensa menuconfig'''
and save a new copy of your configuration.

=== Build the kernel ===

$ '''make O=../build-xtav60 ARCH=xtensa'''

The build will issue a few warnings which are normal.
Once complete, the bootable image is in:
<workdir>/build-xtav60/arch/xtensa/boot/Image.elf
and the uncompressed ELF file containing kernel symbols is in:
<workdir>/build-xtav60/vmlinux
There is also a RedBoot bootable image (if you use RedBoot) in:
<workdir>/build-xtav60/arch/xtensa/boot/zImage.redboot

=== Install Xtensa Tools for the selected core ===

If you opt to download the kernel over OCD, you need <tt>xt-gdb</tt>
which is part of Tensilica's Xtensa Tools package. This must be obtained
from Tensilica, and is not the same toolchain as built by buildroot.
You also need to install the corresponding Tensilica core package,
so that the Xtensa Tools know about your particular configured
Tensilica core.

The toolchain built using buildroot can be configured to
include GDB, but that version of GDB does not support
communicating with Tensilica's Xtensa OCD Daemon, and
thus cannot be used to download the kernel over OCD.

In this example, it is assumed that the machine hosting the
Xtensa Tools has access to the <workdir> directory tree.

=== Install and setup the Xtensa OCD Daemon ===

Setup and connect your JTAG probe, etc.

=== Connect a terminal server ===

At 38400 bps 8N1 no flow control to the XTAV60 serial port.

=== Optionally, setup networking ===

This step is optional.

Setup the board's MAC address using dipswitches
(see XTAV60 or XTAV200 board docs as appropriate)
and connect the board to a network that has a
DHCP server that will respond to that MAC address.
If you don't do this step, you'll simply not have network
access, and the boot process will take a minute or so longer
while the kernel times out waiting for a BOOTP response.
You can edit the kernel configuration and rebuild the kernel
to avoid using bootp (in particular, remove "ip=bootp" from
the kernel cmdline).

=== Download and run the kernel ===

Reset the board (see board documentation).

Using Xtensa Tools, invoke:

$ '''xt-gdb <workdir>/build-xtav60/arch/xtensa/boot/Image.elf'''

'''(xt-gdb) target remote <ocdhost>:20000 0'''
'''(xt-gdb) reset'''
'''(xt-gdb) load'''
'''(xt-gdb) set $pc = &_ResetVector'''
'''(xt-gdb) symbol-file <workdir>/build-xtav60/vmlinux'''
'''(xt-gdb) c'''

where <ocdhost> is the IP address or DNS name of the machine
running the Xtensa OCD daemon. The Linux kernel should
start booting as soon as 'c' (continue) is executed.

You should eventually get a login prompt.
Just login as root (no password).

Try various Linux commands. Look at <tt>/bin</tt>,
<tt>/sbin</tt>, <tt>/usr/bin</tt>, etc to see what's available.

'''Note:''' no need to setup an NFS or TFTP server. The filesystem
is contained within the kernel image. You may be able to mount
other filesystems over NFS though, if you wish, after booting.

=== Mounting the Root Filesystem Over NFS ===

If you build more than the minimal set of packages using
buildroot, the root filesystem can easily grow too large to
fit comfortably (or at all) inside the kernel. In this case,
rather than follow the instructions exactly as above,
you'll want to mount the root filesystem over NFS.

You may also want to mount the root filesystem over NFS to
make changes to the filesystem persistent across runs and
accessible from your development host.

First you need to install the root filesystem generated
using buildroot, to a machine that can serve it over NFS.
Assuming this machine runs Linux, one way to install it is
as follows:

$ '''mkdir ''<exportpath>'' '''
$ '''cd ''<exportpath>'' '''
$ '''sudo cpio -i -d -m -F ''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio --no-absolute-filenames '''

You then need to enable the NFS server on your system
(if not already active), and export this filesystem.
How you do this depends on your host Linux distribution.
For example, on some Fedora releases, one might:

* add the export path to <tt>/etc/exports</tt> using a line such as

''<exportpath>'' *(rw,sync,no_root_squash,no_all_squash)

* turn on the NFS server if needed:

$ '''sudo /sbin/chkconfig nfs on'''

* tell the NFS server about the new exported filesystem

$ '''sudo /usr/sbin/exportfs -a'''
$ '''sudo /usr/sbin/exportfs -r'''

Second, follow the instructions in the previous sections,
then configure the kernel again as follows.

Under '''General setup''', make sure the
'''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is disabled (rather than enabled as done in previous sections).

Under '''Platform options''', under the line '''Default bootloader kernel arguments''',
select the boot parameters line and set it to something like this:

'''console=ttyS0,38400 ip=dhcp root=/dev/nfs rw nfsroot=''<server_ip>'':''<exportpath>'' '''

where ''<server_ip>'' is the IP address of your NFS server, and ''<exportpath>''
is the exported filesystem path.

Another approach is to just specify the ip addresses directly in the CMDLINE
'''CONFIG_CMDLINE="console=ttyS0,38400 ip=192.168.11.95:192.168.11.220:192.168.11.1:255.255.255.0:HiFi-2 root=/dev/nfs rw nfsroot=192.168.11.55:/exports/LINUX_ROOT.DC_C_233L debug coredump_filter=0xff" '''${ipaddr}:${nfsroot_server}:${gatewayip}:${netmask}:${hostname}'''

Where the IP addresses are in the form:

'''${ipaddr}:${nfsroot_server}:${gatewayip}:${netmask}:${hostname}'''

Save this configuration, rebuild the kernel, and follow the
instructions in previous sections to download and run the kernel.
If everything goes well and is setup correctly, your kernel should
now boot with a root filesystem mounted over NFS.

== Build and Run a Linux Kernel on the Instruction Set Simulator (ISS) ==

You can build and run a Linux kernel in the Xtensa Instruction Set
Simulator (ISS). The following instructions have only been tried
with an ISS from the RB-2008.3 release of Xtensa Tools. Bear in
mind that the XTAV60 port is likely much more stable than the ISS port
of Linux at this point in time.

Note: Depending on your host OS version, you may need to install
Xtensa Tools on a separate machine.

=== Configure and Build the Kernel for ISS ===

Repeat all the same instructions as above for building the kernel for an
Avnet board, except that when initially configuring the kernel,
start from a ISS platform template instead. For example for the
DC233C Variant:

'''$ mkdir build-iss'''
'''$ cd linux'''
'''$ make O=../build-iss ARCH=xtensa KBUILD_DEFCONFIG=iss_dc233c_defconfig defconfig'''

The above make example configures the kernel using the default configuration found in
'''arch/xtensa/configs/iss_dc233_defconfig'''. Most important to note is that the
root file system mounted when Linux boots comes via the targets device '''/dev/simdisk0'''
which is defined in the kernel '''.config''' file. For example:

'''CONFIG_SIMDISK0_FILENAME="/export2/DC_C_233L/LINUX_ROOT.ext2"'''

The SIMDISK file name and VARIANT name are typically configured when running '''make menuconfig'''; Ex:

'''$ make O=../build-iss ARCH=xtensa menuconfig'''

and selecting

'''Xtensa Platform options''' ---> '''Host filename for a simulated device'''

and entering the pathname to the .ext2 file there. Ex: '''/export2/DC_C_233L/LINUX_ROOT.ext2'''

You often want to change the VARIANT to the one you desire, Ex: FSF. You do this via
the top level menu:

'''Xtensa Processor type and features ---> Xtensa Processor Custom Core Variant Name'''

With the new SIMDISK approach you copy the EXT2 Filesystem file generated by Buildroot
to a location to be accessed by Xtensa Linux. Ex:

'''$ cp /export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot/binaries/dc233c/rootfs.xtensa_dc233c.ext2 /export2/DC_C_233L/LINUX_ROOT.ext2'''

'''NOTE:''' There is an old '''iss_defconfig''' that tries to use a '''tuntap''' Ethernet
interface that currently isn't supported.
Previously with this old iss_defconfig using the '''tuntap''' Ethernet interface
it was suggested to set up the initramfs filesystem, and do the following.
Under '''Bus Options''', deselect '''PCI support'''.
Under '''Platform Options''', deselect '''Default bootloader kernel arguments'''.
Hopefully we will someday be able to support the use of a network interface with
ISS simulation and then be able to mount NFS root partitions again. So I'm leaving
this note for future exploration of this mechanism; Hope you don't mind the clutter.

Continue configuring and building the kernel as usual.

=== Run the Kernel on ISS ===

Using Xtensa Tools, invoke:

'''$ xt-gdb <workdir>/build-iss/arch/xtensa/boot/Image.elf'''
'''(xt-gdb) target sim --turbo --memlimit=128'''
'''(xt-gdb) symbol-file <workdir>/build-iss/vmlinux'''
'''(xt-gdb) run'''

Wait patiently while Linux boots ... (maybe a minute). The setting of the '''memlimit'''
needs to match the PLATFORM_DEFAULT_MEM_SIZE defined in /arch/xtensa/platforms/iss/include/platform/hardware.h.
Currently this limit us 128 MegaBytes:

#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000 /* 13,4217,728 128M */

and we will be extending this for the DC233L to take advantage of it's V3 MMU.

Login as root (no password).

'''Note:''' Input via ISS is cooked, so everything typed gets echoed.
Also, time as reported by the kernel does not progress
according to true wall-clock time: it currently depends on
a simulated processor clock, which advances at various speeds
according to load.

Instructions for building and booting Linux

2011-01-06T05:32:27Z

Piet: /* Mounting the Root Filesystem Over NFS */

These instructions explain how to build a toolchain, root filesystem and kernel for Linux running on an Xtensa processor. These instructions apply specifically to the XTAV60 (LX60) board.

Some general notes on these instructions:

* They are a work in progress. If you are using the latest development sources, the build process may change, so you should be sure to get the latest version of this document at [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions]. If you are using one of the development snapshot releases, you should use the version of the build instructions included with that snapshot.

* The following was tested on x86 machines running RedHat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3). It is expected to work on newer Fedora releases (e.g., was tested on FC6) but to maintain host compatibility with Xtensa Tools, it is best to avoid Fedora releases beyond FC5. Other host distributions likely work but have not been tested.
** '''NOTE:''' this assumes the default selection of packages in buildroot. Selecting extra packages may require a more recent host OS or more recent version of certain tools. For example, the default version of <tt>find</tt> on RHEL4 is too old to allow building all X11 packages in buildroot, so it is necessary to upgrade the host version of <tt>findutils</tt> on RHEL4 to build these packages.

* Lines prefixed with "sudo" need to be executed as root. The rest is best executed as a non-root user. (It is possible to install <tt>git</tt> as a non-root user if root access is an issue. How to do this isn't shown here.)

* Lines that set environment variables assume a Bourne compatible shell (e.g., /bin/sh or bash), but are easily adapted to other shells.

* Instructions are assumed executed all in order (e.g., commands assume current directory and environment variables set earlier).

== Setup your host system ==

If you are using one of the snapshot releases, you can skip this step.

If you want to work with the latest development sources, you will need
[[Installing GIT|<tt>git</tt> installed on your system]].

== Download buildroot and the Linux kernel ==

The following section describes how to download the latest
versions of buildroot and of the Linux kernel.
Skip this step if you are using one of the
[http://wiki.linux-xtensa.org/index.php/Buildroot_Snapshots snapshot releases].

Adventurous users that want the use the '''bleeding edge''' code should execute the following:

'''$ cd <workdir>'''
'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa.git buildroot'''
'''$ git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git linux'''

where <tt><workdir></tt> is the path to an empty directory on a disk with
at least 4 GB available space. You end up with the following file structure,
which is assumed by the rest of this document:

<workdir>/
/buildroot
/linux

The MASTER branch of the buildroot repository is often is a state of development.
It's recommended to use the last snapshot for application developers. In the
case of the Avnet development boards a 'snapshot_2+SMP' branch is recommended
in the currently experimental SMP git repository:

'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

If you happen to have write access to either repository you should change '''git:''' to '''git+ssh:'''
For Example:

'''$ git clone git+ssh://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

For more details, see the [http://wiki.linux-xtensa.org/index.php/Repository_Access repository access] page.

== Install any required processor specific overlay ==

This step is required if you are targeting a custom Xtensa processor.
If you use a Diamond 232L Standard Core, you can skip this step.

To configure buildroot and the kernel to use a custom Xtensa processor
configuration, you need to overlay a set of files customized for your
processor configuration onto toolchain sources (gcc, binutils, gdb, etc)
and the Linux kernel. This process has been automated using a script
located in the buildroot source tree.
For usage information, you can invoke it without arguments:

'''$ cd <workdir>'''
'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install'''

which displays a help message similar to the following:

xt-buildroot-overlay-install version 1.3
Usage: xt-buildroot-overlay-install <parameters> [<options>]
Where <parameters> are:
-t file.tgz Specify path to the Xtensa Linux overlay tarball, typically
<xtensa_root>/src/xtensa-config-overlay.tar.gz
-b dir Path to the base of the buildroot source tree, in which
package specific overlay tarballs get installed.
-k dir Path to the base of the Linux kernel source tree, in which
the Linux kernel specific overlay gets installed.
-c config_name Name for the Xtensa processor configuration as it will be
known to the open source community. Must be a lowercase
identifier, starting with a letter, consisting of letters
and numbers and underscores, not ending with underscore
and not containing consecutive underscores. For examples:
dc232b , dc232b_be , mmubasele , fsf , s5000 .
-l long_name Long name for the Xtensa processor configuration, human-
readable with spaces etc allowed (must be quoted).
For example: 'Diamond 232L Standard Core Rev.B (LE)'
Try to keep it within approximately 40 characters.
And <options> are:
-f If package specific overlay tarballs already exist in
the destination source tree, overwrite them without asking.
--help Show this usage message.

Note that the Xtensa Linux overlay tarball MUST be obtained from an Xtensa
core package built using release RB-2008.3 or later.

Here is an example invocation of the overlay installation script:

'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install -t blinkcore-config-overlay.tar.gz''' \
'''-b ./buildroot -k ./linux -c superzip -l "ChipCorp SuperZIP Blink Accelerator Core"'''

The script extracts some relevant information from the overlay tarball,
presents it along with relevant parameters to the user, and prompts
for confirmation before proceeding.

The chosen processor name (-c option) must be unique among known Xtensa processors.
It is also probably wise to avoid names confusingly similar to other (non-Xtensa) processors.
If you expect at some point to contribute support for your custom processor to the
open-source community, this name will likely be long-lived.
(One way to contribute support for a custom processor might be to submit the overlay tarball
or files to the linux-xtensa.org maintainers.)

In the steps below, buildroot and the Linux kernel must be configured
(in their respective <code>''make menuconfig''</code> steps) to select
the <code>''custom''</code> Xtensa processor option.
This presents an extra configuration menu entry where you must provide
the name of the Xtensa processor. Set it to the same name
as was specified in the <code>-c</code> option above.

== Build a toolchain and root filesystem using buildroot ==

'''Note:''' for more details on generic buildroot topics not covered in this simple how-to,
see [http://buildroot.uclibc.org/ buildroot.uclibc.org].

=== Configure buildroot ===

The first time you configure buildroot, start with defaults for your Xtensa processor:

'''$ cd <workdir>/buildroot'''
'''$ ./target/xtensa/setup-config <corename>'''

where ''<corename>'' is the overlay name of your selected Xtensa or Diamond core
(e.g., '''dc232b'''). If you omit ''<corename>'', a help message and a list
of currently installed Tensilica core overlays is displayed.

Optionally, you can then customize your buildroot configuration, such as
selecting additional packages, setting various parameters, and so on.
The following make targets provide a ''curses'' (text-based graphical) interface
for configuring buildroot, the uClibc C library, and busybox, respectively.
('''Note:''' You need the <tt>TERM</tt> environment variable properly set for
these curses based tools to work.)

'''$ make menuconfig'''
'''$ make uclibc-menuconfig'''
'''$ make busybox-menuconfig'''

=== Build buildroot ===

Just type:

'''$ make'''

THIS WILL TAKE A LONG TIME (from about 30 minutes with defaults on a 3 GHz Pentium 4,
to perhaps an hour or many depending on your system and on whether
you enabled extra packages in your buildroot configuration).

Wait patiently for the build to complete. This builds an entire toolchain
as well as some basic packages, and constructs a root filesystem.
It might build many more packages if you selected them earlier with menuconfig.

==== If Something Goes Wrong ====

Perhaps you missed some step above and the build fails. Or you're just switching to a different processor configuration, or making some change with unknown dependencies. Either way, you'll probably need to fix the error and/or make the change, and redo the whole build. The above <tt>make</tt> command usually works fine if you
just added a package using menuconfig, but otherwise does not check many dependencies, so it will usually NOT rebuild things that depend on whatever you have fixed or changed. Here's one way to retry the make from scratch without having to wipe out the <tt>buildroot</tt> directory tree completely and start again from the git cloning.

$ '''rm -rf *build_xtensa* binaries'''
$ '''make'''

It is not necessary to empty the 'dl' subdirectory, which contains tarballs downloaded from the Internet, nor the .config file, which contains the buildroot configuration. Customizations to the uClibc and <tt>busybox</tt> configurations should have ended up getting saved in target/xtensa/uClibc.config and target/xtensa/busybox-config, respectively, so hopefully are preserved by the above sequence.

== Build and Run a Linux Kernel on the XTAV60, AXAV110, or XTAV200 Boards ==

References to the ''XTAV60 board'' refer to the combination of
the Avnet [http://www.em.avnet.com/tensilica1 LX60 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX60 (XT-AV60) Board User's Guide''.

Similarly, references to the ''XTAV200 board'' refers the combination of
the Avnet [http://www.em.avnet.com/tensilica2 LX200 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX200 (XT-AV200) Board User's Guide''.

=== Configure the kernel ===

The kernel build is a two-step process: configure the kernel, and build it.
First, before we can do anything with the kernel, set your PATH to
point to the toolchain built using buildroot.

$ '''export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"'''

where ''<cname>'' is the name of the Xtensa processor configuration you selected
when building the toolchain (e.g., <code>dc232b</code>).

Now setup a destination for kernel builds.
We usually like to have the build directory separate from
the source directory, so we use 'O=</destination/path>' in
kernel make commands. If you'll be routinely building multiple
configurations of the Linux kernel, it's good to have some
naming conventions for the build directory. For example,
to experiment with multiple target platforms but only one
processor configuration, we include just the platform name here:

$'''mkdir build-xtav60'''

Let's start with the default kernel configuration for the Avnet board
(which works on both XTAV60 (LX60), XTAV110 (LX110), and XTAV200 (LX200) boards)
as follows:

$ '''cd linux'''
$ '''make O=../build-xtav60 ARCH=xtensa KBUILD_DEFCONFIG=lx60_defconfig defconfig'''

This configures the kernel using the default configuration found in
'''arch/xtensa/configs/lx60_defconfig'''.

'''NOTE:''' This kernel configuration has nothing to do with Xtensa
processor configuration. That comes next.

Let's now customize this a little bit to select the correct Xtensa processor
configuration, and to bundle the root filesystem into the kernel:

$ '''make O=../build-xtav60 ARCH=xtensa menuconfig'''

Under '''General setup''',
make sure the '''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is enabled. Underneath that, edit '''Initramfs source file(s)''',
and enter the path to the cpio formatted root filesystem
generated by buildroot:

''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio.gz

(Don't forget to replace ''<workdir>'' with the appropriate full path
and ''<cname>'' with your Xtensa processor configuration name.)

Under '''Processor type and features''',
make sure the '''Xtensa Processor Configuration''' is correct and matches
the processor configuration name you used to build the toolchain with buildroot
(for example, ''dc232b'' for Diamond 232L Rev.B).
The kernel build selects a toolchain and processor variant specific headers
based on this selection.
If the desired processor configuration does not appear explicitly in the list,
simply select '''Custom Xtensa processor configuration''' and enter the
processor configuration name (all lowercase) into the next menu parameter,
'''Xtensa Processor Custom Variant Name'''.

Back in the main menu, under '''Platform options''', make sure the
'''CPU clock rate''' entry is set correctly according to the following table:

{| border="1" style="text-align:center; margin: 1em auto 1em auto"
|-
! Board !! Frequency selected in XPG (MHz) !! ''CPU clock rate'' setting (kHz)
|-
|rowspan="3"| XTAV60 (LX60)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV110 (LX110)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV200 (LX200)
| 30 || 31250
|-
| 40 || 41667
|-
| 50 || 50000
|-
|}

Exit menuconfig, saving your configuration changes.

Backup your configuration outside the build directory. For example:

$ '''cp ../build-xtav60/.config config.xtav60.saved'''

If you do a clean rebuild of the kernel (e.g., "rm -rf ../build-xtav60")
you can now configure it with simply:
$ '''mkdir ../build-xtav60 ; cp config.xtav60.saved ../build-xtav60/.config'''
Of course if you update the kernel, you'll probably again have to do:
$ '''make O=../build-xtav60 ARCH=xtensa menuconfig'''
and save a new copy of your configuration.

=== Build the kernel ===

$ '''make O=../build-xtav60 ARCH=xtensa'''

The build will issue a few warnings which are normal.
Once complete, the bootable image is in:
<workdir>/build-xtav60/arch/xtensa/boot/Image.elf
and the uncompressed ELF file containing kernel symbols is in:
<workdir>/build-xtav60/vmlinux
There is also a RedBoot bootable image (if you use RedBoot) in:
<workdir>/build-xtav60/arch/xtensa/boot/zImage.redboot

=== Install Xtensa Tools for the selected core ===

If you opt to download the kernel over OCD, you need <tt>xt-gdb</tt>
which is part of Tensilica's Xtensa Tools package. This must be obtained
from Tensilica, and is not the same toolchain as built by buildroot.
You also need to install the corresponding Tensilica core package,
so that the Xtensa Tools know about your particular configured
Tensilica core.

The toolchain built using buildroot can be configured to
include GDB, but that version of GDB does not support
communicating with Tensilica's Xtensa OCD Daemon, and
thus cannot be used to download the kernel over OCD.

In this example, it is assumed that the machine hosting the
Xtensa Tools has access to the <workdir> directory tree.

=== Install and setup the Xtensa OCD Daemon ===

Setup and connect your JTAG probe, etc.

=== Connect a terminal server ===

At 38400 bps 8N1 no flow control to the XTAV60 serial port.

=== Optionally, setup networking ===

This step is optional.

Setup the board's MAC address using dipswitches
(see XTAV60 or XTAV200 board docs as appropriate)
and connect the board to a network that has a
DHCP server that will respond to that MAC address.
If you don't do this step, you'll simply not have network
access, and the boot process will take a minute or so longer
while the kernel times out waiting for a BOOTP response.
You can edit the kernel configuration and rebuild the kernel
to avoid using bootp (in particular, remove "ip=bootp" from
the kernel cmdline).

=== Download and run the kernel ===

Reset the board (see board documentation).

Using Xtensa Tools, invoke:

$ '''xt-gdb <workdir>/build-xtav60/arch/xtensa/boot/Image.elf'''

'''(xt-gdb) target remote <ocdhost>:20000 0'''
'''(xt-gdb) reset'''
'''(xt-gdb) load'''
'''(xt-gdb) set $pc = &_ResetVector'''
'''(xt-gdb) symbol-file <workdir>/build-xtav60/vmlinux'''
'''(xt-gdb) c'''

where <ocdhost> is the IP address or DNS name of the machine
running the Xtensa OCD daemon. The Linux kernel should
start booting as soon as 'c' (continue) is executed.

You should eventually get a login prompt.
Just login as root (no password).

Try various Linux commands. Look at <tt>/bin</tt>,
<tt>/sbin</tt>, <tt>/usr/bin</tt>, etc to see what's available.

'''Note:''' no need to setup an NFS or TFTP server. The filesystem
is contained within the kernel image. You may be able to mount
other filesystems over NFS though, if you wish, after booting.

=== Mounting the Root Filesystem Over NFS ===

If you build more than the minimal set of packages using
buildroot, the root filesystem can easily grow too large to
fit comfortably (or at all) inside the kernel. In this case,
rather than follow the instructions exactly as above,
you'll want to mount the root filesystem over NFS.

You may also want to mount the root filesystem over NFS to
make changes to the filesystem persistent across runs and
accessible from your development host.

First you need to install the root filesystem generated
using buildroot, to a machine that can serve it over NFS.
Assuming this machine runs Linux, one way to install it is
as follows:

$ '''mkdir ''<exportpath>'' '''
$ '''cd ''<exportpath>'' '''
$ '''sudo cpio -i -d -m -F ''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio --no-absolute-filenames '''

You then need to enable the NFS server on your system
(if not already active), and export this filesystem.
How you do this depends on your host Linux distribution.
For example, on some Fedora releases, one might:

* add the export path to <tt>/etc/exports</tt> using a line such as

''<exportpath>'' *(rw,sync,no_root_squash,no_all_squash)

* turn on the NFS server if needed:

$ '''sudo /sbin/chkconfig nfs on'''

* tell the NFS server about the new exported filesystem

$ '''sudo /usr/sbin/exportfs -a'''
$ '''sudo /usr/sbin/exportfs -r'''

Second, follow the instructions in the previous sections,
then configure the kernel again as follows.

Under '''General setup''', make sure the
'''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is disabled (rather than enabled as done in previous sections).

Under '''Platform options''', under the line '''Default bootloader kernel arguments''',
select the boot parameters line and set it to something like this:

'''console=ttyS0,38400 ip=dhcp root=/dev/nfs rw nfsroot=''<server_ip>'':''<exportpath>'' '''

where ''<server_ip>'' is the IP address of your NFS server, and ''<exportpath>''
is the exported filesystem path.

Another approach is to just specify the ip addresses directly in the CMDLINE
'''CONFIG_CMDLINE="console=ttyS0,38400 ip=192.168.11.95:192.168.11.220:192.168.11.1:255.255.255.0:HiFi-2 root=/dev/nfs rw nfsroot=192.168.11.55:/exports/LINUX_ROOT.DC_C_233L debug coredump_filter=0xff" '''${ipaddr}:${nfsroot_server}:${gatewayip}:${netmask}:${hostname}'''

Where the IP addresses are in the form:

'''${ipaddr}:${nfsroot_server}:${gatewayip}:${netmask}:${hostname}'''

Save this configuration, rebuild the kernel, and follow the
instructions in previous sections to download and run the kernel.
If everything goes well and is setup correctly, your kernel should
now boot with a root filesystem mounted over NFS.

== Build and Run a Linux Kernel on the Instruction Set Simulator (ISS) ==

You can build and run a Linux kernel in the Xtensa Instruction Set
Simulator (ISS). The following instructions have only been tried
with an ISS from the RB-2008.3 release of Xtensa Tools. Bear in
mind that the XTAV60 port is likely much more stable than the ISS port
of Linux at this point in time.

Note: Depending on your host OS version, you may need to install
Xtensa Tools on a separate machine.

=== Configure and Build the Kernel for ISS ===

Repeat all the same instructions as above for building the kernel for an
Avnet board, except that when initially configuring the kernel,
start from a ISS platform template instead. For example for the
DC233C Variant:

'''$ mkdir build-iss'''
'''$ cd linux'''
'''$ make O=../build-iss ARCH=xtensa KBUILD_DEFCONFIG=iss_dc233c_defconfig defconfig'''

The above make example configures the kernel using the default configuration found in
'''arch/xtensa/configs/iss_dc233_defconfig'''. Most important to note is that the
root file system mounted when Linux boots comes via the targets device '''/dev/simdisk0'''
which is defined in the kernel '''.config''' file. For example:

'''CONFIG_SIMDISK0_FILENAME="/export2/DC_C_233L/LINUX_ROOT.ext2"'''

The SIMDISK file name and VARIANT name are typically configured when running '''make menuconfig'''; Ex:

'''$ make O=../build-iss ARCH=xtensa menuconfig'''

and selecting

'''Xtensa Platform options''' ---> '''Host filename for a simulated device'''

and entering the pathname to the .ext2 file there. Ex: '''/export2/DC_C_233L/LINUX_ROOT.ext2'''

You often want to change the VARIANT to the one you desire, Ex: FSF. You do this via
the top level menu:

'''Xtensa Processor type and features ---> Xtensa Processor Custom Core Variant Name'''

With the new SIMDISK approach you copy the EXT2 Filesystem file generated by Buildroot
to a location to be accessed by Xtensa Linux. Ex:

'''$ cp /export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot/binaries/dc233c/rootfs.xtensa_dc233c.ext2 /export2/DC_C_233L/LINUX_ROOT.ext2'''

'''NOTE:''' There is an old '''iss_defconfig''' that tries to use a '''tuntap''' Ethernet
interface that currently isn't supported.
Previously with this old iss_defconfig using the '''tuntap''' Ethernet interface
it was suggested to set up the initramfs filesystem, and do the following.
Under '''Bus Options''', deselect '''PCI support'''.
Under '''Platform Options''', deselect '''Default bootloader kernel arguments'''.
Hopefully we will someday be able to support the use of a network interface with
ISS simulation and then be able to mount NFS root partitions again. So I'm leaving
this note for future exploration of this mechanism; Hope you don't mind the clutter.

Continue configuring and building the kernel as usual.

=== Run the Kernel on ISS ===

Using Xtensa Tools, invoke:

'''$ xt-gdb <workdir>/build-iss/arch/xtensa/boot/Image.elf'''
'''(xt-gdb) target sim --turbo --memlimit=128'''
'''(xt-gdb) symbol-file <workdir>/build-iss/vmlinux'''
'''(xt-gdb) run'''

Wait patiently while Linux boots ... (maybe a minute). The setting of the '''memlimit'''
needs to match the PLATFORM_DEFAULT_MEM_SIZE defined in /arch/xtensa/platforms/iss/include/platform/hardware.h.
Currently this limit us 128 MegaBytes:

#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000 /* 13,4217,728 128M */

and we will be extending this for the DC233L to take advantage of it's V3 MMU.

Login as root (no password).

'''Note:''' Input via ISS is cooked, so everything typed gets echoed.
Also, time as reported by the kernel does not progress
according to true wall-clock time: it currently depends on
a simulated processor clock, which advances at various speeds
according to load.

Instructions for building and booting Linux

2011-01-06T05:30:28Z

Piet: /* Mounting the Root Filesystem Over NFS */

These instructions explain how to build a toolchain, root filesystem and kernel for Linux running on an Xtensa processor. These instructions apply specifically to the XTAV60 (LX60) board.

Some general notes on these instructions:

* They are a work in progress. If you are using the latest development sources, the build process may change, so you should be sure to get the latest version of this document at [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions]. If you are using one of the development snapshot releases, you should use the version of the build instructions included with that snapshot.

* The following was tested on x86 machines running RedHat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3). It is expected to work on newer Fedora releases (e.g., was tested on FC6) but to maintain host compatibility with Xtensa Tools, it is best to avoid Fedora releases beyond FC5. Other host distributions likely work but have not been tested.
** '''NOTE:''' this assumes the default selection of packages in buildroot. Selecting extra packages may require a more recent host OS or more recent version of certain tools. For example, the default version of <tt>find</tt> on RHEL4 is too old to allow building all X11 packages in buildroot, so it is necessary to upgrade the host version of <tt>findutils</tt> on RHEL4 to build these packages.

* Lines prefixed with "sudo" need to be executed as root. The rest is best executed as a non-root user. (It is possible to install <tt>git</tt> as a non-root user if root access is an issue. How to do this isn't shown here.)

* Lines that set environment variables assume a Bourne compatible shell (e.g., /bin/sh or bash), but are easily adapted to other shells.

* Instructions are assumed executed all in order (e.g., commands assume current directory and environment variables set earlier).

== Setup your host system ==

If you are using one of the snapshot releases, you can skip this step.

If you want to work with the latest development sources, you will need
[[Installing GIT|<tt>git</tt> installed on your system]].

== Download buildroot and the Linux kernel ==

The following section describes how to download the latest
versions of buildroot and of the Linux kernel.
Skip this step if you are using one of the
[http://wiki.linux-xtensa.org/index.php/Buildroot_Snapshots snapshot releases].

Adventurous users that want the use the '''bleeding edge''' code should execute the following:

'''$ cd <workdir>'''
'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa.git buildroot'''
'''$ git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git linux'''

where <tt><workdir></tt> is the path to an empty directory on a disk with
at least 4 GB available space. You end up with the following file structure,
which is assumed by the rest of this document:

<workdir>/
/buildroot
/linux

The MASTER branch of the buildroot repository is often is a state of development.
It's recommended to use the last snapshot for application developers. In the
case of the Avnet development boards a 'snapshot_2+SMP' branch is recommended
in the currently experimental SMP git repository:

'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

If you happen to have write access to either repository you should change '''git:''' to '''git+ssh:'''
For Example:

'''$ git clone git+ssh://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

For more details, see the [http://wiki.linux-xtensa.org/index.php/Repository_Access repository access] page.

== Install any required processor specific overlay ==

This step is required if you are targeting a custom Xtensa processor.
If you use a Diamond 232L Standard Core, you can skip this step.

To configure buildroot and the kernel to use a custom Xtensa processor
configuration, you need to overlay a set of files customized for your
processor configuration onto toolchain sources (gcc, binutils, gdb, etc)
and the Linux kernel. This process has been automated using a script
located in the buildroot source tree.
For usage information, you can invoke it without arguments:

'''$ cd <workdir>'''
'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install'''

which displays a help message similar to the following:

xt-buildroot-overlay-install version 1.3
Usage: xt-buildroot-overlay-install <parameters> [<options>]
Where <parameters> are:
-t file.tgz Specify path to the Xtensa Linux overlay tarball, typically
<xtensa_root>/src/xtensa-config-overlay.tar.gz
-b dir Path to the base of the buildroot source tree, in which
package specific overlay tarballs get installed.
-k dir Path to the base of the Linux kernel source tree, in which
the Linux kernel specific overlay gets installed.
-c config_name Name for the Xtensa processor configuration as it will be
known to the open source community. Must be a lowercase
identifier, starting with a letter, consisting of letters
and numbers and underscores, not ending with underscore
and not containing consecutive underscores. For examples:
dc232b , dc232b_be , mmubasele , fsf , s5000 .
-l long_name Long name for the Xtensa processor configuration, human-
readable with spaces etc allowed (must be quoted).
For example: 'Diamond 232L Standard Core Rev.B (LE)'
Try to keep it within approximately 40 characters.
And <options> are:
-f If package specific overlay tarballs already exist in
the destination source tree, overwrite them without asking.
--help Show this usage message.

Note that the Xtensa Linux overlay tarball MUST be obtained from an Xtensa
core package built using release RB-2008.3 or later.

Here is an example invocation of the overlay installation script:

'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install -t blinkcore-config-overlay.tar.gz''' \
'''-b ./buildroot -k ./linux -c superzip -l "ChipCorp SuperZIP Blink Accelerator Core"'''

The script extracts some relevant information from the overlay tarball,
presents it along with relevant parameters to the user, and prompts
for confirmation before proceeding.

The chosen processor name (-c option) must be unique among known Xtensa processors.
It is also probably wise to avoid names confusingly similar to other (non-Xtensa) processors.
If you expect at some point to contribute support for your custom processor to the
open-source community, this name will likely be long-lived.
(One way to contribute support for a custom processor might be to submit the overlay tarball
or files to the linux-xtensa.org maintainers.)

In the steps below, buildroot and the Linux kernel must be configured
(in their respective <code>''make menuconfig''</code> steps) to select
the <code>''custom''</code> Xtensa processor option.
This presents an extra configuration menu entry where you must provide
the name of the Xtensa processor. Set it to the same name
as was specified in the <code>-c</code> option above.

== Build a toolchain and root filesystem using buildroot ==

'''Note:''' for more details on generic buildroot topics not covered in this simple how-to,
see [http://buildroot.uclibc.org/ buildroot.uclibc.org].

=== Configure buildroot ===

The first time you configure buildroot, start with defaults for your Xtensa processor:

'''$ cd <workdir>/buildroot'''
'''$ ./target/xtensa/setup-config <corename>'''

where ''<corename>'' is the overlay name of your selected Xtensa or Diamond core
(e.g., '''dc232b'''). If you omit ''<corename>'', a help message and a list
of currently installed Tensilica core overlays is displayed.

Optionally, you can then customize your buildroot configuration, such as
selecting additional packages, setting various parameters, and so on.
The following make targets provide a ''curses'' (text-based graphical) interface
for configuring buildroot, the uClibc C library, and busybox, respectively.
('''Note:''' You need the <tt>TERM</tt> environment variable properly set for
these curses based tools to work.)

'''$ make menuconfig'''
'''$ make uclibc-menuconfig'''
'''$ make busybox-menuconfig'''

=== Build buildroot ===

Just type:

'''$ make'''

THIS WILL TAKE A LONG TIME (from about 30 minutes with defaults on a 3 GHz Pentium 4,
to perhaps an hour or many depending on your system and on whether
you enabled extra packages in your buildroot configuration).

Wait patiently for the build to complete. This builds an entire toolchain
as well as some basic packages, and constructs a root filesystem.
It might build many more packages if you selected them earlier with menuconfig.

==== If Something Goes Wrong ====

Perhaps you missed some step above and the build fails. Or you're just switching to a different processor configuration, or making some change with unknown dependencies. Either way, you'll probably need to fix the error and/or make the change, and redo the whole build. The above <tt>make</tt> command usually works fine if you
just added a package using menuconfig, but otherwise does not check many dependencies, so it will usually NOT rebuild things that depend on whatever you have fixed or changed. Here's one way to retry the make from scratch without having to wipe out the <tt>buildroot</tt> directory tree completely and start again from the git cloning.

$ '''rm -rf *build_xtensa* binaries'''
$ '''make'''

It is not necessary to empty the 'dl' subdirectory, which contains tarballs downloaded from the Internet, nor the .config file, which contains the buildroot configuration. Customizations to the uClibc and <tt>busybox</tt> configurations should have ended up getting saved in target/xtensa/uClibc.config and target/xtensa/busybox-config, respectively, so hopefully are preserved by the above sequence.

== Build and Run a Linux Kernel on the XTAV60, AXAV110, or XTAV200 Boards ==

References to the ''XTAV60 board'' refer to the combination of
the Avnet [http://www.em.avnet.com/tensilica1 LX60 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX60 (XT-AV60) Board User's Guide''.

Similarly, references to the ''XTAV200 board'' refers the combination of
the Avnet [http://www.em.avnet.com/tensilica2 LX200 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX200 (XT-AV200) Board User's Guide''.

=== Configure the kernel ===

The kernel build is a two-step process: configure the kernel, and build it.
First, before we can do anything with the kernel, set your PATH to
point to the toolchain built using buildroot.

$ '''export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"'''

where ''<cname>'' is the name of the Xtensa processor configuration you selected
when building the toolchain (e.g., <code>dc232b</code>).

Now setup a destination for kernel builds.
We usually like to have the build directory separate from
the source directory, so we use 'O=</destination/path>' in
kernel make commands. If you'll be routinely building multiple
configurations of the Linux kernel, it's good to have some
naming conventions for the build directory. For example,
to experiment with multiple target platforms but only one
processor configuration, we include just the platform name here:

$'''mkdir build-xtav60'''

Let's start with the default kernel configuration for the Avnet board
(which works on both XTAV60 (LX60), XTAV110 (LX110), and XTAV200 (LX200) boards)
as follows:

$ '''cd linux'''
$ '''make O=../build-xtav60 ARCH=xtensa KBUILD_DEFCONFIG=lx60_defconfig defconfig'''

This configures the kernel using the default configuration found in
'''arch/xtensa/configs/lx60_defconfig'''.

'''NOTE:''' This kernel configuration has nothing to do with Xtensa
processor configuration. That comes next.

Let's now customize this a little bit to select the correct Xtensa processor
configuration, and to bundle the root filesystem into the kernel:

$ '''make O=../build-xtav60 ARCH=xtensa menuconfig'''

Under '''General setup''',
make sure the '''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is enabled. Underneath that, edit '''Initramfs source file(s)''',
and enter the path to the cpio formatted root filesystem
generated by buildroot:

''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio.gz

(Don't forget to replace ''<workdir>'' with the appropriate full path
and ''<cname>'' with your Xtensa processor configuration name.)

Under '''Processor type and features''',
make sure the '''Xtensa Processor Configuration''' is correct and matches
the processor configuration name you used to build the toolchain with buildroot
(for example, ''dc232b'' for Diamond 232L Rev.B).
The kernel build selects a toolchain and processor variant specific headers
based on this selection.
If the desired processor configuration does not appear explicitly in the list,
simply select '''Custom Xtensa processor configuration''' and enter the
processor configuration name (all lowercase) into the next menu parameter,
'''Xtensa Processor Custom Variant Name'''.

Back in the main menu, under '''Platform options''', make sure the
'''CPU clock rate''' entry is set correctly according to the following table:

{| border="1" style="text-align:center; margin: 1em auto 1em auto"
|-
! Board !! Frequency selected in XPG (MHz) !! ''CPU clock rate'' setting (kHz)
|-
|rowspan="3"| XTAV60 (LX60)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV110 (LX110)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV200 (LX200)
| 30 || 31250
|-
| 40 || 41667
|-
| 50 || 50000
|-
|}

Exit menuconfig, saving your configuration changes.

Backup your configuration outside the build directory. For example:

$ '''cp ../build-xtav60/.config config.xtav60.saved'''

If you do a clean rebuild of the kernel (e.g., "rm -rf ../build-xtav60")
you can now configure it with simply:
$ '''mkdir ../build-xtav60 ; cp config.xtav60.saved ../build-xtav60/.config'''
Of course if you update the kernel, you'll probably again have to do:
$ '''make O=../build-xtav60 ARCH=xtensa menuconfig'''
and save a new copy of your configuration.

=== Build the kernel ===

$ '''make O=../build-xtav60 ARCH=xtensa'''

The build will issue a few warnings which are normal.
Once complete, the bootable image is in:
<workdir>/build-xtav60/arch/xtensa/boot/Image.elf
and the uncompressed ELF file containing kernel symbols is in:
<workdir>/build-xtav60/vmlinux
There is also a RedBoot bootable image (if you use RedBoot) in:
<workdir>/build-xtav60/arch/xtensa/boot/zImage.redboot

=== Install Xtensa Tools for the selected core ===

If you opt to download the kernel over OCD, you need <tt>xt-gdb</tt>
which is part of Tensilica's Xtensa Tools package. This must be obtained
from Tensilica, and is not the same toolchain as built by buildroot.
You also need to install the corresponding Tensilica core package,
so that the Xtensa Tools know about your particular configured
Tensilica core.

The toolchain built using buildroot can be configured to
include GDB, but that version of GDB does not support
communicating with Tensilica's Xtensa OCD Daemon, and
thus cannot be used to download the kernel over OCD.

In this example, it is assumed that the machine hosting the
Xtensa Tools has access to the <workdir> directory tree.

=== Install and setup the Xtensa OCD Daemon ===

Setup and connect your JTAG probe, etc.

=== Connect a terminal server ===

At 38400 bps 8N1 no flow control to the XTAV60 serial port.

=== Optionally, setup networking ===

This step is optional.

Setup the board's MAC address using dipswitches
(see XTAV60 or XTAV200 board docs as appropriate)
and connect the board to a network that has a
DHCP server that will respond to that MAC address.
If you don't do this step, you'll simply not have network
access, and the boot process will take a minute or so longer
while the kernel times out waiting for a BOOTP response.
You can edit the kernel configuration and rebuild the kernel
to avoid using bootp (in particular, remove "ip=bootp" from
the kernel cmdline).

=== Download and run the kernel ===

Reset the board (see board documentation).

Using Xtensa Tools, invoke:

$ '''xt-gdb <workdir>/build-xtav60/arch/xtensa/boot/Image.elf'''

'''(xt-gdb) target remote <ocdhost>:20000 0'''
'''(xt-gdb) reset'''
'''(xt-gdb) load'''
'''(xt-gdb) set $pc = &_ResetVector'''
'''(xt-gdb) symbol-file <workdir>/build-xtav60/vmlinux'''
'''(xt-gdb) c'''

where <ocdhost> is the IP address or DNS name of the machine
running the Xtensa OCD daemon. The Linux kernel should
start booting as soon as 'c' (continue) is executed.

You should eventually get a login prompt.
Just login as root (no password).

Try various Linux commands. Look at <tt>/bin</tt>,
<tt>/sbin</tt>, <tt>/usr/bin</tt>, etc to see what's available.

'''Note:''' no need to setup an NFS or TFTP server. The filesystem
is contained within the kernel image. You may be able to mount
other filesystems over NFS though, if you wish, after booting.

=== Mounting the Root Filesystem Over NFS ===

If you build more than the minimal set of packages using
buildroot, the root filesystem can easily grow too large to
fit comfortably (or at all) inside the kernel. In this case,
rather than follow the instructions exactly as above,
you'll want to mount the root filesystem over NFS.

You may also want to mount the root filesystem over NFS to
make changes to the filesystem persistent across runs and
accessible from your development host.

First you need to install the root filesystem generated
using buildroot, to a machine that can serve it over NFS.
Assuming this machine runs Linux, one way to install it is
as follows:

'''mkdir ''<exportpath>'' '''
'''cd ''<exportpath>'' '''
'''sudo cpio -i -d -m -F ''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio --no-absolute-filenames '''

You then need to enable the NFS server on your system
(if not already active), and export this filesystem.
How you do this depends on your host Linux distribution.
For example, on some Fedora releases, one might:

* add the export path to <tt>/etc/exports</tt> using a line such as

''<exportpath>'' *(rw,sync,no_root_squash,no_all_squash)

* turn on the NFS server if needed:

'''sudo /sbin/chkconfig nfs on'''

* tell the NFS server about the new exported filesystem

'''sudo /usr/sbin/exportfs -a'''
'''sudo /usr/sbin/exportfs -r'''

Second, follow the instructions in the previous sections,
then configure the kernel again as follows.

Under '''General setup''', make sure the
'''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is disabled (rather than enabled as done in previous sections).

Under '''Platform options''', under the line '''Default bootloader kernel arguments''',
select the boot parameters line and set it to something like this:

'''console=ttyS0,38400 ip=dhcp root=/dev/nfs rw nfsroot=''<server_ip>'':''<exportpath>'' '''

where ''<server_ip>'' is the IP address of your NFS server, and ''<exportpath>''
is the exported filesystem path.

Another approach is to just specify the ip addresses directly in the CMDLINE
'''CONFIG_CMDLINE="console=ttyS0,38400 ip=192.168.11.95:192.168.11.220:192.168.11.1:255.255.255.0:HiFi-2 root=/dev/nfs rw nfsroot=192.168.11.55:/exports/LINUX_ROOT.DC_C_233L debug coredump_filter=0xff" '''${ipaddr}:${nfsroot_server}:${gatewayip}:${netmask}:${hostname}'''

Where the IP addresses are in the form:

'''${ipaddr}:${nfsroot_server}:${gatewayip}:${netmask}:${hostname}'''

Save this configuration, rebuild the kernel, and follow the
instructions in previous sections to download and run the kernel.
If everything goes well and is setup correctly, your kernel should
now boot with a root filesystem mounted over NFS.

== Build and Run a Linux Kernel on the Instruction Set Simulator (ISS) ==

You can build and run a Linux kernel in the Xtensa Instruction Set
Simulator (ISS). The following instructions have only been tried
with an ISS from the RB-2008.3 release of Xtensa Tools. Bear in
mind that the XTAV60 port is likely much more stable than the ISS port
of Linux at this point in time.

Note: Depending on your host OS version, you may need to install
Xtensa Tools on a separate machine.

=== Configure and Build the Kernel for ISS ===

Repeat all the same instructions as above for building the kernel for an
Avnet board, except that when initially configuring the kernel,
start from a ISS platform template instead. For example for the
DC233C Variant:

'''$ mkdir build-iss'''
'''$ cd linux'''
'''$ make O=../build-iss ARCH=xtensa KBUILD_DEFCONFIG=iss_dc233c_defconfig defconfig'''

The above make example configures the kernel using the default configuration found in
'''arch/xtensa/configs/iss_dc233_defconfig'''. Most important to note is that the
root file system mounted when Linux boots comes via the targets device '''/dev/simdisk0'''
which is defined in the kernel '''.config''' file. For example:

'''CONFIG_SIMDISK0_FILENAME="/export2/DC_C_233L/LINUX_ROOT.ext2"'''

The SIMDISK file name and VARIANT name are typically configured when running '''make menuconfig'''; Ex:

'''$ make O=../build-iss ARCH=xtensa menuconfig'''

and selecting

'''Xtensa Platform options''' ---> '''Host filename for a simulated device'''

and entering the pathname to the .ext2 file there. Ex: '''/export2/DC_C_233L/LINUX_ROOT.ext2'''

You often want to change the VARIANT to the one you desire, Ex: FSF. You do this via
the top level menu:

'''Xtensa Processor type and features ---> Xtensa Processor Custom Core Variant Name'''

With the new SIMDISK approach you copy the EXT2 Filesystem file generated by Buildroot
to a location to be accessed by Xtensa Linux. Ex:

'''$ cp /export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot/binaries/dc233c/rootfs.xtensa_dc233c.ext2 /export2/DC_C_233L/LINUX_ROOT.ext2'''

'''NOTE:''' There is an old '''iss_defconfig''' that tries to use a '''tuntap''' Ethernet
interface that currently isn't supported.
Previously with this old iss_defconfig using the '''tuntap''' Ethernet interface
it was suggested to set up the initramfs filesystem, and do the following.
Under '''Bus Options''', deselect '''PCI support'''.
Under '''Platform Options''', deselect '''Default bootloader kernel arguments'''.
Hopefully we will someday be able to support the use of a network interface with
ISS simulation and then be able to mount NFS root partitions again. So I'm leaving
this note for future exploration of this mechanism; Hope you don't mind the clutter.

Continue configuring and building the kernel as usual.

=== Run the Kernel on ISS ===

Using Xtensa Tools, invoke:

'''$ xt-gdb <workdir>/build-iss/arch/xtensa/boot/Image.elf'''
'''(xt-gdb) target sim --turbo --memlimit=128'''
'''(xt-gdb) symbol-file <workdir>/build-iss/vmlinux'''
'''(xt-gdb) run'''

Wait patiently while Linux boots ... (maybe a minute). The setting of the '''memlimit'''
needs to match the PLATFORM_DEFAULT_MEM_SIZE defined in /arch/xtensa/platforms/iss/include/platform/hardware.h.
Currently this limit us 128 MegaBytes:

#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000 /* 13,4217,728 128M */

and we will be extending this for the DC233L to take advantage of it's V3 MMU.

Login as root (no password).

'''Note:''' Input via ISS is cooked, so everything typed gets echoed.
Also, time as reported by the kernel does not progress
according to true wall-clock time: it currently depends on
a simulated processor clock, which advances at various speeds
according to load.

Instructions for building and booting Linux

2011-01-06T04:32:27Z

Piet: /* Download and run the kernel */

These instructions explain how to build a toolchain, root filesystem and kernel for Linux running on an Xtensa processor. These instructions apply specifically to the XTAV60 (LX60) board.

Some general notes on these instructions:

* They are a work in progress. If you are using the latest development sources, the build process may change, so you should be sure to get the latest version of this document at [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions]. If you are using one of the development snapshot releases, you should use the version of the build instructions included with that snapshot.

* The following was tested on x86 machines running RedHat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3). It is expected to work on newer Fedora releases (e.g., was tested on FC6) but to maintain host compatibility with Xtensa Tools, it is best to avoid Fedora releases beyond FC5. Other host distributions likely work but have not been tested.
** '''NOTE:''' this assumes the default selection of packages in buildroot. Selecting extra packages may require a more recent host OS or more recent version of certain tools. For example, the default version of <tt>find</tt> on RHEL4 is too old to allow building all X11 packages in buildroot, so it is necessary to upgrade the host version of <tt>findutils</tt> on RHEL4 to build these packages.

* Lines prefixed with "sudo" need to be executed as root. The rest is best executed as a non-root user. (It is possible to install <tt>git</tt> as a non-root user if root access is an issue. How to do this isn't shown here.)

* Lines that set environment variables assume a Bourne compatible shell (e.g., /bin/sh or bash), but are easily adapted to other shells.

* Instructions are assumed executed all in order (e.g., commands assume current directory and environment variables set earlier).

== Setup your host system ==

If you are using one of the snapshot releases, you can skip this step.

If you want to work with the latest development sources, you will need
[[Installing GIT|<tt>git</tt> installed on your system]].

== Download buildroot and the Linux kernel ==

The following section describes how to download the latest
versions of buildroot and of the Linux kernel.
Skip this step if you are using one of the
[http://wiki.linux-xtensa.org/index.php/Buildroot_Snapshots snapshot releases].

Adventurous users that want the use the '''bleeding edge''' code should execute the following:

'''$ cd <workdir>'''
'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa.git buildroot'''
'''$ git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git linux'''

where <tt><workdir></tt> is the path to an empty directory on a disk with
at least 4 GB available space. You end up with the following file structure,
which is assumed by the rest of this document:

<workdir>/
/buildroot
/linux

The MASTER branch of the buildroot repository is often is a state of development.
It's recommended to use the last snapshot for application developers. In the
case of the Avnet development boards a 'snapshot_2+SMP' branch is recommended
in the currently experimental SMP git repository:

'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

If you happen to have write access to either repository you should change '''git:''' to '''git+ssh:'''
For Example:

'''$ git clone git+ssh://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

For more details, see the [http://wiki.linux-xtensa.org/index.php/Repository_Access repository access] page.

== Install any required processor specific overlay ==

This step is required if you are targeting a custom Xtensa processor.
If you use a Diamond 232L Standard Core, you can skip this step.

To configure buildroot and the kernel to use a custom Xtensa processor
configuration, you need to overlay a set of files customized for your
processor configuration onto toolchain sources (gcc, binutils, gdb, etc)
and the Linux kernel. This process has been automated using a script
located in the buildroot source tree.
For usage information, you can invoke it without arguments:

'''$ cd <workdir>'''
'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install'''

which displays a help message similar to the following:

xt-buildroot-overlay-install version 1.3
Usage: xt-buildroot-overlay-install <parameters> [<options>]
Where <parameters> are:
-t file.tgz Specify path to the Xtensa Linux overlay tarball, typically
<xtensa_root>/src/xtensa-config-overlay.tar.gz
-b dir Path to the base of the buildroot source tree, in which
package specific overlay tarballs get installed.
-k dir Path to the base of the Linux kernel source tree, in which
the Linux kernel specific overlay gets installed.
-c config_name Name for the Xtensa processor configuration as it will be
known to the open source community. Must be a lowercase
identifier, starting with a letter, consisting of letters
and numbers and underscores, not ending with underscore
and not containing consecutive underscores. For examples:
dc232b , dc232b_be , mmubasele , fsf , s5000 .
-l long_name Long name for the Xtensa processor configuration, human-
readable with spaces etc allowed (must be quoted).
For example: 'Diamond 232L Standard Core Rev.B (LE)'
Try to keep it within approximately 40 characters.
And <options> are:
-f If package specific overlay tarballs already exist in
the destination source tree, overwrite them without asking.
--help Show this usage message.

Note that the Xtensa Linux overlay tarball MUST be obtained from an Xtensa
core package built using release RB-2008.3 or later.

Here is an example invocation of the overlay installation script:

'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install -t blinkcore-config-overlay.tar.gz''' \
'''-b ./buildroot -k ./linux -c superzip -l "ChipCorp SuperZIP Blink Accelerator Core"'''

The script extracts some relevant information from the overlay tarball,
presents it along with relevant parameters to the user, and prompts
for confirmation before proceeding.

The chosen processor name (-c option) must be unique among known Xtensa processors.
It is also probably wise to avoid names confusingly similar to other (non-Xtensa) processors.
If you expect at some point to contribute support for your custom processor to the
open-source community, this name will likely be long-lived.
(One way to contribute support for a custom processor might be to submit the overlay tarball
or files to the linux-xtensa.org maintainers.)

In the steps below, buildroot and the Linux kernel must be configured
(in their respective <code>''make menuconfig''</code> steps) to select
the <code>''custom''</code> Xtensa processor option.
This presents an extra configuration menu entry where you must provide
the name of the Xtensa processor. Set it to the same name
as was specified in the <code>-c</code> option above.

== Build a toolchain and root filesystem using buildroot ==

'''Note:''' for more details on generic buildroot topics not covered in this simple how-to,
see [http://buildroot.uclibc.org/ buildroot.uclibc.org].

=== Configure buildroot ===

The first time you configure buildroot, start with defaults for your Xtensa processor:

'''$ cd <workdir>/buildroot'''
'''$ ./target/xtensa/setup-config <corename>'''

where ''<corename>'' is the overlay name of your selected Xtensa or Diamond core
(e.g., '''dc232b'''). If you omit ''<corename>'', a help message and a list
of currently installed Tensilica core overlays is displayed.

Optionally, you can then customize your buildroot configuration, such as
selecting additional packages, setting various parameters, and so on.
The following make targets provide a ''curses'' (text-based graphical) interface
for configuring buildroot, the uClibc C library, and busybox, respectively.
('''Note:''' You need the <tt>TERM</tt> environment variable properly set for
these curses based tools to work.)

'''$ make menuconfig'''
'''$ make uclibc-menuconfig'''
'''$ make busybox-menuconfig'''

=== Build buildroot ===

Just type:

'''$ make'''

THIS WILL TAKE A LONG TIME (from about 30 minutes with defaults on a 3 GHz Pentium 4,
to perhaps an hour or many depending on your system and on whether
you enabled extra packages in your buildroot configuration).

Wait patiently for the build to complete. This builds an entire toolchain
as well as some basic packages, and constructs a root filesystem.
It might build many more packages if you selected them earlier with menuconfig.

==== If Something Goes Wrong ====

Perhaps you missed some step above and the build fails. Or you're just switching to a different processor configuration, or making some change with unknown dependencies. Either way, you'll probably need to fix the error and/or make the change, and redo the whole build. The above <tt>make</tt> command usually works fine if you
just added a package using menuconfig, but otherwise does not check many dependencies, so it will usually NOT rebuild things that depend on whatever you have fixed or changed. Here's one way to retry the make from scratch without having to wipe out the <tt>buildroot</tt> directory tree completely and start again from the git cloning.

$ '''rm -rf *build_xtensa* binaries'''
$ '''make'''

It is not necessary to empty the 'dl' subdirectory, which contains tarballs downloaded from the Internet, nor the .config file, which contains the buildroot configuration. Customizations to the uClibc and <tt>busybox</tt> configurations should have ended up getting saved in target/xtensa/uClibc.config and target/xtensa/busybox-config, respectively, so hopefully are preserved by the above sequence.

== Build and Run a Linux Kernel on the XTAV60, AXAV110, or XTAV200 Boards ==

References to the ''XTAV60 board'' refer to the combination of
the Avnet [http://www.em.avnet.com/tensilica1 LX60 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX60 (XT-AV60) Board User's Guide''.

Similarly, references to the ''XTAV200 board'' refers the combination of
the Avnet [http://www.em.avnet.com/tensilica2 LX200 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX200 (XT-AV200) Board User's Guide''.

=== Configure the kernel ===

The kernel build is a two-step process: configure the kernel, and build it.
First, before we can do anything with the kernel, set your PATH to
point to the toolchain built using buildroot.

$ '''export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"'''

where ''<cname>'' is the name of the Xtensa processor configuration you selected
when building the toolchain (e.g., <code>dc232b</code>).

Now setup a destination for kernel builds.
We usually like to have the build directory separate from
the source directory, so we use 'O=</destination/path>' in
kernel make commands. If you'll be routinely building multiple
configurations of the Linux kernel, it's good to have some
naming conventions for the build directory. For example,
to experiment with multiple target platforms but only one
processor configuration, we include just the platform name here:

$'''mkdir build-xtav60'''

Let's start with the default kernel configuration for the Avnet board
(which works on both XTAV60 (LX60), XTAV110 (LX110), and XTAV200 (LX200) boards)
as follows:

$ '''cd linux'''
$ '''make O=../build-xtav60 ARCH=xtensa KBUILD_DEFCONFIG=lx60_defconfig defconfig'''

This configures the kernel using the default configuration found in
'''arch/xtensa/configs/lx60_defconfig'''.

'''NOTE:''' This kernel configuration has nothing to do with Xtensa
processor configuration. That comes next.

Let's now customize this a little bit to select the correct Xtensa processor
configuration, and to bundle the root filesystem into the kernel:

$ '''make O=../build-xtav60 ARCH=xtensa menuconfig'''

Under '''General setup''',
make sure the '''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is enabled. Underneath that, edit '''Initramfs source file(s)''',
and enter the path to the cpio formatted root filesystem
generated by buildroot:

''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio.gz

(Don't forget to replace ''<workdir>'' with the appropriate full path
and ''<cname>'' with your Xtensa processor configuration name.)

Under '''Processor type and features''',
make sure the '''Xtensa Processor Configuration''' is correct and matches
the processor configuration name you used to build the toolchain with buildroot
(for example, ''dc232b'' for Diamond 232L Rev.B).
The kernel build selects a toolchain and processor variant specific headers
based on this selection.
If the desired processor configuration does not appear explicitly in the list,
simply select '''Custom Xtensa processor configuration''' and enter the
processor configuration name (all lowercase) into the next menu parameter,
'''Xtensa Processor Custom Variant Name'''.

Back in the main menu, under '''Platform options''', make sure the
'''CPU clock rate''' entry is set correctly according to the following table:

{| border="1" style="text-align:center; margin: 1em auto 1em auto"
|-
! Board !! Frequency selected in XPG (MHz) !! ''CPU clock rate'' setting (kHz)
|-
|rowspan="3"| XTAV60 (LX60)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV110 (LX110)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV200 (LX200)
| 30 || 31250
|-
| 40 || 41667
|-
| 50 || 50000
|-
|}

Exit menuconfig, saving your configuration changes.

Backup your configuration outside the build directory. For example:

$ '''cp ../build-xtav60/.config config.xtav60.saved'''

If you do a clean rebuild of the kernel (e.g., "rm -rf ../build-xtav60")
you can now configure it with simply:
$ '''mkdir ../build-xtav60 ; cp config.xtav60.saved ../build-xtav60/.config'''
Of course if you update the kernel, you'll probably again have to do:
$ '''make O=../build-xtav60 ARCH=xtensa menuconfig'''
and save a new copy of your configuration.

=== Build the kernel ===

$ '''make O=../build-xtav60 ARCH=xtensa'''

The build will issue a few warnings which are normal.
Once complete, the bootable image is in:
<workdir>/build-xtav60/arch/xtensa/boot/Image.elf
and the uncompressed ELF file containing kernel symbols is in:
<workdir>/build-xtav60/vmlinux
There is also a RedBoot bootable image (if you use RedBoot) in:
<workdir>/build-xtav60/arch/xtensa/boot/zImage.redboot

=== Install Xtensa Tools for the selected core ===

If you opt to download the kernel over OCD, you need <tt>xt-gdb</tt>
which is part of Tensilica's Xtensa Tools package. This must be obtained
from Tensilica, and is not the same toolchain as built by buildroot.
You also need to install the corresponding Tensilica core package,
so that the Xtensa Tools know about your particular configured
Tensilica core.

The toolchain built using buildroot can be configured to
include GDB, but that version of GDB does not support
communicating with Tensilica's Xtensa OCD Daemon, and
thus cannot be used to download the kernel over OCD.

In this example, it is assumed that the machine hosting the
Xtensa Tools has access to the <workdir> directory tree.

=== Install and setup the Xtensa OCD Daemon ===

Setup and connect your JTAG probe, etc.

=== Connect a terminal server ===

At 38400 bps 8N1 no flow control to the XTAV60 serial port.

=== Optionally, setup networking ===

This step is optional.

Setup the board's MAC address using dipswitches
(see XTAV60 or XTAV200 board docs as appropriate)
and connect the board to a network that has a
DHCP server that will respond to that MAC address.
If you don't do this step, you'll simply not have network
access, and the boot process will take a minute or so longer
while the kernel times out waiting for a BOOTP response.
You can edit the kernel configuration and rebuild the kernel
to avoid using bootp (in particular, remove "ip=bootp" from
the kernel cmdline).

=== Download and run the kernel ===

Reset the board (see board documentation).

Using Xtensa Tools, invoke:

$ '''xt-gdb <workdir>/build-xtav60/arch/xtensa/boot/Image.elf'''

'''(xt-gdb) target remote <ocdhost>:20000 0'''
'''(xt-gdb) reset'''
'''(xt-gdb) load'''
'''(xt-gdb) set $pc = &_ResetVector'''
'''(xt-gdb) symbol-file <workdir>/build-xtav60/vmlinux'''
'''(xt-gdb) c'''

where <ocdhost> is the IP address or DNS name of the machine
running the Xtensa OCD daemon. The Linux kernel should
start booting as soon as 'c' (continue) is executed.

You should eventually get a login prompt.
Just login as root (no password).

Try various Linux commands. Look at <tt>/bin</tt>,
<tt>/sbin</tt>, <tt>/usr/bin</tt>, etc to see what's available.

'''Note:''' no need to setup an NFS or TFTP server. The filesystem
is contained within the kernel image. You may be able to mount
other filesystems over NFS though, if you wish, after booting.

=== Mounting the Root Filesystem Over NFS ===

If you build more than the minimal set of packages using
buildroot, the root filesystem can easily grow too large to
fit comfortably (or at all) inside the kernel. In this case,
rather than follow the instructions exactly as above,
you'll want to mount the root filesystem over NFS.

You may also want to mount the root filesystem over NFS to
make changes to the filesystem persistent across runs and
accessible from your development host.

First you need to install the root filesystem generated
using buildroot, to a machine that can serve it over NFS.
Assuming this machine runs Linux, one way to install it is
as follows:

mkdir ''<exportpath>''
cd ''<exportpath>''
sudo cpio -i -d -m -F ''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio --no-absolute-filenames

You then need to enable the NFS server on your system
(if not already active), and export this filesystem.
How you do this depends on your host Linux distribution.
For example, on some Fedora releases, one might:

* add the export path to <tt>/etc/exports</tt> using a line such as

''<exportpath>'' *(rw,sync,no_root_squash,no_all_squash)

* turn on the NFS server if needed:

sudo /sbin/chkconfig nfs on

* tell the NFS server about the new exported filesystem

sudo /usr/sbin/exportfs -a
sudo /usr/sbin/exportfs -r

Second, follow the instructions in the previous sections,
then configure the kernel again as follows.

Under '''General setup''', make sure the
'''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is disabled (rather than enabled as done in previous sections).

Under '''Platform options''', under the line '''Default bootloader kernel arguments''',
select the boot parameters line and set it to something like this:

console=ttyS0,38400 ip=dhcp root=/dev/nfs rw nfsroot=''<server_ip>'':''<exportpath>''

where ''<server_ip>'' is the IP address of your NFS server, and ''<exportpath>''
is the exported filesystem path.

Save this configuration, rebuild the kernel, and follow the
instructions in previous sections to download and run the kernel.
If everything goes well and is setup correctly, your kernel should
now boot with a root filesystem mounted over NFS.

== Build and Run a Linux Kernel on the Instruction Set Simulator (ISS) ==

You can build and run a Linux kernel in the Xtensa Instruction Set
Simulator (ISS). The following instructions have only been tried
with an ISS from the RB-2008.3 release of Xtensa Tools. Bear in
mind that the XTAV60 port is likely much more stable than the ISS port
of Linux at this point in time.

Note: Depending on your host OS version, you may need to install
Xtensa Tools on a separate machine.

=== Configure and Build the Kernel for ISS ===

Repeat all the same instructions as above for building the kernel for an
Avnet board, except that when initially configuring the kernel,
start from a ISS platform template instead. For example for the
DC233C Variant:

'''$ mkdir build-iss'''
'''$ cd linux'''
'''$ make O=../build-iss ARCH=xtensa KBUILD_DEFCONFIG=iss_dc233c_defconfig defconfig'''

The above make example configures the kernel using the default configuration found in
'''arch/xtensa/configs/iss_dc233_defconfig'''. Most important to note is that the
root file system mounted when Linux boots comes via the targets device '''/dev/simdisk0'''
which is defined in the kernel '''.config''' file. For example:

'''CONFIG_SIMDISK0_FILENAME="/export2/DC_C_233L/LINUX_ROOT.ext2"'''

The SIMDISK file name and VARIANT name are typically configured when running '''make menuconfig'''; Ex:

'''$ make O=../build-iss ARCH=xtensa menuconfig'''

and selecting

'''Xtensa Platform options''' ---> '''Host filename for a simulated device'''

and entering the pathname to the .ext2 file there. Ex: '''/export2/DC_C_233L/LINUX_ROOT.ext2'''

You often want to change the VARIANT to the one you desire, Ex: FSF. You do this via
the top level menu:

'''Xtensa Processor type and features ---> Xtensa Processor Custom Core Variant Name'''

With the new SIMDISK approach you copy the EXT2 Filesystem file generated by Buildroot
to a location to be accessed by Xtensa Linux. Ex:

'''$ cp /export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot/binaries/dc233c/rootfs.xtensa_dc233c.ext2 /export2/DC_C_233L/LINUX_ROOT.ext2'''

'''NOTE:''' There is an old '''iss_defconfig''' that tries to use a '''tuntap''' Ethernet
interface that currently isn't supported.
Previously with this old iss_defconfig using the '''tuntap''' Ethernet interface
it was suggested to set up the initramfs filesystem, and do the following.
Under '''Bus Options''', deselect '''PCI support'''.
Under '''Platform Options''', deselect '''Default bootloader kernel arguments'''.
Hopefully we will someday be able to support the use of a network interface with
ISS simulation and then be able to mount NFS root partitions again. So I'm leaving
this note for future exploration of this mechanism; Hope you don't mind the clutter.

Continue configuring and building the kernel as usual.

=== Run the Kernel on ISS ===

Using Xtensa Tools, invoke:

'''$ xt-gdb <workdir>/build-iss/arch/xtensa/boot/Image.elf'''
'''(xt-gdb) target sim --turbo --memlimit=128'''
'''(xt-gdb) symbol-file <workdir>/build-iss/vmlinux'''
'''(xt-gdb) run'''

Wait patiently while Linux boots ... (maybe a minute). The setting of the '''memlimit'''
needs to match the PLATFORM_DEFAULT_MEM_SIZE defined in /arch/xtensa/platforms/iss/include/platform/hardware.h.
Currently this limit us 128 MegaBytes:

#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000 /* 13,4217,728 128M */

and we will be extending this for the DC233L to take advantage of it's V3 MMU.

Login as root (no password).

'''Note:''' Input via ISS is cooked, so everything typed gets echoed.
Also, time as reported by the kernel does not progress
according to true wall-clock time: it currently depends on
a simulated processor clock, which advances at various speeds
according to load.

Instructions for building and booting Linux

2011-01-06T04:31:28Z

Piet: /* Download and run the kernel */

These instructions explain how to build a toolchain, root filesystem and kernel for Linux running on an Xtensa processor. These instructions apply specifically to the XTAV60 (LX60) board.

Some general notes on these instructions:

* They are a work in progress. If you are using the latest development sources, the build process may change, so you should be sure to get the latest version of this document at [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions]. If you are using one of the development snapshot releases, you should use the version of the build instructions included with that snapshot.

* The following was tested on x86 machines running RedHat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3). It is expected to work on newer Fedora releases (e.g., was tested on FC6) but to maintain host compatibility with Xtensa Tools, it is best to avoid Fedora releases beyond FC5. Other host distributions likely work but have not been tested.
** '''NOTE:''' this assumes the default selection of packages in buildroot. Selecting extra packages may require a more recent host OS or more recent version of certain tools. For example, the default version of <tt>find</tt> on RHEL4 is too old to allow building all X11 packages in buildroot, so it is necessary to upgrade the host version of <tt>findutils</tt> on RHEL4 to build these packages.

* Lines prefixed with "sudo" need to be executed as root. The rest is best executed as a non-root user. (It is possible to install <tt>git</tt> as a non-root user if root access is an issue. How to do this isn't shown here.)

* Lines that set environment variables assume a Bourne compatible shell (e.g., /bin/sh or bash), but are easily adapted to other shells.

* Instructions are assumed executed all in order (e.g., commands assume current directory and environment variables set earlier).

== Setup your host system ==

If you are using one of the snapshot releases, you can skip this step.

If you want to work with the latest development sources, you will need
[[Installing GIT|<tt>git</tt> installed on your system]].

== Download buildroot and the Linux kernel ==

The following section describes how to download the latest
versions of buildroot and of the Linux kernel.
Skip this step if you are using one of the
[http://wiki.linux-xtensa.org/index.php/Buildroot_Snapshots snapshot releases].

Adventurous users that want the use the '''bleeding edge''' code should execute the following:

'''$ cd <workdir>'''
'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa.git buildroot'''
'''$ git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git linux'''

where <tt><workdir></tt> is the path to an empty directory on a disk with
at least 4 GB available space. You end up with the following file structure,
which is assumed by the rest of this document:

<workdir>/
/buildroot
/linux

The MASTER branch of the buildroot repository is often is a state of development.
It's recommended to use the last snapshot for application developers. In the
case of the Avnet development boards a 'snapshot_2+SMP' branch is recommended
in the currently experimental SMP git repository:

'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

If you happen to have write access to either repository you should change '''git:''' to '''git+ssh:'''
For Example:

'''$ git clone git+ssh://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

For more details, see the [http://wiki.linux-xtensa.org/index.php/Repository_Access repository access] page.

== Install any required processor specific overlay ==

This step is required if you are targeting a custom Xtensa processor.
If you use a Diamond 232L Standard Core, you can skip this step.

To configure buildroot and the kernel to use a custom Xtensa processor
configuration, you need to overlay a set of files customized for your
processor configuration onto toolchain sources (gcc, binutils, gdb, etc)
and the Linux kernel. This process has been automated using a script
located in the buildroot source tree.
For usage information, you can invoke it without arguments:

'''$ cd <workdir>'''
'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install'''

which displays a help message similar to the following:

xt-buildroot-overlay-install version 1.3
Usage: xt-buildroot-overlay-install <parameters> [<options>]
Where <parameters> are:
-t file.tgz Specify path to the Xtensa Linux overlay tarball, typically
<xtensa_root>/src/xtensa-config-overlay.tar.gz
-b dir Path to the base of the buildroot source tree, in which
package specific overlay tarballs get installed.
-k dir Path to the base of the Linux kernel source tree, in which
the Linux kernel specific overlay gets installed.
-c config_name Name for the Xtensa processor configuration as it will be
known to the open source community. Must be a lowercase
identifier, starting with a letter, consisting of letters
and numbers and underscores, not ending with underscore
and not containing consecutive underscores. For examples:
dc232b , dc232b_be , mmubasele , fsf , s5000 .
-l long_name Long name for the Xtensa processor configuration, human-
readable with spaces etc allowed (must be quoted).
For example: 'Diamond 232L Standard Core Rev.B (LE)'
Try to keep it within approximately 40 characters.
And <options> are:
-f If package specific overlay tarballs already exist in
the destination source tree, overwrite them without asking.
--help Show this usage message.

Note that the Xtensa Linux overlay tarball MUST be obtained from an Xtensa
core package built using release RB-2008.3 or later.

Here is an example invocation of the overlay installation script:

'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install -t blinkcore-config-overlay.tar.gz''' \
'''-b ./buildroot -k ./linux -c superzip -l "ChipCorp SuperZIP Blink Accelerator Core"'''

The script extracts some relevant information from the overlay tarball,
presents it along with relevant parameters to the user, and prompts
for confirmation before proceeding.

The chosen processor name (-c option) must be unique among known Xtensa processors.
It is also probably wise to avoid names confusingly similar to other (non-Xtensa) processors.
If you expect at some point to contribute support for your custom processor to the
open-source community, this name will likely be long-lived.
(One way to contribute support for a custom processor might be to submit the overlay tarball
or files to the linux-xtensa.org maintainers.)

In the steps below, buildroot and the Linux kernel must be configured
(in their respective <code>''make menuconfig''</code> steps) to select
the <code>''custom''</code> Xtensa processor option.
This presents an extra configuration menu entry where you must provide
the name of the Xtensa processor. Set it to the same name
as was specified in the <code>-c</code> option above.

== Build a toolchain and root filesystem using buildroot ==

'''Note:''' for more details on generic buildroot topics not covered in this simple how-to,
see [http://buildroot.uclibc.org/ buildroot.uclibc.org].

=== Configure buildroot ===

The first time you configure buildroot, start with defaults for your Xtensa processor:

'''$ cd <workdir>/buildroot'''
'''$ ./target/xtensa/setup-config <corename>'''

where ''<corename>'' is the overlay name of your selected Xtensa or Diamond core
(e.g., '''dc232b'''). If you omit ''<corename>'', a help message and a list
of currently installed Tensilica core overlays is displayed.

Optionally, you can then customize your buildroot configuration, such as
selecting additional packages, setting various parameters, and so on.
The following make targets provide a ''curses'' (text-based graphical) interface
for configuring buildroot, the uClibc C library, and busybox, respectively.
('''Note:''' You need the <tt>TERM</tt> environment variable properly set for
these curses based tools to work.)

'''$ make menuconfig'''
'''$ make uclibc-menuconfig'''
'''$ make busybox-menuconfig'''

=== Build buildroot ===

Just type:

'''$ make'''

THIS WILL TAKE A LONG TIME (from about 30 minutes with defaults on a 3 GHz Pentium 4,
to perhaps an hour or many depending on your system and on whether
you enabled extra packages in your buildroot configuration).

Wait patiently for the build to complete. This builds an entire toolchain
as well as some basic packages, and constructs a root filesystem.
It might build many more packages if you selected them earlier with menuconfig.

==== If Something Goes Wrong ====

Perhaps you missed some step above and the build fails. Or you're just switching to a different processor configuration, or making some change with unknown dependencies. Either way, you'll probably need to fix the error and/or make the change, and redo the whole build. The above <tt>make</tt> command usually works fine if you
just added a package using menuconfig, but otherwise does not check many dependencies, so it will usually NOT rebuild things that depend on whatever you have fixed or changed. Here's one way to retry the make from scratch without having to wipe out the <tt>buildroot</tt> directory tree completely and start again from the git cloning.

$ '''rm -rf *build_xtensa* binaries'''
$ '''make'''

It is not necessary to empty the 'dl' subdirectory, which contains tarballs downloaded from the Internet, nor the .config file, which contains the buildroot configuration. Customizations to the uClibc and <tt>busybox</tt> configurations should have ended up getting saved in target/xtensa/uClibc.config and target/xtensa/busybox-config, respectively, so hopefully are preserved by the above sequence.

== Build and Run a Linux Kernel on the XTAV60, AXAV110, or XTAV200 Boards ==

References to the ''XTAV60 board'' refer to the combination of
the Avnet [http://www.em.avnet.com/tensilica1 LX60 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX60 (XT-AV60) Board User's Guide''.

Similarly, references to the ''XTAV200 board'' refers the combination of
the Avnet [http://www.em.avnet.com/tensilica2 LX200 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX200 (XT-AV200) Board User's Guide''.

=== Configure the kernel ===

The kernel build is a two-step process: configure the kernel, and build it.
First, before we can do anything with the kernel, set your PATH to
point to the toolchain built using buildroot.

$ '''export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"'''

where ''<cname>'' is the name of the Xtensa processor configuration you selected
when building the toolchain (e.g., <code>dc232b</code>).

Now setup a destination for kernel builds.
We usually like to have the build directory separate from
the source directory, so we use 'O=</destination/path>' in
kernel make commands. If you'll be routinely building multiple
configurations of the Linux kernel, it's good to have some
naming conventions for the build directory. For example,
to experiment with multiple target platforms but only one
processor configuration, we include just the platform name here:

$'''mkdir build-xtav60'''

Let's start with the default kernel configuration for the Avnet board
(which works on both XTAV60 (LX60), XTAV110 (LX110), and XTAV200 (LX200) boards)
as follows:

$ '''cd linux'''
$ '''make O=../build-xtav60 ARCH=xtensa KBUILD_DEFCONFIG=lx60_defconfig defconfig'''

This configures the kernel using the default configuration found in
'''arch/xtensa/configs/lx60_defconfig'''.

'''NOTE:''' This kernel configuration has nothing to do with Xtensa
processor configuration. That comes next.

Let's now customize this a little bit to select the correct Xtensa processor
configuration, and to bundle the root filesystem into the kernel:

$ '''make O=../build-xtav60 ARCH=xtensa menuconfig'''

Under '''General setup''',
make sure the '''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is enabled. Underneath that, edit '''Initramfs source file(s)''',
and enter the path to the cpio formatted root filesystem
generated by buildroot:

''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio.gz

(Don't forget to replace ''<workdir>'' with the appropriate full path
and ''<cname>'' with your Xtensa processor configuration name.)

Under '''Processor type and features''',
make sure the '''Xtensa Processor Configuration''' is correct and matches
the processor configuration name you used to build the toolchain with buildroot
(for example, ''dc232b'' for Diamond 232L Rev.B).
The kernel build selects a toolchain and processor variant specific headers
based on this selection.
If the desired processor configuration does not appear explicitly in the list,
simply select '''Custom Xtensa processor configuration''' and enter the
processor configuration name (all lowercase) into the next menu parameter,
'''Xtensa Processor Custom Variant Name'''.

Back in the main menu, under '''Platform options''', make sure the
'''CPU clock rate''' entry is set correctly according to the following table:

{| border="1" style="text-align:center; margin: 1em auto 1em auto"
|-
! Board !! Frequency selected in XPG (MHz) !! ''CPU clock rate'' setting (kHz)
|-
|rowspan="3"| XTAV60 (LX60)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV110 (LX110)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV200 (LX200)
| 30 || 31250
|-
| 40 || 41667
|-
| 50 || 50000
|-
|}

Exit menuconfig, saving your configuration changes.

Backup your configuration outside the build directory. For example:

$ '''cp ../build-xtav60/.config config.xtav60.saved'''

If you do a clean rebuild of the kernel (e.g., "rm -rf ../build-xtav60")
you can now configure it with simply:
$ '''mkdir ../build-xtav60 ; cp config.xtav60.saved ../build-xtav60/.config'''
Of course if you update the kernel, you'll probably again have to do:
$ '''make O=../build-xtav60 ARCH=xtensa menuconfig'''
and save a new copy of your configuration.

=== Build the kernel ===

$ '''make O=../build-xtav60 ARCH=xtensa'''

The build will issue a few warnings which are normal.
Once complete, the bootable image is in:
<workdir>/build-xtav60/arch/xtensa/boot/Image.elf
and the uncompressed ELF file containing kernel symbols is in:
<workdir>/build-xtav60/vmlinux
There is also a RedBoot bootable image (if you use RedBoot) in:
<workdir>/build-xtav60/arch/xtensa/boot/zImage.redboot

=== Install Xtensa Tools for the selected core ===

If you opt to download the kernel over OCD, you need <tt>xt-gdb</tt>
which is part of Tensilica's Xtensa Tools package. This must be obtained
from Tensilica, and is not the same toolchain as built by buildroot.
You also need to install the corresponding Tensilica core package,
so that the Xtensa Tools know about your particular configured
Tensilica core.

The toolchain built using buildroot can be configured to
include GDB, but that version of GDB does not support
communicating with Tensilica's Xtensa OCD Daemon, and
thus cannot be used to download the kernel over OCD.

In this example, it is assumed that the machine hosting the
Xtensa Tools has access to the <workdir> directory tree.

=== Install and setup the Xtensa OCD Daemon ===

Setup and connect your JTAG probe, etc.

=== Connect a terminal server ===

At 38400 bps 8N1 no flow control to the XTAV60 serial port.

=== Optionally, setup networking ===

This step is optional.

Setup the board's MAC address using dipswitches
(see XTAV60 or XTAV200 board docs as appropriate)
and connect the board to a network that has a
DHCP server that will respond to that MAC address.
If you don't do this step, you'll simply not have network
access, and the boot process will take a minute or so longer
while the kernel times out waiting for a BOOTP response.
You can edit the kernel configuration and rebuild the kernel
to avoid using bootp (in particular, remove "ip=bootp" from
the kernel cmdline).

=== Download and run the kernel ===

Reset the board (see board documentation).

Using Xtensa Tools, invoke:

$ '''xt-gdb <workdir>/build-xtav60/arch/xtensa/boot/Image.elf'''

'''(xt-gdb) target remote <ocdhost>:20000 0'''
'''(xt-gdb) reset'''
'''(xt-gdb) load'''
'''(xt-gdb) set $pc = &_ResetVector'''
'''(xt-gdb) symbol-file <workdir>/build-xtav60/vmlinux'''
'''(xt-gdb) c'''

where <ocdhost> is the IP address or DNS name of the machine
running the Xtensa OCD daemon. The Linux kernel should
start booting as soon as 'c' (continue) is executed.

You should eventually get a login prompt.
Just login as root (no password).

Try various Linux commands. Look at <tt>/bin</tt>,
<tt>/sbin</tt>, <tt>/usr/bin</tt>, etc to see what's available.

Note: no need to setup an NFS or TFTP server. The filesystem
is contained within the kernel image. You may be able to mount
other filesystems over NFS though, if you wish, after booting.

=== Mounting the Root Filesystem Over NFS ===

If you build more than the minimal set of packages using
buildroot, the root filesystem can easily grow too large to
fit comfortably (or at all) inside the kernel. In this case,
rather than follow the instructions exactly as above,
you'll want to mount the root filesystem over NFS.

You may also want to mount the root filesystem over NFS to
make changes to the filesystem persistent across runs and
accessible from your development host.

First you need to install the root filesystem generated
using buildroot, to a machine that can serve it over NFS.
Assuming this machine runs Linux, one way to install it is
as follows:

mkdir ''<exportpath>''
cd ''<exportpath>''
sudo cpio -i -d -m -F ''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio --no-absolute-filenames

You then need to enable the NFS server on your system
(if not already active), and export this filesystem.
How you do this depends on your host Linux distribution.
For example, on some Fedora releases, one might:

* add the export path to <tt>/etc/exports</tt> using a line such as

''<exportpath>'' *(rw,sync,no_root_squash,no_all_squash)

* turn on the NFS server if needed:

sudo /sbin/chkconfig nfs on

* tell the NFS server about the new exported filesystem

sudo /usr/sbin/exportfs -a
sudo /usr/sbin/exportfs -r

Second, follow the instructions in the previous sections,
then configure the kernel again as follows.

Under '''General setup''', make sure the
'''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is disabled (rather than enabled as done in previous sections).

Under '''Platform options''', under the line '''Default bootloader kernel arguments''',
select the boot parameters line and set it to something like this:

console=ttyS0,38400 ip=dhcp root=/dev/nfs rw nfsroot=''<server_ip>'':''<exportpath>''

where ''<server_ip>'' is the IP address of your NFS server, and ''<exportpath>''
is the exported filesystem path.

Save this configuration, rebuild the kernel, and follow the
instructions in previous sections to download and run the kernel.
If everything goes well and is setup correctly, your kernel should
now boot with a root filesystem mounted over NFS.

== Build and Run a Linux Kernel on the Instruction Set Simulator (ISS) ==

You can build and run a Linux kernel in the Xtensa Instruction Set
Simulator (ISS). The following instructions have only been tried
with an ISS from the RB-2008.3 release of Xtensa Tools. Bear in
mind that the XTAV60 port is likely much more stable than the ISS port
of Linux at this point in time.

Note: Depending on your host OS version, you may need to install
Xtensa Tools on a separate machine.

=== Configure and Build the Kernel for ISS ===

Repeat all the same instructions as above for building the kernel for an
Avnet board, except that when initially configuring the kernel,
start from a ISS platform template instead. For example for the
DC233C Variant:

'''$ mkdir build-iss'''
'''$ cd linux'''
'''$ make O=../build-iss ARCH=xtensa KBUILD_DEFCONFIG=iss_dc233c_defconfig defconfig'''

The above make example configures the kernel using the default configuration found in
'''arch/xtensa/configs/iss_dc233_defconfig'''. Most important to note is that the
root file system mounted when Linux boots comes via the targets device '''/dev/simdisk0'''
which is defined in the kernel '''.config''' file. For example:

'''CONFIG_SIMDISK0_FILENAME="/export2/DC_C_233L/LINUX_ROOT.ext2"'''

The SIMDISK file name and VARIANT name are typically configured when running '''make menuconfig'''; Ex:

'''$ make O=../build-iss ARCH=xtensa menuconfig'''

and selecting

'''Xtensa Platform options''' ---> '''Host filename for a simulated device'''

and entering the pathname to the .ext2 file there. Ex: '''/export2/DC_C_233L/LINUX_ROOT.ext2'''

You often want to change the VARIANT to the one you desire, Ex: FSF. You do this via
the top level menu:

'''Xtensa Processor type and features ---> Xtensa Processor Custom Core Variant Name'''

With the new SIMDISK approach you copy the EXT2 Filesystem file generated by Buildroot
to a location to be accessed by Xtensa Linux. Ex:

'''$ cp /export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot/binaries/dc233c/rootfs.xtensa_dc233c.ext2 /export2/DC_C_233L/LINUX_ROOT.ext2'''

'''NOTE:''' There is an old '''iss_defconfig''' that tries to use a '''tuntap''' Ethernet
interface that currently isn't supported.
Previously with this old iss_defconfig using the '''tuntap''' Ethernet interface
it was suggested to set up the initramfs filesystem, and do the following.
Under '''Bus Options''', deselect '''PCI support'''.
Under '''Platform Options''', deselect '''Default bootloader kernel arguments'''.
Hopefully we will someday be able to support the use of a network interface with
ISS simulation and then be able to mount NFS root partitions again. So I'm leaving
this note for future exploration of this mechanism; Hope you don't mind the clutter.

Continue configuring and building the kernel as usual.

=== Run the Kernel on ISS ===

Using Xtensa Tools, invoke:

'''$ xt-gdb <workdir>/build-iss/arch/xtensa/boot/Image.elf'''
'''(xt-gdb) target sim --turbo --memlimit=128'''
'''(xt-gdb) symbol-file <workdir>/build-iss/vmlinux'''
'''(xt-gdb) run'''

Wait patiently while Linux boots ... (maybe a minute). The setting of the '''memlimit'''
needs to match the PLATFORM_DEFAULT_MEM_SIZE defined in /arch/xtensa/platforms/iss/include/platform/hardware.h.
Currently this limit us 128 MegaBytes:

#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000 /* 13,4217,728 128M */

and we will be extending this for the DC233L to take advantage of it's V3 MMU.

Login as root (no password).

'''Note:''' Input via ISS is cooked, so everything typed gets echoed.
Also, time as reported by the kernel does not progress
according to true wall-clock time: it currently depends on
a simulated processor clock, which advances at various speeds
according to load.

Instructions for building and booting Linux

2011-01-06T04:30:37Z

Piet: /* Build the kernel */

These instructions explain how to build a toolchain, root filesystem and kernel for Linux running on an Xtensa processor. These instructions apply specifically to the XTAV60 (LX60) board.

Some general notes on these instructions:

* They are a work in progress. If you are using the latest development sources, the build process may change, so you should be sure to get the latest version of this document at [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions]. If you are using one of the development snapshot releases, you should use the version of the build instructions included with that snapshot.

* The following was tested on x86 machines running RedHat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3). It is expected to work on newer Fedora releases (e.g., was tested on FC6) but to maintain host compatibility with Xtensa Tools, it is best to avoid Fedora releases beyond FC5. Other host distributions likely work but have not been tested.
** '''NOTE:''' this assumes the default selection of packages in buildroot. Selecting extra packages may require a more recent host OS or more recent version of certain tools. For example, the default version of <tt>find</tt> on RHEL4 is too old to allow building all X11 packages in buildroot, so it is necessary to upgrade the host version of <tt>findutils</tt> on RHEL4 to build these packages.

* Lines prefixed with "sudo" need to be executed as root. The rest is best executed as a non-root user. (It is possible to install <tt>git</tt> as a non-root user if root access is an issue. How to do this isn't shown here.)

* Lines that set environment variables assume a Bourne compatible shell (e.g., /bin/sh or bash), but are easily adapted to other shells.

* Instructions are assumed executed all in order (e.g., commands assume current directory and environment variables set earlier).

== Setup your host system ==

If you are using one of the snapshot releases, you can skip this step.

If you want to work with the latest development sources, you will need
[[Installing GIT|<tt>git</tt> installed on your system]].

== Download buildroot and the Linux kernel ==

The following section describes how to download the latest
versions of buildroot and of the Linux kernel.
Skip this step if you are using one of the
[http://wiki.linux-xtensa.org/index.php/Buildroot_Snapshots snapshot releases].

Adventurous users that want the use the '''bleeding edge''' code should execute the following:

'''$ cd <workdir>'''
'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa.git buildroot'''
'''$ git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git linux'''

where <tt><workdir></tt> is the path to an empty directory on a disk with
at least 4 GB available space. You end up with the following file structure,
which is assumed by the rest of this document:

<workdir>/
/buildroot
/linux

The MASTER branch of the buildroot repository is often is a state of development.
It's recommended to use the last snapshot for application developers. In the
case of the Avnet development boards a 'snapshot_2+SMP' branch is recommended
in the currently experimental SMP git repository:

'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

If you happen to have write access to either repository you should change '''git:''' to '''git+ssh:'''
For Example:

'''$ git clone git+ssh://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

For more details, see the [http://wiki.linux-xtensa.org/index.php/Repository_Access repository access] page.

== Install any required processor specific overlay ==

This step is required if you are targeting a custom Xtensa processor.
If you use a Diamond 232L Standard Core, you can skip this step.

To configure buildroot and the kernel to use a custom Xtensa processor
configuration, you need to overlay a set of files customized for your
processor configuration onto toolchain sources (gcc, binutils, gdb, etc)
and the Linux kernel. This process has been automated using a script
located in the buildroot source tree.
For usage information, you can invoke it without arguments:

'''$ cd <workdir>'''
'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install'''

which displays a help message similar to the following:

xt-buildroot-overlay-install version 1.3
Usage: xt-buildroot-overlay-install <parameters> [<options>]
Where <parameters> are:
-t file.tgz Specify path to the Xtensa Linux overlay tarball, typically
<xtensa_root>/src/xtensa-config-overlay.tar.gz
-b dir Path to the base of the buildroot source tree, in which
package specific overlay tarballs get installed.
-k dir Path to the base of the Linux kernel source tree, in which
the Linux kernel specific overlay gets installed.
-c config_name Name for the Xtensa processor configuration as it will be
known to the open source community. Must be a lowercase
identifier, starting with a letter, consisting of letters
and numbers and underscores, not ending with underscore
and not containing consecutive underscores. For examples:
dc232b , dc232b_be , mmubasele , fsf , s5000 .
-l long_name Long name for the Xtensa processor configuration, human-
readable with spaces etc allowed (must be quoted).
For example: 'Diamond 232L Standard Core Rev.B (LE)'
Try to keep it within approximately 40 characters.
And <options> are:
-f If package specific overlay tarballs already exist in
the destination source tree, overwrite them without asking.
--help Show this usage message.

Note that the Xtensa Linux overlay tarball MUST be obtained from an Xtensa
core package built using release RB-2008.3 or later.

Here is an example invocation of the overlay installation script:

'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install -t blinkcore-config-overlay.tar.gz''' \
'''-b ./buildroot -k ./linux -c superzip -l "ChipCorp SuperZIP Blink Accelerator Core"'''

The script extracts some relevant information from the overlay tarball,
presents it along with relevant parameters to the user, and prompts
for confirmation before proceeding.

The chosen processor name (-c option) must be unique among known Xtensa processors.
It is also probably wise to avoid names confusingly similar to other (non-Xtensa) processors.
If you expect at some point to contribute support for your custom processor to the
open-source community, this name will likely be long-lived.
(One way to contribute support for a custom processor might be to submit the overlay tarball
or files to the linux-xtensa.org maintainers.)

In the steps below, buildroot and the Linux kernel must be configured
(in their respective <code>''make menuconfig''</code> steps) to select
the <code>''custom''</code> Xtensa processor option.
This presents an extra configuration menu entry where you must provide
the name of the Xtensa processor. Set it to the same name
as was specified in the <code>-c</code> option above.

== Build a toolchain and root filesystem using buildroot ==

'''Note:''' for more details on generic buildroot topics not covered in this simple how-to,
see [http://buildroot.uclibc.org/ buildroot.uclibc.org].

=== Configure buildroot ===

The first time you configure buildroot, start with defaults for your Xtensa processor:

'''$ cd <workdir>/buildroot'''
'''$ ./target/xtensa/setup-config <corename>'''

where ''<corename>'' is the overlay name of your selected Xtensa or Diamond core
(e.g., '''dc232b'''). If you omit ''<corename>'', a help message and a list
of currently installed Tensilica core overlays is displayed.

Optionally, you can then customize your buildroot configuration, such as
selecting additional packages, setting various parameters, and so on.
The following make targets provide a ''curses'' (text-based graphical) interface
for configuring buildroot, the uClibc C library, and busybox, respectively.
('''Note:''' You need the <tt>TERM</tt> environment variable properly set for
these curses based tools to work.)

'''$ make menuconfig'''
'''$ make uclibc-menuconfig'''
'''$ make busybox-menuconfig'''

=== Build buildroot ===

Just type:

'''$ make'''

THIS WILL TAKE A LONG TIME (from about 30 minutes with defaults on a 3 GHz Pentium 4,
to perhaps an hour or many depending on your system and on whether
you enabled extra packages in your buildroot configuration).

Wait patiently for the build to complete. This builds an entire toolchain
as well as some basic packages, and constructs a root filesystem.
It might build many more packages if you selected them earlier with menuconfig.

==== If Something Goes Wrong ====

Perhaps you missed some step above and the build fails. Or you're just switching to a different processor configuration, or making some change with unknown dependencies. Either way, you'll probably need to fix the error and/or make the change, and redo the whole build. The above <tt>make</tt> command usually works fine if you
just added a package using menuconfig, but otherwise does not check many dependencies, so it will usually NOT rebuild things that depend on whatever you have fixed or changed. Here's one way to retry the make from scratch without having to wipe out the <tt>buildroot</tt> directory tree completely and start again from the git cloning.

$ '''rm -rf *build_xtensa* binaries'''
$ '''make'''

It is not necessary to empty the 'dl' subdirectory, which contains tarballs downloaded from the Internet, nor the .config file, which contains the buildroot configuration. Customizations to the uClibc and <tt>busybox</tt> configurations should have ended up getting saved in target/xtensa/uClibc.config and target/xtensa/busybox-config, respectively, so hopefully are preserved by the above sequence.

== Build and Run a Linux Kernel on the XTAV60, AXAV110, or XTAV200 Boards ==

References to the ''XTAV60 board'' refer to the combination of
the Avnet [http://www.em.avnet.com/tensilica1 LX60 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX60 (XT-AV60) Board User's Guide''.

Similarly, references to the ''XTAV200 board'' refers the combination of
the Avnet [http://www.em.avnet.com/tensilica2 LX200 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX200 (XT-AV200) Board User's Guide''.

=== Configure the kernel ===

The kernel build is a two-step process: configure the kernel, and build it.
First, before we can do anything with the kernel, set your PATH to
point to the toolchain built using buildroot.

$ '''export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"'''

where ''<cname>'' is the name of the Xtensa processor configuration you selected
when building the toolchain (e.g., <code>dc232b</code>).

Now setup a destination for kernel builds.
We usually like to have the build directory separate from
the source directory, so we use 'O=</destination/path>' in
kernel make commands. If you'll be routinely building multiple
configurations of the Linux kernel, it's good to have some
naming conventions for the build directory. For example,
to experiment with multiple target platforms but only one
processor configuration, we include just the platform name here:

$'''mkdir build-xtav60'''

Let's start with the default kernel configuration for the Avnet board
(which works on both XTAV60 (LX60), XTAV110 (LX110), and XTAV200 (LX200) boards)
as follows:

$ '''cd linux'''
$ '''make O=../build-xtav60 ARCH=xtensa KBUILD_DEFCONFIG=lx60_defconfig defconfig'''

This configures the kernel using the default configuration found in
'''arch/xtensa/configs/lx60_defconfig'''.

'''NOTE:''' This kernel configuration has nothing to do with Xtensa
processor configuration. That comes next.

Let's now customize this a little bit to select the correct Xtensa processor
configuration, and to bundle the root filesystem into the kernel:

$ '''make O=../build-xtav60 ARCH=xtensa menuconfig'''

Under '''General setup''',
make sure the '''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is enabled. Underneath that, edit '''Initramfs source file(s)''',
and enter the path to the cpio formatted root filesystem
generated by buildroot:

''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio.gz

(Don't forget to replace ''<workdir>'' with the appropriate full path
and ''<cname>'' with your Xtensa processor configuration name.)

Under '''Processor type and features''',
make sure the '''Xtensa Processor Configuration''' is correct and matches
the processor configuration name you used to build the toolchain with buildroot
(for example, ''dc232b'' for Diamond 232L Rev.B).
The kernel build selects a toolchain and processor variant specific headers
based on this selection.
If the desired processor configuration does not appear explicitly in the list,
simply select '''Custom Xtensa processor configuration''' and enter the
processor configuration name (all lowercase) into the next menu parameter,
'''Xtensa Processor Custom Variant Name'''.

Back in the main menu, under '''Platform options''', make sure the
'''CPU clock rate''' entry is set correctly according to the following table:

{| border="1" style="text-align:center; margin: 1em auto 1em auto"
|-
! Board !! Frequency selected in XPG (MHz) !! ''CPU clock rate'' setting (kHz)
|-
|rowspan="3"| XTAV60 (LX60)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV110 (LX110)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV200 (LX200)
| 30 || 31250
|-
| 40 || 41667
|-
| 50 || 50000
|-
|}

Exit menuconfig, saving your configuration changes.

Backup your configuration outside the build directory. For example:

$ '''cp ../build-xtav60/.config config.xtav60.saved'''

If you do a clean rebuild of the kernel (e.g., "rm -rf ../build-xtav60")
you can now configure it with simply:
$ '''mkdir ../build-xtav60 ; cp config.xtav60.saved ../build-xtav60/.config'''
Of course if you update the kernel, you'll probably again have to do:
$ '''make O=../build-xtav60 ARCH=xtensa menuconfig'''
and save a new copy of your configuration.

=== Build the kernel ===

$ '''make O=../build-xtav60 ARCH=xtensa'''

The build will issue a few warnings which are normal.
Once complete, the bootable image is in:
<workdir>/build-xtav60/arch/xtensa/boot/Image.elf
and the uncompressed ELF file containing kernel symbols is in:
<workdir>/build-xtav60/vmlinux
There is also a RedBoot bootable image (if you use RedBoot) in:
<workdir>/build-xtav60/arch/xtensa/boot/zImage.redboot

=== Install Xtensa Tools for the selected core ===

If you opt to download the kernel over OCD, you need <tt>xt-gdb</tt>
which is part of Tensilica's Xtensa Tools package. This must be obtained
from Tensilica, and is not the same toolchain as built by buildroot.
You also need to install the corresponding Tensilica core package,
so that the Xtensa Tools know about your particular configured
Tensilica core.

The toolchain built using buildroot can be configured to
include GDB, but that version of GDB does not support
communicating with Tensilica's Xtensa OCD Daemon, and
thus cannot be used to download the kernel over OCD.

In this example, it is assumed that the machine hosting the
Xtensa Tools has access to the <workdir> directory tree.

=== Install and setup the Xtensa OCD Daemon ===

Setup and connect your JTAG probe, etc.

=== Connect a terminal server ===

At 38400 bps 8N1 no flow control to the XTAV60 serial port.

=== Optionally, setup networking ===

This step is optional.

Setup the board's MAC address using dipswitches
(see XTAV60 or XTAV200 board docs as appropriate)
and connect the board to a network that has a
DHCP server that will respond to that MAC address.
If you don't do this step, you'll simply not have network
access, and the boot process will take a minute or so longer
while the kernel times out waiting for a BOOTP response.
You can edit the kernel configuration and rebuild the kernel
to avoid using bootp (in particular, remove "ip=bootp" from
the kernel cmdline).

=== Download and run the kernel ===

Reset the board (see board documentation).

Using Xtensa Tools, invoke:

$ xt-gdb <workdir>/build-xtav60/arch/xtensa/boot/Image.elf

(xt-gdb) target remote <ocdhost>:20000 0
(xt-gdb) reset
(xt-gdb) load
(xt-gdb) set $pc = &_ResetVector
(xt-gdb) symbol-file <workdir>/build-xtav60/vmlinux
(xt-gdb) c

where <ocdhost> is the IP address or DNS name of the machine
running the Xtensa OCD daemon. The Linux kernel should
start booting as soon as 'c' (continue) is executed.

You should eventually get a login prompt.
Just login as root (no password).

Try various Linux commands. Look at <tt>/bin</tt>,
<tt>/sbin</tt>, <tt>/usr/bin</tt>, etc to see what's available.

Note: no need to setup an NFS or TFTP server. The filesystem
is contained within the kernel image. You may be able to mount
other filesystems over NFS though, if you wish, after booting.

=== Mounting the Root Filesystem Over NFS ===

If you build more than the minimal set of packages using
buildroot, the root filesystem can easily grow too large to
fit comfortably (or at all) inside the kernel. In this case,
rather than follow the instructions exactly as above,
you'll want to mount the root filesystem over NFS.

You may also want to mount the root filesystem over NFS to
make changes to the filesystem persistent across runs and
accessible from your development host.

First you need to install the root filesystem generated
using buildroot, to a machine that can serve it over NFS.
Assuming this machine runs Linux, one way to install it is
as follows:

mkdir ''<exportpath>''
cd ''<exportpath>''
sudo cpio -i -d -m -F ''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio --no-absolute-filenames

You then need to enable the NFS server on your system
(if not already active), and export this filesystem.
How you do this depends on your host Linux distribution.
For example, on some Fedora releases, one might:

* add the export path to <tt>/etc/exports</tt> using a line such as

''<exportpath>'' *(rw,sync,no_root_squash,no_all_squash)

* turn on the NFS server if needed:

sudo /sbin/chkconfig nfs on

* tell the NFS server about the new exported filesystem

sudo /usr/sbin/exportfs -a
sudo /usr/sbin/exportfs -r

Second, follow the instructions in the previous sections,
then configure the kernel again as follows.

Under '''General setup''', make sure the
'''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is disabled (rather than enabled as done in previous sections).

Under '''Platform options''', under the line '''Default bootloader kernel arguments''',
select the boot parameters line and set it to something like this:

console=ttyS0,38400 ip=dhcp root=/dev/nfs rw nfsroot=''<server_ip>'':''<exportpath>''

where ''<server_ip>'' is the IP address of your NFS server, and ''<exportpath>''
is the exported filesystem path.

Save this configuration, rebuild the kernel, and follow the
instructions in previous sections to download and run the kernel.
If everything goes well and is setup correctly, your kernel should
now boot with a root filesystem mounted over NFS.

== Build and Run a Linux Kernel on the Instruction Set Simulator (ISS) ==

You can build and run a Linux kernel in the Xtensa Instruction Set
Simulator (ISS). The following instructions have only been tried
with an ISS from the RB-2008.3 release of Xtensa Tools. Bear in
mind that the XTAV60 port is likely much more stable than the ISS port
of Linux at this point in time.

Note: Depending on your host OS version, you may need to install
Xtensa Tools on a separate machine.

=== Configure and Build the Kernel for ISS ===

Repeat all the same instructions as above for building the kernel for an
Avnet board, except that when initially configuring the kernel,
start from a ISS platform template instead. For example for the
DC233C Variant:

'''$ mkdir build-iss'''
'''$ cd linux'''
'''$ make O=../build-iss ARCH=xtensa KBUILD_DEFCONFIG=iss_dc233c_defconfig defconfig'''

The above make example configures the kernel using the default configuration found in
'''arch/xtensa/configs/iss_dc233_defconfig'''. Most important to note is that the
root file system mounted when Linux boots comes via the targets device '''/dev/simdisk0'''
which is defined in the kernel '''.config''' file. For example:

'''CONFIG_SIMDISK0_FILENAME="/export2/DC_C_233L/LINUX_ROOT.ext2"'''

The SIMDISK file name and VARIANT name are typically configured when running '''make menuconfig'''; Ex:

'''$ make O=../build-iss ARCH=xtensa menuconfig'''

and selecting

'''Xtensa Platform options''' ---> '''Host filename for a simulated device'''

and entering the pathname to the .ext2 file there. Ex: '''/export2/DC_C_233L/LINUX_ROOT.ext2'''

You often want to change the VARIANT to the one you desire, Ex: FSF. You do this via
the top level menu:

'''Xtensa Processor type and features ---> Xtensa Processor Custom Core Variant Name'''

With the new SIMDISK approach you copy the EXT2 Filesystem file generated by Buildroot
to a location to be accessed by Xtensa Linux. Ex:

'''$ cp /export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot/binaries/dc233c/rootfs.xtensa_dc233c.ext2 /export2/DC_C_233L/LINUX_ROOT.ext2'''

'''NOTE:''' There is an old '''iss_defconfig''' that tries to use a '''tuntap''' Ethernet
interface that currently isn't supported.
Previously with this old iss_defconfig using the '''tuntap''' Ethernet interface
it was suggested to set up the initramfs filesystem, and do the following.
Under '''Bus Options''', deselect '''PCI support'''.
Under '''Platform Options''', deselect '''Default bootloader kernel arguments'''.
Hopefully we will someday be able to support the use of a network interface with
ISS simulation and then be able to mount NFS root partitions again. So I'm leaving
this note for future exploration of this mechanism; Hope you don't mind the clutter.

Continue configuring and building the kernel as usual.

=== Run the Kernel on ISS ===

Using Xtensa Tools, invoke:

'''$ xt-gdb <workdir>/build-iss/arch/xtensa/boot/Image.elf'''
'''(xt-gdb) target sim --turbo --memlimit=128'''
'''(xt-gdb) symbol-file <workdir>/build-iss/vmlinux'''
'''(xt-gdb) run'''

Wait patiently while Linux boots ... (maybe a minute). The setting of the '''memlimit'''
needs to match the PLATFORM_DEFAULT_MEM_SIZE defined in /arch/xtensa/platforms/iss/include/platform/hardware.h.
Currently this limit us 128 MegaBytes:

#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000 /* 13,4217,728 128M */

and we will be extending this for the DC233L to take advantage of it's V3 MMU.

Login as root (no password).

'''Note:''' Input via ISS is cooked, so everything typed gets echoed.
Also, time as reported by the kernel does not progress
according to true wall-clock time: it currently depends on
a simulated processor clock, which advances at various speeds
according to load.

Instructions for building and booting Linux

2011-01-06T04:30:16Z

Piet: /* Configure the kernel */

These instructions explain how to build a toolchain, root filesystem and kernel for Linux running on an Xtensa processor. These instructions apply specifically to the XTAV60 (LX60) board.

Some general notes on these instructions:

* They are a work in progress. If you are using the latest development sources, the build process may change, so you should be sure to get the latest version of this document at [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions]. If you are using one of the development snapshot releases, you should use the version of the build instructions included with that snapshot.

* The following was tested on x86 machines running RedHat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3). It is expected to work on newer Fedora releases (e.g., was tested on FC6) but to maintain host compatibility with Xtensa Tools, it is best to avoid Fedora releases beyond FC5. Other host distributions likely work but have not been tested.
** '''NOTE:''' this assumes the default selection of packages in buildroot. Selecting extra packages may require a more recent host OS or more recent version of certain tools. For example, the default version of <tt>find</tt> on RHEL4 is too old to allow building all X11 packages in buildroot, so it is necessary to upgrade the host version of <tt>findutils</tt> on RHEL4 to build these packages.

* Lines prefixed with "sudo" need to be executed as root. The rest is best executed as a non-root user. (It is possible to install <tt>git</tt> as a non-root user if root access is an issue. How to do this isn't shown here.)

* Lines that set environment variables assume a Bourne compatible shell (e.g., /bin/sh or bash), but are easily adapted to other shells.

* Instructions are assumed executed all in order (e.g., commands assume current directory and environment variables set earlier).

== Setup your host system ==

If you are using one of the snapshot releases, you can skip this step.

If you want to work with the latest development sources, you will need
[[Installing GIT|<tt>git</tt> installed on your system]].

== Download buildroot and the Linux kernel ==

The following section describes how to download the latest
versions of buildroot and of the Linux kernel.
Skip this step if you are using one of the
[http://wiki.linux-xtensa.org/index.php/Buildroot_Snapshots snapshot releases].

Adventurous users that want the use the '''bleeding edge''' code should execute the following:

'''$ cd <workdir>'''
'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa.git buildroot'''
'''$ git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git linux'''

where <tt><workdir></tt> is the path to an empty directory on a disk with
at least 4 GB available space. You end up with the following file structure,
which is assumed by the rest of this document:

<workdir>/
/buildroot
/linux

The MASTER branch of the buildroot repository is often is a state of development.
It's recommended to use the last snapshot for application developers. In the
case of the Avnet development boards a 'snapshot_2+SMP' branch is recommended
in the currently experimental SMP git repository:

'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

If you happen to have write access to either repository you should change '''git:''' to '''git+ssh:'''
For Example:

'''$ git clone git+ssh://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

For more details, see the [http://wiki.linux-xtensa.org/index.php/Repository_Access repository access] page.

== Install any required processor specific overlay ==

This step is required if you are targeting a custom Xtensa processor.
If you use a Diamond 232L Standard Core, you can skip this step.

To configure buildroot and the kernel to use a custom Xtensa processor
configuration, you need to overlay a set of files customized for your
processor configuration onto toolchain sources (gcc, binutils, gdb, etc)
and the Linux kernel. This process has been automated using a script
located in the buildroot source tree.
For usage information, you can invoke it without arguments:

'''$ cd <workdir>'''
'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install'''

which displays a help message similar to the following:

xt-buildroot-overlay-install version 1.3
Usage: xt-buildroot-overlay-install <parameters> [<options>]
Where <parameters> are:
-t file.tgz Specify path to the Xtensa Linux overlay tarball, typically
<xtensa_root>/src/xtensa-config-overlay.tar.gz
-b dir Path to the base of the buildroot source tree, in which
package specific overlay tarballs get installed.
-k dir Path to the base of the Linux kernel source tree, in which
the Linux kernel specific overlay gets installed.
-c config_name Name for the Xtensa processor configuration as it will be
known to the open source community. Must be a lowercase
identifier, starting with a letter, consisting of letters
and numbers and underscores, not ending with underscore
and not containing consecutive underscores. For examples:
dc232b , dc232b_be , mmubasele , fsf , s5000 .
-l long_name Long name for the Xtensa processor configuration, human-
readable with spaces etc allowed (must be quoted).
For example: 'Diamond 232L Standard Core Rev.B (LE)'
Try to keep it within approximately 40 characters.
And <options> are:
-f If package specific overlay tarballs already exist in
the destination source tree, overwrite them without asking.
--help Show this usage message.

Note that the Xtensa Linux overlay tarball MUST be obtained from an Xtensa
core package built using release RB-2008.3 or later.

Here is an example invocation of the overlay installation script:

'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install -t blinkcore-config-overlay.tar.gz''' \
'''-b ./buildroot -k ./linux -c superzip -l "ChipCorp SuperZIP Blink Accelerator Core"'''

The script extracts some relevant information from the overlay tarball,
presents it along with relevant parameters to the user, and prompts
for confirmation before proceeding.

The chosen processor name (-c option) must be unique among known Xtensa processors.
It is also probably wise to avoid names confusingly similar to other (non-Xtensa) processors.
If you expect at some point to contribute support for your custom processor to the
open-source community, this name will likely be long-lived.
(One way to contribute support for a custom processor might be to submit the overlay tarball
or files to the linux-xtensa.org maintainers.)

In the steps below, buildroot and the Linux kernel must be configured
(in their respective <code>''make menuconfig''</code> steps) to select
the <code>''custom''</code> Xtensa processor option.
This presents an extra configuration menu entry where you must provide
the name of the Xtensa processor. Set it to the same name
as was specified in the <code>-c</code> option above.

== Build a toolchain and root filesystem using buildroot ==

'''Note:''' for more details on generic buildroot topics not covered in this simple how-to,
see [http://buildroot.uclibc.org/ buildroot.uclibc.org].

=== Configure buildroot ===

The first time you configure buildroot, start with defaults for your Xtensa processor:

'''$ cd <workdir>/buildroot'''
'''$ ./target/xtensa/setup-config <corename>'''

where ''<corename>'' is the overlay name of your selected Xtensa or Diamond core
(e.g., '''dc232b'''). If you omit ''<corename>'', a help message and a list
of currently installed Tensilica core overlays is displayed.

Optionally, you can then customize your buildroot configuration, such as
selecting additional packages, setting various parameters, and so on.
The following make targets provide a ''curses'' (text-based graphical) interface
for configuring buildroot, the uClibc C library, and busybox, respectively.
('''Note:''' You need the <tt>TERM</tt> environment variable properly set for
these curses based tools to work.)

'''$ make menuconfig'''
'''$ make uclibc-menuconfig'''
'''$ make busybox-menuconfig'''

=== Build buildroot ===

Just type:

'''$ make'''

THIS WILL TAKE A LONG TIME (from about 30 minutes with defaults on a 3 GHz Pentium 4,
to perhaps an hour or many depending on your system and on whether
you enabled extra packages in your buildroot configuration).

Wait patiently for the build to complete. This builds an entire toolchain
as well as some basic packages, and constructs a root filesystem.
It might build many more packages if you selected them earlier with menuconfig.

==== If Something Goes Wrong ====

Perhaps you missed some step above and the build fails. Or you're just switching to a different processor configuration, or making some change with unknown dependencies. Either way, you'll probably need to fix the error and/or make the change, and redo the whole build. The above <tt>make</tt> command usually works fine if you
just added a package using menuconfig, but otherwise does not check many dependencies, so it will usually NOT rebuild things that depend on whatever you have fixed or changed. Here's one way to retry the make from scratch without having to wipe out the <tt>buildroot</tt> directory tree completely and start again from the git cloning.

$ '''rm -rf *build_xtensa* binaries'''
$ '''make'''

It is not necessary to empty the 'dl' subdirectory, which contains tarballs downloaded from the Internet, nor the .config file, which contains the buildroot configuration. Customizations to the uClibc and <tt>busybox</tt> configurations should have ended up getting saved in target/xtensa/uClibc.config and target/xtensa/busybox-config, respectively, so hopefully are preserved by the above sequence.

== Build and Run a Linux Kernel on the XTAV60, AXAV110, or XTAV200 Boards ==

References to the ''XTAV60 board'' refer to the combination of
the Avnet [http://www.em.avnet.com/tensilica1 LX60 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX60 (XT-AV60) Board User's Guide''.

Similarly, references to the ''XTAV200 board'' refers the combination of
the Avnet [http://www.em.avnet.com/tensilica2 LX200 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX200 (XT-AV200) Board User's Guide''.

=== Configure the kernel ===

The kernel build is a two-step process: configure the kernel, and build it.
First, before we can do anything with the kernel, set your PATH to
point to the toolchain built using buildroot.

$ '''export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"'''

where ''<cname>'' is the name of the Xtensa processor configuration you selected
when building the toolchain (e.g., <code>dc232b</code>).

Now setup a destination for kernel builds.
We usually like to have the build directory separate from
the source directory, so we use 'O=</destination/path>' in
kernel make commands. If you'll be routinely building multiple
configurations of the Linux kernel, it's good to have some
naming conventions for the build directory. For example,
to experiment with multiple target platforms but only one
processor configuration, we include just the platform name here:

$'''mkdir build-xtav60'''

Let's start with the default kernel configuration for the Avnet board
(which works on both XTAV60 (LX60), XTAV110 (LX110), and XTAV200 (LX200) boards)
as follows:

$ '''cd linux'''
$ '''make O=../build-xtav60 ARCH=xtensa KBUILD_DEFCONFIG=lx60_defconfig defconfig'''

This configures the kernel using the default configuration found in
'''arch/xtensa/configs/lx60_defconfig'''.

'''NOTE:''' This kernel configuration has nothing to do with Xtensa
processor configuration. That comes next.

Let's now customize this a little bit to select the correct Xtensa processor
configuration, and to bundle the root filesystem into the kernel:

$ '''make O=../build-xtav60 ARCH=xtensa menuconfig'''

Under '''General setup''',
make sure the '''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is enabled. Underneath that, edit '''Initramfs source file(s)''',
and enter the path to the cpio formatted root filesystem
generated by buildroot:

''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio.gz

(Don't forget to replace ''<workdir>'' with the appropriate full path
and ''<cname>'' with your Xtensa processor configuration name.)

Under '''Processor type and features''',
make sure the '''Xtensa Processor Configuration''' is correct and matches
the processor configuration name you used to build the toolchain with buildroot
(for example, ''dc232b'' for Diamond 232L Rev.B).
The kernel build selects a toolchain and processor variant specific headers
based on this selection.
If the desired processor configuration does not appear explicitly in the list,
simply select '''Custom Xtensa processor configuration''' and enter the
processor configuration name (all lowercase) into the next menu parameter,
'''Xtensa Processor Custom Variant Name'''.

Back in the main menu, under '''Platform options''', make sure the
'''CPU clock rate''' entry is set correctly according to the following table:

{| border="1" style="text-align:center; margin: 1em auto 1em auto"
|-
! Board !! Frequency selected in XPG (MHz) !! ''CPU clock rate'' setting (kHz)
|-
|rowspan="3"| XTAV60 (LX60)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV110 (LX110)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV200 (LX200)
| 30 || 31250
|-
| 40 || 41667
|-
| 50 || 50000
|-
|}

Exit menuconfig, saving your configuration changes.

Backup your configuration outside the build directory. For example:

$ '''cp ../build-xtav60/.config config.xtav60.saved'''

If you do a clean rebuild of the kernel (e.g., "rm -rf ../build-xtav60")
you can now configure it with simply:
$ '''mkdir ../build-xtav60 ; cp config.xtav60.saved ../build-xtav60/.config'''
Of course if you update the kernel, you'll probably again have to do:
$ '''make O=../build-xtav60 ARCH=xtensa menuconfig'''
and save a new copy of your configuration.

=== Build the kernel ===

$ make O=../build-xtav60 ARCH=xtensa

The build will issue a few warnings which are normal.
Once complete, the bootable image is in:
<workdir>/build-xtav60/arch/xtensa/boot/Image.elf
and the uncompressed ELF file containing kernel symbols is in:
<workdir>/build-xtav60/vmlinux
There is also a RedBoot bootable image (if you use RedBoot) in:
<workdir>/build-xtav60/arch/xtensa/boot/zImage.redboot

=== Install Xtensa Tools for the selected core ===

If you opt to download the kernel over OCD, you need <tt>xt-gdb</tt>
which is part of Tensilica's Xtensa Tools package. This must be obtained
from Tensilica, and is not the same toolchain as built by buildroot.
You also need to install the corresponding Tensilica core package,
so that the Xtensa Tools know about your particular configured
Tensilica core.

The toolchain built using buildroot can be configured to
include GDB, but that version of GDB does not support
communicating with Tensilica's Xtensa OCD Daemon, and
thus cannot be used to download the kernel over OCD.

In this example, it is assumed that the machine hosting the
Xtensa Tools has access to the <workdir> directory tree.

=== Install and setup the Xtensa OCD Daemon ===

Setup and connect your JTAG probe, etc.

=== Connect a terminal server ===

At 38400 bps 8N1 no flow control to the XTAV60 serial port.

=== Optionally, setup networking ===

This step is optional.

Setup the board's MAC address using dipswitches
(see XTAV60 or XTAV200 board docs as appropriate)
and connect the board to a network that has a
DHCP server that will respond to that MAC address.
If you don't do this step, you'll simply not have network
access, and the boot process will take a minute or so longer
while the kernel times out waiting for a BOOTP response.
You can edit the kernel configuration and rebuild the kernel
to avoid using bootp (in particular, remove "ip=bootp" from
the kernel cmdline).

=== Download and run the kernel ===

Reset the board (see board documentation).

Using Xtensa Tools, invoke:

$ xt-gdb <workdir>/build-xtav60/arch/xtensa/boot/Image.elf

(xt-gdb) target remote <ocdhost>:20000 0
(xt-gdb) reset
(xt-gdb) load
(xt-gdb) set $pc = &_ResetVector
(xt-gdb) symbol-file <workdir>/build-xtav60/vmlinux
(xt-gdb) c

where <ocdhost> is the IP address or DNS name of the machine
running the Xtensa OCD daemon. The Linux kernel should
start booting as soon as 'c' (continue) is executed.

You should eventually get a login prompt.
Just login as root (no password).

Try various Linux commands. Look at <tt>/bin</tt>,
<tt>/sbin</tt>, <tt>/usr/bin</tt>, etc to see what's available.

Note: no need to setup an NFS or TFTP server. The filesystem
is contained within the kernel image. You may be able to mount
other filesystems over NFS though, if you wish, after booting.

=== Mounting the Root Filesystem Over NFS ===

If you build more than the minimal set of packages using
buildroot, the root filesystem can easily grow too large to
fit comfortably (or at all) inside the kernel. In this case,
rather than follow the instructions exactly as above,
you'll want to mount the root filesystem over NFS.

You may also want to mount the root filesystem over NFS to
make changes to the filesystem persistent across runs and
accessible from your development host.

First you need to install the root filesystem generated
using buildroot, to a machine that can serve it over NFS.
Assuming this machine runs Linux, one way to install it is
as follows:

mkdir ''<exportpath>''
cd ''<exportpath>''
sudo cpio -i -d -m -F ''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio --no-absolute-filenames

You then need to enable the NFS server on your system
(if not already active), and export this filesystem.
How you do this depends on your host Linux distribution.
For example, on some Fedora releases, one might:

* add the export path to <tt>/etc/exports</tt> using a line such as

''<exportpath>'' *(rw,sync,no_root_squash,no_all_squash)

* turn on the NFS server if needed:

sudo /sbin/chkconfig nfs on

* tell the NFS server about the new exported filesystem

sudo /usr/sbin/exportfs -a
sudo /usr/sbin/exportfs -r

Second, follow the instructions in the previous sections,
then configure the kernel again as follows.

Under '''General setup''', make sure the
'''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is disabled (rather than enabled as done in previous sections).

Under '''Platform options''', under the line '''Default bootloader kernel arguments''',
select the boot parameters line and set it to something like this:

console=ttyS0,38400 ip=dhcp root=/dev/nfs rw nfsroot=''<server_ip>'':''<exportpath>''

where ''<server_ip>'' is the IP address of your NFS server, and ''<exportpath>''
is the exported filesystem path.

Save this configuration, rebuild the kernel, and follow the
instructions in previous sections to download and run the kernel.
If everything goes well and is setup correctly, your kernel should
now boot with a root filesystem mounted over NFS.

== Build and Run a Linux Kernel on the Instruction Set Simulator (ISS) ==

You can build and run a Linux kernel in the Xtensa Instruction Set
Simulator (ISS). The following instructions have only been tried
with an ISS from the RB-2008.3 release of Xtensa Tools. Bear in
mind that the XTAV60 port is likely much more stable than the ISS port
of Linux at this point in time.

Note: Depending on your host OS version, you may need to install
Xtensa Tools on a separate machine.

=== Configure and Build the Kernel for ISS ===

Repeat all the same instructions as above for building the kernel for an
Avnet board, except that when initially configuring the kernel,
start from a ISS platform template instead. For example for the
DC233C Variant:

'''$ mkdir build-iss'''
'''$ cd linux'''
'''$ make O=../build-iss ARCH=xtensa KBUILD_DEFCONFIG=iss_dc233c_defconfig defconfig'''

The above make example configures the kernel using the default configuration found in
'''arch/xtensa/configs/iss_dc233_defconfig'''. Most important to note is that the
root file system mounted when Linux boots comes via the targets device '''/dev/simdisk0'''
which is defined in the kernel '''.config''' file. For example:

'''CONFIG_SIMDISK0_FILENAME="/export2/DC_C_233L/LINUX_ROOT.ext2"'''

The SIMDISK file name and VARIANT name are typically configured when running '''make menuconfig'''; Ex:

'''$ make O=../build-iss ARCH=xtensa menuconfig'''

and selecting

'''Xtensa Platform options''' ---> '''Host filename for a simulated device'''

and entering the pathname to the .ext2 file there. Ex: '''/export2/DC_C_233L/LINUX_ROOT.ext2'''

You often want to change the VARIANT to the one you desire, Ex: FSF. You do this via
the top level menu:

'''Xtensa Processor type and features ---> Xtensa Processor Custom Core Variant Name'''

With the new SIMDISK approach you copy the EXT2 Filesystem file generated by Buildroot
to a location to be accessed by Xtensa Linux. Ex:

'''$ cp /export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot/binaries/dc233c/rootfs.xtensa_dc233c.ext2 /export2/DC_C_233L/LINUX_ROOT.ext2'''

'''NOTE:''' There is an old '''iss_defconfig''' that tries to use a '''tuntap''' Ethernet
interface that currently isn't supported.
Previously with this old iss_defconfig using the '''tuntap''' Ethernet interface
it was suggested to set up the initramfs filesystem, and do the following.
Under '''Bus Options''', deselect '''PCI support'''.
Under '''Platform Options''', deselect '''Default bootloader kernel arguments'''.
Hopefully we will someday be able to support the use of a network interface with
ISS simulation and then be able to mount NFS root partitions again. So I'm leaving
this note for future exploration of this mechanism; Hope you don't mind the clutter.

Continue configuring and building the kernel as usual.

=== Run the Kernel on ISS ===

Using Xtensa Tools, invoke:

'''$ xt-gdb <workdir>/build-iss/arch/xtensa/boot/Image.elf'''
'''(xt-gdb) target sim --turbo --memlimit=128'''
'''(xt-gdb) symbol-file <workdir>/build-iss/vmlinux'''
'''(xt-gdb) run'''

Wait patiently while Linux boots ... (maybe a minute). The setting of the '''memlimit'''
needs to match the PLATFORM_DEFAULT_MEM_SIZE defined in /arch/xtensa/platforms/iss/include/platform/hardware.h.
Currently this limit us 128 MegaBytes:

#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000 /* 13,4217,728 128M */

and we will be extending this for the DC233L to take advantage of it's V3 MMU.

Login as root (no password).

'''Note:''' Input via ISS is cooked, so everything typed gets echoed.
Also, time as reported by the kernel does not progress
according to true wall-clock time: it currently depends on
a simulated processor clock, which advances at various speeds
according to load.

Instructions for building and booting Linux

2011-01-06T04:26:56Z

Piet: /* Build and Run a Linux Kernel on the XTAV60 or XTAV200 Board */

These instructions explain how to build a toolchain, root filesystem and kernel for Linux running on an Xtensa processor. These instructions apply specifically to the XTAV60 (LX60) board.

Some general notes on these instructions:

* They are a work in progress. If you are using the latest development sources, the build process may change, so you should be sure to get the latest version of this document at [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions]. If you are using one of the development snapshot releases, you should use the version of the build instructions included with that snapshot.

* The following was tested on x86 machines running RedHat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3). It is expected to work on newer Fedora releases (e.g., was tested on FC6) but to maintain host compatibility with Xtensa Tools, it is best to avoid Fedora releases beyond FC5. Other host distributions likely work but have not been tested.
** '''NOTE:''' this assumes the default selection of packages in buildroot. Selecting extra packages may require a more recent host OS or more recent version of certain tools. For example, the default version of <tt>find</tt> on RHEL4 is too old to allow building all X11 packages in buildroot, so it is necessary to upgrade the host version of <tt>findutils</tt> on RHEL4 to build these packages.

* Lines prefixed with "sudo" need to be executed as root. The rest is best executed as a non-root user. (It is possible to install <tt>git</tt> as a non-root user if root access is an issue. How to do this isn't shown here.)

* Lines that set environment variables assume a Bourne compatible shell (e.g., /bin/sh or bash), but are easily adapted to other shells.

* Instructions are assumed executed all in order (e.g., commands assume current directory and environment variables set earlier).

== Setup your host system ==

If you are using one of the snapshot releases, you can skip this step.

If you want to work with the latest development sources, you will need
[[Installing GIT|<tt>git</tt> installed on your system]].

== Download buildroot and the Linux kernel ==

The following section describes how to download the latest
versions of buildroot and of the Linux kernel.
Skip this step if you are using one of the
[http://wiki.linux-xtensa.org/index.php/Buildroot_Snapshots snapshot releases].

Adventurous users that want the use the '''bleeding edge''' code should execute the following:

'''$ cd <workdir>'''
'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa.git buildroot'''
'''$ git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git linux'''

where <tt><workdir></tt> is the path to an empty directory on a disk with
at least 4 GB available space. You end up with the following file structure,
which is assumed by the rest of this document:

<workdir>/
/buildroot
/linux

The MASTER branch of the buildroot repository is often is a state of development.
It's recommended to use the last snapshot for application developers. In the
case of the Avnet development boards a 'snapshot_2+SMP' branch is recommended
in the currently experimental SMP git repository:

'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

If you happen to have write access to either repository you should change '''git:''' to '''git+ssh:'''
For Example:

'''$ git clone git+ssh://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

For more details, see the [http://wiki.linux-xtensa.org/index.php/Repository_Access repository access] page.

== Install any required processor specific overlay ==

This step is required if you are targeting a custom Xtensa processor.
If you use a Diamond 232L Standard Core, you can skip this step.

To configure buildroot and the kernel to use a custom Xtensa processor
configuration, you need to overlay a set of files customized for your
processor configuration onto toolchain sources (gcc, binutils, gdb, etc)
and the Linux kernel. This process has been automated using a script
located in the buildroot source tree.
For usage information, you can invoke it without arguments:

'''$ cd <workdir>'''
'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install'''

which displays a help message similar to the following:

xt-buildroot-overlay-install version 1.3
Usage: xt-buildroot-overlay-install <parameters> [<options>]
Where <parameters> are:
-t file.tgz Specify path to the Xtensa Linux overlay tarball, typically
<xtensa_root>/src/xtensa-config-overlay.tar.gz
-b dir Path to the base of the buildroot source tree, in which
package specific overlay tarballs get installed.
-k dir Path to the base of the Linux kernel source tree, in which
the Linux kernel specific overlay gets installed.
-c config_name Name for the Xtensa processor configuration as it will be
known to the open source community. Must be a lowercase
identifier, starting with a letter, consisting of letters
and numbers and underscores, not ending with underscore
and not containing consecutive underscores. For examples:
dc232b , dc232b_be , mmubasele , fsf , s5000 .
-l long_name Long name for the Xtensa processor configuration, human-
readable with spaces etc allowed (must be quoted).
For example: 'Diamond 232L Standard Core Rev.B (LE)'
Try to keep it within approximately 40 characters.
And <options> are:
-f If package specific overlay tarballs already exist in
the destination source tree, overwrite them without asking.
--help Show this usage message.

Note that the Xtensa Linux overlay tarball MUST be obtained from an Xtensa
core package built using release RB-2008.3 or later.

Here is an example invocation of the overlay installation script:

'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install -t blinkcore-config-overlay.tar.gz''' \
'''-b ./buildroot -k ./linux -c superzip -l "ChipCorp SuperZIP Blink Accelerator Core"'''

The script extracts some relevant information from the overlay tarball,
presents it along with relevant parameters to the user, and prompts
for confirmation before proceeding.

The chosen processor name (-c option) must be unique among known Xtensa processors.
It is also probably wise to avoid names confusingly similar to other (non-Xtensa) processors.
If you expect at some point to contribute support for your custom processor to the
open-source community, this name will likely be long-lived.
(One way to contribute support for a custom processor might be to submit the overlay tarball
or files to the linux-xtensa.org maintainers.)

In the steps below, buildroot and the Linux kernel must be configured
(in their respective <code>''make menuconfig''</code> steps) to select
the <code>''custom''</code> Xtensa processor option.
This presents an extra configuration menu entry where you must provide
the name of the Xtensa processor. Set it to the same name
as was specified in the <code>-c</code> option above.

== Build a toolchain and root filesystem using buildroot ==

'''Note:''' for more details on generic buildroot topics not covered in this simple how-to,
see [http://buildroot.uclibc.org/ buildroot.uclibc.org].

=== Configure buildroot ===

The first time you configure buildroot, start with defaults for your Xtensa processor:

'''$ cd <workdir>/buildroot'''
'''$ ./target/xtensa/setup-config <corename>'''

where ''<corename>'' is the overlay name of your selected Xtensa or Diamond core
(e.g., '''dc232b'''). If you omit ''<corename>'', a help message and a list
of currently installed Tensilica core overlays is displayed.

Optionally, you can then customize your buildroot configuration, such as
selecting additional packages, setting various parameters, and so on.
The following make targets provide a ''curses'' (text-based graphical) interface
for configuring buildroot, the uClibc C library, and busybox, respectively.
('''Note:''' You need the <tt>TERM</tt> environment variable properly set for
these curses based tools to work.)

'''$ make menuconfig'''
'''$ make uclibc-menuconfig'''
'''$ make busybox-menuconfig'''

=== Build buildroot ===

Just type:

'''$ make'''

THIS WILL TAKE A LONG TIME (from about 30 minutes with defaults on a 3 GHz Pentium 4,
to perhaps an hour or many depending on your system and on whether
you enabled extra packages in your buildroot configuration).

Wait patiently for the build to complete. This builds an entire toolchain
as well as some basic packages, and constructs a root filesystem.
It might build many more packages if you selected them earlier with menuconfig.

==== If Something Goes Wrong ====

Perhaps you missed some step above and the build fails. Or you're just switching to a different processor configuration, or making some change with unknown dependencies. Either way, you'll probably need to fix the error and/or make the change, and redo the whole build. The above <tt>make</tt> command usually works fine if you
just added a package using menuconfig, but otherwise does not check many dependencies, so it will usually NOT rebuild things that depend on whatever you have fixed or changed. Here's one way to retry the make from scratch without having to wipe out the <tt>buildroot</tt> directory tree completely and start again from the git cloning.

$ '''rm -rf *build_xtensa* binaries'''
$ '''make'''

It is not necessary to empty the 'dl' subdirectory, which contains tarballs downloaded from the Internet, nor the .config file, which contains the buildroot configuration. Customizations to the uClibc and <tt>busybox</tt> configurations should have ended up getting saved in target/xtensa/uClibc.config and target/xtensa/busybox-config, respectively, so hopefully are preserved by the above sequence.

== Build and Run a Linux Kernel on the XTAV60, AXAV110, or XTAV200 Boards ==

References to the ''XTAV60 board'' refer to the combination of
the Avnet [http://www.em.avnet.com/tensilica1 LX60 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX60 (XT-AV60) Board User's Guide''.

Similarly, references to the ''XTAV200 board'' refers the combination of
the Avnet [http://www.em.avnet.com/tensilica2 LX200 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX200 (XT-AV200) Board User's Guide''.

=== Configure the kernel ===

The kernel build is a two-step process: configure the kernel, and build it.
First, before we can do anything with the kernel, set your PATH to
point to the toolchain built using buildroot.

$ '''export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"'''

where ''<cname>'' is the name of the Xtensa processor configuration you selected
when building the toolchain (e.g., <code>dc232b</code>).

Now setup a destination for kernel builds.
We usually like to have the build directory separate from
the source directory, so we use 'O=</destination/path>' in
kernel make commands. If you'll be routinely building multiple
configurations of the Linux kernel, it's good to have some
naming conventions for the build directory. For example,
to experiment with multiple target platforms but only one
processor configuration, we include just the platform name here:

$'''mkdir build-xtav60'''

Let's start with the default kernel configuration for the Avnet board
(which works on both XTAV60 (LX60), XTAV110 (LX110), and XTAV200 (LX200) boards)
as follows:

$ '''cd linux'''
$ '''make O=../build-xtav60 ARCH=xtensa KBUILD_DEFCONFIG=lx60_defconfig defconfig'''

This configures the kernel using the default configuration found in
'''arch/xtensa/configs/lx60_defconfig'''.

'''NOTE:''' This kernel configuration has nothing to do with Xtensa
processor configuration. That comes next.

Let's now customize this a little bit to select the correct Xtensa processor
configuration, and to bundle the root filesystem into the kernel:

$ '''make O=../build-xtav60 ARCH=xtensa menuconfig'''

Under '''General setup''',
make sure the '''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is enabled. Underneath that, edit '''Initramfs source file(s)''',
and enter the path to the cpio formatted root filesystem
generated by buildroot:

''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio.gz

(Don't forget to replace ''<workdir>'' with the appropriate full path
and ''<cname>'' with your Xtensa processor configuration name.)

Under '''Processor type and features''',
make sure the '''Xtensa Processor Configuration''' is correct and matches
the processor configuration name you used to build the toolchain with buildroot
(for example, ''dc232b'' for Diamond 232L Rev.B).
The kernel build selects a toolchain and processor variant specific headers
based on this selection.
If the desired processor configuration does not appear explicitly in the list,
simply select '''Custom Xtensa processor configuration''' and enter the
processor configuration name (all lowercase) into the next menu parameter,
'''Xtensa Processor Custom Variant Name'''.

Back in the main menu, under '''Platform options''', make sure the
'''CPU clock rate''' entry is set correctly according to the following table:

{| border="1" style="text-align:center; margin: 1em auto 1em auto"
|-
! Board !! Frequency selected in XPG (MHz) !! ''CPU clock rate'' setting (kHz)
|-
|rowspan="3"| XTAV60 (LX60)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV110 (LX110)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV200 (LX200)
| 30 || 31250
|-
| 40 || 41667
|-
| 50 || 50000
|-
|}

Exit menuconfig, saving your configuration changes.

Backup your configuration outside the build directory. For example:

$ cp ../build-xtav60/.config config.xtav60.saved

If you do a clean rebuild of the kernel (e.g., "rm -rf ../build-xtav60")
you can now configure it with simply:
$ mkdir ../build-xtav60 ; cp config.xtav60.saved ../build-xtav60/.config
Of course if you update the kernel, you'll probably again have to do:
$ make O=../build-xtav60 ARCH=xtensa menuconfig
and save a new copy of your configuration.

=== Build the kernel ===

$ make O=../build-xtav60 ARCH=xtensa

The build will issue a few warnings which are normal.
Once complete, the bootable image is in:
<workdir>/build-xtav60/arch/xtensa/boot/Image.elf
and the uncompressed ELF file containing kernel symbols is in:
<workdir>/build-xtav60/vmlinux
There is also a RedBoot bootable image (if you use RedBoot) in:
<workdir>/build-xtav60/arch/xtensa/boot/zImage.redboot

=== Install Xtensa Tools for the selected core ===

If you opt to download the kernel over OCD, you need <tt>xt-gdb</tt>
which is part of Tensilica's Xtensa Tools package. This must be obtained
from Tensilica, and is not the same toolchain as built by buildroot.
You also need to install the corresponding Tensilica core package,
so that the Xtensa Tools know about your particular configured
Tensilica core.

The toolchain built using buildroot can be configured to
include GDB, but that version of GDB does not support
communicating with Tensilica's Xtensa OCD Daemon, and
thus cannot be used to download the kernel over OCD.

In this example, it is assumed that the machine hosting the
Xtensa Tools has access to the <workdir> directory tree.

=== Install and setup the Xtensa OCD Daemon ===

Setup and connect your JTAG probe, etc.

=== Connect a terminal server ===

At 38400 bps 8N1 no flow control to the XTAV60 serial port.

=== Optionally, setup networking ===

This step is optional.

Setup the board's MAC address using dipswitches
(see XTAV60 or XTAV200 board docs as appropriate)
and connect the board to a network that has a
DHCP server that will respond to that MAC address.
If you don't do this step, you'll simply not have network
access, and the boot process will take a minute or so longer
while the kernel times out waiting for a BOOTP response.
You can edit the kernel configuration and rebuild the kernel
to avoid using bootp (in particular, remove "ip=bootp" from
the kernel cmdline).

=== Download and run the kernel ===

Reset the board (see board documentation).

Using Xtensa Tools, invoke:

$ xt-gdb <workdir>/build-xtav60/arch/xtensa/boot/Image.elf

(xt-gdb) target remote <ocdhost>:20000 0
(xt-gdb) reset
(xt-gdb) load
(xt-gdb) set $pc = &_ResetVector
(xt-gdb) symbol-file <workdir>/build-xtav60/vmlinux
(xt-gdb) c

where <ocdhost> is the IP address or DNS name of the machine
running the Xtensa OCD daemon. The Linux kernel should
start booting as soon as 'c' (continue) is executed.

You should eventually get a login prompt.
Just login as root (no password).

Try various Linux commands. Look at <tt>/bin</tt>,
<tt>/sbin</tt>, <tt>/usr/bin</tt>, etc to see what's available.

Note: no need to setup an NFS or TFTP server. The filesystem
is contained within the kernel image. You may be able to mount
other filesystems over NFS though, if you wish, after booting.

=== Mounting the Root Filesystem Over NFS ===

If you build more than the minimal set of packages using
buildroot, the root filesystem can easily grow too large to
fit comfortably (or at all) inside the kernel. In this case,
rather than follow the instructions exactly as above,
you'll want to mount the root filesystem over NFS.

You may also want to mount the root filesystem over NFS to
make changes to the filesystem persistent across runs and
accessible from your development host.

First you need to install the root filesystem generated
using buildroot, to a machine that can serve it over NFS.
Assuming this machine runs Linux, one way to install it is
as follows:

mkdir ''<exportpath>''
cd ''<exportpath>''
sudo cpio -i -d -m -F ''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio --no-absolute-filenames

You then need to enable the NFS server on your system
(if not already active), and export this filesystem.
How you do this depends on your host Linux distribution.
For example, on some Fedora releases, one might:

* add the export path to <tt>/etc/exports</tt> using a line such as

''<exportpath>'' *(rw,sync,no_root_squash,no_all_squash)

* turn on the NFS server if needed:

sudo /sbin/chkconfig nfs on

* tell the NFS server about the new exported filesystem

sudo /usr/sbin/exportfs -a
sudo /usr/sbin/exportfs -r

Second, follow the instructions in the previous sections,
then configure the kernel again as follows.

Under '''General setup''', make sure the
'''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is disabled (rather than enabled as done in previous sections).

Under '''Platform options''', under the line '''Default bootloader kernel arguments''',
select the boot parameters line and set it to something like this:

console=ttyS0,38400 ip=dhcp root=/dev/nfs rw nfsroot=''<server_ip>'':''<exportpath>''

where ''<server_ip>'' is the IP address of your NFS server, and ''<exportpath>''
is the exported filesystem path.

Save this configuration, rebuild the kernel, and follow the
instructions in previous sections to download and run the kernel.
If everything goes well and is setup correctly, your kernel should
now boot with a root filesystem mounted over NFS.

== Build and Run a Linux Kernel on the Instruction Set Simulator (ISS) ==

You can build and run a Linux kernel in the Xtensa Instruction Set
Simulator (ISS). The following instructions have only been tried
with an ISS from the RB-2008.3 release of Xtensa Tools. Bear in
mind that the XTAV60 port is likely much more stable than the ISS port
of Linux at this point in time.

Note: Depending on your host OS version, you may need to install
Xtensa Tools on a separate machine.

=== Configure and Build the Kernel for ISS ===

Repeat all the same instructions as above for building the kernel for an
Avnet board, except that when initially configuring the kernel,
start from a ISS platform template instead. For example for the
DC233C Variant:

'''$ mkdir build-iss'''
'''$ cd linux'''
'''$ make O=../build-iss ARCH=xtensa KBUILD_DEFCONFIG=iss_dc233c_defconfig defconfig'''

The above make example configures the kernel using the default configuration found in
'''arch/xtensa/configs/iss_dc233_defconfig'''. Most important to note is that the
root file system mounted when Linux boots comes via the targets device '''/dev/simdisk0'''
which is defined in the kernel '''.config''' file. For example:

'''CONFIG_SIMDISK0_FILENAME="/export2/DC_C_233L/LINUX_ROOT.ext2"'''

The SIMDISK file name and VARIANT name are typically configured when running '''make menuconfig'''; Ex:

'''$ make O=../build-iss ARCH=xtensa menuconfig'''

and selecting

'''Xtensa Platform options''' ---> '''Host filename for a simulated device'''

and entering the pathname to the .ext2 file there. Ex: '''/export2/DC_C_233L/LINUX_ROOT.ext2'''

You often want to change the VARIANT to the one you desire, Ex: FSF. You do this via
the top level menu:

'''Xtensa Processor type and features ---> Xtensa Processor Custom Core Variant Name'''

With the new SIMDISK approach you copy the EXT2 Filesystem file generated by Buildroot
to a location to be accessed by Xtensa Linux. Ex:

'''$ cp /export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot/binaries/dc233c/rootfs.xtensa_dc233c.ext2 /export2/DC_C_233L/LINUX_ROOT.ext2'''

'''NOTE:''' There is an old '''iss_defconfig''' that tries to use a '''tuntap''' Ethernet
interface that currently isn't supported.
Previously with this old iss_defconfig using the '''tuntap''' Ethernet interface
it was suggested to set up the initramfs filesystem, and do the following.
Under '''Bus Options''', deselect '''PCI support'''.
Under '''Platform Options''', deselect '''Default bootloader kernel arguments'''.
Hopefully we will someday be able to support the use of a network interface with
ISS simulation and then be able to mount NFS root partitions again. So I'm leaving
this note for future exploration of this mechanism; Hope you don't mind the clutter.

Continue configuring and building the kernel as usual.

=== Run the Kernel on ISS ===

Using Xtensa Tools, invoke:

'''$ xt-gdb <workdir>/build-iss/arch/xtensa/boot/Image.elf'''
'''(xt-gdb) target sim --turbo --memlimit=128'''
'''(xt-gdb) symbol-file <workdir>/build-iss/vmlinux'''
'''(xt-gdb) run'''

Wait patiently while Linux boots ... (maybe a minute). The setting of the '''memlimit'''
needs to match the PLATFORM_DEFAULT_MEM_SIZE defined in /arch/xtensa/platforms/iss/include/platform/hardware.h.
Currently this limit us 128 MegaBytes:

#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000 /* 13,4217,728 128M */

and we will be extending this for the DC233L to take advantage of it's V3 MMU.

Login as root (no password).

'''Note:''' Input via ISS is cooked, so everything typed gets echoed.
Also, time as reported by the kernel does not progress
according to true wall-clock time: it currently depends on
a simulated processor clock, which advances at various speeds
according to load.

Instructions for building and booting Linux

2011-01-06T04:14:13Z

Piet: /* Configure the kernel */

These instructions explain how to build a toolchain, root filesystem and kernel for Linux running on an Xtensa processor. These instructions apply specifically to the XTAV60 (LX60) board.

Some general notes on these instructions:

* They are a work in progress. If you are using the latest development sources, the build process may change, so you should be sure to get the latest version of this document at [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions]. If you are using one of the development snapshot releases, you should use the version of the build instructions included with that snapshot.

* The following was tested on x86 machines running RedHat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3). It is expected to work on newer Fedora releases (e.g., was tested on FC6) but to maintain host compatibility with Xtensa Tools, it is best to avoid Fedora releases beyond FC5. Other host distributions likely work but have not been tested.
** '''NOTE:''' this assumes the default selection of packages in buildroot. Selecting extra packages may require a more recent host OS or more recent version of certain tools. For example, the default version of <tt>find</tt> on RHEL4 is too old to allow building all X11 packages in buildroot, so it is necessary to upgrade the host version of <tt>findutils</tt> on RHEL4 to build these packages.

* Lines prefixed with "sudo" need to be executed as root. The rest is best executed as a non-root user. (It is possible to install <tt>git</tt> as a non-root user if root access is an issue. How to do this isn't shown here.)

* Lines that set environment variables assume a Bourne compatible shell (e.g., /bin/sh or bash), but are easily adapted to other shells.

* Instructions are assumed executed all in order (e.g., commands assume current directory and environment variables set earlier).

== Setup your host system ==

If you are using one of the snapshot releases, you can skip this step.

If you want to work with the latest development sources, you will need
[[Installing GIT|<tt>git</tt> installed on your system]].

== Download buildroot and the Linux kernel ==

The following section describes how to download the latest
versions of buildroot and of the Linux kernel.
Skip this step if you are using one of the
[http://wiki.linux-xtensa.org/index.php/Buildroot_Snapshots snapshot releases].

Adventurous users that want the use the '''bleeding edge''' code should execute the following:

'''$ cd <workdir>'''
'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa.git buildroot'''
'''$ git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git linux'''

where <tt><workdir></tt> is the path to an empty directory on a disk with
at least 4 GB available space. You end up with the following file structure,
which is assumed by the rest of this document:

<workdir>/
/buildroot
/linux

The MASTER branch of the buildroot repository is often is a state of development.
It's recommended to use the last snapshot for application developers. In the
case of the Avnet development boards a 'snapshot_2+SMP' branch is recommended
in the currently experimental SMP git repository:

'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

If you happen to have write access to either repository you should change '''git:''' to '''git+ssh:'''
For Example:

'''$ git clone git+ssh://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

For more details, see the [http://wiki.linux-xtensa.org/index.php/Repository_Access repository access] page.

== Install any required processor specific overlay ==

This step is required if you are targeting a custom Xtensa processor.
If you use a Diamond 232L Standard Core, you can skip this step.

To configure buildroot and the kernel to use a custom Xtensa processor
configuration, you need to overlay a set of files customized for your
processor configuration onto toolchain sources (gcc, binutils, gdb, etc)
and the Linux kernel. This process has been automated using a script
located in the buildroot source tree.
For usage information, you can invoke it without arguments:

'''$ cd <workdir>'''
'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install'''

which displays a help message similar to the following:

xt-buildroot-overlay-install version 1.3
Usage: xt-buildroot-overlay-install <parameters> [<options>]
Where <parameters> are:
-t file.tgz Specify path to the Xtensa Linux overlay tarball, typically
<xtensa_root>/src/xtensa-config-overlay.tar.gz
-b dir Path to the base of the buildroot source tree, in which
package specific overlay tarballs get installed.
-k dir Path to the base of the Linux kernel source tree, in which
the Linux kernel specific overlay gets installed.
-c config_name Name for the Xtensa processor configuration as it will be
known to the open source community. Must be a lowercase
identifier, starting with a letter, consisting of letters
and numbers and underscores, not ending with underscore
and not containing consecutive underscores. For examples:
dc232b , dc232b_be , mmubasele , fsf , s5000 .
-l long_name Long name for the Xtensa processor configuration, human-
readable with spaces etc allowed (must be quoted).
For example: 'Diamond 232L Standard Core Rev.B (LE)'
Try to keep it within approximately 40 characters.
And <options> are:
-f If package specific overlay tarballs already exist in
the destination source tree, overwrite them without asking.
--help Show this usage message.

Note that the Xtensa Linux overlay tarball MUST be obtained from an Xtensa
core package built using release RB-2008.3 or later.

Here is an example invocation of the overlay installation script:

'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install -t blinkcore-config-overlay.tar.gz''' \
'''-b ./buildroot -k ./linux -c superzip -l "ChipCorp SuperZIP Blink Accelerator Core"'''

The script extracts some relevant information from the overlay tarball,
presents it along with relevant parameters to the user, and prompts
for confirmation before proceeding.

The chosen processor name (-c option) must be unique among known Xtensa processors.
It is also probably wise to avoid names confusingly similar to other (non-Xtensa) processors.
If you expect at some point to contribute support for your custom processor to the
open-source community, this name will likely be long-lived.
(One way to contribute support for a custom processor might be to submit the overlay tarball
or files to the linux-xtensa.org maintainers.)

In the steps below, buildroot and the Linux kernel must be configured
(in their respective <code>''make menuconfig''</code> steps) to select
the <code>''custom''</code> Xtensa processor option.
This presents an extra configuration menu entry where you must provide
the name of the Xtensa processor. Set it to the same name
as was specified in the <code>-c</code> option above.

== Build a toolchain and root filesystem using buildroot ==

'''Note:''' for more details on generic buildroot topics not covered in this simple how-to,
see [http://buildroot.uclibc.org/ buildroot.uclibc.org].

=== Configure buildroot ===

The first time you configure buildroot, start with defaults for your Xtensa processor:

'''$ cd <workdir>/buildroot'''
'''$ ./target/xtensa/setup-config <corename>'''

where ''<corename>'' is the overlay name of your selected Xtensa or Diamond core
(e.g., '''dc232b'''). If you omit ''<corename>'', a help message and a list
of currently installed Tensilica core overlays is displayed.

Optionally, you can then customize your buildroot configuration, such as
selecting additional packages, setting various parameters, and so on.
The following make targets provide a ''curses'' (text-based graphical) interface
for configuring buildroot, the uClibc C library, and busybox, respectively.
('''Note:''' You need the <tt>TERM</tt> environment variable properly set for
these curses based tools to work.)

'''$ make menuconfig'''
'''$ make uclibc-menuconfig'''
'''$ make busybox-menuconfig'''

=== Build buildroot ===

Just type:

'''$ make'''

THIS WILL TAKE A LONG TIME (from about 30 minutes with defaults on a 3 GHz Pentium 4,
to perhaps an hour or many depending on your system and on whether
you enabled extra packages in your buildroot configuration).

Wait patiently for the build to complete. This builds an entire toolchain
as well as some basic packages, and constructs a root filesystem.
It might build many more packages if you selected them earlier with menuconfig.

==== If Something Goes Wrong ====

Perhaps you missed some step above and the build fails. Or you're just switching to a different processor configuration, or making some change with unknown dependencies. Either way, you'll probably need to fix the error and/or make the change, and redo the whole build. The above <tt>make</tt> command usually works fine if you
just added a package using menuconfig, but otherwise does not check many dependencies, so it will usually NOT rebuild things that depend on whatever you have fixed or changed. Here's one way to retry the make from scratch without having to wipe out the <tt>buildroot</tt> directory tree completely and start again from the git cloning.

$ '''rm -rf *build_xtensa* binaries'''
$ '''make'''

It is not necessary to empty the 'dl' subdirectory, which contains tarballs downloaded from the Internet, nor the .config file, which contains the buildroot configuration. Customizations to the uClibc and <tt>busybox</tt> configurations should have ended up getting saved in target/xtensa/uClibc.config and target/xtensa/busybox-config, respectively, so hopefully are preserved by the above sequence.

== Build and Run a Linux Kernel on the XTAV60 or XTAV200 Board ==

References to the ''XTAV60 board'' refer to the combination of
the Avnet [http://www.em.avnet.com/tensilica1 LX60 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX60 (XT-AV60) Board User's Guide''.

Similarly, references to the ''XTAV200 board'' refers the combination of
the Avnet [http://www.em.avnet.com/tensilica2 LX200 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX200 (XT-AV200) Board User's Guide''.

=== Configure the kernel ===

The kernel build is a two-step process: configure the kernel, and build it.
First, before we can do anything with the kernel, set your PATH to
point to the toolchain built using buildroot.

$ '''export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"'''

where ''<cname>'' is the name of the Xtensa processor configuration you selected
when building the toolchain (e.g., <code>dc232b</code>).

Now setup a destination for kernel builds.
We usually like to have the build directory separate from
the source directory, so we use 'O=</destination/path>' in
kernel make commands. If you'll be routinely building multiple
configurations of the Linux kernel, it's good to have some
naming conventions for the build directory. For example,
to experiment with multiple target platforms but only one
processor configuration, we include just the platform name here:

$'''mkdir build-xtav60'''

Let's start with the default kernel configuration for the Avnet board
(which works on both XTAV60 (LX60), XTAV110 (LX110), and XTAV200 (LX200) boards)
as follows:

$ '''cd linux'''
$ '''make O=../build-xtav60 ARCH=xtensa KBUILD_DEFCONFIG=lx60_defconfig defconfig'''

This configures the kernel using the default configuration found in
'''arch/xtensa/configs/lx60_defconfig'''.

'''NOTE:''' This kernel configuration has nothing to do with Xtensa
processor configuration. That comes next.

Let's now customize this a little bit to select the correct Xtensa processor
configuration, and to bundle the root filesystem into the kernel:

$ '''make O=../build-xtav60 ARCH=xtensa menuconfig'''

Under '''General setup''',
make sure the '''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is enabled. Underneath that, edit '''Initramfs source file(s)''',
and enter the path to the cpio formatted root filesystem
generated by buildroot:

''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio.gz

(Don't forget to replace ''<workdir>'' with the appropriate full path
and ''<cname>'' with your Xtensa processor configuration name.)

Under '''Processor type and features''',
make sure the '''Xtensa Processor Configuration''' is correct and matches
the processor configuration name you used to build the toolchain with buildroot
(for example, ''dc232b'' for Diamond 232L Rev.B).
The kernel build selects a toolchain and processor variant specific headers
based on this selection.
If the desired processor configuration does not appear explicitly in the list,
simply select '''Custom Xtensa processor configuration''' and enter the
processor configuration name (all lowercase) into the next menu parameter,
'''Xtensa Processor Custom Variant Name'''.

Back in the main menu, under '''Platform options''', make sure the
'''CPU clock rate''' entry is set correctly according to the following table:

{| border="1" style="text-align:center; margin: 1em auto 1em auto"
|-
! Board !! Frequency selected in XPG (MHz) !! ''CPU clock rate'' setting (kHz)
|-
|rowspan="3"| XTAV60 (LX60)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV110 (LX110)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV200 (LX200)
| 30 || 31250
|-
| 40 || 41667
|-
| 50 || 50000
|-
|}

Exit menuconfig, saving your configuration changes.

Backup your configuration outside the build directory. For example:

$ cp ../build-xtav60/.config config.xtav60.saved

If you do a clean rebuild of the kernel (e.g., "rm -rf ../build-xtav60")
you can now configure it with simply:
$ mkdir ../build-xtav60 ; cp config.xtav60.saved ../build-xtav60/.config
Of course if you update the kernel, you'll probably again have to do:
$ make O=../build-xtav60 ARCH=xtensa menuconfig
and save a new copy of your configuration.

=== Build the kernel ===

$ make O=../build-xtav60 ARCH=xtensa

The build will issue a few warnings which are normal.
Once complete, the bootable image is in:
<workdir>/build-xtav60/arch/xtensa/boot/Image.elf
and the uncompressed ELF file containing kernel symbols is in:
<workdir>/build-xtav60/vmlinux
There is also a RedBoot bootable image (if you use RedBoot) in:
<workdir>/build-xtav60/arch/xtensa/boot/zImage.redboot

=== Install Xtensa Tools for the selected core ===

If you opt to download the kernel over OCD, you need <tt>xt-gdb</tt>
which is part of Tensilica's Xtensa Tools package. This must be obtained
from Tensilica, and is not the same toolchain as built by buildroot.
You also need to install the corresponding Tensilica core package,
so that the Xtensa Tools know about your particular configured
Tensilica core.

The toolchain built using buildroot can be configured to
include GDB, but that version of GDB does not support
communicating with Tensilica's Xtensa OCD Daemon, and
thus cannot be used to download the kernel over OCD.

In this example, it is assumed that the machine hosting the
Xtensa Tools has access to the <workdir> directory tree.

=== Install and setup the Xtensa OCD Daemon ===

Setup and connect your JTAG probe, etc.

=== Connect a terminal server ===

At 38400 bps 8N1 no flow control to the XTAV60 serial port.

=== Optionally, setup networking ===

This step is optional.

Setup the board's MAC address using dipswitches
(see XTAV60 or XTAV200 board docs as appropriate)
and connect the board to a network that has a
DHCP server that will respond to that MAC address.
If you don't do this step, you'll simply not have network
access, and the boot process will take a minute or so longer
while the kernel times out waiting for a BOOTP response.
You can edit the kernel configuration and rebuild the kernel
to avoid using bootp (in particular, remove "ip=bootp" from
the kernel cmdline).

=== Download and run the kernel ===

Reset the board (see board documentation).

Using Xtensa Tools, invoke:

$ xt-gdb <workdir>/build-xtav60/arch/xtensa/boot/Image.elf

(xt-gdb) target remote <ocdhost>:20000 0
(xt-gdb) reset
(xt-gdb) load
(xt-gdb) set $pc = &_ResetVector
(xt-gdb) symbol-file <workdir>/build-xtav60/vmlinux
(xt-gdb) c

where <ocdhost> is the IP address or DNS name of the machine
running the Xtensa OCD daemon. The Linux kernel should
start booting as soon as 'c' (continue) is executed.

You should eventually get a login prompt.
Just login as root (no password).

Try various Linux commands. Look at <tt>/bin</tt>,
<tt>/sbin</tt>, <tt>/usr/bin</tt>, etc to see what's available.

Note: no need to setup an NFS or TFTP server. The filesystem
is contained within the kernel image. You may be able to mount
other filesystems over NFS though, if you wish, after booting.

=== Mounting the Root Filesystem Over NFS ===

If you build more than the minimal set of packages using
buildroot, the root filesystem can easily grow too large to
fit comfortably (or at all) inside the kernel. In this case,
rather than follow the instructions exactly as above,
you'll want to mount the root filesystem over NFS.

You may also want to mount the root filesystem over NFS to
make changes to the filesystem persistent across runs and
accessible from your development host.

First you need to install the root filesystem generated
using buildroot, to a machine that can serve it over NFS.
Assuming this machine runs Linux, one way to install it is
as follows:

mkdir ''<exportpath>''
cd ''<exportpath>''
sudo cpio -i -d -m -F ''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio --no-absolute-filenames

You then need to enable the NFS server on your system
(if not already active), and export this filesystem.
How you do this depends on your host Linux distribution.
For example, on some Fedora releases, one might:

* add the export path to <tt>/etc/exports</tt> using a line such as

''<exportpath>'' *(rw,sync,no_root_squash,no_all_squash)

* turn on the NFS server if needed:

sudo /sbin/chkconfig nfs on

* tell the NFS server about the new exported filesystem

sudo /usr/sbin/exportfs -a
sudo /usr/sbin/exportfs -r

Second, follow the instructions in the previous sections,
then configure the kernel again as follows.

Under '''General setup''', make sure the
'''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is disabled (rather than enabled as done in previous sections).

Under '''Platform options''', under the line '''Default bootloader kernel arguments''',
select the boot parameters line and set it to something like this:

console=ttyS0,38400 ip=dhcp root=/dev/nfs rw nfsroot=''<server_ip>'':''<exportpath>''

where ''<server_ip>'' is the IP address of your NFS server, and ''<exportpath>''
is the exported filesystem path.

Save this configuration, rebuild the kernel, and follow the
instructions in previous sections to download and run the kernel.
If everything goes well and is setup correctly, your kernel should
now boot with a root filesystem mounted over NFS.

== Build and Run a Linux Kernel on the Instruction Set Simulator (ISS) ==

You can build and run a Linux kernel in the Xtensa Instruction Set
Simulator (ISS). The following instructions have only been tried
with an ISS from the RB-2008.3 release of Xtensa Tools. Bear in
mind that the XTAV60 port is likely much more stable than the ISS port
of Linux at this point in time.

Note: Depending on your host OS version, you may need to install
Xtensa Tools on a separate machine.

=== Configure and Build the Kernel for ISS ===

Repeat all the same instructions as above for building the kernel for an
Avnet board, except that when initially configuring the kernel,
start from a ISS platform template instead. For example for the
DC233C Variant:

'''$ mkdir build-iss'''
'''$ cd linux'''
'''$ make O=../build-iss ARCH=xtensa KBUILD_DEFCONFIG=iss_dc233c_defconfig defconfig'''

The above make example configures the kernel using the default configuration found in
'''arch/xtensa/configs/iss_dc233_defconfig'''. Most important to note is that the
root file system mounted when Linux boots comes via the targets device '''/dev/simdisk0'''
which is defined in the kernel '''.config''' file. For example:

'''CONFIG_SIMDISK0_FILENAME="/export2/DC_C_233L/LINUX_ROOT.ext2"'''

The SIMDISK file name and VARIANT name are typically configured when running '''make menuconfig'''; Ex:

'''$ make O=../build-iss ARCH=xtensa menuconfig'''

and selecting

'''Xtensa Platform options''' ---> '''Host filename for a simulated device'''

and entering the pathname to the .ext2 file there. Ex: '''/export2/DC_C_233L/LINUX_ROOT.ext2'''

You often want to change the VARIANT to the one you desire, Ex: FSF. You do this via
the top level menu:

'''Xtensa Processor type and features ---> Xtensa Processor Custom Core Variant Name'''

With the new SIMDISK approach you copy the EXT2 Filesystem file generated by Buildroot
to a location to be accessed by Xtensa Linux. Ex:

'''$ cp /export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot/binaries/dc233c/rootfs.xtensa_dc233c.ext2 /export2/DC_C_233L/LINUX_ROOT.ext2'''

'''NOTE:''' There is an old '''iss_defconfig''' that tries to use a '''tuntap''' Ethernet
interface that currently isn't supported.
Previously with this old iss_defconfig using the '''tuntap''' Ethernet interface
it was suggested to set up the initramfs filesystem, and do the following.
Under '''Bus Options''', deselect '''PCI support'''.
Under '''Platform Options''', deselect '''Default bootloader kernel arguments'''.
Hopefully we will someday be able to support the use of a network interface with
ISS simulation and then be able to mount NFS root partitions again. So I'm leaving
this note for future exploration of this mechanism; Hope you don't mind the clutter.

Continue configuring and building the kernel as usual.

=== Run the Kernel on ISS ===

Using Xtensa Tools, invoke:

'''$ xt-gdb <workdir>/build-iss/arch/xtensa/boot/Image.elf'''
'''(xt-gdb) target sim --turbo --memlimit=128'''
'''(xt-gdb) symbol-file <workdir>/build-iss/vmlinux'''
'''(xt-gdb) run'''

Wait patiently while Linux boots ... (maybe a minute). The setting of the '''memlimit'''
needs to match the PLATFORM_DEFAULT_MEM_SIZE defined in /arch/xtensa/platforms/iss/include/platform/hardware.h.
Currently this limit us 128 MegaBytes:

#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000 /* 13,4217,728 128M */

and we will be extending this for the DC233L to take advantage of it's V3 MMU.

Login as root (no password).

'''Note:''' Input via ISS is cooked, so everything typed gets echoed.
Also, time as reported by the kernel does not progress
according to true wall-clock time: it currently depends on
a simulated processor clock, which advances at various speeds
according to load.

Instructions for building and booting Linux

2011-01-06T04:10:40Z

Piet: /* Download buildroot and the Linux kernel */

These instructions explain how to build a toolchain, root filesystem and kernel for Linux running on an Xtensa processor. These instructions apply specifically to the XTAV60 (LX60) board.

Some general notes on these instructions:

* They are a work in progress. If you are using the latest development sources, the build process may change, so you should be sure to get the latest version of this document at [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions]. If you are using one of the development snapshot releases, you should use the version of the build instructions included with that snapshot.

* The following was tested on x86 machines running RedHat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3). It is expected to work on newer Fedora releases (e.g., was tested on FC6) but to maintain host compatibility with Xtensa Tools, it is best to avoid Fedora releases beyond FC5. Other host distributions likely work but have not been tested.
** '''NOTE:''' this assumes the default selection of packages in buildroot. Selecting extra packages may require a more recent host OS or more recent version of certain tools. For example, the default version of <tt>find</tt> on RHEL4 is too old to allow building all X11 packages in buildroot, so it is necessary to upgrade the host version of <tt>findutils</tt> on RHEL4 to build these packages.

* Lines prefixed with "sudo" need to be executed as root. The rest is best executed as a non-root user. (It is possible to install <tt>git</tt> as a non-root user if root access is an issue. How to do this isn't shown here.)

* Lines that set environment variables assume a Bourne compatible shell (e.g., /bin/sh or bash), but are easily adapted to other shells.

* Instructions are assumed executed all in order (e.g., commands assume current directory and environment variables set earlier).

== Setup your host system ==

If you are using one of the snapshot releases, you can skip this step.

If you want to work with the latest development sources, you will need
[[Installing GIT|<tt>git</tt> installed on your system]].

== Download buildroot and the Linux kernel ==

The following section describes how to download the latest
versions of buildroot and of the Linux kernel.
Skip this step if you are using one of the
[http://wiki.linux-xtensa.org/index.php/Buildroot_Snapshots snapshot releases].

Adventurous users that want the use the '''bleeding edge''' code should execute the following:

'''$ cd <workdir>'''
'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa.git buildroot'''
'''$ git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git linux'''

where <tt><workdir></tt> is the path to an empty directory on a disk with
at least 4 GB available space. You end up with the following file structure,
which is assumed by the rest of this document:

<workdir>/
/buildroot
/linux

The MASTER branch of the buildroot repository is often is a state of development.
It's recommended to use the last snapshot for application developers. In the
case of the Avnet development boards a 'snapshot_2+SMP' branch is recommended
in the currently experimental SMP git repository:

'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

If you happen to have write access to either repository you should change '''git:''' to '''git+ssh:'''
For Example:

'''$ git clone git+ssh://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

For more details, see the [http://wiki.linux-xtensa.org/index.php/Repository_Access repository access] page.

== Install any required processor specific overlay ==

This step is required if you are targeting a custom Xtensa processor.
If you use a Diamond 232L Standard Core, you can skip this step.

To configure buildroot and the kernel to use a custom Xtensa processor
configuration, you need to overlay a set of files customized for your
processor configuration onto toolchain sources (gcc, binutils, gdb, etc)
and the Linux kernel. This process has been automated using a script
located in the buildroot source tree.
For usage information, you can invoke it without arguments:

'''$ cd <workdir>'''
'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install'''

which displays a help message similar to the following:

xt-buildroot-overlay-install version 1.3
Usage: xt-buildroot-overlay-install <parameters> [<options>]
Where <parameters> are:
-t file.tgz Specify path to the Xtensa Linux overlay tarball, typically
<xtensa_root>/src/xtensa-config-overlay.tar.gz
-b dir Path to the base of the buildroot source tree, in which
package specific overlay tarballs get installed.
-k dir Path to the base of the Linux kernel source tree, in which
the Linux kernel specific overlay gets installed.
-c config_name Name for the Xtensa processor configuration as it will be
known to the open source community. Must be a lowercase
identifier, starting with a letter, consisting of letters
and numbers and underscores, not ending with underscore
and not containing consecutive underscores. For examples:
dc232b , dc232b_be , mmubasele , fsf , s5000 .
-l long_name Long name for the Xtensa processor configuration, human-
readable with spaces etc allowed (must be quoted).
For example: 'Diamond 232L Standard Core Rev.B (LE)'
Try to keep it within approximately 40 characters.
And <options> are:
-f If package specific overlay tarballs already exist in
the destination source tree, overwrite them without asking.
--help Show this usage message.

Note that the Xtensa Linux overlay tarball MUST be obtained from an Xtensa
core package built using release RB-2008.3 or later.

Here is an example invocation of the overlay installation script:

'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install -t blinkcore-config-overlay.tar.gz''' \
'''-b ./buildroot -k ./linux -c superzip -l "ChipCorp SuperZIP Blink Accelerator Core"'''

The script extracts some relevant information from the overlay tarball,
presents it along with relevant parameters to the user, and prompts
for confirmation before proceeding.

The chosen processor name (-c option) must be unique among known Xtensa processors.
It is also probably wise to avoid names confusingly similar to other (non-Xtensa) processors.
If you expect at some point to contribute support for your custom processor to the
open-source community, this name will likely be long-lived.
(One way to contribute support for a custom processor might be to submit the overlay tarball
or files to the linux-xtensa.org maintainers.)

In the steps below, buildroot and the Linux kernel must be configured
(in their respective <code>''make menuconfig''</code> steps) to select
the <code>''custom''</code> Xtensa processor option.
This presents an extra configuration menu entry where you must provide
the name of the Xtensa processor. Set it to the same name
as was specified in the <code>-c</code> option above.

== Build a toolchain and root filesystem using buildroot ==

'''Note:''' for more details on generic buildroot topics not covered in this simple how-to,
see [http://buildroot.uclibc.org/ buildroot.uclibc.org].

=== Configure buildroot ===

The first time you configure buildroot, start with defaults for your Xtensa processor:

'''$ cd <workdir>/buildroot'''
'''$ ./target/xtensa/setup-config <corename>'''

where ''<corename>'' is the overlay name of your selected Xtensa or Diamond core
(e.g., '''dc232b'''). If you omit ''<corename>'', a help message and a list
of currently installed Tensilica core overlays is displayed.

Optionally, you can then customize your buildroot configuration, such as
selecting additional packages, setting various parameters, and so on.
The following make targets provide a ''curses'' (text-based graphical) interface
for configuring buildroot, the uClibc C library, and busybox, respectively.
('''Note:''' You need the <tt>TERM</tt> environment variable properly set for
these curses based tools to work.)

'''$ make menuconfig'''
'''$ make uclibc-menuconfig'''
'''$ make busybox-menuconfig'''

=== Build buildroot ===

Just type:

'''$ make'''

THIS WILL TAKE A LONG TIME (from about 30 minutes with defaults on a 3 GHz Pentium 4,
to perhaps an hour or many depending on your system and on whether
you enabled extra packages in your buildroot configuration).

Wait patiently for the build to complete. This builds an entire toolchain
as well as some basic packages, and constructs a root filesystem.
It might build many more packages if you selected them earlier with menuconfig.

==== If Something Goes Wrong ====

Perhaps you missed some step above and the build fails. Or you're just switching to a different processor configuration, or making some change with unknown dependencies. Either way, you'll probably need to fix the error and/or make the change, and redo the whole build. The above <tt>make</tt> command usually works fine if you
just added a package using menuconfig, but otherwise does not check many dependencies, so it will usually NOT rebuild things that depend on whatever you have fixed or changed. Here's one way to retry the make from scratch without having to wipe out the <tt>buildroot</tt> directory tree completely and start again from the git cloning.

$ '''rm -rf *build_xtensa* binaries'''
$ '''make'''

It is not necessary to empty the 'dl' subdirectory, which contains tarballs downloaded from the Internet, nor the .config file, which contains the buildroot configuration. Customizations to the uClibc and <tt>busybox</tt> configurations should have ended up getting saved in target/xtensa/uClibc.config and target/xtensa/busybox-config, respectively, so hopefully are preserved by the above sequence.

== Build and Run a Linux Kernel on the XTAV60 or XTAV200 Board ==

References to the ''XTAV60 board'' refer to the combination of
the Avnet [http://www.em.avnet.com/tensilica1 LX60 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX60 (XT-AV60) Board User's Guide''.

Similarly, references to the ''XTAV200 board'' refers the combination of
the Avnet [http://www.em.avnet.com/tensilica2 LX200 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX200 (XT-AV200) Board User's Guide''.

=== Configure the kernel ===

The kernel build is a two-step process: configure the kernel, and build it.
First, before we can do anything with the kernel, set your PATH to
point to the toolchain built using buildroot.

$ export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"

where ''<cname>'' is the name of the Xtensa processor configuration you selected
when building the toolchain (e.g., <code>dc232b</code>).

Now setup a destination for kernel builds.
We usually like to have the build directory separate from
the source directory, so we use 'O=</destination/path>' in
kernel make commands. If you'll be routinely building multiple
configurations of the Linux kernel, it's good to have some
naming conventions for the build directory. For example,
to experiment with multiple target platforms but only one
processor configuration, we include just the platform name here:

$ mkdir build-xtav60

Let's start with the default kernel configuration for the Avnet board
(which works on both XTAV60 (LX60) and XTAV200 (LX200) boards)
as follows:

$ cd linux
$ make O=../build-xtav60 ARCH=xtensa KBUILD_DEFCONFIG=lx60_defconfig defconfig

This configures the kernel using the default configuration found in
arch/xtensa/configs/lx60_defconfig.

NOTE: This kernel configuration has nothing to do with Xtensa
processor configuration. That comes next.

Let's now customize this a little bit to select the correct Xtensa processor
configuration, and to bundle the root filesystem into the kernel:

$ make O=../build-xtav60 ARCH=xtensa menuconfig

Under '''General setup''',
make sure the '''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is enabled. Underneath that, edit '''Initramfs source file(s)''',
and enter the path to the cpio formatted root filesystem
generated by buildroot:

''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio.gz

(Don't forget to replace ''<workdir>'' with the appropriate full path
and ''<cname>'' with your Xtensa processor configuration name.)

Under '''Processor type and features''',
make sure the '''Xtensa Processor Configuration''' is correct and matches
the processor configuration name you used to build the toolchain with buildroot
(for example, ''dc232b'' for Diamond 232L Rev.B).
The kernel build selects a toolchain and processor variant specific headers
based on this selection.
If the desired processor configuration does not appear explicitly in the list,
simply select '''Custom Xtensa processor configuration''' and enter the
processor configuration name (all lowercase) into the next menu parameter,
'''Xtensa Processor Custom Variant Name'''.

Back in the main menu, under '''Platform options''', make sure the
'''CPU clock rate''' entry is set correctly according to the following table:

{| border="1" style="text-align:center; margin: 1em auto 1em auto"
|-
! Board !! Frequency selected in XPG (MHz) !! ''CPU clock rate'' setting (kHz)
|-
|rowspan="3"| XTAV60 (LX60)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV110 (LX110)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV200 (LX200)
| 30 || 31250
|-
| 40 || 41667
|-
| 50 || 50000
|-
|}

Exit menuconfig, saving your configuration changes.

Backup your configuration outside the build directory. For example:

$ cp ../build-xtav60/.config config.xtav60.saved

If you do a clean rebuild of the kernel (e.g., "rm -rf ../build-xtav60")
you can now configure it with simply:
$ mkdir ../build-xtav60 ; cp config.xtav60.saved ../build-xtav60/.config
Of course if you update the kernel, you'll probably again have to do:
$ make O=../build-xtav60 ARCH=xtensa menuconfig
and save a new copy of your configuration.

=== Build the kernel ===

$ make O=../build-xtav60 ARCH=xtensa

The build will issue a few warnings which are normal.
Once complete, the bootable image is in:
<workdir>/build-xtav60/arch/xtensa/boot/Image.elf
and the uncompressed ELF file containing kernel symbols is in:
<workdir>/build-xtav60/vmlinux
There is also a RedBoot bootable image (if you use RedBoot) in:
<workdir>/build-xtav60/arch/xtensa/boot/zImage.redboot

=== Install Xtensa Tools for the selected core ===

If you opt to download the kernel over OCD, you need <tt>xt-gdb</tt>
which is part of Tensilica's Xtensa Tools package. This must be obtained
from Tensilica, and is not the same toolchain as built by buildroot.
You also need to install the corresponding Tensilica core package,
so that the Xtensa Tools know about your particular configured
Tensilica core.

The toolchain built using buildroot can be configured to
include GDB, but that version of GDB does not support
communicating with Tensilica's Xtensa OCD Daemon, and
thus cannot be used to download the kernel over OCD.

In this example, it is assumed that the machine hosting the
Xtensa Tools has access to the <workdir> directory tree.

=== Install and setup the Xtensa OCD Daemon ===

Setup and connect your JTAG probe, etc.

=== Connect a terminal server ===

At 38400 bps 8N1 no flow control to the XTAV60 serial port.

=== Optionally, setup networking ===

This step is optional.

Setup the board's MAC address using dipswitches
(see XTAV60 or XTAV200 board docs as appropriate)
and connect the board to a network that has a
DHCP server that will respond to that MAC address.
If you don't do this step, you'll simply not have network
access, and the boot process will take a minute or so longer
while the kernel times out waiting for a BOOTP response.
You can edit the kernel configuration and rebuild the kernel
to avoid using bootp (in particular, remove "ip=bootp" from
the kernel cmdline).

=== Download and run the kernel ===

Reset the board (see board documentation).

Using Xtensa Tools, invoke:

$ xt-gdb <workdir>/build-xtav60/arch/xtensa/boot/Image.elf

(xt-gdb) target remote <ocdhost>:20000 0
(xt-gdb) reset
(xt-gdb) load
(xt-gdb) set $pc = &_ResetVector
(xt-gdb) symbol-file <workdir>/build-xtav60/vmlinux
(xt-gdb) c

where <ocdhost> is the IP address or DNS name of the machine
running the Xtensa OCD daemon. The Linux kernel should
start booting as soon as 'c' (continue) is executed.

You should eventually get a login prompt.
Just login as root (no password).

Try various Linux commands. Look at <tt>/bin</tt>,
<tt>/sbin</tt>, <tt>/usr/bin</tt>, etc to see what's available.

Note: no need to setup an NFS or TFTP server. The filesystem
is contained within the kernel image. You may be able to mount
other filesystems over NFS though, if you wish, after booting.

=== Mounting the Root Filesystem Over NFS ===

If you build more than the minimal set of packages using
buildroot, the root filesystem can easily grow too large to
fit comfortably (or at all) inside the kernel. In this case,
rather than follow the instructions exactly as above,
you'll want to mount the root filesystem over NFS.

You may also want to mount the root filesystem over NFS to
make changes to the filesystem persistent across runs and
accessible from your development host.

First you need to install the root filesystem generated
using buildroot, to a machine that can serve it over NFS.
Assuming this machine runs Linux, one way to install it is
as follows:

mkdir ''<exportpath>''
cd ''<exportpath>''
sudo cpio -i -d -m -F ''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio --no-absolute-filenames

You then need to enable the NFS server on your system
(if not already active), and export this filesystem.
How you do this depends on your host Linux distribution.
For example, on some Fedora releases, one might:

* add the export path to <tt>/etc/exports</tt> using a line such as

''<exportpath>'' *(rw,sync,no_root_squash,no_all_squash)

* turn on the NFS server if needed:

sudo /sbin/chkconfig nfs on

* tell the NFS server about the new exported filesystem

sudo /usr/sbin/exportfs -a
sudo /usr/sbin/exportfs -r

Second, follow the instructions in the previous sections,
then configure the kernel again as follows.

Under '''General setup''', make sure the
'''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is disabled (rather than enabled as done in previous sections).

Under '''Platform options''', under the line '''Default bootloader kernel arguments''',
select the boot parameters line and set it to something like this:

console=ttyS0,38400 ip=dhcp root=/dev/nfs rw nfsroot=''<server_ip>'':''<exportpath>''

where ''<server_ip>'' is the IP address of your NFS server, and ''<exportpath>''
is the exported filesystem path.

Save this configuration, rebuild the kernel, and follow the
instructions in previous sections to download and run the kernel.
If everything goes well and is setup correctly, your kernel should
now boot with a root filesystem mounted over NFS.

== Build and Run a Linux Kernel on the Instruction Set Simulator (ISS) ==

You can build and run a Linux kernel in the Xtensa Instruction Set
Simulator (ISS). The following instructions have only been tried
with an ISS from the RB-2008.3 release of Xtensa Tools. Bear in
mind that the XTAV60 port is likely much more stable than the ISS port
of Linux at this point in time.

Note: Depending on your host OS version, you may need to install
Xtensa Tools on a separate machine.

=== Configure and Build the Kernel for ISS ===

Repeat all the same instructions as above for building the kernel for an
Avnet board, except that when initially configuring the kernel,
start from a ISS platform template instead. For example for the
DC233C Variant:

'''$ mkdir build-iss'''
'''$ cd linux'''
'''$ make O=../build-iss ARCH=xtensa KBUILD_DEFCONFIG=iss_dc233c_defconfig defconfig'''

The above make example configures the kernel using the default configuration found in
'''arch/xtensa/configs/iss_dc233_defconfig'''. Most important to note is that the
root file system mounted when Linux boots comes via the targets device '''/dev/simdisk0'''
which is defined in the kernel '''.config''' file. For example:

'''CONFIG_SIMDISK0_FILENAME="/export2/DC_C_233L/LINUX_ROOT.ext2"'''

The SIMDISK file name and VARIANT name are typically configured when running '''make menuconfig'''; Ex:

'''$ make O=../build-iss ARCH=xtensa menuconfig'''

and selecting

'''Xtensa Platform options''' ---> '''Host filename for a simulated device'''

and entering the pathname to the .ext2 file there. Ex: '''/export2/DC_C_233L/LINUX_ROOT.ext2'''

You often want to change the VARIANT to the one you desire, Ex: FSF. You do this via
the top level menu:

'''Xtensa Processor type and features ---> Xtensa Processor Custom Core Variant Name'''

With the new SIMDISK approach you copy the EXT2 Filesystem file generated by Buildroot
to a location to be accessed by Xtensa Linux. Ex:

'''$ cp /export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot/binaries/dc233c/rootfs.xtensa_dc233c.ext2 /export2/DC_C_233L/LINUX_ROOT.ext2'''

'''NOTE:''' There is an old '''iss_defconfig''' that tries to use a '''tuntap''' Ethernet
interface that currently isn't supported.
Previously with this old iss_defconfig using the '''tuntap''' Ethernet interface
it was suggested to set up the initramfs filesystem, and do the following.
Under '''Bus Options''', deselect '''PCI support'''.
Under '''Platform Options''', deselect '''Default bootloader kernel arguments'''.
Hopefully we will someday be able to support the use of a network interface with
ISS simulation and then be able to mount NFS root partitions again. So I'm leaving
this note for future exploration of this mechanism; Hope you don't mind the clutter.

Continue configuring and building the kernel as usual.

=== Run the Kernel on ISS ===

Using Xtensa Tools, invoke:

'''$ xt-gdb <workdir>/build-iss/arch/xtensa/boot/Image.elf'''
'''(xt-gdb) target sim --turbo --memlimit=128'''
'''(xt-gdb) symbol-file <workdir>/build-iss/vmlinux'''
'''(xt-gdb) run'''

Wait patiently while Linux boots ... (maybe a minute). The setting of the '''memlimit'''
needs to match the PLATFORM_DEFAULT_MEM_SIZE defined in /arch/xtensa/platforms/iss/include/platform/hardware.h.
Currently this limit us 128 MegaBytes:

#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000 /* 13,4217,728 128M */

and we will be extending this for the DC233L to take advantage of it's V3 MMU.

Login as root (no password).

'''Note:''' Input via ISS is cooked, so everything typed gets echoed.
Also, time as reported by the kernel does not progress
according to true wall-clock time: it currently depends on
a simulated processor clock, which advances at various speeds
according to load.

Instructions for building and booting Linux

2011-01-06T04:03:32Z

Piet: /* Download buildroot and the Linux kernel */

These instructions explain how to build a toolchain, root filesystem and kernel for Linux running on an Xtensa processor. These instructions apply specifically to the XTAV60 (LX60) board.

Some general notes on these instructions:

* They are a work in progress. If you are using the latest development sources, the build process may change, so you should be sure to get the latest version of this document at [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions]. If you are using one of the development snapshot releases, you should use the version of the build instructions included with that snapshot.

* The following was tested on x86 machines running RedHat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3). It is expected to work on newer Fedora releases (e.g., was tested on FC6) but to maintain host compatibility with Xtensa Tools, it is best to avoid Fedora releases beyond FC5. Other host distributions likely work but have not been tested.
** '''NOTE:''' this assumes the default selection of packages in buildroot. Selecting extra packages may require a more recent host OS or more recent version of certain tools. For example, the default version of <tt>find</tt> on RHEL4 is too old to allow building all X11 packages in buildroot, so it is necessary to upgrade the host version of <tt>findutils</tt> on RHEL4 to build these packages.

* Lines prefixed with "sudo" need to be executed as root. The rest is best executed as a non-root user. (It is possible to install <tt>git</tt> as a non-root user if root access is an issue. How to do this isn't shown here.)

* Lines that set environment variables assume a Bourne compatible shell (e.g., /bin/sh or bash), but are easily adapted to other shells.

* Instructions are assumed executed all in order (e.g., commands assume current directory and environment variables set earlier).

== Setup your host system ==

If you are using one of the snapshot releases, you can skip this step.

If you want to work with the latest development sources, you will need
[[Installing GIT|<tt>git</tt> installed on your system]].

== Download buildroot and the Linux kernel ==

The following section describes how to download the latest
versions of buildroot and of the Linux kernel.
Skip this step if you are using one of the
[http://wiki.linux-xtensa.org/index.php/Buildroot_Snapshots snapshot releases].

For most users, just execute the following:

'''$ cd <workdir>'''
'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa.git buildroot'''
'''$ git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git linux'''

where <tt><workdir></tt> is the path to an empty directory on a disk with
at least 4 GB available space. You end up with the following file structure,
which is assumed by the rest of this document:

<workdir>/
/buildroot
/linux

The MASTER branch of the buildroot repository is often is a state of development.
It's recommended to use the last snapshot for application developers. In the
case of the Avnet development boards a 'snapshot_2+SMP' branch is recommended
in the currently experimental SMP git repository:

'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

If you happen to have write access to either repository, or want more details,
see the [http://wiki.linux-xtensa.org/index.php/Repository_Access repository access] page.

== Install any required processor specific overlay ==

This step is required if you are targeting a custom Xtensa processor.
If you use a Diamond 232L Standard Core, you can skip this step.

To configure buildroot and the kernel to use a custom Xtensa processor
configuration, you need to overlay a set of files customized for your
processor configuration onto toolchain sources (gcc, binutils, gdb, etc)
and the Linux kernel. This process has been automated using a script
located in the buildroot source tree.
For usage information, you can invoke it without arguments:

'''$ cd <workdir>'''
'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install'''

which displays a help message similar to the following:

xt-buildroot-overlay-install version 1.3
Usage: xt-buildroot-overlay-install <parameters> [<options>]
Where <parameters> are:
-t file.tgz Specify path to the Xtensa Linux overlay tarball, typically
<xtensa_root>/src/xtensa-config-overlay.tar.gz
-b dir Path to the base of the buildroot source tree, in which
package specific overlay tarballs get installed.
-k dir Path to the base of the Linux kernel source tree, in which
the Linux kernel specific overlay gets installed.
-c config_name Name for the Xtensa processor configuration as it will be
known to the open source community. Must be a lowercase
identifier, starting with a letter, consisting of letters
and numbers and underscores, not ending with underscore
and not containing consecutive underscores. For examples:
dc232b , dc232b_be , mmubasele , fsf , s5000 .
-l long_name Long name for the Xtensa processor configuration, human-
readable with spaces etc allowed (must be quoted).
For example: 'Diamond 232L Standard Core Rev.B (LE)'
Try to keep it within approximately 40 characters.
And <options> are:
-f If package specific overlay tarballs already exist in
the destination source tree, overwrite them without asking.
--help Show this usage message.

Note that the Xtensa Linux overlay tarball MUST be obtained from an Xtensa
core package built using release RB-2008.3 or later.

Here is an example invocation of the overlay installation script:

'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install -t blinkcore-config-overlay.tar.gz''' \
'''-b ./buildroot -k ./linux -c superzip -l "ChipCorp SuperZIP Blink Accelerator Core"'''

The script extracts some relevant information from the overlay tarball,
presents it along with relevant parameters to the user, and prompts
for confirmation before proceeding.

The chosen processor name (-c option) must be unique among known Xtensa processors.
It is also probably wise to avoid names confusingly similar to other (non-Xtensa) processors.
If you expect at some point to contribute support for your custom processor to the
open-source community, this name will likely be long-lived.
(One way to contribute support for a custom processor might be to submit the overlay tarball
or files to the linux-xtensa.org maintainers.)

In the steps below, buildroot and the Linux kernel must be configured
(in their respective <code>''make menuconfig''</code> steps) to select
the <code>''custom''</code> Xtensa processor option.
This presents an extra configuration menu entry where you must provide
the name of the Xtensa processor. Set it to the same name
as was specified in the <code>-c</code> option above.

== Build a toolchain and root filesystem using buildroot ==

'''Note:''' for more details on generic buildroot topics not covered in this simple how-to,
see [http://buildroot.uclibc.org/ buildroot.uclibc.org].

=== Configure buildroot ===

The first time you configure buildroot, start with defaults for your Xtensa processor:

'''$ cd <workdir>/buildroot'''
'''$ ./target/xtensa/setup-config <corename>'''

where ''<corename>'' is the overlay name of your selected Xtensa or Diamond core
(e.g., '''dc232b'''). If you omit ''<corename>'', a help message and a list
of currently installed Tensilica core overlays is displayed.

Optionally, you can then customize your buildroot configuration, such as
selecting additional packages, setting various parameters, and so on.
The following make targets provide a ''curses'' (text-based graphical) interface
for configuring buildroot, the uClibc C library, and busybox, respectively.
('''Note:''' You need the <tt>TERM</tt> environment variable properly set for
these curses based tools to work.)

'''$ make menuconfig'''
'''$ make uclibc-menuconfig'''
'''$ make busybox-menuconfig'''

=== Build buildroot ===

Just type:

'''$ make'''

THIS WILL TAKE A LONG TIME (from about 30 minutes with defaults on a 3 GHz Pentium 4,
to perhaps an hour or many depending on your system and on whether
you enabled extra packages in your buildroot configuration).

Wait patiently for the build to complete. This builds an entire toolchain
as well as some basic packages, and constructs a root filesystem.
It might build many more packages if you selected them earlier with menuconfig.

==== If Something Goes Wrong ====

Perhaps you missed some step above and the build fails. Or you're just switching to a different processor configuration, or making some change with unknown dependencies. Either way, you'll probably need to fix the error and/or make the change, and redo the whole build. The above <tt>make</tt> command usually works fine if you
just added a package using menuconfig, but otherwise does not check many dependencies, so it will usually NOT rebuild things that depend on whatever you have fixed or changed. Here's one way to retry the make from scratch without having to wipe out the <tt>buildroot</tt> directory tree completely and start again from the git cloning.

$ '''rm -rf *build_xtensa* binaries'''
$ '''make'''

It is not necessary to empty the 'dl' subdirectory, which contains tarballs downloaded from the Internet, nor the .config file, which contains the buildroot configuration. Customizations to the uClibc and <tt>busybox</tt> configurations should have ended up getting saved in target/xtensa/uClibc.config and target/xtensa/busybox-config, respectively, so hopefully are preserved by the above sequence.

== Build and Run a Linux Kernel on the XTAV60 or XTAV200 Board ==

References to the ''XTAV60 board'' refer to the combination of
the Avnet [http://www.em.avnet.com/tensilica1 LX60 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX60 (XT-AV60) Board User's Guide''.

Similarly, references to the ''XTAV200 board'' refers the combination of
the Avnet [http://www.em.avnet.com/tensilica2 LX200 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX200 (XT-AV200) Board User's Guide''.

=== Configure the kernel ===

The kernel build is a two-step process: configure the kernel, and build it.
First, before we can do anything with the kernel, set your PATH to
point to the toolchain built using buildroot.

$ export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"

where ''<cname>'' is the name of the Xtensa processor configuration you selected
when building the toolchain (e.g., <code>dc232b</code>).

Now setup a destination for kernel builds.
We usually like to have the build directory separate from
the source directory, so we use 'O=</destination/path>' in
kernel make commands. If you'll be routinely building multiple
configurations of the Linux kernel, it's good to have some
naming conventions for the build directory. For example,
to experiment with multiple target platforms but only one
processor configuration, we include just the platform name here:

$ mkdir build-xtav60

Let's start with the default kernel configuration for the Avnet board
(which works on both XTAV60 (LX60) and XTAV200 (LX200) boards)
as follows:

$ cd linux
$ make O=../build-xtav60 ARCH=xtensa KBUILD_DEFCONFIG=lx60_defconfig defconfig

This configures the kernel using the default configuration found in
arch/xtensa/configs/lx60_defconfig.

NOTE: This kernel configuration has nothing to do with Xtensa
processor configuration. That comes next.

Let's now customize this a little bit to select the correct Xtensa processor
configuration, and to bundle the root filesystem into the kernel:

$ make O=../build-xtav60 ARCH=xtensa menuconfig

Under '''General setup''',
make sure the '''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is enabled. Underneath that, edit '''Initramfs source file(s)''',
and enter the path to the cpio formatted root filesystem
generated by buildroot:

''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio.gz

(Don't forget to replace ''<workdir>'' with the appropriate full path
and ''<cname>'' with your Xtensa processor configuration name.)

Under '''Processor type and features''',
make sure the '''Xtensa Processor Configuration''' is correct and matches
the processor configuration name you used to build the toolchain with buildroot
(for example, ''dc232b'' for Diamond 232L Rev.B).
The kernel build selects a toolchain and processor variant specific headers
based on this selection.
If the desired processor configuration does not appear explicitly in the list,
simply select '''Custom Xtensa processor configuration''' and enter the
processor configuration name (all lowercase) into the next menu parameter,
'''Xtensa Processor Custom Variant Name'''.

Back in the main menu, under '''Platform options''', make sure the
'''CPU clock rate''' entry is set correctly according to the following table:

{| border="1" style="text-align:center; margin: 1em auto 1em auto"
|-
! Board !! Frequency selected in XPG (MHz) !! ''CPU clock rate'' setting (kHz)
|-
|rowspan="3"| XTAV60 (LX60)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV110 (LX110)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV200 (LX200)
| 30 || 31250
|-
| 40 || 41667
|-
| 50 || 50000
|-
|}

Exit menuconfig, saving your configuration changes.

Backup your configuration outside the build directory. For example:

$ cp ../build-xtav60/.config config.xtav60.saved

If you do a clean rebuild of the kernel (e.g., "rm -rf ../build-xtav60")
you can now configure it with simply:
$ mkdir ../build-xtav60 ; cp config.xtav60.saved ../build-xtav60/.config
Of course if you update the kernel, you'll probably again have to do:
$ make O=../build-xtav60 ARCH=xtensa menuconfig
and save a new copy of your configuration.

=== Build the kernel ===

$ make O=../build-xtav60 ARCH=xtensa

The build will issue a few warnings which are normal.
Once complete, the bootable image is in:
<workdir>/build-xtav60/arch/xtensa/boot/Image.elf
and the uncompressed ELF file containing kernel symbols is in:
<workdir>/build-xtav60/vmlinux
There is also a RedBoot bootable image (if you use RedBoot) in:
<workdir>/build-xtav60/arch/xtensa/boot/zImage.redboot

=== Install Xtensa Tools for the selected core ===

If you opt to download the kernel over OCD, you need <tt>xt-gdb</tt>
which is part of Tensilica's Xtensa Tools package. This must be obtained
from Tensilica, and is not the same toolchain as built by buildroot.
You also need to install the corresponding Tensilica core package,
so that the Xtensa Tools know about your particular configured
Tensilica core.

The toolchain built using buildroot can be configured to
include GDB, but that version of GDB does not support
communicating with Tensilica's Xtensa OCD Daemon, and
thus cannot be used to download the kernel over OCD.

In this example, it is assumed that the machine hosting the
Xtensa Tools has access to the <workdir> directory tree.

=== Install and setup the Xtensa OCD Daemon ===

Setup and connect your JTAG probe, etc.

=== Connect a terminal server ===

At 38400 bps 8N1 no flow control to the XTAV60 serial port.

=== Optionally, setup networking ===

This step is optional.

Setup the board's MAC address using dipswitches
(see XTAV60 or XTAV200 board docs as appropriate)
and connect the board to a network that has a
DHCP server that will respond to that MAC address.
If you don't do this step, you'll simply not have network
access, and the boot process will take a minute or so longer
while the kernel times out waiting for a BOOTP response.
You can edit the kernel configuration and rebuild the kernel
to avoid using bootp (in particular, remove "ip=bootp" from
the kernel cmdline).

=== Download and run the kernel ===

Reset the board (see board documentation).

Using Xtensa Tools, invoke:

$ xt-gdb <workdir>/build-xtav60/arch/xtensa/boot/Image.elf

(xt-gdb) target remote <ocdhost>:20000 0
(xt-gdb) reset
(xt-gdb) load
(xt-gdb) set $pc = &_ResetVector
(xt-gdb) symbol-file <workdir>/build-xtav60/vmlinux
(xt-gdb) c

where <ocdhost> is the IP address or DNS name of the machine
running the Xtensa OCD daemon. The Linux kernel should
start booting as soon as 'c' (continue) is executed.

You should eventually get a login prompt.
Just login as root (no password).

Try various Linux commands. Look at <tt>/bin</tt>,
<tt>/sbin</tt>, <tt>/usr/bin</tt>, etc to see what's available.

Note: no need to setup an NFS or TFTP server. The filesystem
is contained within the kernel image. You may be able to mount
other filesystems over NFS though, if you wish, after booting.

=== Mounting the Root Filesystem Over NFS ===

If you build more than the minimal set of packages using
buildroot, the root filesystem can easily grow too large to
fit comfortably (or at all) inside the kernel. In this case,
rather than follow the instructions exactly as above,
you'll want to mount the root filesystem over NFS.

You may also want to mount the root filesystem over NFS to
make changes to the filesystem persistent across runs and
accessible from your development host.

First you need to install the root filesystem generated
using buildroot, to a machine that can serve it over NFS.
Assuming this machine runs Linux, one way to install it is
as follows:

mkdir ''<exportpath>''
cd ''<exportpath>''
sudo cpio -i -d -m -F ''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio --no-absolute-filenames

You then need to enable the NFS server on your system
(if not already active), and export this filesystem.
How you do this depends on your host Linux distribution.
For example, on some Fedora releases, one might:

* add the export path to <tt>/etc/exports</tt> using a line such as

''<exportpath>'' *(rw,sync,no_root_squash,no_all_squash)

* turn on the NFS server if needed:

sudo /sbin/chkconfig nfs on

* tell the NFS server about the new exported filesystem

sudo /usr/sbin/exportfs -a
sudo /usr/sbin/exportfs -r

Second, follow the instructions in the previous sections,
then configure the kernel again as follows.

Under '''General setup''', make sure the
'''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is disabled (rather than enabled as done in previous sections).

Under '''Platform options''', under the line '''Default bootloader kernel arguments''',
select the boot parameters line and set it to something like this:

console=ttyS0,38400 ip=dhcp root=/dev/nfs rw nfsroot=''<server_ip>'':''<exportpath>''

where ''<server_ip>'' is the IP address of your NFS server, and ''<exportpath>''
is the exported filesystem path.

Save this configuration, rebuild the kernel, and follow the
instructions in previous sections to download and run the kernel.
If everything goes well and is setup correctly, your kernel should
now boot with a root filesystem mounted over NFS.

== Build and Run a Linux Kernel on the Instruction Set Simulator (ISS) ==

You can build and run a Linux kernel in the Xtensa Instruction Set
Simulator (ISS). The following instructions have only been tried
with an ISS from the RB-2008.3 release of Xtensa Tools. Bear in
mind that the XTAV60 port is likely much more stable than the ISS port
of Linux at this point in time.

Note: Depending on your host OS version, you may need to install
Xtensa Tools on a separate machine.

=== Configure and Build the Kernel for ISS ===

Repeat all the same instructions as above for building the kernel for an
Avnet board, except that when initially configuring the kernel,
start from a ISS platform template instead. For example for the
DC233C Variant:

'''$ mkdir build-iss'''
'''$ cd linux'''
'''$ make O=../build-iss ARCH=xtensa KBUILD_DEFCONFIG=iss_dc233c_defconfig defconfig'''

The above make example configures the kernel using the default configuration found in
'''arch/xtensa/configs/iss_dc233_defconfig'''. Most important to note is that the
root file system mounted when Linux boots comes via the targets device '''/dev/simdisk0'''
which is defined in the kernel '''.config''' file. For example:

'''CONFIG_SIMDISK0_FILENAME="/export2/DC_C_233L/LINUX_ROOT.ext2"'''

The SIMDISK file name and VARIANT name are typically configured when running '''make menuconfig'''; Ex:

'''$ make O=../build-iss ARCH=xtensa menuconfig'''

and selecting

'''Xtensa Platform options''' ---> '''Host filename for a simulated device'''

and entering the pathname to the .ext2 file there. Ex: '''/export2/DC_C_233L/LINUX_ROOT.ext2'''

You often want to change the VARIANT to the one you desire, Ex: FSF. You do this via
the top level menu:

'''Xtensa Processor type and features ---> Xtensa Processor Custom Core Variant Name'''

With the new SIMDISK approach you copy the EXT2 Filesystem file generated by Buildroot
to a location to be accessed by Xtensa Linux. Ex:

'''$ cp /export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot/binaries/dc233c/rootfs.xtensa_dc233c.ext2 /export2/DC_C_233L/LINUX_ROOT.ext2'''

'''NOTE:''' There is an old '''iss_defconfig''' that tries to use a '''tuntap''' Ethernet
interface that currently isn't supported.
Previously with this old iss_defconfig using the '''tuntap''' Ethernet interface
it was suggested to set up the initramfs filesystem, and do the following.
Under '''Bus Options''', deselect '''PCI support'''.
Under '''Platform Options''', deselect '''Default bootloader kernel arguments'''.
Hopefully we will someday be able to support the use of a network interface with
ISS simulation and then be able to mount NFS root partitions again. So I'm leaving
this note for future exploration of this mechanism; Hope you don't mind the clutter.

Continue configuring and building the kernel as usual.

=== Run the Kernel on ISS ===

Using Xtensa Tools, invoke:

'''$ xt-gdb <workdir>/build-iss/arch/xtensa/boot/Image.elf'''
'''(xt-gdb) target sim --turbo --memlimit=128'''
'''(xt-gdb) symbol-file <workdir>/build-iss/vmlinux'''
'''(xt-gdb) run'''

Wait patiently while Linux boots ... (maybe a minute). The setting of the '''memlimit'''
needs to match the PLATFORM_DEFAULT_MEM_SIZE defined in /arch/xtensa/platforms/iss/include/platform/hardware.h.
Currently this limit us 128 MegaBytes:

#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000 /* 13,4217,728 128M */

and we will be extending this for the DC233L to take advantage of it's V3 MMU.

Login as root (no password).

'''Note:''' Input via ISS is cooked, so everything typed gets echoed.
Also, time as reported by the kernel does not progress
according to true wall-clock time: it currently depends on
a simulated processor clock, which advances at various speeds
according to load.

Instructions for building and booting Linux

2011-01-06T04:01:09Z

Piet: /* Configure and Build the Kernel for ISS */

These instructions explain how to build a toolchain, root filesystem and kernel for Linux running on an Xtensa processor. These instructions apply specifically to the XTAV60 (LX60) board.

Some general notes on these instructions:

* They are a work in progress. If you are using the latest development sources, the build process may change, so you should be sure to get the latest version of this document at [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions]. If you are using one of the development snapshot releases, you should use the version of the build instructions included with that snapshot.

* The following was tested on x86 machines running RedHat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3). It is expected to work on newer Fedora releases (e.g., was tested on FC6) but to maintain host compatibility with Xtensa Tools, it is best to avoid Fedora releases beyond FC5. Other host distributions likely work but have not been tested.
** '''NOTE:''' this assumes the default selection of packages in buildroot. Selecting extra packages may require a more recent host OS or more recent version of certain tools. For example, the default version of <tt>find</tt> on RHEL4 is too old to allow building all X11 packages in buildroot, so it is necessary to upgrade the host version of <tt>findutils</tt> on RHEL4 to build these packages.

* Lines prefixed with "sudo" need to be executed as root. The rest is best executed as a non-root user. (It is possible to install <tt>git</tt> as a non-root user if root access is an issue. How to do this isn't shown here.)

* Lines that set environment variables assume a Bourne compatible shell (e.g., /bin/sh or bash), but are easily adapted to other shells.

* Instructions are assumed executed all in order (e.g., commands assume current directory and environment variables set earlier).

== Setup your host system ==

If you are using one of the snapshot releases, you can skip this step.

If you want to work with the latest development sources, you will need
[[Installing GIT|<tt>git</tt> installed on your system]].

== Download buildroot and the Linux kernel ==

The following section describes how to download the latest
versions of buildroot and of the Linux kernel.
Skip this step if you are using one of the
[http://wiki.linux-xtensa.org/index.php/Buildroot_Snapshots snapshot releases].

For most users, just execute the following:

'''$ cd <workdir>'''
'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa.git buildroot'''
'''$ git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git linux'''

where <tt><workdir></tt> is the path to an empty directory on a disk with
at least 4 GB available space. You end up with the following file structure,
which is assumed by the rest of this document:

<workdir>/
/buildroot
/linux

The MASTER branch of the buildroot repository is often is a state of development.
It's recommended to use the last snapshot for application developers. In the
case of the HiFi-2 development board a 'snapshot_2+SMP' branch is recommended
in the currently experimental SMP git repository:

'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

If you happen to have write access to either repository, or want more details,
see the [http://wiki.linux-xtensa.org/index.php/Repository_Access repository access] page.

== Install any required processor specific overlay ==

This step is required if you are targeting a custom Xtensa processor.
If you use a Diamond 232L Standard Core, you can skip this step.

To configure buildroot and the kernel to use a custom Xtensa processor
configuration, you need to overlay a set of files customized for your
processor configuration onto toolchain sources (gcc, binutils, gdb, etc)
and the Linux kernel. This process has been automated using a script
located in the buildroot source tree.
For usage information, you can invoke it without arguments:

'''$ cd <workdir>'''
'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install'''

which displays a help message similar to the following:

xt-buildroot-overlay-install version 1.3
Usage: xt-buildroot-overlay-install <parameters> [<options>]
Where <parameters> are:
-t file.tgz Specify path to the Xtensa Linux overlay tarball, typically
<xtensa_root>/src/xtensa-config-overlay.tar.gz
-b dir Path to the base of the buildroot source tree, in which
package specific overlay tarballs get installed.
-k dir Path to the base of the Linux kernel source tree, in which
the Linux kernel specific overlay gets installed.
-c config_name Name for the Xtensa processor configuration as it will be
known to the open source community. Must be a lowercase
identifier, starting with a letter, consisting of letters
and numbers and underscores, not ending with underscore
and not containing consecutive underscores. For examples:
dc232b , dc232b_be , mmubasele , fsf , s5000 .
-l long_name Long name for the Xtensa processor configuration, human-
readable with spaces etc allowed (must be quoted).
For example: 'Diamond 232L Standard Core Rev.B (LE)'
Try to keep it within approximately 40 characters.
And <options> are:
-f If package specific overlay tarballs already exist in
the destination source tree, overwrite them without asking.
--help Show this usage message.

Note that the Xtensa Linux overlay tarball MUST be obtained from an Xtensa
core package built using release RB-2008.3 or later.

Here is an example invocation of the overlay installation script:

'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install -t blinkcore-config-overlay.tar.gz''' \
'''-b ./buildroot -k ./linux -c superzip -l "ChipCorp SuperZIP Blink Accelerator Core"'''

The script extracts some relevant information from the overlay tarball,
presents it along with relevant parameters to the user, and prompts
for confirmation before proceeding.

The chosen processor name (-c option) must be unique among known Xtensa processors.
It is also probably wise to avoid names confusingly similar to other (non-Xtensa) processors.
If you expect at some point to contribute support for your custom processor to the
open-source community, this name will likely be long-lived.
(One way to contribute support for a custom processor might be to submit the overlay tarball
or files to the linux-xtensa.org maintainers.)

In the steps below, buildroot and the Linux kernel must be configured
(in their respective <code>''make menuconfig''</code> steps) to select
the <code>''custom''</code> Xtensa processor option.
This presents an extra configuration menu entry where you must provide
the name of the Xtensa processor. Set it to the same name
as was specified in the <code>-c</code> option above.

== Build a toolchain and root filesystem using buildroot ==

'''Note:''' for more details on generic buildroot topics not covered in this simple how-to,
see [http://buildroot.uclibc.org/ buildroot.uclibc.org].

=== Configure buildroot ===

The first time you configure buildroot, start with defaults for your Xtensa processor:

'''$ cd <workdir>/buildroot'''
'''$ ./target/xtensa/setup-config <corename>'''

where ''<corename>'' is the overlay name of your selected Xtensa or Diamond core
(e.g., '''dc232b'''). If you omit ''<corename>'', a help message and a list
of currently installed Tensilica core overlays is displayed.

Optionally, you can then customize your buildroot configuration, such as
selecting additional packages, setting various parameters, and so on.
The following make targets provide a ''curses'' (text-based graphical) interface
for configuring buildroot, the uClibc C library, and busybox, respectively.
('''Note:''' You need the <tt>TERM</tt> environment variable properly set for
these curses based tools to work.)

'''$ make menuconfig'''
'''$ make uclibc-menuconfig'''
'''$ make busybox-menuconfig'''

=== Build buildroot ===

Just type:

'''$ make'''

THIS WILL TAKE A LONG TIME (from about 30 minutes with defaults on a 3 GHz Pentium 4,
to perhaps an hour or many depending on your system and on whether
you enabled extra packages in your buildroot configuration).

Wait patiently for the build to complete. This builds an entire toolchain
as well as some basic packages, and constructs a root filesystem.
It might build many more packages if you selected them earlier with menuconfig.

==== If Something Goes Wrong ====

Perhaps you missed some step above and the build fails. Or you're just switching to a different processor configuration, or making some change with unknown dependencies. Either way, you'll probably need to fix the error and/or make the change, and redo the whole build. The above <tt>make</tt> command usually works fine if you
just added a package using menuconfig, but otherwise does not check many dependencies, so it will usually NOT rebuild things that depend on whatever you have fixed or changed. Here's one way to retry the make from scratch without having to wipe out the <tt>buildroot</tt> directory tree completely and start again from the git cloning.

$ '''rm -rf *build_xtensa* binaries'''
$ '''make'''

It is not necessary to empty the 'dl' subdirectory, which contains tarballs downloaded from the Internet, nor the .config file, which contains the buildroot configuration. Customizations to the uClibc and <tt>busybox</tt> configurations should have ended up getting saved in target/xtensa/uClibc.config and target/xtensa/busybox-config, respectively, so hopefully are preserved by the above sequence.

== Build and Run a Linux Kernel on the XTAV60 or XTAV200 Board ==

References to the ''XTAV60 board'' refer to the combination of
the Avnet [http://www.em.avnet.com/tensilica1 LX60 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX60 (XT-AV60) Board User's Guide''.

Similarly, references to the ''XTAV200 board'' refers the combination of
the Avnet [http://www.em.avnet.com/tensilica2 LX200 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX200 (XT-AV200) Board User's Guide''.

=== Configure the kernel ===

The kernel build is a two-step process: configure the kernel, and build it.
First, before we can do anything with the kernel, set your PATH to
point to the toolchain built using buildroot.

$ export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"

where ''<cname>'' is the name of the Xtensa processor configuration you selected
when building the toolchain (e.g., <code>dc232b</code>).

Now setup a destination for kernel builds.
We usually like to have the build directory separate from
the source directory, so we use 'O=</destination/path>' in
kernel make commands. If you'll be routinely building multiple
configurations of the Linux kernel, it's good to have some
naming conventions for the build directory. For example,
to experiment with multiple target platforms but only one
processor configuration, we include just the platform name here:

$ mkdir build-xtav60

Let's start with the default kernel configuration for the Avnet board
(which works on both XTAV60 (LX60) and XTAV200 (LX200) boards)
as follows:

$ cd linux
$ make O=../build-xtav60 ARCH=xtensa KBUILD_DEFCONFIG=lx60_defconfig defconfig

This configures the kernel using the default configuration found in
arch/xtensa/configs/lx60_defconfig.

NOTE: This kernel configuration has nothing to do with Xtensa
processor configuration. That comes next.

Let's now customize this a little bit to select the correct Xtensa processor
configuration, and to bundle the root filesystem into the kernel:

$ make O=../build-xtav60 ARCH=xtensa menuconfig

Under '''General setup''',
make sure the '''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is enabled. Underneath that, edit '''Initramfs source file(s)''',
and enter the path to the cpio formatted root filesystem
generated by buildroot:

''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio.gz

(Don't forget to replace ''<workdir>'' with the appropriate full path
and ''<cname>'' with your Xtensa processor configuration name.)

Under '''Processor type and features''',
make sure the '''Xtensa Processor Configuration''' is correct and matches
the processor configuration name you used to build the toolchain with buildroot
(for example, ''dc232b'' for Diamond 232L Rev.B).
The kernel build selects a toolchain and processor variant specific headers
based on this selection.
If the desired processor configuration does not appear explicitly in the list,
simply select '''Custom Xtensa processor configuration''' and enter the
processor configuration name (all lowercase) into the next menu parameter,
'''Xtensa Processor Custom Variant Name'''.

Back in the main menu, under '''Platform options''', make sure the
'''CPU clock rate''' entry is set correctly according to the following table:

{| border="1" style="text-align:center; margin: 1em auto 1em auto"
|-
! Board !! Frequency selected in XPG (MHz) !! ''CPU clock rate'' setting (kHz)
|-
|rowspan="3"| XTAV60 (LX60)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV110 (LX110)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV200 (LX200)
| 30 || 31250
|-
| 40 || 41667
|-
| 50 || 50000
|-
|}

Exit menuconfig, saving your configuration changes.

Backup your configuration outside the build directory. For example:

$ cp ../build-xtav60/.config config.xtav60.saved

If you do a clean rebuild of the kernel (e.g., "rm -rf ../build-xtav60")
you can now configure it with simply:
$ mkdir ../build-xtav60 ; cp config.xtav60.saved ../build-xtav60/.config
Of course if you update the kernel, you'll probably again have to do:
$ make O=../build-xtav60 ARCH=xtensa menuconfig
and save a new copy of your configuration.

=== Build the kernel ===

$ make O=../build-xtav60 ARCH=xtensa

The build will issue a few warnings which are normal.
Once complete, the bootable image is in:
<workdir>/build-xtav60/arch/xtensa/boot/Image.elf
and the uncompressed ELF file containing kernel symbols is in:
<workdir>/build-xtav60/vmlinux
There is also a RedBoot bootable image (if you use RedBoot) in:
<workdir>/build-xtav60/arch/xtensa/boot/zImage.redboot

=== Install Xtensa Tools for the selected core ===

If you opt to download the kernel over OCD, you need <tt>xt-gdb</tt>
which is part of Tensilica's Xtensa Tools package. This must be obtained
from Tensilica, and is not the same toolchain as built by buildroot.
You also need to install the corresponding Tensilica core package,
so that the Xtensa Tools know about your particular configured
Tensilica core.

The toolchain built using buildroot can be configured to
include GDB, but that version of GDB does not support
communicating with Tensilica's Xtensa OCD Daemon, and
thus cannot be used to download the kernel over OCD.

In this example, it is assumed that the machine hosting the
Xtensa Tools has access to the <workdir> directory tree.

=== Install and setup the Xtensa OCD Daemon ===

Setup and connect your JTAG probe, etc.

=== Connect a terminal server ===

At 38400 bps 8N1 no flow control to the XTAV60 serial port.

=== Optionally, setup networking ===

This step is optional.

Setup the board's MAC address using dipswitches
(see XTAV60 or XTAV200 board docs as appropriate)
and connect the board to a network that has a
DHCP server that will respond to that MAC address.
If you don't do this step, you'll simply not have network
access, and the boot process will take a minute or so longer
while the kernel times out waiting for a BOOTP response.
You can edit the kernel configuration and rebuild the kernel
to avoid using bootp (in particular, remove "ip=bootp" from
the kernel cmdline).

=== Download and run the kernel ===

Reset the board (see board documentation).

Using Xtensa Tools, invoke:

$ xt-gdb <workdir>/build-xtav60/arch/xtensa/boot/Image.elf

(xt-gdb) target remote <ocdhost>:20000 0
(xt-gdb) reset
(xt-gdb) load
(xt-gdb) set $pc = &_ResetVector
(xt-gdb) symbol-file <workdir>/build-xtav60/vmlinux
(xt-gdb) c

where <ocdhost> is the IP address or DNS name of the machine
running the Xtensa OCD daemon. The Linux kernel should
start booting as soon as 'c' (continue) is executed.

You should eventually get a login prompt.
Just login as root (no password).

Try various Linux commands. Look at <tt>/bin</tt>,
<tt>/sbin</tt>, <tt>/usr/bin</tt>, etc to see what's available.

Note: no need to setup an NFS or TFTP server. The filesystem
is contained within the kernel image. You may be able to mount
other filesystems over NFS though, if you wish, after booting.

=== Mounting the Root Filesystem Over NFS ===

If you build more than the minimal set of packages using
buildroot, the root filesystem can easily grow too large to
fit comfortably (or at all) inside the kernel. In this case,
rather than follow the instructions exactly as above,
you'll want to mount the root filesystem over NFS.

You may also want to mount the root filesystem over NFS to
make changes to the filesystem persistent across runs and
accessible from your development host.

First you need to install the root filesystem generated
using buildroot, to a machine that can serve it over NFS.
Assuming this machine runs Linux, one way to install it is
as follows:

mkdir ''<exportpath>''
cd ''<exportpath>''
sudo cpio -i -d -m -F ''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio --no-absolute-filenames

You then need to enable the NFS server on your system
(if not already active), and export this filesystem.
How you do this depends on your host Linux distribution.
For example, on some Fedora releases, one might:

* add the export path to <tt>/etc/exports</tt> using a line such as

''<exportpath>'' *(rw,sync,no_root_squash,no_all_squash)

* turn on the NFS server if needed:

sudo /sbin/chkconfig nfs on

* tell the NFS server about the new exported filesystem

sudo /usr/sbin/exportfs -a
sudo /usr/sbin/exportfs -r

Second, follow the instructions in the previous sections,
then configure the kernel again as follows.

Under '''General setup''', make sure the
'''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is disabled (rather than enabled as done in previous sections).

Under '''Platform options''', under the line '''Default bootloader kernel arguments''',
select the boot parameters line and set it to something like this:

console=ttyS0,38400 ip=dhcp root=/dev/nfs rw nfsroot=''<server_ip>'':''<exportpath>''

where ''<server_ip>'' is the IP address of your NFS server, and ''<exportpath>''
is the exported filesystem path.

Save this configuration, rebuild the kernel, and follow the
instructions in previous sections to download and run the kernel.
If everything goes well and is setup correctly, your kernel should
now boot with a root filesystem mounted over NFS.

== Build and Run a Linux Kernel on the Instruction Set Simulator (ISS) ==

You can build and run a Linux kernel in the Xtensa Instruction Set
Simulator (ISS). The following instructions have only been tried
with an ISS from the RB-2008.3 release of Xtensa Tools. Bear in
mind that the XTAV60 port is likely much more stable than the ISS port
of Linux at this point in time.

Note: Depending on your host OS version, you may need to install
Xtensa Tools on a separate machine.

=== Configure and Build the Kernel for ISS ===

Repeat all the same instructions as above for building the kernel for an
Avnet board, except that when initially configuring the kernel,
start from a ISS platform template instead. For example for the
DC233C Variant:

'''$ mkdir build-iss'''
'''$ cd linux'''
'''$ make O=../build-iss ARCH=xtensa KBUILD_DEFCONFIG=iss_dc233c_defconfig defconfig'''

The above make example configures the kernel using the default configuration found in
'''arch/xtensa/configs/iss_dc233_defconfig'''. Most important to note is that the
root file system mounted when Linux boots comes via the targets device '''/dev/simdisk0'''
which is defined in the kernel '''.config''' file. For example:

'''CONFIG_SIMDISK0_FILENAME="/export2/DC_C_233L/LINUX_ROOT.ext2"'''

The SIMDISK file name and VARIANT name are typically configured when running '''make menuconfig'''; Ex:

'''$ make O=../build-iss ARCH=xtensa menuconfig'''

and selecting

'''Xtensa Platform options''' ---> '''Host filename for a simulated device'''

and entering the pathname to the .ext2 file there. Ex: '''/export2/DC_C_233L/LINUX_ROOT.ext2'''

You often want to change the VARIANT to the one you desire, Ex: FSF. You do this via
the top level menu:

'''Xtensa Processor type and features ---> Xtensa Processor Custom Core Variant Name'''

With the new SIMDISK approach you copy the EXT2 Filesystem file generated by Buildroot
to a location to be accessed by Xtensa Linux. Ex:

'''$ cp /export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot/binaries/dc233c/rootfs.xtensa_dc233c.ext2 /export2/DC_C_233L/LINUX_ROOT.ext2'''

'''NOTE:''' There is an old '''iss_defconfig''' that tries to use a '''tuntap''' Ethernet
interface that currently isn't supported.
Previously with this old iss_defconfig using the '''tuntap''' Ethernet interface
it was suggested to set up the initramfs filesystem, and do the following.
Under '''Bus Options''', deselect '''PCI support'''.
Under '''Platform Options''', deselect '''Default bootloader kernel arguments'''.
Hopefully we will someday be able to support the use of a network interface with
ISS simulation and then be able to mount NFS root partitions again. So I'm leaving
this note for future exploration of this mechanism; Hope you don't mind the clutter.

Continue configuring and building the kernel as usual.

=== Run the Kernel on ISS ===

Using Xtensa Tools, invoke:

'''$ xt-gdb <workdir>/build-iss/arch/xtensa/boot/Image.elf'''
'''(xt-gdb) target sim --turbo --memlimit=128'''
'''(xt-gdb) symbol-file <workdir>/build-iss/vmlinux'''
'''(xt-gdb) run'''

Wait patiently while Linux boots ... (maybe a minute). The setting of the '''memlimit'''
needs to match the PLATFORM_DEFAULT_MEM_SIZE defined in /arch/xtensa/platforms/iss/include/platform/hardware.h.
Currently this limit us 128 MegaBytes:

#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000 /* 13,4217,728 128M */

and we will be extending this for the DC233L to take advantage of it's V3 MMU.

Login as root (no password).

'''Note:''' Input via ISS is cooked, so everything typed gets echoed.
Also, time as reported by the kernel does not progress
according to true wall-clock time: it currently depends on
a simulated processor clock, which advances at various speeds
according to load.

Instructions for building and booting Linux

2011-01-06T03:59:55Z

Piet: /* Configure and Build the Kernel for ISS */

These instructions explain how to build a toolchain, root filesystem and kernel for Linux running on an Xtensa processor. These instructions apply specifically to the XTAV60 (LX60) board.

Some general notes on these instructions:

* They are a work in progress. If you are using the latest development sources, the build process may change, so you should be sure to get the latest version of this document at [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions]. If you are using one of the development snapshot releases, you should use the version of the build instructions included with that snapshot.

* The following was tested on x86 machines running RedHat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3). It is expected to work on newer Fedora releases (e.g., was tested on FC6) but to maintain host compatibility with Xtensa Tools, it is best to avoid Fedora releases beyond FC5. Other host distributions likely work but have not been tested.
** '''NOTE:''' this assumes the default selection of packages in buildroot. Selecting extra packages may require a more recent host OS or more recent version of certain tools. For example, the default version of <tt>find</tt> on RHEL4 is too old to allow building all X11 packages in buildroot, so it is necessary to upgrade the host version of <tt>findutils</tt> on RHEL4 to build these packages.

* Lines prefixed with "sudo" need to be executed as root. The rest is best executed as a non-root user. (It is possible to install <tt>git</tt> as a non-root user if root access is an issue. How to do this isn't shown here.)

* Lines that set environment variables assume a Bourne compatible shell (e.g., /bin/sh or bash), but are easily adapted to other shells.

* Instructions are assumed executed all in order (e.g., commands assume current directory and environment variables set earlier).

== Setup your host system ==

If you are using one of the snapshot releases, you can skip this step.

If you want to work with the latest development sources, you will need
[[Installing GIT|<tt>git</tt> installed on your system]].

== Download buildroot and the Linux kernel ==

The following section describes how to download the latest
versions of buildroot and of the Linux kernel.
Skip this step if you are using one of the
[http://wiki.linux-xtensa.org/index.php/Buildroot_Snapshots snapshot releases].

For most users, just execute the following:

'''$ cd <workdir>'''
'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa.git buildroot'''
'''$ git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git linux'''

where <tt><workdir></tt> is the path to an empty directory on a disk with
at least 4 GB available space. You end up with the following file structure,
which is assumed by the rest of this document:

<workdir>/
/buildroot
/linux

The MASTER branch of the buildroot repository is often is a state of development.
It's recommended to use the last snapshot for application developers. In the
case of the HiFi-2 development board a 'snapshot_2+SMP' branch is recommended
in the currently experimental SMP git repository:

'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

If you happen to have write access to either repository, or want more details,
see the [http://wiki.linux-xtensa.org/index.php/Repository_Access repository access] page.

== Install any required processor specific overlay ==

This step is required if you are targeting a custom Xtensa processor.
If you use a Diamond 232L Standard Core, you can skip this step.

To configure buildroot and the kernel to use a custom Xtensa processor
configuration, you need to overlay a set of files customized for your
processor configuration onto toolchain sources (gcc, binutils, gdb, etc)
and the Linux kernel. This process has been automated using a script
located in the buildroot source tree.
For usage information, you can invoke it without arguments:

'''$ cd <workdir>'''
'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install'''

which displays a help message similar to the following:

xt-buildroot-overlay-install version 1.3
Usage: xt-buildroot-overlay-install <parameters> [<options>]
Where <parameters> are:
-t file.tgz Specify path to the Xtensa Linux overlay tarball, typically
<xtensa_root>/src/xtensa-config-overlay.tar.gz
-b dir Path to the base of the buildroot source tree, in which
package specific overlay tarballs get installed.
-k dir Path to the base of the Linux kernel source tree, in which
the Linux kernel specific overlay gets installed.
-c config_name Name for the Xtensa processor configuration as it will be
known to the open source community. Must be a lowercase
identifier, starting with a letter, consisting of letters
and numbers and underscores, not ending with underscore
and not containing consecutive underscores. For examples:
dc232b , dc232b_be , mmubasele , fsf , s5000 .
-l long_name Long name for the Xtensa processor configuration, human-
readable with spaces etc allowed (must be quoted).
For example: 'Diamond 232L Standard Core Rev.B (LE)'
Try to keep it within approximately 40 characters.
And <options> are:
-f If package specific overlay tarballs already exist in
the destination source tree, overwrite them without asking.
--help Show this usage message.

Note that the Xtensa Linux overlay tarball MUST be obtained from an Xtensa
core package built using release RB-2008.3 or later.

Here is an example invocation of the overlay installation script:

'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install -t blinkcore-config-overlay.tar.gz''' \
'''-b ./buildroot -k ./linux -c superzip -l "ChipCorp SuperZIP Blink Accelerator Core"'''

The script extracts some relevant information from the overlay tarball,
presents it along with relevant parameters to the user, and prompts
for confirmation before proceeding.

The chosen processor name (-c option) must be unique among known Xtensa processors.
It is also probably wise to avoid names confusingly similar to other (non-Xtensa) processors.
If you expect at some point to contribute support for your custom processor to the
open-source community, this name will likely be long-lived.
(One way to contribute support for a custom processor might be to submit the overlay tarball
or files to the linux-xtensa.org maintainers.)

In the steps below, buildroot and the Linux kernel must be configured
(in their respective <code>''make menuconfig''</code> steps) to select
the <code>''custom''</code> Xtensa processor option.
This presents an extra configuration menu entry where you must provide
the name of the Xtensa processor. Set it to the same name
as was specified in the <code>-c</code> option above.

== Build a toolchain and root filesystem using buildroot ==

'''Note:''' for more details on generic buildroot topics not covered in this simple how-to,
see [http://buildroot.uclibc.org/ buildroot.uclibc.org].

=== Configure buildroot ===

The first time you configure buildroot, start with defaults for your Xtensa processor:

'''$ cd <workdir>/buildroot'''
'''$ ./target/xtensa/setup-config <corename>'''

where ''<corename>'' is the overlay name of your selected Xtensa or Diamond core
(e.g., '''dc232b'''). If you omit ''<corename>'', a help message and a list
of currently installed Tensilica core overlays is displayed.

Optionally, you can then customize your buildroot configuration, such as
selecting additional packages, setting various parameters, and so on.
The following make targets provide a ''curses'' (text-based graphical) interface
for configuring buildroot, the uClibc C library, and busybox, respectively.
('''Note:''' You need the <tt>TERM</tt> environment variable properly set for
these curses based tools to work.)

'''$ make menuconfig'''
'''$ make uclibc-menuconfig'''
'''$ make busybox-menuconfig'''

=== Build buildroot ===

Just type:

'''$ make'''

THIS WILL TAKE A LONG TIME (from about 30 minutes with defaults on a 3 GHz Pentium 4,
to perhaps an hour or many depending on your system and on whether
you enabled extra packages in your buildroot configuration).

Wait patiently for the build to complete. This builds an entire toolchain
as well as some basic packages, and constructs a root filesystem.
It might build many more packages if you selected them earlier with menuconfig.

==== If Something Goes Wrong ====

Perhaps you missed some step above and the build fails. Or you're just switching to a different processor configuration, or making some change with unknown dependencies. Either way, you'll probably need to fix the error and/or make the change, and redo the whole build. The above <tt>make</tt> command usually works fine if you
just added a package using menuconfig, but otherwise does not check many dependencies, so it will usually NOT rebuild things that depend on whatever you have fixed or changed. Here's one way to retry the make from scratch without having to wipe out the <tt>buildroot</tt> directory tree completely and start again from the git cloning.

$ '''rm -rf *build_xtensa* binaries'''
$ '''make'''

It is not necessary to empty the 'dl' subdirectory, which contains tarballs downloaded from the Internet, nor the .config file, which contains the buildroot configuration. Customizations to the uClibc and <tt>busybox</tt> configurations should have ended up getting saved in target/xtensa/uClibc.config and target/xtensa/busybox-config, respectively, so hopefully are preserved by the above sequence.

== Build and Run a Linux Kernel on the XTAV60 or XTAV200 Board ==

References to the ''XTAV60 board'' refer to the combination of
the Avnet [http://www.em.avnet.com/tensilica1 LX60 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX60 (XT-AV60) Board User's Guide''.

Similarly, references to the ''XTAV200 board'' refers the combination of
the Avnet [http://www.em.avnet.com/tensilica2 LX200 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX200 (XT-AV200) Board User's Guide''.

=== Configure the kernel ===

The kernel build is a two-step process: configure the kernel, and build it.
First, before we can do anything with the kernel, set your PATH to
point to the toolchain built using buildroot.

$ export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"

where ''<cname>'' is the name of the Xtensa processor configuration you selected
when building the toolchain (e.g., <code>dc232b</code>).

Now setup a destination for kernel builds.
We usually like to have the build directory separate from
the source directory, so we use 'O=</destination/path>' in
kernel make commands. If you'll be routinely building multiple
configurations of the Linux kernel, it's good to have some
naming conventions for the build directory. For example,
to experiment with multiple target platforms but only one
processor configuration, we include just the platform name here:

$ mkdir build-xtav60

Let's start with the default kernel configuration for the Avnet board
(which works on both XTAV60 (LX60) and XTAV200 (LX200) boards)
as follows:

$ cd linux
$ make O=../build-xtav60 ARCH=xtensa KBUILD_DEFCONFIG=lx60_defconfig defconfig

This configures the kernel using the default configuration found in
arch/xtensa/configs/lx60_defconfig.

NOTE: This kernel configuration has nothing to do with Xtensa
processor configuration. That comes next.

Let's now customize this a little bit to select the correct Xtensa processor
configuration, and to bundle the root filesystem into the kernel:

$ make O=../build-xtav60 ARCH=xtensa menuconfig

Under '''General setup''',
make sure the '''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is enabled. Underneath that, edit '''Initramfs source file(s)''',
and enter the path to the cpio formatted root filesystem
generated by buildroot:

''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio.gz

(Don't forget to replace ''<workdir>'' with the appropriate full path
and ''<cname>'' with your Xtensa processor configuration name.)

Under '''Processor type and features''',
make sure the '''Xtensa Processor Configuration''' is correct and matches
the processor configuration name you used to build the toolchain with buildroot
(for example, ''dc232b'' for Diamond 232L Rev.B).
The kernel build selects a toolchain and processor variant specific headers
based on this selection.
If the desired processor configuration does not appear explicitly in the list,
simply select '''Custom Xtensa processor configuration''' and enter the
processor configuration name (all lowercase) into the next menu parameter,
'''Xtensa Processor Custom Variant Name'''.

Back in the main menu, under '''Platform options''', make sure the
'''CPU clock rate''' entry is set correctly according to the following table:

{| border="1" style="text-align:center; margin: 1em auto 1em auto"
|-
! Board !! Frequency selected in XPG (MHz) !! ''CPU clock rate'' setting (kHz)
|-
|rowspan="3"| XTAV60 (LX60)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV110 (LX110)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV200 (LX200)
| 30 || 31250
|-
| 40 || 41667
|-
| 50 || 50000
|-
|}

Exit menuconfig, saving your configuration changes.

Backup your configuration outside the build directory. For example:

$ cp ../build-xtav60/.config config.xtav60.saved

If you do a clean rebuild of the kernel (e.g., "rm -rf ../build-xtav60")
you can now configure it with simply:
$ mkdir ../build-xtav60 ; cp config.xtav60.saved ../build-xtav60/.config
Of course if you update the kernel, you'll probably again have to do:
$ make O=../build-xtav60 ARCH=xtensa menuconfig
and save a new copy of your configuration.

=== Build the kernel ===

$ make O=../build-xtav60 ARCH=xtensa

The build will issue a few warnings which are normal.
Once complete, the bootable image is in:
<workdir>/build-xtav60/arch/xtensa/boot/Image.elf
and the uncompressed ELF file containing kernel symbols is in:
<workdir>/build-xtav60/vmlinux
There is also a RedBoot bootable image (if you use RedBoot) in:
<workdir>/build-xtav60/arch/xtensa/boot/zImage.redboot

=== Install Xtensa Tools for the selected core ===

If you opt to download the kernel over OCD, you need <tt>xt-gdb</tt>
which is part of Tensilica's Xtensa Tools package. This must be obtained
from Tensilica, and is not the same toolchain as built by buildroot.
You also need to install the corresponding Tensilica core package,
so that the Xtensa Tools know about your particular configured
Tensilica core.

The toolchain built using buildroot can be configured to
include GDB, but that version of GDB does not support
communicating with Tensilica's Xtensa OCD Daemon, and
thus cannot be used to download the kernel over OCD.

In this example, it is assumed that the machine hosting the
Xtensa Tools has access to the <workdir> directory tree.

=== Install and setup the Xtensa OCD Daemon ===

Setup and connect your JTAG probe, etc.

=== Connect a terminal server ===

At 38400 bps 8N1 no flow control to the XTAV60 serial port.

=== Optionally, setup networking ===

This step is optional.

Setup the board's MAC address using dipswitches
(see XTAV60 or XTAV200 board docs as appropriate)
and connect the board to a network that has a
DHCP server that will respond to that MAC address.
If you don't do this step, you'll simply not have network
access, and the boot process will take a minute or so longer
while the kernel times out waiting for a BOOTP response.
You can edit the kernel configuration and rebuild the kernel
to avoid using bootp (in particular, remove "ip=bootp" from
the kernel cmdline).

=== Download and run the kernel ===

Reset the board (see board documentation).

Using Xtensa Tools, invoke:

$ xt-gdb <workdir>/build-xtav60/arch/xtensa/boot/Image.elf

(xt-gdb) target remote <ocdhost>:20000 0
(xt-gdb) reset
(xt-gdb) load
(xt-gdb) set $pc = &_ResetVector
(xt-gdb) symbol-file <workdir>/build-xtav60/vmlinux
(xt-gdb) c

where <ocdhost> is the IP address or DNS name of the machine
running the Xtensa OCD daemon. The Linux kernel should
start booting as soon as 'c' (continue) is executed.

You should eventually get a login prompt.
Just login as root (no password).

Try various Linux commands. Look at <tt>/bin</tt>,
<tt>/sbin</tt>, <tt>/usr/bin</tt>, etc to see what's available.

Note: no need to setup an NFS or TFTP server. The filesystem
is contained within the kernel image. You may be able to mount
other filesystems over NFS though, if you wish, after booting.

=== Mounting the Root Filesystem Over NFS ===

If you build more than the minimal set of packages using
buildroot, the root filesystem can easily grow too large to
fit comfortably (or at all) inside the kernel. In this case,
rather than follow the instructions exactly as above,
you'll want to mount the root filesystem over NFS.

You may also want to mount the root filesystem over NFS to
make changes to the filesystem persistent across runs and
accessible from your development host.

First you need to install the root filesystem generated
using buildroot, to a machine that can serve it over NFS.
Assuming this machine runs Linux, one way to install it is
as follows:

mkdir ''<exportpath>''
cd ''<exportpath>''
sudo cpio -i -d -m -F ''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio --no-absolute-filenames

You then need to enable the NFS server on your system
(if not already active), and export this filesystem.
How you do this depends on your host Linux distribution.
For example, on some Fedora releases, one might:

* add the export path to <tt>/etc/exports</tt> using a line such as

''<exportpath>'' *(rw,sync,no_root_squash,no_all_squash)

* turn on the NFS server if needed:

sudo /sbin/chkconfig nfs on

* tell the NFS server about the new exported filesystem

sudo /usr/sbin/exportfs -a
sudo /usr/sbin/exportfs -r

Second, follow the instructions in the previous sections,
then configure the kernel again as follows.

Under '''General setup''', make sure the
'''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is disabled (rather than enabled as done in previous sections).

Under '''Platform options''', under the line '''Default bootloader kernel arguments''',
select the boot parameters line and set it to something like this:

console=ttyS0,38400 ip=dhcp root=/dev/nfs rw nfsroot=''<server_ip>'':''<exportpath>''

where ''<server_ip>'' is the IP address of your NFS server, and ''<exportpath>''
is the exported filesystem path.

Save this configuration, rebuild the kernel, and follow the
instructions in previous sections to download and run the kernel.
If everything goes well and is setup correctly, your kernel should
now boot with a root filesystem mounted over NFS.

== Build and Run a Linux Kernel on the Instruction Set Simulator (ISS) ==

You can build and run a Linux kernel in the Xtensa Instruction Set
Simulator (ISS). The following instructions have only been tried
with an ISS from the RB-2008.3 release of Xtensa Tools. Bear in
mind that the XTAV60 port is likely much more stable than the ISS port
of Linux at this point in time.

Note: Depending on your host OS version, you may need to install
Xtensa Tools on a separate machine.

=== Configure and Build the Kernel for ISS ===

Repeat all the same instructions as above for building the kernel for the
XTAV60 board, except that when initially configuring the kernel,
start from a ISS platform template instead. For example for the
DC233C Variant:

'''$ mkdir build-iss'''
'''$ cd linux'''
'''$ make O=../build-iss ARCH=xtensa KBUILD_DEFCONFIG=iss_dc233c_defconfig defconfig'''

The above make example configures the kernel using the default configuration found in
'''arch/xtensa/configs/iss_dc233_defconfig'''. Most important to note is that the
root file system mounted when Linux boots comes via the targets device '''/dev/simdisk0'''
which is defined in the kernel '''.config''' file. For example:

'''CONFIG_SIMDISK0_FILENAME="/export2/DC_C_233L/LINUX_ROOT.ext2"'''

The SIMDISK file name and VARIANT name are typically configured when running '''make menuconfig'''; Ex:

'''$ make O=../build-iss ARCH=xtensa menuconfig'''

and selecting

'''Xtensa Platform options''' ---> '''Host filename for a simulated device'''

and entering the pathname to the .ext2 file there. Ex: '''/export2/DC_C_233L/LINUX_ROOT.ext2'''

You often want to change the VARIANT to the one you desire, Ex: FSF. You do this via
the top level menu:

'''Xtensa Processor type and features ---> Xtensa Processor Custom Core Variant Name'''

With the new SIMDISK approach you copy the EXT2 Filesystem file generated by Buildroot
to a location to be accessed by Xtensa Linux. Ex:

'''$ cp /export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot/binaries/dc233c/rootfs.xtensa_dc233c.ext2 /export2/DC_C_233L/LINUX_ROOT.ext2'''

'''NOTE:''' There is an old '''iss_defconfig''' that tries to use a '''tuntap''' Ethernet
interface that currently isn't supported.
Previously with this old iss_defconfig using the '''tuntap''' Ethernet interface
it was suggested to set up the initramfs filesystem, and do the following.
Under '''Bus Options''', deselect '''PCI support'''.
Under '''Platform Options''', deselect '''Default bootloader kernel arguments'''.
Hopefully we will someday be able to support the use of a network interface with
ISS simulation and then be able to mount NFS root partitions again. So I'm leaving
this note for future exploration of this mechanism; Hope you don't mind the clutter.

Continue configuring and building the kernel as usual.

=== Run the Kernel on ISS ===

Using Xtensa Tools, invoke:

'''$ xt-gdb <workdir>/build-iss/arch/xtensa/boot/Image.elf'''
'''(xt-gdb) target sim --turbo --memlimit=128'''
'''(xt-gdb) symbol-file <workdir>/build-iss/vmlinux'''
'''(xt-gdb) run'''

Wait patiently while Linux boots ... (maybe a minute). The setting of the '''memlimit'''
needs to match the PLATFORM_DEFAULT_MEM_SIZE defined in /arch/xtensa/platforms/iss/include/platform/hardware.h.
Currently this limit us 128 MegaBytes:

#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000 /* 13,4217,728 128M */

and we will be extending this for the DC233L to take advantage of it's V3 MMU.

Login as root (no password).

'''Note:''' Input via ISS is cooked, so everything typed gets echoed.
Also, time as reported by the kernel does not progress
according to true wall-clock time: it currently depends on
a simulated processor clock, which advances at various speeds
according to load.

Instructions for building and booting Linux

2011-01-06T03:58:29Z

Piet: /* Configure and Build the Kernel for ISS */

These instructions explain how to build a toolchain, root filesystem and kernel for Linux running on an Xtensa processor. These instructions apply specifically to the XTAV60 (LX60) board.

Some general notes on these instructions:

* They are a work in progress. If you are using the latest development sources, the build process may change, so you should be sure to get the latest version of this document at [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions]. If you are using one of the development snapshot releases, you should use the version of the build instructions included with that snapshot.

* The following was tested on x86 machines running RedHat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3). It is expected to work on newer Fedora releases (e.g., was tested on FC6) but to maintain host compatibility with Xtensa Tools, it is best to avoid Fedora releases beyond FC5. Other host distributions likely work but have not been tested.
** '''NOTE:''' this assumes the default selection of packages in buildroot. Selecting extra packages may require a more recent host OS or more recent version of certain tools. For example, the default version of <tt>find</tt> on RHEL4 is too old to allow building all X11 packages in buildroot, so it is necessary to upgrade the host version of <tt>findutils</tt> on RHEL4 to build these packages.

* Lines prefixed with "sudo" need to be executed as root. The rest is best executed as a non-root user. (It is possible to install <tt>git</tt> as a non-root user if root access is an issue. How to do this isn't shown here.)

* Lines that set environment variables assume a Bourne compatible shell (e.g., /bin/sh or bash), but are easily adapted to other shells.

* Instructions are assumed executed all in order (e.g., commands assume current directory and environment variables set earlier).

== Setup your host system ==

If you are using one of the snapshot releases, you can skip this step.

If you want to work with the latest development sources, you will need
[[Installing GIT|<tt>git</tt> installed on your system]].

== Download buildroot and the Linux kernel ==

The following section describes how to download the latest
versions of buildroot and of the Linux kernel.
Skip this step if you are using one of the
[http://wiki.linux-xtensa.org/index.php/Buildroot_Snapshots snapshot releases].

For most users, just execute the following:

'''$ cd <workdir>'''
'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa.git buildroot'''
'''$ git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git linux'''

where <tt><workdir></tt> is the path to an empty directory on a disk with
at least 4 GB available space. You end up with the following file structure,
which is assumed by the rest of this document:

<workdir>/
/buildroot
/linux

The MASTER branch of the buildroot repository is often is a state of development.
It's recommended to use the last snapshot for application developers. In the
case of the HiFi-2 development board a 'snapshot_2+SMP' branch is recommended
in the currently experimental SMP git repository:

'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

If you happen to have write access to either repository, or want more details,
see the [http://wiki.linux-xtensa.org/index.php/Repository_Access repository access] page.

== Install any required processor specific overlay ==

This step is required if you are targeting a custom Xtensa processor.
If you use a Diamond 232L Standard Core, you can skip this step.

To configure buildroot and the kernel to use a custom Xtensa processor
configuration, you need to overlay a set of files customized for your
processor configuration onto toolchain sources (gcc, binutils, gdb, etc)
and the Linux kernel. This process has been automated using a script
located in the buildroot source tree.
For usage information, you can invoke it without arguments:

'''$ cd <workdir>'''
'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install'''

which displays a help message similar to the following:

xt-buildroot-overlay-install version 1.3
Usage: xt-buildroot-overlay-install <parameters> [<options>]
Where <parameters> are:
-t file.tgz Specify path to the Xtensa Linux overlay tarball, typically
<xtensa_root>/src/xtensa-config-overlay.tar.gz
-b dir Path to the base of the buildroot source tree, in which
package specific overlay tarballs get installed.
-k dir Path to the base of the Linux kernel source tree, in which
the Linux kernel specific overlay gets installed.
-c config_name Name for the Xtensa processor configuration as it will be
known to the open source community. Must be a lowercase
identifier, starting with a letter, consisting of letters
and numbers and underscores, not ending with underscore
and not containing consecutive underscores. For examples:
dc232b , dc232b_be , mmubasele , fsf , s5000 .
-l long_name Long name for the Xtensa processor configuration, human-
readable with spaces etc allowed (must be quoted).
For example: 'Diamond 232L Standard Core Rev.B (LE)'
Try to keep it within approximately 40 characters.
And <options> are:
-f If package specific overlay tarballs already exist in
the destination source tree, overwrite them without asking.
--help Show this usage message.

Note that the Xtensa Linux overlay tarball MUST be obtained from an Xtensa
core package built using release RB-2008.3 or later.

Here is an example invocation of the overlay installation script:

'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install -t blinkcore-config-overlay.tar.gz''' \
'''-b ./buildroot -k ./linux -c superzip -l "ChipCorp SuperZIP Blink Accelerator Core"'''

The script extracts some relevant information from the overlay tarball,
presents it along with relevant parameters to the user, and prompts
for confirmation before proceeding.

The chosen processor name (-c option) must be unique among known Xtensa processors.
It is also probably wise to avoid names confusingly similar to other (non-Xtensa) processors.
If you expect at some point to contribute support for your custom processor to the
open-source community, this name will likely be long-lived.
(One way to contribute support for a custom processor might be to submit the overlay tarball
or files to the linux-xtensa.org maintainers.)

In the steps below, buildroot and the Linux kernel must be configured
(in their respective <code>''make menuconfig''</code> steps) to select
the <code>''custom''</code> Xtensa processor option.
This presents an extra configuration menu entry where you must provide
the name of the Xtensa processor. Set it to the same name
as was specified in the <code>-c</code> option above.

== Build a toolchain and root filesystem using buildroot ==

'''Note:''' for more details on generic buildroot topics not covered in this simple how-to,
see [http://buildroot.uclibc.org/ buildroot.uclibc.org].

=== Configure buildroot ===

The first time you configure buildroot, start with defaults for your Xtensa processor:

'''$ cd <workdir>/buildroot'''
'''$ ./target/xtensa/setup-config <corename>'''

where ''<corename>'' is the overlay name of your selected Xtensa or Diamond core
(e.g., '''dc232b'''). If you omit ''<corename>'', a help message and a list
of currently installed Tensilica core overlays is displayed.

Optionally, you can then customize your buildroot configuration, such as
selecting additional packages, setting various parameters, and so on.
The following make targets provide a ''curses'' (text-based graphical) interface
for configuring buildroot, the uClibc C library, and busybox, respectively.
('''Note:''' You need the <tt>TERM</tt> environment variable properly set for
these curses based tools to work.)

'''$ make menuconfig'''
'''$ make uclibc-menuconfig'''
'''$ make busybox-menuconfig'''

=== Build buildroot ===

Just type:

'''$ make'''

THIS WILL TAKE A LONG TIME (from about 30 minutes with defaults on a 3 GHz Pentium 4,
to perhaps an hour or many depending on your system and on whether
you enabled extra packages in your buildroot configuration).

Wait patiently for the build to complete. This builds an entire toolchain
as well as some basic packages, and constructs a root filesystem.
It might build many more packages if you selected them earlier with menuconfig.

==== If Something Goes Wrong ====

Perhaps you missed some step above and the build fails. Or you're just switching to a different processor configuration, or making some change with unknown dependencies. Either way, you'll probably need to fix the error and/or make the change, and redo the whole build. The above <tt>make</tt> command usually works fine if you
just added a package using menuconfig, but otherwise does not check many dependencies, so it will usually NOT rebuild things that depend on whatever you have fixed or changed. Here's one way to retry the make from scratch without having to wipe out the <tt>buildroot</tt> directory tree completely and start again from the git cloning.

$ '''rm -rf *build_xtensa* binaries'''
$ '''make'''

It is not necessary to empty the 'dl' subdirectory, which contains tarballs downloaded from the Internet, nor the .config file, which contains the buildroot configuration. Customizations to the uClibc and <tt>busybox</tt> configurations should have ended up getting saved in target/xtensa/uClibc.config and target/xtensa/busybox-config, respectively, so hopefully are preserved by the above sequence.

== Build and Run a Linux Kernel on the XTAV60 or XTAV200 Board ==

References to the ''XTAV60 board'' refer to the combination of
the Avnet [http://www.em.avnet.com/tensilica1 LX60 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX60 (XT-AV60) Board User's Guide''.

Similarly, references to the ''XTAV200 board'' refers the combination of
the Avnet [http://www.em.avnet.com/tensilica2 LX200 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX200 (XT-AV200) Board User's Guide''.

=== Configure the kernel ===

The kernel build is a two-step process: configure the kernel, and build it.
First, before we can do anything with the kernel, set your PATH to
point to the toolchain built using buildroot.

$ export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"

where ''<cname>'' is the name of the Xtensa processor configuration you selected
when building the toolchain (e.g., <code>dc232b</code>).

Now setup a destination for kernel builds.
We usually like to have the build directory separate from
the source directory, so we use 'O=</destination/path>' in
kernel make commands. If you'll be routinely building multiple
configurations of the Linux kernel, it's good to have some
naming conventions for the build directory. For example,
to experiment with multiple target platforms but only one
processor configuration, we include just the platform name here:

$ mkdir build-xtav60

Let's start with the default kernel configuration for the Avnet board
(which works on both XTAV60 (LX60) and XTAV200 (LX200) boards)
as follows:

$ cd linux
$ make O=../build-xtav60 ARCH=xtensa KBUILD_DEFCONFIG=lx60_defconfig defconfig

This configures the kernel using the default configuration found in
arch/xtensa/configs/lx60_defconfig.

NOTE: This kernel configuration has nothing to do with Xtensa
processor configuration. That comes next.

Let's now customize this a little bit to select the correct Xtensa processor
configuration, and to bundle the root filesystem into the kernel:

$ make O=../build-xtav60 ARCH=xtensa menuconfig

Under '''General setup''',
make sure the '''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is enabled. Underneath that, edit '''Initramfs source file(s)''',
and enter the path to the cpio formatted root filesystem
generated by buildroot:

''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio.gz

(Don't forget to replace ''<workdir>'' with the appropriate full path
and ''<cname>'' with your Xtensa processor configuration name.)

Under '''Processor type and features''',
make sure the '''Xtensa Processor Configuration''' is correct and matches
the processor configuration name you used to build the toolchain with buildroot
(for example, ''dc232b'' for Diamond 232L Rev.B).
The kernel build selects a toolchain and processor variant specific headers
based on this selection.
If the desired processor configuration does not appear explicitly in the list,
simply select '''Custom Xtensa processor configuration''' and enter the
processor configuration name (all lowercase) into the next menu parameter,
'''Xtensa Processor Custom Variant Name'''.

Back in the main menu, under '''Platform options''', make sure the
'''CPU clock rate''' entry is set correctly according to the following table:

{| border="1" style="text-align:center; margin: 1em auto 1em auto"
|-
! Board !! Frequency selected in XPG (MHz) !! ''CPU clock rate'' setting (kHz)
|-
|rowspan="3"| XTAV60 (LX60)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV110 (LX110)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV200 (LX200)
| 30 || 31250
|-
| 40 || 41667
|-
| 50 || 50000
|-
|}

Exit menuconfig, saving your configuration changes.

Backup your configuration outside the build directory. For example:

$ cp ../build-xtav60/.config config.xtav60.saved

If you do a clean rebuild of the kernel (e.g., "rm -rf ../build-xtav60")
you can now configure it with simply:
$ mkdir ../build-xtav60 ; cp config.xtav60.saved ../build-xtav60/.config
Of course if you update the kernel, you'll probably again have to do:
$ make O=../build-xtav60 ARCH=xtensa menuconfig
and save a new copy of your configuration.

=== Build the kernel ===

$ make O=../build-xtav60 ARCH=xtensa

The build will issue a few warnings which are normal.
Once complete, the bootable image is in:
<workdir>/build-xtav60/arch/xtensa/boot/Image.elf
and the uncompressed ELF file containing kernel symbols is in:
<workdir>/build-xtav60/vmlinux
There is also a RedBoot bootable image (if you use RedBoot) in:
<workdir>/build-xtav60/arch/xtensa/boot/zImage.redboot

=== Install Xtensa Tools for the selected core ===

If you opt to download the kernel over OCD, you need <tt>xt-gdb</tt>
which is part of Tensilica's Xtensa Tools package. This must be obtained
from Tensilica, and is not the same toolchain as built by buildroot.
You also need to install the corresponding Tensilica core package,
so that the Xtensa Tools know about your particular configured
Tensilica core.

The toolchain built using buildroot can be configured to
include GDB, but that version of GDB does not support
communicating with Tensilica's Xtensa OCD Daemon, and
thus cannot be used to download the kernel over OCD.

In this example, it is assumed that the machine hosting the
Xtensa Tools has access to the <workdir> directory tree.

=== Install and setup the Xtensa OCD Daemon ===

Setup and connect your JTAG probe, etc.

=== Connect a terminal server ===

At 38400 bps 8N1 no flow control to the XTAV60 serial port.

=== Optionally, setup networking ===

This step is optional.

Setup the board's MAC address using dipswitches
(see XTAV60 or XTAV200 board docs as appropriate)
and connect the board to a network that has a
DHCP server that will respond to that MAC address.
If you don't do this step, you'll simply not have network
access, and the boot process will take a minute or so longer
while the kernel times out waiting for a BOOTP response.
You can edit the kernel configuration and rebuild the kernel
to avoid using bootp (in particular, remove "ip=bootp" from
the kernel cmdline).

=== Download and run the kernel ===

Reset the board (see board documentation).

Using Xtensa Tools, invoke:

$ xt-gdb <workdir>/build-xtav60/arch/xtensa/boot/Image.elf

(xt-gdb) target remote <ocdhost>:20000 0
(xt-gdb) reset
(xt-gdb) load
(xt-gdb) set $pc = &_ResetVector
(xt-gdb) symbol-file <workdir>/build-xtav60/vmlinux
(xt-gdb) c

where <ocdhost> is the IP address or DNS name of the machine
running the Xtensa OCD daemon. The Linux kernel should
start booting as soon as 'c' (continue) is executed.

You should eventually get a login prompt.
Just login as root (no password).

Try various Linux commands. Look at <tt>/bin</tt>,
<tt>/sbin</tt>, <tt>/usr/bin</tt>, etc to see what's available.

Note: no need to setup an NFS or TFTP server. The filesystem
is contained within the kernel image. You may be able to mount
other filesystems over NFS though, if you wish, after booting.

=== Mounting the Root Filesystem Over NFS ===

If you build more than the minimal set of packages using
buildroot, the root filesystem can easily grow too large to
fit comfortably (or at all) inside the kernel. In this case,
rather than follow the instructions exactly as above,
you'll want to mount the root filesystem over NFS.

You may also want to mount the root filesystem over NFS to
make changes to the filesystem persistent across runs and
accessible from your development host.

First you need to install the root filesystem generated
using buildroot, to a machine that can serve it over NFS.
Assuming this machine runs Linux, one way to install it is
as follows:

mkdir ''<exportpath>''
cd ''<exportpath>''
sudo cpio -i -d -m -F ''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio --no-absolute-filenames

You then need to enable the NFS server on your system
(if not already active), and export this filesystem.
How you do this depends on your host Linux distribution.
For example, on some Fedora releases, one might:

* add the export path to <tt>/etc/exports</tt> using a line such as

''<exportpath>'' *(rw,sync,no_root_squash,no_all_squash)

* turn on the NFS server if needed:

sudo /sbin/chkconfig nfs on

* tell the NFS server about the new exported filesystem

sudo /usr/sbin/exportfs -a
sudo /usr/sbin/exportfs -r

Second, follow the instructions in the previous sections,
then configure the kernel again as follows.

Under '''General setup''', make sure the
'''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is disabled (rather than enabled as done in previous sections).

Under '''Platform options''', under the line '''Default bootloader kernel arguments''',
select the boot parameters line and set it to something like this:

console=ttyS0,38400 ip=dhcp root=/dev/nfs rw nfsroot=''<server_ip>'':''<exportpath>''

where ''<server_ip>'' is the IP address of your NFS server, and ''<exportpath>''
is the exported filesystem path.

Save this configuration, rebuild the kernel, and follow the
instructions in previous sections to download and run the kernel.
If everything goes well and is setup correctly, your kernel should
now boot with a root filesystem mounted over NFS.

== Build and Run a Linux Kernel on the Instruction Set Simulator (ISS) ==

You can build and run a Linux kernel in the Xtensa Instruction Set
Simulator (ISS). The following instructions have only been tried
with an ISS from the RB-2008.3 release of Xtensa Tools. Bear in
mind that the XTAV60 port is likely much more stable than the ISS port
of Linux at this point in time.

Note: Depending on your host OS version, you may need to install
Xtensa Tools on a separate machine.

=== Configure and Build the Kernel for ISS ===

Repeat all the same instructions as above for building the kernel for the
XTAV60 board, except that when initially configuring the kernel,
start from a ISS platform template instead. For example for the
DC233C Variant:

'''$ mkdir build-iss'''
'''$ cd linux'''
'''$ make O=../build-iss ARCH=xtensa KBUILD_DEFCONFIG=iss_dc233c_defconfig defconfig'''

The above make example configures the kernel using the default configuration found in
'''arch/xtensa/configs/iss_dc233_defconfig'''. Most important to note is that the
root file system mounted when Linux boots comes via the targets device '''/dev/simdisk0'''
which is defined in the kernel '''.config''' file. For example:

'''CONFIG_SIMDISK0_FILENAME="/export2/DC_C_233L/LINUX_ROOT.ext2"'''

The SIMDISK file name and VARIANT name are typically configured when running '''make menuconfig''', Ex:

'''$ make O=../build-iss ARCH=xtensa menuconfig'''

and selecting

'''Xtensa Platform options''' ---> '''Host filename for a simulated device'''

and entering the pathname to the .ext2 file there. Ex: '''/export2/DC_C_233L/LINUX_ROOT.ext2'''

You often want to change the VARIANT to the one you desire, Ex: FSF. You do this via
the top level menu:

'''Xtensa Processor type and features ---> Xtensa Processor Custom Core Variant Name'''

With the new SIMDISK approach you copy the EXT2 Filesystem file generated by Buildroot
to a location to be accessed by Xtensa Linux. Ex:

'''$ cp /export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot/binaries/dc233c/rootfs.xtensa_dc233c.ext2 /export2/DC_C_233L/LINUX_ROOT.ext2'''

'''NOTE:''' There is an old '''iss_defconfig''' that tries to use a '''tuntap''' Ethernet
interface that currently isn't supported.
Previously with this old iss_defconfig using the '''tuntap''' Ethernet interface
it was suggested to set up the initramfs filesystem, and do the following.
Under '''Bus Options''', deselect '''PCI support'''.
Under '''Platform Options''', deselect '''Default bootloader kernel arguments'''.
Hopefully we will someday be able to support the use of a network interface with
ISS simulation and then be able to mount NFS root partitions again. So I'm leaving
this note for future exploration of this mechanism. Hope you don't mind the clutter.

Continue configuring and building the kernel as usual.

=== Run the Kernel on ISS ===

Using Xtensa Tools, invoke:

'''$ xt-gdb <workdir>/build-iss/arch/xtensa/boot/Image.elf'''
'''(xt-gdb) target sim --turbo --memlimit=128'''
'''(xt-gdb) symbol-file <workdir>/build-iss/vmlinux'''
'''(xt-gdb) run'''

Wait patiently while Linux boots ... (maybe a minute). The setting of the '''memlimit'''
needs to match the PLATFORM_DEFAULT_MEM_SIZE defined in /arch/xtensa/platforms/iss/include/platform/hardware.h.
Currently this limit us 128 MegaBytes:

#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000 /* 13,4217,728 128M */

and we will be extending this for the DC233L to take advantage of it's V3 MMU.

Login as root (no password).

'''Note:''' Input via ISS is cooked, so everything typed gets echoed.
Also, time as reported by the kernel does not progress
according to true wall-clock time: it currently depends on
a simulated processor clock, which advances at various speeds
according to load.

Instructions for building and booting Linux

2011-01-06T03:50:14Z

Piet: /* Configure and Build the Kernel for ISS */

These instructions explain how to build a toolchain, root filesystem and kernel for Linux running on an Xtensa processor. These instructions apply specifically to the XTAV60 (LX60) board.

Some general notes on these instructions:

* They are a work in progress. If you are using the latest development sources, the build process may change, so you should be sure to get the latest version of this document at [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions]. If you are using one of the development snapshot releases, you should use the version of the build instructions included with that snapshot.

* The following was tested on x86 machines running RedHat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3). It is expected to work on newer Fedora releases (e.g., was tested on FC6) but to maintain host compatibility with Xtensa Tools, it is best to avoid Fedora releases beyond FC5. Other host distributions likely work but have not been tested.
** '''NOTE:''' this assumes the default selection of packages in buildroot. Selecting extra packages may require a more recent host OS or more recent version of certain tools. For example, the default version of <tt>find</tt> on RHEL4 is too old to allow building all X11 packages in buildroot, so it is necessary to upgrade the host version of <tt>findutils</tt> on RHEL4 to build these packages.

* Lines prefixed with "sudo" need to be executed as root. The rest is best executed as a non-root user. (It is possible to install <tt>git</tt> as a non-root user if root access is an issue. How to do this isn't shown here.)

* Lines that set environment variables assume a Bourne compatible shell (e.g., /bin/sh or bash), but are easily adapted to other shells.

* Instructions are assumed executed all in order (e.g., commands assume current directory and environment variables set earlier).

== Setup your host system ==

If you are using one of the snapshot releases, you can skip this step.

If you want to work with the latest development sources, you will need
[[Installing GIT|<tt>git</tt> installed on your system]].

== Download buildroot and the Linux kernel ==

The following section describes how to download the latest
versions of buildroot and of the Linux kernel.
Skip this step if you are using one of the
[http://wiki.linux-xtensa.org/index.php/Buildroot_Snapshots snapshot releases].

For most users, just execute the following:

'''$ cd <workdir>'''
'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa.git buildroot'''
'''$ git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git linux'''

where <tt><workdir></tt> is the path to an empty directory on a disk with
at least 4 GB available space. You end up with the following file structure,
which is assumed by the rest of this document:

<workdir>/
/buildroot
/linux

The MASTER branch of the buildroot repository is often is a state of development.
It's recommended to use the last snapshot for application developers. In the
case of the HiFi-2 development board a 'snapshot_2+SMP' branch is recommended
in the currently experimental SMP git repository:

'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

If you happen to have write access to either repository, or want more details,
see the [http://wiki.linux-xtensa.org/index.php/Repository_Access repository access] page.

== Install any required processor specific overlay ==

This step is required if you are targeting a custom Xtensa processor.
If you use a Diamond 232L Standard Core, you can skip this step.

To configure buildroot and the kernel to use a custom Xtensa processor
configuration, you need to overlay a set of files customized for your
processor configuration onto toolchain sources (gcc, binutils, gdb, etc)
and the Linux kernel. This process has been automated using a script
located in the buildroot source tree.
For usage information, you can invoke it without arguments:

'''$ cd <workdir>'''
'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install'''

which displays a help message similar to the following:

xt-buildroot-overlay-install version 1.3
Usage: xt-buildroot-overlay-install <parameters> [<options>]
Where <parameters> are:
-t file.tgz Specify path to the Xtensa Linux overlay tarball, typically
<xtensa_root>/src/xtensa-config-overlay.tar.gz
-b dir Path to the base of the buildroot source tree, in which
package specific overlay tarballs get installed.
-k dir Path to the base of the Linux kernel source tree, in which
the Linux kernel specific overlay gets installed.
-c config_name Name for the Xtensa processor configuration as it will be
known to the open source community. Must be a lowercase
identifier, starting with a letter, consisting of letters
and numbers and underscores, not ending with underscore
and not containing consecutive underscores. For examples:
dc232b , dc232b_be , mmubasele , fsf , s5000 .
-l long_name Long name for the Xtensa processor configuration, human-
readable with spaces etc allowed (must be quoted).
For example: 'Diamond 232L Standard Core Rev.B (LE)'
Try to keep it within approximately 40 characters.
And <options> are:
-f If package specific overlay tarballs already exist in
the destination source tree, overwrite them without asking.
--help Show this usage message.

Note that the Xtensa Linux overlay tarball MUST be obtained from an Xtensa
core package built using release RB-2008.3 or later.

Here is an example invocation of the overlay installation script:

'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install -t blinkcore-config-overlay.tar.gz''' \
'''-b ./buildroot -k ./linux -c superzip -l "ChipCorp SuperZIP Blink Accelerator Core"'''

The script extracts some relevant information from the overlay tarball,
presents it along with relevant parameters to the user, and prompts
for confirmation before proceeding.

The chosen processor name (-c option) must be unique among known Xtensa processors.
It is also probably wise to avoid names confusingly similar to other (non-Xtensa) processors.
If you expect at some point to contribute support for your custom processor to the
open-source community, this name will likely be long-lived.
(One way to contribute support for a custom processor might be to submit the overlay tarball
or files to the linux-xtensa.org maintainers.)

In the steps below, buildroot and the Linux kernel must be configured
(in their respective <code>''make menuconfig''</code> steps) to select
the <code>''custom''</code> Xtensa processor option.
This presents an extra configuration menu entry where you must provide
the name of the Xtensa processor. Set it to the same name
as was specified in the <code>-c</code> option above.

== Build a toolchain and root filesystem using buildroot ==

'''Note:''' for more details on generic buildroot topics not covered in this simple how-to,
see [http://buildroot.uclibc.org/ buildroot.uclibc.org].

=== Configure buildroot ===

The first time you configure buildroot, start with defaults for your Xtensa processor:

'''$ cd <workdir>/buildroot'''
'''$ ./target/xtensa/setup-config <corename>'''

where ''<corename>'' is the overlay name of your selected Xtensa or Diamond core
(e.g., '''dc232b'''). If you omit ''<corename>'', a help message and a list
of currently installed Tensilica core overlays is displayed.

Optionally, you can then customize your buildroot configuration, such as
selecting additional packages, setting various parameters, and so on.
The following make targets provide a ''curses'' (text-based graphical) interface
for configuring buildroot, the uClibc C library, and busybox, respectively.
('''Note:''' You need the <tt>TERM</tt> environment variable properly set for
these curses based tools to work.)

'''$ make menuconfig'''
'''$ make uclibc-menuconfig'''
'''$ make busybox-menuconfig'''

=== Build buildroot ===

Just type:

'''$ make'''

THIS WILL TAKE A LONG TIME (from about 30 minutes with defaults on a 3 GHz Pentium 4,
to perhaps an hour or many depending on your system and on whether
you enabled extra packages in your buildroot configuration).

Wait patiently for the build to complete. This builds an entire toolchain
as well as some basic packages, and constructs a root filesystem.
It might build many more packages if you selected them earlier with menuconfig.

==== If Something Goes Wrong ====

Perhaps you missed some step above and the build fails. Or you're just switching to a different processor configuration, or making some change with unknown dependencies. Either way, you'll probably need to fix the error and/or make the change, and redo the whole build. The above <tt>make</tt> command usually works fine if you
just added a package using menuconfig, but otherwise does not check many dependencies, so it will usually NOT rebuild things that depend on whatever you have fixed or changed. Here's one way to retry the make from scratch without having to wipe out the <tt>buildroot</tt> directory tree completely and start again from the git cloning.

$ '''rm -rf *build_xtensa* binaries'''
$ '''make'''

It is not necessary to empty the 'dl' subdirectory, which contains tarballs downloaded from the Internet, nor the .config file, which contains the buildroot configuration. Customizations to the uClibc and <tt>busybox</tt> configurations should have ended up getting saved in target/xtensa/uClibc.config and target/xtensa/busybox-config, respectively, so hopefully are preserved by the above sequence.

== Build and Run a Linux Kernel on the XTAV60 or XTAV200 Board ==

References to the ''XTAV60 board'' refer to the combination of
the Avnet [http://www.em.avnet.com/tensilica1 LX60 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX60 (XT-AV60) Board User's Guide''.

Similarly, references to the ''XTAV200 board'' refers the combination of
the Avnet [http://www.em.avnet.com/tensilica2 LX200 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX200 (XT-AV200) Board User's Guide''.

=== Configure the kernel ===

The kernel build is a two-step process: configure the kernel, and build it.
First, before we can do anything with the kernel, set your PATH to
point to the toolchain built using buildroot.

$ export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"

where ''<cname>'' is the name of the Xtensa processor configuration you selected
when building the toolchain (e.g., <code>dc232b</code>).

Now setup a destination for kernel builds.
We usually like to have the build directory separate from
the source directory, so we use 'O=</destination/path>' in
kernel make commands. If you'll be routinely building multiple
configurations of the Linux kernel, it's good to have some
naming conventions for the build directory. For example,
to experiment with multiple target platforms but only one
processor configuration, we include just the platform name here:

$ mkdir build-xtav60

Let's start with the default kernel configuration for the Avnet board
(which works on both XTAV60 (LX60) and XTAV200 (LX200) boards)
as follows:

$ cd linux
$ make O=../build-xtav60 ARCH=xtensa KBUILD_DEFCONFIG=lx60_defconfig defconfig

This configures the kernel using the default configuration found in
arch/xtensa/configs/lx60_defconfig.

NOTE: This kernel configuration has nothing to do with Xtensa
processor configuration. That comes next.

Let's now customize this a little bit to select the correct Xtensa processor
configuration, and to bundle the root filesystem into the kernel:

$ make O=../build-xtav60 ARCH=xtensa menuconfig

Under '''General setup''',
make sure the '''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is enabled. Underneath that, edit '''Initramfs source file(s)''',
and enter the path to the cpio formatted root filesystem
generated by buildroot:

''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio.gz

(Don't forget to replace ''<workdir>'' with the appropriate full path
and ''<cname>'' with your Xtensa processor configuration name.)

Under '''Processor type and features''',
make sure the '''Xtensa Processor Configuration''' is correct and matches
the processor configuration name you used to build the toolchain with buildroot
(for example, ''dc232b'' for Diamond 232L Rev.B).
The kernel build selects a toolchain and processor variant specific headers
based on this selection.
If the desired processor configuration does not appear explicitly in the list,
simply select '''Custom Xtensa processor configuration''' and enter the
processor configuration name (all lowercase) into the next menu parameter,
'''Xtensa Processor Custom Variant Name'''.

Back in the main menu, under '''Platform options''', make sure the
'''CPU clock rate''' entry is set correctly according to the following table:

{| border="1" style="text-align:center; margin: 1em auto 1em auto"
|-
! Board !! Frequency selected in XPG (MHz) !! ''CPU clock rate'' setting (kHz)
|-
|rowspan="3"| XTAV60 (LX60)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV110 (LX110)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV200 (LX200)
| 30 || 31250
|-
| 40 || 41667
|-
| 50 || 50000
|-
|}

Exit menuconfig, saving your configuration changes.

Backup your configuration outside the build directory. For example:

$ cp ../build-xtav60/.config config.xtav60.saved

If you do a clean rebuild of the kernel (e.g., "rm -rf ../build-xtav60")
you can now configure it with simply:
$ mkdir ../build-xtav60 ; cp config.xtav60.saved ../build-xtav60/.config
Of course if you update the kernel, you'll probably again have to do:
$ make O=../build-xtav60 ARCH=xtensa menuconfig
and save a new copy of your configuration.

=== Build the kernel ===

$ make O=../build-xtav60 ARCH=xtensa

The build will issue a few warnings which are normal.
Once complete, the bootable image is in:
<workdir>/build-xtav60/arch/xtensa/boot/Image.elf
and the uncompressed ELF file containing kernel symbols is in:
<workdir>/build-xtav60/vmlinux
There is also a RedBoot bootable image (if you use RedBoot) in:
<workdir>/build-xtav60/arch/xtensa/boot/zImage.redboot

=== Install Xtensa Tools for the selected core ===

If you opt to download the kernel over OCD, you need <tt>xt-gdb</tt>
which is part of Tensilica's Xtensa Tools package. This must be obtained
from Tensilica, and is not the same toolchain as built by buildroot.
You also need to install the corresponding Tensilica core package,
so that the Xtensa Tools know about your particular configured
Tensilica core.

The toolchain built using buildroot can be configured to
include GDB, but that version of GDB does not support
communicating with Tensilica's Xtensa OCD Daemon, and
thus cannot be used to download the kernel over OCD.

In this example, it is assumed that the machine hosting the
Xtensa Tools has access to the <workdir> directory tree.

=== Install and setup the Xtensa OCD Daemon ===

Setup and connect your JTAG probe, etc.

=== Connect a terminal server ===

At 38400 bps 8N1 no flow control to the XTAV60 serial port.

=== Optionally, setup networking ===

This step is optional.

Setup the board's MAC address using dipswitches
(see XTAV60 or XTAV200 board docs as appropriate)
and connect the board to a network that has a
DHCP server that will respond to that MAC address.
If you don't do this step, you'll simply not have network
access, and the boot process will take a minute or so longer
while the kernel times out waiting for a BOOTP response.
You can edit the kernel configuration and rebuild the kernel
to avoid using bootp (in particular, remove "ip=bootp" from
the kernel cmdline).

=== Download and run the kernel ===

Reset the board (see board documentation).

Using Xtensa Tools, invoke:

$ xt-gdb <workdir>/build-xtav60/arch/xtensa/boot/Image.elf

(xt-gdb) target remote <ocdhost>:20000 0
(xt-gdb) reset
(xt-gdb) load
(xt-gdb) set $pc = &_ResetVector
(xt-gdb) symbol-file <workdir>/build-xtav60/vmlinux
(xt-gdb) c

where <ocdhost> is the IP address or DNS name of the machine
running the Xtensa OCD daemon. The Linux kernel should
start booting as soon as 'c' (continue) is executed.

You should eventually get a login prompt.
Just login as root (no password).

Try various Linux commands. Look at <tt>/bin</tt>,
<tt>/sbin</tt>, <tt>/usr/bin</tt>, etc to see what's available.

Note: no need to setup an NFS or TFTP server. The filesystem
is contained within the kernel image. You may be able to mount
other filesystems over NFS though, if you wish, after booting.

=== Mounting the Root Filesystem Over NFS ===

If you build more than the minimal set of packages using
buildroot, the root filesystem can easily grow too large to
fit comfortably (or at all) inside the kernel. In this case,
rather than follow the instructions exactly as above,
you'll want to mount the root filesystem over NFS.

You may also want to mount the root filesystem over NFS to
make changes to the filesystem persistent across runs and
accessible from your development host.

First you need to install the root filesystem generated
using buildroot, to a machine that can serve it over NFS.
Assuming this machine runs Linux, one way to install it is
as follows:

mkdir ''<exportpath>''
cd ''<exportpath>''
sudo cpio -i -d -m -F ''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio --no-absolute-filenames

You then need to enable the NFS server on your system
(if not already active), and export this filesystem.
How you do this depends on your host Linux distribution.
For example, on some Fedora releases, one might:

* add the export path to <tt>/etc/exports</tt> using a line such as

''<exportpath>'' *(rw,sync,no_root_squash,no_all_squash)

* turn on the NFS server if needed:

sudo /sbin/chkconfig nfs on

* tell the NFS server about the new exported filesystem

sudo /usr/sbin/exportfs -a
sudo /usr/sbin/exportfs -r

Second, follow the instructions in the previous sections,
then configure the kernel again as follows.

Under '''General setup''', make sure the
'''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is disabled (rather than enabled as done in previous sections).

Under '''Platform options''', under the line '''Default bootloader kernel arguments''',
select the boot parameters line and set it to something like this:

console=ttyS0,38400 ip=dhcp root=/dev/nfs rw nfsroot=''<server_ip>'':''<exportpath>''

where ''<server_ip>'' is the IP address of your NFS server, and ''<exportpath>''
is the exported filesystem path.

Save this configuration, rebuild the kernel, and follow the
instructions in previous sections to download and run the kernel.
If everything goes well and is setup correctly, your kernel should
now boot with a root filesystem mounted over NFS.

== Build and Run a Linux Kernel on the Instruction Set Simulator (ISS) ==

You can build and run a Linux kernel in the Xtensa Instruction Set
Simulator (ISS). The following instructions have only been tried
with an ISS from the RB-2008.3 release of Xtensa Tools. Bear in
mind that the XTAV60 port is likely much more stable than the ISS port
of Linux at this point in time.

Note: Depending on your host OS version, you may need to install
Xtensa Tools on a separate machine.

=== Configure and Build the Kernel for ISS ===

Repeat all the same instructions as above for building the kernel for the
XTAV60 board, except that when initially configuring the kernel,
start from a ISS platform template instead. For example for the
DC233C Variant:

'''$ mkdir build-iss'''
'''$ cd linux'''
'''$ make O=../build-iss ARCH=xtensa KBUILD_DEFCONFIG=iss_dc233c_defconfig defconfig'''

The above make example configures the kernel using the default configuration found in
'''arch/xtensa/configs/iss_dc233_defconfig'''. Most important to note is that the
root file system mounted when Linux boots comes via the targets device '''/dev/simdisk0'''
which is defined in the kernel '''.config''' file. For example:

CONFIG_SIMDISK0_FILENAME="/export2/DC_C_233L/LINUX_ROOT.ext2"

The SIMDISK file name and VARIANT name are typically configured when running '''make menuconfig''', Ex:

'''$ make O=../build-iss ARCH=xtensa menuconfig'''

and selecting

'''Xtensa Platform options''' ---> '''Host filename for a simulated device'''

and entering the pathname to the .ext2 file there. Ex: '''/export2/DC_C_233L/LINUX_ROOT.ext2'''

You often want to change the VARIANT to the one you desire, Ex: FSF. You do this via
the top level menu:

'''Xtensa Processor type and features ---> Xtensa Processor Custom Core Variant Name'''

With the new SIMDISK approach you copy the EXT2 Filesystem file generated by Buildroot
to a location to be accessed by Xtensa Linux. Ex:

'''$ cp /export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot/binaries/dc233c/rootfs.xtensa_dc233c.ext2 /export2/DC_C_233L/LINUX_ROOT.ext2'''

'''NOTE:''' There is an old '''iss_defconfig''' that tries to use a '''tuntap''' Ethernet
interface that currently isn't supported.
Previously with this old iss_defconfig using the '''tuntap''' Ethernet interface
it was suggested to set up the initramfs filesystem, and do the following.
Under '''Bus Options''', deselect '''PCI support'''.
Under '''Platform Options''', deselect '''Default bootloader kernel arguments'''.
Hopefully we will someday be able to support the use of a network interface with
ISS simulation and then be able to mount NFS root partitions again. So I'm leaving
this note for future exploration of this mechanism. Hope you don't mind the clutter.

Continue configuring and building the kernel as usual.

=== Run the Kernel on ISS ===

Using Xtensa Tools, invoke:

'''$ xt-gdb <workdir>/build-iss/arch/xtensa/boot/Image.elf'''
'''(xt-gdb) target sim --turbo --memlimit=128'''
'''(xt-gdb) symbol-file <workdir>/build-iss/vmlinux'''
'''(xt-gdb) run'''

Wait patiently while Linux boots ... (maybe a minute). The setting of the '''memlimit'''
needs to match the PLATFORM_DEFAULT_MEM_SIZE defined in /arch/xtensa/platforms/iss/include/platform/hardware.h.
Currently this limit us 128 MegaBytes:

#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000 /* 13,4217,728 128M */

and we will be extending this for the DC233L to take advantage of it's V3 MMU.

Login as root (no password).

'''Note:''' Input via ISS is cooked, so everything typed gets echoed.
Also, time as reported by the kernel does not progress
according to true wall-clock time: it currently depends on
a simulated processor clock, which advances at various speeds
according to load.

Instructions for building and booting Linux

2011-01-06T03:49:12Z

Piet: /* Build buildroot */

These instructions explain how to build a toolchain, root filesystem and kernel for Linux running on an Xtensa processor. These instructions apply specifically to the XTAV60 (LX60) board.

Some general notes on these instructions:

* They are a work in progress. If you are using the latest development sources, the build process may change, so you should be sure to get the latest version of this document at [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions]. If you are using one of the development snapshot releases, you should use the version of the build instructions included with that snapshot.

* The following was tested on x86 machines running RedHat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3). It is expected to work on newer Fedora releases (e.g., was tested on FC6) but to maintain host compatibility with Xtensa Tools, it is best to avoid Fedora releases beyond FC5. Other host distributions likely work but have not been tested.
** '''NOTE:''' this assumes the default selection of packages in buildroot. Selecting extra packages may require a more recent host OS or more recent version of certain tools. For example, the default version of <tt>find</tt> on RHEL4 is too old to allow building all X11 packages in buildroot, so it is necessary to upgrade the host version of <tt>findutils</tt> on RHEL4 to build these packages.

* Lines prefixed with "sudo" need to be executed as root. The rest is best executed as a non-root user. (It is possible to install <tt>git</tt> as a non-root user if root access is an issue. How to do this isn't shown here.)

* Lines that set environment variables assume a Bourne compatible shell (e.g., /bin/sh or bash), but are easily adapted to other shells.

* Instructions are assumed executed all in order (e.g., commands assume current directory and environment variables set earlier).

== Setup your host system ==

If you are using one of the snapshot releases, you can skip this step.

If you want to work with the latest development sources, you will need
[[Installing GIT|<tt>git</tt> installed on your system]].

== Download buildroot and the Linux kernel ==

The following section describes how to download the latest
versions of buildroot and of the Linux kernel.
Skip this step if you are using one of the
[http://wiki.linux-xtensa.org/index.php/Buildroot_Snapshots snapshot releases].

For most users, just execute the following:

'''$ cd <workdir>'''
'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa.git buildroot'''
'''$ git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git linux'''

where <tt><workdir></tt> is the path to an empty directory on a disk with
at least 4 GB available space. You end up with the following file structure,
which is assumed by the rest of this document:

<workdir>/
/buildroot
/linux

The MASTER branch of the buildroot repository is often is a state of development.
It's recommended to use the last snapshot for application developers. In the
case of the HiFi-2 development board a 'snapshot_2+SMP' branch is recommended
in the currently experimental SMP git repository:

'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

If you happen to have write access to either repository, or want more details,
see the [http://wiki.linux-xtensa.org/index.php/Repository_Access repository access] page.

== Install any required processor specific overlay ==

This step is required if you are targeting a custom Xtensa processor.
If you use a Diamond 232L Standard Core, you can skip this step.

To configure buildroot and the kernel to use a custom Xtensa processor
configuration, you need to overlay a set of files customized for your
processor configuration onto toolchain sources (gcc, binutils, gdb, etc)
and the Linux kernel. This process has been automated using a script
located in the buildroot source tree.
For usage information, you can invoke it without arguments:

'''$ cd <workdir>'''
'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install'''

which displays a help message similar to the following:

xt-buildroot-overlay-install version 1.3
Usage: xt-buildroot-overlay-install <parameters> [<options>]
Where <parameters> are:
-t file.tgz Specify path to the Xtensa Linux overlay tarball, typically
<xtensa_root>/src/xtensa-config-overlay.tar.gz
-b dir Path to the base of the buildroot source tree, in which
package specific overlay tarballs get installed.
-k dir Path to the base of the Linux kernel source tree, in which
the Linux kernel specific overlay gets installed.
-c config_name Name for the Xtensa processor configuration as it will be
known to the open source community. Must be a lowercase
identifier, starting with a letter, consisting of letters
and numbers and underscores, not ending with underscore
and not containing consecutive underscores. For examples:
dc232b , dc232b_be , mmubasele , fsf , s5000 .
-l long_name Long name for the Xtensa processor configuration, human-
readable with spaces etc allowed (must be quoted).
For example: 'Diamond 232L Standard Core Rev.B (LE)'
Try to keep it within approximately 40 characters.
And <options> are:
-f If package specific overlay tarballs already exist in
the destination source tree, overwrite them without asking.
--help Show this usage message.

Note that the Xtensa Linux overlay tarball MUST be obtained from an Xtensa
core package built using release RB-2008.3 or later.

Here is an example invocation of the overlay installation script:

'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install -t blinkcore-config-overlay.tar.gz''' \
'''-b ./buildroot -k ./linux -c superzip -l "ChipCorp SuperZIP Blink Accelerator Core"'''

The script extracts some relevant information from the overlay tarball,
presents it along with relevant parameters to the user, and prompts
for confirmation before proceeding.

The chosen processor name (-c option) must be unique among known Xtensa processors.
It is also probably wise to avoid names confusingly similar to other (non-Xtensa) processors.
If you expect at some point to contribute support for your custom processor to the
open-source community, this name will likely be long-lived.
(One way to contribute support for a custom processor might be to submit the overlay tarball
or files to the linux-xtensa.org maintainers.)

In the steps below, buildroot and the Linux kernel must be configured
(in their respective <code>''make menuconfig''</code> steps) to select
the <code>''custom''</code> Xtensa processor option.
This presents an extra configuration menu entry where you must provide
the name of the Xtensa processor. Set it to the same name
as was specified in the <code>-c</code> option above.

== Build a toolchain and root filesystem using buildroot ==

'''Note:''' for more details on generic buildroot topics not covered in this simple how-to,
see [http://buildroot.uclibc.org/ buildroot.uclibc.org].

=== Configure buildroot ===

The first time you configure buildroot, start with defaults for your Xtensa processor:

'''$ cd <workdir>/buildroot'''
'''$ ./target/xtensa/setup-config <corename>'''

where ''<corename>'' is the overlay name of your selected Xtensa or Diamond core
(e.g., '''dc232b'''). If you omit ''<corename>'', a help message and a list
of currently installed Tensilica core overlays is displayed.

Optionally, you can then customize your buildroot configuration, such as
selecting additional packages, setting various parameters, and so on.
The following make targets provide a ''curses'' (text-based graphical) interface
for configuring buildroot, the uClibc C library, and busybox, respectively.
('''Note:''' You need the <tt>TERM</tt> environment variable properly set for
these curses based tools to work.)

'''$ make menuconfig'''
'''$ make uclibc-menuconfig'''
'''$ make busybox-menuconfig'''

=== Build buildroot ===

Just type:

'''$ make'''

THIS WILL TAKE A LONG TIME (from about 30 minutes with defaults on a 3 GHz Pentium 4,
to perhaps an hour or many depending on your system and on whether
you enabled extra packages in your buildroot configuration).

Wait patiently for the build to complete. This builds an entire toolchain
as well as some basic packages, and constructs a root filesystem.
It might build many more packages if you selected them earlier with menuconfig.

==== If Something Goes Wrong ====

Perhaps you missed some step above and the build fails. Or you're just switching to a different processor configuration, or making some change with unknown dependencies. Either way, you'll probably need to fix the error and/or make the change, and redo the whole build. The above <tt>make</tt> command usually works fine if you
just added a package using menuconfig, but otherwise does not check many dependencies, so it will usually NOT rebuild things that depend on whatever you have fixed or changed. Here's one way to retry the make from scratch without having to wipe out the <tt>buildroot</tt> directory tree completely and start again from the git cloning.

$ '''rm -rf *build_xtensa* binaries'''
$ '''make'''

It is not necessary to empty the 'dl' subdirectory, which contains tarballs downloaded from the Internet, nor the .config file, which contains the buildroot configuration. Customizations to the uClibc and <tt>busybox</tt> configurations should have ended up getting saved in target/xtensa/uClibc.config and target/xtensa/busybox-config, respectively, so hopefully are preserved by the above sequence.

== Build and Run a Linux Kernel on the XTAV60 or XTAV200 Board ==

References to the ''XTAV60 board'' refer to the combination of
the Avnet [http://www.em.avnet.com/tensilica1 LX60 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX60 (XT-AV60) Board User's Guide''.

Similarly, references to the ''XTAV200 board'' refers the combination of
the Avnet [http://www.em.avnet.com/tensilica2 LX200 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX200 (XT-AV200) Board User's Guide''.

=== Configure the kernel ===

The kernel build is a two-step process: configure the kernel, and build it.
First, before we can do anything with the kernel, set your PATH to
point to the toolchain built using buildroot.

$ export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"

where ''<cname>'' is the name of the Xtensa processor configuration you selected
when building the toolchain (e.g., <code>dc232b</code>).

Now setup a destination for kernel builds.
We usually like to have the build directory separate from
the source directory, so we use 'O=</destination/path>' in
kernel make commands. If you'll be routinely building multiple
configurations of the Linux kernel, it's good to have some
naming conventions for the build directory. For example,
to experiment with multiple target platforms but only one
processor configuration, we include just the platform name here:

$ mkdir build-xtav60

Let's start with the default kernel configuration for the Avnet board
(which works on both XTAV60 (LX60) and XTAV200 (LX200) boards)
as follows:

$ cd linux
$ make O=../build-xtav60 ARCH=xtensa KBUILD_DEFCONFIG=lx60_defconfig defconfig

This configures the kernel using the default configuration found in
arch/xtensa/configs/lx60_defconfig.

NOTE: This kernel configuration has nothing to do with Xtensa
processor configuration. That comes next.

Let's now customize this a little bit to select the correct Xtensa processor
configuration, and to bundle the root filesystem into the kernel:

$ make O=../build-xtav60 ARCH=xtensa menuconfig

Under '''General setup''',
make sure the '''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is enabled. Underneath that, edit '''Initramfs source file(s)''',
and enter the path to the cpio formatted root filesystem
generated by buildroot:

''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio.gz

(Don't forget to replace ''<workdir>'' with the appropriate full path
and ''<cname>'' with your Xtensa processor configuration name.)

Under '''Processor type and features''',
make sure the '''Xtensa Processor Configuration''' is correct and matches
the processor configuration name you used to build the toolchain with buildroot
(for example, ''dc232b'' for Diamond 232L Rev.B).
The kernel build selects a toolchain and processor variant specific headers
based on this selection.
If the desired processor configuration does not appear explicitly in the list,
simply select '''Custom Xtensa processor configuration''' and enter the
processor configuration name (all lowercase) into the next menu parameter,
'''Xtensa Processor Custom Variant Name'''.

Back in the main menu, under '''Platform options''', make sure the
'''CPU clock rate''' entry is set correctly according to the following table:

{| border="1" style="text-align:center; margin: 1em auto 1em auto"
|-
! Board !! Frequency selected in XPG (MHz) !! ''CPU clock rate'' setting (kHz)
|-
|rowspan="3"| XTAV60 (LX60)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV110 (LX110)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV200 (LX200)
| 30 || 31250
|-
| 40 || 41667
|-
| 50 || 50000
|-
|}

Exit menuconfig, saving your configuration changes.

Backup your configuration outside the build directory. For example:

$ cp ../build-xtav60/.config config.xtav60.saved

If you do a clean rebuild of the kernel (e.g., "rm -rf ../build-xtav60")
you can now configure it with simply:
$ mkdir ../build-xtav60 ; cp config.xtav60.saved ../build-xtav60/.config
Of course if you update the kernel, you'll probably again have to do:
$ make O=../build-xtav60 ARCH=xtensa menuconfig
and save a new copy of your configuration.

=== Build the kernel ===

$ make O=../build-xtav60 ARCH=xtensa

The build will issue a few warnings which are normal.
Once complete, the bootable image is in:
<workdir>/build-xtav60/arch/xtensa/boot/Image.elf
and the uncompressed ELF file containing kernel symbols is in:
<workdir>/build-xtav60/vmlinux
There is also a RedBoot bootable image (if you use RedBoot) in:
<workdir>/build-xtav60/arch/xtensa/boot/zImage.redboot

=== Install Xtensa Tools for the selected core ===

If you opt to download the kernel over OCD, you need <tt>xt-gdb</tt>
which is part of Tensilica's Xtensa Tools package. This must be obtained
from Tensilica, and is not the same toolchain as built by buildroot.
You also need to install the corresponding Tensilica core package,
so that the Xtensa Tools know about your particular configured
Tensilica core.

The toolchain built using buildroot can be configured to
include GDB, but that version of GDB does not support
communicating with Tensilica's Xtensa OCD Daemon, and
thus cannot be used to download the kernel over OCD.

In this example, it is assumed that the machine hosting the
Xtensa Tools has access to the <workdir> directory tree.

=== Install and setup the Xtensa OCD Daemon ===

Setup and connect your JTAG probe, etc.

=== Connect a terminal server ===

At 38400 bps 8N1 no flow control to the XTAV60 serial port.

=== Optionally, setup networking ===

This step is optional.

Setup the board's MAC address using dipswitches
(see XTAV60 or XTAV200 board docs as appropriate)
and connect the board to a network that has a
DHCP server that will respond to that MAC address.
If you don't do this step, you'll simply not have network
access, and the boot process will take a minute or so longer
while the kernel times out waiting for a BOOTP response.
You can edit the kernel configuration and rebuild the kernel
to avoid using bootp (in particular, remove "ip=bootp" from
the kernel cmdline).

=== Download and run the kernel ===

Reset the board (see board documentation).

Using Xtensa Tools, invoke:

$ xt-gdb <workdir>/build-xtav60/arch/xtensa/boot/Image.elf

(xt-gdb) target remote <ocdhost>:20000 0
(xt-gdb) reset
(xt-gdb) load
(xt-gdb) set $pc = &_ResetVector
(xt-gdb) symbol-file <workdir>/build-xtav60/vmlinux
(xt-gdb) c

where <ocdhost> is the IP address or DNS name of the machine
running the Xtensa OCD daemon. The Linux kernel should
start booting as soon as 'c' (continue) is executed.

You should eventually get a login prompt.
Just login as root (no password).

Try various Linux commands. Look at <tt>/bin</tt>,
<tt>/sbin</tt>, <tt>/usr/bin</tt>, etc to see what's available.

Note: no need to setup an NFS or TFTP server. The filesystem
is contained within the kernel image. You may be able to mount
other filesystems over NFS though, if you wish, after booting.

=== Mounting the Root Filesystem Over NFS ===

If you build more than the minimal set of packages using
buildroot, the root filesystem can easily grow too large to
fit comfortably (or at all) inside the kernel. In this case,
rather than follow the instructions exactly as above,
you'll want to mount the root filesystem over NFS.

You may also want to mount the root filesystem over NFS to
make changes to the filesystem persistent across runs and
accessible from your development host.

First you need to install the root filesystem generated
using buildroot, to a machine that can serve it over NFS.
Assuming this machine runs Linux, one way to install it is
as follows:

mkdir ''<exportpath>''
cd ''<exportpath>''
sudo cpio -i -d -m -F ''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio --no-absolute-filenames

You then need to enable the NFS server on your system
(if not already active), and export this filesystem.
How you do this depends on your host Linux distribution.
For example, on some Fedora releases, one might:

* add the export path to <tt>/etc/exports</tt> using a line such as

''<exportpath>'' *(rw,sync,no_root_squash,no_all_squash)

* turn on the NFS server if needed:

sudo /sbin/chkconfig nfs on

* tell the NFS server about the new exported filesystem

sudo /usr/sbin/exportfs -a
sudo /usr/sbin/exportfs -r

Second, follow the instructions in the previous sections,
then configure the kernel again as follows.

Under '''General setup''', make sure the
'''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is disabled (rather than enabled as done in previous sections).

Under '''Platform options''', under the line '''Default bootloader kernel arguments''',
select the boot parameters line and set it to something like this:

console=ttyS0,38400 ip=dhcp root=/dev/nfs rw nfsroot=''<server_ip>'':''<exportpath>''

where ''<server_ip>'' is the IP address of your NFS server, and ''<exportpath>''
is the exported filesystem path.

Save this configuration, rebuild the kernel, and follow the
instructions in previous sections to download and run the kernel.
If everything goes well and is setup correctly, your kernel should
now boot with a root filesystem mounted over NFS.

== Build and Run a Linux Kernel on the Instruction Set Simulator (ISS) ==

You can build and run a Linux kernel in the Xtensa Instruction Set
Simulator (ISS). The following instructions have only been tried
with an ISS from the RB-2008.3 release of Xtensa Tools. Bear in
mind that the XTAV60 port is likely much more stable than the ISS port
of Linux at this point in time.

Note: Depending on your host OS version, you may need to install
Xtensa Tools on a separate machine.

=== Configure and Build the Kernel for ISS ===

Repeat all the same instructions as above for building the kernel for the
XTAV60 board, except that when initially configuring the kernel,
start from a ISS platform template instead. For example for the
DC233C Variant:

'''$ mkdir build-iss'''
'''$ cd linux'''
'''$ make O=../build-iss ARCH=xtensa KBUILD_DEFCONFIG=iss_dc233c_defconfig defconfig'''

The above make example configures the kernel using the default configuration found in
'''arch/xtensa/configs/iss_dc233_defconfig'''. Most important to note is that the
root file system mounted when Linux boots comes via the targets device '''/dev/simdisk0'''
which is defined in the kernel '''.config''' file. For example:

CONFIG_SIMDISK0_FILENAME="/export2/DC_C_233L/LINUX_ROOT.ext2"

The SIMDISK file name and VARIANT name are typically configured when running '''make menuconfig''', Ex:

'''$ make O=../build-iss ARCH=xtensa menuconfig'''

and selecting

'''Xtensa Platform options''' ---> '''Host filename for a simulated device'''

and entering the pathname to the .ext2 file there. Ex: '''/export2/DC_C_233L/LINUX_ROOT.ext2'''

You often want to change the VARIANT to the one you desire, Ex: FSF. You do this via
the top level menu:

'''Xtensa Processor type and features --->Xtensa Processor Custom Core Variant Name'''

With the new SIMDISK approach you copy the EXT2 Filesystem file generated by Buildroot
to a location to be accessed by Xtensa Linux. Ex:

'''$ cp /export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot/binaries/dc233c/rootfs.xtensa_dc233c.ext2 /export2/DC_C_233L/LINUX_ROOT.ext2'''

'''NOTE:''' There is an old '''iss_defconfig''' that tries to use a '''tuntap''' Ethernet
interface that currently isn't supported.
Previously with this old iss_defconfig using the '''tuntap''' Ethernet interface
it was suggested to set up the initramfs filesystem, and do the following.
Under '''Bus Options''', deselect '''PCI support'''.
Under '''Platform Options''', deselect '''Default bootloader kernel arguments'''.
Hopefully we will someday be able to support the use of a network interface with
ISS simulation and then be able to mount NFS root partitions again. So I'm leaving
this note for future exploration of this mechanism. Hope you don't mind the clutter.

Continue configuring and building the kernel as usual.

=== Run the Kernel on ISS ===

Using Xtensa Tools, invoke:

'''$ xt-gdb <workdir>/build-iss/arch/xtensa/boot/Image.elf'''
'''(xt-gdb) target sim --turbo --memlimit=128'''
'''(xt-gdb) symbol-file <workdir>/build-iss/vmlinux'''
'''(xt-gdb) run'''

Wait patiently while Linux boots ... (maybe a minute). The setting of the '''memlimit'''
needs to match the PLATFORM_DEFAULT_MEM_SIZE defined in /arch/xtensa/platforms/iss/include/platform/hardware.h.
Currently this limit us 128 MegaBytes:

#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000 /* 13,4217,728 128M */

and we will be extending this for the DC233L to take advantage of it's V3 MMU.

Login as root (no password).

'''Note:''' Input via ISS is cooked, so everything typed gets echoed.
Also, time as reported by the kernel does not progress
according to true wall-clock time: it currently depends on
a simulated processor clock, which advances at various speeds
according to load.

Instructions for building and booting Linux

2011-01-06T03:48:13Z

Piet: /* Configure buildroot */

These instructions explain how to build a toolchain, root filesystem and kernel for Linux running on an Xtensa processor. These instructions apply specifically to the XTAV60 (LX60) board.

Some general notes on these instructions:

* They are a work in progress. If you are using the latest development sources, the build process may change, so you should be sure to get the latest version of this document at [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions]. If you are using one of the development snapshot releases, you should use the version of the build instructions included with that snapshot.

* The following was tested on x86 machines running RedHat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3). It is expected to work on newer Fedora releases (e.g., was tested on FC6) but to maintain host compatibility with Xtensa Tools, it is best to avoid Fedora releases beyond FC5. Other host distributions likely work but have not been tested.
** '''NOTE:''' this assumes the default selection of packages in buildroot. Selecting extra packages may require a more recent host OS or more recent version of certain tools. For example, the default version of <tt>find</tt> on RHEL4 is too old to allow building all X11 packages in buildroot, so it is necessary to upgrade the host version of <tt>findutils</tt> on RHEL4 to build these packages.

* Lines prefixed with "sudo" need to be executed as root. The rest is best executed as a non-root user. (It is possible to install <tt>git</tt> as a non-root user if root access is an issue. How to do this isn't shown here.)

* Lines that set environment variables assume a Bourne compatible shell (e.g., /bin/sh or bash), but are easily adapted to other shells.

* Instructions are assumed executed all in order (e.g., commands assume current directory and environment variables set earlier).

== Setup your host system ==

If you are using one of the snapshot releases, you can skip this step.

If you want to work with the latest development sources, you will need
[[Installing GIT|<tt>git</tt> installed on your system]].

== Download buildroot and the Linux kernel ==

The following section describes how to download the latest
versions of buildroot and of the Linux kernel.
Skip this step if you are using one of the
[http://wiki.linux-xtensa.org/index.php/Buildroot_Snapshots snapshot releases].

For most users, just execute the following:

'''$ cd <workdir>'''
'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa.git buildroot'''
'''$ git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git linux'''

where <tt><workdir></tt> is the path to an empty directory on a disk with
at least 4 GB available space. You end up with the following file structure,
which is assumed by the rest of this document:

<workdir>/
/buildroot
/linux

The MASTER branch of the buildroot repository is often is a state of development.
It's recommended to use the last snapshot for application developers. In the
case of the HiFi-2 development board a 'snapshot_2+SMP' branch is recommended
in the currently experimental SMP git repository:

'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

If you happen to have write access to either repository, or want more details,
see the [http://wiki.linux-xtensa.org/index.php/Repository_Access repository access] page.

== Install any required processor specific overlay ==

This step is required if you are targeting a custom Xtensa processor.
If you use a Diamond 232L Standard Core, you can skip this step.

To configure buildroot and the kernel to use a custom Xtensa processor
configuration, you need to overlay a set of files customized for your
processor configuration onto toolchain sources (gcc, binutils, gdb, etc)
and the Linux kernel. This process has been automated using a script
located in the buildroot source tree.
For usage information, you can invoke it without arguments:

'''$ cd <workdir>'''
'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install'''

which displays a help message similar to the following:

xt-buildroot-overlay-install version 1.3
Usage: xt-buildroot-overlay-install <parameters> [<options>]
Where <parameters> are:
-t file.tgz Specify path to the Xtensa Linux overlay tarball, typically
<xtensa_root>/src/xtensa-config-overlay.tar.gz
-b dir Path to the base of the buildroot source tree, in which
package specific overlay tarballs get installed.
-k dir Path to the base of the Linux kernel source tree, in which
the Linux kernel specific overlay gets installed.
-c config_name Name for the Xtensa processor configuration as it will be
known to the open source community. Must be a lowercase
identifier, starting with a letter, consisting of letters
and numbers and underscores, not ending with underscore
and not containing consecutive underscores. For examples:
dc232b , dc232b_be , mmubasele , fsf , s5000 .
-l long_name Long name for the Xtensa processor configuration, human-
readable with spaces etc allowed (must be quoted).
For example: 'Diamond 232L Standard Core Rev.B (LE)'
Try to keep it within approximately 40 characters.
And <options> are:
-f If package specific overlay tarballs already exist in
the destination source tree, overwrite them without asking.
--help Show this usage message.

Note that the Xtensa Linux overlay tarball MUST be obtained from an Xtensa
core package built using release RB-2008.3 or later.

Here is an example invocation of the overlay installation script:

'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install -t blinkcore-config-overlay.tar.gz''' \
'''-b ./buildroot -k ./linux -c superzip -l "ChipCorp SuperZIP Blink Accelerator Core"'''

The script extracts some relevant information from the overlay tarball,
presents it along with relevant parameters to the user, and prompts
for confirmation before proceeding.

The chosen processor name (-c option) must be unique among known Xtensa processors.
It is also probably wise to avoid names confusingly similar to other (non-Xtensa) processors.
If you expect at some point to contribute support for your custom processor to the
open-source community, this name will likely be long-lived.
(One way to contribute support for a custom processor might be to submit the overlay tarball
or files to the linux-xtensa.org maintainers.)

In the steps below, buildroot and the Linux kernel must be configured
(in their respective <code>''make menuconfig''</code> steps) to select
the <code>''custom''</code> Xtensa processor option.
This presents an extra configuration menu entry where you must provide
the name of the Xtensa processor. Set it to the same name
as was specified in the <code>-c</code> option above.

== Build a toolchain and root filesystem using buildroot ==

'''Note:''' for more details on generic buildroot topics not covered in this simple how-to,
see [http://buildroot.uclibc.org/ buildroot.uclibc.org].

=== Configure buildroot ===

The first time you configure buildroot, start with defaults for your Xtensa processor:

'''$ cd <workdir>/buildroot'''
'''$ ./target/xtensa/setup-config <corename>'''

where ''<corename>'' is the overlay name of your selected Xtensa or Diamond core
(e.g., '''dc232b'''). If you omit ''<corename>'', a help message and a list
of currently installed Tensilica core overlays is displayed.

Optionally, you can then customize your buildroot configuration, such as
selecting additional packages, setting various parameters, and so on.
The following make targets provide a ''curses'' (text-based graphical) interface
for configuring buildroot, the uClibc C library, and busybox, respectively.
('''Note:''' You need the <tt>TERM</tt> environment variable properly set for
these curses based tools to work.)

'''$ make menuconfig'''
'''$ make uclibc-menuconfig'''
'''$ make busybox-menuconfig'''

=== Build buildroot ===

Just type:

$ make

THIS WILL TAKE A LONG TIME (from about 30 minutes with defaults on a 3 GHz Pentium 4,
to perhaps an hour or many depending on your system and on whether
you enabled extra packages in your buildroot configuration).

Wait patiently for the build to complete. This builds an entire toolchain
as well as some basic packages, and constructs a root filesystem.
It might build many more packages if you selected them earlier with menuconfig.

==== If Something Goes Wrong ====

Perhaps you missed some step above and the build fails. Or you're just switching to a different processor configuration, or making some change with unknown dependencies. Either way, you'll probably need to fix the error and/or make the change, and redo the whole build. The above <tt>make</tt> command usually works fine if you
just added a package using menuconfig, but otherwise does not check many dependencies, so it will usually NOT rebuild things that depend on whatever you have fixed or changed. Here's one way to retry the make from scratch without having to wipe out the <tt>buildroot</tt> directory tree completely and start again from the git cloning.

$ rm -rf *build_xtensa* binaries
$ make

It is not necessary to empty the 'dl' subdirectory, which contains tarballs downloaded from the Internet, nor the .config file, which contains the buildroot configuration. Customizations to the uClibc and <tt>busybox</tt> configurations should have ended up getting saved in target/xtensa/uClibc.config and target/xtensa/busybox-config, respectively, so hopefully are preserved by the above sequence.

== Build and Run a Linux Kernel on the XTAV60 or XTAV200 Board ==

References to the ''XTAV60 board'' refer to the combination of
the Avnet [http://www.em.avnet.com/tensilica1 LX60 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX60 (XT-AV60) Board User's Guide''.

Similarly, references to the ''XTAV200 board'' refers the combination of
the Avnet [http://www.em.avnet.com/tensilica2 LX200 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX200 (XT-AV200) Board User's Guide''.

=== Configure the kernel ===

The kernel build is a two-step process: configure the kernel, and build it.
First, before we can do anything with the kernel, set your PATH to
point to the toolchain built using buildroot.

$ export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"

where ''<cname>'' is the name of the Xtensa processor configuration you selected
when building the toolchain (e.g., <code>dc232b</code>).

Now setup a destination for kernel builds.
We usually like to have the build directory separate from
the source directory, so we use 'O=</destination/path>' in
kernel make commands. If you'll be routinely building multiple
configurations of the Linux kernel, it's good to have some
naming conventions for the build directory. For example,
to experiment with multiple target platforms but only one
processor configuration, we include just the platform name here:

$ mkdir build-xtav60

Let's start with the default kernel configuration for the Avnet board
(which works on both XTAV60 (LX60) and XTAV200 (LX200) boards)
as follows:

$ cd linux
$ make O=../build-xtav60 ARCH=xtensa KBUILD_DEFCONFIG=lx60_defconfig defconfig

This configures the kernel using the default configuration found in
arch/xtensa/configs/lx60_defconfig.

NOTE: This kernel configuration has nothing to do with Xtensa
processor configuration. That comes next.

Let's now customize this a little bit to select the correct Xtensa processor
configuration, and to bundle the root filesystem into the kernel:

$ make O=../build-xtav60 ARCH=xtensa menuconfig

Under '''General setup''',
make sure the '''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is enabled. Underneath that, edit '''Initramfs source file(s)''',
and enter the path to the cpio formatted root filesystem
generated by buildroot:

''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio.gz

(Don't forget to replace ''<workdir>'' with the appropriate full path
and ''<cname>'' with your Xtensa processor configuration name.)

Under '''Processor type and features''',
make sure the '''Xtensa Processor Configuration''' is correct and matches
the processor configuration name you used to build the toolchain with buildroot
(for example, ''dc232b'' for Diamond 232L Rev.B).
The kernel build selects a toolchain and processor variant specific headers
based on this selection.
If the desired processor configuration does not appear explicitly in the list,
simply select '''Custom Xtensa processor configuration''' and enter the
processor configuration name (all lowercase) into the next menu parameter,
'''Xtensa Processor Custom Variant Name'''.

Back in the main menu, under '''Platform options''', make sure the
'''CPU clock rate''' entry is set correctly according to the following table:

{| border="1" style="text-align:center; margin: 1em auto 1em auto"
|-
! Board !! Frequency selected in XPG (MHz) !! ''CPU clock rate'' setting (kHz)
|-
|rowspan="3"| XTAV60 (LX60)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV110 (LX110)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV200 (LX200)
| 30 || 31250
|-
| 40 || 41667
|-
| 50 || 50000
|-
|}

Exit menuconfig, saving your configuration changes.

Backup your configuration outside the build directory. For example:

$ cp ../build-xtav60/.config config.xtav60.saved

If you do a clean rebuild of the kernel (e.g., "rm -rf ../build-xtav60")
you can now configure it with simply:
$ mkdir ../build-xtav60 ; cp config.xtav60.saved ../build-xtav60/.config
Of course if you update the kernel, you'll probably again have to do:
$ make O=../build-xtav60 ARCH=xtensa menuconfig
and save a new copy of your configuration.

=== Build the kernel ===

$ make O=../build-xtav60 ARCH=xtensa

The build will issue a few warnings which are normal.
Once complete, the bootable image is in:
<workdir>/build-xtav60/arch/xtensa/boot/Image.elf
and the uncompressed ELF file containing kernel symbols is in:
<workdir>/build-xtav60/vmlinux
There is also a RedBoot bootable image (if you use RedBoot) in:
<workdir>/build-xtav60/arch/xtensa/boot/zImage.redboot

=== Install Xtensa Tools for the selected core ===

If you opt to download the kernel over OCD, you need <tt>xt-gdb</tt>
which is part of Tensilica's Xtensa Tools package. This must be obtained
from Tensilica, and is not the same toolchain as built by buildroot.
You also need to install the corresponding Tensilica core package,
so that the Xtensa Tools know about your particular configured
Tensilica core.

The toolchain built using buildroot can be configured to
include GDB, but that version of GDB does not support
communicating with Tensilica's Xtensa OCD Daemon, and
thus cannot be used to download the kernel over OCD.

In this example, it is assumed that the machine hosting the
Xtensa Tools has access to the <workdir> directory tree.

=== Install and setup the Xtensa OCD Daemon ===

Setup and connect your JTAG probe, etc.

=== Connect a terminal server ===

At 38400 bps 8N1 no flow control to the XTAV60 serial port.

=== Optionally, setup networking ===

This step is optional.

Setup the board's MAC address using dipswitches
(see XTAV60 or XTAV200 board docs as appropriate)
and connect the board to a network that has a
DHCP server that will respond to that MAC address.
If you don't do this step, you'll simply not have network
access, and the boot process will take a minute or so longer
while the kernel times out waiting for a BOOTP response.
You can edit the kernel configuration and rebuild the kernel
to avoid using bootp (in particular, remove "ip=bootp" from
the kernel cmdline).

=== Download and run the kernel ===

Reset the board (see board documentation).

Using Xtensa Tools, invoke:

$ xt-gdb <workdir>/build-xtav60/arch/xtensa/boot/Image.elf

(xt-gdb) target remote <ocdhost>:20000 0
(xt-gdb) reset
(xt-gdb) load
(xt-gdb) set $pc = &_ResetVector
(xt-gdb) symbol-file <workdir>/build-xtav60/vmlinux
(xt-gdb) c

where <ocdhost> is the IP address or DNS name of the machine
running the Xtensa OCD daemon. The Linux kernel should
start booting as soon as 'c' (continue) is executed.

You should eventually get a login prompt.
Just login as root (no password).

Try various Linux commands. Look at <tt>/bin</tt>,
<tt>/sbin</tt>, <tt>/usr/bin</tt>, etc to see what's available.

Note: no need to setup an NFS or TFTP server. The filesystem
is contained within the kernel image. You may be able to mount
other filesystems over NFS though, if you wish, after booting.

=== Mounting the Root Filesystem Over NFS ===

If you build more than the minimal set of packages using
buildroot, the root filesystem can easily grow too large to
fit comfortably (or at all) inside the kernel. In this case,
rather than follow the instructions exactly as above,
you'll want to mount the root filesystem over NFS.

You may also want to mount the root filesystem over NFS to
make changes to the filesystem persistent across runs and
accessible from your development host.

First you need to install the root filesystem generated
using buildroot, to a machine that can serve it over NFS.
Assuming this machine runs Linux, one way to install it is
as follows:

mkdir ''<exportpath>''
cd ''<exportpath>''
sudo cpio -i -d -m -F ''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio --no-absolute-filenames

You then need to enable the NFS server on your system
(if not already active), and export this filesystem.
How you do this depends on your host Linux distribution.
For example, on some Fedora releases, one might:

* add the export path to <tt>/etc/exports</tt> using a line such as

''<exportpath>'' *(rw,sync,no_root_squash,no_all_squash)

* turn on the NFS server if needed:

sudo /sbin/chkconfig nfs on

* tell the NFS server about the new exported filesystem

sudo /usr/sbin/exportfs -a
sudo /usr/sbin/exportfs -r

Second, follow the instructions in the previous sections,
then configure the kernel again as follows.

Under '''General setup''', make sure the
'''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is disabled (rather than enabled as done in previous sections).

Under '''Platform options''', under the line '''Default bootloader kernel arguments''',
select the boot parameters line and set it to something like this:

console=ttyS0,38400 ip=dhcp root=/dev/nfs rw nfsroot=''<server_ip>'':''<exportpath>''

where ''<server_ip>'' is the IP address of your NFS server, and ''<exportpath>''
is the exported filesystem path.

Save this configuration, rebuild the kernel, and follow the
instructions in previous sections to download and run the kernel.
If everything goes well and is setup correctly, your kernel should
now boot with a root filesystem mounted over NFS.

== Build and Run a Linux Kernel on the Instruction Set Simulator (ISS) ==

You can build and run a Linux kernel in the Xtensa Instruction Set
Simulator (ISS). The following instructions have only been tried
with an ISS from the RB-2008.3 release of Xtensa Tools. Bear in
mind that the XTAV60 port is likely much more stable than the ISS port
of Linux at this point in time.

Note: Depending on your host OS version, you may need to install
Xtensa Tools on a separate machine.

=== Configure and Build the Kernel for ISS ===

Repeat all the same instructions as above for building the kernel for the
XTAV60 board, except that when initially configuring the kernel,
start from a ISS platform template instead. For example for the
DC233C Variant:

'''$ mkdir build-iss'''
'''$ cd linux'''
'''$ make O=../build-iss ARCH=xtensa KBUILD_DEFCONFIG=iss_dc233c_defconfig defconfig'''

The above make example configures the kernel using the default configuration found in
'''arch/xtensa/configs/iss_dc233_defconfig'''. Most important to note is that the
root file system mounted when Linux boots comes via the targets device '''/dev/simdisk0'''
which is defined in the kernel '''.config''' file. For example:

CONFIG_SIMDISK0_FILENAME="/export2/DC_C_233L/LINUX_ROOT.ext2"

The SIMDISK file name and VARIANT name are typically configured when running '''make menuconfig''', Ex:

'''$ make O=../build-iss ARCH=xtensa menuconfig'''

and selecting

'''Xtensa Platform options''' ---> '''Host filename for a simulated device'''

and entering the pathname to the .ext2 file there. Ex: '''/export2/DC_C_233L/LINUX_ROOT.ext2'''

You often want to change the VARIANT to the one you desire, Ex: FSF. You do this via
the top level menu:

'''Xtensa Processor type and features --->Xtensa Processor Custom Core Variant Name'''

With the new SIMDISK approach you copy the EXT2 Filesystem file generated by Buildroot
to a location to be accessed by Xtensa Linux. Ex:

'''$ cp /export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot/binaries/dc233c/rootfs.xtensa_dc233c.ext2 /export2/DC_C_233L/LINUX_ROOT.ext2'''

'''NOTE:''' There is an old '''iss_defconfig''' that tries to use a '''tuntap''' Ethernet
interface that currently isn't supported.
Previously with this old iss_defconfig using the '''tuntap''' Ethernet interface
it was suggested to set up the initramfs filesystem, and do the following.
Under '''Bus Options''', deselect '''PCI support'''.
Under '''Platform Options''', deselect '''Default bootloader kernel arguments'''.
Hopefully we will someday be able to support the use of a network interface with
ISS simulation and then be able to mount NFS root partitions again. So I'm leaving
this note for future exploration of this mechanism. Hope you don't mind the clutter.

Continue configuring and building the kernel as usual.

=== Run the Kernel on ISS ===

Using Xtensa Tools, invoke:

'''$ xt-gdb <workdir>/build-iss/arch/xtensa/boot/Image.elf'''
'''(xt-gdb) target sim --turbo --memlimit=128'''
'''(xt-gdb) symbol-file <workdir>/build-iss/vmlinux'''
'''(xt-gdb) run'''

Wait patiently while Linux boots ... (maybe a minute). The setting of the '''memlimit'''
needs to match the PLATFORM_DEFAULT_MEM_SIZE defined in /arch/xtensa/platforms/iss/include/platform/hardware.h.
Currently this limit us 128 MegaBytes:

#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000 /* 13,4217,728 128M */

and we will be extending this for the DC233L to take advantage of it's V3 MMU.

Login as root (no password).

'''Note:''' Input via ISS is cooked, so everything typed gets echoed.
Also, time as reported by the kernel does not progress
according to true wall-clock time: it currently depends on
a simulated processor clock, which advances at various speeds
according to load.

Instructions for building and booting Linux

2011-01-06T03:47:29Z

Piet: /* Install any required processor specific overlay */

These instructions explain how to build a toolchain, root filesystem and kernel for Linux running on an Xtensa processor. These instructions apply specifically to the XTAV60 (LX60) board.

Some general notes on these instructions:

* They are a work in progress. If you are using the latest development sources, the build process may change, so you should be sure to get the latest version of this document at [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions]. If you are using one of the development snapshot releases, you should use the version of the build instructions included with that snapshot.

* The following was tested on x86 machines running RedHat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3). It is expected to work on newer Fedora releases (e.g., was tested on FC6) but to maintain host compatibility with Xtensa Tools, it is best to avoid Fedora releases beyond FC5. Other host distributions likely work but have not been tested.
** '''NOTE:''' this assumes the default selection of packages in buildroot. Selecting extra packages may require a more recent host OS or more recent version of certain tools. For example, the default version of <tt>find</tt> on RHEL4 is too old to allow building all X11 packages in buildroot, so it is necessary to upgrade the host version of <tt>findutils</tt> on RHEL4 to build these packages.

* Lines prefixed with "sudo" need to be executed as root. The rest is best executed as a non-root user. (It is possible to install <tt>git</tt> as a non-root user if root access is an issue. How to do this isn't shown here.)

* Lines that set environment variables assume a Bourne compatible shell (e.g., /bin/sh or bash), but are easily adapted to other shells.

* Instructions are assumed executed all in order (e.g., commands assume current directory and environment variables set earlier).

== Setup your host system ==

If you are using one of the snapshot releases, you can skip this step.

If you want to work with the latest development sources, you will need
[[Installing GIT|<tt>git</tt> installed on your system]].

== Download buildroot and the Linux kernel ==

The following section describes how to download the latest
versions of buildroot and of the Linux kernel.
Skip this step if you are using one of the
[http://wiki.linux-xtensa.org/index.php/Buildroot_Snapshots snapshot releases].

For most users, just execute the following:

'''$ cd <workdir>'''
'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa.git buildroot'''
'''$ git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git linux'''

where <tt><workdir></tt> is the path to an empty directory on a disk with
at least 4 GB available space. You end up with the following file structure,
which is assumed by the rest of this document:

<workdir>/
/buildroot
/linux

The MASTER branch of the buildroot repository is often is a state of development.
It's recommended to use the last snapshot for application developers. In the
case of the HiFi-2 development board a 'snapshot_2+SMP' branch is recommended
in the currently experimental SMP git repository:

'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

If you happen to have write access to either repository, or want more details,
see the [http://wiki.linux-xtensa.org/index.php/Repository_Access repository access] page.

== Install any required processor specific overlay ==

This step is required if you are targeting a custom Xtensa processor.
If you use a Diamond 232L Standard Core, you can skip this step.

To configure buildroot and the kernel to use a custom Xtensa processor
configuration, you need to overlay a set of files customized for your
processor configuration onto toolchain sources (gcc, binutils, gdb, etc)
and the Linux kernel. This process has been automated using a script
located in the buildroot source tree.
For usage information, you can invoke it without arguments:

'''$ cd <workdir>'''
'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install'''

which displays a help message similar to the following:

xt-buildroot-overlay-install version 1.3
Usage: xt-buildroot-overlay-install <parameters> [<options>]
Where <parameters> are:
-t file.tgz Specify path to the Xtensa Linux overlay tarball, typically
<xtensa_root>/src/xtensa-config-overlay.tar.gz
-b dir Path to the base of the buildroot source tree, in which
package specific overlay tarballs get installed.
-k dir Path to the base of the Linux kernel source tree, in which
the Linux kernel specific overlay gets installed.
-c config_name Name for the Xtensa processor configuration as it will be
known to the open source community. Must be a lowercase
identifier, starting with a letter, consisting of letters
and numbers and underscores, not ending with underscore
and not containing consecutive underscores. For examples:
dc232b , dc232b_be , mmubasele , fsf , s5000 .
-l long_name Long name for the Xtensa processor configuration, human-
readable with spaces etc allowed (must be quoted).
For example: 'Diamond 232L Standard Core Rev.B (LE)'
Try to keep it within approximately 40 characters.
And <options> are:
-f If package specific overlay tarballs already exist in
the destination source tree, overwrite them without asking.
--help Show this usage message.

Note that the Xtensa Linux overlay tarball MUST be obtained from an Xtensa
core package built using release RB-2008.3 or later.

Here is an example invocation of the overlay installation script:

'''$ ./buildroot/target/xtensa/xt-buildroot-overlay-install -t blinkcore-config-overlay.tar.gz''' \
'''-b ./buildroot -k ./linux -c superzip -l "ChipCorp SuperZIP Blink Accelerator Core"'''

The script extracts some relevant information from the overlay tarball,
presents it along with relevant parameters to the user, and prompts
for confirmation before proceeding.

The chosen processor name (-c option) must be unique among known Xtensa processors.
It is also probably wise to avoid names confusingly similar to other (non-Xtensa) processors.
If you expect at some point to contribute support for your custom processor to the
open-source community, this name will likely be long-lived.
(One way to contribute support for a custom processor might be to submit the overlay tarball
or files to the linux-xtensa.org maintainers.)

In the steps below, buildroot and the Linux kernel must be configured
(in their respective <code>''make menuconfig''</code> steps) to select
the <code>''custom''</code> Xtensa processor option.
This presents an extra configuration menu entry where you must provide
the name of the Xtensa processor. Set it to the same name
as was specified in the <code>-c</code> option above.

== Build a toolchain and root filesystem using buildroot ==

'''Note:''' for more details on generic buildroot topics not covered in this simple how-to,
see [http://buildroot.uclibc.org/ buildroot.uclibc.org].

=== Configure buildroot ===

The first time you configure buildroot, start with defaults for your Xtensa processor:

$ cd <workdir>/buildroot
$ ./target/xtensa/setup-config <corename>

where ''<corename>'' is the overlay name of your selected Xtensa or Diamond core
(e.g., '''dc232b'''). If you omit ''<corename>'', a help message and a list
of currently installed Tensilica core overlays is displayed.

Optionally, you can then customize your buildroot configuration, such as
selecting additional packages, setting various parameters, and so on.
The following make targets provide a ''curses'' (text-based graphical) interface
for configuring buildroot, the uClibc C library, and busybox, respectively.
('''Note:''' You need the <tt>TERM</tt> environment variable properly set for
these curses based tools to work.)

$ make menuconfig
$ make uclibc-menuconfig
$ make busybox-menuconfig

=== Build buildroot ===

Just type:

$ make

THIS WILL TAKE A LONG TIME (from about 30 minutes with defaults on a 3 GHz Pentium 4,
to perhaps an hour or many depending on your system and on whether
you enabled extra packages in your buildroot configuration).

Wait patiently for the build to complete. This builds an entire toolchain
as well as some basic packages, and constructs a root filesystem.
It might build many more packages if you selected them earlier with menuconfig.

==== If Something Goes Wrong ====

Perhaps you missed some step above and the build fails. Or you're just switching to a different processor configuration, or making some change with unknown dependencies. Either way, you'll probably need to fix the error and/or make the change, and redo the whole build. The above <tt>make</tt> command usually works fine if you
just added a package using menuconfig, but otherwise does not check many dependencies, so it will usually NOT rebuild things that depend on whatever you have fixed or changed. Here's one way to retry the make from scratch without having to wipe out the <tt>buildroot</tt> directory tree completely and start again from the git cloning.

$ rm -rf *build_xtensa* binaries
$ make

It is not necessary to empty the 'dl' subdirectory, which contains tarballs downloaded from the Internet, nor the .config file, which contains the buildroot configuration. Customizations to the uClibc and <tt>busybox</tt> configurations should have ended up getting saved in target/xtensa/uClibc.config and target/xtensa/busybox-config, respectively, so hopefully are preserved by the above sequence.

== Build and Run a Linux Kernel on the XTAV60 or XTAV200 Board ==

References to the ''XTAV60 board'' refer to the combination of
the Avnet [http://www.em.avnet.com/tensilica1 LX60 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX60 (XT-AV60) Board User's Guide''.

Similarly, references to the ''XTAV200 board'' refers the combination of
the Avnet [http://www.em.avnet.com/tensilica2 LX200 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX200 (XT-AV200) Board User's Guide''.

=== Configure the kernel ===

The kernel build is a two-step process: configure the kernel, and build it.
First, before we can do anything with the kernel, set your PATH to
point to the toolchain built using buildroot.

$ export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"

where ''<cname>'' is the name of the Xtensa processor configuration you selected
when building the toolchain (e.g., <code>dc232b</code>).

Now setup a destination for kernel builds.
We usually like to have the build directory separate from
the source directory, so we use 'O=</destination/path>' in
kernel make commands. If you'll be routinely building multiple
configurations of the Linux kernel, it's good to have some
naming conventions for the build directory. For example,
to experiment with multiple target platforms but only one
processor configuration, we include just the platform name here:

$ mkdir build-xtav60

Let's start with the default kernel configuration for the Avnet board
(which works on both XTAV60 (LX60) and XTAV200 (LX200) boards)
as follows:

$ cd linux
$ make O=../build-xtav60 ARCH=xtensa KBUILD_DEFCONFIG=lx60_defconfig defconfig

This configures the kernel using the default configuration found in
arch/xtensa/configs/lx60_defconfig.

NOTE: This kernel configuration has nothing to do with Xtensa
processor configuration. That comes next.

Let's now customize this a little bit to select the correct Xtensa processor
configuration, and to bundle the root filesystem into the kernel:

$ make O=../build-xtav60 ARCH=xtensa menuconfig

Under '''General setup''',
make sure the '''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is enabled. Underneath that, edit '''Initramfs source file(s)''',
and enter the path to the cpio formatted root filesystem
generated by buildroot:

''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio.gz

(Don't forget to replace ''<workdir>'' with the appropriate full path
and ''<cname>'' with your Xtensa processor configuration name.)

Under '''Processor type and features''',
make sure the '''Xtensa Processor Configuration''' is correct and matches
the processor configuration name you used to build the toolchain with buildroot
(for example, ''dc232b'' for Diamond 232L Rev.B).
The kernel build selects a toolchain and processor variant specific headers
based on this selection.
If the desired processor configuration does not appear explicitly in the list,
simply select '''Custom Xtensa processor configuration''' and enter the
processor configuration name (all lowercase) into the next menu parameter,
'''Xtensa Processor Custom Variant Name'''.

Back in the main menu, under '''Platform options''', make sure the
'''CPU clock rate''' entry is set correctly according to the following table:

{| border="1" style="text-align:center; margin: 1em auto 1em auto"
|-
! Board !! Frequency selected in XPG (MHz) !! ''CPU clock rate'' setting (kHz)
|-
|rowspan="3"| XTAV60 (LX60)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV110 (LX110)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV200 (LX200)
| 30 || 31250
|-
| 40 || 41667
|-
| 50 || 50000
|-
|}

Exit menuconfig, saving your configuration changes.

Backup your configuration outside the build directory. For example:

$ cp ../build-xtav60/.config config.xtav60.saved

If you do a clean rebuild of the kernel (e.g., "rm -rf ../build-xtav60")
you can now configure it with simply:
$ mkdir ../build-xtav60 ; cp config.xtav60.saved ../build-xtav60/.config
Of course if you update the kernel, you'll probably again have to do:
$ make O=../build-xtav60 ARCH=xtensa menuconfig
and save a new copy of your configuration.

=== Build the kernel ===

$ make O=../build-xtav60 ARCH=xtensa

The build will issue a few warnings which are normal.
Once complete, the bootable image is in:
<workdir>/build-xtav60/arch/xtensa/boot/Image.elf
and the uncompressed ELF file containing kernel symbols is in:
<workdir>/build-xtav60/vmlinux
There is also a RedBoot bootable image (if you use RedBoot) in:
<workdir>/build-xtav60/arch/xtensa/boot/zImage.redboot

=== Install Xtensa Tools for the selected core ===

If you opt to download the kernel over OCD, you need <tt>xt-gdb</tt>
which is part of Tensilica's Xtensa Tools package. This must be obtained
from Tensilica, and is not the same toolchain as built by buildroot.
You also need to install the corresponding Tensilica core package,
so that the Xtensa Tools know about your particular configured
Tensilica core.

The toolchain built using buildroot can be configured to
include GDB, but that version of GDB does not support
communicating with Tensilica's Xtensa OCD Daemon, and
thus cannot be used to download the kernel over OCD.

In this example, it is assumed that the machine hosting the
Xtensa Tools has access to the <workdir> directory tree.

=== Install and setup the Xtensa OCD Daemon ===

Setup and connect your JTAG probe, etc.

=== Connect a terminal server ===

At 38400 bps 8N1 no flow control to the XTAV60 serial port.

=== Optionally, setup networking ===

This step is optional.

Setup the board's MAC address using dipswitches
(see XTAV60 or XTAV200 board docs as appropriate)
and connect the board to a network that has a
DHCP server that will respond to that MAC address.
If you don't do this step, you'll simply not have network
access, and the boot process will take a minute or so longer
while the kernel times out waiting for a BOOTP response.
You can edit the kernel configuration and rebuild the kernel
to avoid using bootp (in particular, remove "ip=bootp" from
the kernel cmdline).

=== Download and run the kernel ===

Reset the board (see board documentation).

Using Xtensa Tools, invoke:

$ xt-gdb <workdir>/build-xtav60/arch/xtensa/boot/Image.elf

(xt-gdb) target remote <ocdhost>:20000 0
(xt-gdb) reset
(xt-gdb) load
(xt-gdb) set $pc = &_ResetVector
(xt-gdb) symbol-file <workdir>/build-xtav60/vmlinux
(xt-gdb) c

where <ocdhost> is the IP address or DNS name of the machine
running the Xtensa OCD daemon. The Linux kernel should
start booting as soon as 'c' (continue) is executed.

You should eventually get a login prompt.
Just login as root (no password).

Try various Linux commands. Look at <tt>/bin</tt>,
<tt>/sbin</tt>, <tt>/usr/bin</tt>, etc to see what's available.

Note: no need to setup an NFS or TFTP server. The filesystem
is contained within the kernel image. You may be able to mount
other filesystems over NFS though, if you wish, after booting.

=== Mounting the Root Filesystem Over NFS ===

If you build more than the minimal set of packages using
buildroot, the root filesystem can easily grow too large to
fit comfortably (or at all) inside the kernel. In this case,
rather than follow the instructions exactly as above,
you'll want to mount the root filesystem over NFS.

You may also want to mount the root filesystem over NFS to
make changes to the filesystem persistent across runs and
accessible from your development host.

First you need to install the root filesystem generated
using buildroot, to a machine that can serve it over NFS.
Assuming this machine runs Linux, one way to install it is
as follows:

mkdir ''<exportpath>''
cd ''<exportpath>''
sudo cpio -i -d -m -F ''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio --no-absolute-filenames

You then need to enable the NFS server on your system
(if not already active), and export this filesystem.
How you do this depends on your host Linux distribution.
For example, on some Fedora releases, one might:

* add the export path to <tt>/etc/exports</tt> using a line such as

''<exportpath>'' *(rw,sync,no_root_squash,no_all_squash)

* turn on the NFS server if needed:

sudo /sbin/chkconfig nfs on

* tell the NFS server about the new exported filesystem

sudo /usr/sbin/exportfs -a
sudo /usr/sbin/exportfs -r

Second, follow the instructions in the previous sections,
then configure the kernel again as follows.

Under '''General setup''', make sure the
'''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is disabled (rather than enabled as done in previous sections).

Under '''Platform options''', under the line '''Default bootloader kernel arguments''',
select the boot parameters line and set it to something like this:

console=ttyS0,38400 ip=dhcp root=/dev/nfs rw nfsroot=''<server_ip>'':''<exportpath>''

where ''<server_ip>'' is the IP address of your NFS server, and ''<exportpath>''
is the exported filesystem path.

Save this configuration, rebuild the kernel, and follow the
instructions in previous sections to download and run the kernel.
If everything goes well and is setup correctly, your kernel should
now boot with a root filesystem mounted over NFS.

== Build and Run a Linux Kernel on the Instruction Set Simulator (ISS) ==

You can build and run a Linux kernel in the Xtensa Instruction Set
Simulator (ISS). The following instructions have only been tried
with an ISS from the RB-2008.3 release of Xtensa Tools. Bear in
mind that the XTAV60 port is likely much more stable than the ISS port
of Linux at this point in time.

Note: Depending on your host OS version, you may need to install
Xtensa Tools on a separate machine.

=== Configure and Build the Kernel for ISS ===

Repeat all the same instructions as above for building the kernel for the
XTAV60 board, except that when initially configuring the kernel,
start from a ISS platform template instead. For example for the
DC233C Variant:

'''$ mkdir build-iss'''
'''$ cd linux'''
'''$ make O=../build-iss ARCH=xtensa KBUILD_DEFCONFIG=iss_dc233c_defconfig defconfig'''

The above make example configures the kernel using the default configuration found in
'''arch/xtensa/configs/iss_dc233_defconfig'''. Most important to note is that the
root file system mounted when Linux boots comes via the targets device '''/dev/simdisk0'''
which is defined in the kernel '''.config''' file. For example:

CONFIG_SIMDISK0_FILENAME="/export2/DC_C_233L/LINUX_ROOT.ext2"

The SIMDISK file name and VARIANT name are typically configured when running '''make menuconfig''', Ex:

'''$ make O=../build-iss ARCH=xtensa menuconfig'''

and selecting

'''Xtensa Platform options''' ---> '''Host filename for a simulated device'''

and entering the pathname to the .ext2 file there. Ex: '''/export2/DC_C_233L/LINUX_ROOT.ext2'''

You often want to change the VARIANT to the one you desire, Ex: FSF. You do this via
the top level menu:

'''Xtensa Processor type and features --->Xtensa Processor Custom Core Variant Name'''

With the new SIMDISK approach you copy the EXT2 Filesystem file generated by Buildroot
to a location to be accessed by Xtensa Linux. Ex:

'''$ cp /export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot/binaries/dc233c/rootfs.xtensa_dc233c.ext2 /export2/DC_C_233L/LINUX_ROOT.ext2'''

'''NOTE:''' There is an old '''iss_defconfig''' that tries to use a '''tuntap''' Ethernet
interface that currently isn't supported.
Previously with this old iss_defconfig using the '''tuntap''' Ethernet interface
it was suggested to set up the initramfs filesystem, and do the following.
Under '''Bus Options''', deselect '''PCI support'''.
Under '''Platform Options''', deselect '''Default bootloader kernel arguments'''.
Hopefully we will someday be able to support the use of a network interface with
ISS simulation and then be able to mount NFS root partitions again. So I'm leaving
this note for future exploration of this mechanism. Hope you don't mind the clutter.

Continue configuring and building the kernel as usual.

=== Run the Kernel on ISS ===

Using Xtensa Tools, invoke:

'''$ xt-gdb <workdir>/build-iss/arch/xtensa/boot/Image.elf'''
'''(xt-gdb) target sim --turbo --memlimit=128'''
'''(xt-gdb) symbol-file <workdir>/build-iss/vmlinux'''
'''(xt-gdb) run'''

Wait patiently while Linux boots ... (maybe a minute). The setting of the '''memlimit'''
needs to match the PLATFORM_DEFAULT_MEM_SIZE defined in /arch/xtensa/platforms/iss/include/platform/hardware.h.
Currently this limit us 128 MegaBytes:

#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000 /* 13,4217,728 128M */

and we will be extending this for the DC233L to take advantage of it's V3 MMU.

Login as root (no password).

'''Note:''' Input via ISS is cooked, so everything typed gets echoed.
Also, time as reported by the kernel does not progress
according to true wall-clock time: it currently depends on
a simulated processor clock, which advances at various speeds
according to load.

Instructions for building and booting Linux

2011-01-06T03:46:23Z

Piet: /* Download buildroot and the Linux kernel */

These instructions explain how to build a toolchain, root filesystem and kernel for Linux running on an Xtensa processor. These instructions apply specifically to the XTAV60 (LX60) board.

Some general notes on these instructions:

* They are a work in progress. If you are using the latest development sources, the build process may change, so you should be sure to get the latest version of this document at [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions]. If you are using one of the development snapshot releases, you should use the version of the build instructions included with that snapshot.

* The following was tested on x86 machines running RedHat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3). It is expected to work on newer Fedora releases (e.g., was tested on FC6) but to maintain host compatibility with Xtensa Tools, it is best to avoid Fedora releases beyond FC5. Other host distributions likely work but have not been tested.
** '''NOTE:''' this assumes the default selection of packages in buildroot. Selecting extra packages may require a more recent host OS or more recent version of certain tools. For example, the default version of <tt>find</tt> on RHEL4 is too old to allow building all X11 packages in buildroot, so it is necessary to upgrade the host version of <tt>findutils</tt> on RHEL4 to build these packages.

* Lines prefixed with "sudo" need to be executed as root. The rest is best executed as a non-root user. (It is possible to install <tt>git</tt> as a non-root user if root access is an issue. How to do this isn't shown here.)

* Lines that set environment variables assume a Bourne compatible shell (e.g., /bin/sh or bash), but are easily adapted to other shells.

* Instructions are assumed executed all in order (e.g., commands assume current directory and environment variables set earlier).

== Setup your host system ==

If you are using one of the snapshot releases, you can skip this step.

If you want to work with the latest development sources, you will need
[[Installing GIT|<tt>git</tt> installed on your system]].

== Download buildroot and the Linux kernel ==

The following section describes how to download the latest
versions of buildroot and of the Linux kernel.
Skip this step if you are using one of the
[http://wiki.linux-xtensa.org/index.php/Buildroot_Snapshots snapshot releases].

For most users, just execute the following:

'''$ cd <workdir>'''
'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa.git buildroot'''
'''$ git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git linux'''

where <tt><workdir></tt> is the path to an empty directory on a disk with
at least 4 GB available space. You end up with the following file structure,
which is assumed by the rest of this document:

<workdir>/
/buildroot
/linux

The MASTER branch of the buildroot repository is often is a state of development.
It's recommended to use the last snapshot for application developers. In the
case of the HiFi-2 development board a 'snapshot_2+SMP' branch is recommended
in the currently experimental SMP git repository:

'''$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot'''
'''$ git branch --track snapshot_2+SMP'''
'''$ git checkout snapshot_2+SMP'''

If you happen to have write access to either repository, or want more details,
see the [http://wiki.linux-xtensa.org/index.php/Repository_Access repository access] page.

== Install any required processor specific overlay ==

This step is required if you are targeting a custom Xtensa processor.
If you use a Diamond 232L Standard Core, you can skip this step.

To configure buildroot and the kernel to use a custom Xtensa processor
configuration, you need to overlay a set of files customized for your
processor configuration onto toolchain sources (gcc, binutils, gdb, etc)
and the Linux kernel. This process has been automated using a script
located in the buildroot source tree.
For usage information, you can invoke it without arguments:

$ cd <workdir>
$ ./buildroot/target/xtensa/xt-buildroot-overlay-install

which displays a help message similar to the following:

xt-buildroot-overlay-install version 1.3
Usage: xt-buildroot-overlay-install <parameters> [<options>]
Where <parameters> are:
-t file.tgz Specify path to the Xtensa Linux overlay tarball, typically
<xtensa_root>/src/xtensa-config-overlay.tar.gz
-b dir Path to the base of the buildroot source tree, in which
package specific overlay tarballs get installed.
-k dir Path to the base of the Linux kernel source tree, in which
the Linux kernel specific overlay gets installed.
-c config_name Name for the Xtensa processor configuration as it will be
known to the open source community. Must be a lowercase
identifier, starting with a letter, consisting of letters
and numbers and underscores, not ending with underscore
and not containing consecutive underscores. For examples:
dc232b , dc232b_be , mmubasele , fsf , s5000 .
-l long_name Long name for the Xtensa processor configuration, human-
readable with spaces etc allowed (must be quoted).
For example: 'Diamond 232L Standard Core Rev.B (LE)'
Try to keep it within approximately 40 characters.
And <options> are:
-f If package specific overlay tarballs already exist in
the destination source tree, overwrite them without asking.
--help Show this usage message.

Note that the Xtensa Linux overlay tarball MUST be obtained from an Xtensa
core package built using release RB-2008.3 or later.

Here is an example invocation of the overlay installation script:

$ ./buildroot/target/xtensa/xt-buildroot-overlay-install -t blinkcore-config-overlay.tar.gz \
-b ./buildroot -k ./linux -c superzip -l "ChipCorp SuperZIP Blink Accelerator Core"

The script extracts some relevant information from the overlay tarball,
presents it along with relevant parameters to the user, and prompts
for confirmation before proceeding.

The chosen processor name (-c option) must be unique among known Xtensa processors.
It is also probably wise to avoid names confusingly similar to other (non-Xtensa) processors.
If you expect at some point to contribute support for your custom processor to the
open-source community, this name will likely be long-lived.
(One way to contribute support for a custom processor might be to submit the overlay tarball
or files to the linux-xtensa.org maintainers.)

In the steps below, buildroot and the Linux kernel must be configured
(in their respective <code>''make menuconfig''</code> steps) to select
the <code>''custom''</code> Xtensa processor option.
This presents an extra configuration menu entry where you must provide
the name of the Xtensa processor. Set it to the same name
as was specified in the <code>-c</code> option above.

== Build a toolchain and root filesystem using buildroot ==

'''Note:''' for more details on generic buildroot topics not covered in this simple how-to,
see [http://buildroot.uclibc.org/ buildroot.uclibc.org].

=== Configure buildroot ===

The first time you configure buildroot, start with defaults for your Xtensa processor:

$ cd <workdir>/buildroot
$ ./target/xtensa/setup-config <corename>

where ''<corename>'' is the overlay name of your selected Xtensa or Diamond core
(e.g., '''dc232b'''). If you omit ''<corename>'', a help message and a list
of currently installed Tensilica core overlays is displayed.

Optionally, you can then customize your buildroot configuration, such as
selecting additional packages, setting various parameters, and so on.
The following make targets provide a ''curses'' (text-based graphical) interface
for configuring buildroot, the uClibc C library, and busybox, respectively.
('''Note:''' You need the <tt>TERM</tt> environment variable properly set for
these curses based tools to work.)

$ make menuconfig
$ make uclibc-menuconfig
$ make busybox-menuconfig

=== Build buildroot ===

Just type:

$ make

THIS WILL TAKE A LONG TIME (from about 30 minutes with defaults on a 3 GHz Pentium 4,
to perhaps an hour or many depending on your system and on whether
you enabled extra packages in your buildroot configuration).

Wait patiently for the build to complete. This builds an entire toolchain
as well as some basic packages, and constructs a root filesystem.
It might build many more packages if you selected them earlier with menuconfig.

==== If Something Goes Wrong ====

Perhaps you missed some step above and the build fails. Or you're just switching to a different processor configuration, or making some change with unknown dependencies. Either way, you'll probably need to fix the error and/or make the change, and redo the whole build. The above <tt>make</tt> command usually works fine if you
just added a package using menuconfig, but otherwise does not check many dependencies, so it will usually NOT rebuild things that depend on whatever you have fixed or changed. Here's one way to retry the make from scratch without having to wipe out the <tt>buildroot</tt> directory tree completely and start again from the git cloning.

$ rm -rf *build_xtensa* binaries
$ make

It is not necessary to empty the 'dl' subdirectory, which contains tarballs downloaded from the Internet, nor the .config file, which contains the buildroot configuration. Customizations to the uClibc and <tt>busybox</tt> configurations should have ended up getting saved in target/xtensa/uClibc.config and target/xtensa/busybox-config, respectively, so hopefully are preserved by the above sequence.

== Build and Run a Linux Kernel on the XTAV60 or XTAV200 Board ==

References to the ''XTAV60 board'' refer to the combination of
the Avnet [http://www.em.avnet.com/tensilica1 LX60 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX60 (XT-AV60) Board User's Guide''.

Similarly, references to the ''XTAV200 board'' refers the combination of
the Avnet [http://www.em.avnet.com/tensilica2 LX200 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX200 (XT-AV200) Board User's Guide''.

=== Configure the kernel ===

The kernel build is a two-step process: configure the kernel, and build it.
First, before we can do anything with the kernel, set your PATH to
point to the toolchain built using buildroot.

$ export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"

where ''<cname>'' is the name of the Xtensa processor configuration you selected
when building the toolchain (e.g., <code>dc232b</code>).

Now setup a destination for kernel builds.
We usually like to have the build directory separate from
the source directory, so we use 'O=</destination/path>' in
kernel make commands. If you'll be routinely building multiple
configurations of the Linux kernel, it's good to have some
naming conventions for the build directory. For example,
to experiment with multiple target platforms but only one
processor configuration, we include just the platform name here:

$ mkdir build-xtav60

Let's start with the default kernel configuration for the Avnet board
(which works on both XTAV60 (LX60) and XTAV200 (LX200) boards)
as follows:

$ cd linux
$ make O=../build-xtav60 ARCH=xtensa KBUILD_DEFCONFIG=lx60_defconfig defconfig

This configures the kernel using the default configuration found in
arch/xtensa/configs/lx60_defconfig.

NOTE: This kernel configuration has nothing to do with Xtensa
processor configuration. That comes next.

Let's now customize this a little bit to select the correct Xtensa processor
configuration, and to bundle the root filesystem into the kernel:

$ make O=../build-xtav60 ARCH=xtensa menuconfig

Under '''General setup''',
make sure the '''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is enabled. Underneath that, edit '''Initramfs source file(s)''',
and enter the path to the cpio formatted root filesystem
generated by buildroot:

''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio.gz

(Don't forget to replace ''<workdir>'' with the appropriate full path
and ''<cname>'' with your Xtensa processor configuration name.)

Under '''Processor type and features''',
make sure the '''Xtensa Processor Configuration''' is correct and matches
the processor configuration name you used to build the toolchain with buildroot
(for example, ''dc232b'' for Diamond 232L Rev.B).
The kernel build selects a toolchain and processor variant specific headers
based on this selection.
If the desired processor configuration does not appear explicitly in the list,
simply select '''Custom Xtensa processor configuration''' and enter the
processor configuration name (all lowercase) into the next menu parameter,
'''Xtensa Processor Custom Variant Name'''.

Back in the main menu, under '''Platform options''', make sure the
'''CPU clock rate''' entry is set correctly according to the following table:

{| border="1" style="text-align:center; margin: 1em auto 1em auto"
|-
! Board !! Frequency selected in XPG (MHz) !! ''CPU clock rate'' setting (kHz)
|-
|rowspan="3"| XTAV60 (LX60)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV110 (LX110)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV200 (LX200)
| 30 || 31250
|-
| 40 || 41667
|-
| 50 || 50000
|-
|}

Exit menuconfig, saving your configuration changes.

Backup your configuration outside the build directory. For example:

$ cp ../build-xtav60/.config config.xtav60.saved

If you do a clean rebuild of the kernel (e.g., "rm -rf ../build-xtav60")
you can now configure it with simply:
$ mkdir ../build-xtav60 ; cp config.xtav60.saved ../build-xtav60/.config
Of course if you update the kernel, you'll probably again have to do:
$ make O=../build-xtav60 ARCH=xtensa menuconfig
and save a new copy of your configuration.

=== Build the kernel ===

$ make O=../build-xtav60 ARCH=xtensa

The build will issue a few warnings which are normal.
Once complete, the bootable image is in:
<workdir>/build-xtav60/arch/xtensa/boot/Image.elf
and the uncompressed ELF file containing kernel symbols is in:
<workdir>/build-xtav60/vmlinux
There is also a RedBoot bootable image (if you use RedBoot) in:
<workdir>/build-xtav60/arch/xtensa/boot/zImage.redboot

=== Install Xtensa Tools for the selected core ===

If you opt to download the kernel over OCD, you need <tt>xt-gdb</tt>
which is part of Tensilica's Xtensa Tools package. This must be obtained
from Tensilica, and is not the same toolchain as built by buildroot.
You also need to install the corresponding Tensilica core package,
so that the Xtensa Tools know about your particular configured
Tensilica core.

The toolchain built using buildroot can be configured to
include GDB, but that version of GDB does not support
communicating with Tensilica's Xtensa OCD Daemon, and
thus cannot be used to download the kernel over OCD.

In this example, it is assumed that the machine hosting the
Xtensa Tools has access to the <workdir> directory tree.

=== Install and setup the Xtensa OCD Daemon ===

Setup and connect your JTAG probe, etc.

=== Connect a terminal server ===

At 38400 bps 8N1 no flow control to the XTAV60 serial port.

=== Optionally, setup networking ===

This step is optional.

Setup the board's MAC address using dipswitches
(see XTAV60 or XTAV200 board docs as appropriate)
and connect the board to a network that has a
DHCP server that will respond to that MAC address.
If you don't do this step, you'll simply not have network
access, and the boot process will take a minute or so longer
while the kernel times out waiting for a BOOTP response.
You can edit the kernel configuration and rebuild the kernel
to avoid using bootp (in particular, remove "ip=bootp" from
the kernel cmdline).

=== Download and run the kernel ===

Reset the board (see board documentation).

Using Xtensa Tools, invoke:

$ xt-gdb <workdir>/build-xtav60/arch/xtensa/boot/Image.elf

(xt-gdb) target remote <ocdhost>:20000 0
(xt-gdb) reset
(xt-gdb) load
(xt-gdb) set $pc = &_ResetVector
(xt-gdb) symbol-file <workdir>/build-xtav60/vmlinux
(xt-gdb) c

where <ocdhost> is the IP address or DNS name of the machine
running the Xtensa OCD daemon. The Linux kernel should
start booting as soon as 'c' (continue) is executed.

You should eventually get a login prompt.
Just login as root (no password).

Try various Linux commands. Look at <tt>/bin</tt>,
<tt>/sbin</tt>, <tt>/usr/bin</tt>, etc to see what's available.

Note: no need to setup an NFS or TFTP server. The filesystem
is contained within the kernel image. You may be able to mount
other filesystems over NFS though, if you wish, after booting.

=== Mounting the Root Filesystem Over NFS ===

If you build more than the minimal set of packages using
buildroot, the root filesystem can easily grow too large to
fit comfortably (or at all) inside the kernel. In this case,
rather than follow the instructions exactly as above,
you'll want to mount the root filesystem over NFS.

You may also want to mount the root filesystem over NFS to
make changes to the filesystem persistent across runs and
accessible from your development host.

First you need to install the root filesystem generated
using buildroot, to a machine that can serve it over NFS.
Assuming this machine runs Linux, one way to install it is
as follows:

mkdir ''<exportpath>''
cd ''<exportpath>''
sudo cpio -i -d -m -F ''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio --no-absolute-filenames

You then need to enable the NFS server on your system
(if not already active), and export this filesystem.
How you do this depends on your host Linux distribution.
For example, on some Fedora releases, one might:

* add the export path to <tt>/etc/exports</tt> using a line such as

''<exportpath>'' *(rw,sync,no_root_squash,no_all_squash)

* turn on the NFS server if needed:

sudo /sbin/chkconfig nfs on

* tell the NFS server about the new exported filesystem

sudo /usr/sbin/exportfs -a
sudo /usr/sbin/exportfs -r

Second, follow the instructions in the previous sections,
then configure the kernel again as follows.

Under '''General setup''', make sure the
'''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is disabled (rather than enabled as done in previous sections).

Under '''Platform options''', under the line '''Default bootloader kernel arguments''',
select the boot parameters line and set it to something like this:

console=ttyS0,38400 ip=dhcp root=/dev/nfs rw nfsroot=''<server_ip>'':''<exportpath>''

where ''<server_ip>'' is the IP address of your NFS server, and ''<exportpath>''
is the exported filesystem path.

Save this configuration, rebuild the kernel, and follow the
instructions in previous sections to download and run the kernel.
If everything goes well and is setup correctly, your kernel should
now boot with a root filesystem mounted over NFS.

== Build and Run a Linux Kernel on the Instruction Set Simulator (ISS) ==

You can build and run a Linux kernel in the Xtensa Instruction Set
Simulator (ISS). The following instructions have only been tried
with an ISS from the RB-2008.3 release of Xtensa Tools. Bear in
mind that the XTAV60 port is likely much more stable than the ISS port
of Linux at this point in time.

Note: Depending on your host OS version, you may need to install
Xtensa Tools on a separate machine.

=== Configure and Build the Kernel for ISS ===

Repeat all the same instructions as above for building the kernel for the
XTAV60 board, except that when initially configuring the kernel,
start from a ISS platform template instead. For example for the
DC233C Variant:

'''$ mkdir build-iss'''
'''$ cd linux'''
'''$ make O=../build-iss ARCH=xtensa KBUILD_DEFCONFIG=iss_dc233c_defconfig defconfig'''

The above make example configures the kernel using the default configuration found in
'''arch/xtensa/configs/iss_dc233_defconfig'''. Most important to note is that the
root file system mounted when Linux boots comes via the targets device '''/dev/simdisk0'''
which is defined in the kernel '''.config''' file. For example:

CONFIG_SIMDISK0_FILENAME="/export2/DC_C_233L/LINUX_ROOT.ext2"

The SIMDISK file name and VARIANT name are typically configured when running '''make menuconfig''', Ex:

'''$ make O=../build-iss ARCH=xtensa menuconfig'''

and selecting

'''Xtensa Platform options''' ---> '''Host filename for a simulated device'''

and entering the pathname to the .ext2 file there. Ex: '''/export2/DC_C_233L/LINUX_ROOT.ext2'''

You often want to change the VARIANT to the one you desire, Ex: FSF. You do this via
the top level menu:

'''Xtensa Processor type and features --->Xtensa Processor Custom Core Variant Name'''

With the new SIMDISK approach you copy the EXT2 Filesystem file generated by Buildroot
to a location to be accessed by Xtensa Linux. Ex:

'''$ cp /export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot/binaries/dc233c/rootfs.xtensa_dc233c.ext2 /export2/DC_C_233L/LINUX_ROOT.ext2'''

'''NOTE:''' There is an old '''iss_defconfig''' that tries to use a '''tuntap''' Ethernet
interface that currently isn't supported.
Previously with this old iss_defconfig using the '''tuntap''' Ethernet interface
it was suggested to set up the initramfs filesystem, and do the following.
Under '''Bus Options''', deselect '''PCI support'''.
Under '''Platform Options''', deselect '''Default bootloader kernel arguments'''.
Hopefully we will someday be able to support the use of a network interface with
ISS simulation and then be able to mount NFS root partitions again. So I'm leaving
this note for future exploration of this mechanism. Hope you don't mind the clutter.

Continue configuring and building the kernel as usual.

=== Run the Kernel on ISS ===

Using Xtensa Tools, invoke:

'''$ xt-gdb <workdir>/build-iss/arch/xtensa/boot/Image.elf'''
'''(xt-gdb) target sim --turbo --memlimit=128'''
'''(xt-gdb) symbol-file <workdir>/build-iss/vmlinux'''
'''(xt-gdb) run'''

Wait patiently while Linux boots ... (maybe a minute). The setting of the '''memlimit'''
needs to match the PLATFORM_DEFAULT_MEM_SIZE defined in /arch/xtensa/platforms/iss/include/platform/hardware.h.
Currently this limit us 128 MegaBytes:

#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000 /* 13,4217,728 128M */

and we will be extending this for the DC233L to take advantage of it's V3 MMU.

Login as root (no password).

'''Note:''' Input via ISS is cooked, so everything typed gets echoed.
Also, time as reported by the kernel does not progress
according to true wall-clock time: it currently depends on
a simulated processor clock, which advances at various speeds
according to load.

Instructions for building and booting Linux

2011-01-06T03:45:19Z

Piet: /* Run the Kernel on ISS */

These instructions explain how to build a toolchain, root filesystem and kernel for Linux running on an Xtensa processor. These instructions apply specifically to the XTAV60 (LX60) board.

Some general notes on these instructions:

* They are a work in progress. If you are using the latest development sources, the build process may change, so you should be sure to get the latest version of this document at [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions]. If you are using one of the development snapshot releases, you should use the version of the build instructions included with that snapshot.

* The following was tested on x86 machines running RedHat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3). It is expected to work on newer Fedora releases (e.g., was tested on FC6) but to maintain host compatibility with Xtensa Tools, it is best to avoid Fedora releases beyond FC5. Other host distributions likely work but have not been tested.
** '''NOTE:''' this assumes the default selection of packages in buildroot. Selecting extra packages may require a more recent host OS or more recent version of certain tools. For example, the default version of <tt>find</tt> on RHEL4 is too old to allow building all X11 packages in buildroot, so it is necessary to upgrade the host version of <tt>findutils</tt> on RHEL4 to build these packages.

* Lines prefixed with "sudo" need to be executed as root. The rest is best executed as a non-root user. (It is possible to install <tt>git</tt> as a non-root user if root access is an issue. How to do this isn't shown here.)

* Lines that set environment variables assume a Bourne compatible shell (e.g., /bin/sh or bash), but are easily adapted to other shells.

* Instructions are assumed executed all in order (e.g., commands assume current directory and environment variables set earlier).

== Setup your host system ==

If you are using one of the snapshot releases, you can skip this step.

If you want to work with the latest development sources, you will need
[[Installing GIT|<tt>git</tt> installed on your system]].

== Download buildroot and the Linux kernel ==

The following section describes how to download the latest
versions of buildroot and of the Linux kernel.
Skip this step if you are using one of the
[http://wiki.linux-xtensa.org/index.php/Buildroot_Snapshots snapshot releases].

For most users, just execute the following:

$ cd <workdir>
$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa.git buildroot
$ git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git linux

where <tt><workdir></tt> is the path to an empty directory on a disk with
at least 4 GB available space. You end up with the following file structure,
which is assumed by the rest of this document:

<workdir>/
/buildroot
/linux

The MASTER branch of the buildroot repository is often is a state of development.
It's recommended to use the last snapshot for application developers. In the
case of the HiFi-2 development board a 'snapshot_2+SMP' branch is recommended
in the currently experimental SMP git repository:

$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot
$ git branch --track snapshot_2+SMP
$ git checkout snapshot_2+SMP

If you happen to have write access to either repository, or want more details,
see the [http://wiki.linux-xtensa.org/index.php/Repository_Access repository access] page.

== Install any required processor specific overlay ==

This step is required if you are targeting a custom Xtensa processor.
If you use a Diamond 232L Standard Core, you can skip this step.

To configure buildroot and the kernel to use a custom Xtensa processor
configuration, you need to overlay a set of files customized for your
processor configuration onto toolchain sources (gcc, binutils, gdb, etc)
and the Linux kernel. This process has been automated using a script
located in the buildroot source tree.
For usage information, you can invoke it without arguments:

$ cd <workdir>
$ ./buildroot/target/xtensa/xt-buildroot-overlay-install

which displays a help message similar to the following:

xt-buildroot-overlay-install version 1.3
Usage: xt-buildroot-overlay-install <parameters> [<options>]
Where <parameters> are:
-t file.tgz Specify path to the Xtensa Linux overlay tarball, typically
<xtensa_root>/src/xtensa-config-overlay.tar.gz
-b dir Path to the base of the buildroot source tree, in which
package specific overlay tarballs get installed.
-k dir Path to the base of the Linux kernel source tree, in which
the Linux kernel specific overlay gets installed.
-c config_name Name for the Xtensa processor configuration as it will be
known to the open source community. Must be a lowercase
identifier, starting with a letter, consisting of letters
and numbers and underscores, not ending with underscore
and not containing consecutive underscores. For examples:
dc232b , dc232b_be , mmubasele , fsf , s5000 .
-l long_name Long name for the Xtensa processor configuration, human-
readable with spaces etc allowed (must be quoted).
For example: 'Diamond 232L Standard Core Rev.B (LE)'
Try to keep it within approximately 40 characters.
And <options> are:
-f If package specific overlay tarballs already exist in
the destination source tree, overwrite them without asking.
--help Show this usage message.

Note that the Xtensa Linux overlay tarball MUST be obtained from an Xtensa
core package built using release RB-2008.3 or later.

Here is an example invocation of the overlay installation script:

$ ./buildroot/target/xtensa/xt-buildroot-overlay-install -t blinkcore-config-overlay.tar.gz \
-b ./buildroot -k ./linux -c superzip -l "ChipCorp SuperZIP Blink Accelerator Core"

The script extracts some relevant information from the overlay tarball,
presents it along with relevant parameters to the user, and prompts
for confirmation before proceeding.

The chosen processor name (-c option) must be unique among known Xtensa processors.
It is also probably wise to avoid names confusingly similar to other (non-Xtensa) processors.
If you expect at some point to contribute support for your custom processor to the
open-source community, this name will likely be long-lived.
(One way to contribute support for a custom processor might be to submit the overlay tarball
or files to the linux-xtensa.org maintainers.)

In the steps below, buildroot and the Linux kernel must be configured
(in their respective <code>''make menuconfig''</code> steps) to select
the <code>''custom''</code> Xtensa processor option.
This presents an extra configuration menu entry where you must provide
the name of the Xtensa processor. Set it to the same name
as was specified in the <code>-c</code> option above.

== Build a toolchain and root filesystem using buildroot ==

'''Note:''' for more details on generic buildroot topics not covered in this simple how-to,
see [http://buildroot.uclibc.org/ buildroot.uclibc.org].

=== Configure buildroot ===

The first time you configure buildroot, start with defaults for your Xtensa processor:

$ cd <workdir>/buildroot
$ ./target/xtensa/setup-config <corename>

where ''<corename>'' is the overlay name of your selected Xtensa or Diamond core
(e.g., '''dc232b'''). If you omit ''<corename>'', a help message and a list
of currently installed Tensilica core overlays is displayed.

Optionally, you can then customize your buildroot configuration, such as
selecting additional packages, setting various parameters, and so on.
The following make targets provide a ''curses'' (text-based graphical) interface
for configuring buildroot, the uClibc C library, and busybox, respectively.
('''Note:''' You need the <tt>TERM</tt> environment variable properly set for
these curses based tools to work.)

$ make menuconfig
$ make uclibc-menuconfig
$ make busybox-menuconfig

=== Build buildroot ===

Just type:

$ make

THIS WILL TAKE A LONG TIME (from about 30 minutes with defaults on a 3 GHz Pentium 4,
to perhaps an hour or many depending on your system and on whether
you enabled extra packages in your buildroot configuration).

Wait patiently for the build to complete. This builds an entire toolchain
as well as some basic packages, and constructs a root filesystem.
It might build many more packages if you selected them earlier with menuconfig.

==== If Something Goes Wrong ====

Perhaps you missed some step above and the build fails. Or you're just switching to a different processor configuration, or making some change with unknown dependencies. Either way, you'll probably need to fix the error and/or make the change, and redo the whole build. The above <tt>make</tt> command usually works fine if you
just added a package using menuconfig, but otherwise does not check many dependencies, so it will usually NOT rebuild things that depend on whatever you have fixed or changed. Here's one way to retry the make from scratch without having to wipe out the <tt>buildroot</tt> directory tree completely and start again from the git cloning.

$ rm -rf *build_xtensa* binaries
$ make

It is not necessary to empty the 'dl' subdirectory, which contains tarballs downloaded from the Internet, nor the .config file, which contains the buildroot configuration. Customizations to the uClibc and <tt>busybox</tt> configurations should have ended up getting saved in target/xtensa/uClibc.config and target/xtensa/busybox-config, respectively, so hopefully are preserved by the above sequence.

== Build and Run a Linux Kernel on the XTAV60 or XTAV200 Board ==

References to the ''XTAV60 board'' refer to the combination of
the Avnet [http://www.em.avnet.com/tensilica1 LX60 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX60 (XT-AV60) Board User's Guide''.

Similarly, references to the ''XTAV200 board'' refers the combination of
the Avnet [http://www.em.avnet.com/tensilica2 LX200 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX200 (XT-AV200) Board User's Guide''.

=== Configure the kernel ===

The kernel build is a two-step process: configure the kernel, and build it.
First, before we can do anything with the kernel, set your PATH to
point to the toolchain built using buildroot.

$ export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"

where ''<cname>'' is the name of the Xtensa processor configuration you selected
when building the toolchain (e.g., <code>dc232b</code>).

Now setup a destination for kernel builds.
We usually like to have the build directory separate from
the source directory, so we use 'O=</destination/path>' in
kernel make commands. If you'll be routinely building multiple
configurations of the Linux kernel, it's good to have some
naming conventions for the build directory. For example,
to experiment with multiple target platforms but only one
processor configuration, we include just the platform name here:

$ mkdir build-xtav60

Let's start with the default kernel configuration for the Avnet board
(which works on both XTAV60 (LX60) and XTAV200 (LX200) boards)
as follows:

$ cd linux
$ make O=../build-xtav60 ARCH=xtensa KBUILD_DEFCONFIG=lx60_defconfig defconfig

This configures the kernel using the default configuration found in
arch/xtensa/configs/lx60_defconfig.

NOTE: This kernel configuration has nothing to do with Xtensa
processor configuration. That comes next.

Let's now customize this a little bit to select the correct Xtensa processor
configuration, and to bundle the root filesystem into the kernel:

$ make O=../build-xtav60 ARCH=xtensa menuconfig

Under '''General setup''',
make sure the '''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is enabled. Underneath that, edit '''Initramfs source file(s)''',
and enter the path to the cpio formatted root filesystem
generated by buildroot:

''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio.gz

(Don't forget to replace ''<workdir>'' with the appropriate full path
and ''<cname>'' with your Xtensa processor configuration name.)

Under '''Processor type and features''',
make sure the '''Xtensa Processor Configuration''' is correct and matches
the processor configuration name you used to build the toolchain with buildroot
(for example, ''dc232b'' for Diamond 232L Rev.B).
The kernel build selects a toolchain and processor variant specific headers
based on this selection.
If the desired processor configuration does not appear explicitly in the list,
simply select '''Custom Xtensa processor configuration''' and enter the
processor configuration name (all lowercase) into the next menu parameter,
'''Xtensa Processor Custom Variant Name'''.

Back in the main menu, under '''Platform options''', make sure the
'''CPU clock rate''' entry is set correctly according to the following table:

{| border="1" style="text-align:center; margin: 1em auto 1em auto"
|-
! Board !! Frequency selected in XPG (MHz) !! ''CPU clock rate'' setting (kHz)
|-
|rowspan="3"| XTAV60 (LX60)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV110 (LX110)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV200 (LX200)
| 30 || 31250
|-
| 40 || 41667
|-
| 50 || 50000
|-
|}

Exit menuconfig, saving your configuration changes.

Backup your configuration outside the build directory. For example:

$ cp ../build-xtav60/.config config.xtav60.saved

If you do a clean rebuild of the kernel (e.g., "rm -rf ../build-xtav60")
you can now configure it with simply:
$ mkdir ../build-xtav60 ; cp config.xtav60.saved ../build-xtav60/.config
Of course if you update the kernel, you'll probably again have to do:
$ make O=../build-xtav60 ARCH=xtensa menuconfig
and save a new copy of your configuration.

=== Build the kernel ===

$ make O=../build-xtav60 ARCH=xtensa

The build will issue a few warnings which are normal.
Once complete, the bootable image is in:
<workdir>/build-xtav60/arch/xtensa/boot/Image.elf
and the uncompressed ELF file containing kernel symbols is in:
<workdir>/build-xtav60/vmlinux
There is also a RedBoot bootable image (if you use RedBoot) in:
<workdir>/build-xtav60/arch/xtensa/boot/zImage.redboot

=== Install Xtensa Tools for the selected core ===

If you opt to download the kernel over OCD, you need <tt>xt-gdb</tt>
which is part of Tensilica's Xtensa Tools package. This must be obtained
from Tensilica, and is not the same toolchain as built by buildroot.
You also need to install the corresponding Tensilica core package,
so that the Xtensa Tools know about your particular configured
Tensilica core.

The toolchain built using buildroot can be configured to
include GDB, but that version of GDB does not support
communicating with Tensilica's Xtensa OCD Daemon, and
thus cannot be used to download the kernel over OCD.

In this example, it is assumed that the machine hosting the
Xtensa Tools has access to the <workdir> directory tree.

=== Install and setup the Xtensa OCD Daemon ===

Setup and connect your JTAG probe, etc.

=== Connect a terminal server ===

At 38400 bps 8N1 no flow control to the XTAV60 serial port.

=== Optionally, setup networking ===

This step is optional.

Setup the board's MAC address using dipswitches
(see XTAV60 or XTAV200 board docs as appropriate)
and connect the board to a network that has a
DHCP server that will respond to that MAC address.
If you don't do this step, you'll simply not have network
access, and the boot process will take a minute or so longer
while the kernel times out waiting for a BOOTP response.
You can edit the kernel configuration and rebuild the kernel
to avoid using bootp (in particular, remove "ip=bootp" from
the kernel cmdline).

=== Download and run the kernel ===

Reset the board (see board documentation).

Using Xtensa Tools, invoke:

$ xt-gdb <workdir>/build-xtav60/arch/xtensa/boot/Image.elf

(xt-gdb) target remote <ocdhost>:20000 0
(xt-gdb) reset
(xt-gdb) load
(xt-gdb) set $pc = &_ResetVector
(xt-gdb) symbol-file <workdir>/build-xtav60/vmlinux
(xt-gdb) c

where <ocdhost> is the IP address or DNS name of the machine
running the Xtensa OCD daemon. The Linux kernel should
start booting as soon as 'c' (continue) is executed.

You should eventually get a login prompt.
Just login as root (no password).

Try various Linux commands. Look at <tt>/bin</tt>,
<tt>/sbin</tt>, <tt>/usr/bin</tt>, etc to see what's available.

Note: no need to setup an NFS or TFTP server. The filesystem
is contained within the kernel image. You may be able to mount
other filesystems over NFS though, if you wish, after booting.

=== Mounting the Root Filesystem Over NFS ===

If you build more than the minimal set of packages using
buildroot, the root filesystem can easily grow too large to
fit comfortably (or at all) inside the kernel. In this case,
rather than follow the instructions exactly as above,
you'll want to mount the root filesystem over NFS.

You may also want to mount the root filesystem over NFS to
make changes to the filesystem persistent across runs and
accessible from your development host.

First you need to install the root filesystem generated
using buildroot, to a machine that can serve it over NFS.
Assuming this machine runs Linux, one way to install it is
as follows:

mkdir ''<exportpath>''
cd ''<exportpath>''
sudo cpio -i -d -m -F ''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio --no-absolute-filenames

You then need to enable the NFS server on your system
(if not already active), and export this filesystem.
How you do this depends on your host Linux distribution.
For example, on some Fedora releases, one might:

* add the export path to <tt>/etc/exports</tt> using a line such as

''<exportpath>'' *(rw,sync,no_root_squash,no_all_squash)

* turn on the NFS server if needed:

sudo /sbin/chkconfig nfs on

* tell the NFS server about the new exported filesystem

sudo /usr/sbin/exportfs -a
sudo /usr/sbin/exportfs -r

Second, follow the instructions in the previous sections,
then configure the kernel again as follows.

Under '''General setup''', make sure the
'''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is disabled (rather than enabled as done in previous sections).

Under '''Platform options''', under the line '''Default bootloader kernel arguments''',
select the boot parameters line and set it to something like this:

console=ttyS0,38400 ip=dhcp root=/dev/nfs rw nfsroot=''<server_ip>'':''<exportpath>''

where ''<server_ip>'' is the IP address of your NFS server, and ''<exportpath>''
is the exported filesystem path.

Save this configuration, rebuild the kernel, and follow the
instructions in previous sections to download and run the kernel.
If everything goes well and is setup correctly, your kernel should
now boot with a root filesystem mounted over NFS.

== Build and Run a Linux Kernel on the Instruction Set Simulator (ISS) ==

You can build and run a Linux kernel in the Xtensa Instruction Set
Simulator (ISS). The following instructions have only been tried
with an ISS from the RB-2008.3 release of Xtensa Tools. Bear in
mind that the XTAV60 port is likely much more stable than the ISS port
of Linux at this point in time.

Note: Depending on your host OS version, you may need to install
Xtensa Tools on a separate machine.

=== Configure and Build the Kernel for ISS ===

Repeat all the same instructions as above for building the kernel for the
XTAV60 board, except that when initially configuring the kernel,
start from a ISS platform template instead. For example for the
DC233C Variant:

'''$ mkdir build-iss'''
'''$ cd linux'''
'''$ make O=../build-iss ARCH=xtensa KBUILD_DEFCONFIG=iss_dc233c_defconfig defconfig'''

The above make example configures the kernel using the default configuration found in
'''arch/xtensa/configs/iss_dc233_defconfig'''. Most important to note is that the
root file system mounted when Linux boots comes via the targets device '''/dev/simdisk0'''
which is defined in the kernel '''.config''' file. For example:

CONFIG_SIMDISK0_FILENAME="/export2/DC_C_233L/LINUX_ROOT.ext2"

The SIMDISK file name and VARIANT name are typically configured when running '''make menuconfig''', Ex:

'''$ make O=../build-iss ARCH=xtensa menuconfig'''

and selecting

'''Xtensa Platform options''' ---> '''Host filename for a simulated device'''

and entering the pathname to the .ext2 file there. Ex: '''/export2/DC_C_233L/LINUX_ROOT.ext2'''

You often want to change the VARIANT to the one you desire, Ex: FSF. You do this via
the top level menu:

'''Xtensa Processor type and features --->Xtensa Processor Custom Core Variant Name'''

With the new SIMDISK approach you copy the EXT2 Filesystem file generated by Buildroot
to a location to be accessed by Xtensa Linux. Ex:

'''$ cp /export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot/binaries/dc233c/rootfs.xtensa_dc233c.ext2 /export2/DC_C_233L/LINUX_ROOT.ext2'''

'''NOTE:''' There is an old '''iss_defconfig''' that tries to use a '''tuntap''' Ethernet
interface that currently isn't supported.
Previously with this old iss_defconfig using the '''tuntap''' Ethernet interface
it was suggested to set up the initramfs filesystem, and do the following.
Under '''Bus Options''', deselect '''PCI support'''.
Under '''Platform Options''', deselect '''Default bootloader kernel arguments'''.
Hopefully we will someday be able to support the use of a network interface with
ISS simulation and then be able to mount NFS root partitions again. So I'm leaving
this note for future exploration of this mechanism. Hope you don't mind the clutter.

Continue configuring and building the kernel as usual.

=== Run the Kernel on ISS ===

Using Xtensa Tools, invoke:

'''$ xt-gdb <workdir>/build-iss/arch/xtensa/boot/Image.elf'''
'''(xt-gdb) target sim --turbo --memlimit=128'''
'''(xt-gdb) symbol-file <workdir>/build-iss/vmlinux'''
'''(xt-gdb) run'''

Wait patiently while Linux boots ... (maybe a minute). The setting of the '''memlimit'''
needs to match the PLATFORM_DEFAULT_MEM_SIZE defined in /arch/xtensa/platforms/iss/include/platform/hardware.h.
Currently this limit us 128 MegaBytes:

#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000 /* 13,4217,728 128M */

and we will be extending this for the DC233L to take advantage of it's V3 MMU.

Login as root (no password).

'''Note:''' Input via ISS is cooked, so everything typed gets echoed.
Also, time as reported by the kernel does not progress
according to true wall-clock time: it currently depends on
a simulated processor clock, which advances at various speeds
according to load.

Instructions for building and booting Linux

2011-01-06T03:42:22Z

Piet: /* Configure and Build the Kernel for ISS */

These instructions explain how to build a toolchain, root filesystem and kernel for Linux running on an Xtensa processor. These instructions apply specifically to the XTAV60 (LX60) board.

Some general notes on these instructions:

* They are a work in progress. If you are using the latest development sources, the build process may change, so you should be sure to get the latest version of this document at [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions]. If you are using one of the development snapshot releases, you should use the version of the build instructions included with that snapshot.

* The following was tested on x86 machines running RedHat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3). It is expected to work on newer Fedora releases (e.g., was tested on FC6) but to maintain host compatibility with Xtensa Tools, it is best to avoid Fedora releases beyond FC5. Other host distributions likely work but have not been tested.
** '''NOTE:''' this assumes the default selection of packages in buildroot. Selecting extra packages may require a more recent host OS or more recent version of certain tools. For example, the default version of <tt>find</tt> on RHEL4 is too old to allow building all X11 packages in buildroot, so it is necessary to upgrade the host version of <tt>findutils</tt> on RHEL4 to build these packages.

* Lines prefixed with "sudo" need to be executed as root. The rest is best executed as a non-root user. (It is possible to install <tt>git</tt> as a non-root user if root access is an issue. How to do this isn't shown here.)

* Lines that set environment variables assume a Bourne compatible shell (e.g., /bin/sh or bash), but are easily adapted to other shells.

* Instructions are assumed executed all in order (e.g., commands assume current directory and environment variables set earlier).

== Setup your host system ==

If you are using one of the snapshot releases, you can skip this step.

If you want to work with the latest development sources, you will need
[[Installing GIT|<tt>git</tt> installed on your system]].

== Download buildroot and the Linux kernel ==

The following section describes how to download the latest
versions of buildroot and of the Linux kernel.
Skip this step if you are using one of the
[http://wiki.linux-xtensa.org/index.php/Buildroot_Snapshots snapshot releases].

For most users, just execute the following:

$ cd <workdir>
$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa.git buildroot
$ git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git linux

where <tt><workdir></tt> is the path to an empty directory on a disk with
at least 4 GB available space. You end up with the following file structure,
which is assumed by the rest of this document:

<workdir>/
/buildroot
/linux

The MASTER branch of the buildroot repository is often is a state of development.
It's recommended to use the last snapshot for application developers. In the
case of the HiFi-2 development board a 'snapshot_2+SMP' branch is recommended
in the currently experimental SMP git repository:

$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot
$ git branch --track snapshot_2+SMP
$ git checkout snapshot_2+SMP

If you happen to have write access to either repository, or want more details,
see the [http://wiki.linux-xtensa.org/index.php/Repository_Access repository access] page.

== Install any required processor specific overlay ==

This step is required if you are targeting a custom Xtensa processor.
If you use a Diamond 232L Standard Core, you can skip this step.

To configure buildroot and the kernel to use a custom Xtensa processor
configuration, you need to overlay a set of files customized for your
processor configuration onto toolchain sources (gcc, binutils, gdb, etc)
and the Linux kernel. This process has been automated using a script
located in the buildroot source tree.
For usage information, you can invoke it without arguments:

$ cd <workdir>
$ ./buildroot/target/xtensa/xt-buildroot-overlay-install

which displays a help message similar to the following:

xt-buildroot-overlay-install version 1.3
Usage: xt-buildroot-overlay-install <parameters> [<options>]
Where <parameters> are:
-t file.tgz Specify path to the Xtensa Linux overlay tarball, typically
<xtensa_root>/src/xtensa-config-overlay.tar.gz
-b dir Path to the base of the buildroot source tree, in which
package specific overlay tarballs get installed.
-k dir Path to the base of the Linux kernel source tree, in which
the Linux kernel specific overlay gets installed.
-c config_name Name for the Xtensa processor configuration as it will be
known to the open source community. Must be a lowercase
identifier, starting with a letter, consisting of letters
and numbers and underscores, not ending with underscore
and not containing consecutive underscores. For examples:
dc232b , dc232b_be , mmubasele , fsf , s5000 .
-l long_name Long name for the Xtensa processor configuration, human-
readable with spaces etc allowed (must be quoted).
For example: 'Diamond 232L Standard Core Rev.B (LE)'
Try to keep it within approximately 40 characters.
And <options> are:
-f If package specific overlay tarballs already exist in
the destination source tree, overwrite them without asking.
--help Show this usage message.

Note that the Xtensa Linux overlay tarball MUST be obtained from an Xtensa
core package built using release RB-2008.3 or later.

Here is an example invocation of the overlay installation script:

$ ./buildroot/target/xtensa/xt-buildroot-overlay-install -t blinkcore-config-overlay.tar.gz \
-b ./buildroot -k ./linux -c superzip -l "ChipCorp SuperZIP Blink Accelerator Core"

The script extracts some relevant information from the overlay tarball,
presents it along with relevant parameters to the user, and prompts
for confirmation before proceeding.

The chosen processor name (-c option) must be unique among known Xtensa processors.
It is also probably wise to avoid names confusingly similar to other (non-Xtensa) processors.
If you expect at some point to contribute support for your custom processor to the
open-source community, this name will likely be long-lived.
(One way to contribute support for a custom processor might be to submit the overlay tarball
or files to the linux-xtensa.org maintainers.)

In the steps below, buildroot and the Linux kernel must be configured
(in their respective <code>''make menuconfig''</code> steps) to select
the <code>''custom''</code> Xtensa processor option.
This presents an extra configuration menu entry where you must provide
the name of the Xtensa processor. Set it to the same name
as was specified in the <code>-c</code> option above.

== Build a toolchain and root filesystem using buildroot ==

'''Note:''' for more details on generic buildroot topics not covered in this simple how-to,
see [http://buildroot.uclibc.org/ buildroot.uclibc.org].

=== Configure buildroot ===

The first time you configure buildroot, start with defaults for your Xtensa processor:

$ cd <workdir>/buildroot
$ ./target/xtensa/setup-config <corename>

where ''<corename>'' is the overlay name of your selected Xtensa or Diamond core
(e.g., '''dc232b'''). If you omit ''<corename>'', a help message and a list
of currently installed Tensilica core overlays is displayed.

Optionally, you can then customize your buildroot configuration, such as
selecting additional packages, setting various parameters, and so on.
The following make targets provide a ''curses'' (text-based graphical) interface
for configuring buildroot, the uClibc C library, and busybox, respectively.
('''Note:''' You need the <tt>TERM</tt> environment variable properly set for
these curses based tools to work.)

$ make menuconfig
$ make uclibc-menuconfig
$ make busybox-menuconfig

=== Build buildroot ===

Just type:

$ make

THIS WILL TAKE A LONG TIME (from about 30 minutes with defaults on a 3 GHz Pentium 4,
to perhaps an hour or many depending on your system and on whether
you enabled extra packages in your buildroot configuration).

Wait patiently for the build to complete. This builds an entire toolchain
as well as some basic packages, and constructs a root filesystem.
It might build many more packages if you selected them earlier with menuconfig.

==== If Something Goes Wrong ====

Perhaps you missed some step above and the build fails. Or you're just switching to a different processor configuration, or making some change with unknown dependencies. Either way, you'll probably need to fix the error and/or make the change, and redo the whole build. The above <tt>make</tt> command usually works fine if you
just added a package using menuconfig, but otherwise does not check many dependencies, so it will usually NOT rebuild things that depend on whatever you have fixed or changed. Here's one way to retry the make from scratch without having to wipe out the <tt>buildroot</tt> directory tree completely and start again from the git cloning.

$ rm -rf *build_xtensa* binaries
$ make

It is not necessary to empty the 'dl' subdirectory, which contains tarballs downloaded from the Internet, nor the .config file, which contains the buildroot configuration. Customizations to the uClibc and <tt>busybox</tt> configurations should have ended up getting saved in target/xtensa/uClibc.config and target/xtensa/busybox-config, respectively, so hopefully are preserved by the above sequence.

== Build and Run a Linux Kernel on the XTAV60 or XTAV200 Board ==

References to the ''XTAV60 board'' refer to the combination of
the Avnet [http://www.em.avnet.com/tensilica1 LX60 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX60 (XT-AV60) Board User's Guide''.

Similarly, references to the ''XTAV200 board'' refers the combination of
the Avnet [http://www.em.avnet.com/tensilica2 LX200 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX200 (XT-AV200) Board User's Guide''.

=== Configure the kernel ===

The kernel build is a two-step process: configure the kernel, and build it.
First, before we can do anything with the kernel, set your PATH to
point to the toolchain built using buildroot.

$ export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"

where ''<cname>'' is the name of the Xtensa processor configuration you selected
when building the toolchain (e.g., <code>dc232b</code>).

Now setup a destination for kernel builds.
We usually like to have the build directory separate from
the source directory, so we use 'O=</destination/path>' in
kernel make commands. If you'll be routinely building multiple
configurations of the Linux kernel, it's good to have some
naming conventions for the build directory. For example,
to experiment with multiple target platforms but only one
processor configuration, we include just the platform name here:

$ mkdir build-xtav60

Let's start with the default kernel configuration for the Avnet board
(which works on both XTAV60 (LX60) and XTAV200 (LX200) boards)
as follows:

$ cd linux
$ make O=../build-xtav60 ARCH=xtensa KBUILD_DEFCONFIG=lx60_defconfig defconfig

This configures the kernel using the default configuration found in
arch/xtensa/configs/lx60_defconfig.

NOTE: This kernel configuration has nothing to do with Xtensa
processor configuration. That comes next.

Let's now customize this a little bit to select the correct Xtensa processor
configuration, and to bundle the root filesystem into the kernel:

$ make O=../build-xtav60 ARCH=xtensa menuconfig

Under '''General setup''',
make sure the '''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is enabled. Underneath that, edit '''Initramfs source file(s)''',
and enter the path to the cpio formatted root filesystem
generated by buildroot:

''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio.gz

(Don't forget to replace ''<workdir>'' with the appropriate full path
and ''<cname>'' with your Xtensa processor configuration name.)

Under '''Processor type and features''',
make sure the '''Xtensa Processor Configuration''' is correct and matches
the processor configuration name you used to build the toolchain with buildroot
(for example, ''dc232b'' for Diamond 232L Rev.B).
The kernel build selects a toolchain and processor variant specific headers
based on this selection.
If the desired processor configuration does not appear explicitly in the list,
simply select '''Custom Xtensa processor configuration''' and enter the
processor configuration name (all lowercase) into the next menu parameter,
'''Xtensa Processor Custom Variant Name'''.

Back in the main menu, under '''Platform options''', make sure the
'''CPU clock rate''' entry is set correctly according to the following table:

{| border="1" style="text-align:center; margin: 1em auto 1em auto"
|-
! Board !! Frequency selected in XPG (MHz) !! ''CPU clock rate'' setting (kHz)
|-
|rowspan="3"| XTAV60 (LX60)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV110 (LX110)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV200 (LX200)
| 30 || 31250
|-
| 40 || 41667
|-
| 50 || 50000
|-
|}

Exit menuconfig, saving your configuration changes.

Backup your configuration outside the build directory. For example:

$ cp ../build-xtav60/.config config.xtav60.saved

If you do a clean rebuild of the kernel (e.g., "rm -rf ../build-xtav60")
you can now configure it with simply:
$ mkdir ../build-xtav60 ; cp config.xtav60.saved ../build-xtav60/.config
Of course if you update the kernel, you'll probably again have to do:
$ make O=../build-xtav60 ARCH=xtensa menuconfig
and save a new copy of your configuration.

=== Build the kernel ===

$ make O=../build-xtav60 ARCH=xtensa

The build will issue a few warnings which are normal.
Once complete, the bootable image is in:
<workdir>/build-xtav60/arch/xtensa/boot/Image.elf
and the uncompressed ELF file containing kernel symbols is in:
<workdir>/build-xtav60/vmlinux
There is also a RedBoot bootable image (if you use RedBoot) in:
<workdir>/build-xtav60/arch/xtensa/boot/zImage.redboot

=== Install Xtensa Tools for the selected core ===

If you opt to download the kernel over OCD, you need <tt>xt-gdb</tt>
which is part of Tensilica's Xtensa Tools package. This must be obtained
from Tensilica, and is not the same toolchain as built by buildroot.
You also need to install the corresponding Tensilica core package,
so that the Xtensa Tools know about your particular configured
Tensilica core.

The toolchain built using buildroot can be configured to
include GDB, but that version of GDB does not support
communicating with Tensilica's Xtensa OCD Daemon, and
thus cannot be used to download the kernel over OCD.

In this example, it is assumed that the machine hosting the
Xtensa Tools has access to the <workdir> directory tree.

=== Install and setup the Xtensa OCD Daemon ===

Setup and connect your JTAG probe, etc.

=== Connect a terminal server ===

At 38400 bps 8N1 no flow control to the XTAV60 serial port.

=== Optionally, setup networking ===

This step is optional.

Setup the board's MAC address using dipswitches
(see XTAV60 or XTAV200 board docs as appropriate)
and connect the board to a network that has a
DHCP server that will respond to that MAC address.
If you don't do this step, you'll simply not have network
access, and the boot process will take a minute or so longer
while the kernel times out waiting for a BOOTP response.
You can edit the kernel configuration and rebuild the kernel
to avoid using bootp (in particular, remove "ip=bootp" from
the kernel cmdline).

=== Download and run the kernel ===

Reset the board (see board documentation).

Using Xtensa Tools, invoke:

$ xt-gdb <workdir>/build-xtav60/arch/xtensa/boot/Image.elf

(xt-gdb) target remote <ocdhost>:20000 0
(xt-gdb) reset
(xt-gdb) load
(xt-gdb) set $pc = &_ResetVector
(xt-gdb) symbol-file <workdir>/build-xtav60/vmlinux
(xt-gdb) c

where <ocdhost> is the IP address or DNS name of the machine
running the Xtensa OCD daemon. The Linux kernel should
start booting as soon as 'c' (continue) is executed.

You should eventually get a login prompt.
Just login as root (no password).

Try various Linux commands. Look at <tt>/bin</tt>,
<tt>/sbin</tt>, <tt>/usr/bin</tt>, etc to see what's available.

Note: no need to setup an NFS or TFTP server. The filesystem
is contained within the kernel image. You may be able to mount
other filesystems over NFS though, if you wish, after booting.

=== Mounting the Root Filesystem Over NFS ===

If you build more than the minimal set of packages using
buildroot, the root filesystem can easily grow too large to
fit comfortably (or at all) inside the kernel. In this case,
rather than follow the instructions exactly as above,
you'll want to mount the root filesystem over NFS.

You may also want to mount the root filesystem over NFS to
make changes to the filesystem persistent across runs and
accessible from your development host.

First you need to install the root filesystem generated
using buildroot, to a machine that can serve it over NFS.
Assuming this machine runs Linux, one way to install it is
as follows:

mkdir ''<exportpath>''
cd ''<exportpath>''
sudo cpio -i -d -m -F ''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio --no-absolute-filenames

You then need to enable the NFS server on your system
(if not already active), and export this filesystem.
How you do this depends on your host Linux distribution.
For example, on some Fedora releases, one might:

* add the export path to <tt>/etc/exports</tt> using a line such as

''<exportpath>'' *(rw,sync,no_root_squash,no_all_squash)

* turn on the NFS server if needed:

sudo /sbin/chkconfig nfs on

* tell the NFS server about the new exported filesystem

sudo /usr/sbin/exportfs -a
sudo /usr/sbin/exportfs -r

Second, follow the instructions in the previous sections,
then configure the kernel again as follows.

Under '''General setup''', make sure the
'''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is disabled (rather than enabled as done in previous sections).

Under '''Platform options''', under the line '''Default bootloader kernel arguments''',
select the boot parameters line and set it to something like this:

console=ttyS0,38400 ip=dhcp root=/dev/nfs rw nfsroot=''<server_ip>'':''<exportpath>''

where ''<server_ip>'' is the IP address of your NFS server, and ''<exportpath>''
is the exported filesystem path.

Save this configuration, rebuild the kernel, and follow the
instructions in previous sections to download and run the kernel.
If everything goes well and is setup correctly, your kernel should
now boot with a root filesystem mounted over NFS.

== Build and Run a Linux Kernel on the Instruction Set Simulator (ISS) ==

You can build and run a Linux kernel in the Xtensa Instruction Set
Simulator (ISS). The following instructions have only been tried
with an ISS from the RB-2008.3 release of Xtensa Tools. Bear in
mind that the XTAV60 port is likely much more stable than the ISS port
of Linux at this point in time.

Note: Depending on your host OS version, you may need to install
Xtensa Tools on a separate machine.

=== Configure and Build the Kernel for ISS ===

Repeat all the same instructions as above for building the kernel for the
XTAV60 board, except that when initially configuring the kernel,
start from a ISS platform template instead. For example for the
DC233C Variant:

'''$ mkdir build-iss'''
'''$ cd linux'''
'''$ make O=../build-iss ARCH=xtensa KBUILD_DEFCONFIG=iss_dc233c_defconfig defconfig'''

The above make example configures the kernel using the default configuration found in
'''arch/xtensa/configs/iss_dc233_defconfig'''. Most important to note is that the
root file system mounted when Linux boots comes via the targets device '''/dev/simdisk0'''
which is defined in the kernel '''.config''' file. For example:

CONFIG_SIMDISK0_FILENAME="/export2/DC_C_233L/LINUX_ROOT.ext2"

The SIMDISK file name and VARIANT name are typically configured when running '''make menuconfig''', Ex:

'''$ make O=../build-iss ARCH=xtensa menuconfig'''

and selecting

'''Xtensa Platform options''' ---> '''Host filename for a simulated device'''

and entering the pathname to the .ext2 file there. Ex: '''/export2/DC_C_233L/LINUX_ROOT.ext2'''

You often want to change the VARIANT to the one you desire, Ex: FSF. You do this via
the top level menu:

'''Xtensa Processor type and features --->Xtensa Processor Custom Core Variant Name'''

With the new SIMDISK approach you copy the EXT2 Filesystem file generated by Buildroot
to a location to be accessed by Xtensa Linux. Ex:

'''$ cp /export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot/binaries/dc233c/rootfs.xtensa_dc233c.ext2 /export2/DC_C_233L/LINUX_ROOT.ext2'''

'''NOTE:''' There is an old '''iss_defconfig''' that tries to use a '''tuntap''' Ethernet
interface that currently isn't supported.
Previously with this old iss_defconfig using the '''tuntap''' Ethernet interface
it was suggested to set up the initramfs filesystem, and do the following.
Under '''Bus Options''', deselect '''PCI support'''.
Under '''Platform Options''', deselect '''Default bootloader kernel arguments'''.
Hopefully we will someday be able to support the use of a network interface with
ISS simulation and then be able to mount NFS root partitions again. So I'm leaving
this note for future exploration of this mechanism. Hope you don't mind the clutter.

Continue configuring and building the kernel as usual.

=== Run the Kernel on ISS ===

Using Xtensa Tools, invoke:

$ xt-gdb <workdir>/build-iss/arch/xtensa/boot/Image.elf
(xt-gdb) target sim --turbo --memlimit=128
(xt-gdb) symbol-file <workdir>/build-iss/vmlinux
(xt-gdb) run

Wait patiently while Linux boots ... (maybe a minute). The setting of the '''memlimit'''
needs to match the PLATFORM_DEFAULT_MEM_SIZE defined in /arch/xtensa/platforms/iss/include/platform/hardware.h.
Currently this limit us 128 MegaBytes:

#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000 /* 13,4217,728 128M */

and we will be extending this for the DC233L to take advantage of it's V3 MMU.

Login as root (no password).

Note: Input via ISS is cooked, so everything typed gets echoed.
Also, time as reported by the kernel does not progress
according to true wall-clock time: it currently depends on
a simulated processor clock, which advances at various speeds
according to load.

Instructions for building and booting Linux

2010-12-02T06:49:23Z

Piet: /* Run the Kernel on ISS */

These instructions explain how to build a toolchain, root filesystem and kernel for Linux running on an Xtensa processor. These instructions apply specifically to the XTAV60 (LX60) board.

Some general notes on these instructions:

* They are a work in progress. If you are using the latest development sources, the build process may change, so you should be sure to get the latest version of this document at [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions]. If you are using one of the development snapshot releases, you should use the version of the build instructions included with that snapshot.

* The following was tested on x86 machines running RedHat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3). It is expected to work on newer Fedora releases (e.g., was tested on FC6) but to maintain host compatibility with Xtensa Tools, it is best to avoid Fedora releases beyond FC5. Other host distributions likely work but have not been tested.
** '''NOTE:''' this assumes the default selection of packages in buildroot. Selecting extra packages may require a more recent host OS or more recent version of certain tools. For example, the default version of <tt>find</tt> on RHEL4 is too old to allow building all X11 packages in buildroot, so it is necessary to upgrade the host version of <tt>findutils</tt> on RHEL4 to build these packages.

* Lines prefixed with "sudo" need to be executed as root. The rest is best executed as a non-root user. (It is possible to install <tt>git</tt> as a non-root user if root access is an issue. How to do this isn't shown here.)

* Lines that set environment variables assume a Bourne compatible shell (e.g., /bin/sh or bash), but are easily adapted to other shells.

* Instructions are assumed executed all in order (e.g., commands assume current directory and environment variables set earlier).

== Setup your host system ==

If you are using one of the snapshot releases, you can skip this step.

If you want to work with the latest development sources, you will need
[[Installing GIT|<tt>git</tt> installed on your system]].

== Download buildroot and the Linux kernel ==

The following section describes how to download the latest
versions of buildroot and of the Linux kernel.
Skip this step if you are using one of the
[http://wiki.linux-xtensa.org/index.php/Buildroot_Snapshots snapshot releases].

For most users, just execute the following:

$ cd <workdir>
$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa.git buildroot
$ git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git linux

where <tt><workdir></tt> is the path to an empty directory on a disk with
at least 4 GB available space. You end up with the following file structure,
which is assumed by the rest of this document:

<workdir>/
/buildroot
/linux

The MASTER branch of the buildroot repository is often is a state of development.
It's recommended to use the last snapshot for application developers. In the
case of the HiFi-2 development board a 'snapshot_2+SMP' branch is recommended
in the currently experimental SMP git repository:

$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot
$ git branch --track snapshot_2+SMP
$ git checkout snapshot_2+SMP

If you happen to have write access to either repository, or want more details,
see the [http://wiki.linux-xtensa.org/index.php/Repository_Access repository access] page.

== Install any required processor specific overlay ==

This step is required if you are targeting a custom Xtensa processor.
If you use a Diamond 232L Standard Core, you can skip this step.

To configure buildroot and the kernel to use a custom Xtensa processor
configuration, you need to overlay a set of files customized for your
processor configuration onto toolchain sources (gcc, binutils, gdb, etc)
and the Linux kernel. This process has been automated using a script
located in the buildroot source tree.
For usage information, you can invoke it without arguments:

$ cd <workdir>
$ ./buildroot/target/xtensa/xt-buildroot-overlay-install

which displays a help message similar to the following:

xt-buildroot-overlay-install version 1.3
Usage: xt-buildroot-overlay-install <parameters> [<options>]
Where <parameters> are:
-t file.tgz Specify path to the Xtensa Linux overlay tarball, typically
<xtensa_root>/src/xtensa-config-overlay.tar.gz
-b dir Path to the base of the buildroot source tree, in which
package specific overlay tarballs get installed.
-k dir Path to the base of the Linux kernel source tree, in which
the Linux kernel specific overlay gets installed.
-c config_name Name for the Xtensa processor configuration as it will be
known to the open source community. Must be a lowercase
identifier, starting with a letter, consisting of letters
and numbers and underscores, not ending with underscore
and not containing consecutive underscores. For examples:
dc232b , dc232b_be , mmubasele , fsf , s5000 .
-l long_name Long name for the Xtensa processor configuration, human-
readable with spaces etc allowed (must be quoted).
For example: 'Diamond 232L Standard Core Rev.B (LE)'
Try to keep it within approximately 40 characters.
And <options> are:
-f If package specific overlay tarballs already exist in
the destination source tree, overwrite them without asking.
--help Show this usage message.

Note that the Xtensa Linux overlay tarball MUST be obtained from an Xtensa
core package built using release RB-2008.3 or later.

Here is an example invocation of the overlay installation script:

$ ./buildroot/target/xtensa/xt-buildroot-overlay-install -t blinkcore-config-overlay.tar.gz \
-b ./buildroot -k ./linux -c superzip -l "ChipCorp SuperZIP Blink Accelerator Core"

The script extracts some relevant information from the overlay tarball,
presents it along with relevant parameters to the user, and prompts
for confirmation before proceeding.

The chosen processor name (-c option) must be unique among known Xtensa processors.
It is also probably wise to avoid names confusingly similar to other (non-Xtensa) processors.
If you expect at some point to contribute support for your custom processor to the
open-source community, this name will likely be long-lived.
(One way to contribute support for a custom processor might be to submit the overlay tarball
or files to the linux-xtensa.org maintainers.)

In the steps below, buildroot and the Linux kernel must be configured
(in their respective <code>''make menuconfig''</code> steps) to select
the <code>''custom''</code> Xtensa processor option.
This presents an extra configuration menu entry where you must provide
the name of the Xtensa processor. Set it to the same name
as was specified in the <code>-c</code> option above.

== Build a toolchain and root filesystem using buildroot ==

'''Note:''' for more details on generic buildroot topics not covered in this simple how-to,
see [http://buildroot.uclibc.org/ buildroot.uclibc.org].

=== Configure buildroot ===

The first time you configure buildroot, start with defaults for your Xtensa processor:

$ cd <workdir>/buildroot
$ ./target/xtensa/setup-config <corename>

where ''<corename>'' is the overlay name of your selected Xtensa or Diamond core
(e.g., '''dc232b'''). If you omit ''<corename>'', a help message and a list
of currently installed Tensilica core overlays is displayed.

Optionally, you can then customize your buildroot configuration, such as
selecting additional packages, setting various parameters, and so on.
The following make targets provide a ''curses'' (text-based graphical) interface
for configuring buildroot, the uClibc C library, and busybox, respectively.
('''Note:''' You need the <tt>TERM</tt> environment variable properly set for
these curses based tools to work.)

$ make menuconfig
$ make uclibc-menuconfig
$ make busybox-menuconfig

=== Build buildroot ===

Just type:

$ make

THIS WILL TAKE A LONG TIME (from about 30 minutes with defaults on a 3 GHz Pentium 4,
to perhaps an hour or many depending on your system and on whether
you enabled extra packages in your buildroot configuration).

Wait patiently for the build to complete. This builds an entire toolchain
as well as some basic packages, and constructs a root filesystem.
It might build many more packages if you selected them earlier with menuconfig.

==== If Something Goes Wrong ====

Perhaps you missed some step above and the build fails. Or you're just switching to a different processor configuration, or making some change with unknown dependencies. Either way, you'll probably need to fix the error and/or make the change, and redo the whole build. The above <tt>make</tt> command usually works fine if you
just added a package using menuconfig, but otherwise does not check many dependencies, so it will usually NOT rebuild things that depend on whatever you have fixed or changed. Here's one way to retry the make from scratch without having to wipe out the <tt>buildroot</tt> directory tree completely and start again from the git cloning.

$ rm -rf *build_xtensa* binaries
$ make

It is not necessary to empty the 'dl' subdirectory, which contains tarballs downloaded from the Internet, nor the .config file, which contains the buildroot configuration. Customizations to the uClibc and <tt>busybox</tt> configurations should have ended up getting saved in target/xtensa/uClibc.config and target/xtensa/busybox-config, respectively, so hopefully are preserved by the above sequence.

== Build and Run a Linux Kernel on the XTAV60 or XTAV200 Board ==

References to the ''XTAV60 board'' refer to the combination of
the Avnet [http://www.em.avnet.com/tensilica1 LX60 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX60 (XT-AV60) Board User's Guide''.

Similarly, references to the ''XTAV200 board'' refers the combination of
the Avnet [http://www.em.avnet.com/tensilica2 LX200 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX200 (XT-AV200) Board User's Guide''.

=== Configure the kernel ===

The kernel build is a two-step process: configure the kernel, and build it.
First, before we can do anything with the kernel, set your PATH to
point to the toolchain built using buildroot.

$ export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"

where ''<cname>'' is the name of the Xtensa processor configuration you selected
when building the toolchain (e.g., <code>dc232b</code>).

Now setup a destination for kernel builds.
We usually like to have the build directory separate from
the source directory, so we use 'O=</destination/path>' in
kernel make commands. If you'll be routinely building multiple
configurations of the Linux kernel, it's good to have some
naming conventions for the build directory. For example,
to experiment with multiple target platforms but only one
processor configuration, we include just the platform name here:

$ mkdir build-xtav60

Let's start with the default kernel configuration for the Avnet board
(which works on both XTAV60 (LX60) and XTAV200 (LX200) boards)
as follows:

$ cd linux
$ make O=../build-xtav60 ARCH=xtensa KBUILD_DEFCONFIG=lx60_defconfig defconfig

This configures the kernel using the default configuration found in
arch/xtensa/configs/lx60_defconfig.

NOTE: This kernel configuration has nothing to do with Xtensa
processor configuration. That comes next.

Let's now customize this a little bit to select the correct Xtensa processor
configuration, and to bundle the root filesystem into the kernel:

$ make O=../build-xtav60 ARCH=xtensa menuconfig

Under '''General setup''',
make sure the '''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is enabled. Underneath that, edit '''Initramfs source file(s)''',
and enter the path to the cpio formatted root filesystem
generated by buildroot:

''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio.gz

(Don't forget to replace ''<workdir>'' with the appropriate full path
and ''<cname>'' with your Xtensa processor configuration name.)

Under '''Processor type and features''',
make sure the '''Xtensa Processor Configuration''' is correct and matches
the processor configuration name you used to build the toolchain with buildroot
(for example, ''dc232b'' for Diamond 232L Rev.B).
The kernel build selects a toolchain and processor variant specific headers
based on this selection.
If the desired processor configuration does not appear explicitly in the list,
simply select '''Custom Xtensa processor configuration''' and enter the
processor configuration name (all lowercase) into the next menu parameter,
'''Xtensa Processor Custom Variant Name'''.

Back in the main menu, under '''Platform options''', make sure the
'''CPU clock rate''' entry is set correctly according to the following table:

{| border="1" style="text-align:center; margin: 1em auto 1em auto"
|-
! Board !! Frequency selected in XPG (MHz) !! ''CPU clock rate'' setting (kHz)
|-
|rowspan="3"| XTAV60 (LX60)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV110 (LX110)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV200 (LX200)
| 30 || 31250
|-
| 40 || 41667
|-
| 50 || 50000
|-
|}

Exit menuconfig, saving your configuration changes.

Backup your configuration outside the build directory. For example:

$ cp ../build-xtav60/.config config.xtav60.saved

If you do a clean rebuild of the kernel (e.g., "rm -rf ../build-xtav60")
you can now configure it with simply:
$ mkdir ../build-xtav60 ; cp config.xtav60.saved ../build-xtav60/.config
Of course if you update the kernel, you'll probably again have to do:
$ make O=../build-xtav60 ARCH=xtensa menuconfig
and save a new copy of your configuration.

=== Build the kernel ===

$ make O=../build-xtav60 ARCH=xtensa

The build will issue a few warnings which are normal.
Once complete, the bootable image is in:
<workdir>/build-xtav60/arch/xtensa/boot/Image.elf
and the uncompressed ELF file containing kernel symbols is in:
<workdir>/build-xtav60/vmlinux
There is also a RedBoot bootable image (if you use RedBoot) in:
<workdir>/build-xtav60/arch/xtensa/boot/zImage.redboot

=== Install Xtensa Tools for the selected core ===

If you opt to download the kernel over OCD, you need <tt>xt-gdb</tt>
which is part of Tensilica's Xtensa Tools package. This must be obtained
from Tensilica, and is not the same toolchain as built by buildroot.
You also need to install the corresponding Tensilica core package,
so that the Xtensa Tools know about your particular configured
Tensilica core.

The toolchain built using buildroot can be configured to
include GDB, but that version of GDB does not support
communicating with Tensilica's Xtensa OCD Daemon, and
thus cannot be used to download the kernel over OCD.

In this example, it is assumed that the machine hosting the
Xtensa Tools has access to the <workdir> directory tree.

=== Install and setup the Xtensa OCD Daemon ===

Setup and connect your JTAG probe, etc.

=== Connect a terminal server ===

At 38400 bps 8N1 no flow control to the XTAV60 serial port.

=== Optionally, setup networking ===

This step is optional.

Setup the board's MAC address using dipswitches
(see XTAV60 or XTAV200 board docs as appropriate)
and connect the board to a network that has a
DHCP server that will respond to that MAC address.
If you don't do this step, you'll simply not have network
access, and the boot process will take a minute or so longer
while the kernel times out waiting for a BOOTP response.
You can edit the kernel configuration and rebuild the kernel
to avoid using bootp (in particular, remove "ip=bootp" from
the kernel cmdline).

=== Download and run the kernel ===

Reset the board (see board documentation).

Using Xtensa Tools, invoke:

$ xt-gdb <workdir>/build-xtav60/arch/xtensa/boot/Image.elf

(xt-gdb) target remote <ocdhost>:20000 0
(xt-gdb) reset
(xt-gdb) load
(xt-gdb) set $pc = &_ResetVector
(xt-gdb) symbol-file <workdir>/build-xtav60/vmlinux
(xt-gdb) c

where <ocdhost> is the IP address or DNS name of the machine
running the Xtensa OCD daemon. The Linux kernel should
start booting as soon as 'c' (continue) is executed.

You should eventually get a login prompt.
Just login as root (no password).

Try various Linux commands. Look at <tt>/bin</tt>,
<tt>/sbin</tt>, <tt>/usr/bin</tt>, etc to see what's available.

Note: no need to setup an NFS or TFTP server. The filesystem
is contained within the kernel image. You may be able to mount
other filesystems over NFS though, if you wish, after booting.

=== Mounting the Root Filesystem Over NFS ===

If you build more than the minimal set of packages using
buildroot, the root filesystem can easily grow too large to
fit comfortably (or at all) inside the kernel. In this case,
rather than follow the instructions exactly as above,
you'll want to mount the root filesystem over NFS.

You may also want to mount the root filesystem over NFS to
make changes to the filesystem persistent across runs and
accessible from your development host.

First you need to install the root filesystem generated
using buildroot, to a machine that can serve it over NFS.
Assuming this machine runs Linux, one way to install it is
as follows:

mkdir ''<exportpath>''
cd ''<exportpath>''
sudo cpio -i -d -m -F ''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio --no-absolute-filenames

You then need to enable the NFS server on your system
(if not already active), and export this filesystem.
How you do this depends on your host Linux distribution.
For example, on some Fedora releases, one might:

* add the export path to <tt>/etc/exports</tt> using a line such as

''<exportpath>'' *(rw,sync,no_root_squash,no_all_squash)

* turn on the NFS server if needed:

sudo /sbin/chkconfig nfs on

* tell the NFS server about the new exported filesystem

sudo /usr/sbin/exportfs -a
sudo /usr/sbin/exportfs -r

Second, follow the instructions in the previous sections,
then configure the kernel again as follows.

Under '''General setup''', make sure the
'''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is disabled (rather than enabled as done in previous sections).

Under '''Platform options''', under the line '''Default bootloader kernel arguments''',
select the boot parameters line and set it to something like this:

console=ttyS0,38400 ip=dhcp root=/dev/nfs rw nfsroot=''<server_ip>'':''<exportpath>''

where ''<server_ip>'' is the IP address of your NFS server, and ''<exportpath>''
is the exported filesystem path.

Save this configuration, rebuild the kernel, and follow the
instructions in previous sections to download and run the kernel.
If everything goes well and is setup correctly, your kernel should
now boot with a root filesystem mounted over NFS.

== Build and Run a Linux Kernel on the Instruction Set Simulator (ISS) ==

You can build and run a Linux kernel in the Xtensa Instruction Set
Simulator (ISS). The following instructions have only been tried
with an ISS from the RB-2008.3 release of Xtensa Tools. Bear in
mind that the XTAV60 port is likely much more stable than the ISS port
of Linux at this point in time.

Note: Depending on your host OS version, you may need to install
Xtensa Tools on a separate machine.

=== Configure and Build the Kernel for ISS ===

Repeat all the same instructions as above for building the kernel for the
XTAV60 board, except that when initially configuring the kernel,
start from the ISS platform template instead:

$ mkdir build-iss
$ cd linux
$ make O=../build-iss ARCH=xtensa KBUILD_DEFCONFIG=iss_defconfig defconfig

This configures the kernel using the default configuration found in
arch/xtensa/configs/iss_defconfig.

Also, when running menuconfig:

$ make O=../build-iss ARCH=xtensa menuconfig

in addition to setting up the initramfs filesystem, do the following.
Under '''Bus Options''', deselect '''PCI support'''.
Under '''Platform Options''', deselect '''Default bootloader kernel arguments'''.

Continue configuring and building the kernel as usual.

=== Run the Kernel on ISS ===

Using Xtensa Tools, invoke:

$ xt-gdb <workdir>/build-iss/arch/xtensa/boot/Image.elf
(xt-gdb) target sim --turbo --memlimit=128
(xt-gdb) symbol-file <workdir>/build-iss/vmlinux
(xt-gdb) run

Wait patiently while Linux boots ... (maybe a minute). The setting of the '''memlimit'''
needs to match the PLATFORM_DEFAULT_MEM_SIZE defined in /arch/xtensa/platforms/iss/include/platform/hardware.h.
Currently this limit us 128 MegaBytes:

#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000 /* 13,4217,728 128M */

and we will be extending this for the DC233L to take advantage of it's V3 MMU.

Login as root (no password).

Note: Input via ISS is cooked, so everything typed gets echoed.
Also, time as reported by the kernel does not progress
according to true wall-clock time: it currently depends on
a simulated processor clock, which advances at various speeds
according to load.

Instructions for building and booting Linux

2010-12-02T01:47:27Z

Piet: /* Run the Kernel on ISS */

These instructions explain how to build a toolchain, root filesystem and kernel for Linux running on an Xtensa processor. These instructions apply specifically to the XTAV60 (LX60) board.

Some general notes on these instructions:

* They are a work in progress. If you are using the latest development sources, the build process may change, so you should be sure to get the latest version of this document at [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions]. If you are using one of the development snapshot releases, you should use the version of the build instructions included with that snapshot.

* The following was tested on x86 machines running RedHat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3). It is expected to work on newer Fedora releases (e.g., was tested on FC6) but to maintain host compatibility with Xtensa Tools, it is best to avoid Fedora releases beyond FC5. Other host distributions likely work but have not been tested.
** '''NOTE:''' this assumes the default selection of packages in buildroot. Selecting extra packages may require a more recent host OS or more recent version of certain tools. For example, the default version of <tt>find</tt> on RHEL4 is too old to allow building all X11 packages in buildroot, so it is necessary to upgrade the host version of <tt>findutils</tt> on RHEL4 to build these packages.

* Lines prefixed with "sudo" need to be executed as root. The rest is best executed as a non-root user. (It is possible to install <tt>git</tt> as a non-root user if root access is an issue. How to do this isn't shown here.)

* Lines that set environment variables assume a Bourne compatible shell (e.g., /bin/sh or bash), but are easily adapted to other shells.

* Instructions are assumed executed all in order (e.g., commands assume current directory and environment variables set earlier).

== Setup your host system ==

If you are using one of the snapshot releases, you can skip this step.

If you want to work with the latest development sources, you will need
[[Installing GIT|<tt>git</tt> installed on your system]].

== Download buildroot and the Linux kernel ==

The following section describes how to download the latest
versions of buildroot and of the Linux kernel.
Skip this step if you are using one of the
[http://wiki.linux-xtensa.org/index.php/Buildroot_Snapshots snapshot releases].

For most users, just execute the following:

$ cd <workdir>
$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa.git buildroot
$ git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git linux

where <tt><workdir></tt> is the path to an empty directory on a disk with
at least 4 GB available space. You end up with the following file structure,
which is assumed by the rest of this document:

<workdir>/
/buildroot
/linux

The MASTER branch of the buildroot repository is often is a state of development.
It's recommended to use the last snapshot for application developers. In the
case of the HiFi-2 development board a 'snapshot_2+SMP' branch is recommended
in the currently experimental SMP git repository:

$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot
$ git branch --track snapshot_2+SMP
$ git checkout snapshot_2+SMP

If you happen to have write access to either repository, or want more details,
see the [http://wiki.linux-xtensa.org/index.php/Repository_Access repository access] page.

== Install any required processor specific overlay ==

This step is required if you are targeting a custom Xtensa processor.
If you use a Diamond 232L Standard Core, you can skip this step.

To configure buildroot and the kernel to use a custom Xtensa processor
configuration, you need to overlay a set of files customized for your
processor configuration onto toolchain sources (gcc, binutils, gdb, etc)
and the Linux kernel. This process has been automated using a script
located in the buildroot source tree.
For usage information, you can invoke it without arguments:

$ cd <workdir>
$ ./buildroot/target/xtensa/xt-buildroot-overlay-install

which displays a help message similar to the following:

xt-buildroot-overlay-install version 1.3
Usage: xt-buildroot-overlay-install <parameters> [<options>]
Where <parameters> are:
-t file.tgz Specify path to the Xtensa Linux overlay tarball, typically
<xtensa_root>/src/xtensa-config-overlay.tar.gz
-b dir Path to the base of the buildroot source tree, in which
package specific overlay tarballs get installed.
-k dir Path to the base of the Linux kernel source tree, in which
the Linux kernel specific overlay gets installed.
-c config_name Name for the Xtensa processor configuration as it will be
known to the open source community. Must be a lowercase
identifier, starting with a letter, consisting of letters
and numbers and underscores, not ending with underscore
and not containing consecutive underscores. For examples:
dc232b , dc232b_be , mmubasele , fsf , s5000 .
-l long_name Long name for the Xtensa processor configuration, human-
readable with spaces etc allowed (must be quoted).
For example: 'Diamond 232L Standard Core Rev.B (LE)'
Try to keep it within approximately 40 characters.
And <options> are:
-f If package specific overlay tarballs already exist in
the destination source tree, overwrite them without asking.
--help Show this usage message.

Note that the Xtensa Linux overlay tarball MUST be obtained from an Xtensa
core package built using release RB-2008.3 or later.

Here is an example invocation of the overlay installation script:

$ ./buildroot/target/xtensa/xt-buildroot-overlay-install -t blinkcore-config-overlay.tar.gz \
-b ./buildroot -k ./linux -c superzip -l "ChipCorp SuperZIP Blink Accelerator Core"

The script extracts some relevant information from the overlay tarball,
presents it along with relevant parameters to the user, and prompts
for confirmation before proceeding.

The chosen processor name (-c option) must be unique among known Xtensa processors.
It is also probably wise to avoid names confusingly similar to other (non-Xtensa) processors.
If you expect at some point to contribute support for your custom processor to the
open-source community, this name will likely be long-lived.
(One way to contribute support for a custom processor might be to submit the overlay tarball
or files to the linux-xtensa.org maintainers.)

In the steps below, buildroot and the Linux kernel must be configured
(in their respective <code>''make menuconfig''</code> steps) to select
the <code>''custom''</code> Xtensa processor option.
This presents an extra configuration menu entry where you must provide
the name of the Xtensa processor. Set it to the same name
as was specified in the <code>-c</code> option above.

== Build a toolchain and root filesystem using buildroot ==

'''Note:''' for more details on generic buildroot topics not covered in this simple how-to,
see [http://buildroot.uclibc.org/ buildroot.uclibc.org].

=== Configure buildroot ===

The first time you configure buildroot, start with defaults for your Xtensa processor:

$ cd <workdir>/buildroot
$ ./target/xtensa/setup-config <corename>

where ''<corename>'' is the overlay name of your selected Xtensa or Diamond core
(e.g., '''dc232b'''). If you omit ''<corename>'', a help message and a list
of currently installed Tensilica core overlays is displayed.

Optionally, you can then customize your buildroot configuration, such as
selecting additional packages, setting various parameters, and so on.
The following make targets provide a ''curses'' (text-based graphical) interface
for configuring buildroot, the uClibc C library, and busybox, respectively.
('''Note:''' You need the <tt>TERM</tt> environment variable properly set for
these curses based tools to work.)

$ make menuconfig
$ make uclibc-menuconfig
$ make busybox-menuconfig

=== Build buildroot ===

Just type:

$ make

THIS WILL TAKE A LONG TIME (from about 30 minutes with defaults on a 3 GHz Pentium 4,
to perhaps an hour or many depending on your system and on whether
you enabled extra packages in your buildroot configuration).

Wait patiently for the build to complete. This builds an entire toolchain
as well as some basic packages, and constructs a root filesystem.
It might build many more packages if you selected them earlier with menuconfig.

==== If Something Goes Wrong ====

Perhaps you missed some step above and the build fails. Or you're just switching to a different processor configuration, or making some change with unknown dependencies. Either way, you'll probably need to fix the error and/or make the change, and redo the whole build. The above <tt>make</tt> command usually works fine if you
just added a package using menuconfig, but otherwise does not check many dependencies, so it will usually NOT rebuild things that depend on whatever you have fixed or changed. Here's one way to retry the make from scratch without having to wipe out the <tt>buildroot</tt> directory tree completely and start again from the git cloning.

$ rm -rf *build_xtensa* binaries
$ make

It is not necessary to empty the 'dl' subdirectory, which contains tarballs downloaded from the Internet, nor the .config file, which contains the buildroot configuration. Customizations to the uClibc and <tt>busybox</tt> configurations should have ended up getting saved in target/xtensa/uClibc.config and target/xtensa/busybox-config, respectively, so hopefully are preserved by the above sequence.

== Build and Run a Linux Kernel on the XTAV60 or XTAV200 Board ==

References to the ''XTAV60 board'' refer to the combination of
the Avnet [http://www.em.avnet.com/tensilica1 LX60 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX60 (XT-AV60) Board User's Guide''.

Similarly, references to the ''XTAV200 board'' refers the combination of
the Avnet [http://www.em.avnet.com/tensilica2 LX200 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX200 (XT-AV200) Board User's Guide''.

=== Configure the kernel ===

The kernel build is a two-step process: configure the kernel, and build it.
First, before we can do anything with the kernel, set your PATH to
point to the toolchain built using buildroot.

$ export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"

where ''<cname>'' is the name of the Xtensa processor configuration you selected
when building the toolchain (e.g., <code>dc232b</code>).

Now setup a destination for kernel builds.
We usually like to have the build directory separate from
the source directory, so we use 'O=</destination/path>' in
kernel make commands. If you'll be routinely building multiple
configurations of the Linux kernel, it's good to have some
naming conventions for the build directory. For example,
to experiment with multiple target platforms but only one
processor configuration, we include just the platform name here:

$ mkdir build-xtav60

Let's start with the default kernel configuration for the Avnet board
(which works on both XTAV60 (LX60) and XTAV200 (LX200) boards)
as follows:

$ cd linux
$ make O=../build-xtav60 ARCH=xtensa KBUILD_DEFCONFIG=lx60_defconfig defconfig

This configures the kernel using the default configuration found in
arch/xtensa/configs/lx60_defconfig.

NOTE: This kernel configuration has nothing to do with Xtensa
processor configuration. That comes next.

Let's now customize this a little bit to select the correct Xtensa processor
configuration, and to bundle the root filesystem into the kernel:

$ make O=../build-xtav60 ARCH=xtensa menuconfig

Under '''General setup''',
make sure the '''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is enabled. Underneath that, edit '''Initramfs source file(s)''',
and enter the path to the cpio formatted root filesystem
generated by buildroot:

''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio.gz

(Don't forget to replace ''<workdir>'' with the appropriate full path
and ''<cname>'' with your Xtensa processor configuration name.)

Under '''Processor type and features''',
make sure the '''Xtensa Processor Configuration''' is correct and matches
the processor configuration name you used to build the toolchain with buildroot
(for example, ''dc232b'' for Diamond 232L Rev.B).
The kernel build selects a toolchain and processor variant specific headers
based on this selection.
If the desired processor configuration does not appear explicitly in the list,
simply select '''Custom Xtensa processor configuration''' and enter the
processor configuration name (all lowercase) into the next menu parameter,
'''Xtensa Processor Custom Variant Name'''.

Back in the main menu, under '''Platform options''', make sure the
'''CPU clock rate''' entry is set correctly according to the following table:

{| border="1" style="text-align:center; margin: 1em auto 1em auto"
|-
! Board !! Frequency selected in XPG (MHz) !! ''CPU clock rate'' setting (kHz)
|-
|rowspan="3"| XTAV60 (LX60)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV110 (LX110)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV200 (LX200)
| 30 || 31250
|-
| 40 || 41667
|-
| 50 || 50000
|-
|}

Exit menuconfig, saving your configuration changes.

Backup your configuration outside the build directory. For example:

$ cp ../build-xtav60/.config config.xtav60.saved

If you do a clean rebuild of the kernel (e.g., "rm -rf ../build-xtav60")
you can now configure it with simply:
$ mkdir ../build-xtav60 ; cp config.xtav60.saved ../build-xtav60/.config
Of course if you update the kernel, you'll probably again have to do:
$ make O=../build-xtav60 ARCH=xtensa menuconfig
and save a new copy of your configuration.

=== Build the kernel ===

$ make O=../build-xtav60 ARCH=xtensa

The build will issue a few warnings which are normal.
Once complete, the bootable image is in:
<workdir>/build-xtav60/arch/xtensa/boot/Image.elf
and the uncompressed ELF file containing kernel symbols is in:
<workdir>/build-xtav60/vmlinux
There is also a RedBoot bootable image (if you use RedBoot) in:
<workdir>/build-xtav60/arch/xtensa/boot/zImage.redboot

=== Install Xtensa Tools for the selected core ===

If you opt to download the kernel over OCD, you need <tt>xt-gdb</tt>
which is part of Tensilica's Xtensa Tools package. This must be obtained
from Tensilica, and is not the same toolchain as built by buildroot.
You also need to install the corresponding Tensilica core package,
so that the Xtensa Tools know about your particular configured
Tensilica core.

The toolchain built using buildroot can be configured to
include GDB, but that version of GDB does not support
communicating with Tensilica's Xtensa OCD Daemon, and
thus cannot be used to download the kernel over OCD.

In this example, it is assumed that the machine hosting the
Xtensa Tools has access to the <workdir> directory tree.

=== Install and setup the Xtensa OCD Daemon ===

Setup and connect your JTAG probe, etc.

=== Connect a terminal server ===

At 38400 bps 8N1 no flow control to the XTAV60 serial port.

=== Optionally, setup networking ===

This step is optional.

Setup the board's MAC address using dipswitches
(see XTAV60 or XTAV200 board docs as appropriate)
and connect the board to a network that has a
DHCP server that will respond to that MAC address.
If you don't do this step, you'll simply not have network
access, and the boot process will take a minute or so longer
while the kernel times out waiting for a BOOTP response.
You can edit the kernel configuration and rebuild the kernel
to avoid using bootp (in particular, remove "ip=bootp" from
the kernel cmdline).

=== Download and run the kernel ===

Reset the board (see board documentation).

Using Xtensa Tools, invoke:

$ xt-gdb <workdir>/build-xtav60/arch/xtensa/boot/Image.elf

(xt-gdb) target remote <ocdhost>:20000 0
(xt-gdb) reset
(xt-gdb) load
(xt-gdb) set $pc = &_ResetVector
(xt-gdb) symbol-file <workdir>/build-xtav60/vmlinux
(xt-gdb) c

where <ocdhost> is the IP address or DNS name of the machine
running the Xtensa OCD daemon. The Linux kernel should
start booting as soon as 'c' (continue) is executed.

You should eventually get a login prompt.
Just login as root (no password).

Try various Linux commands. Look at <tt>/bin</tt>,
<tt>/sbin</tt>, <tt>/usr/bin</tt>, etc to see what's available.

Note: no need to setup an NFS or TFTP server. The filesystem
is contained within the kernel image. You may be able to mount
other filesystems over NFS though, if you wish, after booting.

=== Mounting the Root Filesystem Over NFS ===

If you build more than the minimal set of packages using
buildroot, the root filesystem can easily grow too large to
fit comfortably (or at all) inside the kernel. In this case,
rather than follow the instructions exactly as above,
you'll want to mount the root filesystem over NFS.

You may also want to mount the root filesystem over NFS to
make changes to the filesystem persistent across runs and
accessible from your development host.

First you need to install the root filesystem generated
using buildroot, to a machine that can serve it over NFS.
Assuming this machine runs Linux, one way to install it is
as follows:

mkdir ''<exportpath>''
cd ''<exportpath>''
sudo cpio -i -d -m -F ''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio --no-absolute-filenames

You then need to enable the NFS server on your system
(if not already active), and export this filesystem.
How you do this depends on your host Linux distribution.
For example, on some Fedora releases, one might:

* add the export path to <tt>/etc/exports</tt> using a line such as

''<exportpath>'' *(rw,sync,no_root_squash,no_all_squash)

* turn on the NFS server if needed:

sudo /sbin/chkconfig nfs on

* tell the NFS server about the new exported filesystem

sudo /usr/sbin/exportfs -a
sudo /usr/sbin/exportfs -r

Second, follow the instructions in the previous sections,
then configure the kernel again as follows.

Under '''General setup''', make sure the
'''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is disabled (rather than enabled as done in previous sections).

Under '''Platform options''', under the line '''Default bootloader kernel arguments''',
select the boot parameters line and set it to something like this:

console=ttyS0,38400 ip=dhcp root=/dev/nfs rw nfsroot=''<server_ip>'':''<exportpath>''

where ''<server_ip>'' is the IP address of your NFS server, and ''<exportpath>''
is the exported filesystem path.

Save this configuration, rebuild the kernel, and follow the
instructions in previous sections to download and run the kernel.
If everything goes well and is setup correctly, your kernel should
now boot with a root filesystem mounted over NFS.

== Build and Run a Linux Kernel on the Instruction Set Simulator (ISS) ==

You can build and run a Linux kernel in the Xtensa Instruction Set
Simulator (ISS). The following instructions have only been tried
with an ISS from the RB-2008.3 release of Xtensa Tools. Bear in
mind that the XTAV60 port is likely much more stable than the ISS port
of Linux at this point in time.

Note: Depending on your host OS version, you may need to install
Xtensa Tools on a separate machine.

=== Configure and Build the Kernel for ISS ===

Repeat all the same instructions as above for building the kernel for the
XTAV60 board, except that when initially configuring the kernel,
start from the ISS platform template instead:

$ mkdir build-iss
$ cd linux
$ make O=../build-iss ARCH=xtensa KBUILD_DEFCONFIG=iss_defconfig defconfig

This configures the kernel using the default configuration found in
arch/xtensa/configs/iss_defconfig.

Also, when running menuconfig:

$ make O=../build-iss ARCH=xtensa menuconfig

in addition to setting up the initramfs filesystem, do the following.
Under '''Bus Options''', deselect '''PCI support'''.
Under '''Platform Options''', deselect '''Default bootloader kernel arguments'''.

Continue configuring and building the kernel as usual.

=== Run the Kernel on ISS ===

Using Xtensa Tools, invoke:

$ xt-gdb <workdir>/build-iss/arch/xtensa/boot/Image.elf

(xt-gdb) target sim --turbo
(xt-gdb) target_memory_limit 134217728
(xt-gdb) symbol-file <workdir>/build-iss/vmlinux
(xt-gdb) run

Wait patiently while Linux boots ... (maybe a minute). The setting of the '''target_memory_limit'''
should match the PLATFORM_DEFAULT_MEM_SIZE defined in /arch/xtensa/platforms/iss/include/platform/hardware.h.
Currently this limit us 128MegBytes:

#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000 /* 13,4217,728 128M */

and we will be extending this shortly for the DC233 and it's V3 MMU.

Login as root (no password).

Note: Input via ISS is cooked, so everything typed gets echoed.
Also, time as reported by the kernel does not progress
according to true wall-clock time: it currently depends on
a simulated processor clock, which advances at various speeds
according to load.

Instructions for building and booting Linux

2010-12-01T22:46:33Z

Piet: /* Run the Kernel on ISS */

These instructions explain how to build a toolchain, root filesystem and kernel for Linux running on an Xtensa processor. These instructions apply specifically to the XTAV60 (LX60) board.

Some general notes on these instructions:

* They are a work in progress. If you are using the latest development sources, the build process may change, so you should be sure to get the latest version of this document at [http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions]. If you are using one of the development snapshot releases, you should use the version of the build instructions included with that snapshot.

* The following was tested on x86 machines running RedHat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3). It is expected to work on newer Fedora releases (e.g., was tested on FC6) but to maintain host compatibility with Xtensa Tools, it is best to avoid Fedora releases beyond FC5. Other host distributions likely work but have not been tested.
** '''NOTE:''' this assumes the default selection of packages in buildroot. Selecting extra packages may require a more recent host OS or more recent version of certain tools. For example, the default version of <tt>find</tt> on RHEL4 is too old to allow building all X11 packages in buildroot, so it is necessary to upgrade the host version of <tt>findutils</tt> on RHEL4 to build these packages.

* Lines prefixed with "sudo" need to be executed as root. The rest is best executed as a non-root user. (It is possible to install <tt>git</tt> as a non-root user if root access is an issue. How to do this isn't shown here.)

* Lines that set environment variables assume a Bourne compatible shell (e.g., /bin/sh or bash), but are easily adapted to other shells.

* Instructions are assumed executed all in order (e.g., commands assume current directory and environment variables set earlier).

== Setup your host system ==

If you are using one of the snapshot releases, you can skip this step.

If you want to work with the latest development sources, you will need
[[Installing GIT|<tt>git</tt> installed on your system]].

== Download buildroot and the Linux kernel ==

The following section describes how to download the latest
versions of buildroot and of the Linux kernel.
Skip this step if you are using one of the
[http://wiki.linux-xtensa.org/index.php/Buildroot_Snapshots snapshot releases].

For most users, just execute the following:

$ cd <workdir>
$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-xtensa.git buildroot
$ git clone git://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git linux

where <tt><workdir></tt> is the path to an empty directory on a disk with
at least 4 GB available space. You end up with the following file structure,
which is assumed by the rest of this document:

<workdir>/
/buildroot
/linux

The MASTER branch of the buildroot repository is often is a state of development.
It's recommended to use the last snapshot for application developers. In the
case of the HiFi-2 development board a 'snapshot_2+SMP' branch is recommended
in the currently experimental SMP git repository:

$ git clone git://git.linux-xtensa.org/git/buildroot/buildroot-HiFi2-Snapshot.git buildroot
$ git branch --track snapshot_2+SMP
$ git checkout snapshot_2+SMP

If you happen to have write access to either repository, or want more details,
see the [http://wiki.linux-xtensa.org/index.php/Repository_Access repository access] page.

== Install any required processor specific overlay ==

This step is required if you are targeting a custom Xtensa processor.
If you use a Diamond 232L Standard Core, you can skip this step.

To configure buildroot and the kernel to use a custom Xtensa processor
configuration, you need to overlay a set of files customized for your
processor configuration onto toolchain sources (gcc, binutils, gdb, etc)
and the Linux kernel. This process has been automated using a script
located in the buildroot source tree.
For usage information, you can invoke it without arguments:

$ cd <workdir>
$ ./buildroot/target/xtensa/xt-buildroot-overlay-install

which displays a help message similar to the following:

xt-buildroot-overlay-install version 1.3
Usage: xt-buildroot-overlay-install <parameters> [<options>]
Where <parameters> are:
-t file.tgz Specify path to the Xtensa Linux overlay tarball, typically
<xtensa_root>/src/xtensa-config-overlay.tar.gz
-b dir Path to the base of the buildroot source tree, in which
package specific overlay tarballs get installed.
-k dir Path to the base of the Linux kernel source tree, in which
the Linux kernel specific overlay gets installed.
-c config_name Name for the Xtensa processor configuration as it will be
known to the open source community. Must be a lowercase
identifier, starting with a letter, consisting of letters
and numbers and underscores, not ending with underscore
and not containing consecutive underscores. For examples:
dc232b , dc232b_be , mmubasele , fsf , s5000 .
-l long_name Long name for the Xtensa processor configuration, human-
readable with spaces etc allowed (must be quoted).
For example: 'Diamond 232L Standard Core Rev.B (LE)'
Try to keep it within approximately 40 characters.
And <options> are:
-f If package specific overlay tarballs already exist in
the destination source tree, overwrite them without asking.
--help Show this usage message.

Note that the Xtensa Linux overlay tarball MUST be obtained from an Xtensa
core package built using release RB-2008.3 or later.

Here is an example invocation of the overlay installation script:

$ ./buildroot/target/xtensa/xt-buildroot-overlay-install -t blinkcore-config-overlay.tar.gz \
-b ./buildroot -k ./linux -c superzip -l "ChipCorp SuperZIP Blink Accelerator Core"

The script extracts some relevant information from the overlay tarball,
presents it along with relevant parameters to the user, and prompts
for confirmation before proceeding.

The chosen processor name (-c option) must be unique among known Xtensa processors.
It is also probably wise to avoid names confusingly similar to other (non-Xtensa) processors.
If you expect at some point to contribute support for your custom processor to the
open-source community, this name will likely be long-lived.
(One way to contribute support for a custom processor might be to submit the overlay tarball
or files to the linux-xtensa.org maintainers.)

In the steps below, buildroot and the Linux kernel must be configured
(in their respective <code>''make menuconfig''</code> steps) to select
the <code>''custom''</code> Xtensa processor option.
This presents an extra configuration menu entry where you must provide
the name of the Xtensa processor. Set it to the same name
as was specified in the <code>-c</code> option above.

== Build a toolchain and root filesystem using buildroot ==

'''Note:''' for more details on generic buildroot topics not covered in this simple how-to,
see [http://buildroot.uclibc.org/ buildroot.uclibc.org].

=== Configure buildroot ===

The first time you configure buildroot, start with defaults for your Xtensa processor:

$ cd <workdir>/buildroot
$ ./target/xtensa/setup-config <corename>

where ''<corename>'' is the overlay name of your selected Xtensa or Diamond core
(e.g., '''dc232b'''). If you omit ''<corename>'', a help message and a list
of currently installed Tensilica core overlays is displayed.

Optionally, you can then customize your buildroot configuration, such as
selecting additional packages, setting various parameters, and so on.
The following make targets provide a ''curses'' (text-based graphical) interface
for configuring buildroot, the uClibc C library, and busybox, respectively.
('''Note:''' You need the <tt>TERM</tt> environment variable properly set for
these curses based tools to work.)

$ make menuconfig
$ make uclibc-menuconfig
$ make busybox-menuconfig

=== Build buildroot ===

Just type:

$ make

THIS WILL TAKE A LONG TIME (from about 30 minutes with defaults on a 3 GHz Pentium 4,
to perhaps an hour or many depending on your system and on whether
you enabled extra packages in your buildroot configuration).

Wait patiently for the build to complete. This builds an entire toolchain
as well as some basic packages, and constructs a root filesystem.
It might build many more packages if you selected them earlier with menuconfig.

==== If Something Goes Wrong ====

Perhaps you missed some step above and the build fails. Or you're just switching to a different processor configuration, or making some change with unknown dependencies. Either way, you'll probably need to fix the error and/or make the change, and redo the whole build. The above <tt>make</tt> command usually works fine if you
just added a package using menuconfig, but otherwise does not check many dependencies, so it will usually NOT rebuild things that depend on whatever you have fixed or changed. Here's one way to retry the make from scratch without having to wipe out the <tt>buildroot</tt> directory tree completely and start again from the git cloning.

$ rm -rf *build_xtensa* binaries
$ make

It is not necessary to empty the 'dl' subdirectory, which contains tarballs downloaded from the Internet, nor the .config file, which contains the buildroot configuration. Customizations to the uClibc and <tt>busybox</tt> configurations should have ended up getting saved in target/xtensa/uClibc.config and target/xtensa/busybox-config, respectively, so hopefully are preserved by the above sequence.

== Build and Run a Linux Kernel on the XTAV60 or XTAV200 Board ==

References to the ''XTAV60 board'' refer to the combination of
the Avnet [http://www.em.avnet.com/tensilica1 LX60 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX60 (XT-AV60) Board User's Guide''.

Similarly, references to the ''XTAV200 board'' refers the combination of
the Avnet [http://www.em.avnet.com/tensilica2 LX200 (Xilinx) Development Board]
and a Tensilica-provided FPGA bitstream containing a configured Tensilica
processor and basic peripheral IP. For more details, please refer to the
''Tensilica Avnet LX200 (XT-AV200) Board User's Guide''.

=== Configure the kernel ===

The kernel build is a two-step process: configure the kernel, and build it.
First, before we can do anything with the kernel, set your PATH to
point to the toolchain built using buildroot.

$ export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"

where ''<cname>'' is the name of the Xtensa processor configuration you selected
when building the toolchain (e.g., <code>dc232b</code>).

Now setup a destination for kernel builds.
We usually like to have the build directory separate from
the source directory, so we use 'O=</destination/path>' in
kernel make commands. If you'll be routinely building multiple
configurations of the Linux kernel, it's good to have some
naming conventions for the build directory. For example,
to experiment with multiple target platforms but only one
processor configuration, we include just the platform name here:

$ mkdir build-xtav60

Let's start with the default kernel configuration for the Avnet board
(which works on both XTAV60 (LX60) and XTAV200 (LX200) boards)
as follows:

$ cd linux
$ make O=../build-xtav60 ARCH=xtensa KBUILD_DEFCONFIG=lx60_defconfig defconfig

This configures the kernel using the default configuration found in
arch/xtensa/configs/lx60_defconfig.

NOTE: This kernel configuration has nothing to do with Xtensa
processor configuration. That comes next.

Let's now customize this a little bit to select the correct Xtensa processor
configuration, and to bundle the root filesystem into the kernel:

$ make O=../build-xtav60 ARCH=xtensa menuconfig

Under '''General setup''',
make sure the '''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is enabled. Underneath that, edit '''Initramfs source file(s)''',
and enter the path to the cpio formatted root filesystem
generated by buildroot:

''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio.gz

(Don't forget to replace ''<workdir>'' with the appropriate full path
and ''<cname>'' with your Xtensa processor configuration name.)

Under '''Processor type and features''',
make sure the '''Xtensa Processor Configuration''' is correct and matches
the processor configuration name you used to build the toolchain with buildroot
(for example, ''dc232b'' for Diamond 232L Rev.B).
The kernel build selects a toolchain and processor variant specific headers
based on this selection.
If the desired processor configuration does not appear explicitly in the list,
simply select '''Custom Xtensa processor configuration''' and enter the
processor configuration name (all lowercase) into the next menu parameter,
'''Xtensa Processor Custom Variant Name'''.

Back in the main menu, under '''Platform options''', make sure the
'''CPU clock rate''' entry is set correctly according to the following table:

{| border="1" style="text-align:center; margin: 1em auto 1em auto"
|-
! Board !! Frequency selected in XPG (MHz) !! ''CPU clock rate'' setting (kHz)
|-
|rowspan="3"| XTAV60 (LX60)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV110 (LX110)
| 30 || 33333
|-
| 40 || 40000
|-
| 50 || 50000
|-
|rowspan="3"| XTAV200 (LX200)
| 30 || 31250
|-
| 40 || 41667
|-
| 50 || 50000
|-
|}

Exit menuconfig, saving your configuration changes.

Backup your configuration outside the build directory. For example:

$ cp ../build-xtav60/.config config.xtav60.saved

If you do a clean rebuild of the kernel (e.g., "rm -rf ../build-xtav60")
you can now configure it with simply:
$ mkdir ../build-xtav60 ; cp config.xtav60.saved ../build-xtav60/.config
Of course if you update the kernel, you'll probably again have to do:
$ make O=../build-xtav60 ARCH=xtensa menuconfig
and save a new copy of your configuration.

=== Build the kernel ===

$ make O=../build-xtav60 ARCH=xtensa

The build will issue a few warnings which are normal.
Once complete, the bootable image is in:
<workdir>/build-xtav60/arch/xtensa/boot/Image.elf
and the uncompressed ELF file containing kernel symbols is in:
<workdir>/build-xtav60/vmlinux
There is also a RedBoot bootable image (if you use RedBoot) in:
<workdir>/build-xtav60/arch/xtensa/boot/zImage.redboot

=== Install Xtensa Tools for the selected core ===

If you opt to download the kernel over OCD, you need <tt>xt-gdb</tt>
which is part of Tensilica's Xtensa Tools package. This must be obtained
from Tensilica, and is not the same toolchain as built by buildroot.
You also need to install the corresponding Tensilica core package,
so that the Xtensa Tools know about your particular configured
Tensilica core.

The toolchain built using buildroot can be configured to
include GDB, but that version of GDB does not support
communicating with Tensilica's Xtensa OCD Daemon, and
thus cannot be used to download the kernel over OCD.

In this example, it is assumed that the machine hosting the
Xtensa Tools has access to the <workdir> directory tree.

=== Install and setup the Xtensa OCD Daemon ===

Setup and connect your JTAG probe, etc.

=== Connect a terminal server ===

At 38400 bps 8N1 no flow control to the XTAV60 serial port.

=== Optionally, setup networking ===

This step is optional.

Setup the board's MAC address using dipswitches
(see XTAV60 or XTAV200 board docs as appropriate)
and connect the board to a network that has a
DHCP server that will respond to that MAC address.
If you don't do this step, you'll simply not have network
access, and the boot process will take a minute or so longer
while the kernel times out waiting for a BOOTP response.
You can edit the kernel configuration and rebuild the kernel
to avoid using bootp (in particular, remove "ip=bootp" from
the kernel cmdline).

=== Download and run the kernel ===

Reset the board (see board documentation).

Using Xtensa Tools, invoke:

$ xt-gdb <workdir>/build-xtav60/arch/xtensa/boot/Image.elf

(xt-gdb) target remote <ocdhost>:20000 0
(xt-gdb) reset
(xt-gdb) load
(xt-gdb) set $pc = &_ResetVector
(xt-gdb) symbol-file <workdir>/build-xtav60/vmlinux
(xt-gdb) c

where <ocdhost> is the IP address or DNS name of the machine
running the Xtensa OCD daemon. The Linux kernel should
start booting as soon as 'c' (continue) is executed.

You should eventually get a login prompt.
Just login as root (no password).

Try various Linux commands. Look at <tt>/bin</tt>,
<tt>/sbin</tt>, <tt>/usr/bin</tt>, etc to see what's available.

Note: no need to setup an NFS or TFTP server. The filesystem
is contained within the kernel image. You may be able to mount
other filesystems over NFS though, if you wish, after booting.

=== Mounting the Root Filesystem Over NFS ===

If you build more than the minimal set of packages using
buildroot, the root filesystem can easily grow too large to
fit comfortably (or at all) inside the kernel. In this case,
rather than follow the instructions exactly as above,
you'll want to mount the root filesystem over NFS.

You may also want to mount the root filesystem over NFS to
make changes to the filesystem persistent across runs and
accessible from your development host.

First you need to install the root filesystem generated
using buildroot, to a machine that can serve it over NFS.
Assuming this machine runs Linux, one way to install it is
as follows:

mkdir ''<exportpath>''
cd ''<exportpath>''
sudo cpio -i -d -m -F ''<workdir>''/buildroot/binaries/uclibc/rootfs.xtensa_''<cname>''.cpio --no-absolute-filenames

You then need to enable the NFS server on your system
(if not already active), and export this filesystem.
How you do this depends on your host Linux distribution.
For example, on some Fedora releases, one might:

* add the export path to <tt>/etc/exports</tt> using a line such as

''<exportpath>'' *(rw,sync,no_root_squash,no_all_squash)

* turn on the NFS server if needed:

sudo /sbin/chkconfig nfs on

* tell the NFS server about the new exported filesystem

sudo /usr/sbin/exportfs -a
sudo /usr/sbin/exportfs -r

Second, follow the instructions in the previous sections,
then configure the kernel again as follows.

Under '''General setup''', make sure the
'''Initial RAM filesystem and RAM disk (initramfs/initrd) support'''
entry is disabled (rather than enabled as done in previous sections).

Under '''Platform options''', under the line '''Default bootloader kernel arguments''',
select the boot parameters line and set it to something like this:

console=ttyS0,38400 ip=dhcp root=/dev/nfs rw nfsroot=''<server_ip>'':''<exportpath>''

where ''<server_ip>'' is the IP address of your NFS server, and ''<exportpath>''
is the exported filesystem path.

Save this configuration, rebuild the kernel, and follow the
instructions in previous sections to download and run the kernel.
If everything goes well and is setup correctly, your kernel should
now boot with a root filesystem mounted over NFS.

== Build and Run a Linux Kernel on the Instruction Set Simulator (ISS) ==

You can build and run a Linux kernel in the Xtensa Instruction Set
Simulator (ISS). The following instructions have only been tried
with an ISS from the RB-2008.3 release of Xtensa Tools. Bear in
mind that the XTAV60 port is likely much more stable than the ISS port
of Linux at this point in time.

Note: Depending on your host OS version, you may need to install
Xtensa Tools on a separate machine.

=== Configure and Build the Kernel for ISS ===

Repeat all the same instructions as above for building the kernel for the
XTAV60 board, except that when initially configuring the kernel,
start from the ISS platform template instead:

$ mkdir build-iss
$ cd linux
$ make O=../build-iss ARCH=xtensa KBUILD_DEFCONFIG=iss_defconfig defconfig

This configures the kernel using the default configuration found in
arch/xtensa/configs/iss_defconfig.

Also, when running menuconfig:

$ make O=../build-iss ARCH=xtensa menuconfig

in addition to setting up the initramfs filesystem, do the following.
Under '''Bus Options''', deselect '''PCI support'''.
Under '''Platform Options''', deselect '''Default bootloader kernel arguments'''.

Continue configuring and building the kernel as usual.

=== Run the Kernel on ISS ===

Using Xtensa Tools, invoke:

$ xt-gdb <workdir>/build-iss/arch/xtensa/boot/Image.elf

(xt-gdb) target sim --turbo
(xt-gdb) target_memory_limit 134217728
(xt-gdb) symbol-file <workdir>/build-iss/vmlinux
(xt-gdb) run

Wait patiently while Linux boots ... (maybe a minute). The setting of the '''target_memory_limit'''
should match the PLATFORM_DEFAULT_MEM_SIZE defined in /arch/xtensa/platforms/iss/include/platform/hardware.h.
Currently this is:

#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000 /* 13,4217,728 128M */

Login as root (no password).

Note: Input via ISS is cooked, so everything typed gets echoed.
Also, time as reported by the kernel does not progress
according to true wall-clock time: it currently depends on
a simulated processor clock, which advances at various speeds
according to load.

Setting up U-Boot

2010-11-25T09:06:01Z

Piet: /* LX60 and LX200 U-Boot Installation (LX110 in Progress) */

== LX60 and LX200 U-Boot Installation (LX110 in Progress) ==

''('''News:''' U-Boot for the new DC233, with the V3 MMU, is now working fine and checked into the master branch. Work is almost complete with the Linux 2.6.29-smp kernel, with
Linux now booting from this updated U-Boot. The kernel on the 'Initialize_MMU_Inside_vmlinux' branch seems to be working fine, and has survived 14 hours of stress testing so far.
Plain is to merge this and a few additional branches to the master branch and then move forward to a newer version of the Linux kernel.
'''Summary:'''

[http://www.denx.de/wiki/UBoot U-Boot] is a very popular boot loader; especially within the [http://elinux.org/Bootloader Embedded Linux community].
The U-Boot loader runs on the FPGA boards which are equipped with a dip switch, number 8, which can select where the memory location for the reset
vector (0XFE00,0000) comes from. With switch number 8 off the board will map the memory at the reset vector to a small block of SRAM located in the
I/O block with the UART and Ethernet buffer memory. When switch number 8 is on the Avnet boards map the beginning of the Flash Memory at 0XF800,000
to the reset vector at 0xFE00,000.

What we are going to do here is build a version of U-Boot for your Avnet board and Variant, install that ELF file into memory
with xt-gdb and run U-Boot. Then we are going to download a another copy of this identical program with '''tftp'''. The version we
are going to download is just the ELF file with the headers and debug information removed. It's just the actual bits that get
loaded into memory. For the new V3 MMU the default '''loadaddr''' is typically 0x20,0000 and for the older V2 MMU this is in the
Linux mapping equivalent, 0xD0200,0000. The default location can be change by setting the U-Boot 'loadaddr' environment variable
or by changing the variable '''CONFIG_SYS_LOAD_ADDR''' in the boards U-Boot config file.

Once the virgin copy of the U-Boot program has been loaded into memory, the Flash memory is un-protected and errasd, then the
memory with the U-Boot program in it is copied to the flash memory and protected. Next you will set dip switch 8 on, recycle
power on the board, and U-Boot will be accessible via the serial UART at 38400 baud. U-Boot works without any MMU mapping,
and should be fine on configurations without an MMU. Only an ethernet and serial interface are required.

'''Proceedure:'''

A local port to the Xtensa architecture is now available at linux-xtensa.org. See [http://git.linux-xtensa.org/cgi-bin/git.cgi?p=u-boot/u-boot-xtensa.git;a=summary U-Boot Sources (GIT Summary)]. Or, to access this tree using <tt>git</tt> directly, use something like:

$ '''git clone git://git.linux-xtensa.org/git/u-boot/u-boot-xtensa.git u-boot'''
$ '''cd u-boot'''

''('''Note:''' This path is subject to change.)''

The U-Boot git repository has a branch with a HiFi 2 snapshot made for
the LX200 [[SMP HiFi 2 Development Board]]. With this branch you can simply check
out the snapshot_2+SMP branch which includes the binaries which are discussed below:

$ '''git clone git://git.linux-xtensa.org/git/u-boot/u-boot-xtensa.git u-boot'''
$ '''cd u-boot'''
$ '''git branch --track snapshot_2+SMP origin/snapshot_2+SMP'''
$ '''git checkout snapshot_2+SMP'''

$ '''ls -l u-boot u-boot.bin tools/mkimage'''
-rwxr-xr-x 1 piet tensilica 45016 2009-12-07 19:40 tools/mkimage [This is a small program you need to put in your search path to build kernel U-Boot images]
-rwxr-xr-x 1 piet tensilica 635339 2009-12-07 19:40 u-boot [Started with xt-gdb to bring up the 1st instance of a HiFi 2 U-Boot]
-rwxr-xr-x 1 piet tensilica 144944 2009-12-07 19:40 u-boot.bin [Loaded by the 1st instance of U-Boot, it's a HiFi2 version of u-boot that will be put in flash]
$

Unless you are using a U-Boot snapshot you need to build U-Boot for which you must have built the Buildroot toolchain for XTensa core.
Set your PATH to point to the toolchain built using buildroot. For example:

$ '''export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"'''

where '''<cname>''' is the name of the Xtensa core variant you wish to build for (e.g., <tt>dc232b</tt> <tt>dc233c</tt>).

To build U-Boot, use the cloned git tree pulled above, you should be at the top level of the tree in the '''u-boot''' directory , then configure it for your board and Xtensa core variant as follows:

make distclean
make <cname>'''_<board>_'''config
'dc232b'dc
This should only take a few seconds. For example, to build U-boot for the 'xtav60' board and the older 'dc232b' core with the V2 MMU type:

$ '''cd u-boot'''
$ '''make dc232b_xtav60_config'''

or for the new 'dc233c' core with the new V3 MMU type:

$ '''make dc233c_xtav60_config'''

or for a 'xtav200' board type with the new 'dc233c' core type:

$ '''make dc233c_xtav110_config'''

or for a 'xtav200' board type with the new 'dc233c' core type:

$ '''make dc233c_xtav200_config'''

or for the snapshot_2+SMP branch you can also build U-Boot for the HiFi 2 core:

$ '''make test_mmuhifi_c3_xtav200_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

Only boards and core variants currently supported in the tree can be built out of the box. Headers for supported cores can be found in the tree under <tt>include/asm-xtensa/variant-<cname></tt>. The core specific headers are described in the <tt>doc/README.xtensa</tt> file. To support a new core, these headers must be copied from the overlay in the same way as for the linux kernel.

After the configuration step, to actually build U-Boot, simply:

$ '''make all''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

This will take a quite a few minutes.

This is likely a good time to copy '''mkimage''' to your ${HOME}/bin directory
for later use while building the Linux kernel. The '''mkimage''' program was
just built in the tool directory by the above '''make all'''.

$ '''cd tools'''
$ '''cp mkimage ~/bin''' [NOTE: '''mkimage''' should be in your search PATH while building the Linux kernel]

Next, start xt-gdb and load u-boot from the top of the git repository:

$ '''xt-gdb -n''' [NOTE: Even with the HiFi 2 snapshot_2+SMP branch you still may have to put U-Boot on the board]
(xt-gdb) '''file u-boot'''
(xt-gdb) '''target remote localhost:20000 0'''
(xt-gdb) '''reset'''
(xt-gdb) '''load'''
(xt-gdb) '''break panic'''
(xt-gdb) '''continue'''

Hopefully U-Boot will start, and display on the LCD in the case of a LX60.

U-Boot 50.00 Mhz

Often you will be starting with the boards flash in an unknown state and it's best to unprotect and erase the entire flash. Just type '''protect off all''' followed by '''erase all''':

U-Boot> '''protect off all'''
Un-Protect Flash Bank # 1
................................................................................................................................... done
U-Boot> '''erase all'''
Erase Flash Bank # 1
..........................................................................................................
Flash erase timeout at address f8d40000 da0
Flash erase error at address f8d40000
........................ done
U-Boot>

The timeout and error messages are likley just warning messages and you board has been errased. You can see that with the flash info command '''flinfo'''. Below is an example with a LX200 board, which has a much larger flash than the smaller LX60:

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
F8000000 E F8020000 E F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E F8FE0000 E F8FE8000 E F8FF0000 E
F8FF8000 E
U-Boot>

The new LX110 looks very similar to the LX200, also with with 16Mb of Flash:

U-Boot> flinfo

Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 32 bytes

Sector Start Addresses:
F8000000 E F8020000 E F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E F8FE0000 E

Now set your preliminary U-Boot environment variables to point to your TFTP server so we can download yet another copy of U-Boot. At Tensilica we use a machine in the RTOS group called rtos-lab2. Folks using the [[SMP HiFi 2 Development Board]] likely have set up their workstation with a TFTP server.

U-Boot> '''setenv serverip 192.168.11.78''' rtos-lab2
or
U-Boot> '''setenv serverip 192.168.11.55''' pdelaney_fc9

U-Boot> '''setenv ipaddr 192.168.11.95''' I/P address of RTOS5, Piet's LX60; MAC: 00:05:C2:13:6f:0a

U-Boot> '''setenv bootfile u-boot.bin'''
U-Boot> '''saveenv'''
Saving Environment to Flash...
.... done
Un-Protected 4 sectors
Erasing Flash...
.... done
Erased 4 sectors
Writing to Flash... done
.... done
Protected 4 sectors
U-Boot>

Next, download '''u-boot.bin''' from the tftp server using the info we just entered into U-Boot's enviroment variables.
Here for example is the case for a LX60 running the HiFi-2 Bitstream with the older V2 MMU. Note that it starts up
in the D-gazillion (0XD0000000) region:

U-Boot> '''tftpboot'''
TFTP from server 192.168.11.78; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0xd2000000
Loading: T ########
done
Bytes transferred = 107592 (1a448 hex)

For the V3 MMU U-Boot is loaded from host pdelaney_fc9 into memory with virtual == physical. Here is a DC233L, with V3 MMU, example:

U-Boot> '''tftpboot'''
Using open_ethernet device
TFTP from server 192.168.11.55; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: T ########
done
Bytes transferred = 109964 (1ad8c hex)
U-Boot>

Now things get a bit tricky here for the LX60. The FLASH has '''Two sizes of Flash Sectors'''.
The first 8 sectors are small 0x2000 (8KB) and apparently intended for parameters. The rest
of the 4MB flash is composed of larger 0x10000 (64KB) sectors. Our code doesn't differentiate
between the sectors and the LX60 hardware is going to map 0XF800,0000 to 0XFE00,0000 so this
makes us use of all 8 of the 8KB sectors and the 1st 64KB sector at F8010000. So we are going
to flash up to F801FFFF below.

On a LX200 we have much more space and can easily fit a version of U-boot that has been compiled without optimization, make debugging much easier.
So in this case the image is a bit larger, but relatively similar to the LX60 (2 sectors):

U-Boot> '''tftpboot'''
Using open_ethernet device
TFTP from server 192.168.11.78; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0xd2000000
Loading: ###############
done
Bytes transferred = 205852 (3241c hex)
U-Boot>

On a LX110 we have less memory than an LX60, but FLASH sectors like the LX200. It turns out that the u-boot image
compiled with optimization is just a bit larger than 1 sector, so like the LX200 we will need to write u-boot
into two sectors. Here's and example tftpboot of U-Bot for the LX110:

U-Boot> tftpboot
Using open_ethernet device
TFTP from server 192.168.11.55; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: ##########
done
Bytes transferred = 144956 (2363c hex)
U-Boot>

Note that for both the LX200 and the LX60 that the image size, '''(3241c hex)''' in this case, is a bit less than 0x40000 or 10 sectors,
so turn off protection on the 1st 11 sectors and
erase the current contents.

For the '''LX60''' you do this:

U-Boot> '''protect off F8000000 F801FFFF'''
... done
Un-Protected 9 sectors
U-Boot> '''erase F8000000 F801FFFF'''
erase F8000000 F801FFFF
... done
Erased 9 sectors
U-Boot>

For the '''LX200''' and the '''LX110''' the starting address '''(F8000000)''' is the same as with the LX60 but the last address '''(F803FFFF)''' is 'twice' as high:

U-Boot> '''protect off F8000000 F803FFFF'''
... done
Un-Protected 2 sectors
U-Boot> '''erase F8000000 F803FFFF'''
Erased 2 sectors
U-Boot>

Now copy the the image of u-boot.bin in memory to the flash. For the XL60 with the '''OLD''' V2 MMU you copy 0x20000
bytes from 0xd2000000 to 0XF8000000:

U-Boot> '''cp.b d2000000 F8000000 20000'''
Copy to Flash... done

For the LX60 with the '''NEW''' V3 MMU you copy 0x24000 bytes from 0x2000000 to F8000000:

U-Boot> '''cp.b 2000000 F8000000 20000'''
Copy to Flash... done

For the LX200 you copy 0x40000 bytes from 0xd2000000 to 0XF8000000...0XF803FFFF:

U-Boot> '''cp.b d2000000 F8000000 40000'''
Copy to Flash... done

For the LX110 with a V3-MMU you copy 0x40000 bytes from 0x2000000 to F8000000:
U-Boot> cp.b 2000000 F8000000 40000
Copy to Flash... done

Finally we protect these sectors so that U-Boot isn't easily erased by accident.
Below is what it looks like on a LX60 with the New V3 MMU with a subsequent display of the flash info:

U-Boot> '''cp.b 2000000 F8000000 2000'''
Copy to Flash... done
U-Boot> flinfo

Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x2257
Erase timeout: 8192 ms, write timeout: 1 ms

Sector Start Addresses:
'''F8000000 F8002000 F8004000 F8006000 F8008000'''
'''F800A000 F800C000 F800E000 F8010000 '''F8020000 E
F8030000 E F8040000 E F8050000 E F8060000 E F8070000 E
F8080000 E F8090000 E F80A0000 E F80B0000 E F80C0000 E
F80D0000 E F80E0000 E F80F0000 E F8100000 E F8110000 E
F8120000 E F8130000 E F8140000 E F8150000 E F8160000 E
F8170000 E F8180000 E F8190000 E F81A0000 E F81B0000 E
F81C0000 E F81D0000 E F81E0000 E F81F0000 E F8200000 E
F8210000 E F8220000 E F8230000 E F8240000 E F8250000 E
F8260000 E F8270000 E F8280000 E F8290000 E F82A0000 E
F82B0000 E F82C0000 E F82D0000 E F82E0000 E F82F0000 E
F8300000 E F8310000 E F8320000 E F8330000 E F8340000 E
F8350000 E F8360000 E F8370000 E F8380000 E F8390000 E
F83A0000 E F83B0000 E F83C0000 E F83D0000 E F83E0000
'''F83F0000 RO'''
U-Boot> '''protect on F8000000 F801FFFF'''
.......... done
Protected 9 sectors
U-Boot>

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x2257
Erase timeout: 8192 ms, write timeout: 1 ms

Sector Start Addresses:
'''F8000000 RO F8002000 RO F8004000 RO F8006000 RO F8008000 RO
F800A000 RO F800C000 RO F800E000 RO F8010000 RO''' F8020000 E
F8030000 E F8040000 E F8050000 E F8060000 E F8070000 E
F8080000 E F8090000 E F80A0000 E F80B0000 E F80C0000 E
F80D0000 E F80E0000 E F80F0000 E F8100000 E F8110000 E
F8120000 E F8130000 E F8140000 E F8150000 E F8160000 E
F8170000 E F8180000 E F8190000 E F81A0000 E F81B0000 E
F81C0000 E F81D0000 E F81E0000 E F81F0000 E F8200000 E
F8210000 E F8220000 E F8230000 E F8240000 E F8250000 E
F8260000 E F8270000 E F8280000 E F8290000 E F82A0000 E
F82B0000 E F82C0000 E F82D0000 E F82E0000 E F82F0000 E
F8300000 E F8310000 E F8320000 E F8330000 E F8340000 E
F8350000 E F8360000 E F8370000 E F8380000 E F8390000 E
F83A0000 E F83B0000 E F83C0000 E F83D0000 E F83E0000
'''F83F0000 RO'''
U-Boot>

For the '''LX110''' with the '''V3-MMU''' here's what the flash info looks like after we
protect the first two sectors with U-Boot copied to it:

U-Boot> '''protect on F8000000 F803FFFF'''
Protected 2 sectors
U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 32 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E '''F8FE0000 RO'''
U-Boot> help

Below is what it looks like on a '''LX200''' with the '''V2 MMU''' with a subsequent display of the flash info.
Notice that the Flash Sectors are 10X as large on the LX200:

U-Boot> '''protect on F8000000 F802FFFF'''
.. done
Protected 2 sectors
U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E '''F8FE0000 RO F8FE8000 RO F8FF0000 RO'''
'''F8FF8000 RO'''
U-Boot>

Note that the U-Boot '''saveenv''' command Erased and protected the last four sectors
of this LX200.

On both the LX60 and the LX200 now move DIP switch 8 to the ON position, on the LX110 move DIP switch 4 to the ON position.
Next, power cycle the board. On the LX60 you should see U-boot in the LCD display.

The '''LX60''' with the new '''V3 MMU''' the serial console should print something like the following:

U-Boot 2009.08-dirty (Sep 10 2010 - 18:23:26)

CPU: Xtensa dc233c at 50.00 MHz
Board: XT-AV60: Avnet board + Xilinx LX60 FPGA + Tensilica bitstream
SysRAM: 64 MB
Flash: 4 MB
In: serial
Out: serial
Err: serial
MAC: 00:50:C2:13:6f:0a
IP: 192.168.11.95
open_ethernet
U-Boot>

On the '''LX110''' with the new '''V3 MMU''' the serial console should print something like the following:

U-Boot 2009.08-dirty (Nov 15 2010 - 23:04:45)

CPU: Xtensa dc233c at 50.00 MHz
Board: XT-AV110: Avnet board + Xilinx LX110 FPGA + Tensilica bitstream
SysRAM: 48 MB
Flash: 16 MB
In: serial
Out: serial
Err: serial
MAC: 00:50:C2:13:6f:00
IP: 192.168.11.95
open_ethernet
U-Boot>

On the '''LX200''', shown below with the old V2 MMU, you should see something like the following. In this case we also show the flash info command, '''flinfo''', being invoked just after booting U-Boot:

U-Boot 2009.08-dirty (Nov 15 2010 - 23:04:45)

CPU: Xtensa test_mmuhifi_c3 at 41.6777 MHz
Board: XT-AV200: Avnet board + Xilinx LX200 FPGA + Tensilica bitstream
SysRAM: 96 MB
Flash: 16 MB
In: serial
Out: serial
Err: serial
MAC:
IP: 192.168.11.95
U-Boot>

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E RO F8060000 E RO F8080000 E RO
F80A0000 E RO F80C0000 E RO F80E0000 E RO F8100000 E RO F8120000 E RO
F8140000 E RO F8160000 E RO F8180000 E RO F81A0000 E RO F81C0000 E RO
F81E0000 E RO F8200000 E RO F8220000 E RO F8240000 E RO F8260000 E RO
F8280000 E RO F82A0000 E RO F82C0000 E RO F82E0000 E RO F8300000 E RO
F8320000 E RO F8340000 E RO F8360000 E RO F8380000 E RO F83A0000 E RO
F83C0000 E RO F83E0000 E RO F8400000 E RO F8420000 E RO F8440000 E RO
F8460000 E RO F8480000 E RO F84A0000 E RO F84C0000 E RO F84E0000 E RO
F8500000 E RO F8520000 E RO F8540000 E RO F8560000 E RO F8580000 E RO
F85A0000 E RO F85C0000 E RO F85E0000 E RO F8600000 E RO F8620000 E RO
F8640000 E RO F8660000 E RO F8680000 E RO F86A0000 E RO F86C0000 E RO
F86E0000 E RO F8700000 E RO F8720000 E RO F8740000 E RO F8760000 E RO
F8780000 E RO F87A0000 E RO F87C0000 E RO F87E0000 E RO F8800000 E RO
F8820000 E RO F8840000 E RO F8860000 E RO F8880000 E RO F88A0000 E RO
F88C0000 E RO F88E0000 E RO F8900000 E RO F8920000 E RO F8940000 E RO
F8960000 E RO F8980000 E RO F89A0000 E RO F89C0000 E RO F89E0000 E RO
F8A00000 E RO F8A20000 E RO F8A40000 E RO F8A60000 E RO F8A80000 E RO
F8AA0000 E RO F8AC0000 E RO F8AE0000 E RO F8B00000 E RO F8B20000 E RO
F8B40000 E RO F8B60000 E RO F8B80000 E RO F8BA0000 E RO F8BC0000 E RO
F8BE0000 E RO F8C00000 E RO F8C20000 E RO F8C40000 E RO F8C60000 E RO
F8C80000 E RO F8CA0000 E RO F8CC0000 E RO F8CE0000 E RO F8D00000 E RO
F8D20000 E RO F8D40000 E RO F8D60000 E RO F8D80000 E RO F8DA0000 E RO
F8DC0000 E RO F8DE0000 E RO F8E00000 E RO F8E20000 E RO F8E40000 E RO
F8E60000 E RO F8E80000 E RO F8EA0000 E RO F8EC0000 E RO F8EE0000 E RO
F8F00000 E RO F8F20000 E RO F8F40000 E RO F8F60000 E RO F8F80000 E RO
F8FA0000 E RO F8FC0000 E RO '''F8FE0000 RO F8FE8000 RO F8FF0000 RO'''
'''F8FF8000 RO'''
U-Boot>

Note that the 1st two sectors with U-Boot saved in them came up as not being erased ('''E''') but that all sectors came up Read Only ('''RO''').
Same with the last four sectors that the U-Boot '''saveenv''' command Erased. This is likely a '''bug''' on the LX200 boards with some preliminary investigation.
We will be discussing this with the U-Boot developers sometime in the future prior to pushing our U-boot changes upstream.

If U-Boot fails to boot ya might try making sure your U-Boot '''serverip''' environment variable matches the address of the tftp server where
you have copied your '''u-boot.bin''' file to and comparing the bits in the flash that got mapped to 0xfe00,0000 to what in the file:

u-boot]$ '''od -t x4 u-boot.bin | more'''
.0000000 00000206 fe000040 ffffffff a0fffe21
.0000020 00000002 fe01ad14 fe01ad8c 03f95030
.0000040 03f9aa78 04000000 00040003 03f8147c
.0000060 03f81418 00000000 00000000 00000000
.0000100 5300000c 13a00013 4800130c 13493013
.0000120 0c130200 13e62032 22002010 a03200a0
.0000140 1d837680 82037282 72822372 63728243
.0000160 72007272 72720872 18727210 2201d222
.0000200 020c80c2 3d80a032 1d8376f0 d20372d2
.0000220 72d22372 6372d243 f20072f2 72f20872
.0000240 1872f210 2201d222 200080c2 ffd92100
.0000260 37ffda31 02481d12 22681258 145722cb
.0000300 ee1467f1 664b0678 444b0479 06f43457
.0000320 0000fff8 31ffd221 4320ffd2 40443bc0
.0000340 84764142 4b020903 32020c22 837680a0
.0000360 04728211 82247282 72824472 01d22264
.0000400 1180c222 c821ffc8 13e620ff 41002010
.0000420 04d0ffc7 ffc64100 fffffd86 1049c500
.0000440 e52049d5 49f53049 00003400 00000000
.0000460 00000000 00000000 00000000 00000000
.
.(gdb) '''x/100x 0xfe000000'''
.0xfe000000 <_ResetVector>: 0x00000206 0xfe000040 0xffffffff 0xa0fffe21
.0xfe000010 <_ResetVector+16>: 0x00000002 0xfe01ad14 0xfe01ad8c 0x03f95030
.0xfe000020 <_ResetVector+32>: 0x03f9aa78 0x04000000 0x00040003 0x03f8147c
.0xfe000030 <_ResetVector+48>: 0x03f81418 0x00000000 0x00000000 0x00000000
.0xfe000040 <_start>: 0x5300000c 0x13a00013 0x4800130c 0x13493013
.0xfe000050 <_start+16>: 0x0c130200 0x13e62032 0x22002010 0xa03200a0
.0xfe000060 <_start+32>: 0x1d837680 0x82037282 0x72822372 0x63728243
.0xfe000070 <_start+48>: 0x72007272 0x72720872 0x18727210 0x2201d222
.0xfe000080 <_start+64>: 0x020c80c2 0x3d80a032 0x1d8376f0 0xd20372d2
.0xfe000090 <_start+80>: 0x72d22372 0x6372d243 0xf20072f2 0x72f20872
.0xfe0000a0 <_start+96>: 0x1872f210 0x2201d222 0x200080c2 0xffd92100
.0xfe0000b0 <_start+112>: 0x37ffda31 0x02481d12 0x22681258 0x145722cb
.0xfe0000c0 <_start+128>: 0xee1467f1 0x664b0678 0x444b0479 0x06f43457
.0xfe0000d0 <_start+144>: 0x0000fff8 0x31ffd221 0x4320ffd2 0x40443bc0
.0xfe0000e0 <_start+160>: 0x84764142 0x4b020903 0x32020c22 0x837680a0
.0xfe0000f0 <_start+176>: 0x04728211 0x82247282 0x72824472 0x01d22264
.0xfe000100 <_start+192>: 0x1180c222 0xc821ffc8 0x13e620ff 0x41002010
.0xfe000110 <_reset+1>: 0x04d0ffc7 0xffc64100 0x00fffd86 0x1049c500
.0xfe000120: 0xe52049d5 0x49f53049 0x00003400 0x00000000
.0xfe000130: 0x00000000 0x00000000 0x00000000 0x00000000
.(gdb)

Further details on U-Boot in general are in the generic <tt>README</tt> at the top of the U-Boot tree. Details specific to the Xtensa architecture are in <tt>doc/README.xtensa</tt>. Details specific to a board are in <tt>board[/<family>]/<board>/README</tt> (for example <tt>board/avnet/xtav60/README</tt>).

Setting up U-Boot

2010-11-24T00:07:57Z

Piet: /* LX60 and LX200 U-Boot Installation (LX110 in Progress) */

== LX60 and LX200 U-Boot Installation (LX110 in Progress) ==

''('''News:''' U-Boot for the new DC233, with the V3 MMU, is now working fine and checked into the master branch. Work is almost complete with the Linux 2.6.29-smp kernel, with
Linux now booting from this updated U-Boot. The kernel on the 'Initialize_MMU_Inside_vmlinux' branch seems to be working fine, and has survived 14 hours of stress testing so far.
Plain is to merge this and a few additional branches to the master branch and then move forward to a newer version of the Linux kernel.
'''Summary:'''

[http://www.denx.de/wiki/UBoot U-Boot] is a very popular boot loader; especially within the [http://elinux.org/Bootloader Embedded Linux community].
The U-Boot loader runs on the FPGA boards which are equipped with a dip switch, number 8, which can select where the memory location for the reset
vector (0XFE00,0000) comes from. With switch number 8 off the board will map the memory at the reset vector to a small block of SRAM located in the
I/O block with the UART and Ethernet buffer memory. When switch number 8 is on the Avnet boards map the beginning of the Flash Memory at 0XF800,000
to the reset vector at 0xFE00,000.

What we are going to do here is build a version of U-Boot for your Avnet board and Variant, install that ELF file into memory
with xt-gdb and run U-Boot. Then we are going to download a another copy of this identical program with '''tftp'''. The version we
are going to download is just the ELF file with the headers and debug information removed. It's just the actual bits that get
loaded into memory. For the new V3 MMU the default '''loadaddr''' is typically 0x20,0000 and for the older V2 MMU this is in the
Linux mapping equivalent, 0xD0200,0000. The default location can be change by setting the U-Boot 'loadaddr' environment variable
or by changing the variable '''CONFIG_SYS_LOAD_ADDR''' in the boards U-Boot config file.

Once the virgin copy of the U-Boot program has been loaded into memory, the Flash memory is un-protected and errasd, then the
memory with the U-Boot program in it is copied to the flash memory and protected. Next you will set dip switch 8 on, recycle
power on the board, and U-Boot will be accessible via the serial UART at 38400 baud. U-Boot works without any MMU mapping,
and should be fine on configurations without an MMU. Only an ethernet and serial interface are required.

'''Proceedure:'''

A local port to the Xtensa architecture is now available at linux-xtensa.org. See [http://git.linux-xtensa.org/cgi-bin/git.cgi?p=u-boot/u-boot-xtensa.git;a=summary U-Boot Sources (GIT Summary)]. Or, to access this tree using <tt>git</tt> directly, use something like:

$ '''git clone git://git.linux-xtensa.org/git/u-boot/u-boot-xtensa.git u-boot'''
$ '''cd u-boot'''

''('''Note:''' This path is subject to change.)''

The U-Boot git repository has a branch with a HiFi 2 snapshot made for
the LX200 [[SMP HiFi 2 Development Board]]. With this branch you can simply check
out the snapshot_2+SMP branch which includes the binaries which are discussed below:

$ '''git clone git://git.linux-xtensa.org/git/u-boot/u-boot-xtensa.git u-boot'''
$ '''cd u-boot'''
$ '''git branch --track snapshot_2+SMP origin/snapshot_2+SMP'''
$ '''git checkout snapshot_2+SMP'''

$ '''ls -l u-boot u-boot.bin tools/mkimage'''
-rwxr-xr-x 1 piet tensilica 45016 2009-12-07 19:40 tools/mkimage [This is a small program you need to put in your search path to build kernel U-Boot images]
-rwxr-xr-x 1 piet tensilica 635339 2009-12-07 19:40 u-boot [Started with xt-gdb to bring up the 1st instance of a HiFi 2 U-Boot]
-rwxr-xr-x 1 piet tensilica 144944 2009-12-07 19:40 u-boot.bin [Loaded by the 1st instance of U-Boot, it's a HiFi2 version of u-boot that will be put in flash]
$

Unless you are using a U-Boot snapshot you need to build U-Boot for which you must have built the Buildroot toolchain for XTensa core.
Set your PATH to point to the toolchain built using buildroot. For example:

$ '''export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"'''

where '''<cname>''' is the name of the Xtensa core variant you wish to build for (e.g., <tt>dc232b</tt> <tt>dc233c</tt>).

To build U-Boot, use the cloned git tree pulled above, you should be at the top level of the tree in the '''u-boot''' directory , then configure it for your board and Xtensa core variant as follows:

make distclean
make <cname>'''_<board>_'''config
'dc232b'dc
This should only take a few seconds. For example, to build U-boot for the 'xtav60' board and the older 'dc232b' core with the V2 MMU type:

$ '''cd u-boot'''
$ '''make dc232b_xtav60_config'''

or for the new 'dc233c' core with the new V3 MMU type:

$ '''make dc233c_xtav60_config'''

or for a 'xtav200' board type with the new 'dc233c' core type:

$ '''make dc233c_xtav200_config'''

or for the snapshot_2+SMP branch you can also build U-Boot for the HiFi 2 core:

$ '''make test_mmuhifi_c3_xtav200_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

Only boards and core variants currently supported in the tree can be built out of the box. Headers for supported cores can be found in the tree under <tt>include/asm-xtensa/variant-<cname></tt>. The core specific headers are described in the <tt>doc/README.xtensa</tt> file. To support a new core, these headers must be copied from the overlay in the same way as for the linux kernel.

After the configuration step, to actually build U-Boot, simply:

$ '''make all''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

This will take a quite a few minutes.

This is likely a good time to copy '''mkimage''' to your ${HOME}/bin directory
for later use while building the Linux kernel. The '''mkimage''' program was
just built in the tool directory by the above '''make all'''.

$ '''cd tools'''
$ '''cp mkimage ~/bin''' [NOTE: '''mkimage''' should be in your search PATH while building the Linux kernel]

Next, start xt-gdb and load u-boot from the top of the git repository:

$ '''xt-gdb -n''' [NOTE: Even with the HiFi 2 snapshot_2+SMP branch you still may have to put U-Boot on the board]
(xt-gdb) '''file u-boot'''
(xt-gdb) '''target remote localhost:20000 0'''
(xt-gdb) '''reset'''
(xt-gdb) '''load'''
(xt-gdb) '''break panic'''
(xt-gdb) '''continue'''

Hopefully U-Boot will start, and display on the LCD in the case of a LX60.

U-Boot 50.00 Mhz

Often you will be starting with the boards flash in an unknown state and it's best to unprotect and erase the entire flash. Just type '''protect off all''' followed by '''erase all''':

U-Boot> '''protect off all'''
Un-Protect Flash Bank # 1
................................................................................................................................... done
U-Boot> '''erase all'''
Erase Flash Bank # 1
..........................................................................................................
Flash erase timeout at address f8d40000 da0
Flash erase error at address f8d40000
........................ done
U-Boot>

The timeout and error messages are likley just warning messages and you board has been errased. You can see that with the flash info command '''flinfo'''. Below is an example with a LX200 board, which has a much larger flash than the smaller LX60:

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
F8000000 E F8020000 E F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E F8FE0000 E F8FE8000 E F8FF0000 E
F8FF8000 E
U-Boot>

The new LX110 looks very similar to the LX200, also with with 16Mb of Flash:

U-Boot> flinfo

Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 32 bytes

Sector Start Addresses:
F8000000 E F8020000 E F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E F8FE0000 E

Now set your preliminary U-Boot environment variables to point to your TFTP server so we can download yet another copy of U-Boot. At Tensilica we use a machine in the RTOS group called rtos-lab2. Folks using the [[SMP HiFi 2 Development Board]] likely have set up their workstation with a TFTP server.

U-Boot> '''setenv serverip 192.168.11.78''' rtos-lab2
or
U-Boot> '''setenv serverip 192.168.11.55''' pdelaney_fc9

U-Boot> '''setenv ipaddr 192.168.11.95''' I/P address of RTOS5, Piet's LX60; MAC: 00:05:C2:13:6f:0a

U-Boot> '''setenv bootfile u-boot.bin'''
U-Boot> '''saveenv'''
Saving Environment to Flash...
.... done
Un-Protected 4 sectors
Erasing Flash...
.... done
Erased 4 sectors
Writing to Flash... done
.... done
Protected 4 sectors
U-Boot>

Next, download '''u-boot.bin''' from the tftp server using the info we just entered into U-Boot's enviroment variables.
Here for example is the case for a LX60 running the HiFi-2 Bitstream with the older V2 MMU. Note that it starts up
in the D-gazillion (0XD0000000) region:

U-Boot> '''tftpboot'''
TFTP from server 192.168.11.78; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0xd2000000
Loading: T ########
done
Bytes transferred = 107592 (1a448 hex)

For the V3 MMU U-Boot is loaded from host pdelaney_fc9 into memory with virtual == physical. Here is a DC233L, with V3 MMU, example:

U-Boot> '''tftpboot'''
Using open_ethernet device
TFTP from server 192.168.11.55; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: T ########
done
Bytes transferred = 109964 (1ad8c hex)
U-Boot>

Now things get a bit tricky here for the LX60. The FLASH has '''Two sizes of Flash Sectors'''.
The first 8 sectors are small 0x2000 (8KB) and apparently intended for parameters. The rest
of the 4MB flash is composed of larger 0x10000 (64KB) sectors. Our code doesn't differentiate
between the sectors and the LX60 hardware is going to map 0XF800,0000 to 0XFE00,0000 so this
makes us use of all 8 of the 8KB sectors and the 1st 64KB sector at F8010000. So we are going
to flash up to F801FFFF below.

On a LX200 we have much more space and can easily fit a version of U-boot that has been compiled without optimization, make debugging much easier.
So in this case the image is a bit larger, but relatively similar to the LX60 (2 sectors):

U-Boot> '''tftpboot'''
Using open_ethernet device
TFTP from server 192.168.11.78; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0xd2000000
Loading: ###############
done
Bytes transferred = 205852 (3241c hex)
U-Boot>

On a LX110 we have less memory than an LX60, but FLASH sectors like the LX200. It turns out that the u-boot image
compiled with optimization is just a bit larger than 1 sector, so like the LX200 we will need to write u-boot
into two sectors. Here's and example tftpboot of U-Bot for the LX110:

U-Boot> tftpboot
Using open_ethernet device
TFTP from server 192.168.11.55; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: ##########
done
Bytes transferred = 144956 (2363c hex)
U-Boot>

Note that for both the LX200 and the LX60 that the image size, '''(3241c hex)''' in this case, is a bit less than 0x40000 or 10 sectors,
so turn off protection on the 1st 11 sectors and
erase the current contents.

For the '''LX60''' you do this:

U-Boot> '''protect off F8000000 F801FFFF'''
... done
Un-Protected 9 sectors
U-Boot> '''erase F8000000 F801FFFF'''
erase F8000000 F801FFFF
... done
Erased 9 sectors
U-Boot>

For the '''LX200''' and the '''LX110''' the starting address '''(F8000000)''' is the same as with the LX60 but the last address '''(F803FFFF)''' is 'twice' as high:

U-Boot> '''protect off F8000000 F803FFFF'''
... done
Un-Protected 2 sectors
U-Boot> '''erase F8000000 F803FFFF'''
Erased 2 sectors
U-Boot>

Now copy the the image of u-boot.bin in memory to the flash. For the XL60 with the '''OLD''' V2 MMU you copy 0x20000
bytes from 0xd2000000 to 0XF8000000:

U-Boot> '''cp.b d2000000 F8000000 20000'''
Copy to Flash... done

For the LX60 with the '''NEW''' V3 MMU you copy 0x24000 bytes from 0x2000000 to F8000000:

U-Boot> '''cp.b 2000000 F8000000 20000'''
Copy to Flash... done

For the LX200 you copy 0x40000 bytes from 0xd2000000 to 0XF8000000...0XF803FFFF:

U-Boot> '''cp.b d2000000 F8000000 40000'''
Copy to Flash... done

For the LX110 with a V3-MMU you copy 0x40000 bytes from 0x2000000 to F8000000:
U-Boot> cp.b 2000000 F8000000 40000
Copy to Flash... done

Finally we protect these sectors so that U-Boot isn't easily erased by accident.
Below is what it looks like on a LX60 with the New V3 MMU with a subsequent display of the flash info:

U-Boot> '''cp.b 2000000 F8000000 2000'''
Copy to Flash... done
U-Boot> flinfo

Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x2257
Erase timeout: 8192 ms, write timeout: 1 ms

Sector Start Addresses:
'''F8000000 F8002000 F8004000 F8006000 F8008000'''
'''F800A000 F800C000 F800E000 F8010000 '''F8020000 E
F8030000 E F8040000 E F8050000 E F8060000 E F8070000 E
F8080000 E F8090000 E F80A0000 E F80B0000 E F80C0000 E
F80D0000 E F80E0000 E F80F0000 E F8100000 E F8110000 E
F8120000 E F8130000 E F8140000 E F8150000 E F8160000 E
F8170000 E F8180000 E F8190000 E F81A0000 E F81B0000 E
F81C0000 E F81D0000 E F81E0000 E F81F0000 E F8200000 E
F8210000 E F8220000 E F8230000 E F8240000 E F8250000 E
F8260000 E F8270000 E F8280000 E F8290000 E F82A0000 E
F82B0000 E F82C0000 E F82D0000 E F82E0000 E F82F0000 E
F8300000 E F8310000 E F8320000 E F8330000 E F8340000 E
F8350000 E F8360000 E F8370000 E F8380000 E F8390000 E
F83A0000 E F83B0000 E F83C0000 E F83D0000 E F83E0000
'''F83F0000 RO'''
U-Boot> '''protect on F8000000 F801FFFF'''
.......... done
Protected 9 sectors
U-Boot>

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x2257
Erase timeout: 8192 ms, write timeout: 1 ms

Sector Start Addresses:
'''F8000000 RO F8002000 RO F8004000 RO F8006000 RO F8008000 RO
F800A000 RO F800C000 RO F800E000 RO F8010000 RO''' F8020000 E
F8030000 E F8040000 E F8050000 E F8060000 E F8070000 E
F8080000 E F8090000 E F80A0000 E F80B0000 E F80C0000 E
F80D0000 E F80E0000 E F80F0000 E F8100000 E F8110000 E
F8120000 E F8130000 E F8140000 E F8150000 E F8160000 E
F8170000 E F8180000 E F8190000 E F81A0000 E F81B0000 E
F81C0000 E F81D0000 E F81E0000 E F81F0000 E F8200000 E
F8210000 E F8220000 E F8230000 E F8240000 E F8250000 E
F8260000 E F8270000 E F8280000 E F8290000 E F82A0000 E
F82B0000 E F82C0000 E F82D0000 E F82E0000 E F82F0000 E
F8300000 E F8310000 E F8320000 E F8330000 E F8340000 E
F8350000 E F8360000 E F8370000 E F8380000 E F8390000 E
F83A0000 E F83B0000 E F83C0000 E F83D0000 E F83E0000
'''F83F0000 RO'''
U-Boot>

For the '''LX110''' with the '''V3-MMU''' here's what the flash info looks like after we
protect the first two sectors with U-Boot copied to it:

U-Boot> '''protect on F8000000 F803FFFF'''
Protected 2 sectors
U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 32 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E '''F8FE0000 RO'''
U-Boot> help

Below is what it looks like on a '''LX200''' with the '''V2 MMU''' with a subsequent display of the flash info.
Notice that the Flash Sectors are 10X as large on the LX200:

U-Boot> '''protect on F8000000 F802FFFF'''
.. done
Protected 2 sectors
U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E '''F8FE0000 RO F8FE8000 RO F8FF0000 RO'''
'''F8FF8000 RO'''
U-Boot>

Note that the U-Boot '''saveenv''' command Erased and protected the last four sectors
of this LX200.

On both the LX60 and the LX200 now move DIP switch 8 to the ON position, on the LX110 move DIP switch 4 to the ON position.
Next, power cycle the board. On the LX60 you should see U-boot in the LCD display.

The '''LX60''' with the new '''V3 MMU''' the serial console should print something like the following:

U-Boot 2009.08-dirty (Sep 10 2010 - 18:23:26)

CPU: Xtensa dc233c at 50.00 MHz
Board: XT-AV60: Avnet board + Xilinx LX60 FPGA + Tensilica bitstream
SysRAM: 64 MB
Flash: 4 MB
In: serial
Out: serial
Err: serial
MAC: 00:50:C2:13:6f:0a
IP: 192.168.11.95
open_ethernet
U-Boot>

On the '''LX110''' with the new '''V3 MMU''' the serial console should print something like the following:

U-Boot 2009.08-dirty (Nov 15 2010 - 23:04:45)

CPU: Xtensa dc233c at 50.00 MHz
Board: XT-AV110: Avnet board + Xilinx LX110 FPGA + Tensilica bitstream
SysRAM: 48 MB
Flash: 16 MB
In: serial
Out: serial
Err: serial
MAC: 00:50:C2:13:6f:00
IP: 192.168.11.95
open_ethernet
U-Boot>

On the '''LX200''', shown below with the old V2 MMU, you should see something like the following. In this case we also show the flash info command, '''flinfo''', being invoked just after booting U-Boot:

U-Boot 2009.08-dirty (Nov 15 2010 - 23:04:45)

CPU: Xtensa test_mmuhifi_c3 at 41.6777 MHz
Board: XT-AV200: Avnet board + Xilinx LX200 FPGA + Tensilica bitstream
SysRAM: 96 MB
Flash: 16 MB
In: serial
Out: serial
Err: serial
MAC:
IP: 192.168.11.95
U-Boot>

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E RO F8060000 E RO F8080000 E RO
F80A0000 E RO F80C0000 E RO F80E0000 E RO F8100000 E RO F8120000 E RO
F8140000 E RO F8160000 E RO F8180000 E RO F81A0000 E RO F81C0000 E RO
F81E0000 E RO F8200000 E RO F8220000 E RO F8240000 E RO F8260000 E RO
F8280000 E RO F82A0000 E RO F82C0000 E RO F82E0000 E RO F8300000 E RO
F8320000 E RO F8340000 E RO F8360000 E RO F8380000 E RO F83A0000 E RO
F83C0000 E RO F83E0000 E RO F8400000 E RO F8420000 E RO F8440000 E RO
F8460000 E RO F8480000 E RO F84A0000 E RO F84C0000 E RO F84E0000 E RO
F8500000 E RO F8520000 E RO F8540000 E RO F8560000 E RO F8580000 E RO
F85A0000 E RO F85C0000 E RO F85E0000 E RO F8600000 E RO F8620000 E RO
F8640000 E RO F8660000 E RO F8680000 E RO F86A0000 E RO F86C0000 E RO
F86E0000 E RO F8700000 E RO F8720000 E RO F8740000 E RO F8760000 E RO
F8780000 E RO F87A0000 E RO F87C0000 E RO F87E0000 E RO F8800000 E RO
F8820000 E RO F8840000 E RO F8860000 E RO F8880000 E RO F88A0000 E RO
F88C0000 E RO F88E0000 E RO F8900000 E RO F8920000 E RO F8940000 E RO
F8960000 E RO F8980000 E RO F89A0000 E RO F89C0000 E RO F89E0000 E RO
F8A00000 E RO F8A20000 E RO F8A40000 E RO F8A60000 E RO F8A80000 E RO
F8AA0000 E RO F8AC0000 E RO F8AE0000 E RO F8B00000 E RO F8B20000 E RO
F8B40000 E RO F8B60000 E RO F8B80000 E RO F8BA0000 E RO F8BC0000 E RO
F8BE0000 E RO F8C00000 E RO F8C20000 E RO F8C40000 E RO F8C60000 E RO
F8C80000 E RO F8CA0000 E RO F8CC0000 E RO F8CE0000 E RO F8D00000 E RO
F8D20000 E RO F8D40000 E RO F8D60000 E RO F8D80000 E RO F8DA0000 E RO
F8DC0000 E RO F8DE0000 E RO F8E00000 E RO F8E20000 E RO F8E40000 E RO
F8E60000 E RO F8E80000 E RO F8EA0000 E RO F8EC0000 E RO F8EE0000 E RO
F8F00000 E RO F8F20000 E RO F8F40000 E RO F8F60000 E RO F8F80000 E RO
F8FA0000 E RO F8FC0000 E RO '''F8FE0000 RO F8FE8000 RO F8FF0000 RO'''
'''F8FF8000 RO'''
U-Boot>

Note that the 1st two sectors with U-Boot saved in them came up as not being erased ('''E''') but that all sectors came up Read Only ('''RO''').
Same with the last four sectors that the U-Boot '''saveenv''' command Erased. This is likely a '''bug''' on the LX200 boards with some preliminary investigation.
We will be discussing this with the U-Boot developers sometime in the future prior to pushing our U-boot changes upstream.

If U-Boot fails to boot ya might try making sure your U-Boot '''serverip''' environment variable matches the address of the tftp server where
you have copied your '''u-boot.bin''' file to and comparing the bits in the flash that got mapped to 0xfe00,0000 to what in the file:

u-boot]$ '''od -t x4 u-boot.bin | more'''
.0000000 00000206 fe000040 ffffffff a0fffe21
.0000020 00000002 fe01ad14 fe01ad8c 03f95030
.0000040 03f9aa78 04000000 00040003 03f8147c
.0000060 03f81418 00000000 00000000 00000000
.0000100 5300000c 13a00013 4800130c 13493013
.0000120 0c130200 13e62032 22002010 a03200a0
.0000140 1d837680 82037282 72822372 63728243
.0000160 72007272 72720872 18727210 2201d222
.0000200 020c80c2 3d80a032 1d8376f0 d20372d2
.0000220 72d22372 6372d243 f20072f2 72f20872
.0000240 1872f210 2201d222 200080c2 ffd92100
.0000260 37ffda31 02481d12 22681258 145722cb
.0000300 ee1467f1 664b0678 444b0479 06f43457
.0000320 0000fff8 31ffd221 4320ffd2 40443bc0
.0000340 84764142 4b020903 32020c22 837680a0
.0000360 04728211 82247282 72824472 01d22264
.0000400 1180c222 c821ffc8 13e620ff 41002010
.0000420 04d0ffc7 ffc64100 fffffd86 1049c500
.0000440 e52049d5 49f53049 00003400 00000000
.0000460 00000000 00000000 00000000 00000000
.
.(gdb) '''x/100x 0xfe000000'''
.0xfe000000 <_ResetVector>: 0x00000206 0xfe000040 0xffffffff 0xa0fffe21
.0xfe000010 <_ResetVector+16>: 0x00000002 0xfe01ad14 0xfe01ad8c 0x03f95030
.0xfe000020 <_ResetVector+32>: 0x03f9aa78 0x04000000 0x00040003 0x03f8147c
.0xfe000030 <_ResetVector+48>: 0x03f81418 0x00000000 0x00000000 0x00000000
.0xfe000040 <_start>: 0x5300000c 0x13a00013 0x4800130c 0x13493013
.0xfe000050 <_start+16>: 0x0c130200 0x13e62032 0x22002010 0xa03200a0
.0xfe000060 <_start+32>: 0x1d837680 0x82037282 0x72822372 0x63728243
.0xfe000070 <_start+48>: 0x72007272 0x72720872 0x18727210 0x2201d222
.0xfe000080 <_start+64>: 0x020c80c2 0x3d80a032 0x1d8376f0 0xd20372d2
.0xfe000090 <_start+80>: 0x72d22372 0x6372d243 0xf20072f2 0x72f20872
.0xfe0000a0 <_start+96>: 0x1872f210 0x2201d222 0x200080c2 0xffd92100
.0xfe0000b0 <_start+112>: 0x37ffda31 0x02481d12 0x22681258 0x145722cb
.0xfe0000c0 <_start+128>: 0xee1467f1 0x664b0678 0x444b0479 0x06f43457
.0xfe0000d0 <_start+144>: 0x0000fff8 0x31ffd221 0x4320ffd2 0x40443bc0
.0xfe0000e0 <_start+160>: 0x84764142 0x4b020903 0x32020c22 0x837680a0
.0xfe0000f0 <_start+176>: 0x04728211 0x82247282 0x72824472 0x01d22264
.0xfe000100 <_start+192>: 0x1180c222 0xc821ffc8 0x13e620ff 0x41002010
.0xfe000110 <_reset+1>: 0x04d0ffc7 0xffc64100 0x00fffd86 0x1049c500
.0xfe000120: 0xe52049d5 0x49f53049 0x00003400 0x00000000
.0xfe000130: 0x00000000 0x00000000 0x00000000 0x00000000
.(gdb)

Further details on U-Boot in general are in the generic <tt>README</tt> at the top of the U-Boot tree. Details specific to the Xtensa architecture are in <tt>doc/README.xtensa</tt>. Details specific to a board are in <tt>board[/<family>]/<board>/README</tt> (for example <tt>board/avnet/xtav60/README</tt>).

Setting up U-Boot

2010-11-24T00:03:10Z

Piet: /* LX60 and LX200 U-Boot Installation (LX110 in Progress) */

== LX60 and LX200 U-Boot Installation (LX110 in Progress) ==

''('''News:''' U-Boot for the new DC233, with the V3 MMU, is now working fine and checked into the master branch. Work is almost complete with the Linux 2.6.29-smp kernel, with
Linux now booting from this updated U-Boot. The kernel on the 'Initialize_MMU_Inside_vmlinux' branch seems to be working fine, and has survived 14 hours of stress testing so far.
Plain is to merge this and a few additional branches to the master branch and then move forward to a newer version of the Linux kernel.
'''Summary:'''

[http://www.denx.de/wiki/UBoot U-Boot] is a very popular boot loader; especially within the [http://elinux.org/Bootloader Embedded Linux community].
The U-Boot loader runs on the FPGA boards which are equipped with a dip switch, number 8, which can select where the memory location for the reset
vector (0XFE00,0000) comes from. With switch number 8 off the board will map the memory at the reset vector to a small block of SRAM located in the
I/O block with the UART and Ethernet buffer memory. When switch number 8 is on the Avnet boards map the beginning of the Flash Memory at 0XF800,000
to the reset vector at 0xFE00,000.

What we are going to do here is build a version of U-Boot for your Avnet board and Variant, install that ELF file into memory
with xt-gdb and run U-Boot. Then we are going to download a another copy of this identical program with '''tftp'''. The version we
are going to download is just the ELF file with the headers and debug information removed. It's just the actual bits that get
loaded into memory. For the new V3 MMU the default '''loadaddr''' is typically 0x20,0000 and for the older V2 MMU this is in the
Linux mapping equivalent, 0xD0200,0000. The default location can be change by setting the U-Boot 'loadaddr' environment variable
or by changing the variable '''CONFIG_SYS_LOAD_ADDR''' in the boards U-Boot config file.

Once the virgin copy of the U-Boot program has been loaded into memory, the Flash memory is un-protected and errasd, then the
memory with the U-Boot program in it is copied to the flash memory and protected. Next you will set dip switch 8 on, recycle
power on the board, and U-Boot will be accessible via the serial UART at 38400 baud. U-Boot works without any MMU mapping,
and should be fine on configurations without an MMU. Only an ethernet and serial interface are required.

'''Proceedure:'''

A local port to the Xtensa architecture is now available at linux-xtensa.org. See [http://git.linux-xtensa.org/cgi-bin/git.cgi?p=u-boot/u-boot-xtensa.git;a=summary U-Boot Sources (GIT Summary)]. Or, to access this tree using <tt>git</tt> directly, use something like:

$ '''git clone git://git.linux-xtensa.org/git/u-boot/u-boot-xtensa.git u-boot'''
$ '''cd u-boot'''

''('''Note:''' This path is subject to change.)''

The U-Boot git repository has a branch with a HiFi 2 snapshot made for
the LX200 [[SMP HiFi 2 Development Board]]. With this branch you can simply check
out the snapshot_2+SMP branch which includes the binaries which are discussed below:

$ '''git clone git://git.linux-xtensa.org/git/u-boot/u-boot-xtensa.git u-boot'''
$ '''cd u-boot'''
$ '''git branch --track snapshot_2+SMP origin/snapshot_2+SMP'''
$ '''git checkout snapshot_2+SMP'''

$ '''ls -l u-boot u-boot.bin tools/mkimage'''
-rwxr-xr-x 1 piet tensilica 45016 2009-12-07 19:40 tools/mkimage [This is a small program you need to put in your search path to build kernel U-Boot images]
-rwxr-xr-x 1 piet tensilica 635339 2009-12-07 19:40 u-boot [Started with xt-gdb to bring up the 1st instance of a HiFi 2 U-Boot]
-rwxr-xr-x 1 piet tensilica 144944 2009-12-07 19:40 u-boot.bin [Loaded by the 1st instance of U-Boot, it's a HiFi2 version of u-boot that will be put in flash]
$

Unless you are using a U-Boot snapshot you need to build U-Boot for which you must have built the Buildroot toolchain for XTensa core.
Set your PATH to point to the toolchain built using buildroot. For example:

$ '''export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"'''

where '''<cname>''' is the name of the Xtensa core variant you wish to build for (e.g., <tt>dc232b</tt> <tt>dc233c</tt>).

To build U-Boot, use the cloned git tree pulled above, you should be at the top level of the tree in the '''u-boot''' directory , then configure it for your board and Xtensa core variant as follows:

make distclean
make <cname>'''_<board>_'''config
'dc232b'dc
This should only take a few seconds. For example, to build U-boot for the 'xtav60' board and the older 'dc232b' core with the V2 MMU type:

$ '''cd u-boot'''
$ '''make dc232b_xtav60_config'''

or for the new 'dc233c' core with the new V3 MMU type:

$ '''make dc233c_xtav60_config'''

or for a 'xtav200' board type with the new 'dc233c' core type:

$ '''make dc233c_xtav200_config'''

or for the snapshot_2+SMP branch you can also build U-Boot for the HiFi 2 core:

$ '''make test_mmuhifi_c3_xtav200_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

Only boards and core variants currently supported in the tree can be built out of the box. Headers for supported cores can be found in the tree under <tt>include/asm-xtensa/variant-<cname></tt>. The core specific headers are described in the <tt>doc/README.xtensa</tt> file. To support a new core, these headers must be copied from the overlay in the same way as for the linux kernel.

After the configuration step, to actually build U-Boot, simply:

$ '''make all''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

This will take a quite a few minutes.

This is likely a good time to copy 'mkimage' to your ${HOME}/bin directory
for later use while building the Linux kernel. The 'mkimage' program is
in the tool directory:

$ '''cd tools'
$ '''cp mkimage ~/bin

Next, start xt-gdb and load u-boot from the top of the git repository:

$ '''xt-gdb -n''' [NOTE: Even with the HiFi 2 snapshot_2+SMP branch you still may have to put U-Boot on the board]
(xt-gdb) '''file u-boot'''
(xt-gdb) '''target remote localhost:20000 0'''
(xt-gdb) '''reset'''
(xt-gdb) '''load'''
(xt-gdb) '''break panic'''
(xt-gdb) '''continue'''

Hopefully U-Boot will start, and display on the LCD in the case of a LX60.

U-Boot 50.00 Mhz

Often you will be starting with the boards flash in an unknown state and it's best to unprotect and erase the entire flash. Just type '''protect off all''' followed by '''erase all''':

U-Boot> '''protect off all'''
Un-Protect Flash Bank # 1
................................................................................................................................... done
U-Boot> '''erase all'''
Erase Flash Bank # 1
..........................................................................................................
Flash erase timeout at address f8d40000 da0
Flash erase error at address f8d40000
........................ done
U-Boot>

The timeout and error messages are likley just warning messages and you board has been errased. You can see that with the flash info command '''flinfo'''. Below is an example with a LX200 board, which has a much larger flash than the smaller LX60:

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
F8000000 E F8020000 E F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E F8FE0000 E F8FE8000 E F8FF0000 E
F8FF8000 E
U-Boot>

The new LX110 looks very similar to the LX200, also with with 16Mb of Flash:

U-Boot> flinfo

Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 32 bytes

Sector Start Addresses:
F8000000 E F8020000 E F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E F8FE0000 E

Now set your preliminary U-Boot environment variables to point to your TFTP server so we can download yet another copy of U-Boot. At Tensilica we use a machine in the RTOS group called rtos-lab2. Folks using the [[SMP HiFi 2 Development Board]] likely have set up their workstation with a TFTP server.

U-Boot> '''setenv serverip 192.168.11.78''' rtos-lab2
or
U-Boot> '''setenv serverip 192.168.11.55''' pdelaney_fc9

U-Boot> '''setenv ipaddr 192.168.11.95''' I/P address of RTOS5, Piet's LX60; MAC: 00:05:C2:13:6f:0a

U-Boot> '''setenv bootfile u-boot.bin'''
U-Boot> '''saveenv'''
Saving Environment to Flash...
.... done
Un-Protected 4 sectors
Erasing Flash...
.... done
Erased 4 sectors
Writing to Flash... done
.... done
Protected 4 sectors
U-Boot>

Next, download '''u-boot.bin''' from the tftp server using the info we just entered into U-Boot's enviroment variables.
Here for example is the case for a LX60 running the HiFi-2 Bitstream with the older V2 MMU. Note that it starts up
in the D-gazillion (0XD0000000) region:

U-Boot> '''tftpboot'''
TFTP from server 192.168.11.78; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0xd2000000
Loading: T ########
done
Bytes transferred = 107592 (1a448 hex)

For the V3 MMU U-Boot is loaded from host pdelaney_fc9 into memory with virtual == physical. Here is a DC233L, with V3 MMU, example:

U-Boot> '''tftpboot'''
Using open_ethernet device
TFTP from server 192.168.11.55; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: T ########
done
Bytes transferred = 109964 (1ad8c hex)
U-Boot>

Now things get a bit tricky here for the LX60. The FLASH has '''Two sizes of Flash Sectors'''.
The first 8 sectors are small 0x2000 (8KB) and apparently intended for parameters. The rest
of the 4MB flash is composed of larger 0x10000 (64KB) sectors. Our code doesn't differentiate
between the sectors and the LX60 hardware is going to map 0XF800,0000 to 0XFE00,0000 so this
makes us use of all 8 of the 8KB sectors and the 1st 64KB sector at F8010000. So we are going
to flash up to F801FFFF below.

On a LX200 we have much more space and can easily fit a version of U-boot that has been compiled without optimization, make debugging much easier.
So in this case the image is a bit larger, but relatively similar to the LX60 (2 sectors):

U-Boot> '''tftpboot'''
Using open_ethernet device
TFTP from server 192.168.11.78; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0xd2000000
Loading: ###############
done
Bytes transferred = 205852 (3241c hex)
U-Boot>

On a LX110 we have less memory than an LX60, but FLASH sectors like the LX200. It turns out that the u-boot image
compiled with optimization is just a bit larger than 1 sector, so like the LX200 we will need to write u-boot
into two sectors. Here's and example tftpboot of U-Bot for the LX110:

U-Boot> tftpboot
Using open_ethernet device
TFTP from server 192.168.11.55; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: ##########
done
Bytes transferred = 144956 (2363c hex)
U-Boot>

Note that for both the LX200 and the LX60 that the image size, '''(3241c hex)''' in this case, is a bit less than 0x40000 or 10 sectors,
so turn off protection on the 1st 11 sectors and
erase the current contents.

For the '''LX60''' you do this:

U-Boot> '''protect off F8000000 F801FFFF'''
... done
Un-Protected 9 sectors
U-Boot> '''erase F8000000 F801FFFF'''
erase F8000000 F801FFFF
... done
Erased 9 sectors
U-Boot>

For the '''LX200''' and the '''LX110''' the starting address '''(F8000000)''' is the same as with the LX60 but the last address '''(F803FFFF)''' is 'twice' as high:

U-Boot> '''protect off F8000000 F803FFFF'''
... done
Un-Protected 2 sectors
U-Boot> '''erase F8000000 F803FFFF'''
Erased 2 sectors
U-Boot>

Now copy the the image of u-boot.bin in memory to the flash. For the XL60 with the '''OLD''' V2 MMU you copy 0x20000
bytes from 0xd2000000 to 0XF8000000:

U-Boot> '''cp.b d2000000 F8000000 20000'''
Copy to Flash... done

For the LX60 with the '''NEW''' V3 MMU you copy 0x24000 bytes from 0x2000000 to F8000000:

U-Boot> '''cp.b 2000000 F8000000 20000'''
Copy to Flash... done

For the LX200 you copy 0x40000 bytes from 0xd2000000 to 0XF8000000...0XF803FFFF:

U-Boot> '''cp.b d2000000 F8000000 40000'''
Copy to Flash... done

For the LX110 with a V3-MMU you copy 0x40000 bytes from 0x2000000 to F8000000:
U-Boot> cp.b 2000000 F8000000 40000
Copy to Flash... done

Finally we protect these sectors so that U-Boot isn't easily erased by accident.
Below is what it looks like on a LX60 with the New V3 MMU with a subsequent display of the flash info:

U-Boot> '''cp.b 2000000 F8000000 2000'''
Copy to Flash... done
U-Boot> flinfo

Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x2257
Erase timeout: 8192 ms, write timeout: 1 ms

Sector Start Addresses:
'''F8000000 F8002000 F8004000 F8006000 F8008000'''
'''F800A000 F800C000 F800E000 F8010000 '''F8020000 E
F8030000 E F8040000 E F8050000 E F8060000 E F8070000 E
F8080000 E F8090000 E F80A0000 E F80B0000 E F80C0000 E
F80D0000 E F80E0000 E F80F0000 E F8100000 E F8110000 E
F8120000 E F8130000 E F8140000 E F8150000 E F8160000 E
F8170000 E F8180000 E F8190000 E F81A0000 E F81B0000 E
F81C0000 E F81D0000 E F81E0000 E F81F0000 E F8200000 E
F8210000 E F8220000 E F8230000 E F8240000 E F8250000 E
F8260000 E F8270000 E F8280000 E F8290000 E F82A0000 E
F82B0000 E F82C0000 E F82D0000 E F82E0000 E F82F0000 E
F8300000 E F8310000 E F8320000 E F8330000 E F8340000 E
F8350000 E F8360000 E F8370000 E F8380000 E F8390000 E
F83A0000 E F83B0000 E F83C0000 E F83D0000 E F83E0000
'''F83F0000 RO'''
U-Boot> '''protect on F8000000 F801FFFF'''
.......... done
Protected 9 sectors
U-Boot>

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x2257
Erase timeout: 8192 ms, write timeout: 1 ms

Sector Start Addresses:
'''F8000000 RO F8002000 RO F8004000 RO F8006000 RO F8008000 RO
F800A000 RO F800C000 RO F800E000 RO F8010000 RO''' F8020000 E
F8030000 E F8040000 E F8050000 E F8060000 E F8070000 E
F8080000 E F8090000 E F80A0000 E F80B0000 E F80C0000 E
F80D0000 E F80E0000 E F80F0000 E F8100000 E F8110000 E
F8120000 E F8130000 E F8140000 E F8150000 E F8160000 E
F8170000 E F8180000 E F8190000 E F81A0000 E F81B0000 E
F81C0000 E F81D0000 E F81E0000 E F81F0000 E F8200000 E
F8210000 E F8220000 E F8230000 E F8240000 E F8250000 E
F8260000 E F8270000 E F8280000 E F8290000 E F82A0000 E
F82B0000 E F82C0000 E F82D0000 E F82E0000 E F82F0000 E
F8300000 E F8310000 E F8320000 E F8330000 E F8340000 E
F8350000 E F8360000 E F8370000 E F8380000 E F8390000 E
F83A0000 E F83B0000 E F83C0000 E F83D0000 E F83E0000
'''F83F0000 RO'''
U-Boot>

For the '''LX110''' with the '''V3-MMU''' here's what the flash info looks like after we
protect the first two sectors with U-Boot copied to it:

U-Boot> '''protect on F8000000 F803FFFF'''
Protected 2 sectors
U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 32 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E '''F8FE0000 RO'''
U-Boot> help

Below is what it looks like on a '''LX200''' with the '''V2 MMU''' with a subsequent display of the flash info.
Notice that the Flash Sectors are 10X as large on the LX200:

U-Boot> '''protect on F8000000 F802FFFF'''
.. done
Protected 2 sectors
U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E '''F8FE0000 RO F8FE8000 RO F8FF0000 RO'''
'''F8FF8000 RO'''
U-Boot>

Note that the U-Boot '''saveenv''' command Erased and protected the last four sectors
of this LX200.

On both the LX60 and the LX200 now move DIP switch 8 to the ON position, on the LX110 move DIP switch 4 to the ON position.
Next, power cycle the board. On the LX60 you should see U-boot in the LCD display.

The '''LX60''' with the new '''V3 MMU''' the serial console should print something like the following:

U-Boot 2009.08-dirty (Sep 10 2010 - 18:23:26)

CPU: Xtensa dc233c at 50.00 MHz
Board: XT-AV60: Avnet board + Xilinx LX60 FPGA + Tensilica bitstream
SysRAM: 64 MB
Flash: 4 MB
In: serial
Out: serial
Err: serial
MAC: 00:50:C2:13:6f:0a
IP: 192.168.11.95
open_ethernet
U-Boot>

On the '''LX110''' with the new '''V3 MMU''' the serial console should print something like the following:

U-Boot 2009.08-dirty (Nov 15 2010 - 23:04:45)

CPU: Xtensa dc233c at 50.00 MHz
Board: XT-AV110: Avnet board + Xilinx LX110 FPGA + Tensilica bitstream
SysRAM: 48 MB
Flash: 16 MB
In: serial
Out: serial
Err: serial
MAC: 00:50:C2:13:6f:00
IP: 192.168.11.95
open_ethernet
U-Boot>

On the '''LX200''', shown below with the old V2 MMU, you should see something like the following. In this case we also show the flash info command, '''flinfo''', being invoked just after booting U-Boot:

U-Boot 2009.08-dirty (Nov 15 2010 - 23:04:45)

CPU: Xtensa test_mmuhifi_c3 at 41.6777 MHz
Board: XT-AV200: Avnet board + Xilinx LX200 FPGA + Tensilica bitstream
SysRAM: 96 MB
Flash: 16 MB
In: serial
Out: serial
Err: serial
MAC:
IP: 192.168.11.95
U-Boot>

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E RO F8060000 E RO F8080000 E RO
F80A0000 E RO F80C0000 E RO F80E0000 E RO F8100000 E RO F8120000 E RO
F8140000 E RO F8160000 E RO F8180000 E RO F81A0000 E RO F81C0000 E RO
F81E0000 E RO F8200000 E RO F8220000 E RO F8240000 E RO F8260000 E RO
F8280000 E RO F82A0000 E RO F82C0000 E RO F82E0000 E RO F8300000 E RO
F8320000 E RO F8340000 E RO F8360000 E RO F8380000 E RO F83A0000 E RO
F83C0000 E RO F83E0000 E RO F8400000 E RO F8420000 E RO F8440000 E RO
F8460000 E RO F8480000 E RO F84A0000 E RO F84C0000 E RO F84E0000 E RO
F8500000 E RO F8520000 E RO F8540000 E RO F8560000 E RO F8580000 E RO
F85A0000 E RO F85C0000 E RO F85E0000 E RO F8600000 E RO F8620000 E RO
F8640000 E RO F8660000 E RO F8680000 E RO F86A0000 E RO F86C0000 E RO
F86E0000 E RO F8700000 E RO F8720000 E RO F8740000 E RO F8760000 E RO
F8780000 E RO F87A0000 E RO F87C0000 E RO F87E0000 E RO F8800000 E RO
F8820000 E RO F8840000 E RO F8860000 E RO F8880000 E RO F88A0000 E RO
F88C0000 E RO F88E0000 E RO F8900000 E RO F8920000 E RO F8940000 E RO
F8960000 E RO F8980000 E RO F89A0000 E RO F89C0000 E RO F89E0000 E RO
F8A00000 E RO F8A20000 E RO F8A40000 E RO F8A60000 E RO F8A80000 E RO
F8AA0000 E RO F8AC0000 E RO F8AE0000 E RO F8B00000 E RO F8B20000 E RO
F8B40000 E RO F8B60000 E RO F8B80000 E RO F8BA0000 E RO F8BC0000 E RO
F8BE0000 E RO F8C00000 E RO F8C20000 E RO F8C40000 E RO F8C60000 E RO
F8C80000 E RO F8CA0000 E RO F8CC0000 E RO F8CE0000 E RO F8D00000 E RO
F8D20000 E RO F8D40000 E RO F8D60000 E RO F8D80000 E RO F8DA0000 E RO
F8DC0000 E RO F8DE0000 E RO F8E00000 E RO F8E20000 E RO F8E40000 E RO
F8E60000 E RO F8E80000 E RO F8EA0000 E RO F8EC0000 E RO F8EE0000 E RO
F8F00000 E RO F8F20000 E RO F8F40000 E RO F8F60000 E RO F8F80000 E RO
F8FA0000 E RO F8FC0000 E RO '''F8FE0000 RO F8FE8000 RO F8FF0000 RO'''
'''F8FF8000 RO'''
U-Boot>

Note that the 1st two sectors with U-Boot saved in them came up as not being erased ('''E''') but that all sectors came up Read Only ('''RO''').
Same with the last four sectors that the U-Boot '''saveenv''' command Erased. This is likely a '''bug''' on the LX200 boards with some preliminary investigation.
We will be discussing this with the U-Boot developers sometime in the future prior to pushing our U-boot changes upstream.

If U-Boot fails to boot ya might try making sure your U-Boot '''serverip''' environment variable matches the address of the tftp server where
you have copied your '''u-boot.bin''' file to and comparing the bits in the flash that got mapped to 0xfe00,0000 to what in the file:

u-boot]$ '''od -t x4 u-boot.bin | more'''
.0000000 00000206 fe000040 ffffffff a0fffe21
.0000020 00000002 fe01ad14 fe01ad8c 03f95030
.0000040 03f9aa78 04000000 00040003 03f8147c
.0000060 03f81418 00000000 00000000 00000000
.0000100 5300000c 13a00013 4800130c 13493013
.0000120 0c130200 13e62032 22002010 a03200a0
.0000140 1d837680 82037282 72822372 63728243
.0000160 72007272 72720872 18727210 2201d222
.0000200 020c80c2 3d80a032 1d8376f0 d20372d2
.0000220 72d22372 6372d243 f20072f2 72f20872
.0000240 1872f210 2201d222 200080c2 ffd92100
.0000260 37ffda31 02481d12 22681258 145722cb
.0000300 ee1467f1 664b0678 444b0479 06f43457
.0000320 0000fff8 31ffd221 4320ffd2 40443bc0
.0000340 84764142 4b020903 32020c22 837680a0
.0000360 04728211 82247282 72824472 01d22264
.0000400 1180c222 c821ffc8 13e620ff 41002010
.0000420 04d0ffc7 ffc64100 fffffd86 1049c500
.0000440 e52049d5 49f53049 00003400 00000000
.0000460 00000000 00000000 00000000 00000000
.
.(gdb) '''x/100x 0xfe000000'''
.0xfe000000 <_ResetVector>: 0x00000206 0xfe000040 0xffffffff 0xa0fffe21
.0xfe000010 <_ResetVector+16>: 0x00000002 0xfe01ad14 0xfe01ad8c 0x03f95030
.0xfe000020 <_ResetVector+32>: 0x03f9aa78 0x04000000 0x00040003 0x03f8147c
.0xfe000030 <_ResetVector+48>: 0x03f81418 0x00000000 0x00000000 0x00000000
.0xfe000040 <_start>: 0x5300000c 0x13a00013 0x4800130c 0x13493013
.0xfe000050 <_start+16>: 0x0c130200 0x13e62032 0x22002010 0xa03200a0
.0xfe000060 <_start+32>: 0x1d837680 0x82037282 0x72822372 0x63728243
.0xfe000070 <_start+48>: 0x72007272 0x72720872 0x18727210 0x2201d222
.0xfe000080 <_start+64>: 0x020c80c2 0x3d80a032 0x1d8376f0 0xd20372d2
.0xfe000090 <_start+80>: 0x72d22372 0x6372d243 0xf20072f2 0x72f20872
.0xfe0000a0 <_start+96>: 0x1872f210 0x2201d222 0x200080c2 0xffd92100
.0xfe0000b0 <_start+112>: 0x37ffda31 0x02481d12 0x22681258 0x145722cb
.0xfe0000c0 <_start+128>: 0xee1467f1 0x664b0678 0x444b0479 0x06f43457
.0xfe0000d0 <_start+144>: 0x0000fff8 0x31ffd221 0x4320ffd2 0x40443bc0
.0xfe0000e0 <_start+160>: 0x84764142 0x4b020903 0x32020c22 0x837680a0
.0xfe0000f0 <_start+176>: 0x04728211 0x82247282 0x72824472 0x01d22264
.0xfe000100 <_start+192>: 0x1180c222 0xc821ffc8 0x13e620ff 0x41002010
.0xfe000110 <_reset+1>: 0x04d0ffc7 0xffc64100 0x00fffd86 0x1049c500
.0xfe000120: 0xe52049d5 0x49f53049 0x00003400 0x00000000
.0xfe000130: 0x00000000 0x00000000 0x00000000 0x00000000
.(gdb)

Further details on U-Boot in general are in the generic <tt>README</tt> at the top of the U-Boot tree. Details specific to the Xtensa architecture are in <tt>doc/README.xtensa</tt>. Details specific to a board are in <tt>board[/<family>]/<board>/README</tt> (for example <tt>board/avnet/xtav60/README</tt>).

Setting up U-Boot

2010-11-18T04:25:29Z

Piet: /* LX60 and LX200 U-Boot Installation (LX110 in Progress) */

== LX60 and LX200 U-Boot Installation (LX110 in Progress) ==

''('''News:''' The New DC233, with the V3 MMU, is now working. Work is in progress with the Linux 2.6.29-smp kernel to boot from this updated U-Boot. U-Boot is starting to work for the LX110 with the V3_MMU, having a minor problem with the LCD display and the kernel isn't booting, likely need to get the Load Address correct for V3 MMU.

'''Summary:'''

[http://www.denx.de/wiki/UBoot U-Boot] is a very popular boot loader; especially within the [http://elinux.org/Bootloader Embedded Linux community].
The U-Boot loader runs on the FPGA boards which are equipped with a dip switch, number 8, which can select where the memory location for the reset
vector (0XFE00,0000) comes from. With switch number 8 off the board will map the memory at the reset vector to a small block of SRAM located in the
I/O block with the UART and Ethernet buffer memory. When switch number 8 is on the Avnet boards map the beginning of the Flash Memory at 0XF800,000
to the reset vector at 0xFE00,000.

What we are going to do here is build a version of U-Boot for your Avnet board and Variant, install that ELF file into memory
with xt-gdb and run U-Boot. Then we are going to download a another copy of this identical program with '''tftp'''. The version we
are going to download is just the ELF file with the headers and debug information removed. It's just the actual bits that get
loaded into memory. For the new V3 MMU the default '''loadaddr''' is typically 0x20,0000 and for the older V2 MMU this is in the
Linux mapping equivalent, 0xD0200,0000. The default location can be change by setting the U-Boot 'loadaddr' environment variable
or by changing the variable '''CONFIG_SYS_LOAD_ADDR''' in the boards U-Boot config file.

Once the virgin copy of the U-Boot program has been loaded into memory, the Flash memory is un-protected and errasd, then the
memory with the U-Boot program in it is copied to the flash memory and protected. Next you will set dip switch 8 on, recycle
power on the board, and U-Boot will be accessible via the serial UART at 38400 baud. U-Boot works without any MMU mapping,
and should be fine on configurations without an MMU. Only an ethernet and serial interface are required.

'''Proceedure:'''

A local port to the Xtensa architecture is now available at linux-xtensa.org. See [http://git.linux-xtensa.org/cgi-bin/git.cgi?p=u-boot/u-boot-xtensa.git;a=summary U-Boot Sources (GIT Summary)]. Or, to access this tree using <tt>git</tt> directly, use something like:

$ '''git clone git://git.linux-xtensa.org/git/u-boot/u-boot-xtensa.git u-boot'''
$ '''cd u-boot'''

''('''Note:''' This path is subject to change.)''

The U-Boot git repository has a branch with a HiFi 2 snapshot made for
the LX200 [[SMP HiFi 2 Development Board]]. With this branch you can simply check
out the snapshot_2+SMP branch which includes the binaries which are discussed below:

$ '''git clone git://git.linux-xtensa.org/git/u-boot/u-boot-xtensa.git u-boot'''
$ '''cd u-boot'''
$ '''git branch --track snapshot_2+SMP origin/snapshot_2+SMP'''
$ '''git checkout snapshot_2+SMP'''

$ '''ls -l u-boot u-boot.bin tools/mkimage'''
-rwxr-xr-x 1 piet tensilica 45016 2009-12-07 19:40 tools/mkimage [This is a small program you need to put in your search path to build kernel U-Boot images]
-rwxr-xr-x 1 piet tensilica 635339 2009-12-07 19:40 u-boot [Started with xt-gdb to bring up the 1st instance of a HiFi 2 U-Boot]
-rwxr-xr-x 1 piet tensilica 144944 2009-12-07 19:40 u-boot.bin [Loaded by the 1st instance of U-Boot, it's a HiFi2 version of u-boot that will be put in flash]
$

Unless you are using a U-Boot snapshot you need to build U-Boot for which you must have built the Buildroot toolchain for XTensa core.
Set your PATH to point to the toolchain built using buildroot. For example:

$ '''export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"'''

where '''<cname>''' is the name of the Xtensa core variant you wish to build for (e.g., <tt>dc232b</tt> <tt>dc233c</tt>).

To build U-Boot, use the cloned git tree pulled above, you should be at the top level of the tree in the '''u-boot''' directory , then configure it for your board and Xtensa core variant as follows:

make distclean
make <cname>'''_<board>_'''config
'dc232b'dc
This should only take a few seconds. For example, to build U-boot for the 'xtav60' board and the older 'dc232b' core with the V2 MMU type:

$ '''cd u-boot'''
$ '''make dc232b_xtav60_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

or for the new 'dc233c' core with the new V3 MMU type:

$ '''make dc233c_xtav60_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

or for a 'xtav200' board type with the new 'dc233c' core type:

$ '''make dc233c_xtav200_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

or for the snapshot_2+SMP branch you can also build U-Boot for the HiFi 2 core:

$ '''make test_mmuhifi_c3_xtav200_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

Only boards and core variants currently supported in the tree can be built out of the box. Headers for supported cores can be found in the tree under <tt>include/asm-xtensa/variant-<cname></tt>. The core specific headers are described in the <tt>doc/README.xtensa</tt> file. To support a new core, these headers must be copied from the overlay in the same way as for the linux kernel.

After the configuration step, to actually build U-Boot, simply:

$ '''make all''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

This will take a quite a few minutes.

Next, start xt-gdb and load u-boot from the top of the git repository:

$ '''xt-gdb -n''' [NOTE: Even with the HiFi 2 snapshot_2+SMP branch you still may have to put U-Boot on the board]
(xt-gdb) '''file u-boot'''
(xt-gdb) '''target remote localhost:20000 0'''
(xt-gdb) '''reset'''
(xt-gdb) '''load'''
(xt-gdb) '''break panic'''
(xt-gdb) '''continue'''

Hopefully U-Boot will start, and display on the LCD in the case of a LX60.

U-Boot 50.00 Mhz

Often you will be starting with the boards flash in an unknown state and it's best to unprotect and erase the entire flash. Just type '''protect off all''' followed by '''erase all''':

U-Boot> '''protect off all'''
Un-Protect Flash Bank # 1
................................................................................................................................... done
U-Boot> '''erase all'''
Erase Flash Bank # 1
..........................................................................................................
Flash erase timeout at address f8d40000 da0
Flash erase error at address f8d40000
........................ done
U-Boot>

The timeout and error messages are likley just warning messages and you board has been errased. You can see that with the flash info command '''flinfo'''. Below is an example with a LX200 board, which has a much larger flash than the smaller LX60:

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
F8000000 E F8020000 E F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E F8FE0000 E F8FE8000 E F8FF0000 E
F8FF8000 E
U-Boot>

The new LX110 looks very similar to the LX200, also with with 16Mb of Flash:

U-Boot> flinfo

Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 32 bytes

Sector Start Addresses:
F8000000 E F8020000 E F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E F8FE0000 E

Now set your preliminary U-Boot environment variables to point to your TFTP server so we can download yet another copy of U-Boot. At Tensilica we use a machine in the RTOS group called rtos-lab2. Folks using the [[SMP HiFi 2 Development Board]] likely have set up their workstation with a TFTP server.

U-Boot> '''setenv serverip 192.168.11.78''' rtos-lab2
or
U-Boot> '''setenv serverip 192.168.11.55''' pdelaney_fc9

U-Boot> '''setenv ipaddr 192.168.11.95''' I/P address of RTOS5, Piet's LX60; MAC: 00:05:C2:13:6f:0a

U-Boot> '''setenv bootfile u-boot.bin'''
U-Boot> '''saveenv'''
Saving Environment to Flash...
.... done
Un-Protected 4 sectors
Erasing Flash...
.... done
Erased 4 sectors
Writing to Flash... done
.... done
Protected 4 sectors
U-Boot>

Next, download '''u-boot.bin''' from the tftp server using the info we just entered into U-Boot's enviroment variables.
Here for example is the case for a LX60 running the HiFi-2 Bitstream with the older V2 MMU. Note that it starts up
in the D-gazillion (0XD0000000) region:

U-Boot> '''tftpboot'''
TFTP from server 192.168.11.78; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0xd2000000
Loading: T ########
done
Bytes transferred = 107592 (1a448 hex)

For the V3 MMU U-Boot is loaded from host pdelaney_fc9 into memory with virtual == physical. Here is a DC233L, with V3 MMU, example:

U-Boot> '''tftpboot'''
Using open_ethernet device
TFTP from server 192.168.11.55; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: T ########
done
Bytes transferred = 109964 (1ad8c hex)
U-Boot>

Now things get a bit tricky here for the LX60. The FLASH has '''Two sizes of Flash Sectors'''.
The first 8 sectors are small 0x2000 (8KB) and apparently intended for parameters. The rest
of the 4MB flash is composed of larger 0x10000 (64KB) sectors. Our code doesn't differentiate
between the sectors and the LX60 hardware is going to map 0XF800,0000 to 0XFE00,0000 so this
makes us use of all 8 of the 8KB sectors and the 1st 64KB sector at F8010000. So we are going
to flash up to F801FFFF below.

On a LX200 we have much more space and can easily fit a version of U-boot that has been compiled without optimization, make debugging much easier.
So in this case the image is a bit larger, but relatively similar to the LX60 (2 sectors):

U-Boot> '''tftpboot'''
Using open_ethernet device
TFTP from server 192.168.11.78; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0xd2000000
Loading: ###############
done
Bytes transferred = 205852 (3241c hex)
U-Boot>

On a LX110 we have less memory than an LX60, but FLASH sectors like the LX200. It turns out that the u-boot image
compiled with optimization is just a bit larger than 1 sector, so like the LX200 we will need to write u-boot
into two sectors. Here's and example tftpboot of U-Bot for the LX110:

U-Boot> tftpboot
Using open_ethernet device
TFTP from server 192.168.11.55; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: ##########
done
Bytes transferred = 144956 (2363c hex)
U-Boot>

Note that for both the LX200 and the LX60 that the image size, '''(3241c hex)''' in this case, is a bit less than 0x40000 or 10 sectors,
so turn off protection on the 1st 11 sectors and
erase the current contents.

For the '''LX60''' you do this:

U-Boot> '''protect off F8000000 F801FFFF'''
... done
Un-Protected 9 sectors
U-Boot> '''erase F8000000 F801FFFF'''
erase F8000000 F801FFFF
... done
Erased 9 sectors
U-Boot>

For the '''LX200''' and the '''LX110''' the starting address '''(F8000000)''' is the same as with the LX60 but the last address '''(F803FFFF)''' is 'twice' as high:

U-Boot> '''protect off F8000000 F803FFFF'''
... done
Un-Protected 2 sectors
U-Boot> '''erase F8000000 F803FFFF'''
Erased 2 sectors
U-Boot>

Now copy the the image of u-boot.bin in memory to the flash. For the XL60 with the '''OLD''' V2 MMU you copy 0x20000
bytes from 0xd2000000 to 0XF8000000:

U-Boot> '''cp.b d2000000 F8000000 20000'''
Copy to Flash... done

For the LX60 with the '''NEW''' V3 MMU you copy 0x24000 bytes from 0x2000000 to F8000000:

U-Boot> '''cp.b 2000000 F8000000 20000'''
Copy to Flash... done

For the LX200 you copy 0x40000 bytes from 0xd2000000 to 0XF8000000...0XF803FFFF:

U-Boot> '''cp.b d2000000 F8000000 40000'''
Copy to Flash... done

For the LX110 with a V3-MMU you copy 0x40000 bytes from 0x2000000 to F8000000:
U-Boot> cp.b 2000000 F8000000 40000
Copy to Flash... done

Finally we protect these sectors so that U-Boot isn't easily erased by accident.
Below is what it looks like on a LX60 with the New V3 MMU with a subsequent display of the flash info:

U-Boot> '''cp.b 2000000 F8000000 2000'''
Copy to Flash... done
U-Boot> flinfo

Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x2257
Erase timeout: 8192 ms, write timeout: 1 ms

Sector Start Addresses:
'''F8000000 F8002000 F8004000 F8006000 F8008000'''
'''F800A000 F800C000 F800E000 F8010000 '''F8020000 E
F8030000 E F8040000 E F8050000 E F8060000 E F8070000 E
F8080000 E F8090000 E F80A0000 E F80B0000 E F80C0000 E
F80D0000 E F80E0000 E F80F0000 E F8100000 E F8110000 E
F8120000 E F8130000 E F8140000 E F8150000 E F8160000 E
F8170000 E F8180000 E F8190000 E F81A0000 E F81B0000 E
F81C0000 E F81D0000 E F81E0000 E F81F0000 E F8200000 E
F8210000 E F8220000 E F8230000 E F8240000 E F8250000 E
F8260000 E F8270000 E F8280000 E F8290000 E F82A0000 E
F82B0000 E F82C0000 E F82D0000 E F82E0000 E F82F0000 E
F8300000 E F8310000 E F8320000 E F8330000 E F8340000 E
F8350000 E F8360000 E F8370000 E F8380000 E F8390000 E
F83A0000 E F83B0000 E F83C0000 E F83D0000 E F83E0000
'''F83F0000 RO'''
U-Boot> '''protect on F8000000 F801FFFF'''
.......... done
Protected 9 sectors
U-Boot>

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x2257
Erase timeout: 8192 ms, write timeout: 1 ms

Sector Start Addresses:
'''F8000000 RO F8002000 RO F8004000 RO F8006000 RO F8008000 RO
F800A000 RO F800C000 RO F800E000 RO F8010000 RO''' F8020000 E
F8030000 E F8040000 E F8050000 E F8060000 E F8070000 E
F8080000 E F8090000 E F80A0000 E F80B0000 E F80C0000 E
F80D0000 E F80E0000 E F80F0000 E F8100000 E F8110000 E
F8120000 E F8130000 E F8140000 E F8150000 E F8160000 E
F8170000 E F8180000 E F8190000 E F81A0000 E F81B0000 E
F81C0000 E F81D0000 E F81E0000 E F81F0000 E F8200000 E
F8210000 E F8220000 E F8230000 E F8240000 E F8250000 E
F8260000 E F8270000 E F8280000 E F8290000 E F82A0000 E
F82B0000 E F82C0000 E F82D0000 E F82E0000 E F82F0000 E
F8300000 E F8310000 E F8320000 E F8330000 E F8340000 E
F8350000 E F8360000 E F8370000 E F8380000 E F8390000 E
F83A0000 E F83B0000 E F83C0000 E F83D0000 E F83E0000
'''F83F0000 RO'''
U-Boot>

For the '''LX110''' with the '''V3-MMU''' here's what the flash info looks like after we
protect the first two sectors with U-Boot copied to it:

U-Boot> '''protect on F8000000 F803FFFF'''
Protected 2 sectors
U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 32 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E '''F8FE0000 RO'''
U-Boot> help

Below is what it looks like on a '''LX200''' with the '''V2 MMU''' with a subsequent display of the flash info.
Notice that the Flash Sectors are 10X as large on the LX200:

U-Boot> '''protect on F8000000 F802FFFF'''
.. done
Protected 2 sectors
U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E '''F8FE0000 RO F8FE8000 RO F8FF0000 RO'''
'''F8FF8000 RO'''
U-Boot>

Note that the U-Boot '''saveenv''' command Erased and protected the last four sectors
of this LX200.

On both the LX60 and the LX200 now move DIP switch 8 to the ON position, on the LX110 move DIP switch 4 to the ON position.
Next, power cycle the board. On the LX60 you should see U-boot in the LCD display.

The '''LX60''' with the new '''V3 MMU''' the serial console should print something like the following:

U-Boot 2009.08-dirty (Sep 10 2010 - 18:23:26)

CPU: Xtensa dc233c at 50.00 MHz
Board: XT-AV60: Avnet board + Xilinx LX60 FPGA + Tensilica bitstream
SysRAM: 64 MB
Flash: 4 MB
In: serial
Out: serial
Err: serial
MAC: 00:50:C2:13:6f:0a
IP: 192.168.11.95
open_ethernet
U-Boot>

On the '''LX110''' with the new '''V3 MMU''' the serial console should print something like the following:

U-Boot 2009.08-dirty (Nov 15 2010 - 23:04:45)

CPU: Xtensa dc233c at 50.00 MHz
Board: XT-AV110: Avnet board + Xilinx LX110 FPGA + Tensilica bitstream
SysRAM: 48 MB
Flash: 16 MB
In: serial
Out: serial
Err: serial
MAC: 00:50:C2:13:6f:00
IP: 192.168.11.95
open_ethernet
U-Boot>

On the '''LX200''', shown below with the old V2 MMU, you should see something like the following. In this case we also show the flash info command, '''flinfo''', being invoked just after booting U-Boot:

U-Boot 2009.08-dirty (Nov 15 2010 - 23:04:45)

CPU: Xtensa test_mmuhifi_c3 at 41.6777 MHz
Board: XT-AV200: Avnet board + Xilinx LX200 FPGA + Tensilica bitstream
SysRAM: 96 MB
Flash: 16 MB
In: serial
Out: serial
Err: serial
MAC:
IP: 192.168.11.95
U-Boot>

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E RO F8060000 E RO F8080000 E RO
F80A0000 E RO F80C0000 E RO F80E0000 E RO F8100000 E RO F8120000 E RO
F8140000 E RO F8160000 E RO F8180000 E RO F81A0000 E RO F81C0000 E RO
F81E0000 E RO F8200000 E RO F8220000 E RO F8240000 E RO F8260000 E RO
F8280000 E RO F82A0000 E RO F82C0000 E RO F82E0000 E RO F8300000 E RO
F8320000 E RO F8340000 E RO F8360000 E RO F8380000 E RO F83A0000 E RO
F83C0000 E RO F83E0000 E RO F8400000 E RO F8420000 E RO F8440000 E RO
F8460000 E RO F8480000 E RO F84A0000 E RO F84C0000 E RO F84E0000 E RO
F8500000 E RO F8520000 E RO F8540000 E RO F8560000 E RO F8580000 E RO
F85A0000 E RO F85C0000 E RO F85E0000 E RO F8600000 E RO F8620000 E RO
F8640000 E RO F8660000 E RO F8680000 E RO F86A0000 E RO F86C0000 E RO
F86E0000 E RO F8700000 E RO F8720000 E RO F8740000 E RO F8760000 E RO
F8780000 E RO F87A0000 E RO F87C0000 E RO F87E0000 E RO F8800000 E RO
F8820000 E RO F8840000 E RO F8860000 E RO F8880000 E RO F88A0000 E RO
F88C0000 E RO F88E0000 E RO F8900000 E RO F8920000 E RO F8940000 E RO
F8960000 E RO F8980000 E RO F89A0000 E RO F89C0000 E RO F89E0000 E RO
F8A00000 E RO F8A20000 E RO F8A40000 E RO F8A60000 E RO F8A80000 E RO
F8AA0000 E RO F8AC0000 E RO F8AE0000 E RO F8B00000 E RO F8B20000 E RO
F8B40000 E RO F8B60000 E RO F8B80000 E RO F8BA0000 E RO F8BC0000 E RO
F8BE0000 E RO F8C00000 E RO F8C20000 E RO F8C40000 E RO F8C60000 E RO
F8C80000 E RO F8CA0000 E RO F8CC0000 E RO F8CE0000 E RO F8D00000 E RO
F8D20000 E RO F8D40000 E RO F8D60000 E RO F8D80000 E RO F8DA0000 E RO
F8DC0000 E RO F8DE0000 E RO F8E00000 E RO F8E20000 E RO F8E40000 E RO
F8E60000 E RO F8E80000 E RO F8EA0000 E RO F8EC0000 E RO F8EE0000 E RO
F8F00000 E RO F8F20000 E RO F8F40000 E RO F8F60000 E RO F8F80000 E RO
F8FA0000 E RO F8FC0000 E RO '''F8FE0000 RO F8FE8000 RO F8FF0000 RO'''
'''F8FF8000 RO'''
U-Boot>

Note that the 1st two sectors with U-Boot saved in them came up as not being erased ('''E''') but that all sectors came up Read Only ('''RO''').
Same with the last four sectors that the U-Boot '''saveenv''' command Erased. This is likely a '''bug''' on the LX200 boards with some preliminary investigation.
We will be discussing this with the U-Boot developers sometime in the future prior to pushing our U-boot changes upstream.

If U-Boot fails to boot ya might try making sure your U-Boot '''serverip''' environment variable matches the address of the tftp server where
you have copied your '''u-boot.bin''' file to and comparing the bits in the flash that got mapped to 0xfe00,0000 to what in the file:

u-boot]$ '''od -t x4 u-boot.bin | more'''
.0000000 00000206 fe000040 ffffffff a0fffe21
.0000020 00000002 fe01ad14 fe01ad8c 03f95030
.0000040 03f9aa78 04000000 00040003 03f8147c
.0000060 03f81418 00000000 00000000 00000000
.0000100 5300000c 13a00013 4800130c 13493013
.0000120 0c130200 13e62032 22002010 a03200a0
.0000140 1d837680 82037282 72822372 63728243
.0000160 72007272 72720872 18727210 2201d222
.0000200 020c80c2 3d80a032 1d8376f0 d20372d2
.0000220 72d22372 6372d243 f20072f2 72f20872
.0000240 1872f210 2201d222 200080c2 ffd92100
.0000260 37ffda31 02481d12 22681258 145722cb
.0000300 ee1467f1 664b0678 444b0479 06f43457
.0000320 0000fff8 31ffd221 4320ffd2 40443bc0
.0000340 84764142 4b020903 32020c22 837680a0
.0000360 04728211 82247282 72824472 01d22264
.0000400 1180c222 c821ffc8 13e620ff 41002010
.0000420 04d0ffc7 ffc64100 fffffd86 1049c500
.0000440 e52049d5 49f53049 00003400 00000000
.0000460 00000000 00000000 00000000 00000000
.
.(gdb) '''x/100x 0xfe000000'''
.0xfe000000 <_ResetVector>: 0x00000206 0xfe000040 0xffffffff 0xa0fffe21
.0xfe000010 <_ResetVector+16>: 0x00000002 0xfe01ad14 0xfe01ad8c 0x03f95030
.0xfe000020 <_ResetVector+32>: 0x03f9aa78 0x04000000 0x00040003 0x03f8147c
.0xfe000030 <_ResetVector+48>: 0x03f81418 0x00000000 0x00000000 0x00000000
.0xfe000040 <_start>: 0x5300000c 0x13a00013 0x4800130c 0x13493013
.0xfe000050 <_start+16>: 0x0c130200 0x13e62032 0x22002010 0xa03200a0
.0xfe000060 <_start+32>: 0x1d837680 0x82037282 0x72822372 0x63728243
.0xfe000070 <_start+48>: 0x72007272 0x72720872 0x18727210 0x2201d222
.0xfe000080 <_start+64>: 0x020c80c2 0x3d80a032 0x1d8376f0 0xd20372d2
.0xfe000090 <_start+80>: 0x72d22372 0x6372d243 0xf20072f2 0x72f20872
.0xfe0000a0 <_start+96>: 0x1872f210 0x2201d222 0x200080c2 0xffd92100
.0xfe0000b0 <_start+112>: 0x37ffda31 0x02481d12 0x22681258 0x145722cb
.0xfe0000c0 <_start+128>: 0xee1467f1 0x664b0678 0x444b0479 0x06f43457
.0xfe0000d0 <_start+144>: 0x0000fff8 0x31ffd221 0x4320ffd2 0x40443bc0
.0xfe0000e0 <_start+160>: 0x84764142 0x4b020903 0x32020c22 0x837680a0
.0xfe0000f0 <_start+176>: 0x04728211 0x82247282 0x72824472 0x01d22264
.0xfe000100 <_start+192>: 0x1180c222 0xc821ffc8 0x13e620ff 0x41002010
.0xfe000110 <_reset+1>: 0x04d0ffc7 0xffc64100 0x00fffd86 0x1049c500
.0xfe000120: 0xe52049d5 0x49f53049 0x00003400 0x00000000
.0xfe000130: 0x00000000 0x00000000 0x00000000 0x00000000
.(gdb)

Further details on U-Boot in general are in the generic <tt>README</tt> at the top of the U-Boot tree. Details specific to the Xtensa architecture are in <tt>doc/README.xtensa</tt>. Details specific to a board are in <tt>board[/<family>]/<board>/README</tt> (for example <tt>board/avnet/xtav60/README</tt>).

Setting up U-Boot

2010-11-16T09:55:09Z

Piet: /* LX60 and LX200 U-Boot Installation (LX110 in Progress) */

== LX60 and LX200 U-Boot Installation (LX110 in Progress) ==

''('''News:''' The New DC233, with the V3 MMU, is now working. Work is in progress with the Linux 2.6.29-smp kernel to boot from this updated U-Boot. U-Boot is starting to work for the LX110 with the V3_MMU, having a minor problem with the LCD display and the kernel isn't booting, likely need to get the Load Address correct for V3 MMU.

'''Summary:'''

[http://www.denx.de/wiki/UBoot U-Boot] is a very popular boot loader; especially within the [http://elinux.org/Bootloader Embedded Linux community].
The U-Boot loader runs on the FPGA boards which are equipped with a dip switch, number 8, which can select where the memory location for the reset
vector (0XFE00,0000) comes from. With switch number 8 off the board will map the memory at the reset vector to a small block of SRAM located in the
I/O block with the UART and Ethernet buffer memory. When switch number 8 is on the Avnet boards map the beginning of the Flash Memory at 0XF800,000
to the reset vector at 0xFE00,000.

What we are going to do here is build a version of U-Boot for your Avnet board and Variant, install that ELF file into memory
with xt-gdb and run U-Boot. Then we are going to download a another copy of this identical program with '''tftp'''. The version we
are going to download is just the ELF file with the headers and debug information removed. It's just the actual bits that get
loaded into memory. For the new V3 MMU the default '''loadaddr''' is typically 0x20,0000 and for the older V2 MMU this is in the
Linux mapping equivalent, 0xD0200,0000. The default location can be change by setting the U-Boot 'loadaddr' environment variable
or by changing the variable '''CONFIG_SYS_LOAD_ADDR''' in the boards U-Boot config file.

Once the virgin copy of the U-Boot program has been loaded into memory, the Flash memory is un-protected and errasd, then the
memory with the U-Boot program in it is copied to the flash memory and protected. Next you will set dip switch 8 on, recycle
power on the board, and U-Boot will be accessible via the serial UART at 38400 baud. U-Boot works without any MMU mapping,
and should be fine on configurations without an MMU. Only an ethernet and serial interface are required.

'''Proceedure:'''

A local port to the Xtensa architecture is now available at linux-xtensa.org. See [http://git.linux-xtensa.org/cgi-bin/git.cgi?p=u-boot/u-boot-xtensa.git;a=summary U-Boot Sources (GIT Summary)]. Or, to access this tree using <tt>git</tt> directly, use something like:

$ '''git clone git://git.linux-xtensa.org/git/u-boot/u-boot-xtensa.git u-boot'''
$ '''cd u-boot'''

''('''Note:''' This path is subject to change.)''

The U-Boot git repository has a branch with a HiFi 2 snapshot made for
the LX200 [[SMP HiFi 2 Development Board]]. With this branch you can simply check
out the snapshot_2+SMP branch which includes the binaries which are discussed below:

$ '''git clone git://git.linux-xtensa.org/git/u-boot/u-boot-xtensa.git u-boot'''
$ '''cd u-boot'''
$ '''git branch --track snapshot_2+SMP origin/snapshot_2+SMP'''
$ '''git checkout snapshot_2+SMP'''

$ '''ls -l u-boot u-boot.bin tools/mkimage'''
-rwxr-xr-x 1 piet tensilica 45016 2009-12-07 19:40 tools/mkimage [This is a small program you need to put in your search path to build kernel U-Boot images]
-rwxr-xr-x 1 piet tensilica 635339 2009-12-07 19:40 u-boot [Started with xt-gdb to bring up the 1st instance of a HiFi 2 U-Boot]
-rwxr-xr-x 1 piet tensilica 144944 2009-12-07 19:40 u-boot.bin [Loaded by the 1st instance of U-Boot, it's a HiFi2 version of u-boot that will be put in flash]
$

Unless you are using a U-Boot snapshot you need to build U-Boot for which you must have built the Buildroot toolchain for XTensa core.
Set your PATH to point to the toolchain built using buildroot. For example:

$ '''export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"'''

where '''<cname>''' is the name of the Xtensa core variant you wish to build for (e.g., <tt>dc232b</tt> <tt>dc233c</tt>).

To build U-Boot, use the cloned git tree pulled above, you should be at the top level of the tree in the '''u-boot''' directory , then configure it for your board and Xtensa core variant as follows:

make distclean
make <cname>'''_<board>_'''config
'dc232b'dc
This should only take a few seconds. For example, to build U-boot for the 'xtav60' board and the older 'dc232b' core with the V2 MMU type:

$ '''cd u-boot'''
$ '''make dc232b_xtav60_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

or for the new 'dc233c' core with the new V3 MMU type:

$ '''make dc233c_xtav60_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

or for a 'xtav200' board type with the new 'dc233c' core type:

$ '''make dc233c_xtav200_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

or for the snapshot_2+SMP branch you can also build U-Boot for the HiFi 2 core:

$ '''make test_mmuhifi_c3_xtav200_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

Only boards and core variants currently supported in the tree can be built out of the box. Headers for supported cores can be found in the tree under <tt>include/asm-xtensa/variant-<cname></tt>. The core specific headers are described in the <tt>doc/README.xtensa</tt> file. To support a new core, these headers must be copied from the overlay in the same way as for the linux kernel.

After the configuration step, to actually build U-Boot, simply:

$ '''make all''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

This will take a quite a few minutes.

Next, start xt-gdb and load u-boot from the top of the git repository:

$ '''xt-gdb -n''' [NOTE: Even with the HiFi 2 snapshot_2+SMP branch you still may have to put U-Boot on the board]
(xt-gdb) '''file u-boot'''
(xt-gdb) '''target remote localhost:20000 0'''
(xt-gdb) '''reset'''
(xt-gdb) '''load'''
(xt-gdb) '''break panic'''
(xt-gdb) '''continue'''

Hopefully U-Boot will start, and display on the LCD in the case of a LX60.

U-Boot 50.00 Mhz

Often you will be starting with the boards flash in an unknown state and it's best to unprotect and erase the entire flash. Just type '''protect off all''' followed by '''erase all''':

U-Boot> '''protect off all'''
Un-Protect Flash Bank # 1
................................................................................................................................... done
U-Boot> '''erase all'''
Erase Flash Bank # 1
..........................................................................................................
Flash erase timeout at address f8d40000 da0
Flash erase error at address f8d40000
........................ done
U-Boot>

The timeout and error messages are likley just warning messages and you board has been errased. You can see that with the flash info command '''flinfo'''. Below is an example with a LX200 board, which has a much larger flash than the smaller LX60:

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
F8000000 E F8020000 E F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E F8FE0000 E F8FE8000 E F8FF0000 E
F8FF8000 E
U-Boot>

The new LX110 looks very similar to the LX200, also with with 16Mb of Flash:

U-Boot> flinfo

Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 32 bytes

Sector Start Addresses:
F8000000 E F8020000 E F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E F8FE0000 E

Now set your preliminary U-Boot environment variables to point to your TFTP server so we can download yet another copy of U-Boot. At Tensilica we use a machine in the RTOS group called rtos-lab2. Folks using the [[SMP HiFi 2 Development Board]] likely have set up their workstation with a TFTP server.

U-Boot> '''setenv serverip 192.168.11.78''' rtos-lab2
or
U-Boot> '''setenv serverip 192.168.11.55''' pdelaney_fc9

U-Boot> '''setenv ipaddr 192.168.11.95''' I/P address of RTOS5, Piet's LX60; MAC: 00:05:C2:13:6f:0a

U-Boot> '''setenv bootfile u-boot.bin'''
U-Boot> '''saveenv'''
Saving Environment to Flash...
.... done
Un-Protected 4 sectors
Erasing Flash...
.... done
Erased 4 sectors
Writing to Flash... done
.... done
Protected 4 sectors
U-Boot>

Next, download '''u-boot.bin''' from the tftp server using the info we just entered into U-Boot's enviroment variables.
Here for example is the case for a LX60 running the HiFi-2 Bitstream with the older V2 MMU. Note that it starts up
in the D-gazillion (0XD0000000) region:

U-Boot> '''tftpboot'''
TFTP from server 192.168.11.78; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0xd2000000
Loading: T ########
done
Bytes transferred = 107592 (1a448 hex)

For the V3 MMU U-Boot is loaded from host pdelaney_fc9 into memory with virtual == physical. Here is a DC233L, with V3 MMU, example:

U-Boot> '''tftpboot'''
Using open_ethernet device
TFTP from server 192.168.11.55; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: T ########
done
Bytes transferred = 109964 (1ad8c hex)
U-Boot>

Now things get a bit tricky here for the LX60. The FLASH has '''Two sizes of Flash Sectors'''.
The first 8 sectors are small 0x2000 (8KB) and apparently intended for parameters. The rest
of the 4MB flash is composed of larger 0x10000 (64KB) sectors. Our code doesn't differentiate
between the sectors and the LX60 hardware is going to map 0XF800,0000 to 0XFE00,0000 so this
makes us use of all 8 of the 8KB sectors and the 1st 64KB sector at F8010000. So we are going
to flash up to F801FFFF below.

On a LX200 we have much more space and can easily fit a version of U-boot that has been compiled without optimization, make debugging much easier.
So in this case the image is a bit larger, but relatively similar to the LX60 (2 sectors):

U-Boot> '''tftpboot'''
Using open_ethernet device
TFTP from server 192.168.11.78; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0xd2000000
Loading: ###############
done
Bytes transferred = 205852 (3241c hex)
U-Boot>

On a LX110 we have less memory than an LX60, but FLASH sectors like the LX200. It turns out that the u-boot image
compiled with optimization is just a bit larger than 1 sector, so like the LX200 we will need to write u-boot
into two sectors. Here's and example tftpboot of U-Bot for the LX110:

U-Boot> tftpboot
Using open_ethernet device
TFTP from server 192.168.11.55; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: ##########
done
Bytes transferred = 144956 (2363c hex)
U-Boot>

Note that for both the LX200 and the LX60 that the image size, '''(3241c hex)''' in this case, is a bit less than 0x40000 or 10 sectors,
so turn off protection on the 1st 11 sectors and
erase the current contents.

For the '''LX60''' you do this:

U-Boot> '''protect off F8000000 F801FFFF'''
... done
Un-Protected 2 sectors
U-Boot> '''erase F8000000 F801FFFF'''
erase F8000000 F801FFFF
... done

For the '''LX200''' and the '''LX110''' the starting address '''(F8000000)''' is the same as with the LX60 but the last address '''(F803FFFF)''' is 'twice' as high:

U-Boot> '''protect off F8000000 F803FFFF'''
... done
Un-Protected 2 sectors
U-Boot> '''erase F8000000 F803FFFF'''
Erased 2 sectors
U-Boot>

Now copy the the image of u-boot.bin in memory to the flash. For the XL60 with the '''OLD''' V2 MMU you copy 0x20000
bytes from 0xd2000000 to 0XF8000000:

U-Boot> '''cp.b d2000000 F8000000 20000'''
Copy to Flash... done

For the LX60 with the '''NEW''' V3 MMU you copy 0x24000 bytes from 0x2000000 to F8000000:

U-Boot> '''cp.b 2000000 F8000000 20000'''
Copy to Flash... done

For the LX200 you copy 0x40000 bytes from 0xd2000000 to 0XF8000000...0XF803FFFF:

U-Boot> '''cp.b d2000000 F8000000 40000'''
Copy to Flash... done

For the LX110 with a V3-MMU you copy 0x40000 bytes from 0x2000000 to F8000000:
U-Boot> cp.b 2000000 F8000000 40000
Copy to Flash... done

Finally we protect these sectors so that U-Boot isn't easily erased by accident.
Below is what it looks like on a LX60 with the New V3 MMU with a subsequent display of the flash info:

U-Boot> '''cp.b 2000000 F8000000 2000'''
Copy to Flash... done
U-Boot> flinfo

Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x2257
Erase timeout: 8192 ms, write timeout: 1 ms

Sector Start Addresses:
'''F8000000 F8002000 F8004000 F8006000 F8008000'''
'''F800A000 F800C000 F800E000 F8010000 '''F8020000 E
F8030000 E F8040000 E F8050000 E F8060000 E F8070000 E
F8080000 E F8090000 E F80A0000 E F80B0000 E F80C0000 E
F80D0000 E F80E0000 E F80F0000 E F8100000 E F8110000 E
F8120000 E F8130000 E F8140000 E F8150000 E F8160000 E
F8170000 E F8180000 E F8190000 E F81A0000 E F81B0000 E
F81C0000 E F81D0000 E F81E0000 E F81F0000 E F8200000 E
F8210000 E F8220000 E F8230000 E F8240000 E F8250000 E
F8260000 E F8270000 E F8280000 E F8290000 E F82A0000 E
F82B0000 E F82C0000 E F82D0000 E F82E0000 E F82F0000 E
F8300000 E F8310000 E F8320000 E F8330000 E F8340000 E
F8350000 E F8360000 E F8370000 E F8380000 E F8390000 E
F83A0000 E F83B0000 E F83C0000 E F83D0000 E F83E0000
'''F83F0000 RO'''
U-Boot> '''protect on F8000000 F802FFFF'''
.......... done
Protected 10 sectors
U-Boot>

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x2257
Erase timeout: 8192 ms, write timeout: 1 ms

Sector Start Addresses:
'''F8000000 RO F8002000 RO F8004000 RO F8006000 RO F8008000 RO
F800A000 RO F800C000 RO F800E000 RO F8010000 RO''' F8020000 E
F8030000 E F8040000 E F8050000 E F8060000 E F8070000 E
F8080000 E F8090000 E F80A0000 E F80B0000 E F80C0000 E
F80D0000 E F80E0000 E F80F0000 E F8100000 E F8110000 E
F8120000 E F8130000 E F8140000 E F8150000 E F8160000 E
F8170000 E F8180000 E F8190000 E F81A0000 E F81B0000 E
F81C0000 E F81D0000 E F81E0000 E F81F0000 E F8200000 E
F8210000 E F8220000 E F8230000 E F8240000 E F8250000 E
F8260000 E F8270000 E F8280000 E F8290000 E F82A0000 E
F82B0000 E F82C0000 E F82D0000 E F82E0000 E F82F0000 E
F8300000 E F8310000 E F8320000 E F8330000 E F8340000 E
F8350000 E F8360000 E F8370000 E F8380000 E F8390000 E
F83A0000 E F83B0000 E F83C0000 E F83D0000 E F83E0000
'''F83F0000 RO'''
U-Boot>

For the '''LX110''' with the '''V3-MMU''' here's what the flash info looks like after we
protect the first two sectors with U-Boot copied to it:

U-Boot> '''protect on F8000000 F803FFFF'''
Protected 2 sectors
U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 32 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E '''F8FE0000 RO'''
U-Boot> help

Below is what it looks like on a '''LX200''' with the '''V2 MMU''' with a subsequent display of the flash info.
Notice that the Flash Sectors are 10X as large on the LX200:

U-Boot> '''protect on F8000000 F802FFFF'''
.. done
Protected 2 sectors
U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E '''F8FE0000 RO F8FE8000 RO F8FF0000 RO'''
'''F8FF8000 RO'''
U-Boot>

Note that the U-Boot '''saveenv''' command Erased and protected the last four sectors
of this LX200.

On both the LX60 and the LX200 now move DIP switch 8 to the ON position, on the LX110 move DIP switch 4 to the ON position.
Next, power cycle the board. On the LX60 you should see U-boot in the LCD display.

The '''LX60''' with the new '''V3 MMU''' the serial console should print something like the following:

U-Boot 2009.08-dirty (Sep 10 2010 - 18:23:26)

CPU: Xtensa dc233c at 50.00 MHz
Board: XT-AV60: Avnet board + Xilinx LX60 FPGA + Tensilica bitstream
SysRAM: 64 MB
Flash: 4 MB
In: serial
Out: serial
Err: serial
MAC: 00:50:C2:13:6f:0a
IP: 192.168.11.95
open_ethernet
U-Boot>

On the '''LX110''' with the new '''V3 MMU''' the serial console should print something like the following:

U-Boot 2009.08-dirty (Nov 15 2010 - 23:04:45)

CPU: Xtensa dc233c at 50.00 MHz
Board: XT-AV110: Avnet board + Xilinx LX110 FPGA + Tensilica bitstream
SysRAM: 48 MB
Flash: 16 MB
In: serial
Out: serial
Err: serial
MAC: 00:50:C2:13:6f:00
IP: 192.168.11.95
open_ethernet
U-Boot>

On the '''LX200''', shown below with the old V2 MMU, you should see something like the following. In this case we also show the flash info command, '''flinfo''', being invoked just after booting U-Boot:

U-Boot 2009.08-dirty (Nov 15 2010 - 23:04:45)

CPU: Xtensa test_mmuhifi_c3 at 41.6777 MHz
Board: XT-AV200: Avnet board + Xilinx LX200 FPGA + Tensilica bitstream
SysRAM: 96 MB
Flash: 16 MB
In: serial
Out: serial
Err: serial
MAC:
IP: 192.168.11.95
U-Boot>

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E RO F8060000 E RO F8080000 E RO
F80A0000 E RO F80C0000 E RO F80E0000 E RO F8100000 E RO F8120000 E RO
F8140000 E RO F8160000 E RO F8180000 E RO F81A0000 E RO F81C0000 E RO
F81E0000 E RO F8200000 E RO F8220000 E RO F8240000 E RO F8260000 E RO
F8280000 E RO F82A0000 E RO F82C0000 E RO F82E0000 E RO F8300000 E RO
F8320000 E RO F8340000 E RO F8360000 E RO F8380000 E RO F83A0000 E RO
F83C0000 E RO F83E0000 E RO F8400000 E RO F8420000 E RO F8440000 E RO
F8460000 E RO F8480000 E RO F84A0000 E RO F84C0000 E RO F84E0000 E RO
F8500000 E RO F8520000 E RO F8540000 E RO F8560000 E RO F8580000 E RO
F85A0000 E RO F85C0000 E RO F85E0000 E RO F8600000 E RO F8620000 E RO
F8640000 E RO F8660000 E RO F8680000 E RO F86A0000 E RO F86C0000 E RO
F86E0000 E RO F8700000 E RO F8720000 E RO F8740000 E RO F8760000 E RO
F8780000 E RO F87A0000 E RO F87C0000 E RO F87E0000 E RO F8800000 E RO
F8820000 E RO F8840000 E RO F8860000 E RO F8880000 E RO F88A0000 E RO
F88C0000 E RO F88E0000 E RO F8900000 E RO F8920000 E RO F8940000 E RO
F8960000 E RO F8980000 E RO F89A0000 E RO F89C0000 E RO F89E0000 E RO
F8A00000 E RO F8A20000 E RO F8A40000 E RO F8A60000 E RO F8A80000 E RO
F8AA0000 E RO F8AC0000 E RO F8AE0000 E RO F8B00000 E RO F8B20000 E RO
F8B40000 E RO F8B60000 E RO F8B80000 E RO F8BA0000 E RO F8BC0000 E RO
F8BE0000 E RO F8C00000 E RO F8C20000 E RO F8C40000 E RO F8C60000 E RO
F8C80000 E RO F8CA0000 E RO F8CC0000 E RO F8CE0000 E RO F8D00000 E RO
F8D20000 E RO F8D40000 E RO F8D60000 E RO F8D80000 E RO F8DA0000 E RO
F8DC0000 E RO F8DE0000 E RO F8E00000 E RO F8E20000 E RO F8E40000 E RO
F8E60000 E RO F8E80000 E RO F8EA0000 E RO F8EC0000 E RO F8EE0000 E RO
F8F00000 E RO F8F20000 E RO F8F40000 E RO F8F60000 E RO F8F80000 E RO
F8FA0000 E RO F8FC0000 E RO '''F8FE0000 RO F8FE8000 RO F8FF0000 RO'''
'''F8FF8000 RO'''
U-Boot>

Note that the 1st two sectors with U-Boot saved in them came up as not being erased ('''E''') but that all sectors came up Read Only ('''RO''').
Same with the last four sectors that the U-Boot '''saveenv''' command Erased. This is likely a '''bug''' on the LX200 boards with some preliminary investigation.
We will be discussing this with the U-Boot developers sometime in the future prior to pushing our U-boot changes upstream.

If U-Boot fails to boot ya might try making sure your U-Boot '''serverip''' environment variable matches the address of the tftp server where
you have copied your '''u-boot.bin''' file to and comparing the bits in the flash that got mapped to 0xfe00,0000 to what in the file:

u-boot]$ '''od -t x4 u-boot.bin | more'''
.0000000 00000206 fe000040 ffffffff a0fffe21
.0000020 00000002 fe01ad14 fe01ad8c 03f95030
.0000040 03f9aa78 04000000 00040003 03f8147c
.0000060 03f81418 00000000 00000000 00000000
.0000100 5300000c 13a00013 4800130c 13493013
.0000120 0c130200 13e62032 22002010 a03200a0
.0000140 1d837680 82037282 72822372 63728243
.0000160 72007272 72720872 18727210 2201d222
.0000200 020c80c2 3d80a032 1d8376f0 d20372d2
.0000220 72d22372 6372d243 f20072f2 72f20872
.0000240 1872f210 2201d222 200080c2 ffd92100
.0000260 37ffda31 02481d12 22681258 145722cb
.0000300 ee1467f1 664b0678 444b0479 06f43457
.0000320 0000fff8 31ffd221 4320ffd2 40443bc0
.0000340 84764142 4b020903 32020c22 837680a0
.0000360 04728211 82247282 72824472 01d22264
.0000400 1180c222 c821ffc8 13e620ff 41002010
.0000420 04d0ffc7 ffc64100 fffffd86 1049c500
.0000440 e52049d5 49f53049 00003400 00000000
.0000460 00000000 00000000 00000000 00000000
.
.(gdb) '''x/100x 0xfe000000'''
.0xfe000000 <_ResetVector>: 0x00000206 0xfe000040 0xffffffff 0xa0fffe21
.0xfe000010 <_ResetVector+16>: 0x00000002 0xfe01ad14 0xfe01ad8c 0x03f95030
.0xfe000020 <_ResetVector+32>: 0x03f9aa78 0x04000000 0x00040003 0x03f8147c
.0xfe000030 <_ResetVector+48>: 0x03f81418 0x00000000 0x00000000 0x00000000
.0xfe000040 <_start>: 0x5300000c 0x13a00013 0x4800130c 0x13493013
.0xfe000050 <_start+16>: 0x0c130200 0x13e62032 0x22002010 0xa03200a0
.0xfe000060 <_start+32>: 0x1d837680 0x82037282 0x72822372 0x63728243
.0xfe000070 <_start+48>: 0x72007272 0x72720872 0x18727210 0x2201d222
.0xfe000080 <_start+64>: 0x020c80c2 0x3d80a032 0x1d8376f0 0xd20372d2
.0xfe000090 <_start+80>: 0x72d22372 0x6372d243 0xf20072f2 0x72f20872
.0xfe0000a0 <_start+96>: 0x1872f210 0x2201d222 0x200080c2 0xffd92100
.0xfe0000b0 <_start+112>: 0x37ffda31 0x02481d12 0x22681258 0x145722cb
.0xfe0000c0 <_start+128>: 0xee1467f1 0x664b0678 0x444b0479 0x06f43457
.0xfe0000d0 <_start+144>: 0x0000fff8 0x31ffd221 0x4320ffd2 0x40443bc0
.0xfe0000e0 <_start+160>: 0x84764142 0x4b020903 0x32020c22 0x837680a0
.0xfe0000f0 <_start+176>: 0x04728211 0x82247282 0x72824472 0x01d22264
.0xfe000100 <_start+192>: 0x1180c222 0xc821ffc8 0x13e620ff 0x41002010
.0xfe000110 <_reset+1>: 0x04d0ffc7 0xffc64100 0x00fffd86 0x1049c500
.0xfe000120: 0xe52049d5 0x49f53049 0x00003400 0x00000000
.0xfe000130: 0x00000000 0x00000000 0x00000000 0x00000000
.(gdb)

Further details on U-Boot in general are in the generic <tt>README</tt> at the top of the U-Boot tree. Details specific to the Xtensa architecture are in <tt>doc/README.xtensa</tt>. Details specific to a board are in <tt>board[/<family>]/<board>/README</tt> (for example <tt>board/avnet/xtav60/README</tt>).

Setting up U-Boot

2010-11-16T09:52:24Z

Piet: /* LX60 and LX200 U-Boot Installation (LX110 in Progress, UART and FLASH Working, fixing LCD) */

== LX60 and LX200 U-Boot Installation (LX110 in Progress) ==

''('''News:''' The New DC233, with the V3 MMU, is now working. Work is in progress with the Linux 2.6.29-smp kernel to boot from this updated U-Boot. U-Boot is starting to work for the LX110 with the V3_MMU, having a minor problem with the LCD display and the kernel isn't booting, likely need to get the Load Address correct for V3 MMU.

'''Summary:'''

[http://www.denx.de/wiki/UBoot U-Boot] is a very popular boot loader; especially within the [http://elinux.org/Bootloader Embedded Linux community].
The U-Boot loader runs on the FPGA boards which are equipped with a dip switch, number 8, which can select where the memory location for the reset
vector (0XFE00,0000) comes from. With switch number 8 off the board will map the memory at the reset vector to a small block of SRAM located in the
I/O block with the UART and Ethernet buffer memory. When switch number 8 is on the Avnet boards map the beginning of the Flash Memory at 0XF800,000
to the reset vector at 0xFE00,000.

What we are going to do here is build a version of U-Boot for your Avnet board and Variant, install that ELF file into memory
with xt-gdb and run U-Boot. Then we are going to download a another copy of this identical program with '''tftp'''. The version we
are going to download is just the ELF file with the headers and debug information removed. It's just the actual bits that get
loaded into memory. For the new V3 MMU the default '''loadaddr''' is typically 0x20,0000 and for the older V2 MMU this is in the
Linux mapping equivalent, 0xD0200,0000. The default location can be change by setting the U-Boot 'loadaddr' environment variable
or by changing the variable '''CONFIG_SYS_LOAD_ADDR''' in the boards U-Boot config file.

Once the virgin copy of the U-Boot program has been loaded into memory, the Flash memory is un-protected and errasd, then the
memory with the U-Boot program in it is copied to the flash memory and protected. Next you will set dip switch 8 on, recycle
power on the board, and U-Boot will be accessible via the serial UART at 38400 baud. U-Boot works without any MMU mapping,
and should be fine on configurations without an MMU. Only an ethernet and serial interface are required.

'''Proceedure:'''

A local port to the Xtensa architecture is now available at linux-xtensa.org. See [http://git.linux-xtensa.org/cgi-bin/git.cgi?p=u-boot/u-boot-xtensa.git;a=summary U-Boot Sources (GIT Summary)]. Or, to access this tree using <tt>git</tt> directly, use something like:

$ '''git clone git://git.linux-xtensa.org/git/u-boot/u-boot-xtensa.git u-boot'''
$ '''cd u-boot'''

''('''Note:''' This path is subject to change.)''

The U-Boot git repository has a branch with a HiFi 2 snapshot made for
the LX200 [[SMP HiFi 2 Development Board]]. With this branch you can simply check
out the snapshot_2+SMP branch which includes the binaries which are discussed below:

$ '''git clone git://git.linux-xtensa.org/git/u-boot/u-boot-xtensa.git u-boot'''
$ '''cd u-boot'''
$ '''git branch --track snapshot_2+SMP origin/snapshot_2+SMP'''
$ '''git checkout snapshot_2+SMP'''

$ '''ls -l u-boot u-boot.bin tools/mkimage'''
-rwxr-xr-x 1 piet tensilica 45016 2009-12-07 19:40 tools/mkimage [This is a small program you need to put in your search path to build kernel U-Boot images]
-rwxr-xr-x 1 piet tensilica 635339 2009-12-07 19:40 u-boot [Started with xt-gdb to bring up the 1st instance of a HiFi 2 U-Boot]
-rwxr-xr-x 1 piet tensilica 144944 2009-12-07 19:40 u-boot.bin [Loaded by the 1st instance of U-Boot, it's a HiFi2 version of u-boot that will be put in flash]
$

Unless you are using a U-Boot snapshot you need to build U-Boot for which you must have built the Buildroot toolchain for XTensa core.
Set your PATH to point to the toolchain built using buildroot. For example:

$ '''export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"'''

where '''<cname>''' is the name of the Xtensa core variant you wish to build for (e.g., <tt>dc232b</tt> <tt>dc233c</tt>).

To build U-Boot, use the cloned git tree pulled above, you should be at the top level of the tree in the '''u-boot''' directory , then configure it for your board and Xtensa core variant as follows:

make distclean
make <cname>'''_<board>_'''config
'dc232b'dc
This should only take a few seconds. For example, to build U-boot for the 'xtav60' board and the older 'dc232b' core with the V2 MMU type:

$ '''cd u-boot'''
$ '''make dc232b_xtav60_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

or for the new 'dc233c' core with the new V3 MMU type:

$ '''make dc233c_xtav60_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

or for a 'xtav200' board type with the new 'dc233c' core type:

$ '''make dc233c_xtav200_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

or for the snapshot_2+SMP branch you can also build U-Boot for the HiFi 2 core:

$ '''make test_mmuhifi_c3_xtav200_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

Only boards and core variants currently supported in the tree can be built out of the box. Headers for supported cores can be found in the tree under <tt>include/asm-xtensa/variant-<cname></tt>. The core specific headers are described in the <tt>doc/README.xtensa</tt> file. To support a new core, these headers must be copied from the overlay in the same way as for the linux kernel.

After the configuration step, to actually build U-Boot, simply:

$ '''make all''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

This will take a quite a few minutes.

Next, start xt-gdb and load u-boot from the top of the git repository:

$ '''xt-gdb -n''' [NOTE: Even with the HiFi 2 snapshot_2+SMP branch you still may have to put U-Boot on the board]
(xt-gdb) '''file u-boot'''
(xt-gdb) '''target remote localhost:20000 0'''
(xt-gdb) '''reset'''
(xt-gdb) '''load'''
(xt-gdb) '''break panic'''
(xt-gdb) '''continue'''

Hopefully U-Boot will start, and display on the LCD in the case of a LX60.

U-Boot 50.00 Mhz

Often you will be starting with the boards flash in an unknown state and it's best to unprotect and erase the entire flash. Just type '''protect off all''' followed by '''erase all''':

U-Boot> '''protect off all'''
Un-Protect Flash Bank # 1
................................................................................................................................... done
U-Boot> '''erase all'''
Erase Flash Bank # 1
..........................................................................................................
Flash erase timeout at address f8d40000 da0
Flash erase error at address f8d40000
........................ done
U-Boot>

The timeout and error messages are likley just warning messages and you board has been errased. You can see that with the flash info command '''flinfo'''. Below is an example with a LX200 board, which has a much larger flash than the smaller LX60:

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
F8000000 E F8020000 E F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E F8FE0000 E F8FE8000 E F8FF0000 E
F8FF8000 E
U-Boot>

The new LX110 looks very similar to the LX200, also with with 16Mb of Flash:

U-Boot> flinfo

Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 32 bytes

Sector Start Addresses:
F8000000 E F8020000 E F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E F8FE0000 E

Now set your preliminary U-Boot environment variables to point to your TFTP server so we can download yet another copy of U-Boot. At Tensilica we use a machine in the RTOS group called rtos-lab2. Folks using the [[SMP HiFi 2 Development Board]] likely have set up their workstation with a TFTP server.

U-Boot> '''setenv serverip 192.168.11.78''' rtos-lab2
or
U-Boot> '''setenv serverip 192.168.11.55''' pdelaney_fc9

U-Boot> '''setenv ipaddr 192.168.11.95''' I/P address of RTOS5, Piet's LX60; MAC: 00:05:C2:13:6f:0a

U-Boot> '''setenv bootfile u-boot.bin'''
U-Boot> '''saveenv'''
Saving Environment to Flash...
.... done
Un-Protected 4 sectors
Erasing Flash...
.... done
Erased 4 sectors
Writing to Flash... done
.... done
Protected 4 sectors
U-Boot>

Next, download '''u-boot.bin''' from the tftp server using the info we just entered into U-Boot's enviroment variables.
Here for example is the case for a LX60 running the HiFi-2 Bitstream with the older V2 MMU. Note that it starts up
in the D-gazillion (0XD0000000) region:

U-Boot> '''tftpboot'''
TFTP from server 192.168.11.78; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0xd2000000
Loading: T ########
done
Bytes transferred = 107592 (1a448 hex)

For the V3 MMU U-Boot is loaded from host pdelaney_fc9 into memory with virtual == physical. Here is a DC233L, with V3 MMU, example:

U-Boot> '''tftpboot'''
Using open_ethernet device
TFTP from server 192.168.11.55; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: T ########
done
Bytes transferred = 109964 (1ad8c hex)
U-Boot>

Now things get a bit tricky here for the LX60. The FLASH has '''Two sizes of Flash Sectors'''.
The first 8 sectors are small 0x2000 (8KB) and apparently intended for parameters. The rest
of the 4MB flash is composed of larger 0x10000 (64KB) sectors. Our code doesn't differentiate
between the sectors and the LX60 hardware is going to map 0XF800,0000 to 0XFE00,0000 so this
makes us use of all 8 of the 8KB sectors and the 1st 64KB sector at F8010000. So we are going
to flash up to F801FFFF below.

On a LX200 we have much more space and can easily fit a version of U-boot that has been compiled without optimization, make debugging much easier.
So in this case the image is a bit larger, but relatively similar to the LX60 (2 sectors):

U-Boot> '''tftpboot'''
Using open_ethernet device
TFTP from server 192.168.11.78; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0xd2000000
Loading: ###############
done
Bytes transferred = 205852 (3241c hex)
U-Boot>

On a LX110 we have less memory than an LX60, but FLASH sectors like the LX200. It turns out that the u-boot image
compiled with optimization is just a bit larger than 1 sector, so like the LX200 we will need to write u-boot
into two sectors. Here's and example tftpboot of U-Bot for the LX110:

U-Boot> tftpboot
Using open_ethernet device
TFTP from server 192.168.11.55; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: ##########
done
Bytes transferred = 144956 (2363c hex)
U-Boot>

Note that for both the LX200 and the LX60 that the image size, '''(3241c hex)''' in this case, is a bit less than 0x40000 or 10 sectors,
so turn off protection on the 1st 11 sectors and
erase the current contents.

For the '''LX60''' you do this:

U-Boot> '''protect off F8000000 F801FFFF'''
... done
Un-Protected 2 sectors
U-Boot> '''erase F8000000 F801FFFF'''
erase F8000000 F801FFFF
... done

For the '''LX200''' and the '''LX110''' the starting address '''(F8000000)''' is the same as with the LX60 but the last address '''(F803FFFF)''' is 'twice' as high:

U-Boot> '''protect off F8000000 F803FFFF'''
... done
Un-Protected 2 sectors
U-Boot> '''erase F8000000 F803FFFF'''
Erased 2 sectors
U-Boot>

Now copy the the image of u-boot.bin in memory to the flash. For the XL60 with the '''OLD''' V2 MMU you copy 0x20000
bytes from 0xd2000000 to 0XF8000000:

U-Boot> '''cp.b d2000000 F8000000 20000'''
Copy to Flash... done

For the LX60 with the '''NEW''' V3 MMU you copy 0x24000 bytes from 0x2000000 to F8000000:

U-Boot> '''cp.b 2000000 F8000000 20000'''
Copy to Flash... done

For the LX200 you copy 0x40000 bytes from 0xd2000000 to 0XF8000000...0XF803FFFF:

U-Boot> '''cp.b d2000000 F8000000 40000'''
Copy to Flash... done

For the LX110 with a V3-MMU you copy 0x40000 bytes from 0x2000000 to F8000000:
U-Boot> cp.b 2000000 F8000000 40000
Copy to Flash... done

Finally we protect these sectors so that U-Boot isn't easily erased by accident.
Below is what it looks like on a LX60 with the New V3 MMU with a subsequent display of the flash info:

U-Boot> '''cp.b 2000000 F8000000 2000'''
Copy to Flash... done
U-Boot> flinfo

Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x2257
Erase timeout: 8192 ms, write timeout: 1 ms

Sector Start Addresses:
'''F8000000 F8002000 F8004000 F8006000 F8008000'''
'''F800A000 F800C000 F800E000 F8010000 '''F8020000 E
F8030000 E F8040000 E F8050000 E F8060000 E F8070000 E
F8080000 E F8090000 E F80A0000 E F80B0000 E F80C0000 E
F80D0000 E F80E0000 E F80F0000 E F8100000 E F8110000 E
F8120000 E F8130000 E F8140000 E F8150000 E F8160000 E
F8170000 E F8180000 E F8190000 E F81A0000 E F81B0000 E
F81C0000 E F81D0000 E F81E0000 E F81F0000 E F8200000 E
F8210000 E F8220000 E F8230000 E F8240000 E F8250000 E
F8260000 E F8270000 E F8280000 E F8290000 E F82A0000 E
F82B0000 E F82C0000 E F82D0000 E F82E0000 E F82F0000 E
F8300000 E F8310000 E F8320000 E F8330000 E F8340000 E
F8350000 E F8360000 E F8370000 E F8380000 E F8390000 E
F83A0000 E F83B0000 E F83C0000 E F83D0000 E F83E0000
'''F83F0000 RO'''
U-Boot> '''protect on F8000000 F802FFFF'''
.......... done
Protected 10 sectors
U-Boot>

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x2257
Erase timeout: 8192 ms, write timeout: 1 ms

Sector Start Addresses:
'''F8000000 RO F8002000 RO F8004000 RO F8006000 RO F8008000 RO
F800A000 RO F800C000 RO F800E000 RO F8010000 RO''' F8020000 E
F8030000 E F8040000 E F8050000 E F8060000 E F8070000 E
F8080000 E F8090000 E F80A0000 E F80B0000 E F80C0000 E
F80D0000 E F80E0000 E F80F0000 E F8100000 E F8110000 E
F8120000 E F8130000 E F8140000 E F8150000 E F8160000 E
F8170000 E F8180000 E F8190000 E F81A0000 E F81B0000 E
F81C0000 E F81D0000 E F81E0000 E F81F0000 E F8200000 E
F8210000 E F8220000 E F8230000 E F8240000 E F8250000 E
F8260000 E F8270000 E F8280000 E F8290000 E F82A0000 E
F82B0000 E F82C0000 E F82D0000 E F82E0000 E F82F0000 E
F8300000 E F8310000 E F8320000 E F8330000 E F8340000 E
F8350000 E F8360000 E F8370000 E F8380000 E F8390000 E
F83A0000 E F83B0000 E F83C0000 E F83D0000 E F83E0000
'''F83F0000 RO'''
U-Boot>

For the '''LX110''' with the '''V3-MMU''' here's what the flash info looks like after we
protect the first two sectors with U-Boot copied to it:

U-Boot> '''protect on F8000000 F803FFFF'''
Protected 2 sectors
U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 32 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E '''F8FE0000 RO'''
U-Boot> help

Below is what it looks like on a LX200 with the V2 MMU with a subsequent display of the flash info.
Notice that the Flash Sectors are 10X as large on the LX200:

U-Boot> '''protect on F8000000 F802FFFF'''
.. done
Protected 2 sectors
U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E '''F8FE0000 RO F8FE8000 RO F8FF0000 RO'''
'''F8FF8000 RO'''
U-Boot>

Note that the U-Boot '''saveenv''' command Erased and protected the last four sectors
of this LX200.

On both the LX60 and the LX200 now move DIP switch 8 to the ON position, on the LX110 move DIP switch 4 to the ON position.
Next, power cycle the board. On the LX60 you should see U-boot in the LCD display.

The '''LX60''' with the new V3 MMU the serial console should print something like the following:

U-Boot 2009.08-dirty (Sep 10 2010 - 18:23:26)

CPU: Xtensa dc233c at 50.00 MHz
Board: XT-AV60: Avnet board + Xilinx LX60 FPGA + Tensilica bitstream
SysRAM: 64 MB
Flash: 4 MB
In: serial
Out: serial
Err: serial
MAC: 00:50:C2:13:6f:0a
IP: 192.168.11.95
open_ethernet
U-Boot>

On the '''LX110 with the new V3 MMU the serial console should print something like the following:

U-Boot 2009.08-dirty (Nov 15 2010 - 23:04:45)

CPU: Xtensa dc233c at 50.00 MHz
Board: XT-AV110: Avnet board + Xilinx LX110 FPGA + Tensilica bitstream
SysRAM: 48 MB
Flash: 16 MB
In: serial
Out: serial
Err: serial
MAC: 00:50:C2:13:6f:00
IP: 192.168.11.95
open_ethernet
U-Boot>

On the '''LX200''', shown below with the old V2 MMU, you should see something like the following. In this case we also show the flash info command, '''flinfo''', being invoked just after booting U-Boot:

U-Boot 2009.08-dirty (Nov 15 2010 - 23:04:45)

CPU: Xtensa test_mmuhifi_c3 at 41.6777 MHz
Board: XT-AV200: Avnet board + Xilinx LX200 FPGA + Tensilica bitstream
SysRAM: 96 MB
Flash: 16 MB
In: serial
Out: serial
Err: serial
MAC:
IP: 192.168.11.95
U-Boot>

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E RO F8060000 E RO F8080000 E RO
F80A0000 E RO F80C0000 E RO F80E0000 E RO F8100000 E RO F8120000 E RO
F8140000 E RO F8160000 E RO F8180000 E RO F81A0000 E RO F81C0000 E RO
F81E0000 E RO F8200000 E RO F8220000 E RO F8240000 E RO F8260000 E RO
F8280000 E RO F82A0000 E RO F82C0000 E RO F82E0000 E RO F8300000 E RO
F8320000 E RO F8340000 E RO F8360000 E RO F8380000 E RO F83A0000 E RO
F83C0000 E RO F83E0000 E RO F8400000 E RO F8420000 E RO F8440000 E RO
F8460000 E RO F8480000 E RO F84A0000 E RO F84C0000 E RO F84E0000 E RO
F8500000 E RO F8520000 E RO F8540000 E RO F8560000 E RO F8580000 E RO
F85A0000 E RO F85C0000 E RO F85E0000 E RO F8600000 E RO F8620000 E RO
F8640000 E RO F8660000 E RO F8680000 E RO F86A0000 E RO F86C0000 E RO
F86E0000 E RO F8700000 E RO F8720000 E RO F8740000 E RO F8760000 E RO
F8780000 E RO F87A0000 E RO F87C0000 E RO F87E0000 E RO F8800000 E RO
F8820000 E RO F8840000 E RO F8860000 E RO F8880000 E RO F88A0000 E RO
F88C0000 E RO F88E0000 E RO F8900000 E RO F8920000 E RO F8940000 E RO
F8960000 E RO F8980000 E RO F89A0000 E RO F89C0000 E RO F89E0000 E RO
F8A00000 E RO F8A20000 E RO F8A40000 E RO F8A60000 E RO F8A80000 E RO
F8AA0000 E RO F8AC0000 E RO F8AE0000 E RO F8B00000 E RO F8B20000 E RO
F8B40000 E RO F8B60000 E RO F8B80000 E RO F8BA0000 E RO F8BC0000 E RO
F8BE0000 E RO F8C00000 E RO F8C20000 E RO F8C40000 E RO F8C60000 E RO
F8C80000 E RO F8CA0000 E RO F8CC0000 E RO F8CE0000 E RO F8D00000 E RO
F8D20000 E RO F8D40000 E RO F8D60000 E RO F8D80000 E RO F8DA0000 E RO
F8DC0000 E RO F8DE0000 E RO F8E00000 E RO F8E20000 E RO F8E40000 E RO
F8E60000 E RO F8E80000 E RO F8EA0000 E RO F8EC0000 E RO F8EE0000 E RO
F8F00000 E RO F8F20000 E RO F8F40000 E RO F8F60000 E RO F8F80000 E RO
F8FA0000 E RO F8FC0000 E RO '''F8FE0000 RO F8FE8000 RO F8FF0000 RO'''
'''F8FF8000 RO'''
U-Boot>

Note that the 1st two sectors with U-Boot saved in them came up as not being erased ('''E''') but that all sectors came up Read Only ('''RO''').
Same with the last four sectors that the U-Boot '''saveenv''' command Erased. This is likely a '''bug''' on the LX200 boards with some preliminary investigation.
We will be discussing this with the U-Boot developers sometime in the future prior to pushing our U-boot changes upstream.

If U-Boot fails to boot ya might try making sure your U-Boot '''serverip''' environment variable matches the address of the tftp server where
you have copied your '''u-boot.bin''' file to and comparing the bits in the flash that got mapped to 0xfe00,0000 to what in the file:

u-boot]$ '''od -t x4 u-boot.bin | more'''
.0000000 00000206 fe000040 ffffffff a0fffe21
.0000020 00000002 fe01ad14 fe01ad8c 03f95030
.0000040 03f9aa78 04000000 00040003 03f8147c
.0000060 03f81418 00000000 00000000 00000000
.0000100 5300000c 13a00013 4800130c 13493013
.0000120 0c130200 13e62032 22002010 a03200a0
.0000140 1d837680 82037282 72822372 63728243
.0000160 72007272 72720872 18727210 2201d222
.0000200 020c80c2 3d80a032 1d8376f0 d20372d2
.0000220 72d22372 6372d243 f20072f2 72f20872
.0000240 1872f210 2201d222 200080c2 ffd92100
.0000260 37ffda31 02481d12 22681258 145722cb
.0000300 ee1467f1 664b0678 444b0479 06f43457
.0000320 0000fff8 31ffd221 4320ffd2 40443bc0
.0000340 84764142 4b020903 32020c22 837680a0
.0000360 04728211 82247282 72824472 01d22264
.0000400 1180c222 c821ffc8 13e620ff 41002010
.0000420 04d0ffc7 ffc64100 fffffd86 1049c500
.0000440 e52049d5 49f53049 00003400 00000000
.0000460 00000000 00000000 00000000 00000000
.
.(gdb) '''x/100x 0xfe000000'''
.0xfe000000 <_ResetVector>: 0x00000206 0xfe000040 0xffffffff 0xa0fffe21
.0xfe000010 <_ResetVector+16>: 0x00000002 0xfe01ad14 0xfe01ad8c 0x03f95030
.0xfe000020 <_ResetVector+32>: 0x03f9aa78 0x04000000 0x00040003 0x03f8147c
.0xfe000030 <_ResetVector+48>: 0x03f81418 0x00000000 0x00000000 0x00000000
.0xfe000040 <_start>: 0x5300000c 0x13a00013 0x4800130c 0x13493013
.0xfe000050 <_start+16>: 0x0c130200 0x13e62032 0x22002010 0xa03200a0
.0xfe000060 <_start+32>: 0x1d837680 0x82037282 0x72822372 0x63728243
.0xfe000070 <_start+48>: 0x72007272 0x72720872 0x18727210 0x2201d222
.0xfe000080 <_start+64>: 0x020c80c2 0x3d80a032 0x1d8376f0 0xd20372d2
.0xfe000090 <_start+80>: 0x72d22372 0x6372d243 0xf20072f2 0x72f20872
.0xfe0000a0 <_start+96>: 0x1872f210 0x2201d222 0x200080c2 0xffd92100
.0xfe0000b0 <_start+112>: 0x37ffda31 0x02481d12 0x22681258 0x145722cb
.0xfe0000c0 <_start+128>: 0xee1467f1 0x664b0678 0x444b0479 0x06f43457
.0xfe0000d0 <_start+144>: 0x0000fff8 0x31ffd221 0x4320ffd2 0x40443bc0
.0xfe0000e0 <_start+160>: 0x84764142 0x4b020903 0x32020c22 0x837680a0
.0xfe0000f0 <_start+176>: 0x04728211 0x82247282 0x72824472 0x01d22264
.0xfe000100 <_start+192>: 0x1180c222 0xc821ffc8 0x13e620ff 0x41002010
.0xfe000110 <_reset+1>: 0x04d0ffc7 0xffc64100 0x00fffd86 0x1049c500
.0xfe000120: 0xe52049d5 0x49f53049 0x00003400 0x00000000
.0xfe000130: 0x00000000 0x00000000 0x00000000 0x00000000
.(gdb)

Further details on U-Boot in general are in the generic <tt>README</tt> at the top of the U-Boot tree. Details specific to the Xtensa architecture are in <tt>doc/README.xtensa</tt>. Details specific to a board are in <tt>board[/<family>]/<board>/README</tt> (for example <tt>board/avnet/xtav60/README</tt>).

Setting up U-Boot

2010-11-16T09:40:06Z

Piet: /* LX60 and LX200 U-Boot Installation (LX110 in Progress, UART and FLASH Working, fixing LCD) */

== LX60 and LX200 U-Boot Installation (LX110 in Progress, UART and FLASH Working, fixing LCD) ==

''('''News:''' The New DC233, with the V3 MMU, is now working. Work is in progress with the Linux 2.6.29-smp kernel to boot from this updated U-Boot.

'''Summary:'''

[http://www.denx.de/wiki/UBoot U-Boot] is a very popular boot loader; especially within the [http://elinux.org/Bootloader Embedded Linux community].
The U-Boot loader runs on the FPGA boards which are equipped with a dip switch, number 8, which can select where the memory location for the reset
vector (0XFE00,0000) comes from. With switch number 8 off the board will map the memory at the reset vector to a small block of SRAM located in the
I/O block with the UART and Ethernet buffer memory. When switch number 8 is on the Avnet boards map the beginning of the Flash Memory at 0XF800,000
to the reset vector at 0xFE00,000.

What we are going to do here is build a version of U-Boot for your Avnet board and Variant, install that ELF file into memory
with xt-gdb and run U-Boot. Then we are going to download a another copy of this identical program with '''tftp'''. The version we
are going to download is just the ELF file with the headers and debug information removed. It's just the actual bits that get
loaded into memory. For the new V3 MMU the default '''loadaddr''' is typically 0x20,0000 and for the older V2 MMU this is in the
Linux mapping equivalent, 0xD0200,0000. The default location can be change by setting the U-Boot 'loadaddr' environment variable
or by changing the variable '''CONFIG_SYS_LOAD_ADDR''' in the boards U-Boot config file.

Once the virgin copy of the U-Boot program has been loaded into memory, the Flash memory is un-protected and errasd, then the
memory with the U-Boot program in it is copied to the flash memory and protected. Next you will set dip switch 8 on, recycle
power on the board, and U-Boot will be accessible via the serial UART at 38400 baud. U-Boot works without any MMU mapping,
and should be fine on configurations without an MMU. Only an ethernet and serial interface are required.

'''Proceedure:'''

A local port to the Xtensa architecture is now available at linux-xtensa.org. See [http://git.linux-xtensa.org/cgi-bin/git.cgi?p=u-boot/u-boot-xtensa.git;a=summary U-Boot Sources (GIT Summary)]. Or, to access this tree using <tt>git</tt> directly, use something like:

$ '''git clone git://git.linux-xtensa.org/git/u-boot/u-boot-xtensa.git u-boot'''
$ '''cd u-boot'''

''('''Note:''' This path is subject to change.)''

The U-Boot git repository has a branch with a HiFi 2 snapshot made for
the LX200 [[SMP HiFi 2 Development Board]]. With this branch you can simply check
out the snapshot_2+SMP branch which includes the binaries which are discussed below:

$ '''git clone git://git.linux-xtensa.org/git/u-boot/u-boot-xtensa.git u-boot'''
$ '''cd u-boot'''
$ '''git branch --track snapshot_2+SMP origin/snapshot_2+SMP'''
$ '''git checkout snapshot_2+SMP'''

$ '''ls -l u-boot u-boot.bin tools/mkimage'''
-rwxr-xr-x 1 piet tensilica 45016 2009-12-07 19:40 tools/mkimage [This is a small program you need to put in your search path to build kernel U-Boot images]
-rwxr-xr-x 1 piet tensilica 635339 2009-12-07 19:40 u-boot [Started with xt-gdb to bring up the 1st instance of a HiFi 2 U-Boot]
-rwxr-xr-x 1 piet tensilica 144944 2009-12-07 19:40 u-boot.bin [Loaded by the 1st instance of U-Boot, it's a HiFi2 version of u-boot that will be put in flash]
$

Unless you are using a U-Boot snapshot you need to build U-Boot for which you must have built the Buildroot toolchain for XTensa core.
Set your PATH to point to the toolchain built using buildroot. For example:

$ '''export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"'''

where '''<cname>''' is the name of the Xtensa core variant you wish to build for (e.g., <tt>dc232b</tt> <tt>dc233c</tt>).

To build U-Boot, use the cloned git tree pulled above, you should be at the top level of the tree in the '''u-boot''' directory , then configure it for your board and Xtensa core variant as follows:

make distclean
make <cname>'''_<board>_'''config
'dc232b'dc
This should only take a few seconds. For example, to build U-boot for the 'xtav60' board and the older 'dc232b' core with the V2 MMU type:

$ '''cd u-boot'''
$ '''make dc232b_xtav60_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

or for the new 'dc233c' core with the new V3 MMU type:

$ '''make dc233c_xtav60_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

or for a 'xtav200' board type with the new 'dc233c' core type:

$ '''make dc233c_xtav200_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

or for the snapshot_2+SMP branch you can also build U-Boot for the HiFi 2 core:

$ '''make test_mmuhifi_c3_xtav200_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

Only boards and core variants currently supported in the tree can be built out of the box. Headers for supported cores can be found in the tree under <tt>include/asm-xtensa/variant-<cname></tt>. The core specific headers are described in the <tt>doc/README.xtensa</tt> file. To support a new core, these headers must be copied from the overlay in the same way as for the linux kernel.

After the configuration step, to actually build U-Boot, simply:

$ '''make all''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

This will take a quite a few minutes.

Next, start xt-gdb and load u-boot from the top of the git repository:

$ '''xt-gdb -n''' [NOTE: Even with the HiFi 2 snapshot_2+SMP branch you still may have to put U-Boot on the board]
(xt-gdb) '''file u-boot'''
(xt-gdb) '''target remote localhost:20000 0'''
(xt-gdb) '''reset'''
(xt-gdb) '''load'''
(xt-gdb) '''break panic'''
(xt-gdb) '''continue'''

Hopefully U-Boot will start, and display on the LCD in the case of a LX60.

U-Boot 50.00 Mhz

Often you will be starting with the boards flash in an unknown state and it's best to unprotect and erase the entire flash. Just type '''protect off all''' followed by '''erase all''':

U-Boot> '''protect off all'''
Un-Protect Flash Bank # 1
................................................................................................................................... done
U-Boot> '''erase all'''
Erase Flash Bank # 1
..........................................................................................................
Flash erase timeout at address f8d40000 da0
Flash erase error at address f8d40000
........................ done
U-Boot>

The timeout and error messages are likley just warning messages and you board has been errased. You can see that with the flash info command '''flinfo'''. Below is an example with a LX200 board, which has a much larger flash than the smaller LX60:

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
F8000000 E F8020000 E F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E F8FE0000 E F8FE8000 E F8FF0000 E
F8FF8000 E
U-Boot>

The new LX110 looks very similar to the LX200, also with with 16Mb of Flash:

U-Boot> flinfo

Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 32 bytes

Sector Start Addresses:
F8000000 E F8020000 E F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E F8FE0000 E

Now set your preliminary U-Boot environment variables to point to your TFTP server so we can download yet another copy of U-Boot. At Tensilica we use a machine in the RTOS group called rtos-lab2. Folks using the [[SMP HiFi 2 Development Board]] likely have set up their workstation with a TFTP server.

U-Boot> '''setenv serverip 192.168.11.78''' rtos-lab2
or
U-Boot> '''setenv serverip 192.168.11.55''' pdelaney_fc9

U-Boot> '''setenv ipaddr 192.168.11.95''' I/P address of RTOS5, Piet's LX60; MAC: 00:05:C2:13:6f:0a

U-Boot> '''setenv bootfile u-boot.bin'''
U-Boot> '''saveenv'''
Saving Environment to Flash...
.... done
Un-Protected 4 sectors
Erasing Flash...
.... done
Erased 4 sectors
Writing to Flash... done
.... done
Protected 4 sectors
U-Boot>

Next, download '''u-boot.bin''' from the tftp server using the info we just entered into U-Boot's enviroment variables.
Here for example is the case for a LX60 running the HiFi-2 Bitstream with the older V2 MMU. Note that it starts up
in the D-gazillion (0XD0000000) region:

U-Boot> '''tftpboot'''
TFTP from server 192.168.11.78; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0xd2000000
Loading: T ########
done
Bytes transferred = 107592 (1a448 hex)

For the V3 MMU U-Boot is loaded from host pdelaney_fc9 into memory with virtual == physical. Here is a DC233L, with V3 MMU, example:

U-Boot> '''tftpboot'''
Using open_ethernet device
TFTP from server 192.168.11.55; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: T ########
done
Bytes transferred = 109964 (1ad8c hex)
U-Boot>

Now things get a bit tricky here for the LX60. The FLASH has '''Two sizes of Flash Sectors'''.
The first 8 sectors are small 0x2000 (8KB) and apparently intended for parameters. The rest
of the 4MB flash is composed of larger 0x10000 (64KB) sectors. Our code doesn't differentiate
between the sectors and the LX60 hardware is going to map 0XF800,0000 to 0XFE00,0000 so this
makes us use of all 8 of the 8KB sectors and the 1st 64KB sector at F8010000. So we are going
to flash up to F801FFFF below.

On a LX200 we have much more space and can easily fit a version of U-boot that has been compiled without optimization, make debugging much easier.
So in this case the image is a bit larger, but relatively similar to the LX60 (2 sectors):

U-Boot> '''tftpboot'''
Using open_ethernet device
TFTP from server 192.168.11.78; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0xd2000000
Loading: ###############
done
Bytes transferred = 205852 (3241c hex)
U-Boot>

On a LX110 we have less memory than an LX60, but FLASH sectors like the LX200. It turns out that the u-boot image
compiled with optimization is just a bit larger than 1 sector, so like the LX200 we will need to write u-boot
into two sectors. Here's and example tftpboot of U-Bot for the LX110:

U-Boot> tftpboot
Using open_ethernet device
TFTP from server 192.168.11.55; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: ##########
done
Bytes transferred = 144956 (2363c hex)
U-Boot>

Note that for both the LX200 and the LX60 that the image size, '''(3241c hex)''' in this case, is a bit less than 0x40000 or 10 sectors,
so turn off protection on the 1st 11 sectors and
erase the current contents.

For the '''LX60''' you do this:

U-Boot> '''protect off F8000000 F801FFFF'''
... done
Un-Protected 2 sectors
U-Boot> '''erase F8000000 F801FFFF'''
erase F8000000 F801FFFF
... done

For the '''LX200''' and the '''LX110''' the starting address '''(F8000000)''' is the same as with the LX60 but the last address '''(F803FFFF)''' is 'twice' as high:

U-Boot> '''protect off F8000000 F803FFFF'''
... done
Un-Protected 2 sectors
U-Boot> '''erase F8000000 F803FFFF'''
Erased 2 sectors
U-Boot>

Now copy the the image of u-boot.bin in memory to the flash. For the XL60 with the '''OLD''' V2 MMU you copy 0x20000
bytes from 0xd2000000 to 0XF8000000:

U-Boot> '''cp.b d2000000 F8000000 20000'''
Copy to Flash... done

For the LX60 with the '''NEW''' V3 MMU you copy 0x24000 bytes from 0x2000000 to F8000000:

U-Boot> '''cp.b 2000000 F8000000 20000'''
Copy to Flash... done

For the LX200 you copy 0x40000 bytes from 0xd2000000 to 0XF8000000...0XF803FFFF:

U-Boot> '''cp.b d2000000 F8000000 40000'''
Copy to Flash... done

For the LX110 with a V3-MMU you copy 0x40000 bytes from 0x2000000 to F8000000:
U-Boot> cp.b 2000000 F8000000 40000
Copy to Flash... done

Finally we protect these sectors so that U-Boot isn't easily erased by accident.
Below is what it looks like on a LX60 with the New V3 MMU with a subsequent display of the flash info:

U-Boot> '''cp.b 2000000 F8000000 2000'''
Copy to Flash... done
U-Boot> flinfo

Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x2257
Erase timeout: 8192 ms, write timeout: 1 ms

Sector Start Addresses:
'''F8000000 F8002000 F8004000 F8006000 F8008000'''
'''F800A000 F800C000 F800E000 F8010000 '''F8020000 E
F8030000 E F8040000 E F8050000 E F8060000 E F8070000 E
F8080000 E F8090000 E F80A0000 E F80B0000 E F80C0000 E
F80D0000 E F80E0000 E F80F0000 E F8100000 E F8110000 E
F8120000 E F8130000 E F8140000 E F8150000 E F8160000 E
F8170000 E F8180000 E F8190000 E F81A0000 E F81B0000 E
F81C0000 E F81D0000 E F81E0000 E F81F0000 E F8200000 E
F8210000 E F8220000 E F8230000 E F8240000 E F8250000 E
F8260000 E F8270000 E F8280000 E F8290000 E F82A0000 E
F82B0000 E F82C0000 E F82D0000 E F82E0000 E F82F0000 E
F8300000 E F8310000 E F8320000 E F8330000 E F8340000 E
F8350000 E F8360000 E F8370000 E F8380000 E F8390000 E
F83A0000 E F83B0000 E F83C0000 E F83D0000 E F83E0000
'''F83F0000 RO'''
U-Boot> '''protect on F8000000 F802FFFF'''
.......... done
Protected 10 sectors
U-Boot>

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x2257
Erase timeout: 8192 ms, write timeout: 1 ms

Sector Start Addresses:
'''F8000000 RO F8002000 RO F8004000 RO F8006000 RO F8008000 RO
F800A000 RO F800C000 RO F800E000 RO F8010000 RO''' F8020000 E
F8030000 E F8040000 E F8050000 E F8060000 E F8070000 E
F8080000 E F8090000 E F80A0000 E F80B0000 E F80C0000 E
F80D0000 E F80E0000 E F80F0000 E F8100000 E F8110000 E
F8120000 E F8130000 E F8140000 E F8150000 E F8160000 E
F8170000 E F8180000 E F8190000 E F81A0000 E F81B0000 E
F81C0000 E F81D0000 E F81E0000 E F81F0000 E F8200000 E
F8210000 E F8220000 E F8230000 E F8240000 E F8250000 E
F8260000 E F8270000 E F8280000 E F8290000 E F82A0000 E
F82B0000 E F82C0000 E F82D0000 E F82E0000 E F82F0000 E
F8300000 E F8310000 E F8320000 E F8330000 E F8340000 E
F8350000 E F8360000 E F8370000 E F8380000 E F8390000 E
F83A0000 E F83B0000 E F83C0000 E F83D0000 E F83E0000
'''F83F0000 RO'''
U-Boot>

For the '''LX110''' with the '''V3-MMU''' here's what the flash info looks like after we
protect the first two sectors with U-Boot copied to it:

U-Boot> '''protect on F8000000 F803FFFF'''
Protected 2 sectors
U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 32 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E '''F8FE0000 RO'''
U-Boot> help

Below is what it looks like on a LX200 with the V2 MMU with a subsequent display of the flash info.
Notice that the Flash Sectors are 10X as large on the LX200:

U-Boot> '''protect on F8000000 F802FFFF'''
.. done
Protected 2 sectors
U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E '''F8FE0000 RO F8FE8000 RO F8FF0000 RO'''
'''F8FF8000 RO'''
U-Boot>

Note that the U-Boot '''saveenv''' command Erased and protected the last four sectors
of this LX200.

On both the LX60 and the LX200 now move DIP switch 8 to the ON position, on the LX110 move DIP switch 4 to the ON position.
Next, power cycle the board. On the LX60 you should see U-boot in the LCD display.

The '''LX60''' with the new V3 MMU the serial console should print something like the following:

U-Boot 2009.08-dirty (Sep 10 2010 - 18:23:26)

CPU: Xtensa dc233c at 50.00 MHz
Board: XT-AV60: Avnet board + Xilinx LX60 FPGA + Tensilica bitstream
SysRAM: 64 MB
Flash: 4 MB
In: serial
Out: serial
Err: serial
MAC: 00:50:C2:13:6f:0a
IP: 192.168.11.95
open_ethernet
U-Boot>

On the '''LX110 with the new V3 MMU the serial console should print something like the following:

U-Boot 2009.08-dirty (Nov 15 2010 - 23:04:45)

CPU: Xtensa dc233c at 50.00 MHz
Board: XT-AV110: Avnet board + Xilinx LX110 FPGA + Tensilica bitstream
SysRAM: 48 MB
Flash: 16 MB
In: serial
Out: serial
Err: serial
MAC: 00:50:C2:13:6f:00
IP: 192.168.11.95
open_ethernet
U-Boot>

On the '''LX200''', shown below with the old V2 MMU, you should see something like the following. In this case we also show the flash info command, '''flinfo''', being invoked just after booting U-Boot:

U-Boot 2009.08-dirty (Nov 15 2010 - 23:04:45)

CPU: Xtensa test_mmuhifi_c3 at 41.6777 MHz
Board: XT-AV200: Avnet board + Xilinx LX200 FPGA + Tensilica bitstream
SysRAM: 96 MB
Flash: 16 MB
In: serial
Out: serial
Err: serial
MAC:
IP: 192.168.11.95
U-Boot>

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E RO F8060000 E RO F8080000 E RO
F80A0000 E RO F80C0000 E RO F80E0000 E RO F8100000 E RO F8120000 E RO
F8140000 E RO F8160000 E RO F8180000 E RO F81A0000 E RO F81C0000 E RO
F81E0000 E RO F8200000 E RO F8220000 E RO F8240000 E RO F8260000 E RO
F8280000 E RO F82A0000 E RO F82C0000 E RO F82E0000 E RO F8300000 E RO
F8320000 E RO F8340000 E RO F8360000 E RO F8380000 E RO F83A0000 E RO
F83C0000 E RO F83E0000 E RO F8400000 E RO F8420000 E RO F8440000 E RO
F8460000 E RO F8480000 E RO F84A0000 E RO F84C0000 E RO F84E0000 E RO
F8500000 E RO F8520000 E RO F8540000 E RO F8560000 E RO F8580000 E RO
F85A0000 E RO F85C0000 E RO F85E0000 E RO F8600000 E RO F8620000 E RO
F8640000 E RO F8660000 E RO F8680000 E RO F86A0000 E RO F86C0000 E RO
F86E0000 E RO F8700000 E RO F8720000 E RO F8740000 E RO F8760000 E RO
F8780000 E RO F87A0000 E RO F87C0000 E RO F87E0000 E RO F8800000 E RO
F8820000 E RO F8840000 E RO F8860000 E RO F8880000 E RO F88A0000 E RO
F88C0000 E RO F88E0000 E RO F8900000 E RO F8920000 E RO F8940000 E RO
F8960000 E RO F8980000 E RO F89A0000 E RO F89C0000 E RO F89E0000 E RO
F8A00000 E RO F8A20000 E RO F8A40000 E RO F8A60000 E RO F8A80000 E RO
F8AA0000 E RO F8AC0000 E RO F8AE0000 E RO F8B00000 E RO F8B20000 E RO
F8B40000 E RO F8B60000 E RO F8B80000 E RO F8BA0000 E RO F8BC0000 E RO
F8BE0000 E RO F8C00000 E RO F8C20000 E RO F8C40000 E RO F8C60000 E RO
F8C80000 E RO F8CA0000 E RO F8CC0000 E RO F8CE0000 E RO F8D00000 E RO
F8D20000 E RO F8D40000 E RO F8D60000 E RO F8D80000 E RO F8DA0000 E RO
F8DC0000 E RO F8DE0000 E RO F8E00000 E RO F8E20000 E RO F8E40000 E RO
F8E60000 E RO F8E80000 E RO F8EA0000 E RO F8EC0000 E RO F8EE0000 E RO
F8F00000 E RO F8F20000 E RO F8F40000 E RO F8F60000 E RO F8F80000 E RO
F8FA0000 E RO F8FC0000 E RO '''F8FE0000 RO F8FE8000 RO F8FF0000 RO'''
'''F8FF8000 RO'''
U-Boot>

Note that the 1st two sectors with U-Boot saved in them came up as not being erased ('''E''') but that all sectors came up Read Only ('''RO''').
Same with the last four sectors that the U-Boot '''saveenv''' command Erased. This is likely a '''bug''' on the LX200 boards with some preliminary investigation.
We will be discussing this with the U-Boot developers sometime in the future prior to pushing our U-boot changes upstream.

If U-Boot fails to boot ya might try making sure your U-Boot '''serverip''' environment variable matches the address of the tftp server where
you have copied your '''u-boot.bin''' file to and comparing the bits in the flash that got mapped to 0xfe00,0000 to what in the file:

u-boot]$ '''od -t x4 u-boot.bin | more'''
.0000000 00000206 fe000040 ffffffff a0fffe21
.0000020 00000002 fe01ad14 fe01ad8c 03f95030
.0000040 03f9aa78 04000000 00040003 03f8147c
.0000060 03f81418 00000000 00000000 00000000
.0000100 5300000c 13a00013 4800130c 13493013
.0000120 0c130200 13e62032 22002010 a03200a0
.0000140 1d837680 82037282 72822372 63728243
.0000160 72007272 72720872 18727210 2201d222
.0000200 020c80c2 3d80a032 1d8376f0 d20372d2
.0000220 72d22372 6372d243 f20072f2 72f20872
.0000240 1872f210 2201d222 200080c2 ffd92100
.0000260 37ffda31 02481d12 22681258 145722cb
.0000300 ee1467f1 664b0678 444b0479 06f43457
.0000320 0000fff8 31ffd221 4320ffd2 40443bc0
.0000340 84764142 4b020903 32020c22 837680a0
.0000360 04728211 82247282 72824472 01d22264
.0000400 1180c222 c821ffc8 13e620ff 41002010
.0000420 04d0ffc7 ffc64100 fffffd86 1049c500
.0000440 e52049d5 49f53049 00003400 00000000
.0000460 00000000 00000000 00000000 00000000
.
.(gdb) '''x/100x 0xfe000000'''
.0xfe000000 <_ResetVector>: 0x00000206 0xfe000040 0xffffffff 0xa0fffe21
.0xfe000010 <_ResetVector+16>: 0x00000002 0xfe01ad14 0xfe01ad8c 0x03f95030
.0xfe000020 <_ResetVector+32>: 0x03f9aa78 0x04000000 0x00040003 0x03f8147c
.0xfe000030 <_ResetVector+48>: 0x03f81418 0x00000000 0x00000000 0x00000000
.0xfe000040 <_start>: 0x5300000c 0x13a00013 0x4800130c 0x13493013
.0xfe000050 <_start+16>: 0x0c130200 0x13e62032 0x22002010 0xa03200a0
.0xfe000060 <_start+32>: 0x1d837680 0x82037282 0x72822372 0x63728243
.0xfe000070 <_start+48>: 0x72007272 0x72720872 0x18727210 0x2201d222
.0xfe000080 <_start+64>: 0x020c80c2 0x3d80a032 0x1d8376f0 0xd20372d2
.0xfe000090 <_start+80>: 0x72d22372 0x6372d243 0xf20072f2 0x72f20872
.0xfe0000a0 <_start+96>: 0x1872f210 0x2201d222 0x200080c2 0xffd92100
.0xfe0000b0 <_start+112>: 0x37ffda31 0x02481d12 0x22681258 0x145722cb
.0xfe0000c0 <_start+128>: 0xee1467f1 0x664b0678 0x444b0479 0x06f43457
.0xfe0000d0 <_start+144>: 0x0000fff8 0x31ffd221 0x4320ffd2 0x40443bc0
.0xfe0000e0 <_start+160>: 0x84764142 0x4b020903 0x32020c22 0x837680a0
.0xfe0000f0 <_start+176>: 0x04728211 0x82247282 0x72824472 0x01d22264
.0xfe000100 <_start+192>: 0x1180c222 0xc821ffc8 0x13e620ff 0x41002010
.0xfe000110 <_reset+1>: 0x04d0ffc7 0xffc64100 0x00fffd86 0x1049c500
.0xfe000120: 0xe52049d5 0x49f53049 0x00003400 0x00000000
.0xfe000130: 0x00000000 0x00000000 0x00000000 0x00000000
.(gdb)

Further details on U-Boot in general are in the generic <tt>README</tt> at the top of the U-Boot tree. Details specific to the Xtensa architecture are in <tt>doc/README.xtensa</tt>. Details specific to a board are in <tt>board[/<family>]/<board>/README</tt> (for example <tt>board/avnet/xtav60/README</tt>).

Setting up U-Boot

2010-11-16T09:26:28Z

Piet: /* LX60 and LX200 U-Boot Installation (LX110 in Progress) */

== LX60 and LX200 U-Boot Installation (LX110 in Progress, UART and FLASH Working, fixing LCD) ==

''('''News:''' The New DC233, with the V3 MMU, is now working. Work is in progress with the Linux 2.6.29-smp kernel to boot from this updated U-Boot.

'''Summary:'''

[http://www.denx.de/wiki/UBoot U-Boot] is a very popular boot loader; especially within the [http://elinux.org/Bootloader Embedded Linux community].
The U-Boot loader runs on the FPGA boards which are equipped with a dip switch, number 8, which can select where the memory location for the reset
vector (0XFE00,0000) comes from. With switch number 8 off the board will map the memory at the reset vector to a small block of SRAM located in the
I/O block with the UART and Ethernet buffer memory. When switch number 8 is on the Avnet boards map the beginning of the Flash Memory at 0XF800,000
to the reset vector at 0xFE00,000.

What we are going to do here is build a version of U-Boot for your Avnet board and Variant, install that ELF file into memory
with xt-gdb and run U-Boot. Then we are going to download a another copy of this identical program with '''tftp'''. The version we
are going to download is just the ELF file with the headers and debug information removed. It's just the actual bits that get
loaded into memory. For the new V3 MMU the default '''loadaddr''' is typically 0x20,0000 and for the older V2 MMU this is in the
Linux mapping equivalent, 0xD0200,0000. The default location can be change by setting the U-Boot 'loadaddr' environment variable
or by changing the variable '''CONFIG_SYS_LOAD_ADDR''' in the boards U-Boot config file.

Once the virgin copy of the U-Boot program has been loaded into memory, the Flash memory is un-protected and errasd, then the
memory with the U-Boot program in it is copied to the flash memory and protected. Next you will set dip switch 8 on, recycle
power on the board, and U-Boot will be accessible via the serial UART at 38400 baud. U-Boot works without any MMU mapping,
and should be fine on configurations without an MMU. Only an ethernet and serial interface are required.

'''Proceedure:'''

A local port to the Xtensa architecture is now available at linux-xtensa.org. See [http://git.linux-xtensa.org/cgi-bin/git.cgi?p=u-boot/u-boot-xtensa.git;a=summary U-Boot Sources (GIT Summary)]. Or, to access this tree using <tt>git</tt> directly, use something like:

$ '''git clone git://git.linux-xtensa.org/git/u-boot/u-boot-xtensa.git u-boot'''
$ '''cd u-boot'''

''('''Note:''' This path is subject to change.)''

The U-Boot git repository has a branch with a HiFi 2 snapshot made for
the LX200 [[SMP HiFi 2 Development Board]]. With this branch you can simply check
out the snapshot_2+SMP branch which includes the binaries which are discussed below:

$ '''git clone git://git.linux-xtensa.org/git/u-boot/u-boot-xtensa.git u-boot'''
$ '''cd u-boot'''
$ '''git branch --track snapshot_2+SMP origin/snapshot_2+SMP'''
$ '''git checkout snapshot_2+SMP'''

$ '''ls -l u-boot u-boot.bin tools/mkimage'''
-rwxr-xr-x 1 piet tensilica 45016 2009-12-07 19:40 tools/mkimage [This is a small program you need to put in your search path to build kernel U-Boot images]
-rwxr-xr-x 1 piet tensilica 635339 2009-12-07 19:40 u-boot [Started with xt-gdb to bring up the 1st instance of a HiFi 2 U-Boot]
-rwxr-xr-x 1 piet tensilica 144944 2009-12-07 19:40 u-boot.bin [Loaded by the 1st instance of U-Boot, it's a HiFi2 version of u-boot that will be put in flash]
$

Unless you are using a U-Boot snapshot you need to build U-Boot for which you must have built the Buildroot toolchain for XTensa core.
Set your PATH to point to the toolchain built using buildroot. For example:

$ '''export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"'''

where '''<cname>''' is the name of the Xtensa core variant you wish to build for (e.g., <tt>dc232b</tt> <tt>dc233c</tt>).

To build U-Boot, use the cloned git tree pulled above, you should be at the top level of the tree in the '''u-boot''' directory , then configure it for your board and Xtensa core variant as follows:

make distclean
make <cname>'''_<board>_'''config
'dc232b'dc
This should only take a few seconds. For example, to build U-boot for the 'xtav60' board and the older 'dc232b' core with the V2 MMU type:

$ '''cd u-boot'''
$ '''make dc232b_xtav60_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

or for the new 'dc233c' core with the new V3 MMU type:

$ '''make dc233c_xtav60_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

or for a 'xtav200' board type with the new 'dc233c' core type:

$ '''make dc233c_xtav200_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

or for the snapshot_2+SMP branch you can also build U-Boot for the HiFi 2 core:

$ '''make test_mmuhifi_c3_xtav200_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

Only boards and core variants currently supported in the tree can be built out of the box. Headers for supported cores can be found in the tree under <tt>include/asm-xtensa/variant-<cname></tt>. The core specific headers are described in the <tt>doc/README.xtensa</tt> file. To support a new core, these headers must be copied from the overlay in the same way as for the linux kernel.

After the configuration step, to actually build U-Boot, simply:

$ '''make all''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

This will take a quite a few minutes.

Next, start xt-gdb and load u-boot from the top of the git repository:

$ '''xt-gdb -n''' [NOTE: Even with the HiFi 2 snapshot_2+SMP branch you still may have to put U-Boot on the board]
(xt-gdb) '''file u-boot'''
(xt-gdb) '''target remote localhost:20000 0'''
(xt-gdb) '''reset'''
(xt-gdb) '''load'''
(xt-gdb) '''break panic'''
(xt-gdb) '''continue'''

Hopefully U-Boot will start, and display on the LCD in the case of a LX60.

U-Boot 50.00 Mhz

Often you will be starting with the boards flash in an unknown state and it's best to unprotect and erase the entire flash. Just type '''protect off all''' followed by '''erase all''':

U-Boot> '''protect off all'''
Un-Protect Flash Bank # 1
................................................................................................................................... done
U-Boot> '''erase all'''
Erase Flash Bank # 1
..........................................................................................................
Flash erase timeout at address f8d40000 da0
Flash erase error at address f8d40000
........................ done
U-Boot>

The timeout and error messages are likley just warning messages and you board has been errased. You can see that with the flash info command '''flinfo'''. Below is an example with a LX200 board, which has a much larger flash than the smaller LX60:

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
F8000000 E F8020000 E F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E F8FE0000 E F8FE8000 E F8FF0000 E
F8FF8000 E
U-Boot>

The new LX110 looks very similar to the LX200, also with with 16Mb of Flash:

U-Boot> flinfo

Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 32 bytes

Sector Start Addresses:
F8000000 E F8020000 E F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E F8FE0000 E

Now set your preliminary U-Boot environment variables to point to your TFTP server so we can download yet another copy of U-Boot. At Tensilica we use a machine in the RTOS group called rtos-lab2. Folks using the [[SMP HiFi 2 Development Board]] likely have set up their workstation with a TFTP server.

U-Boot> '''setenv serverip 192.168.11.78''' rtos-lab2
or
U-Boot> '''setenv serverip 192.168.11.55''' pdelaney_fc9

U-Boot> '''setenv ipaddr 192.168.11.95''' I/P address of RTOS5, Piet's LX60; MAC: 00:05:C2:13:6f:0a

U-Boot> '''setenv bootfile u-boot.bin'''
U-Boot> '''saveenv'''
Saving Environment to Flash...
.... done
Un-Protected 4 sectors
Erasing Flash...
.... done
Erased 4 sectors
Writing to Flash... done
.... done
Protected 4 sectors
U-Boot>

Next, download '''u-boot.bin''' from the tftp server using the info we just entered into U-Boot's enviroment variables.
Here for example is the case for a LX60 running the HiFi-2 Bitstream with the older V2 MMU. Note that it starts up
in the D-gazillion (0XD0000000) region:

U-Boot> '''tftpboot'''
TFTP from server 192.168.11.78; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0xd2000000
Loading: T ########
done
Bytes transferred = 107592 (1a448 hex)

For the V3 MMU U-Boot is loaded from host pdelaney_fc9 into memory with virtual == physical. Here is a DC233L, with V3 MMU, example:

U-Boot> '''tftpboot'''
Using open_ethernet device
TFTP from server 192.168.11.55; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: T ########
done
Bytes transferred = 109964 (1ad8c hex)
U-Boot>

Now things get a bit tricky here for the LX60. The FLASH has '''Two sizes of Flash Sectors'''.
The first 8 sectors are small 0x2000 (8KB) and apparently intended for parameters. The rest
of the 4MB flash is composed of larger 0x10000 (64KB) sectors. Our code doesn't differentiate
between the sectors and the LX60 hardware is going to map 0XF800,0000 to 0XFE00,0000 so this
makes us use of all 8 of the 8KB sectors and the 1st 64KB sector at F8010000. So we are going
to flash up to F801FFFF below.

On a LX200 we have much more space and can easily fit a version of U-boot that has been compiled without optimization, make debugging much easier.
So in this case the image is a bit larger, but relatively similar to the LX60 (2 sectors):

U-Boot> '''tftpboot'''
Using open_ethernet device
TFTP from server 192.168.11.78; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0xd2000000
Loading: ###############
done
Bytes transferred = 205852 (3241c hex)
U-Boot>

On a LX110 we have less memory than an LX60, but FLASH sectors like the LX200. It turns out that the u-boot image
compiled with optimization is just a bit larger than 1 sector, so like the LX200 we will need to write u-boot
into two sectors. Here's and example tftpboot of U-Bot for the LX110:

U-Boot> tftpboot
Using open_ethernet device
TFTP from server 192.168.11.55; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: ##########
done
Bytes transferred = 144956 (2363c hex)
U-Boot>

Note that for both the LX200 and the LX60 that the image size, '''(3241c hex)''' in this case, is a bit less than 0x40000 or 10 sectors,
so turn off protection on the 1st 11 sectors and
erase the current contents.

For the '''LX60''' you do this:

U-Boot> '''protect off F8000000 F801FFFF'''
... done
Un-Protected 2 sectors
U-Boot> '''erase F8000000 F801FFFF'''
erase F8000000 F801FFFF
... done

For the '''LX200''' and the '''LX110''' the starting address '''(F8000000)''' is the same as with the LX60 but the last address '''(F803FFFF)''' is 'twice' as high:

U-Boot> '''protect off F8000000 F803FFFF'''
... done
Un-Protected 2 sectors
U-Boot> '''erase F8000000 F803FFFF'''
Erased 2 sectors
U-Boot>

Now copy the the image of u-boot.bin in memory to the flash. For the XL60 with the '''OLD''' V2 MMU you copy 0x20000
bytes from 0xd2000000 to 0XF8000000:

U-Boot> '''cp.b d2000000 F8000000 20000'''
Copy to Flash... done

For the LX60 with the '''NEW''' V3 MMU you copy 0x24000 bytes from 0x2000000 to F8000000:

U-Boot> '''cp.b 2000000 F8000000 20000'''
Copy to Flash... done

For the LX200 you copy 0x40000 bytes from 0xd2000000 to 0XF8000000...0XF803FFFF:

U-Boot> '''cp.b d2000000 F8000000 40000'''
Copy to Flash... done

For the LX110 with a V3-MMU you copy 0x40000 bytes from 0x2000000 to F8000000:
U-Boot> cp.b 2000000 F8000000 40000
Copy to Flash... done

Finally we protect these sectors so that U-Boot isn't easily erased by accident.
Below is what it looks like on a LX60 with the New V3 MMU with a subsequent display of the flash info:

U-Boot> '''cp.b 2000000 F8000000 2000'''
Copy to Flash... done
U-Boot> flinfo

Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x2257
Erase timeout: 8192 ms, write timeout: 1 ms

Sector Start Addresses:
'''F8000000 F8002000 F8004000 F8006000 F8008000'''
'''F800A000 F800C000 F800E000 F8010000 '''F8020000 E
F8030000 E F8040000 E F8050000 E F8060000 E F8070000 E
F8080000 E F8090000 E F80A0000 E F80B0000 E F80C0000 E
F80D0000 E F80E0000 E F80F0000 E F8100000 E F8110000 E
F8120000 E F8130000 E F8140000 E F8150000 E F8160000 E
F8170000 E F8180000 E F8190000 E F81A0000 E F81B0000 E
F81C0000 E F81D0000 E F81E0000 E F81F0000 E F8200000 E
F8210000 E F8220000 E F8230000 E F8240000 E F8250000 E
F8260000 E F8270000 E F8280000 E F8290000 E F82A0000 E
F82B0000 E F82C0000 E F82D0000 E F82E0000 E F82F0000 E
F8300000 E F8310000 E F8320000 E F8330000 E F8340000 E
F8350000 E F8360000 E F8370000 E F8380000 E F8390000 E
F83A0000 E F83B0000 E F83C0000 E F83D0000 E F83E0000
'''F83F0000 RO'''
U-Boot> '''protect on F8000000 F802FFFF'''
.......... done
Protected 10 sectors
U-Boot>

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x2257
Erase timeout: 8192 ms, write timeout: 1 ms

Sector Start Addresses:
'''F8000000 RO F8002000 RO F8004000 RO F8006000 RO F8008000 RO
F800A000 RO F800C000 RO F800E000 RO F8010000 RO''' F8020000 E
F8030000 E F8040000 E F8050000 E F8060000 E F8070000 E
F8080000 E F8090000 E F80A0000 E F80B0000 E F80C0000 E
F80D0000 E F80E0000 E F80F0000 E F8100000 E F8110000 E
F8120000 E F8130000 E F8140000 E F8150000 E F8160000 E
F8170000 E F8180000 E F8190000 E F81A0000 E F81B0000 E
F81C0000 E F81D0000 E F81E0000 E F81F0000 E F8200000 E
F8210000 E F8220000 E F8230000 E F8240000 E F8250000 E
F8260000 E F8270000 E F8280000 E F8290000 E F82A0000 E
F82B0000 E F82C0000 E F82D0000 E F82E0000 E F82F0000 E
F8300000 E F8310000 E F8320000 E F8330000 E F8340000 E
F8350000 E F8360000 E F8370000 E F8380000 E F8390000 E
F83A0000 E F83B0000 E F83C0000 E F83D0000 E F83E0000
'''F83F0000 RO'''
U-Boot>

For the '''LX110''' with the '''V3-MMU''' here's what the flash info looks like after we
protect the first two sectors with U-Boot copied to it:

U-Boot> '''protect on F8000000 F803FFFF'''
Protected 2 sectors
U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 32 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E '''F8FE0000 RO'''
U-Boot> help

Below is what it looks like on a LX200 with the V2 MMU with a subsequent display of the flash info.
Notice that the Flash Sectors are 10X as large on the LX200:

U-Boot> '''protect on F8000000 F802FFFF'''
.. done
Protected 2 sectors
U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E '''F8FE0000 RO F8FE8000 RO F8FF0000 RO'''
'''F8FF8000 RO'''
U-Boot>

Note that the U-Boot '''saveenv''' command Erased and protected the last four sectors
of this LX200.

On both the LX60 and the LX200 now move DIP switch 8 to the ON position, power cycle the board. On the LX60 you should see U-boot in the LCD display.

The '''LX60''' with the new V3 MMU the serial console should print something like the following:

U-Boot 2009.08-dirty (Sep 10 2010 - 18:23:26)

CPU: Xtensa dc233c at 50.00 MHz
Board: XT-AV60: Avnet board + Xilinx LX60 FPGA + Tensilica bitstream
SysRAM: 64 MB
Flash: 4 MB
In: serial
Out: serial
Err: serial
MAC: 00:50:C2:13:6f:0a
IP: 192.168.11.95
open_ethernet
U-Boot>

On the '''LX200''', shown below with the old V2 MMU, you should see something like the following. In this case we also show the flash info command, '''flinfo''', being invoked just after booting U-Boot:

CPU: Xtensa test_mmuhifi_c3 at 41.6777 MHz
Board: XT-AV200: Avnet board + Xilinx LX200 FPGA + Tensilica bitstream
SysRAM: 96 MB
Flash: 16 MB
In: serial
Out: serial
Err: serial
MAC:
IP: 192.168.11.95
U-Boot>

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E RO F8060000 E RO F8080000 E RO
F80A0000 E RO F80C0000 E RO F80E0000 E RO F8100000 E RO F8120000 E RO
F8140000 E RO F8160000 E RO F8180000 E RO F81A0000 E RO F81C0000 E RO
F81E0000 E RO F8200000 E RO F8220000 E RO F8240000 E RO F8260000 E RO
F8280000 E RO F82A0000 E RO F82C0000 E RO F82E0000 E RO F8300000 E RO
F8320000 E RO F8340000 E RO F8360000 E RO F8380000 E RO F83A0000 E RO
F83C0000 E RO F83E0000 E RO F8400000 E RO F8420000 E RO F8440000 E RO
F8460000 E RO F8480000 E RO F84A0000 E RO F84C0000 E RO F84E0000 E RO
F8500000 E RO F8520000 E RO F8540000 E RO F8560000 E RO F8580000 E RO
F85A0000 E RO F85C0000 E RO F85E0000 E RO F8600000 E RO F8620000 E RO
F8640000 E RO F8660000 E RO F8680000 E RO F86A0000 E RO F86C0000 E RO
F86E0000 E RO F8700000 E RO F8720000 E RO F8740000 E RO F8760000 E RO
F8780000 E RO F87A0000 E RO F87C0000 E RO F87E0000 E RO F8800000 E RO
F8820000 E RO F8840000 E RO F8860000 E RO F8880000 E RO F88A0000 E RO
F88C0000 E RO F88E0000 E RO F8900000 E RO F8920000 E RO F8940000 E RO
F8960000 E RO F8980000 E RO F89A0000 E RO F89C0000 E RO F89E0000 E RO
F8A00000 E RO F8A20000 E RO F8A40000 E RO F8A60000 E RO F8A80000 E RO
F8AA0000 E RO F8AC0000 E RO F8AE0000 E RO F8B00000 E RO F8B20000 E RO
F8B40000 E RO F8B60000 E RO F8B80000 E RO F8BA0000 E RO F8BC0000 E RO
F8BE0000 E RO F8C00000 E RO F8C20000 E RO F8C40000 E RO F8C60000 E RO
F8C80000 E RO F8CA0000 E RO F8CC0000 E RO F8CE0000 E RO F8D00000 E RO
F8D20000 E RO F8D40000 E RO F8D60000 E RO F8D80000 E RO F8DA0000 E RO
F8DC0000 E RO F8DE0000 E RO F8E00000 E RO F8E20000 E RO F8E40000 E RO
F8E60000 E RO F8E80000 E RO F8EA0000 E RO F8EC0000 E RO F8EE0000 E RO
F8F00000 E RO F8F20000 E RO F8F40000 E RO F8F60000 E RO F8F80000 E RO
F8FA0000 E RO F8FC0000 E RO '''F8FE0000 RO F8FE8000 RO F8FF0000 RO'''
'''F8FF8000 RO'''
U-Boot>

Note that the 1st two sectors with U-Boot saved in them came up as not being erased ('''E''') but that all sectors came up Read Only ('''RO''').
Same with the last four sectors that the U-Boot '''saveenv''' command Erased. This is likely a '''bug''' on the LX200 boards with some preliminary investigation.
We will be discussing this with the U-Boot developers sometime in the future prior to pushing our U-boot changes upstream.

If U-Boot fails to boot ya might try making sure your U-Boot '''serverip''' environment variable matches the address of the tftp server where
you have copied your '''u-boot.bin''' file to and comparing the bits in the flash that got mapped to 0xfe00,0000 to what in the file:

u-boot]$ '''od -t x4 u-boot.bin | more'''
.0000000 00000206 fe000040 ffffffff a0fffe21
.0000020 00000002 fe01ad14 fe01ad8c 03f95030
.0000040 03f9aa78 04000000 00040003 03f8147c
.0000060 03f81418 00000000 00000000 00000000
.0000100 5300000c 13a00013 4800130c 13493013
.0000120 0c130200 13e62032 22002010 a03200a0
.0000140 1d837680 82037282 72822372 63728243
.0000160 72007272 72720872 18727210 2201d222
.0000200 020c80c2 3d80a032 1d8376f0 d20372d2
.0000220 72d22372 6372d243 f20072f2 72f20872
.0000240 1872f210 2201d222 200080c2 ffd92100
.0000260 37ffda31 02481d12 22681258 145722cb
.0000300 ee1467f1 664b0678 444b0479 06f43457
.0000320 0000fff8 31ffd221 4320ffd2 40443bc0
.0000340 84764142 4b020903 32020c22 837680a0
.0000360 04728211 82247282 72824472 01d22264
.0000400 1180c222 c821ffc8 13e620ff 41002010
.0000420 04d0ffc7 ffc64100 fffffd86 1049c500
.0000440 e52049d5 49f53049 00003400 00000000
.0000460 00000000 00000000 00000000 00000000
.
.(gdb) '''x/100x 0xfe000000'''
.0xfe000000 <_ResetVector>: 0x00000206 0xfe000040 0xffffffff 0xa0fffe21
.0xfe000010 <_ResetVector+16>: 0x00000002 0xfe01ad14 0xfe01ad8c 0x03f95030
.0xfe000020 <_ResetVector+32>: 0x03f9aa78 0x04000000 0x00040003 0x03f8147c
.0xfe000030 <_ResetVector+48>: 0x03f81418 0x00000000 0x00000000 0x00000000
.0xfe000040 <_start>: 0x5300000c 0x13a00013 0x4800130c 0x13493013
.0xfe000050 <_start+16>: 0x0c130200 0x13e62032 0x22002010 0xa03200a0
.0xfe000060 <_start+32>: 0x1d837680 0x82037282 0x72822372 0x63728243
.0xfe000070 <_start+48>: 0x72007272 0x72720872 0x18727210 0x2201d222
.0xfe000080 <_start+64>: 0x020c80c2 0x3d80a032 0x1d8376f0 0xd20372d2
.0xfe000090 <_start+80>: 0x72d22372 0x6372d243 0xf20072f2 0x72f20872
.0xfe0000a0 <_start+96>: 0x1872f210 0x2201d222 0x200080c2 0xffd92100
.0xfe0000b0 <_start+112>: 0x37ffda31 0x02481d12 0x22681258 0x145722cb
.0xfe0000c0 <_start+128>: 0xee1467f1 0x664b0678 0x444b0479 0x06f43457
.0xfe0000d0 <_start+144>: 0x0000fff8 0x31ffd221 0x4320ffd2 0x40443bc0
.0xfe0000e0 <_start+160>: 0x84764142 0x4b020903 0x32020c22 0x837680a0
.0xfe0000f0 <_start+176>: 0x04728211 0x82247282 0x72824472 0x01d22264
.0xfe000100 <_start+192>: 0x1180c222 0xc821ffc8 0x13e620ff 0x41002010
.0xfe000110 <_reset+1>: 0x04d0ffc7 0xffc64100 0x00fffd86 0x1049c500
.0xfe000120: 0xe52049d5 0x49f53049 0x00003400 0x00000000
.0xfe000130: 0x00000000 0x00000000 0x00000000 0x00000000
.(gdb)

Further details on U-Boot in general are in the generic <tt>README</tt> at the top of the U-Boot tree. Details specific to the Xtensa architecture are in <tt>doc/README.xtensa</tt>. Details specific to a board are in <tt>board[/<family>]/<board>/README</tt> (for example <tt>board/avnet/xtav60/README</tt>).

Setting up U-Boot

2010-11-16T09:20:47Z

Piet: /* LX60 and LX200 U-Boot Installation (LX110 in Progress) */

== LX60 and LX200 U-Boot Installation (LX110 in Progress) ==

''('''News:''' The New DC233, with the V3 MMU, is now working. Work is in progress with the Linux 2.6.29-smp kernel to boot from this updated U-Boot.

'''Summary:'''

[http://www.denx.de/wiki/UBoot U-Boot] is a very popular boot loader; especially within the [http://elinux.org/Bootloader Embedded Linux community].
The U-Boot loader runs on the FPGA boards which are equipped with a dip switch, number 8, which can select where the memory location for the reset
vector (0XFE00,0000) comes from. With switch number 8 off the board will map the memory at the reset vector to a small block of SRAM located in the
I/O block with the UART and Ethernet buffer memory. When switch number 8 is on the Avnet boards map the beginning of the Flash Memory at 0XF800,000
to the reset vector at 0xFE00,000.

What we are going to do here is build a version of U-Boot for your Avnet board and Variant, install that ELF file into memory
with xt-gdb and run U-Boot. Then we are going to download a another copy of this identical program with '''tftp'''. The version we
are going to download is just the ELF file with the headers and debug information removed. It's just the actual bits that get
loaded into memory. For the new V3 MMU the default '''loadaddr''' is typically 0x20,0000 and for the older V2 MMU this is in the
Linux mapping equivalent, 0xD0200,0000. The default location can be change by setting the U-Boot 'loadaddr' environment variable
or by changing the variable '''CONFIG_SYS_LOAD_ADDR''' in the boards U-Boot config file.

Once the virgin copy of the U-Boot program has been loaded into memory, the Flash memory is un-protected and errasd, then the
memory with the U-Boot program in it is copied to the flash memory and protected. Next you will set dip switch 8 on, recycle
power on the board, and U-Boot will be accessible via the serial UART at 38400 baud. U-Boot works without any MMU mapping,
and should be fine on configurations without an MMU. Only an ethernet and serial interface are required.

'''Proceedure:'''

A local port to the Xtensa architecture is now available at linux-xtensa.org. See [http://git.linux-xtensa.org/cgi-bin/git.cgi?p=u-boot/u-boot-xtensa.git;a=summary U-Boot Sources (GIT Summary)]. Or, to access this tree using <tt>git</tt> directly, use something like:

$ '''git clone git://git.linux-xtensa.org/git/u-boot/u-boot-xtensa.git u-boot'''
$ '''cd u-boot'''

''('''Note:''' This path is subject to change.)''

The U-Boot git repository has a branch with a HiFi 2 snapshot made for
the LX200 [[SMP HiFi 2 Development Board]]. With this branch you can simply check
out the snapshot_2+SMP branch which includes the binaries which are discussed below:

$ '''git clone git://git.linux-xtensa.org/git/u-boot/u-boot-xtensa.git u-boot'''
$ '''cd u-boot'''
$ '''git branch --track snapshot_2+SMP origin/snapshot_2+SMP'''
$ '''git checkout snapshot_2+SMP'''

$ '''ls -l u-boot u-boot.bin tools/mkimage'''
-rwxr-xr-x 1 piet tensilica 45016 2009-12-07 19:40 tools/mkimage [This is a small program you need to put in your search path to build kernel U-Boot images]
-rwxr-xr-x 1 piet tensilica 635339 2009-12-07 19:40 u-boot [Started with xt-gdb to bring up the 1st instance of a HiFi 2 U-Boot]
-rwxr-xr-x 1 piet tensilica 144944 2009-12-07 19:40 u-boot.bin [Loaded by the 1st instance of U-Boot, it's a HiFi2 version of u-boot that will be put in flash]
$

Unless you are using a U-Boot snapshot you need to build U-Boot for which you must have built the Buildroot toolchain for XTensa core.
Set your PATH to point to the toolchain built using buildroot. For example:

$ '''export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"'''

where '''<cname>''' is the name of the Xtensa core variant you wish to build for (e.g., <tt>dc232b</tt> <tt>dc233c</tt>).

To build U-Boot, use the cloned git tree pulled above, you should be at the top level of the tree in the '''u-boot''' directory , then configure it for your board and Xtensa core variant as follows:

make distclean
make <cname>'''_<board>_'''config
'dc232b'dc
This should only take a few seconds. For example, to build U-boot for the 'xtav60' board and the older 'dc232b' core with the V2 MMU type:

$ '''cd u-boot'''
$ '''make dc232b_xtav60_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

or for the new 'dc233c' core with the new V3 MMU type:

$ '''make dc233c_xtav60_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

or for a 'xtav200' board type with the new 'dc233c' core type:

$ '''make dc233c_xtav200_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

or for the snapshot_2+SMP branch you can also build U-Boot for the HiFi 2 core:

$ '''make test_mmuhifi_c3_xtav200_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

Only boards and core variants currently supported in the tree can be built out of the box. Headers for supported cores can be found in the tree under <tt>include/asm-xtensa/variant-<cname></tt>. The core specific headers are described in the <tt>doc/README.xtensa</tt> file. To support a new core, these headers must be copied from the overlay in the same way as for the linux kernel.

After the configuration step, to actually build U-Boot, simply:

$ '''make all''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

This will take a quite a few minutes.

Next, start xt-gdb and load u-boot from the top of the git repository:

$ '''xt-gdb -n''' [NOTE: Even with the HiFi 2 snapshot_2+SMP branch you still may have to put U-Boot on the board]
(xt-gdb) '''file u-boot'''
(xt-gdb) '''target remote localhost:20000 0'''
(xt-gdb) '''reset'''
(xt-gdb) '''load'''
(xt-gdb) '''break panic'''
(xt-gdb) '''continue'''

Hopefully U-Boot will start, and display on the LCD in the case of a LX60.

U-Boot 50.00 Mhz

Often you will be starting with the boards flash in an unknown state and it's best to unprotect and erase the entire flash. Just type '''protect off all''' followed by '''erase all''':

U-Boot> '''protect off all'''
Un-Protect Flash Bank # 1
................................................................................................................................... done
U-Boot> '''erase all'''
Erase Flash Bank # 1
..........................................................................................................
Flash erase timeout at address f8d40000 da0
Flash erase error at address f8d40000
........................ done
U-Boot>

The timeout and error messages are likley just warning messages and you board has been errased. You can see that with the flash info command '''flinfo'''. Below is an example with a LX200 board, which has a much larger flash than the smaller LX60:

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
F8000000 E F8020000 E F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E F8FE0000 E F8FE8000 E F8FF0000 E
F8FF8000 E
U-Boot>

The new LX110 looks very similar to the LX200, also with with 16Mb of Flash:

U-Boot> flinfo

Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 32 bytes

Sector Start Addresses:
F8000000 E F8020000 E F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E F8FE0000 E

Now set your preliminary U-Boot environment variables to point to your TFTP server so we can download yet another copy of U-Boot. At Tensilica we use a machine in the RTOS group called rtos-lab2. Folks using the [[SMP HiFi 2 Development Board]] likely have set up their workstation with a TFTP server.

U-Boot> '''setenv serverip 192.168.11.78''' rtos-lab2
or
U-Boot> '''setenv serverip 192.168.11.55''' pdelaney_fc9

U-Boot> '''setenv ipaddr 192.168.11.95''' I/P address of RTOS5, Piet's LX60; MAC: 00:05:C2:13:6f:0a

U-Boot> '''setenv bootfile u-boot.bin'''
U-Boot> '''saveenv'''
Saving Environment to Flash...
.... done
Un-Protected 4 sectors
Erasing Flash...
.... done
Erased 4 sectors
Writing to Flash... done
.... done
Protected 4 sectors
U-Boot>

Next, download '''u-boot.bin''' from the tftp server using the info we just entered into U-Boot's enviroment variables.
Here for example is the case for a LX60 running the HiFi-2 Bitstream with the older V2 MMU. Note that it starts up
in the D-gazillion (0XD0000000) region:

U-Boot> '''tftpboot'''
TFTP from server 192.168.11.78; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0xd2000000
Loading: T ########
done
Bytes transferred = 107592 (1a448 hex)

For the V3 MMU U-Boot is loaded from host pdelaney_fc9 into memory with virtual == physical. Here is a DC233L, with V3 MMU, example:

U-Boot> '''tftpboot'''
Using open_ethernet device
TFTP from server 192.168.11.55; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: T ########
done
Bytes transferred = 109964 (1ad8c hex)
U-Boot>

Now things get a bit tricky here for the LX60. The FLASH has '''Two sizes of Flash Sectors'''.
The first 8 sectors are small 0x2000 (8KB) and apparently intended for parameters. The rest
of the 4MB flash is composed of larger 0x10000 (64KB) sectors. Our code doesn't differentiate
between the sectors and the LX60 hardware is going to map 0XF800,0000 to 0XFE00,0000 so this
makes us use of all 8 of the 8KB sectors and the 1st 64KB sector at F8010000. So we are going
to flash up to F801FFFF below.

On a LX200 we have much more space and can easily fit a version of U-boot that has been compiled without optimization, make debugging much easier.
So in this case the image is a bit larger, but relatively similar to the LX60 (2 sectors):

U-Boot> '''tftpboot'''
Using open_ethernet device
TFTP from server 192.168.11.78; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0xd2000000
Loading: ###############
done
Bytes transferred = 205852 (3241c hex)
U-Boot>

On a LX110 we have less memory than an LX60, but FLASH sectors like the LX200. It turns out that the u-boot image
compiled with optimization is just a bit larger than 1 sector, so like the LX200 we will need to write u-boot
into two sectors. Here's and example tftpboot of U-Bot for the LX110:

U-Boot> tftpboot
Using open_ethernet device
TFTP from server 192.168.11.55; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: ##########
done
Bytes transferred = 144956 (2363c hex)
U-Boot>

Note that for both the LX200 and the LX60 that the image size, '''(3241c hex)''' in this case, is a bit less than 0x40000 or 10 sectors,
so turn off protection on the 1st 11 sectors and
erase the current contents.

For the '''LX60''' you do this:

U-Boot> '''protect off F8000000 F801FFFF'''
... done
Un-Protected 2 sectors
U-Boot> '''erase F8000000 F801FFFF'''
erase F8000000 F801FFFF
... done

For the '''LX200''' and the '''LX110''' the starting address '''(F8000000)''' is the same as with the LX60 but the last address '''(F803FFFF)''' is 'twice' as high:

U-Boot> '''protect off F8000000 F803FFFF'''
... done
Un-Protected 2 sectors
U-Boot> '''erase F8000000 F803FFFF'''
Erased 2 sectors
U-Boot>

Now copy the the image of u-boot.bin in memory to the flash. For the XL60 with the '''OLD''' V2 MMU you copy 0x20000
bytes from 0xd2000000 to 0XF8000000:

U-Boot> '''cp.b d2000000 F8000000 20000'''
Copy to Flash... done

For the LX60 with the '''NEW''' V3 MMU you copy 0x24000 bytes from 0x2000000 to F8000000:

U-Boot> '''cp.b 2000000 F8000000 20000'''
Copy to Flash... done

For the LX200 you copy 0x40000 bytes from 0xd2000000 to 0XF8000000...0XF803FFFF:

U-Boot> '''cp.b d2000000 F8000000 40000'''
Copy to Flash... done

For the LX110 with a V3-MMU you copy 0x40000 bytes from 0x2000000 to F8000000:
U-Boot> cp.b 2000000 F8000000 40000
Copy to Flash... done

Finally we protect these sectors so that U-Boot isn't easily erased by accident.
Below is what it looks like on a LX60 with the New V3 MMU with a subsequent display of the flash info:

U-Boot> '''cp.b 2000000 F8000000 2000'''
Copy to Flash... done
U-Boot> flinfo

Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x2257
Erase timeout: 8192 ms, write timeout: 1 ms

Sector Start Addresses:
'''F8000000 F8002000 F8004000 F8006000 F8008000'''
'''F800A000 F800C000 F800E000 F8010000 '''F8020000 E
F8030000 E F8040000 E F8050000 E F8060000 E F8070000 E
F8080000 E F8090000 E F80A0000 E F80B0000 E F80C0000 E
F80D0000 E F80E0000 E F80F0000 E F8100000 E F8110000 E
F8120000 E F8130000 E F8140000 E F8150000 E F8160000 E
F8170000 E F8180000 E F8190000 E F81A0000 E F81B0000 E
F81C0000 E F81D0000 E F81E0000 E F81F0000 E F8200000 E
F8210000 E F8220000 E F8230000 E F8240000 E F8250000 E
F8260000 E F8270000 E F8280000 E F8290000 E F82A0000 E
F82B0000 E F82C0000 E F82D0000 E F82E0000 E F82F0000 E
F8300000 E F8310000 E F8320000 E F8330000 E F8340000 E
F8350000 E F8360000 E F8370000 E F8380000 E F8390000 E
F83A0000 E F83B0000 E F83C0000 E F83D0000 E F83E0000
'''F83F0000 RO'''
U-Boot> '''protect on F8000000 F802FFFF'''
.......... done
Protected 10 sectors
U-Boot>

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x2257
Erase timeout: 8192 ms, write timeout: 1 ms

Sector Start Addresses:
'''F8000000 RO F8002000 RO F8004000 RO F8006000 RO F8008000 RO
F800A000 RO F800C000 RO F800E000 RO F8010000 RO''' F8020000 E
F8030000 E F8040000 E F8050000 E F8060000 E F8070000 E
F8080000 E F8090000 E F80A0000 E F80B0000 E F80C0000 E
F80D0000 E F80E0000 E F80F0000 E F8100000 E F8110000 E
F8120000 E F8130000 E F8140000 E F8150000 E F8160000 E
F8170000 E F8180000 E F8190000 E F81A0000 E F81B0000 E
F81C0000 E F81D0000 E F81E0000 E F81F0000 E F8200000 E
F8210000 E F8220000 E F8230000 E F8240000 E F8250000 E
F8260000 E F8270000 E F8280000 E F8290000 E F82A0000 E
F82B0000 E F82C0000 E F82D0000 E F82E0000 E F82F0000 E
F8300000 E F8310000 E F8320000 E F8330000 E F8340000 E
F8350000 E F8360000 E F8370000 E F8380000 E F8390000 E
F83A0000 E F83B0000 E F83C0000 E F83D0000 E F83E0000
'''F83F0000 RO'''
U-Boot>

For the '''LX110''' with the '''V3-MMU''' here's what the flash info looks like after we
protect the first two sectors with U-Boot copied to it:

U-Boot> '''protect on F8000000 F803FFFF'''
Protected 2 sectors
U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 32 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E '''F8FE0000 RO'''
U-Boot> help

Below is what it looks like on a LX200 with the V2 MMU with a subsequent display of the flash info.
Notice that the Flash Sectors are 10X as large on the LX200:

U-Boot> '''protect on F8000000 F802FFFF'''
.. done
Protected 2 sectors
U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E '''F8FE0000 RO F8FE8000 RO F8FF0000 RO'''
'''F8FF8000 RO'''
U-Boot>

Note that the U-Boot '''saveenv''' command Erased and protected the last four sectors
of this LX200.

On both the LX60 and the LX200 now move DIP switch 8 to the ON position, power cycle the board. On the LX60 you should see U-boot in the LCD display.

The '''LX60''' with the new V3 MMU the serial console should print something like the following:

U-Boot 2009.08-dirty (Sep 10 2010 - 18:23:26)

CPU: Xtensa dc233c at 50.00 MHz
Board: XT-AV60: Avnet board + Xilinx LX60 FPGA + Tensilica bitstream
SysRAM: 64 MB
Flash: 4 MB
In: serial
Out: serial
Err: serial
MAC: 00:50:C2:13:6f:0a
IP: 192.168.11.95
open_ethernet
U-Boot>

On the '''LX200''', shown below with the old V2 MMU, you should see something like the following. In this case we also show the flash info command, '''flinfo''', being invoked just after booting U-Boot:

CPU: Xtensa test_mmuhifi_c3 at 41.6777 MHz
Board: XT-AV200: Avnet board + Xilinx LX200 FPGA + Tensilica bitstream
SysRAM: 96 MB
Flash: 16 MB
In: serial
Out: serial
Err: serial
MAC:
IP: 192.168.11.95
U-Boot>

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E RO F8060000 E RO F8080000 E RO
F80A0000 E RO F80C0000 E RO F80E0000 E RO F8100000 E RO F8120000 E RO
F8140000 E RO F8160000 E RO F8180000 E RO F81A0000 E RO F81C0000 E RO
F81E0000 E RO F8200000 E RO F8220000 E RO F8240000 E RO F8260000 E RO
F8280000 E RO F82A0000 E RO F82C0000 E RO F82E0000 E RO F8300000 E RO
F8320000 E RO F8340000 E RO F8360000 E RO F8380000 E RO F83A0000 E RO
F83C0000 E RO F83E0000 E RO F8400000 E RO F8420000 E RO F8440000 E RO
F8460000 E RO F8480000 E RO F84A0000 E RO F84C0000 E RO F84E0000 E RO
F8500000 E RO F8520000 E RO F8540000 E RO F8560000 E RO F8580000 E RO
F85A0000 E RO F85C0000 E RO F85E0000 E RO F8600000 E RO F8620000 E RO
F8640000 E RO F8660000 E RO F8680000 E RO F86A0000 E RO F86C0000 E RO
F86E0000 E RO F8700000 E RO F8720000 E RO F8740000 E RO F8760000 E RO
F8780000 E RO F87A0000 E RO F87C0000 E RO F87E0000 E RO F8800000 E RO
F8820000 E RO F8840000 E RO F8860000 E RO F8880000 E RO F88A0000 E RO
F88C0000 E RO F88E0000 E RO F8900000 E RO F8920000 E RO F8940000 E RO
F8960000 E RO F8980000 E RO F89A0000 E RO F89C0000 E RO F89E0000 E RO
F8A00000 E RO F8A20000 E RO F8A40000 E RO F8A60000 E RO F8A80000 E RO
F8AA0000 E RO F8AC0000 E RO F8AE0000 E RO F8B00000 E RO F8B20000 E RO
F8B40000 E RO F8B60000 E RO F8B80000 E RO F8BA0000 E RO F8BC0000 E RO
F8BE0000 E RO F8C00000 E RO F8C20000 E RO F8C40000 E RO F8C60000 E RO
F8C80000 E RO F8CA0000 E RO F8CC0000 E RO F8CE0000 E RO F8D00000 E RO
F8D20000 E RO F8D40000 E RO F8D60000 E RO F8D80000 E RO F8DA0000 E RO
F8DC0000 E RO F8DE0000 E RO F8E00000 E RO F8E20000 E RO F8E40000 E RO
F8E60000 E RO F8E80000 E RO F8EA0000 E RO F8EC0000 E RO F8EE0000 E RO
F8F00000 E RO F8F20000 E RO F8F40000 E RO F8F60000 E RO F8F80000 E RO
F8FA0000 E RO F8FC0000 E RO '''F8FE0000 RO F8FE8000 RO F8FF0000 RO'''
'''F8FF8000 RO'''
U-Boot>

Note that the 1st two sectors with U-Boot saved in them came up as not being erased ('''E''') but that all sectors came up Read Only ('''RO''').
Same with the last four sectors that the U-Boot '''saveenv''' command Erased. This is likely a '''bug''' on the LX200 boards with some preliminary investigation.
We will be discussing this with the U-Boot developers sometime in the future prior to pushing our U-boot changes upstream.

If U-Boot fails to boot ya might try making sure your U-Boot '''serverip''' environment variable matches the address of the tftp server where
you have copied your '''u-boot.bin''' file to and comparing the bits in the flash that got mapped to 0xfe00,0000 to what in the file:

u-boot]$ '''od -t x4 u-boot.bin | more'''
.0000000 00000206 fe000040 ffffffff a0fffe21
.0000020 00000002 fe01ad14 fe01ad8c 03f95030
.0000040 03f9aa78 04000000 00040003 03f8147c
.0000060 03f81418 00000000 00000000 00000000
.0000100 5300000c 13a00013 4800130c 13493013
.0000120 0c130200 13e62032 22002010 a03200a0
.0000140 1d837680 82037282 72822372 63728243
.0000160 72007272 72720872 18727210 2201d222
.0000200 020c80c2 3d80a032 1d8376f0 d20372d2
.0000220 72d22372 6372d243 f20072f2 72f20872
.0000240 1872f210 2201d222 200080c2 ffd92100
.0000260 37ffda31 02481d12 22681258 145722cb
.0000300 ee1467f1 664b0678 444b0479 06f43457
.0000320 0000fff8 31ffd221 4320ffd2 40443bc0
.0000340 84764142 4b020903 32020c22 837680a0
.0000360 04728211 82247282 72824472 01d22264
.0000400 1180c222 c821ffc8 13e620ff 41002010
.0000420 04d0ffc7 ffc64100 fffffd86 1049c500
.0000440 e52049d5 49f53049 00003400 00000000
.0000460 00000000 00000000 00000000 00000000
.
.(gdb) '''x/100x 0xfe000000'''
.0xfe000000 <_ResetVector>: 0x00000206 0xfe000040 0xffffffff 0xa0fffe21
.0xfe000010 <_ResetVector+16>: 0x00000002 0xfe01ad14 0xfe01ad8c 0x03f95030
.0xfe000020 <_ResetVector+32>: 0x03f9aa78 0x04000000 0x00040003 0x03f8147c
.0xfe000030 <_ResetVector+48>: 0x03f81418 0x00000000 0x00000000 0x00000000
.0xfe000040 <_start>: 0x5300000c 0x13a00013 0x4800130c 0x13493013
.0xfe000050 <_start+16>: 0x0c130200 0x13e62032 0x22002010 0xa03200a0
.0xfe000060 <_start+32>: 0x1d837680 0x82037282 0x72822372 0x63728243
.0xfe000070 <_start+48>: 0x72007272 0x72720872 0x18727210 0x2201d222
.0xfe000080 <_start+64>: 0x020c80c2 0x3d80a032 0x1d8376f0 0xd20372d2
.0xfe000090 <_start+80>: 0x72d22372 0x6372d243 0xf20072f2 0x72f20872
.0xfe0000a0 <_start+96>: 0x1872f210 0x2201d222 0x200080c2 0xffd92100
.0xfe0000b0 <_start+112>: 0x37ffda31 0x02481d12 0x22681258 0x145722cb
.0xfe0000c0 <_start+128>: 0xee1467f1 0x664b0678 0x444b0479 0x06f43457
.0xfe0000d0 <_start+144>: 0x0000fff8 0x31ffd221 0x4320ffd2 0x40443bc0
.0xfe0000e0 <_start+160>: 0x84764142 0x4b020903 0x32020c22 0x837680a0
.0xfe0000f0 <_start+176>: 0x04728211 0x82247282 0x72824472 0x01d22264
.0xfe000100 <_start+192>: 0x1180c222 0xc821ffc8 0x13e620ff 0x41002010
.0xfe000110 <_reset+1>: 0x04d0ffc7 0xffc64100 0x00fffd86 0x1049c500
.0xfe000120: 0xe52049d5 0x49f53049 0x00003400 0x00000000
.0xfe000130: 0x00000000 0x00000000 0x00000000 0x00000000
.(gdb)

Further details on U-Boot in general are in the generic <tt>README</tt> at the top of the U-Boot tree. Details specific to the Xtensa architecture are in <tt>doc/README.xtensa</tt>. Details specific to a board are in <tt>board[/<family>]/<board>/README</tt> (for example <tt>board/avnet/xtav60/README</tt>).

Setting up U-Boot

2010-11-16T09:19:54Z

Piet: /* LX60 and LX200 U-Boot Installation (LX110 in Progress) */

== LX60 and LX200 U-Boot Installation (LX110 in Progress) ==

''('''News:''' The New DC233, with the V3 MMU, is now working. Work is in progress with the Linux 2.6.29-smp kernel to boot from this updated U-Boot.

'''Summary:'''

[http://www.denx.de/wiki/UBoot U-Boot] is a very popular boot loader; especially within the [http://elinux.org/Bootloader Embedded Linux community].
The U-Boot loader runs on the FPGA boards which are equipped with a dip switch, number 8, which can select where the memory location for the reset
vector (0XFE00,0000) comes from. With switch number 8 off the board will map the memory at the reset vector to a small block of SRAM located in the
I/O block with the UART and Ethernet buffer memory. When switch number 8 is on the Avnet boards map the beginning of the Flash Memory at 0XF800,000
to the reset vector at 0xFE00,000.

What we are going to do here is build a version of U-Boot for your Avnet board and Variant, install that ELF file into memory
with xt-gdb and run U-Boot. Then we are going to download a another copy of this identical program with '''tftp'''. The version we
are going to download is just the ELF file with the headers and debug information removed. It's just the actual bits that get
loaded into memory. For the new V3 MMU the default '''loadaddr''' is typically 0x20,0000 and for the older V2 MMU this is in the
Linux mapping equivalent, 0xD0200,0000. The default location can be change by setting the U-Boot 'loadaddr' environment variable
or by changing the variable '''CONFIG_SYS_LOAD_ADDR''' in the boards U-Boot config file.

Once the virgin copy of the U-Boot program has been loaded into memory, the Flash memory is un-protected and errasd, then the
memory with the U-Boot program in it is copied to the flash memory and protected. Next you will set dip switch 8 on, recycle
power on the board, and U-Boot will be accessible via the serial UART at 38400 baud. U-Boot works without any MMU mapping,
and should be fine on configurations without an MMU. Only an ethernet and serial interface are required.

'''Proceedure:'''

A local port to the Xtensa architecture is now available at linux-xtensa.org. See [http://git.linux-xtensa.org/cgi-bin/git.cgi?p=u-boot/u-boot-xtensa.git;a=summary U-Boot Sources (GIT Summary)]. Or, to access this tree using <tt>git</tt> directly, use something like:

$ '''git clone git://git.linux-xtensa.org/git/u-boot/u-boot-xtensa.git u-boot'''
$ '''cd u-boot'''

''('''Note:''' This path is subject to change.)''

The U-Boot git repository has a branch with a HiFi 2 snapshot made for
the LX200 [[SMP HiFi 2 Development Board]]. With this branch you can simply check
out the snapshot_2+SMP branch which includes the binaries which are discussed below:

$ '''git clone git://git.linux-xtensa.org/git/u-boot/u-boot-xtensa.git u-boot'''
$ '''cd u-boot'''
$ '''git branch --track snapshot_2+SMP origin/snapshot_2+SMP'''
$ '''git checkout snapshot_2+SMP'''

$ '''ls -l u-boot u-boot.bin tools/mkimage'''
-rwxr-xr-x 1 piet tensilica 45016 2009-12-07 19:40 tools/mkimage [This is a small program you need to put in your search path to build kernel U-Boot images]
-rwxr-xr-x 1 piet tensilica 635339 2009-12-07 19:40 u-boot [Started with xt-gdb to bring up the 1st instance of a HiFi 2 U-Boot]
-rwxr-xr-x 1 piet tensilica 144944 2009-12-07 19:40 u-boot.bin [Loaded by the 1st instance of U-Boot, it's a HiFi2 version of u-boot that will be put in flash]
$

Unless you are using a U-Boot snapshot you need to build U-Boot for which you must have built the Buildroot toolchain for XTensa core.
Set your PATH to point to the toolchain built using buildroot. For example:

$ '''export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"'''

where '''<cname>''' is the name of the Xtensa core variant you wish to build for (e.g., <tt>dc232b</tt> <tt>dc233c</tt>).

To build U-Boot, use the cloned git tree pulled above, you should be at the top level of the tree in the '''u-boot''' directory , then configure it for your board and Xtensa core variant as follows:

make distclean
make <cname>'''_<board>_'''config
'dc232b'dc
This should only take a few seconds. For example, to build U-boot for the 'xtav60' board and the older 'dc232b' core with the V2 MMU type:

$ '''cd u-boot'''
$ '''make dc232b_xtav60_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

or for the new 'dc233c' core with the new V3 MMU type:

$ '''make dc233c_xtav60_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

or for a 'xtav200' board type with the new 'dc233c' core type:

$ '''make dc233c_xtav200_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

or for the snapshot_2+SMP branch you can also build U-Boot for the HiFi 2 core:

$ '''make test_mmuhifi_c3_xtav200_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

Only boards and core variants currently supported in the tree can be built out of the box. Headers for supported cores can be found in the tree under <tt>include/asm-xtensa/variant-<cname></tt>. The core specific headers are described in the <tt>doc/README.xtensa</tt> file. To support a new core, these headers must be copied from the overlay in the same way as for the linux kernel.

After the configuration step, to actually build U-Boot, simply:

$ '''make all''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

This will take a quite a few minutes.

Next, start xt-gdb and load u-boot from the top of the git repository:

$ '''xt-gdb -n''' [NOTE: Even with the HiFi 2 snapshot_2+SMP branch you still may have to put U-Boot on the board]
(xt-gdb) '''file u-boot'''
(xt-gdb) '''target remote localhost:20000 0'''
(xt-gdb) '''reset'''
(xt-gdb) '''load'''
(xt-gdb) '''break panic'''
(xt-gdb) '''continue'''

Hopefully U-Boot will start, and display on the LCD in the case of a LX60.

U-Boot 50.00 Mhz

Often you will be starting with the boards flash in an unknown state and it's best to unprotect and erase the entire flash. Just type '''protect off all''' followed by '''erase all''':

U-Boot> '''protect off all'''
Un-Protect Flash Bank # 1
................................................................................................................................... done
U-Boot> '''erase all'''
Erase Flash Bank # 1
..........................................................................................................
Flash erase timeout at address f8d40000 da0
Flash erase error at address f8d40000
........................ done
U-Boot>

The timeout and error messages are likley just warning messages and you board has been errased. You can see that with the flash info command '''flinfo'''. Below is an example with a LX200 board, which has a much larger flash than the smaller LX60:

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
F8000000 E F8020000 E F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E F8FE0000 E F8FE8000 E F8FF0000 E
F8FF8000 E
U-Boot>

The new LX110 looks very similar to the LX200, also with with 16Mb of Flash:

U-Boot> flinfo

Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 32 bytes

Sector Start Addresses:
F8000000 E F8020000 E F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E F8FE0000 E

Now set your preliminary U-Boot environment variables to point to your TFTP server so we can download yet another copy of U-Boot. At Tensilica we use a machine in the RTOS group called rtos-lab2. Folks using the [[SMP HiFi 2 Development Board]] likely have set up their workstation with a TFTP server.

U-Boot> '''setenv serverip 192.168.11.78''' rtos-lab2
or
U-Boot> '''setenv serverip 192.168.11.55''' pdelaney_fc9

U-Boot> '''setenv ipaddr 192.168.11.95''' I/P address of RTOS5, Piet's LX60; MAC: 00:05:C2:13:6f:0a

U-Boot> '''setenv bootfile u-boot.bin'''
U-Boot> '''saveenv'''
Saving Environment to Flash...
.... done
Un-Protected 4 sectors
Erasing Flash...
.... done
Erased 4 sectors
Writing to Flash... done
.... done
Protected 4 sectors
U-Boot>

Next, download '''u-boot.bin''' from the tftp server using the info we just entered into U-Boot's enviroment variables.
Here for example is the case for a LX60 running the HiFi-2 Bitstream with the older V2 MMU. Note that it starts up
in the D-gazillion (0XD0000000) region:

U-Boot> '''tftpboot'''
TFTP from server 192.168.11.78; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0xd2000000
Loading: T ########
done
Bytes transferred = 107592 (1a448 hex)

For the V3 MMU U-Boot is loaded from host pdelaney_fc9 into memory with virtual == physical. Here is a DC233L, with V3 MMU, example:

U-Boot> '''tftpboot'''
Using open_ethernet device
TFTP from server 192.168.11.55; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: T ########
done
Bytes transferred = 109964 (1ad8c hex)
U-Boot>

Now things get a bit tricky here for the LX60. The FLASH has '''Two sizes of Flash Sectors'''.
The first 8 sectors are small 0x2000 (8KB) and apparently intended for parameters. The rest
of the 4MB flash is composed of larger 0x10000 (64KB) sectors. Our code doesn't differentiate
between the sectors and the LX60 hardware is going to map 0XF800,0000 to 0XFE00,0000 so this
makes us use of all 8 of the 8KB sectors and the 1st 64KB sector at F8010000. So we are going
to flash up to F801FFFF below.

On a LX200 we have much more space and can easily fit a version of U-boot that has been compiled without optimization, make debugging much easier.
So in this case the image is a bit larger, but relatively similar to the LX60 (2 sectors):

U-Boot> '''tftpboot'''
Using open_ethernet device
TFTP from server 192.168.11.78; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0xd2000000
Loading: ###############
done
Bytes transferred = 205852 (3241c hex)
U-Boot>

On a LX110 we have less memory than an LX60, but FLASH sectors like the LX200. It turns out that the u-boot image
compiled with optimization is just a bit larger than 1 sector, so like the LX200 we will need to write u-boot
into two sectors. Here's and example tftpboot of U-Bot for the LX110:

U-Boot> tftpboot
Using open_ethernet device
TFTP from server 192.168.11.55; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: ##########
done
Bytes transferred = 144956 (2363c hex)
U-Boot>

Note that for both the LX200 and the LX60 that the image size, '''(3241c hex)''' in this case, is a bit less than 0x40000 or 10 sectors,
so turn off protection on the 1st 11 sectors and
erase the current contents.

For the '''LX60''' you do this:

U-Boot> '''protect off F8000000 F801FFFF'''
... done
Un-Protected 2 sectors
U-Boot> '''erase F8000000 F801FFFF'''
erase F8000000 F801FFFF
... done

For the '''LX200''' and the '''LX110''' the starting address '''(F8000000)''' is the same as with the LX60 but the last address '''(F803FFFF)''' is 'twice' as high:

U-Boot> '''protect off F8000000 F803FFFF'''
... done
Un-Protected 2 sectors
U-Boot> '''erase F8000000 F803FFFF'''
Erased 2 sectors
U-Boot>

Now copy the the image of u-boot.bin in memory to the flash. For the XL60 with the '''OLD''' V2 MMU you copy 0x20000
bytes from 0xd2000000 to 0XF8000000:

U-Boot> '''cp.b d2000000 F8000000 20000'''
Copy to Flash... done

For the LX60 with the '''NEW''' V3 MMU you copy 0x24000 bytes from 0x2000000 to F8000000:

U-Boot> '''cp.b 2000000 F8000000 20000'''
Copy to Flash... done

For the LX200 you copy 0x40000 bytes from 0xd2000000 to 0XF8000000...0XF803FFFF:

U-Boot> '''cp.b d2000000 F8000000 40000'''
Copy to Flash... done

For the LX110 with a V3-MMU you copy 0x40000 bytes from 0x2000000 to F8000000:
U-Boot> cp.b 2000000 F8000000 40000
Copy to Flash... done

Finally we protect these sectors so that U-Boot isn't easily erased by accident.
Below is what it looks like on a LX60 with the New V3 MMU with a subsequent display of the flash info:

U-Boot> '''cp.b 2000000 F8000000 2000'''
Copy to Flash... done
U-Boot> flinfo

Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x2257
Erase timeout: 8192 ms, write timeout: 1 ms

Sector Start Addresses:
'''F8000000 F8002000 F8004000 F8006000 F8008000'''
'''F800A000 F800C000 F800E000 F8010000 '''F8020000 E
F8030000 E F8040000 E F8050000 E F8060000 E F8070000 E
F8080000 E F8090000 E F80A0000 E F80B0000 E F80C0000 E
F80D0000 E F80E0000 E F80F0000 E F8100000 E F8110000 E
F8120000 E F8130000 E F8140000 E F8150000 E F8160000 E
F8170000 E F8180000 E F8190000 E F81A0000 E F81B0000 E
F81C0000 E F81D0000 E F81E0000 E F81F0000 E F8200000 E
F8210000 E F8220000 E F8230000 E F8240000 E F8250000 E
F8260000 E F8270000 E F8280000 E F8290000 E F82A0000 E
F82B0000 E F82C0000 E F82D0000 E F82E0000 E F82F0000 E
F8300000 E F8310000 E F8320000 E F8330000 E F8340000 E
F8350000 E F8360000 E F8370000 E F8380000 E F8390000 E
F83A0000 E F83B0000 E F83C0000 E F83D0000 E F83E0000
'''F83F0000 RO'''
U-Boot> '''protect on F8000000 F802FFFF'''
.......... done
Protected 10 sectors
U-Boot>

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x2257
Erase timeout: 8192 ms, write timeout: 1 ms

Sector Start Addresses:
'''F8000000 RO F8002000 RO F8004000 RO F8006000 RO F8008000 RO
F800A000 RO F800C000 RO F800E000 RO F8010000 RO''' F8020000 E
F8030000 E F8040000 E F8050000 E F8060000 E F8070000 E
F8080000 E F8090000 E F80A0000 E F80B0000 E F80C0000 E
F80D0000 E F80E0000 E F80F0000 E F8100000 E F8110000 E
F8120000 E F8130000 E F8140000 E F8150000 E F8160000 E
F8170000 E F8180000 E F8190000 E F81A0000 E F81B0000 E
F81C0000 E F81D0000 E F81E0000 E F81F0000 E F8200000 E
F8210000 E F8220000 E F8230000 E F8240000 E F8250000 E
F8260000 E F8270000 E F8280000 E F8290000 E F82A0000 E
F82B0000 E F82C0000 E F82D0000 E F82E0000 E F82F0000 E
F8300000 E F8310000 E F8320000 E F8330000 E F8340000 E
F8350000 E F8360000 E F8370000 E F8380000 E F8390000 E
F83A0000 E F83B0000 E F83C0000 E F83D0000 E F83E0000
'''F83F0000 RO'''
U-Boot>

For the LX110 with the V3-MMU here's what the flash info looks like after we
protect the first two sectors with U-Boot copied to it:

U-Boot> '''protect on F8000000 F803FFFF'''
Protected 2 sectors
U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 32 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E '''F8FE0000 RO'''
U-Boot> help

Below is what it looks like on a LX200 with the V2 MMU with a subsequent display of the flash info.
Notice that the Flash Sectors are 10X as large on the LX200:

U-Boot> '''protect on F8000000 F802FFFF'''
.. done
Protected 2 sectors
U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E '''F8FE0000 RO F8FE8000 RO F8FF0000 RO'''
'''F8FF8000 RO'''
U-Boot>

Note that the U-Boot '''saveenv''' command Erased and protected the last four sectors
of this LX200.

On both the LX60 and the LX200 now move DIP switch 8 to the ON position, power cycle the board. On the LX60 you should see U-boot in the LCD display.

The '''LX60''' with the new V3 MMU the serial console should print something like the following:

U-Boot 2009.08-dirty (Sep 10 2010 - 18:23:26)

CPU: Xtensa dc233c at 50.00 MHz
Board: XT-AV60: Avnet board + Xilinx LX60 FPGA + Tensilica bitstream
SysRAM: 64 MB
Flash: 4 MB
In: serial
Out: serial
Err: serial
MAC: 00:50:C2:13:6f:0a
IP: 192.168.11.95
open_ethernet
U-Boot>

On the '''LX200''', shown below with the old V2 MMU, you should see something like the following. In this case we also show the flash info command, '''flinfo''', being invoked just after booting U-Boot:

CPU: Xtensa test_mmuhifi_c3 at 41.6777 MHz
Board: XT-AV200: Avnet board + Xilinx LX200 FPGA + Tensilica bitstream
SysRAM: 96 MB
Flash: 16 MB
In: serial
Out: serial
Err: serial
MAC:
IP: 192.168.11.95
U-Boot>

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E RO F8060000 E RO F8080000 E RO
F80A0000 E RO F80C0000 E RO F80E0000 E RO F8100000 E RO F8120000 E RO
F8140000 E RO F8160000 E RO F8180000 E RO F81A0000 E RO F81C0000 E RO
F81E0000 E RO F8200000 E RO F8220000 E RO F8240000 E RO F8260000 E RO
F8280000 E RO F82A0000 E RO F82C0000 E RO F82E0000 E RO F8300000 E RO
F8320000 E RO F8340000 E RO F8360000 E RO F8380000 E RO F83A0000 E RO
F83C0000 E RO F83E0000 E RO F8400000 E RO F8420000 E RO F8440000 E RO
F8460000 E RO F8480000 E RO F84A0000 E RO F84C0000 E RO F84E0000 E RO
F8500000 E RO F8520000 E RO F8540000 E RO F8560000 E RO F8580000 E RO
F85A0000 E RO F85C0000 E RO F85E0000 E RO F8600000 E RO F8620000 E RO
F8640000 E RO F8660000 E RO F8680000 E RO F86A0000 E RO F86C0000 E RO
F86E0000 E RO F8700000 E RO F8720000 E RO F8740000 E RO F8760000 E RO
F8780000 E RO F87A0000 E RO F87C0000 E RO F87E0000 E RO F8800000 E RO
F8820000 E RO F8840000 E RO F8860000 E RO F8880000 E RO F88A0000 E RO
F88C0000 E RO F88E0000 E RO F8900000 E RO F8920000 E RO F8940000 E RO
F8960000 E RO F8980000 E RO F89A0000 E RO F89C0000 E RO F89E0000 E RO
F8A00000 E RO F8A20000 E RO F8A40000 E RO F8A60000 E RO F8A80000 E RO
F8AA0000 E RO F8AC0000 E RO F8AE0000 E RO F8B00000 E RO F8B20000 E RO
F8B40000 E RO F8B60000 E RO F8B80000 E RO F8BA0000 E RO F8BC0000 E RO
F8BE0000 E RO F8C00000 E RO F8C20000 E RO F8C40000 E RO F8C60000 E RO
F8C80000 E RO F8CA0000 E RO F8CC0000 E RO F8CE0000 E RO F8D00000 E RO
F8D20000 E RO F8D40000 E RO F8D60000 E RO F8D80000 E RO F8DA0000 E RO
F8DC0000 E RO F8DE0000 E RO F8E00000 E RO F8E20000 E RO F8E40000 E RO
F8E60000 E RO F8E80000 E RO F8EA0000 E RO F8EC0000 E RO F8EE0000 E RO
F8F00000 E RO F8F20000 E RO F8F40000 E RO F8F60000 E RO F8F80000 E RO
F8FA0000 E RO F8FC0000 E RO '''F8FE0000 RO F8FE8000 RO F8FF0000 RO'''
'''F8FF8000 RO'''
U-Boot>

Note that the 1st two sectors with U-Boot saved in them came up as not being erased ('''E''') but that all sectors came up Read Only ('''RO''').
Same with the last four sectors that the U-Boot '''saveenv''' command Erased. This is likely a '''bug''' on the LX200 boards with some preliminary investigation.
We will be discussing this with the U-Boot developers sometime in the future prior to pushing our U-boot changes upstream.

If U-Boot fails to boot ya might try making sure your U-Boot '''serverip''' environment variable matches the address of the tftp server where
you have copied your '''u-boot.bin''' file to and comparing the bits in the flash that got mapped to 0xfe00,0000 to what in the file:

u-boot]$ '''od -t x4 u-boot.bin | more'''
.0000000 00000206 fe000040 ffffffff a0fffe21
.0000020 00000002 fe01ad14 fe01ad8c 03f95030
.0000040 03f9aa78 04000000 00040003 03f8147c
.0000060 03f81418 00000000 00000000 00000000
.0000100 5300000c 13a00013 4800130c 13493013
.0000120 0c130200 13e62032 22002010 a03200a0
.0000140 1d837680 82037282 72822372 63728243
.0000160 72007272 72720872 18727210 2201d222
.0000200 020c80c2 3d80a032 1d8376f0 d20372d2
.0000220 72d22372 6372d243 f20072f2 72f20872
.0000240 1872f210 2201d222 200080c2 ffd92100
.0000260 37ffda31 02481d12 22681258 145722cb
.0000300 ee1467f1 664b0678 444b0479 06f43457
.0000320 0000fff8 31ffd221 4320ffd2 40443bc0
.0000340 84764142 4b020903 32020c22 837680a0
.0000360 04728211 82247282 72824472 01d22264
.0000400 1180c222 c821ffc8 13e620ff 41002010
.0000420 04d0ffc7 ffc64100 fffffd86 1049c500
.0000440 e52049d5 49f53049 00003400 00000000
.0000460 00000000 00000000 00000000 00000000
.
.(gdb) '''x/100x 0xfe000000'''
.0xfe000000 <_ResetVector>: 0x00000206 0xfe000040 0xffffffff 0xa0fffe21
.0xfe000010 <_ResetVector+16>: 0x00000002 0xfe01ad14 0xfe01ad8c 0x03f95030
.0xfe000020 <_ResetVector+32>: 0x03f9aa78 0x04000000 0x00040003 0x03f8147c
.0xfe000030 <_ResetVector+48>: 0x03f81418 0x00000000 0x00000000 0x00000000
.0xfe000040 <_start>: 0x5300000c 0x13a00013 0x4800130c 0x13493013
.0xfe000050 <_start+16>: 0x0c130200 0x13e62032 0x22002010 0xa03200a0
.0xfe000060 <_start+32>: 0x1d837680 0x82037282 0x72822372 0x63728243
.0xfe000070 <_start+48>: 0x72007272 0x72720872 0x18727210 0x2201d222
.0xfe000080 <_start+64>: 0x020c80c2 0x3d80a032 0x1d8376f0 0xd20372d2
.0xfe000090 <_start+80>: 0x72d22372 0x6372d243 0xf20072f2 0x72f20872
.0xfe0000a0 <_start+96>: 0x1872f210 0x2201d222 0x200080c2 0xffd92100
.0xfe0000b0 <_start+112>: 0x37ffda31 0x02481d12 0x22681258 0x145722cb
.0xfe0000c0 <_start+128>: 0xee1467f1 0x664b0678 0x444b0479 0x06f43457
.0xfe0000d0 <_start+144>: 0x0000fff8 0x31ffd221 0x4320ffd2 0x40443bc0
.0xfe0000e0 <_start+160>: 0x84764142 0x4b020903 0x32020c22 0x837680a0
.0xfe0000f0 <_start+176>: 0x04728211 0x82247282 0x72824472 0x01d22264
.0xfe000100 <_start+192>: 0x1180c222 0xc821ffc8 0x13e620ff 0x41002010
.0xfe000110 <_reset+1>: 0x04d0ffc7 0xffc64100 0x00fffd86 0x1049c500
.0xfe000120: 0xe52049d5 0x49f53049 0x00003400 0x00000000
.0xfe000130: 0x00000000 0x00000000 0x00000000 0x00000000
.(gdb)

Further details on U-Boot in general are in the generic <tt>README</tt> at the top of the U-Boot tree. Details specific to the Xtensa architecture are in <tt>doc/README.xtensa</tt>. Details specific to a board are in <tt>board[/<family>]/<board>/README</tt> (for example <tt>board/avnet/xtav60/README</tt>).

Setting up U-Boot

2010-11-16T09:18:46Z

Piet: /* LX60 and LX200 U-Boot Installation (LX110 in Progress) */

== LX60 and LX200 U-Boot Installation (LX110 in Progress) ==

''('''News:''' The New DC233, with the V3 MMU, is now working. Work is in progress with the Linux 2.6.29-smp kernel to boot from this updated U-Boot.

'''Summary:'''

[http://www.denx.de/wiki/UBoot U-Boot] is a very popular boot loader; especially within the [http://elinux.org/Bootloader Embedded Linux community].
The U-Boot loader runs on the FPGA boards which are equipped with a dip switch, number 8, which can select where the memory location for the reset
vector (0XFE00,0000) comes from. With switch number 8 off the board will map the memory at the reset vector to a small block of SRAM located in the
I/O block with the UART and Ethernet buffer memory. When switch number 8 is on the Avnet boards map the beginning of the Flash Memory at 0XF800,000
to the reset vector at 0xFE00,000.

What we are going to do here is build a version of U-Boot for your Avnet board and Variant, install that ELF file into memory
with xt-gdb and run U-Boot. Then we are going to download a another copy of this identical program with '''tftp'''. The version we
are going to download is just the ELF file with the headers and debug information removed. It's just the actual bits that get
loaded into memory. For the new V3 MMU the default '''loadaddr''' is typically 0x20,0000 and for the older V2 MMU this is in the
Linux mapping equivalent, 0xD0200,0000. The default location can be change by setting the U-Boot 'loadaddr' environment variable
or by changing the variable '''CONFIG_SYS_LOAD_ADDR''' in the boards U-Boot config file.

Once the virgin copy of the U-Boot program has been loaded into memory, the Flash memory is un-protected and errasd, then the
memory with the U-Boot program in it is copied to the flash memory and protected. Next you will set dip switch 8 on, recycle
power on the board, and U-Boot will be accessible via the serial UART at 38400 baud. U-Boot works without any MMU mapping,
and should be fine on configurations without an MMU. Only an ethernet and serial interface are required.

'''Proceedure:'''

A local port to the Xtensa architecture is now available at linux-xtensa.org. See [http://git.linux-xtensa.org/cgi-bin/git.cgi?p=u-boot/u-boot-xtensa.git;a=summary U-Boot Sources (GIT Summary)]. Or, to access this tree using <tt>git</tt> directly, use something like:

$ '''git clone git://git.linux-xtensa.org/git/u-boot/u-boot-xtensa.git u-boot'''
$ '''cd u-boot'''

''('''Note:''' This path is subject to change.)''

The U-Boot git repository has a branch with a HiFi 2 snapshot made for
the LX200 [[SMP HiFi 2 Development Board]]. With this branch you can simply check
out the snapshot_2+SMP branch which includes the binaries which are discussed below:

$ '''git clone git://git.linux-xtensa.org/git/u-boot/u-boot-xtensa.git u-boot'''
$ '''cd u-boot'''
$ '''git branch --track snapshot_2+SMP origin/snapshot_2+SMP'''
$ '''git checkout snapshot_2+SMP'''

$ '''ls -l u-boot u-boot.bin tools/mkimage'''
-rwxr-xr-x 1 piet tensilica 45016 2009-12-07 19:40 tools/mkimage [This is a small program you need to put in your search path to build kernel U-Boot images]
-rwxr-xr-x 1 piet tensilica 635339 2009-12-07 19:40 u-boot [Started with xt-gdb to bring up the 1st instance of a HiFi 2 U-Boot]
-rwxr-xr-x 1 piet tensilica 144944 2009-12-07 19:40 u-boot.bin [Loaded by the 1st instance of U-Boot, it's a HiFi2 version of u-boot that will be put in flash]
$

Unless you are using a U-Boot snapshot you need to build U-Boot for which you must have built the Buildroot toolchain for XTensa core.
Set your PATH to point to the toolchain built using buildroot. For example:

$ '''export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"'''

where '''<cname>''' is the name of the Xtensa core variant you wish to build for (e.g., <tt>dc232b</tt> <tt>dc233c</tt>).

To build U-Boot, use the cloned git tree pulled above, you should be at the top level of the tree in the '''u-boot''' directory , then configure it for your board and Xtensa core variant as follows:

make distclean
make <cname>'''_<board>_'''config
'dc232b'dc
This should only take a few seconds. For example, to build U-boot for the 'xtav60' board and the older 'dc232b' core with the V2 MMU type:

$ '''cd u-boot'''
$ '''make dc232b_xtav60_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

or for the new 'dc233c' core with the new V3 MMU type:

$ '''make dc233c_xtav60_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

or for a 'xtav200' board type with the new 'dc233c' core type:

$ '''make dc233c_xtav200_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

or for the snapshot_2+SMP branch you can also build U-Boot for the HiFi 2 core:

$ '''make test_mmuhifi_c3_xtav200_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

Only boards and core variants currently supported in the tree can be built out of the box. Headers for supported cores can be found in the tree under <tt>include/asm-xtensa/variant-<cname></tt>. The core specific headers are described in the <tt>doc/README.xtensa</tt> file. To support a new core, these headers must be copied from the overlay in the same way as for the linux kernel.

After the configuration step, to actually build U-Boot, simply:

$ '''make all''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

This will take a quite a few minutes.

Next, start xt-gdb and load u-boot from the top of the git repository:

$ '''xt-gdb -n''' [NOTE: Even with the HiFi 2 snapshot_2+SMP branch you still may have to put U-Boot on the board]
(xt-gdb) '''file u-boot'''
(xt-gdb) '''target remote localhost:20000 0'''
(xt-gdb) '''reset'''
(xt-gdb) '''load'''
(xt-gdb) '''break panic'''
(xt-gdb) '''continue'''

Hopefully U-Boot will start, and display on the LCD in the case of a LX60.

U-Boot 50.00 Mhz

Often you will be starting with the boards flash in an unknown state and it's best to unprotect and erase the entire flash. Just type '''protect off all''' followed by '''erase all''':

U-Boot> '''protect off all'''
Un-Protect Flash Bank # 1
................................................................................................................................... done
U-Boot> '''erase all'''
Erase Flash Bank # 1
..........................................................................................................
Flash erase timeout at address f8d40000 da0
Flash erase error at address f8d40000
........................ done
U-Boot>

The timeout and error messages are likley just warning messages and you board has been errased. You can see that with the flash info command '''flinfo'''. Below is an example with a LX200 board, which has a much larger flash than the smaller LX60:

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
F8000000 E F8020000 E F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E F8FE0000 E F8FE8000 E F8FF0000 E
F8FF8000 E
U-Boot>

The new LX110 looks very similar to the LX200, also with with 16Mb of Flash:

U-Boot> flinfo

Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 32 bytes

Sector Start Addresses:
F8000000 E F8020000 E F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E F8FE0000 E

Now set your preliminary U-Boot environment variables to point to your TFTP server so we can download yet another copy of U-Boot. At Tensilica we use a machine in the RTOS group called rtos-lab2. Folks using the [[SMP HiFi 2 Development Board]] likely have set up their workstation with a TFTP server.

U-Boot> '''setenv serverip 192.168.11.78''' rtos-lab2
or
U-Boot> '''setenv serverip 192.168.11.55''' pdelaney_fc9

U-Boot> '''setenv ipaddr 192.168.11.95''' I/P address of RTOS5, Piet's LX60; MAC: 00:05:C2:13:6f:0a

U-Boot> '''setenv bootfile u-boot.bin'''
U-Boot> '''saveenv'''
Saving Environment to Flash...
.... done
Un-Protected 4 sectors
Erasing Flash...
.... done
Erased 4 sectors
Writing to Flash... done
.... done
Protected 4 sectors
U-Boot>

Next, download '''u-boot.bin''' from the tftp server using the info we just entered into U-Boot's enviroment variables.
Here for example is the case for a LX60 running the HiFi-2 Bitstream with the older V2 MMU. Note that it starts up
in the D-gazillion (0XD0000000) region:

U-Boot> '''tftpboot'''
TFTP from server 192.168.11.78; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0xd2000000
Loading: T ########
done
Bytes transferred = 107592 (1a448 hex)

For the V3 MMU U-Boot is loaded from host pdelaney_fc9 into memory with virtual == physical. Here is a DC233L, with V3 MMU, example:

U-Boot> '''tftpboot'''
Using open_ethernet device
TFTP from server 192.168.11.55; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: T ########
done
Bytes transferred = 109964 (1ad8c hex)
U-Boot>

Now things get a bit tricky here for the LX60. The FLASH has '''Two sizes of Flash Sectors'''.
The first 8 sectors are small 0x2000 (8KB) and apparently intended for parameters. The rest
of the 4MB flash is composed of larger 0x10000 (64KB) sectors. Our code doesn't differentiate
between the sectors and the LX60 hardware is going to map 0XF800,0000 to 0XFE00,0000 so this
makes us use of all 8 of the 8KB sectors and the 1st 64KB sector at F8010000. So we are going
to flash up to F801FFFF below.

On a LX200 we have much more space and can easily fit a version of U-boot that has been compiled without optimization, make debugging much easier.
So in this case the image is a bit larger, but relatively similar to the LX60 (2 sectors):

U-Boot> '''tftpboot'''
Using open_ethernet device
TFTP from server 192.168.11.78; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0xd2000000
Loading: ###############
done
Bytes transferred = 205852 (3241c hex)
U-Boot>

On a LX110 we have less memory than an LX60, but FLASH sectors like the LX200. It turns out that the u-boot image
compiled with optimization is just a bit larger than 1 sector, so like the LX200 we will need to write u-boot
into two sectors. Here's and example tftpboot of U-Bot for the LX110:

U-Boot> tftpboot
Using open_ethernet device
TFTP from server 192.168.11.55; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: ##########
done
Bytes transferred = 144956 (2363c hex)
U-Boot>

Note that for both the LX200 and the LX60 that the image size, '''(3241c hex)''' in this case, is a bit less than 0x40000 or 10 sectors,
so turn off protection on the 1st 11 sectors and
erase the current contents.

For the '''LX60''' you do this:

U-Boot> '''protect off F8000000 F801FFFF'''
... done
Un-Protected 2 sectors
U-Boot> '''erase F8000000 F801FFFF'''
erase F8000000 F801FFFF
... done

For the '''LX200''' and the '''LX110''' the starting address '''(F8000000)''' is the same as with the LX60 but the last address '''(F803FFFF)''' is 'twice' as high:

U-Boot> '''protect off F8000000 F803FFFF'''
... done
Un-Protected 2 sectors
U-Boot> '''erase F8000000 F803FFFF'''
Erased 2 sectors
U-Boot>

Now copy the the image of u-boot.bin in memory to the flash. For the XL60 with the '''OLD''' V2 MMU you copy 0x20000
bytes from 0xd2000000 to 0XF8000000:

U-Boot> '''cp.b d2000000 F8000000 20000'''
Copy to Flash... done

For the LX60 with the '''NEW''' V3 MMU you copy 0x24000 bytes from 0x2000000 to F8000000:

U-Boot> '''cp.b 2000000 F8000000 20000'''
Copy to Flash... done

For the LX200 you copy 0x40000 bytes from 0xd2000000 to 0XF8000000...0XF803FFFF:

U-Boot> '''cp.b d2000000 F8000000 40000'''
Copy to Flash... done

For the LX110 with a V3-MMU you copy 0x40000 bytes from 0x2000000 to F8000000:
U-Boot> cp.b 2000000 F8000000 40000
Copy to Flash... done

Finally we protect these sectors so that U-Boot isn't easily erased by accident.
Below is what it looks like on a LX60 with the New V3 MMU with a subsequent display of the flash info:

U-Boot> '''cp.b 2000000 F8000000 2000'''
Copy to Flash... done
U-Boot> flinfo

Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x2257
Erase timeout: 8192 ms, write timeout: 1 ms

Sector Start Addresses:
'''F8000000 F8002000 F8004000 F8006000 F8008000'''
'''F800A000 F800C000 F800E000 F8010000 '''F8020000 E
F8030000 E F8040000 E F8050000 E F8060000 E F8070000 E
F8080000 E F8090000 E F80A0000 E F80B0000 E F80C0000 E
F80D0000 E F80E0000 E F80F0000 E F8100000 E F8110000 E
F8120000 E F8130000 E F8140000 E F8150000 E F8160000 E
F8170000 E F8180000 E F8190000 E F81A0000 E F81B0000 E
F81C0000 E F81D0000 E F81E0000 E F81F0000 E F8200000 E
F8210000 E F8220000 E F8230000 E F8240000 E F8250000 E
F8260000 E F8270000 E F8280000 E F8290000 E F82A0000 E
F82B0000 E F82C0000 E F82D0000 E F82E0000 E F82F0000 E
F8300000 E F8310000 E F8320000 E F8330000 E F8340000 E
F8350000 E F8360000 E F8370000 E F8380000 E F8390000 E
F83A0000 E F83B0000 E F83C0000 E F83D0000 E F83E0000
'''F83F0000 RO'''
U-Boot> '''protect on F8000000 F802FFFF'''
.......... done
Protected 10 sectors
U-Boot>

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x2257
Erase timeout: 8192 ms, write timeout: 1 ms

Sector Start Addresses:
'''F8000000 RO F8002000 RO F8004000 RO F8006000 RO F8008000 RO
F800A000 RO F800C000 RO F800E000 RO F8010000 RO''' F8020000 E
F8030000 E F8040000 E F8050000 E F8060000 E F8070000 E
F8080000 E F8090000 E F80A0000 E F80B0000 E F80C0000 E
F80D0000 E F80E0000 E F80F0000 E F8100000 E F8110000 E
F8120000 E F8130000 E F8140000 E F8150000 E F8160000 E
F8170000 E F8180000 E F8190000 E F81A0000 E F81B0000 E
F81C0000 E F81D0000 E F81E0000 E F81F0000 E F8200000 E
F8210000 E F8220000 E F8230000 E F8240000 E F8250000 E
F8260000 E F8270000 E F8280000 E F8290000 E F82A0000 E
F82B0000 E F82C0000 E F82D0000 E F82E0000 E F82F0000 E
F8300000 E F8310000 E F8320000 E F8330000 E F8340000 E
F8350000 E F8360000 E F8370000 E F8380000 E F8390000 E
F83A0000 E F83B0000 E F83C0000 E F83D0000 E F83E0000
'''F83F0000 RO'''
U-Boot>

For the LX110 with the V3-MMU here's what the flash info looks like after we
protect the first two sectors with U-Boot copied to it:

U-Boot> '''protect on F8000000 F803FFFF'''
Protected 2 sectors
U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 32 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E '''F8FE0000 RO'''
U-Boot> help

Below is what it looks like on a LX200 with the V2 MMU with a subsequent display of the flash info.
Notice that the Flash Sectors are 10X as large on the LX200:

U-Boot> '''protect on F8000000 F802FFFF'''
.. done
Protected 2 sectors
U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E '''F8FE0000 RO F8FE8000 RO F8FF0000 RO'''
'''F8FF8000 RO'''
U-Boot>

Note that the U-Boot '''saveenv''' command Erased and protected the last four sectors
of this LX200.

On both the LX60 and the LX200 now move DIP switch 8 to the ON position, power cycle the board. On the LX60 you should see U-boot in the LCD display.

The '''LX60''' with the new V3 MMU the serial console should print something like the following:

U-Boot 2009.08-dirty (Sep 10 2010 - 18:23:26)

CPU: Xtensa dc233c at 50.00 MHz
Board: XT-AV60: Avnet board + Xilinx LX60 FPGA + Tensilica bitstream
SysRAM: 64 MB
Flash: 4 MB
In: serial
Out: serial
Err: serial
MAC: 00:50:C2:13:6f:0a
IP: 192.168.11.95
open_ethernet
U-Boot>

On the '''LX200''', shown below with the old V2 MMU, you should see something like the following. In this case we also show the flash info command, '''flinfo''', being invoked just after booting U-Boot:

CPU: Xtensa test_mmuhifi_c3 at 41.6777 MHz
Board: XT-AV200: Avnet board + Xilinx LX200 FPGA + Tensilica bitstream
SysRAM: 96 MB
Flash: 16 MB
In: serial
Out: serial
Err: serial
MAC:
IP: 192.168.11.95
U-Boot>

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E RO F8060000 E RO F8080000 E RO
F80A0000 E RO F80C0000 E RO F80E0000 E RO F8100000 E RO F8120000 E RO
F8140000 E RO F8160000 E RO F8180000 E RO F81A0000 E RO F81C0000 E RO
F81E0000 E RO F8200000 E RO F8220000 E RO F8240000 E RO F8260000 E RO
F8280000 E RO F82A0000 E RO F82C0000 E RO F82E0000 E RO F8300000 E RO
F8320000 E RO F8340000 E RO F8360000 E RO F8380000 E RO F83A0000 E RO
F83C0000 E RO F83E0000 E RO F8400000 E RO F8420000 E RO F8440000 E RO
F8460000 E RO F8480000 E RO F84A0000 E RO F84C0000 E RO F84E0000 E RO
F8500000 E RO F8520000 E RO F8540000 E RO F8560000 E RO F8580000 E RO
F85A0000 E RO F85C0000 E RO F85E0000 E RO F8600000 E RO F8620000 E RO
F8640000 E RO F8660000 E RO F8680000 E RO F86A0000 E RO F86C0000 E RO
F86E0000 E RO F8700000 E RO F8720000 E RO F8740000 E RO F8760000 E RO
F8780000 E RO F87A0000 E RO F87C0000 E RO F87E0000 E RO F8800000 E RO
F8820000 E RO F8840000 E RO F8860000 E RO F8880000 E RO F88A0000 E RO
F88C0000 E RO F88E0000 E RO F8900000 E RO F8920000 E RO F8940000 E RO
F8960000 E RO F8980000 E RO F89A0000 E RO F89C0000 E RO F89E0000 E RO
F8A00000 E RO F8A20000 E RO F8A40000 E RO F8A60000 E RO F8A80000 E RO
F8AA0000 E RO F8AC0000 E RO F8AE0000 E RO F8B00000 E RO F8B20000 E RO
F8B40000 E RO F8B60000 E RO F8B80000 E RO F8BA0000 E RO F8BC0000 E RO
F8BE0000 E RO F8C00000 E RO F8C20000 E RO F8C40000 E RO F8C60000 E RO
F8C80000 E RO F8CA0000 E RO F8CC0000 E RO F8CE0000 E RO F8D00000 E RO
F8D20000 E RO F8D40000 E RO F8D60000 E RO F8D80000 E RO F8DA0000 E RO
F8DC0000 E RO F8DE0000 E RO F8E00000 E RO F8E20000 E RO F8E40000 E RO
F8E60000 E RO F8E80000 E RO F8EA0000 E RO F8EC0000 E RO F8EE0000 E RO
F8F00000 E RO F8F20000 E RO F8F40000 E RO F8F60000 E RO F8F80000 E RO
F8FA0000 E RO F8FC0000 E RO '''F8FE0000 RO F8FE8000 RO F8FF0000 RO'''
'''F8FF8000 RO'''
U-Boot>

Note that the 1st two sectors with U-Boot saved in them came up as not being erased ('''E''') but that all sectors came up Read Only ('''RO''').
Same with the last four sectors that the U-Boot '''saveenv''' command Erased. This is likely a '''bug''' on the LX200 boards with some preliminary investigation.
We will be discussing this with the U-Boot developers sometime in the future prior to pushing our U-boot changes upstream.

If U-Boot fails to boot ya might try making sure your U-Boot '''serverip''' environment variable matches the address of the tftp server where
you have copied your '''u-boot.bin''' file to and comparing the bits in the flash that got mapped to 0xfe00,0000 to what in the file:

u-boot]$ '''od -t x4 u-boot.bin | more'''
.0000000 00000206 fe000040 ffffffff a0fffe21
.0000020 00000002 fe01ad14 fe01ad8c 03f95030
.0000040 03f9aa78 04000000 00040003 03f8147c
.0000060 03f81418 00000000 00000000 00000000
.0000100 5300000c 13a00013 4800130c 13493013
.0000120 0c130200 13e62032 22002010 a03200a0
.0000140 1d837680 82037282 72822372 63728243
.0000160 72007272 72720872 18727210 2201d222
.0000200 020c80c2 3d80a032 1d8376f0 d20372d2
.0000220 72d22372 6372d243 f20072f2 72f20872
.0000240 1872f210 2201d222 200080c2 ffd92100
.0000260 37ffda31 02481d12 22681258 145722cb
.0000300 ee1467f1 664b0678 444b0479 06f43457
.0000320 0000fff8 31ffd221 4320ffd2 40443bc0
.0000340 84764142 4b020903 32020c22 837680a0
.0000360 04728211 82247282 72824472 01d22264
.0000400 1180c222 c821ffc8 13e620ff 41002010
.0000420 04d0ffc7 ffc64100 fffffd86 1049c500
.0000440 e52049d5 49f53049 00003400 00000000
.0000460 00000000 00000000 00000000 00000000
.
.(gdb) '''x/100x 0xfe000000'''
.0xfe000000 <_ResetVector>: 0x00000206 0xfe000040 0xffffffff 0xa0fffe21
.0xfe000010 <_ResetVector+16>: 0x00000002 0xfe01ad14 0xfe01ad8c 0x03f95030
.0xfe000020 <_ResetVector+32>: 0x03f9aa78 0x04000000 0x00040003 0x03f8147c
.0xfe000030 <_ResetVector+48>: 0x03f81418 0x00000000 0x00000000 0x00000000
.0xfe000040 <_start>: 0x5300000c 0x13a00013 0x4800130c 0x13493013
.0xfe000050 <_start+16>: 0x0c130200 0x13e62032 0x22002010 0xa03200a0
.0xfe000060 <_start+32>: 0x1d837680 0x82037282 0x72822372 0x63728243
.0xfe000070 <_start+48>: 0x72007272 0x72720872 0x18727210 0x2201d222
.0xfe000080 <_start+64>: 0x020c80c2 0x3d80a032 0x1d8376f0 0xd20372d2
.0xfe000090 <_start+80>: 0x72d22372 0x6372d243 0xf20072f2 0x72f20872
.0xfe0000a0 <_start+96>: 0x1872f210 0x2201d222 0x200080c2 0xffd92100
.0xfe0000b0 <_start+112>: 0x37ffda31 0x02481d12 0x22681258 0x145722cb
.0xfe0000c0 <_start+128>: 0xee1467f1 0x664b0678 0x444b0479 0x06f43457
.0xfe0000d0 <_start+144>: 0x0000fff8 0x31ffd221 0x4320ffd2 0x40443bc0
.0xfe0000e0 <_start+160>: 0x84764142 0x4b020903 0x32020c22 0x837680a0
.0xfe0000f0 <_start+176>: 0x04728211 0x82247282 0x72824472 0x01d22264
.0xfe000100 <_start+192>: 0x1180c222 0xc821ffc8 0x13e620ff 0x41002010
.0xfe000110 <_reset+1>: 0x04d0ffc7 0xffc64100 0x00fffd86 0x1049c500
.0xfe000120: 0xe52049d5 0x49f53049 0x00003400 0x00000000
.0xfe000130: 0x00000000 0x00000000 0x00000000 0x00000000
.(gdb)

Further details on U-Boot in general are in the generic <tt>README</tt> at the top of the U-Boot tree. Details specific to the Xtensa architecture are in <tt>doc/README.xtensa</tt>. Details specific to a board are in <tt>board[/<family>]/<board>/README</tt> (for example <tt>board/avnet/xtav60/README</tt>).

Setting up U-Boot

2010-11-16T09:15:19Z

Piet: /* LX60 and LX200 U-Boot Installation (LX110 in Progress) */

== LX60 and LX200 U-Boot Installation (LX110 in Progress) ==

''('''News:''' The New DC233, with the V3 MMU, is now working. Work is in progress with the Linux 2.6.29-smp kernel to boot from this updated U-Boot.

'''Summary:'''

[http://www.denx.de/wiki/UBoot U-Boot] is a very popular boot loader; especially within the [http://elinux.org/Bootloader Embedded Linux community].
The U-Boot loader runs on the FPGA boards which are equipped with a dip switch, number 8, which can select where the memory location for the reset
vector (0XFE00,0000) comes from. With switch number 8 off the board will map the memory at the reset vector to a small block of SRAM located in the
I/O block with the UART and Ethernet buffer memory. When switch number 8 is on the Avnet boards map the beginning of the Flash Memory at 0XF800,000
to the reset vector at 0xFE00,000.

What we are going to do here is build a version of U-Boot for your Avnet board and Variant, install that ELF file into memory
with xt-gdb and run U-Boot. Then we are going to download a another copy of this identical program with '''tftp'''. The version we
are going to download is just the ELF file with the headers and debug information removed. It's just the actual bits that get
loaded into memory. For the new V3 MMU the default '''loadaddr''' is typically 0x20,0000 and for the older V2 MMU this is in the
Linux mapping equivalent, 0xD0200,0000. The default location can be change by setting the U-Boot 'loadaddr' environment variable
or by changing the variable '''CONFIG_SYS_LOAD_ADDR''' in the boards U-Boot config file.

Once the virgin copy of the U-Boot program has been loaded into memory, the Flash memory is un-protected and errasd, then the
memory with the U-Boot program in it is copied to the flash memory and protected. Next you will set dip switch 8 on, recycle
power on the board, and U-Boot will be accessible via the serial UART at 38400 baud. U-Boot works without any MMU mapping,
and should be fine on configurations without an MMU. Only an ethernet and serial interface are required.

'''Proceedure:'''

A local port to the Xtensa architecture is now available at linux-xtensa.org. See [http://git.linux-xtensa.org/cgi-bin/git.cgi?p=u-boot/u-boot-xtensa.git;a=summary U-Boot Sources (GIT Summary)]. Or, to access this tree using <tt>git</tt> directly, use something like:

$ '''git clone git://git.linux-xtensa.org/git/u-boot/u-boot-xtensa.git u-boot'''
$ '''cd u-boot'''

''('''Note:''' This path is subject to change.)''

The U-Boot git repository has a branch with a HiFi 2 snapshot made for
the LX200 [[SMP HiFi 2 Development Board]]. With this branch you can simply check
out the snapshot_2+SMP branch which includes the binaries which are discussed below:

$ '''git clone git://git.linux-xtensa.org/git/u-boot/u-boot-xtensa.git u-boot'''
$ '''cd u-boot'''
$ '''git branch --track snapshot_2+SMP origin/snapshot_2+SMP'''
$ '''git checkout snapshot_2+SMP'''

$ '''ls -l u-boot u-boot.bin tools/mkimage'''
-rwxr-xr-x 1 piet tensilica 45016 2009-12-07 19:40 tools/mkimage [This is a small program you need to put in your search path to build kernel U-Boot images]
-rwxr-xr-x 1 piet tensilica 635339 2009-12-07 19:40 u-boot [Started with xt-gdb to bring up the 1st instance of a HiFi 2 U-Boot]
-rwxr-xr-x 1 piet tensilica 144944 2009-12-07 19:40 u-boot.bin [Loaded by the 1st instance of U-Boot, it's a HiFi2 version of u-boot that will be put in flash]
$

Unless you are using a U-Boot snapshot you need to build U-Boot for which you must have built the Buildroot toolchain for XTensa core.
Set your PATH to point to the toolchain built using buildroot. For example:

$ '''export PATH="''<workdir>''/buildroot/build_xtensa_''<cname>''/staging_dir/usr/bin:$PATH"'''

where '''<cname>''' is the name of the Xtensa core variant you wish to build for (e.g., <tt>dc232b</tt> <tt>dc233c</tt>).

To build U-Boot, use the cloned git tree pulled above, you should be at the top level of the tree in the '''u-boot''' directory , then configure it for your board and Xtensa core variant as follows:

make distclean
make <cname>'''_<board>_'''config
'dc232b'dc
This should only take a few seconds. For example, to build U-boot for the 'xtav60' board and the older 'dc232b' core with the V2 MMU type:

$ '''cd u-boot'''
$ '''make dc232b_xtav60_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

or for the new 'dc233c' core with the new V3 MMU type:

$ '''make dc233c_xtav60_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

or for a 'xtav200' board type with the new 'dc233c' core type:

$ '''make dc233c_xtav200_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

or for the snapshot_2+SMP branch you can also build U-Boot for the HiFi 2 core:

$ '''make test_mmuhifi_c3_xtav200_config''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

Only boards and core variants currently supported in the tree can be built out of the box. Headers for supported cores can be found in the tree under <tt>include/asm-xtensa/variant-<cname></tt>. The core specific headers are described in the <tt>doc/README.xtensa</tt> file. To support a new core, these headers must be copied from the overlay in the same way as for the linux kernel.

After the configuration step, to actually build U-Boot, simply:

$ '''make all''' [NOTE: You can skip this step with the the HiFi-2 snapshot_2+SMP branch; binaries are pre-built]

This will take a quite a few minutes.

Next, start xt-gdb and load u-boot from the top of the git repository:

$ '''xt-gdb -n''' [NOTE: Even with the HiFi 2 snapshot_2+SMP branch you still may have to put U-Boot on the board]
(xt-gdb) '''file u-boot'''
(xt-gdb) '''target remote localhost:20000 0'''
(xt-gdb) '''reset'''
(xt-gdb) '''load'''
(xt-gdb) '''break panic'''
(xt-gdb) '''continue'''

Hopefully U-Boot will start, and display on the LCD in the case of a LX60.

U-Boot 50.00 Mhz

Often you will be starting with the boards flash in an unknown state and it's best to unprotect and erase the entire flash. Just type '''protect off all''' followed by '''erase all''':

U-Boot> '''protect off all'''
Un-Protect Flash Bank # 1
................................................................................................................................... done
U-Boot> '''erase all'''
Erase Flash Bank # 1
..........................................................................................................
Flash erase timeout at address f8d40000 da0
Flash erase error at address f8d40000
........................ done
U-Boot>

The timeout and error messages are likley just warning messages and you board has been errased. You can see that with the flash info command '''flinfo'''. Below is an example with a LX200 board, which has a much larger flash than the smaller LX60:

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
F8000000 E F8020000 E F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E F8FE0000 E F8FE8000 E F8FF0000 E
F8FF8000 E
U-Boot>

The new LX110 looks very similar to the LX200, also with with 16Mb of Flash:

U-Boot> flinfo

Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 32 bytes

Sector Start Addresses:
F8000000 E F8020000 E F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E F8FE0000 E

Now set your preliminary U-Boot environment variables to point to your TFTP server so we can download yet another copy of U-Boot. At Tensilica we use a machine in the RTOS group called rtos-lab2. Folks using the [[SMP HiFi 2 Development Board]] likely have set up their workstation with a TFTP server.

U-Boot> '''setenv serverip 192.168.11.78''' rtos-lab2
or
U-Boot> '''setenv serverip 192.168.11.55''' pdelaney_fc9

U-Boot> '''setenv ipaddr 192.168.11.95''' I/P address of RTOS5, Piet's LX60; MAC: 00:05:C2:13:6f:0a

U-Boot> '''setenv bootfile u-boot.bin'''
U-Boot> '''saveenv'''
Saving Environment to Flash...
.... done
Un-Protected 4 sectors
Erasing Flash...
.... done
Erased 4 sectors
Writing to Flash... done
.... done
Protected 4 sectors
U-Boot>

Next, download '''u-boot.bin''' from the tftp server using the info we just entered into U-Boot's enviroment variables.
Here for example is the case for a LX60 running the HiFi-2 Bitstream with the older V2 MMU. Note that it starts up
in the D-gazillion (0XD0000000) region:

U-Boot> '''tftpboot'''
TFTP from server 192.168.11.78; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0xd2000000
Loading: T ########
done
Bytes transferred = 107592 (1a448 hex)

For the V3 MMU U-Boot is loaded from host pdelaney_fc9 into memory with virtual == physical. Here is a DC233L, with V3 MMU, example:

U-Boot> '''tftpboot'''
Using open_ethernet device
TFTP from server 192.168.11.55; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: T ########
done
Bytes transferred = 109964 (1ad8c hex)
U-Boot>

Now things get a bit tricky here for the LX60. The FLASH has '''Two sizes of Flash Sectors'''.
The first 8 sectors are small 0x2000 (8KB) and apparently intended for parameters. The rest
of the 4MB flash is composed of larger 0x10000 (64KB) sectors. Our code doesn't differentiate
between the sectors and the LX60 hardware is going to map 0XF800,0000 to 0XFE00,0000 so this
makes us use of all 8 of the 8KB sectors and the 1st 64KB sector at F8010000. So we are going
to flash up to F801FFFF below.

On a LX200 we have much more space and can easily fit a version of U-boot that has been compiled without optimization, make debugging much easier.
So in this case the image is a bit larger, but relatively similar to the LX60 (2 sectors):

U-Boot> '''tftpboot'''
Using open_ethernet device
TFTP from server 192.168.11.78; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0xd2000000
Loading: ###############
done
Bytes transferred = 205852 (3241c hex)
U-Boot>

On a LX110 we have less memory than an LX60, but FLASH sectors like the LX200. It turns out that the u-boot image
compiled with optimization is just a bit larger than 1 sector, so like the LX200 we will need to write u-boot
into two sectors. Here's and example tftpboot of U-Bot for the LX110:

U-Boot> tftpboot
Using open_ethernet device
TFTP from server 192.168.11.55; our IP address is 192.168.11.95
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: ##########
done
Bytes transferred = 144956 (2363c hex)
U-Boot>

Note that for both the LX200 and the LX60 that the image size, '''(3241c hex)''' in this case, is a bit less than 0x40000 or 10 sectors,
so turn off protection on the 1st 11 sectors and
erase the current contents.

For the '''LX60''' you do this:

U-Boot> '''protect off F8000000 F801FFFF'''
... done
Un-Protected 2 sectors
U-Boot> '''erase F8000000 F801FFFF'''
erase F8000000 F801FFFF
... done

For the '''LX200''' and the '''LX110''' the starting address '''(F8000000)''' is the same as with the LX60 but the last address '''(F803FFFF)''' is 'twice' as high:

U-Boot> '''protect off F8000000 F803FFFF'''
... done
Un-Protected 2 sectors
U-Boot> '''erase F8000000 F803FFFF'''
Erased 2 sectors
U-Boot>

Now copy the the image of u-boot.bin in memory to the flash. For the XL60 with the '''OLD''' V2 MMU you copy 0x20000
bytes from 0xd2000000 to 0XF8000000:

U-Boot> '''cp.b d2000000 F8000000 20000'''
Copy to Flash... done

For the LX60 with the '''NEW''' V3 MMU you copy 0x24000 bytes from 0x2000000 to F8000000:

U-Boot> '''cp.b 2000000 F8000000 20000'''
Copy to Flash... done

For the LX200 you copy 0x40000 bytes from 0xd2000000 to 0XF8000000...0XF803FFFF:

U-Boot> '''cp.b d2000000 F8000000 40000'''
Copy to Flash... done

For the LX110 with a V3-MMU you copy 0x40000 bytes from 0x2000000 to F8000000:
U-Boot> cp.b 2000000 F8000000 40000
Copy to Flash... done

Finally we protect these sectors so that U-Boot isn't easily erased by accident.
Below is what it looks like on a LX60 with the New V3 MMU with a subsequent display of the flash info:

U-Boot> '''cp.b 2000000 F8000000 2000'''
Copy to Flash... done
U-Boot> flinfo

Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x2257
Erase timeout: 8192 ms, write timeout: 1 ms

Sector Start Addresses:
'''F8000000 F8002000 F8004000 F8006000 F8008000'''
'''F800A000 F800C000 F800E000 F8010000 '''F8020000 E
F8030000 E F8040000 E F8050000 E F8060000 E F8070000 E
F8080000 E F8090000 E F80A0000 E F80B0000 E F80C0000 E
F80D0000 E F80E0000 E F80F0000 E F8100000 E F8110000 E
F8120000 E F8130000 E F8140000 E F8150000 E F8160000 E
F8170000 E F8180000 E F8190000 E F81A0000 E F81B0000 E
F81C0000 E F81D0000 E F81E0000 E F81F0000 E F8200000 E
F8210000 E F8220000 E F8230000 E F8240000 E F8250000 E
F8260000 E F8270000 E F8280000 E F8290000 E F82A0000 E
F82B0000 E F82C0000 E F82D0000 E F82E0000 E F82F0000 E
F8300000 E F8310000 E F8320000 E F8330000 E F8340000 E
F8350000 E F8360000 E F8370000 E F8380000 E F8390000 E
F83A0000 E F83B0000 E F83C0000 E F83D0000 E F83E0000
'''F83F0000 RO'''
U-Boot> '''protect on F8000000 F802FFFF'''
.......... done
Protected 10 sectors
U-Boot>

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x2257
Erase timeout: 8192 ms, write timeout: 1 ms

Sector Start Addresses:
'''F8000000 RO F8002000 RO F8004000 RO F8006000 RO F8008000 RO
F800A000 RO F800C000 RO F800E000 RO F8010000 RO''' F8020000 E
F8030000 E F8040000 E F8050000 E F8060000 E F8070000 E
F8080000 E F8090000 E F80A0000 E F80B0000 E F80C0000 E
F80D0000 E F80E0000 E F80F0000 E F8100000 E F8110000 E
F8120000 E F8130000 E F8140000 E F8150000 E F8160000 E
F8170000 E F8180000 E F8190000 E F81A0000 E F81B0000 E
F81C0000 E F81D0000 E F81E0000 E F81F0000 E F8200000 E
F8210000 E F8220000 E F8230000 E F8240000 E F8250000 E
F8260000 E F8270000 E F8280000 E F8290000 E F82A0000 E
F82B0000 E F82C0000 E F82D0000 E F82E0000 E F82F0000 E
F8300000 E F8310000 E F8320000 E F8330000 E F8340000 E
F8350000 E F8360000 E F8370000 E F8380000 E F8390000 E
F83A0000 E F83B0000 E F83C0000 E F83D0000 E F83E0000
'''F83F0000 RO'''
U-Boot>

For the LX110 with the V3-MMU here's what the flash info looks like after we
protect the first two sectors with U-Boot copied to it:

Protected 2 sectors
U-Boot> flinfo

Bank # 1: CFI conformant FLASH (8 x 8) Size: 16 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 32 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E '''F8FE0000 RO'''
U-Boot> help

Below is what it looks like on a LX200 with the V2 MMU with a subsequent display of the flash info.
Notice that the Flash Sectors are 10X as large on the LX200:

U-Boot> '''protect on F8000000 F802FFFF'''
.. done
Protected 2 sectors
U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E F8060000 E F8080000 E
F80A0000 E F80C0000 E F80E0000 E F8100000 E F8120000 E
F8140000 E F8160000 E F8180000 E F81A0000 E F81C0000 E
F81E0000 E F8200000 E F8220000 E F8240000 E F8260000 E
F8280000 E F82A0000 E F82C0000 E F82E0000 E F8300000 E
F8320000 E F8340000 E F8360000 E F8380000 E F83A0000 E
F83C0000 E F83E0000 E F8400000 E F8420000 E F8440000 E
F8460000 E F8480000 E F84A0000 E F84C0000 E F84E0000 E
F8500000 E F8520000 E F8540000 E F8560000 E F8580000 E
F85A0000 E F85C0000 E F85E0000 E F8600000 E F8620000 E
F8640000 E F8660000 E F8680000 E F86A0000 E F86C0000 E
F86E0000 E F8700000 E F8720000 E F8740000 E F8760000 E
F8780000 E F87A0000 E F87C0000 E F87E0000 E F8800000 E
F8820000 E F8840000 E F8860000 E F8880000 E F88A0000 E
F88C0000 E F88E0000 E F8900000 E F8920000 E F8940000 E
F8960000 E F8980000 E F89A0000 E F89C0000 E F89E0000 E
F8A00000 E F8A20000 E F8A40000 E F8A60000 E F8A80000 E
F8AA0000 E F8AC0000 E F8AE0000 E F8B00000 E F8B20000 E
F8B40000 E F8B60000 E F8B80000 E F8BA0000 E F8BC0000 E
F8BE0000 E F8C00000 E F8C20000 E F8C40000 E F8C60000 E
F8C80000 E F8CA0000 E F8CC0000 E F8CE0000 E F8D00000 E
F8D20000 E F8D40000 E F8D60000 E F8D80000 E F8DA0000 E
F8DC0000 E F8DE0000 E F8E00000 E F8E20000 E F8E40000 E
F8E60000 E F8E80000 E F8EA0000 E F8EC0000 E F8EE0000 E
F8F00000 E F8F20000 E F8F40000 E F8F60000 E F8F80000 E
F8FA0000 E F8FC0000 E '''F8FE0000 RO F8FE8000 RO F8FF0000 RO'''
'''F8FF8000 RO'''
U-Boot>

Note that the U-Boot '''saveenv''' command Erased and protected the last four sectors
of this LX200.

On both the LX60 and the LX200 now move DIP switch 8 to the ON position, power cycle the board. On the LX60 you should see U-boot in the LCD display.

The '''LX60''' with the new V3 MMU the serial console should print something like the following:

U-Boot 2009.08-dirty (Sep 10 2010 - 18:23:26)

CPU: Xtensa dc233c at 50.00 MHz
Board: XT-AV60: Avnet board + Xilinx LX60 FPGA + Tensilica bitstream
SysRAM: 64 MB
Flash: 4 MB
In: serial
Out: serial
Err: serial
MAC: 00:50:C2:13:6f:0a
IP: 192.168.11.95
open_ethernet
U-Boot>

On the '''LX200''', shown below with the old V2 MMU, you should see something like the following. In this case we also show the flash info command, '''flinfo''', being invoked just after booting U-Boot:

CPU: Xtensa test_mmuhifi_c3 at 41.6777 MHz
Board: XT-AV200: Avnet board + Xilinx LX200 FPGA + Tensilica bitstream
SysRAM: 96 MB
Flash: 16 MB
In: serial
Out: serial
Err: serial
MAC:
IP: 192.168.11.95
U-Boot>

U-Boot> '''flinfo'''

Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 131 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes

Sector Start Addresses:
'''F8000000 RO F8020000 RO''' F8040000 E RO F8060000 E RO F8080000 E RO
F80A0000 E RO F80C0000 E RO F80E0000 E RO F8100000 E RO F8120000 E RO
F8140000 E RO F8160000 E RO F8180000 E RO F81A0000 E RO F81C0000 E RO
F81E0000 E RO F8200000 E RO F8220000 E RO F8240000 E RO F8260000 E RO
F8280000 E RO F82A0000 E RO F82C0000 E RO F82E0000 E RO F8300000 E RO
F8320000 E RO F8340000 E RO F8360000 E RO F8380000 E RO F83A0000 E RO
F83C0000 E RO F83E0000 E RO F8400000 E RO F8420000 E RO F8440000 E RO
F8460000 E RO F8480000 E RO F84A0000 E RO F84C0000 E RO F84E0000 E RO
F8500000 E RO F8520000 E RO F8540000 E RO F8560000 E RO F8580000 E RO
F85A0000 E RO F85C0000 E RO F85E0000 E RO F8600000 E RO F8620000 E RO
F8640000 E RO F8660000 E RO F8680000 E RO F86A0000 E RO F86C0000 E RO
F86E0000 E RO F8700000 E RO F8720000 E RO F8740000 E RO F8760000 E RO
F8780000 E RO F87A0000 E RO F87C0000 E RO F87E0000 E RO F8800000 E RO
F8820000 E RO F8840000 E RO F8860000 E RO F8880000 E RO F88A0000 E RO
F88C0000 E RO F88E0000 E RO F8900000 E RO F8920000 E RO F8940000 E RO
F8960000 E RO F8980000 E RO F89A0000 E RO F89C0000 E RO F89E0000 E RO
F8A00000 E RO F8A20000 E RO F8A40000 E RO F8A60000 E RO F8A80000 E RO
F8AA0000 E RO F8AC0000 E RO F8AE0000 E RO F8B00000 E RO F8B20000 E RO
F8B40000 E RO F8B60000 E RO F8B80000 E RO F8BA0000 E RO F8BC0000 E RO
F8BE0000 E RO F8C00000 E RO F8C20000 E RO F8C40000 E RO F8C60000 E RO
F8C80000 E RO F8CA0000 E RO F8CC0000 E RO F8CE0000 E RO F8D00000 E RO
F8D20000 E RO F8D40000 E RO F8D60000 E RO F8D80000 E RO F8DA0000 E RO
F8DC0000 E RO F8DE0000 E RO F8E00000 E RO F8E20000 E RO F8E40000 E RO
F8E60000 E RO F8E80000 E RO F8EA0000 E RO F8EC0000 E RO F8EE0000 E RO
F8F00000 E RO F8F20000 E RO F8F40000 E RO F8F60000 E RO F8F80000 E RO
F8FA0000 E RO F8FC0000 E RO '''F8FE0000 RO F8FE8000 RO F8FF0000 RO'''
'''F8FF8000 RO'''
U-Boot>

Note that the 1st two sectors with U-Boot saved in them came up as not being erased ('''E''') but that all sectors came up Read Only ('''RO''').
Same with the last four sectors that the U-Boot '''saveenv''' command Erased. This is likely a '''bug''' on the LX200 boards with some preliminary investigation.
We will be discussing this with the U-Boot developers sometime in the future prior to pushing our U-boot changes upstream.

If U-Boot fails to boot ya might try making sure your U-Boot '''serverip''' environment variable matches the address of the tftp server where
you have copied your '''u-boot.bin''' file to and comparing the bits in the flash that got mapped to 0xfe00,0000 to what in the file:

u-boot]$ '''od -t x4 u-boot.bin | more'''
.0000000 00000206 fe000040 ffffffff a0fffe21
.0000020 00000002 fe01ad14 fe01ad8c 03f95030
.0000040 03f9aa78 04000000 00040003 03f8147c
.0000060 03f81418 00000000 00000000 00000000
.0000100 5300000c 13a00013 4800130c 13493013
.0000120 0c130200 13e62032 22002010 a03200a0
.0000140 1d837680 82037282 72822372 63728243
.0000160 72007272 72720872 18727210 2201d222
.0000200 020c80c2 3d80a032 1d8376f0 d20372d2
.0000220 72d22372 6372d243 f20072f2 72f20872
.0000240 1872f210 2201d222 200080c2 ffd92100
.0000260 37ffda31 02481d12 22681258 145722cb
.0000300 ee1467f1 664b0678 444b0479 06f43457
.0000320 0000fff8 31ffd221 4320ffd2 40443bc0
.0000340 84764142 4b020903 32020c22 837680a0
.0000360 04728211 82247282 72824472 01d22264
.0000400 1180c222 c821ffc8 13e620ff 41002010
.0000420 04d0ffc7 ffc64100 fffffd86 1049c500
.0000440 e52049d5 49f53049 00003400 00000000
.0000460 00000000 00000000 00000000 00000000
.
.(gdb) '''x/100x 0xfe000000'''
.0xfe000000 <_ResetVector>: 0x00000206 0xfe000040 0xffffffff 0xa0fffe21
.0xfe000010 <_ResetVector+16>: 0x00000002 0xfe01ad14 0xfe01ad8c 0x03f95030
.0xfe000020 <_ResetVector+32>: 0x03f9aa78 0x04000000 0x00040003 0x03f8147c
.0xfe000030 <_ResetVector+48>: 0x03f81418 0x00000000 0x00000000 0x00000000
.0xfe000040 <_start>: 0x5300000c 0x13a00013 0x4800130c 0x13493013
.0xfe000050 <_start+16>: 0x0c130200 0x13e62032 0x22002010 0xa03200a0
.0xfe000060 <_start+32>: 0x1d837680 0x82037282 0x72822372 0x63728243
.0xfe000070 <_start+48>: 0x72007272 0x72720872 0x18727210 0x2201d222
.0xfe000080 <_start+64>: 0x020c80c2 0x3d80a032 0x1d8376f0 0xd20372d2
.0xfe000090 <_start+80>: 0x72d22372 0x6372d243 0xf20072f2 0x72f20872
.0xfe0000a0 <_start+96>: 0x1872f210 0x2201d222 0x200080c2 0xffd92100
.0xfe0000b0 <_start+112>: 0x37ffda31 0x02481d12 0x22681258 0x145722cb
.0xfe0000c0 <_start+128>: 0xee1467f1 0x664b0678 0x444b0479 0x06f43457
.0xfe0000d0 <_start+144>: 0x0000fff8 0x31ffd221 0x4320ffd2 0x40443bc0
.0xfe0000e0 <_start+160>: 0x84764142 0x4b020903 0x32020c22 0x837680a0
.0xfe0000f0 <_start+176>: 0x04728211 0x82247282 0x72824472 0x01d22264
.0xfe000100 <_start+192>: 0x1180c222 0xc821ffc8 0x13e620ff 0x41002010
.0xfe000110 <_reset+1>: 0x04d0ffc7 0xffc64100 0x00fffd86 0x1049c500
.0xfe000120: 0xe52049d5 0x49f53049 0x00003400 0x00000000
.0xfe000130: 0x00000000 0x00000000 0x00000000 0x00000000
.(gdb)

Further details on U-Boot in general are in the generic <tt>README</tt> at the top of the U-Boot tree. Details specific to the Xtensa architecture are in <tt>doc/README.xtensa</tt>. Details specific to a board are in <tt>board[/<family>]/<board>/README</tt> (for example <tt>board/avnet/xtav60/README</tt>).