Intel



Running Linux on the Altera Nios II Processor USER GUIDE

®

Version 1.0

Table of Contents

Table of Contents 2

1 Introduction 4

1.1 Purpose and Scope 4

2 Getting Started 5

2.1 Development Methodology 5

2.2 Understanding the Development Process 5

2.3 What you need before you can get started 6

2.4 Getting Started with Hardware Design Files and Tools 6

2.4.1 Downloading the Hardware Design Files from Altera 7

2.4.2 Installing Altera Quartus II Software and Nios II EDS 7

2.4.3 Installing Altera USB Blaster driver for Linux 8

2.5 Getting Started with the Cyclone III FPGA Development Board 9

2.5.1 Update the Max II Design 9

2.5.2 Configure the Development Board Switches and Jumpers 10

2.6 Getting Started with Linux and Software Tools 10

2.6.1 Before You Start 10

2.6.2 Installing a Linux Desktop on Your PC 11

2.6.3 Installing the Linux Development Package 11

2.6.4 Installing the nios2-linux Source and Toolchain 11

3 Nios II Hardware Reference Design 13

3.1 About your Development Platform 13

3.2 About the Nios II Hardware Reference Design 14

3.2.1 System Description 15

3.2.2 Memory Map and Linker Regions 16

4 Running Linux on the Nios II Processor 18

4.1 Check for Updates 18

4.2 Running a Pre-built Linux Image 18

4.3 Configure and Build Your First Linux Image 20

4.3.1 Configure your Kernel with xconfig 20

4.3.2 Compile Your Kernel and User Space Applications 22

4.3.3 Running Linux on the Nios II Target 22

4.4 Git Version Control System 22

4.4.1 Accessing the Git Server 23

4.4.2 Creating Your Git branch 24

4.4.3 Configure and Building a Customized Kernel and User Space Applications 24

4.4.4 Saving Your Configuration Settings 27

4.4.5 Building Your Custom Kernel with a JFFS2 Root File System 29

4.4.6 Commit Your Customization to Local Git Branch 29

4.4.7 Adding an Application to Your Build 31

4.4.8 Program Your Kernel Image and Root Filesystem Into Flash 32

5 Creating a Custom Design 33

5.1 Before You Start 33

5.2 Hardware Bring-up and Kernel Debugging 33

5.3 About the Board Support Package 33

5.4 Creating a Custom Design 34

5.4.1 Creating a Nios II processor system design 34

5.4.2 Compile the Hardware Design 35

5.4.3 Creating a Local Kernel Branch 35

5.4.4 Generate a system header file 35

5.4.5 Configure, Build and Run the Kernel and User Applications 35

5.4.6 Flash 36

6 Working with Flash 37

6.1 Reference Flash Layout Scheme 37

6.2 Reference Flash Image for Linux 38

6.3 Flash Programming Methods 39

6.4 Program Flash over Ethernet Using U-Boot 40

6.4.1 Download a Temporary Processor System 40

6.4.2 Program the Factory Flash Image over Ethernet with U-Boot 40

6.4.3 Updating the Flash with Your Own Kernel Image and Rootfs 41

7 U-Boot Boot Loader 43

7.1 Boot Loader 43

7.1.1 U-Boot 43

7.1.2 U-Boot Environment Variables and Scripts for Nios II 43

8 Kernel Debugging Using the Lauterbach Trace32-ICD Debugger 45

Introduction

1 Purpose and Scope

This document provides the information how to run the free, open source Linux distribution available from the Nios Community Wiki web site () on a Nios II processor system. In the remainder of this document, this particular distribution of Linux for the Nios II processor simply be referred to as Linux.

Highlights of what you will be acquainted with are as follows:

• The general development process

• How to use the Nios Community Wiki git server to get the Linux distribution

• Prepare the Cyclone III FPGA Development Board for running Linux

• The Nios II Hardware Reference Design for Linux, 3C120 Cyclone III Edition

• How to configure and build kernels images

• How to build user space applications

• How to download and run Linux and user space applications on the target

• How to manage custom configurations with the git server

The reader is assumed to be familiar with the Nios II processor, Linux and the Altera Cyclone III FPGA Development Board.

Getting Started

1 Development Methodology

FPGAs are flexible platforms for developing highly custom embedded systems. Using the Altera Quartus II FPGA Design Software, any combination of hardware designs that includes the Nios II processor and a set of standard as well as custom peripherals can be created. Running Linux on such a highly customizable hardware platform presents certain challenges, but these challenges can be overcome with a pre-built stable reference design as a solid starting point. It is therefore recommended that embedded developers always start with a standard hardware reference platform. For the remainder of this document, the standard reference hardware platform is referred to as the Nios II Hardware Reference Design for Linux, 3C120 Cyclone III Edition.

For software engineers, the Nios II Hardware Reference Design for Linux, 3C120 Cyclone III Edition is a fully functional processor system designed to get your application development started quickly. When the FPGA on the Cyclone III FPGA Development Board is configured with this processor system design, the resulting Nios II target is no different from any other microprocessor development board. Supported by a Linux BSP, this Nios II target boots Linux on power-up, and is ready to run Linux applications you create for it. It is strongly recommended that all software developers start here.

For FPGA hardware designers, the Nios II Hardware Reference Design for Linux, 3C120 Cyclone III Edition is also a good starting point. As a blue print from to illustrate the best practices on building a Nios-based processor system design, this design is fully timing-constrained, and optimized for Linux performance. It is recommended that you create your own system by modifying this design incrementally.

For BSP developers who are tasked to create new kernel builds to support custom hardware designs, the best place to start is the BSP that comes with the Nios II Hardware Reference Design for Linux, 3C120 Cyclone III Edition. As incremental changes are made to the hardware system, you can modify the factory BSP in lock-step, and upgrade your Linux kernel accordingly. It is recommended that all BSP development and enhancements begin with the factory BSP, and built upon incrementally.

2 Understanding the Development Process

Software developers should follow the steps below to get started:

1. Understand the Nios II Hardware Reference Design for Linux, 3C120 Cyclone III Edition

2. Work with your hardware team to provide you with a Nios II target that can boot Linux

3. Understand Linux for Nios II processor

4. Proceed to application development

Hardware or firmware developers should follow the steps below to get started:

1. Understand the Nios II Hardware Reference Design for Linux, 3C120 Cyclone III Edition

2. Prepare a Nios II target from the Cyclone III FPGA Development Board that boots Linux on power on to jump start your software team

3. Understand how to modify the processor system, rebuild the factory BSP and the Linux kernel and update the Nios II target

3 What you need before you can get started

[pic]

Figure 1: Development Setup

TO SET UP A TYPICAL DEVELOPMENT PLATFORM AS SHOWN IN FIGURE 1, YOU NEED TO FIND AND ASSEMBLE THE FOLLOWING ITEMS:

• An Altera Cyclone III FPGA Development Kit (P/N: DK-DEV-3C120N). Please connect the board to a 100/1000 Mbps Ethernet switch.

• One PC running a host Linux distribution that installed with:

o Linux for Nios II processor development software

o Altera Quartus II Software 9.0 sp1 or later version, and the corresponding Nios II EDS software.

o This PC should be connected to the aforementioned Nios II target through the Ethernet switch.

• One standard USB Cable. The USB cable should be connected between the Linux PC and the Altera Cyclone III FPGA Development Board.

4 Getting Started with Hardware Design Files and Tools

This section talks about all the necessary hardware design files and Nios II development tools that you will need.

Downloading the Hardware Design Files from Altera

The files required for hardware development and board update can be downloaded from:

wrlinux.

Download the following files and install them on your PC in a directory. Henceforth this location will be referred to as in this document.

|File Category |File Name |Description |Where to get it |

|Hardware Design |niosII_cycloneIII_3c120 |Contains Quartus II Project which |Download from |

|File | |represents the Nios II Hardware |wrlinux |

| | |Reference Design for Linux, 3C120 | |

| | |Cyclone III Edition. This is needed | |

| | |for hardware and firmware development| |

| | |only. | |

|Board Specific |Option_bits.flash |This is the file required to update |Download from |

|Files | |the Flash section that contains board|wrlinux |

| | |specific configuration settings. | |

| |m2_prod_1338.pof |This file is required to update the |Download from |

| | |Max II design on older versions of |wrlinux |

| | |the Cyclone III FGPA Development Kit.| |

| |nios2_linux_3c120_125mhz_top.sof |This is the FPGA Image file that can |Download from |

| | |be used to configure the FPGA |wrlinux |

| |restore_flash |These are scripts for programming |Download from |

| | |Flash with pre-built kernel images. |wrlinux |

| |u-boot-files |Altera provided U-Boot sources with |Download from |

| | |useful utilities and U-Boot friendly |wrlinux |

| | |images (.img) for flash programming | |

| | |via Ethernet. | |

Please remember to check back frequently for updates to these files.

Installing Altera Quartus II Software and Nios II EDS

You can download the Web Edition of this software from the Altera Download Centre. The software provides the tools for building the hardware design and communicating with the Nios II Processor System.

1. Install Quartus II FPGA Design software and Nios II EDS (version 9.0 or later) on a Linux PC by downloading it from the Altera Download Centre at location below:



2. Once the tools are installed, navigate to the location of the Nios II EDS and run a script to set up the environment paths for the Altera development tools

% cd /build/opt/altera/nios2eds

% ./sdk_shell

3. By running the script above the paths for the home directories for the Altera Quartus II Software ($QUARTUS_ROOTDIR) and Altera Nios II EDS ($SOPC_KIT_NIOS2) are set up by a shell script called env.sh (located in the current directory). To verify this run a printenv and view the environment variable path settings.

4. It is recommended that you save the environment settings for the Altera and Linux tools in a single source shell (.e.g. a local copy of env.sh) and run that shell.

Make sure to check the Nios Community Wiki Web site for additional useful information on how to run Quartus on a Linux PC. The Nios Community Wiki Web site is located at:



Installing Altera USB Blaster driver for Linux

For FPGA configuration flash programming and host-target communication using the Altera USB Blaster you need to install the driver for the Altera USB Blaster. To install the USB-Blaster driver on Red Hat 4.0 Linux you need to do the following. Exact syntax may vary for different Linux distributions,

1. Set up, as root user, the file system record for the USB Blaster in /etc/fstab (static information about the file systems). Add the following line to /etc/fstab (as root):

% usbfs /proc/bus/usb usbfs devmode=0666.0.0

2. Unmount usbfs, in case it is already running, as root, and mount it with the new settings:

% umount usbfs

% mount -a

3. Communication over USB is performed via J-TAG. Create a file using touch called .jtag.conf in your home directory by typing

% touch ~/.jtag.conf

4. Verify that the on-board USB-Blaster can now be accessed by plugging one end of a USB cable to the USB port on the Altera Cyclone III FPGA Development board and the other end into a USB port on the Linux host. Check to see if the USB-Blaster is working by executing the following command:

% jtagconfig -n

The jtagconfig command finds devices connect to the port, so you should see the following response:

USB_Blaster [USB 3-1.2]

020F70DD EP3C120

Node 0C006E00

Node 19104600

5 Getting Started with the Cyclone III FPGA Development Board

Update the Max II Design

Before you use the Cyclone III FPGA Development Board for the first time, you need to make sure that it is updated with version 1338 or higher of the Max II Design. To tell which version of Max II design is on your board, power up the board and hold down the CPU Reset button. The left voltmeter display will change to display the build number of Max II design.

If the build number displayed in 1338 or higher, you have the right version of the Max II Design, then you can skip the remainder of this section.

If the display does not change or is not 1338 or higher, it means that you have an older version of the Max II design. You must update it before proceeding further.

To update the Max II Design you will need:

• The POF file which represents the new Max II design called m2_prod_1338.pof. This file is provided to you as part of the Board Design Files downloaded from wrlinux.

• A Stand-Alone USB Blaster. Because the Max II CPLD is a part of the embedded USB Blaster circuitry, to update it you will need a stand-alone USB Blaster. Please contact your Altera sales representative to purchase a USB Blaster cable.

Follow the steps below to update your Max II design. Please note that this only needs to be done only once for each board:

1. On the development board, locate a small black 4-pin dip switch labelled SW3 with the screen print label EMB BLASTER. Set SW3, Jumpers J6 and J7 and SW1 as follows:

2. Connect the USB Blaster to the 10-pin JTAG port on side of the board. Make sure that pin 1 is set correctly.

3. Turn the board on.

4. Start Quartus II Programmer, make sure you’re in “JTAG” mode.

5. Click “Hardware Setup…” button on top left and make sure that the USB Blaster is selected.

6. Click “Auto Detect” on left, it should find “EPM2210”.

7. Double click on the “” field on that EPM2210 line, in the “File” column.

8. Browse to and select the “m2_prod_1338.pof” file.

9. Check the “Program / Configure” checkbox on the EPM2210 line (which will make it checked for both CFM and UFM).

10. Click “Start” on left hand side – you’ll see the progress on the top right side.

11. Once complete, confirm the presence of the new Max II Design by holding down on the “CPU RESET” button on the board (underneath the LCD display), the left LED display should change to show “1338”.

Configure the Development Board Switches and Jumpers

On your development board make sure the following setting are correct:

• On the development board locate a small black 4 pin dip switch labelled SW3 with the screen print label EMB BLASTER. On SW3 is set to 0 – 1 – 1 – 1 (FPGA Bypass is set to 0, everything else is set to 1)

• Jumpers J6 (DEV_SEL) should not be populated

• J7 (JTAG_SEL) must is populated (i.e. shorted) only.

• This is required to be able to use the on-board USB Blaster. If you are using an external USB Blaster connected to the 10-pin J-TAG header on the board, J7 must NOT be populated.

6 Getting Started with Linux and Software Tools

Before You Start

Before deciding to use the Linux distribution for the Nios II processor, please note and acknowledge the following important facts about it:

• This distribution is provided free-of-charge to users under the terms of GPL

• There is absolutely no warranty for this distribution

• The only form of free technical support for this distribution is through the Nios Forum or the niso2-dev mailing list at:





If you are interested in commercially supported Linux and toolchain, please make sure to check for additional options.

Installing a Linux Desktop on Your PC

You should have at least 60GB disk space partitioned for Linux to do host side nios2-linux development.

The Linux tool chain for the Nios II processors were tested against RHEL5 and Centos5 desktop software. We recommend that you start with these desktop software versions.

Alternatively you can try Fedora 11, which is a much newer desktop that supports cutting edge hardware and software features. Because Fedora and RHEL are derivatives, we may expect few compatibility issues with Fedora 11. Extensive instructions for how to install a Fedora desktop is available from here



After you installed a Linux desktop, you might have to disable the "SELinux" feature in order to run Quartus. To change the SELinux setting,

• On RHEL5 and Centos5, run the program system-config-securitylevel

• On Fedora 11, run the program system-config-selinux

Installing the Linux Development Package

Follow the steps below to install the necessary Linux development packages on your Linux desktop, as root or sudo.

• For RHEL5/Centos5 only, enable EPEL at .

% wget

% rpm -Uvh epel-release-5-3.noarch.rpm

• For RHEL5/Centos5/Fedora 11

% yum install git-all git-gui tcsh make gcc ncurses-devel bison \ libglade2-devel byacc flex gawk gettext ccache zlib-devel gtk2-devel lzo-devel pax-utils

Installing the nios2-linux Source and Toolchain

Please download and expand the tar file (1.8GB) as a normal user with the following commands:

% wget

% sha1sum nios2-linux-20090929.tar

2482512682f72a69dd96cdaf907bc614893d9af4 nios2-linux-20090929.tar

% tar xf nios2-linux-20090929.tar

% cd nios2-linux

% ./checkout

After installation, there are three important subdirectories to note:

• toolchain-mmu – contains the binary toolchain executables

• linux-2.6 – contains the kernel source

• uClinux-dist – contains the build environment, including config and user space

Add the toolchain-mmu directory to your PATH in, .bash_profile or .profile with the following command:

PATH=$PATH:/home/hippo/nios2-linux/toolchain-mmu/x86-linux2/bin

Nios II Hardware Reference Design

1 About your Development Platform

[pic]

Figure 2: Development Platform Showing Linux Host and Nios II Target

FIGURE 2 ABOVE ILLUSTRATES ALL THE COMPONENTS OF YOUR DEVELOPMENT PLATFORM, INCLUDING THE DEVELOPMENT HOST, THE NIOS II TARGET, AND THE CONNECTIONS BETWEEN THEM. THE BOARD, WHEN CONFIGURED AS A NIOS II TARGET, WILL BOOT AND RUN LINUX AND ALLOW HOST-TARGET COMMUNICATION AND FLASH PROGRAMMING OVER EITHER THE HIGH SPEED ETHERNET LINK OR USB CABLE.

The Linux Host should have the following software installed:

• Linux for Nios II processor development package

• Altera Quartus II software and Nios II EDS, version 9.0 sp1 or later. Please note that you can also use the Altera Quartus II software on a Windows PC.

The Nios II Target, the Cyclone III FPGA Development Kit, has the following key components:

• Cyclone III FPGA Device

Once configured with the FPGA image for the Nios II Hardware Reference Design, Cyclone III Edition, the FPGA becomes a general purpose processor system with peripherals. On reset, the CPU will jump to reset address in Flash where it will execute the boot loader code.

• Max II CPLD

On power up, the Max II CPLD is the configuration controller that configures the FPGA from a user selectable Flash image. Users select the Flash image by setting the on-board rotary switches and jumpers.

• Flash Memory

Once the on-board Flash memory is programmed with the FPGA configuration image for the Nios II hardware reference design, Cyclone III Edition, the option bits for the Max II configuration controller, the U-Boot boot loader, a JFFS2 Flash file system, and a pre-built Linux kernel, the development board on power up will boot up as a Nios II target running Linux.

• Embedded USB Blaster Interface

This is an on-board circuitry for FPGA configuration, host-target communication and Flash programming over a standard USB Cable

• Ethernet Interface

For host-target communication and high-speed Flash programming

For more information on the Cyclone III FPGA Development Kit, refer to the documentation at:

2 About the Nios II Hardware Reference Design

[pic] Figure 3: Block Diagram For Nios II Hardware Reference Design for Linux, 3C120 Cyclone III Edition

The Nios II Hardware Reference Design for Linux, 3C120 Cyclone III Edition is a fully functional processor system design that is provided as a blue print to illustrate the best practices on building a Nios-based processor subsystem. This design is also timing-constrained, and optimized for Linux performance.

1 System Description

As shown in Figure 3, this design is a processor system that consists of the following components:

• Nios II /f Core

o 32-Bit, 125 MHz CPU clock

o Memory Management Unit

o 32KB Instruction Cache

o 32 KB Data Cache

o Shared Data and Instruction Tightly Coupled Memory 1KB

• System ID

o Maintains version ID used to match hardware system with software executables

• DDR2 SDRAM Memory Controller

o Used for Program and Data Memory

o 64 bit data width

o 125 MHz

• Timer

o 1ms period

• JTAG UART

o For communication via USB connector

• UART

o For communication via RS232 Connector

• Triple Speed Ethernet Media Access Controller Core (TSE-MAC)

o For communication via Ethernet

• Transmit Scatter-Gather DMA (Tx-SGDMA)

o Transfers data to the TSE MAC

• Receive Scatter-Gather DMA (Rx-SGDMA)

o Receives Ethernet data from the TSE MAC

• Descriptor Memory

o On Chip memory allocated to set up the SG-DMA

• CFI Flash Controller

o For non volatile data storage and to store FPGA configuration

• LED PIO

2 Memory Map and Linker Regions

The memory map of the Nios II processor system, the Linker regions and Linker sections are show in Table 2.1, 2.2 and 2.3 respectively.

All address that fall in the range 0x00000000 to 0x1FFFFFFF are direct mapped while addresses from 0x2000000 and above are managed by the Memory Management Unit (MMU). In order to optimize for fast system performance, the base addresses of all peripherals are mapped outside of the area managed by the MMU.

It is recommended that you allocate your user peripherals in the direct mapped memory range (0x00000000 to 0x1FFFFFFF). It is also recommended that you retain the memory allocations for the peripherals provided to you as part of the Nios II Hardware Reference Design for Linux, Cyclone III Edition.

|Device |Device Name |Address Range |Size (bytes) |Attributes |

|High Performance DDR2 SDRAM |ddr2_lo_latency_128m |0x10000000 – 0x17FFFFFF |134217728 |Memory |

|Controller | | | | |

|Timer |linux_timer_1ms |0x08400000 – 0x0840001F |32 |Timer |

|JTAG UART |jtag_uart |0x08004D50 – 0X08004D57 |8 |Printable |

|System ID |Sysid |0x08004D40 – 0x08004D47 |8 | |

|UART |Uart |0x08004C80 – 0x08004C9F |32 |Printable |

|Transmit Scatter Gather DMA |Sgdma_tx |0x08004800 – 0x08004BFF |1024 | |

|Receive Scatter Gather DMA |Sgdma_rx |0x08004400 – 0x080047FF |1024 | |

|Triple Speed Ethernet MAC |tse_mac |0x08004000 – 0x080043FF |1024 | |

|Descriptor Memory (On-Chip) |descriptor_memory |0x08002000 – 0x08003FFF |8192 |Memory |

|Tightly Coupled Memory for TLB miss |fast_tlb_miss_ram_1k |0x07FFF400 – 0x07FFF7FF |1024 |Memory |

|CFI Flash Memory Controller |cfi_flash_64m |0x00000000 – 0x03FFFFFF |67108864 |Flash, memory, |

| | | | |non-volatile |

Table 2.1 Nios II Hardware Reference Design for Linux, 3C120 Cyclone III Edition Memory Map

|LINKER REGION NAME |ADDRESS RANGE |MEMORY DEVICE NAME |SIZE (BYTES) |OFFSET (BYTES) |

|DDR2_LO_LATENCY_128M |0X10000020 – 0X17FFFFFF |DDR2_LO_LATENCY_128M |134217696 |32 |

|DDR2_LO_LATENCY_128M_BEFORE_EX|0X10000000 – 0X1000001F |DDR2_LO_LATENCY_128M |32 |0 |

|CEPTION | | | | |

|DESCRIPTOR_MEMORY |0X08002000 – 0X08003FFF |DESCRIPTOR_MEMORY |8192 |0 |

|FAST_TLB_MISS_RAM_1K |0X07FFF400 – 0X07FFF7FF |FAST_TLB_MISS_RAM_1K |1024 |0 |

|CFI_FLASH_64M |0X02800020 – 0X03FFFFFF |CFI_FLASH_6KM |25165792 |41943072 |

|RESET |0X02800000 – 0X0280001F |CFI_FLASH_6KM |32 |41943040 |

|CFI_FLASH_64M_BEFORE_RESET |0X00000000 – 0X027FFFFF |CFI_FLASH_6KM |41943040 |0 |

TABLE 2.2 NIOS II HARDWARE REFERENCE DESIGN FOR LINUX, 3C120 CYCLONE III EDITION LINKER REGIONS

Table 2.3 Nios II Hardware Reference Design for Linux, 3C120 Cyclone III Edition Linker Sections

Running Linux on the Nios II Processor

1 Check for Updates

Please refer to the Nios Community Wiki Web for the most up-to-date instructions on how to configure and build the latest version of Linux for Nios II processor. The Nios Community Wiki Web is located at



2 Running a Pre-built Linux Image

Before attempting to run Linux on your Cyclone III FPGA 3C120 Development Board, make sure that you have completed all the pre-requisite steps in Chapter 2 to set up your Cyclone III FPGA Development Board.

Before configuring and building your first Linux kernel, you can experiment with a pre-built kernel by following the steps below:

% cd nios2-linux/uClinux-dist

% nios2-configure-sof ../3c120_default/nios2_linux_3c120_125mhz_top.sof

% nios2-download -g ../3c120_default/linux.initramfs.gz

% nios2-terminal

where

• The nios2-configure-sof configures the FPGA with the .sof file that turns the FPGA into a Nios II processor system, and

• The nios2-download command downloads programs into the Nios II processor memory for execution.

You can reference the Embedded Design Handbook from for full information on these commands.

From the Nios II terminal, you will see the following shell console output:

[ ~]$ cd nios2-linux/uClinux-dist

[ uClinux-dist]$ nios2-configure-sof ../3c120_default/nios2_linux_3c120_125mhz_top.sof

Info: *******************************************************************

Info: Running Quartus II Programmer

Info: Command: quartus_pgm --no_banner --mode=jtag -o p;./../3c120_default/nios2_linux_3c120_125mhz_top.sof

Info: Using programming cable "USB-Blaster [USB 2-1.3]"

Info: Started Programmer operation at Fri Aug 14 10:29:25 2009

Info: Configuring device index 1

Info: Device 1 contains JTAG ID code 0x020F70DD

Info: Configuration succeeded -- 1 device(s) configured

Info: Successfully performed operation(s)

Info: Ended Programmer operation at Fri Aug 14 10:29:31 2009

Info: Quartus II Programmer was successful. 0 errors, 0 warnings

Info: Processing ended: Fri Aug 14 10:29:31 2009

Info: Elapsed time: 00:00:07

[ uClinux-dist]$ nios2-download -g ../3c120_default/linux.initramfs.gz

Using cable "USB-Blaster [USB 2-1.3]", device 1, instance 0x00

Pausing target processor: OK

Initializing CPU cache (if present)

OK

Downloaded 3017KB in 42.2s (71.4KB/s)

Verified OK

Starting processor at address 0xD0000000

[ uClinux-dist]$ nios2-terminal

nios2-terminal: connected to hardware target using JTAG UART on cable

nios2-terminal: "USB-Blaster [USB 2-1.3]", device 1, instance 0

nios2-terminal: (Use the IDE stop button or Ctrl-C to terminate)

Linux version 2.6.30-00470-g798546c (hippo@sopc.et.ntust.edu.tw) (gcc version 4.1.2) #2 Tue Jul 21 11:53:58 CST 2009

console [early0] enabled

Early printk initialized

Linux/Nios II-MMU

init_bootmem_node(?,0x1030b, 0x10000, 0x18000)

free_bootmem(0x1030b000, 0x7cf5000)

reserve_bootmem(0x1030b000, 0x1000)

Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512

Kernel command line:

NR_IRQS:32

PID hash table entries: 512 (order: 9, 2048 bytes)

Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)

Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)

We have 98304 pages of RAM

Memory available: 126648k/3114k RAM, 0k/0k ROM (1756k kernel code, 1357k data)

Calibrating delay loop... 62.05 BogoMIPS (lpj=310272)

Mount-cache hash table entries: 512

net_namespace: 296 bytes

NET: Registered protocol family 16

init_BSP(): registering device resources

bio: create slab at 0

NET: Registered protocol family 2

IP route cache hash table entries: 1024 (order: 0, 4096 bytes)

TCP established hash table entries: 4096 (order: 3, 32768 bytes)

TCP bind hash table entries: 4096 (order: 2, 16384 bytes)

TCP: Hash tables configured (established 4096 bind 4096)

TCP reno registered

NET: Registered protocol family 1

msgmni has been set to 247

io scheduler noop registered

io scheduler anticipatory registered

io scheduler deadline registered

io scheduler cfq registered (default)

ttyJ0 at MMIO 0x8004d50 (irq = 1) is a Altera JTAG UART

console handover: boot [early0] -> real [ttyJ0]

0 : New Bus ID

BUG: No TSE MDIO Reset

Altera TSE MII Bus: probed

Found phy with ID=0x1410cc2 at address=0x12

Altera TSE MII Bus: MDIO Bus Registered

eth0 (): not using net_device_ops yet

eth0:Successed to register TSE net device

Altera Triple Speed MAC IP Driver(v8.0) developed by SLS,August-2008,--Linux 2.6.27-rc3

mice: PS/2 mouse device common for all mice

TCP cubic registered

NET: Registered protocol family 17

RPC: Registered udp transport module.

RPC: Registered tcp transport module.

Welcome to

____ _ _

/ __| ||_|

_ _| | | | _ ____ _ _ _ _

| | | | | | || | _ \| | | |\ \/ /

| |_| | |__| || | | | | |_| |/ \

| ___\____|_||_|_| |_|\____|\_/\_/

| |

|_|

For further information check:



BusyBox v1.14.2 (2009-07-21 11:53:23 CST) hush - the humble shell

Enter 'help' for a list of built-in commands.

/ #

Congratulations! You just ran Linux on the Nios II processor!

3 Configure and Build Your First Linux Image

In the last section we showed you how to download and run a pre-built Linux image on a Nios II processor system. In this section we will explain how to configure and build your first Linux image.

Configure your Kernel with xconfig

xconfig is a GUI based configuration utility for configuring Linux kernel build options. In this section you will establish a baseline build options, to be identified as the Altera “Altera nios2” configuration.

To use xconfig, follow these steps below:

1. From the command line, start xconfig with the following commands:

% cd nios2-linux/uClinux-dist

% make xconfig

Figure 4: xconfig GUI

2. Click on the triangle to the left of "Vendor/Product Selection", and change vendor to "Altera", and product to "nios2".

Figure 5: Create an Altera Nios2 configuration

3. File --> Quit --> "Save configuration ?" [OK]

When you save the configuration, default settings will be applied to kernel and user space applications builds.

If you were asked option like this, "Build faac (LIB_FAAC) [N/y/?] (NEW)", enter to use default. This will be improved in a later release.

Compile Your Kernel and User Space Applications

After establishing the “Altera nios2” configuration options, you’re ready to compile the kernel and user space applications with these build options. The steps are:

% cd nios2-linux/uClinux-dist

% make

Note that this command may take some time to complete. When make completes, the following new Linux images are created:

• images/linux.initramfs.gz – This is an .elf format Linux image with a built-in initramfs file system

• images/vmImage – This is a compressed U-Boot image.

• rootfs.initramfs.gz – This is compressed initramfs to be used as initrd by U-Boot

Running Linux on the Nios II Target

You can run the new images by following the steps below and you should see console output as you saw earlier when you experimented with the pre-built image.

% nios2-configure-sof ../3c120_default/nios2_linux_3c120_125mhz_top.sof

% nios2-download -g images/linux.initramfs.gz

% nios2-terminal

4 Git Version Control System

All the source files for the free open source Nios II Linux distribution are managed with the git version control system. You can use the git server to track your source with local git branches, getting updates from the community git server, as well as contributing to the community.

Please refer to the tutorial and documents on the git site at



In this section we will show you how to perform the following common tasks with the git server:

• Accessing the git server

• Getting updates from the git server

• Create your own local branch

• Customize your kernel and user application configuration

• Adding JFFS2 root file system

• Build your own customized kernel

• Save your configuration settings

• Commit your changes to your local branch

• Adding an application to your build

• Booting Linux from Flash

Accessing the Git Server

There are several ways to get source updates from the community git server. Options are:

• Normally you will use "git" protocol to get update from server when your PC

is directly connected to the Internet. If this is the case, you need to do the following:

% cd nios2-linux

% ./update

• If you are behind a proxy firewall and cannot use the git protocol, you then can use ssh tunneling through port 443 to get updates with the following commands:

% cd nios2-linux

% ./use_ssh443_for_update

% ./update

To do this, you will need a ssh tunneling package installed, such as "corkscrew".

Add the following 3 lines to your ~/.ssh/config:

IdentityFile ~/.ssh/id_rsa

IdentityFile ~/nios2-linux/sshkey/id_rsa

ProxyCommand corkscrew %h %p

Then

o Replace

to that of your http proxy server.

o Change the nios2-linux path to yours.

o Disallow public access to the file with "chmod og-rwx config".

• If you can’t use ssh tunnling from above, you can also try dumb http protocol

with this command with

% cd nios2-linux

% ./use_http_for_update

% export http_proxy=http://:

% ./update

This is very slow and not recommended.

• When there is no more firewall blocking , you can revert to git with this command :

% cd nios2-linux

% ./use_git_for_update

% ./update

Creating Your Git branch

You should create a local git branch for your customization. The command below creates a local branch "nios2abc", where you can add your code and customization. It is very important to save your changes with git commits.

% cd nios2-linux/uClinux-dist

% git branch nios2abc origin/trunk

% git checkout nios2abc

Using a kernel configuration and user space applications settings saved in the vendors/Altrea as a start point, you can create your own vendor selection as Mycompany/myproduct with the commands below:

% cp -a vendors/Altera vendors/Mycompany

% cp -a vendors/Mycompany/nios2 vendors/Mycompany/myproduct

You can then save these files with a commit to your local git branch with the following commands:

% git add vendors/Mycompany

% git commit -m "add Mycompany/myproduct dir"

You can view and confirm this change with the command,

% gitk

Figure 6: create a new git branch

Configure and Building a Customized Kernel and User Space Applications

Having created your own branch, now you can select "Mycompany" in vendor selection and "myproduct" in product selection and you are ready to customize the build to meet your needs. Next we will show you how to enable MTD and JFFS2 support in the kernel, and MTD utilities in the user space.

1. Using "make xconfig" in the uClinux-dist directory, you can customize your kernel configuration by checking the “Customize Kernel Settings (NEW)” and the “Customize Application/Library Settings (NEW)” options.

Figure 7: customize kernel configuration options

To finish, choose File --> Quit --> "Save configuration ?" [OK]

When prompted for "Linux Kernel Configuration" and "uClinux Distribution Configuration", choose the MTD support in the kernel as shown below:

[ Linux Kernel Configuration ]

Device Drivers -->

 

#### To enable MTD

[v] Memory Technology Device (MTD) support --->

--- Memory Technology Device (MTD) support

[ ] Debugging (NEW)

[ ] MTD concatenating support (NEW)

[v] MTD partitioning support

[ ] RedBoot partition table parsing (NEW)

[ ] Command line partition table parsing (NEW)

[ ] TI AR7 partitioning support (NEW)

*** User Modules And Translation Layers ***

[v] Direct char device access to MTD devices

-*- Common interface to block layer for MTD 'translation layers

[ ] TI AR7 partitioning support (NEW)

*** User Modules And Translation Layers ***

[v] Direct char device access to MTD devices

-*- Common interface to block layer for MTD 'translation layers

[v] Caching block device access to MTD devices

2. To enable CFI FLAHS and JFFS2 support in the kernel, select kernel configuration settings as shown below:

Figure 8: enable Flash support

#### To enable CFI flash

RAM/ROM/Flash chip drivers -⋄

[v] Detect flash chips by Common Flash Interface (CFI) probe

[ ] Detect non-CFI AMD/JEDEC-compatible flash chips (NEW)

[ ] Flash chip driver advanced configuration options (NEW)

[ ] Support for Intel/Sharp flash chips # for neek

[v] Support for AMD/Fujitsu flash chips # others

[ ] Support for ST (Advanced Architecture) flash chips (NEW)

[ ] Support for RAM chips in bus mapping (NEW)

[ ] Support for ROM chips in bus mapping (NEW)

[ ] Support for absent chips in bus mapping (NEW)

Mapping drivers for chip access --->

[ ] Support non-linear mappings of flash chips (NEW)

Flash device in physical memory map

[ ]   Physmap compat support

[ ] Generic uClinux RAM/ROM filesystem support (NEW)

[ ] Map driver for platform device RAM (mtd-ram) (NEW)

#### To enable flash filesystem support

File systems --> 

Miscellaneous filesystems  ---> 

[v] Journalling Flash File System v2 (JFFS2) support

3. To enable MTD utilities in user space applications, select configuration settings as shown below:

[ uClinux Distribution Configuration ]

Flash Tools  ---> 

--- MTD utils

[v] mtd-utils

[v] flash_erase (former‘y 'er’se')

[v] flash_eraseall (former‘y 'erase’ll')

Figure 9: enable MTD utilities

Saving Your Configuration Settings

After you have custom configured your kernel build, you may want to save your configuration setting as default for “myproduct”. You can do this by selecting the “Update Default Vendor Setting” using xconfig as shown below.

Figure 10: update default vendor settings

This changes the setting files in vendors/Mycompany/myproduct directory, specifically:

• config.linux-2.6.x contains the kernel configuration settings

• config.vendor-2.6.x contains the user space applications configuration settings

Other settings files you can edit in this directory to control how your Linux image behaves are:

• device_table.txt is the device nodes created when system boots

• inittab contains the tasks started by init process in simpleinit format.

• ../common/rc is the init script, you can copy this file to the myproduct directory, edit it and change Makefile to use this new one.

• Since our example includes JFFS2 support, you must also modify the Makefile to accommodate this. Please refer to the diff in the screenshot in Figure 11.

When you select JFFS2 support in the kernel, images/rootfs.jffs2 will be created, and you can use it to program a JFFS2 partition in Flash as the kernel’s root filesystem. The Flash chip on the Altera Cyclone III FPGA Development Board has 128KB erase sector size, which is different from the mkfs.jffs2 default of 64KB. You will need to add a line to change this value at the beginning of Makefile of myproduct directory.

MKFS_JFFS2_FLAGS = -l -p -e 128

Building Your Custom Kernel with a JFFS2 Root File System

After customizing your build, you’re ready to build your new kernel image with the following commands:

% cd nios2-linux/uClinux-dist

% make

Next time when you run the new kernel image, you will see Flash partitions displayed in boot message like this:

physmap platform flash device: 04000000 at 00000000

physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank

Amd/Fujitsu Extended Query Table at 0x0040

physmap-flash.0: CFI does not contain boot bank location. Assuming top.

number of CFI chips: 1

cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.

cmdlinepart partition parsing not available

RedBoot partition parsing not available

Using physmap partition information

Creating 9 MTD partitions on "physmap-flash.0":

0x000000000000-0x000002800000 : "userspace"

0x000002800000-0x000002900000 : "U-Boot"

0x000002900000-0x000002d00000 : "uImage1"

0x000002d00000-0x000003100000 : "uImage2"

0x000003100000-0x000003500000 : "uImage3"

0x000003500000-0x000003880000 : "DEFAULT_MMU"

0x000003880000-0x000003c00000 : "MAXIMUM_MMU"

0x000003c00000-0x000003f80000 : "USER_IMAGE"

0x000003f80000-0x000003fa0000 : "options-bits"

Commit Your Customization to Local Git Branch

To save all of your changes and commit them to your local git branch, follow these steps below:

1. Start the git GUI with the command git-gui or git gui for Fedora11

2. Find the files in the upper left window called "Unstaged Changes"

3. Click on the files which you have changed to see the diff results

4. Click the icon to the left of a file to move it to the "Staged Changes (will commit)" window. Repeat to move all the source files you have changed. This is the same as the "git-add" command

5. Enter your comments in the "commit message" window with a short description on the first line

Figure 11: staging changes in git repository

6. Press the "commit" button to finish

Figure 12: commit changes in git repository

Adding an Application to Your Build

Now we will show you how to add your own application to the “myproduct” distribution. We will use the simple hello.c as an example. The steps are:

1. Edit file user/Kconfig, add an entry after the line of menu "Miscellaneous Applications"

config USER_HELLO_HELLO

bool "hello"

help

The hello example

2. Add a line to user/Makefile

dir_$(CONFIG_USER_HELLO_HELLO) += hello

3. Create a directory and a file with the following commands:

mkdir nios2-linux/uClinux-dist/user/hello

put hello.c in user/hello dir

4. Create a Makefile in the user/hello directory, with the following lines:

EXEC = hello

OBJS = hello.o

all: $(EXEC)

$(EXEC): $(OBJS)

$(CC) $(LDFLAGS) -o $@ $(OBJS) $(LDLIBS)

romfs:

$(ROMFSINST) /bin/$(EXEC)

clean:

-rm -f $(EXEC) *.elf *.gdb *.o

Now you can find a new "hello" application in xconfig. Select it and build with "make" in uClinux-dist directory.

If you want to port existing application or library that is based on autotools configure, there is a helpful script, autotools.mk. Please look at the Makefile of user/haserl as a example.

Again, you should save the code with git-gui.

Program Your Kernel Image and Root Filesystem Into Flash

Now that you have a custom Linux kernel image and a JFFS2 root filesystem that can serve as your new development baseline, you may want to place them in Flash so that you can use U-Boot to boot into your version of Linux on power up.

Before you program the Flash, please make sure that you consult Chapter 3 on the Flash layout, and then follow steps in Chapter 6.

After you finish the "tftp_program_flash" command in U-Boot, copy the kernel image and filesystem to your TFTP server directory with the following commands:

% cp images/vmImage /tftpboot/uImage.img

% cp images/rootfs.jffs2 /tftpboot/filesystem.jffs2

Write the new images to Flash using U-Boot with these U-Boot commands:

==> run update_uImage

==> run update_filesystem

Finish with the "run bootcmd" or a CPU reset to boot into your new kernel.

Creating a Custom Design

1 Before You Start

Many aspects of the Nios II Hardware Reference Design for Linux, 3C120 Cyclone III Edition are implemented to ensure optimal system performance for running Linux. As you add custom logic, IP cores or porting the system to another FPGA device, we strongly recommend that you follow the following guidelines while adapting the design for your system:

• Do not change the MMU managed memory map

• Do not change the STDIO peripherals

• When adding peripherals, make sure that the memory mapped registers for the peripherals are located within the I/O memory partition.

o Note that all the addresses that fall in the range 0x00000000 to 0x1FFFFFFF are direct mapped while addresses from 0x2000000 and above are managed by the Memory Management Unit (MMU).

• Retain the memory allocations for the peripherals provided to you as part of the Nios II Hardware Reference Design for Linux, Cyclone III Edition.

• Do not modify cache properties.

2 Hardware Bring-up and Kernel Debugging

Before you start to make changes to the hardware design and making custom Linux kernel images for your hardware design, we strongly recommend that you obtain a Lauterbach Trace32-ICD debugger for hardware bring-up and kernel debugging. Refer to Chapter 8 to learn more about how to use the Lauterbach Trace32-ICD debugger on a Nios II system.

3 About the Board Support Package

The BSP that comes with the Nios II Hardware Reference Design for Linux, 3C120 Cyclone III Edition contains Linux platform device drivers for the peripherals in the processor system, they include:

• Ethernet

• SGDMA

• UART

• Timer

• CFI Flash

• JTAG UART

The BSP is delivered in source form in the distribution.

The Quartus II project for the Nios II Hardware Reference Design for Linux, 3C120 Cyclone III Edition and the matching BSP provide a solid starting point for BSP Development. It is recommended that you always start with the sample BSP when you create new device drivers or make iterative changes to the provided device drivers as hardware changes are made in the system.

4 Creating a Custom Design

The steps to creating a custom hardware design and then creating a custom Linux build for the hardware design involve the following steps:

1. Creating a Nios II processor system design using SOPC Builder

2. Compile the hardware design using Quartus software

3. Create a new local git branch in kernel directory

4. Generate a custom_fpga.h header file

5. Save the header file in git branch

6. Configure, build and run the kernel and user applications

7. Updating the Flash

Below is an example.

Creating a Nios II processor system design

Using the SOPC Builder tool, create a minimum processor system design that includes the following features. Please consult on-line documentation from on how to use the SOPC Builder tool.

Our example system will have the following features:

• Nios II/f core

• Hardware multiplier

• MMU, use the default MMU settings

• 512B dual-port tightly coupled memory, connect one port to the tightly_coupled_instruction_master of Nios II, and the other port to the tightly_coupled_data_master.

• Assign "Fast TLB Miss Exception Vector" to the aforementioned tightly coupled memory

• Add DDR3, DDR2, DDR or SDRAM to the system, you need a minimum of 8MB, and a maximum of 128MB

• One full-featured timer, not a hi-res timer

• A JTAG/serial UART

Important things to note while you’re creating the hardware design are:

• Note in Linux, irq 0 means auto-detected, so you must not use irq 0 for ANY devices, except for the timer.

• Component naming is critical. They must match the macro defined in your kernel. Please check the kernel source files below to make sure:

o nios2-linux/linux-2.6/arch/nios2/include/asm/nios.h

o nios2-linux/linux-2.6/arch/nios2/kernel/config.c

• Please also note the guidelines given in the Before You Start section of this chapter

Compile the Hardware Design

Please consult the Altera user documentation for Quartus software and the SOPC Builder tool for information on how to create and compile a new hardware design.

Creating a Local Kernel Branch

After you finish your hardware design, you will need to tell Linux about your hardware parameters. You accomplish this by creating a local git branch in nios2-linux/linux-2.6 directory to save your creation.

% cd nios2-linux/linux-2.6

git branch nios2custom origin/nios2mmu

git checkout nios2custom

Generate a system header file

Your hardware design has fixed peripheral component base addresses, which the Linux device drivers access through a static header file called customfpga.h. This file must be regenerated manually by you each time the system memory map changes.

When you make any changes to the hardware design using the SOPC Builder tool, it automatically generates a .sopcinfo file after you recompile the hardware design. The .sopcinfo file contains information on the hardware design, including the system memory map. You must manually run the sopc-create-header-files command on the .sopcinfo file in order to generate the custom_fpga.h.

You can learn more about the sopc-create-header-files with the --help option from the Nios II Command Shell as shown below:

Generate a new header file and move it to the right location with the following commands:

sopc-create-header-files --single custom_fpga.h

cp custom_fpga.h nios2-linux/linux-2.6/arch/nios2/include/asm

You should save your custom_fpga.h with git-gui in nios2-linux/linux-2.6 directory.

Configure, Build and Run the Kernel and User Applications

With the new custom_fpga.h header copied to kernel, you have to tell the kernel to use this file instead of the default one supplied with the original hardware reference design.

Start xconfig with:

% cd nios2-linux/uClinux-dist

% make xconfig  # to select kernel config

Figure 13: create a custom FPGA configuration

Choose NiosII Configuration  ⎝ NiosII FPGA configuration ⎝ (X) CUSTOM_FPGA

Note that you may need to change other kernel driver settings depend on your FPGA design. For example, you may not have Ethernet interface in the minimum design. Or you may have Real Time Clock with battery backup on a I2C bus through the GPIO interface. You can find more IP cores and driver on the NiosWiki.

Build your kernel with the “make” command.

You can run the new images by following these steps:

% nios2-configure-sof /path_to_your_hardware_project/your_fpga.sof

% nios2-download -g images/linux.initramfs.gz

% nios2-terminal

Flash

After creating your own hardware design and building a new kernel imaging for it, you may want to update the Flash so that you can boot into your custom configuration on power up. Please refer to Chapter 5 on how to program the Flash.

Working with Flash

On power-up, FPGAs, which are comprised of volatile memory elements, are generally un-configured, i.e. they are blank. Before the Cyclone III FPGA can operate as a Nios II-based embedded processor system, it first needs to be configured with the configuration data, which is usually stored in the on-board Flash. This section explains the steps to program the Flash so that your board can boot Linux on power-up.

1 Reference Flash Layout Scheme

With this Linux distribution, you can take advantage of a pre-build Reference Flash Image as a starting point. The layout scheme of this reference is as shown below.

[pic]Figure14: Reference Flash Layout Scheme for the Cyclone III FPGA Development Kit

This Flash layout is designed to enable the following features:

• The current Flash layout design allows 3 hardware configuration pages to co-exist in the Flash. Users can select a particular hardware configuration to program the FPGA with the on-board rotary switch (SW5). The Reference Flash Image occupies 1 of the 3 configuration pages, leaving the other two for users to allocate for their designs without having to lose the factory settings.

• Each hardware configuration page allocates space for the SRAM Object File for an FPGA image.

• The Option Bits section stores board specific settings that are used by the Max II configuration controller

• Sufficient space is allocated for U-Boot as well as JFFS2 File system, both of which can be shared for a given combination of hardware configuration and bootable Linux Kernel.

Table 3: Flash Component Addresses, Allocated and Used Portions

THE FLASH SECTIONS LABELLED “USED” IN TABLE 3 ARE USED TO DELIVER THE REFERENCE FLASH IMAGE, WHICH IS DESCRIBED IN DETAIL IN THE SECTION BELOW. THE PARTS LABELLED “ALLOCATED” ARE AVAILABLE FOR USER FLASH IMAGES. BY ADHERING TO THIS FLASH LAYOUT SCHEME, YOU CAN EXPERIMENT WITH DIFFERENT HARDWARE CONFIGURATIONS AND THEIR RESPECTIVE BOOTABLE LINUX KERNELS WITHOUT LOSING THE DEFAULT REFERENCE SETTINGS.

2 Reference Flash Image for Linux

As mentioned before, one of the three possible configuration pages in Flash is used to deliver a fully working Nios II-based processor system which can boot Linux on power-up. This boot image consists of several components and this system appears in Flash as shown in Figure 6. This set of Flash content is collectively referred to as the Reference Flash Image.

[pic]Figure 15: Reference Flash Image for Linux

3 FLASH PROGRAMMING METHODS

There are two alternatives methods to program the configuration Flash.

• Programming Flash over USB using the Nios II Flash Programmer

The simplest and most straight forward method of programming Flash is to use the Nios II Flash Programmer utility, which is a part of the Nios II EDS. The nios2-flash-programmer utility downloads the Flash image from a host machine to the Flash device through a standard USB cable.

• Programming Flash over Ethernet Using U-Boot

Programming the Flash using U-Boot over Ethernet can reduce the time it takes to complete the task. The idea is to first download U-Boot to the FPGA device temporarily for the sole purpose of programming the Flash with it. Once U-Boot is running on the target, you can then use the Flash programming utilities supplied with U-Boot to program the Flash over high speed Ethernet.

You can use U-Boot to program Flash over Ethernet because the popular U-Boot program has been supplemented with a number of utilities to ease the task of working with FPGAs. A complete list of Nios II hardware specific U-Boot environment variables and scripts are available in Chapter 7.

This is the recommended method for programming the Flash for the first time, as well as updating the Flash with your own designs subsequently. Step-by-step instructions on how to program and update your Flash with U-Boot are shown below.

4 Program Flash over Ethernet Using U-Boot

The programming procedure involves the following steps:

1. Using the USB connection, download and run a temporary processor system and a temporary U-Boot in the FPGA memory

2. Program the Flash using this temporary system, and over the high-speed Ethernet connection

Download a Temporary Processor System

The temporary processor system we refer to is in fact a Nios II system whose sole purpose is to run U-Boot to enable you to program the Flash for the first time. You need to use this system only once. Since you will program the minimum system directly into the FPGA memory, it will be lost when you cycle power on the board.

To download the minimum system into the FPGA, please follow the steps below:

1. Connect the Linux host to the USB connector on your development board via a USB Cable.

2. On your Linux host, navigate to the location of where you downloaded the Nios II Hardware Reference Design for Linux, Cyclone III Edition. It is under this directory where the SRAM Object File (SOF) for the project is located:

% cd /niosII_cycloneIII_3C120

3. In the host shell, program the FPGA device by typing the following command:

% quartus_pgm --mode=jtag --operation=p\; default/nios2_linux_3c120_125mhz.sof

This command configures the FPGA with the temporary Nios II processor.

Program the Factory Flash Image over Ethernet with U-Boot

In the steps below we show you how to fetch the Reference Flash Image files from a TFTP server and then use U-Boot to write it into Flash. Note that there are two Flash image files you need:

• The kernel image - nios2-linux/3c120_default/vmImage

• The rootfs image - nios2-linux/3c120_default/rootfs.jffs2

1. You will need access to a TFTP server to complete this step. To verify that a TFTP server is running on a Linux host, execute the following command:

% /sbin/chkconfig --list | grep tftp

Ensure that the status of the TFTP service is set to TFTP : ON

2. Copy the Flash images to the TFTP server with the following commands:

% cp nios2-linux/3c120_default/vmImage /tftpboot/uImage

% cp nios2-linux/3c120_default/rootfs.jffs2 /tftpboot/filesystem.jffs2

4. Navigate to the location of the u-boot-file directory (/U-Boot-files/tftpboot) U-Boot executable and type:

% nios2-download -g u-boot; nios2-terminal

Hit any key in the first 10 seconds to enter U-Boot command prompt.

This command downloads a temporary instance of U-Boot which you will run with the temporary Nios II processor. You can control the operation of U-Boot from the Nios II Terminal, which serves U-Boot’s console port.

5. In the nios2-terminal, set up the IP address for the TFTP Server at the U-Boot prompt.

==> setenv tftpserverip

==> saveenv

==> run tftp_program_flash

==> run bootcmd

The tftp_program_flash script will write the following data to the Flash:

• The standard reference processor system hardware design for the 3C120 board

• The standard reference Linux kernel image for the 3C120 board

• JFFS2 root file system

• U-Boot

• Ethernet MAC address

• Option Bits

By completing these steps, you have created a bootable Linux system with the “factory” images and settings, and a U-Boot with which you can update the Flash in the future.

Updating the Flash with Your Own Kernel Image and Rootfs

With the U-Boot programmed in Flash, you can use it to update the Flash with your own kernel image and rootfs. Note the steps below:

1. Copy the kernel image and filesystem to your TFTP server directory with the following commands:

% cp images/vmImage /tftpboot/uImage.img

% cp images/rootfs.jffs2 /tftpboot/filesystem.jffs2

2. Write the new images to Flash using U-Boot with these U-Boot commands:

⎝ run update_uImage

⎝ run update_filesystem

⎝ run bootcmd

Finish with the "run bootcmd" or a CPU reset to boot into your new kernel.

On the next power up, this system will boot your Linux.

U-Boot Boot Loader

1 Boot Loader

1 U-Boot

The U-Boot program supplied with the Linux distribution for Nios II is a modified version of the popular open source U-Boot project. You can consult for complete information on U-Boot itself.

In addition to common U-Boot features, the Nios II version of the program also provides a number of handy options and utilities for working with a processor on an FPGA, such as Flash programming. U-Boot features that are unique for the Nios II implementation is documented in this chapter.

2 U-Boot Environment Variables and Scripts for Nios II

The U-Boot implementation for the Nios II Hardware Reference Design, 3C120 Cyclone III Edition is an enhanced version of the popular open source U-Boot project. This version includes a number of features that are provided specifically to ease the task of working with a FPGA based processor system. Please refer to the EP3C120.h file for a complete list of features that are available in this implementation.

To view the implementation of these scripts, such as the update_uImage script, as well as the environment variables used by the scripts, simply type ‘printenv’ at the U-Boot prompt.

None of the U-Boot scripts take arguments. The scripts use environment variables instead of parameters. For example, update_uImage utilizes the U-Boot environment variables uImage_cur, loadaddr, serverip, fileaddr, and filesize. Some scripts actually run other scripts as well. For example, update_uImage script runs the ipaddr_cmd script.

|Variable/Script |Description |

|ipaddr_cmd |This script is used by other scripts to set the MAC address and the IP address. This should either |

| |be “dhcp”, or a number of setenv commands to set the IP address, gateway IP, and subnet mask. The |

| |default implementation also calls “altera ethaddr”, and if the MAC address does not already exist in |

| |Flash, the MAC address is set to 00:07:11:01:02:03. |

|tftp_bootcmd |Script to boot a kernel image over TFTP from ${tftpserverip} ipaddress. It copies ${bootfile} to |

| |local memory, and attempts to boot it. |

|uImage_bootcmd |Script to boot from the Flash stored uImage at location ${uImage_cur}. |

|tftp_program_flash |Script to erase and program the entire Flash over TFTP. It downloads a longer U-Boot script called |

| |tftp_program_flash_script.img, and executes it. |

|Bootfile |Variable that defines the filename of a uImage to be booted over TFTP. |

|bootargs_jffs |Script that sets the bootargs environment variable to the default for booting the kernel with a JFFS2|

| |root partition |

|bootargs_nfs |Script that sets the bootargs environment variable to the default for booting the kernel with an NFS |

| |root partition |

|bootargs_cur |Script that runs the script to set the bootargs appropriately. This should be set to either "run |

| |bootargs_jffs", "run bootargs_nfs", or another user defined option. |

|Nfsroot |Variable that contains the path to the NFS root on the NFS server. |

|fpga_page_cur |Variable used by update_fpga_image script. This is the location that will be updated. |

|fpga_page{0,1,2} |Variables that contain the addresses of the FPGA images stored in Flash (for reference only). |

|uImage_cur |Variable that contains the address of the uImage to boot when booting from Flash. |

|uImage{0,1,2} |Variables that contains the addresses of the uImages stored in Flash (for reference only). |

|u-boot |Variable that contains the address if the U-Boot image stored in Flash (for reference only). |

|Option_bits |Variable that contains the address if the option bits used by the PFL statemachine that programs the |

| |FPGA. (for reference only). |

|Filesystem |Variable that contains the address of the JFFS2 partition in Flash (for reference only). |

|Tftpserverip |TFTP server IP address. |

|Nfsserverip |NFS server IP address |

|Update_fpga_image |Script that downloads a new FPGA image over TFTP, and programs it to Flash at location |

| |${fpga_page_cur} |

|Update_uImage |Script that downloads a new uImage image over TFTP, and programs it to Flash at location |

| |${uImage_cur} |

|Update_uboot |Script that downloads a new U-Boot image over TFTP, and programs it to Flash at location ${u-boot}. |

|jffs_bootcmd |Gets the system id of the currently running Nios II processor system running in the FPGA. The system|

| |id is then used to construct the name of a U-Boot image, called /boot/${sysid}.img. This image then |

| |gets loaded from the JFFS2 filesystem into memory, and is booted. This command can be used as a |

| |verification measure to ensure that the right kernel is used for the matching Nios II processor |

| |system, which is particularly important when you are testing iterative changes to the hardware |

| |design. |

|Altera |This command reads the MAC address programmed into Flash at the last Flash sector or where |

| |${ethernet_option_bits} points to. “altera ethaddr” will read the MAC address, verify that |

| |0x00005afe is present (safe code), and set a U-Boot environment variable called ethaddr to this |

| |value. The U-Boot script ipaddr_cmd uses the “altera” command. The Flash writing U-Boot scripts, |

| |such as tftp_program_flash, call ipaddr_cmd. The default built kernel accepts a kernel command line |

| |argument tsemac=${ethaddr}. |

Kernel Debugging Using the Lauterbach Trace32-ICD Debugger

To use the Lauterbach Trace32-ICD debugger to do kernel debugging, you need to do the following:

1. Install the Lauterbach Trace32-ICD debugger and apply a patch named 56469663_update_nios2.zip available from TBD.

2. Set up the board as follows:

a. SW3 bypass=0 all other=1

b. DEV_SEL (J6) and JTAG_SEL (J7) should be off

3. Start the Trace32-ICD debugger and execute the following commands:

% sys.res

% jtag.loadrbf def.rbf

% sys.up

% sys.jtagclock 25MHz

% data.load.elf

% sys.jtagclock 1MHz

% term.method DCC

% go

Please note that the sys.jtag clock setting is only important if you plan to use the JTAG UART.

Please refer to Lauterbach documentation for the complete information on how to use the Trace32 debugger.

-----------------------

Network

Linux PC

Altera Cyclone III FPGA Development Board

USB

|Flash Component |Start Address in |Description |

| |Flash | |

|Ethernet Address Option bits |0x03FC0000 |Used - MAC address |

|Parallel Flash Loader Option Bits |0x03FE0000 |Used - Board specific Configuration Setting bits used by Used – |

| | |Max II Configuration Controller CPLD |

|All Option Bits |0x03F80000 |Reserved - Begin area for option bits of various types |

|HARDWARE CONFIG PAGE 2 |0x03C00000 |Allocated - space for a user FPGA configuration image |

|HARDWARE CONFIG PAGE 1 |0x03880000 |Allocated - space for a user FPGA configuration image |

|HARDWARE CONFIG PAGE 0 |0x03500000 |Used - space for a factory FPGA configuration image |

|User Bootable Linux Kernel 2 |0x03100000 |Allocated - space for User Linux Kernel |

|User Bootable Linux Kernel 1 |0x02D00000 |Allocated - space for User Linux Kernel |

|Factory Bootable Linux Kernel |0x02900000 |Used - space for Factory Provided Linux Kernel |

|U-Boot |0x02800000 |Used - Boot Loader |

|Root File System |0x00000000 |Used - JFFS2 Root File System |

|SW3 (EMB BLASTER) DIP SWITCH |Settings |Jumpers |Settings |

|FPGA BYPASS |0 |J6 (DEV_SEL) |Shorted |

|HSMA_BYPASS |1 |J7 ( JTAG_SEL) |Shorted |

|HSMB_BYPASS |1 |SW1 |Settings |

|MAX_ENABLE |1 |Position 5 (MAX0) |Open |

|Linker Section Name |Linker Region Name |Memory Device |Memory Device Name |

|.bss |ddr2_lo_latency_128m |DDR2 SDRAM |ddr2_lo_latency_128m |

|.entry |Reset |CFI Flash |cfi_flash_64m |

|.exceptions |ddr2_lo_latency_128m |DDR2 SDRAM |ddr2_lo_latency_128m |

|.heap |ddr2_lo_latency_128m |DDR2 SDRAM |ddr2_lo_latency_128m |

|.rodata |ddr2_lo_latency_128m |DDR2 SDRAM |ddr2_lo_latency_128m |

|.rwdata |ddr2_lo_latency_128m |DDR2 SDRAM |ddr2_lo_latency_128m |

|.stack |ddr2_lo_latency_128m |DDR2 SDRAM |ddr2_lo_latency_128m |

|.text |ddr2_lo_latency_128m |DDR2 SDRAM |ddr2_lo_latency_128m |

|SW3 (EMB BLASTER) DIP SWITCH |Settings |Jumpers |Settings |

|FPGA BYPASS |0 |J6 (DEV_SEL) |Unpopulated |

|HSMA_BYPASS |1 |J7 ( JTAG_SEL) |Shorted |

|HSMB_BYPASS |1 |SW1 |Settings |

|MAX_ENABLE |1 |Position 5 (MAX0) |Open |

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download