The Quanta LB9A/u-boot primer
This page is meant to be a "handbook" of sorts that give you a general picture and a HOW-TO of the various technicalities associated with configuring the Quanta LB9A, a switch that, when set up properly, becomes a "purely OpenFlow" switch that must be connected to a controller to function as a network device.
Index
…more like quick links.
I Prep work - some things to keep around and in mind when working with these switches
II LB9A facilities - the bootloader, firmware and their modes, hardware, and how to get to them
III A u-boot Primer - using the bootloader to configure and troubleshoot
IV OpenFlow Switching - setting up OpenFlow mode
I. Preparations
The following things are good to have on hand.
1.1 References
Flashing the firmware
- http://openflowswitch.org/wk/index.php/LB4GImageSetup
- http://www.openflow.org/wk/index.php/IndigoQuickStartLB4G (possibly more up-to-date)
Configuring the switch
- http://www.openflow.org/wk/index.php/IndigoConfiguration - synopsis of system files, variables
- http://www.openflowswitch.org/wk/index.php/IndigoReleaseNotes - the actual HOWTO for turning the box into an OpenFlow switch
1.2 Prerequisites
The things listed here are mostly for connecting to the switch via serial. The actual steps are covered later on.
- A PC running some *nix with a serial port
- RS232 to RJ45 null cable (a Cisco flat cable actually works)
- packages on PC: ckermit, openssh
II LB9A facilities
The Quanta switch is basically a Linux box with a bunch of ports. Out of the box, the Quanta comes with two versions of customized Linux, one pre-installed on the on-board flash, and the other, on the removable cf card. The flash and cf card are the two primary forms of memory found on the switch that we really need to care about. One can chose which image to load through u-boot, the second-stage boot loader provided with the switch. In either case, the Linux base for the Quanta is comprised of the kernel image (uImage), the filesystem (uInitrd2m), and device tree (LB9A.dtb). The primary differences between the two images are:
- The image on flash contains a diagnostics test interface
- The image on the cf card lets you access 3 main things:
- XorPlus, a switching firmware that allows the Quanta to be configured as a regular switch
- an older version of the OpenFlow interface, and
- a system shell
What follows next is a quick primer for u-boot and an overview of the two images. Note, usage of u-boot is covered in greater detail in section 3.
2.1 u-boot
u-boot is the second-stage boot loader for the switch firmware. It has enough smarts to allow you to flash the switch and inspect/configure various boot options, and in the case of OpenFlow, set parameters that the switch will use to connect to the controller.
To enter the u-boot prompt, you have to interrupt the boot process when you see the u-boot banner.The easiest way to do this is to have a serial connection to the switch so you can see it boot. This can be set up using a RJ-45 to RS-232 cable. A Cisco cable will also work for this. Connect the RJ-45 end to the port labeled "Con" on a switch, and the other end to the PC. Next, as root, start a session from a shell using kermit:
kermit -l /dev/ttyS0 set carrier-watch off set baud 115200 connect
Then power on/reboot the switch. If you see the U-Boot banner, you can stop the boot process by hitting any key. This should lead you to the '⇒' u-boot prompt:
U-Boot 1.3.0 (Sep 9 2010 - 16:00:13)
CPU: 8541, Version: 1.1, (0x80720011)
Core: E500, Version: 2.0, (0x80200020)
Clock Configuration:
CPU: 825 MHz, CCB: 330 MHz,
...
Net: TSEC0, TSEC1
IDE: Bus 0: OK
Device 0: Model: CF Card Firm: Ver2.35 Ser#: 14EF0707040600187736
Type: Hard Disk
Capacity: 1923.9 MB = 1.8 GB (3940272 x 512)
Hit any key to stop autoboot: 0
=>
u-boot is configured by creating and modifying environment variables. These can be anything from a single variable to a multi-line script of many variables, parameters, and flags. Several commands that are good to know for working with u-boot are:
?- list available commandshelp- get more information about a commandprintenv- list current environment variablessetenv- make changes to / create new environment variablessaveenv- save changes to environment variablescopy- use tftp to copy files to flashimls- list images in flashflinfo- print flash memory contents
Section 3 will go into more detail.
The next two sections quickly describe the two images found on a fresh switch.
2.2 The cf card image
This is the image loaded by default when the switch is powered on. It can also be loaded from u-boot with the command run cfcard_bootcmd.
If you let the switch boot without intervention, you are presented with three choices:
Please choose which to start: Pica8 XorPlus, OpenFlow, or System shell:
(Will choose default entry if no input in 10 seconds.)
[1] Pica8 XorPlus * default
[2] OpenFlow
[3] System shell
As seen in the above "screenshot", XorPlus will be automatically loaded after 10 seconds, giving you the standard switch CLI. XorPlus is a full-fledged switch configuration interface; Documentation for using XorPlus can be downloaded from the Pica8 website.
The second choice, "OpenFlow", gives you an outdated version of the Indigo interface, the "pure OpenFlow" switch firmware. The interface is essentially a standard Linux shell, plus OpenFlow facilities such as of-bcm-cli.
The last choice, "System shell", lets you access the base system using the ash shell, and is regular Linux as far as anyone cares. This last mode is useful if you need to access the cf card to test out a new image, or to check configuration scripts for XorPlus or OpenFlow.
Any of these options can be chosen by entering a number and hitting <Enter> when the above list pops up.
2.3 The flash image
This image can be loaded form the u-boot prompt with the command run flash_bootcmd. As far as I can tell, the sole purpose of this image is to provide a diagnostics. The following prompt shows up after the standard boot-up procedures:
Diagnostic Test Main Menu v1.3 (LB9A - Linux) [1 ] File Management [2 ] Board Information [3 ] Diagnostic Test [4 ] Manufacturing Test Mode Set [5 ] Test Error Log File Management [6 ] PING [7 ] Reset [8 ] For Vibration Test Enter your choice:
There isn't much I can tell you about this interface, except that option [1 ] doesn't do anything, [7 ] reboots the switch, and [8 ] might be unsafe to do on a hard, inclined surface1.
III A u-boot Primer
This section is a HOW-TO for scripting in u-boot with respect to the Quanta, e.g. variables, scripts, and memory maps unique to this switch. OpenFlow related u-boot stuff can be found in the next section.
3.1 Environment variables
As mentioned in the last section, u-boot is configured through environment variables. The command printenv lets you see all of them:
=> printenv flash_bootcmd=setenv bootargs root=/dev/ram console=ttyS0,$baudrate; bootm ffd00000 ff000000 ffee0000 cfcard_bootcmd=setenv bootargs root=/dev/ram console=ttyS0,$baudrate; ext2load ide 0:1 0x1000000 /uImage;ext2load ide 0:1 0x2000000 /uInitrd2m;ext2load ide 0:1 0x400000 /LB9A.dtb;bootm 1000000 2000000 400000 bootdelay=5 baudrate=115200 loads_echo=1 ipaddr=192.168.2.1 serverip=192.168.2.12 rootpath=/nfsroot gatewayip=192.168.2.254 netmask=255.255.255.0 hostname=LB9A_X bootfile=eldk-quanta loadaddr=4000000 ethact=TSEC0 bootcmd=run cfcard_bootcmd ethaddr=60:eb:69:21:5b:e3 eth1addr=60:eb:69:21:5b:e4 stdin=serial stdout=serial stderr=serial Environment size: 644/8188 bytes
The output above is from a fresh switch out of the box. Each entry is a line of the form [variable name]=[parameters]. the parameters can be a combination of u-boot commands and other variables in a way similar to a simple shell script.
The general syntax for these variables can be summarized as follows:
[name]=[parameters], where [parameter] is some string relevant to the variable, [name]$[name]returns the value of a variable, [name], which is defined in a separate line (same as in bash shell scripting)- semicolon (
delimits individual commands
Variable definitions can be inlined as parameters for other variables. For example, note the first two entries in the "screen shot" above:
<entry 1> flash_bootcmd=setenv bootargs root=/dev/ram console=ttyS0,$baudrate; bootm ffd00000 ff000000 ffee0000 <entry 2> cfcard_bootcmd=setenv bootargs root=/dev/ram console=ttyS0,$baudrate; ext2load ide 0:1 0x1000000 /uImage;ext2load ide 0:1 0x2000000 /uInitrd2m;ext2load ide 0:1 0x400000 /LB9A.dtb;bootm 1000000 2000000 400000
Both flash_bootcmd and cfcard_bootcmd are part of the run commands from the previous section that boot the different Linux images. These entries are made up of multiple strings comprised of u-boot commands and variable declarations and separated by semicolons. The first strings for both define a new variable called "bootargs" using command setenv. setenv is given multiple variables that define "bootargs":
root=/dev/ram- probably specifies where the root filesystem should be loaded2console=ttyS0- set output to /dev/ttyS0$baudrate- use the parameters specified in the variable "baudrate," which we can see is set to 115200 (baud) in the aboveprintenvoutput
The strings that follow the semicolon after $baudrate differ a bit for the two variables. For the cfcard_bootcmd entry the ext2load commands specifies where to fetch the kernel, ramdisk, and device tree files from, respectively. The specific syntax for each ext2load command is:
ext2load [interface] [memory address] [path to file]
What is really important here (and for troubleshooting things) are the memory location values. For the cf card, the values should be:
- 0x1000000 for kernel image (uImage)
- 0x2000000 for filesystem (uInitrd2m)
- 0x400000 for the device tree (LB9A.dtb)
The same follows for the flash image, with ffd00000, ff00000, and ffee0000 being the address locations where the kernel, ramdisk, and device tree files always begin, respectively. The current version of u-boot has some tools for inspecting flash memory. These will be discussed in the troubleshooting section.
Both variable definitions end with the bootm command, which loads the program files from the memory locations given by ext2load in the cf card or implied in the flash. bootm takes parameters as follows:
bootm [kernel img. address] [filesystem address] [device tree address]
3.2 modifying the environment variables list
setenv allows you to modify, create, and delete environment variables. In general:
setenv [name] [parameters], where [name] is new, creates a new variable called [name] defined by parameters specified in [parameters].setenv [name], where [name] already exists, deletes the variable.setenv [name] [parameters]where [name] already exists, overwrites old parameters for the variable [name] with [parameters].
Long parameters. For variables with whitespaces in its parameters (e.g. "script variables" like flash_bootcmd), the parameters have to be surrounded by single quotes to let u-boot know that everything is part of a single script. For example, to create and configure the variable dn_boot (this script tells u-boot to fetch the filesystem via network using NFS and to boot from flash), we'd type this at the u-boot prompt:
setenv dn_boot 'dhcp; nfs ff000000 $nfsip:$rootpath/uInitrd2m; setenv bootargs root=/dev/ram console=ttyS0,$baudrate DEV_ADDR=$ipaddr ETH0_IP=$ipaddr $extra_boot_args rw; bootm ffd00000 ff000000 ffee0000'
Note the single quotes before dhcp and after ffee0000. Another important thing about long parameters is that they cannot contain newlines or backslashes; The whole command must be typed as a single line.
3.3 boot parameters
Most long variables are bootup scripts. By default, there are two bootup scripts on a Quanta: cfcard_bootcmd and flash_bootcmd. As you can see throughout these docs, a user can easily create new bootup scripts of any arbitrary name.
A script called [name] can be run by invoking it with the run command. For example, to run dn_boot, you'd type
run dn_boot
at the u-boot prompt. This runs the command only once. In order to make a bootup script persist (e.g. be the default one that the switch boots to), you must set the variable bootcmd to the run command. The default script used in these switches is cfcard_bootcmd. You can see that in the printenv output.
=> printenv ... bootcmd=run cfcard_bootcmd
3.4 Flashing the switch/testing out images
The copy command is the primary way to flash the switch with new firmware, as well as for updating u-boot itsself:
copy <-b/-k/-r/-d> <tftp://serverip/filename | xmodem> <-b/-boot> boot image file <-k/-kernel> kernel image file <-r/-ramdidk> ramdisk image file <-d/-dtb> Device Tree Binary file
copy leverages TFTP in order to fetch files into the proper locations in flash memory. Memory locations and file type are implied through flags; as such, copy does not check for consistency between flag and file type of the file you specify. This makes it critical that you double-check the flags and filenames you give copy3.
Firmware updates may also be done via NFS. Usages of both copy and bootup via NFS are covered in section IV.
Another tool to consider is the system shell, available from the CF card Linux image. For example, if you don't want to flash the new firmware, one can just add the images to /cf_card and point a u-boot script to the names of the new files:
cfboot=setenv bootargs root=/dev/ram console=ttyS0,$baudrate; ext2load ide 0:1 0x1000000 /uImage2;ext2load ide 0:1 0x2000000 /uInitrd2m2;ext2load ide 0:1 0x400000 /LB9A2.dtb;bootm 1000000 2000000 400000
cfboot can then be manually started with the command run cfboot, or be set as the default boot parameter by setting it as bootcmd's parameter.
3.4 troubleshooting
Mis-configurations in u-boot can cause various interesting4 issues including non-persistent configurations, hanging on bootup, and bricked switches. The first two are mildly annoying; the latter requires a JTAG cable and is serious enough an issue that everyone is discouraged from touching u-boot unless absolutely necessary. A Grid service is provided for manipulating the Quantas.
3.4.1 Flash memory
U-boot comes with tools such as imls and flinfo that allow you to inspect flash memory. Under normal circumstances, the memory map of the switch should look like below. Note the memory location and size of the ramdisk and kernel images. Any deviation can be a potential issue e.g the use of wrong firmware and wrongly copied files.
=> imls Image at FF000000: Image Name: Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size: 12275941 Bytes = 11.7 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Image at FFD00000: Image Name: Linux-2.6.27 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 1742743 Bytes = 1.7 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK
A more detailed memory map can be found with flinfo. The 'E' next to the octets indicate empty spots in memory, RO write protected spots.
=> flinfo Bank # 1: CFI conformant FLASH (16 x 16) Size: 32 MB in 256 Sectors AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x7E2201 Erase timeout: 4096 ms, write timeout: 1 ms Buffer write timeout: 3 ms, buffer size: 64 bytes Sector Start Addresses: FE000000 FE020000 FE040000 FE060000 E FE080000 E FE0A0000 E FE0C0000 E FE0E0000 E FE100000 E FE120000 E FE140000 E FE160000 E FE180000 E FE1A0000 E FE1C0000 E FE1E0000 E FE200000 E FE220000 E FE240000 E FE260000 E FE280000 E FE2A0000 E FE2C0000 E FE2E0000 E FE300000 E ... FFE00000 FFE20000 FFE40000 FFE60000 FFE80000 FFEA0000 FFEC0000 E FFEE0000 FFF00000 RO FFF20000 RO FFF40000 E FFF60000 E FFF80000 E FFFA0000 E FFFC0000 RO FFFE0000
The output can be pretty big. It is also far less intuitive than imls (and often less useful).
3.4.2 CF Card
There are no means of inspecting the CF card from U-boot directly, maybe except from getting a glance of the memory map during (attempted) bootup. It should look like the following:
## Booting image at 01000000 ... Image Name: Linux-2.6.27-svn3877 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 1711826 Bytes = 1.6 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Loading RAMDisk Image at 02000000 ... Image Name: svn3877 Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size: 20822821 Bytes = 19.9 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Booting using the fdt at 0x400000 Loading Ramdisk to 1eae1000, end 1febcb25 ... OK
If the switch can boot from the CF Card, choosing the system shell will give you access to a shell that will let you poke around the CF card. It should be mounted as the /cf_card directory.
IV OpenFlow Switching
the newest method of upgrading the firmware to the OpenFlow capable one (Indigo) does not require messing around with u-Boot. If for some reason the old method is needed, it can be found here. A word of caution - the official how-to link says to use an outdated version of the firmware with a bug whose workaround is to update to the latest firmware. It is better off to just start with the newest version.
4.1 Installation
Here we go over how to flash the switch with the proper firmware. Caution is needed so as not to brick the switch. Several steps might reiterate things from the previous sections, since this section was actually written way before the other sections.
- Official HowTo: http://www.openflowhub.org/display/Indigo/Up+and+Running+on+the+3290+or+3780
- Download links: http://www.openflowhub.org/display/Indigo/Indigo+-+Download+Page
4.1.1 Connecting to the switch
A serial connection can be set up between the switch and a machine using a RJ-45 to RS-232 cable. Surprisingly, a Cisco cable will work for this. Connect the RJ-45 end to the port labeled "Con" on the switch, and the other end to the PC. Next, start a session from a shell with kermit as root:
kermit -l /dev/ttyS0 set carrier-watch off set baud 115200 connect
Start up the switch. Eventually you will be given three or four boot options, depending on your firmware. Choose the system shell.
4.2 update the firmware.
4.2.1. Getting the image
Get the latest tarball from the download page. Currently this is indigo-2012.03.19-pronto-3290.tgz, and it contains, along with some docs, three files that make up the image:
- uImage-pronto-3290
- uInitrd2m-indigo-2012.03.19-pronto-3290
- device-tree.dtb-pronto-3290
The files must be renamed to uImage, uInitrd2m, and LB9A.dtb, respectively, before they can be used. It's also recommended to back up the old image files to a separate directory before overwriting them.
cp uImage uInitrd2m LB9A.dtb /cf_card/backups/
4.2.2. Move the files
Connect one of the switch's management ports, labeled ETH1 and ETH2, to the network. These two ports map to eth0 and eth1; configure them appropriately using ifconfig and route.
ifconfig eth0 inet 192.168.203.156 netmask 0xfffffc00 route add default gw 192.168.200.1
Next, copy the three files mentioned above to /cf_card . This can be done with either tftp or scp. If it hasn't been done already, rename the files appropriately.
4.2.3. Final configs and reboot
The switch is configured by a startup script that reads the contents of /cf_card/local/sysenv . If not there, create the file, adding one line for the management IP:
mkdir /cf_card/local/ cd /cf_card/local/ cat > sysenv export switch_ip=192.168.203.156 ^D
And reboot the switch. If all is well, the switch will be running the new firmware. One good indicator is the throttling of the fans; the switch will be considerably quieter after it boots up into the new firmware.
4.3. The Web GUI
once the switch starts back up, pointing the browser to the management IP should bring up the management page:
http://192.168.203.156
U-Boot method (old)
This section provides example uses of the u-Boot facilities for manipulating the OpenFlow properties of the LB9A. We will also introduce the ORBIT Grid Service facilities that can be used to configure the switch without dealing with the gory details of u-boot (given the switch has the proper firmware, that is).
Fire up the switch. If you see the U-Boot banner, you can stop the boot process (hit ctrl-c) so you can copy/burn the images onto flash.
4.2 updating u-boot
This step is comprised of the following steps:
- change network settings of switch
- update u-boot
- upload kernel, root filesystem, and device tree to flash
- modify boot parameters
The switch for SB9 will be images via nfs with console.sb9 as the server. This is to prevent users from bricking the switch by playing with u-boot.
4.2.1 change network settings
As explained in the u-Boot primer, the network settings are hard-wired into the switch via environment variables. The default settings statically set the switch's IP to a 192.168.X.X address block, which you might want to change depending on your network setup.The four variables of our interest are:
- ipaddr (switch's static ip, default 192.168.1.2)
- gatewayip (what the switch sees as default gw on its route table)
- serverip (who to talk to for services e.g. tftp)
- netmask (self-explanatory)
These variables should correspond to those for the network you're attaching the switch to. In our case, we set the switch's IP to 10.50.0.40, and cut out the hassle of setting the gateway IP by just directly pointing the switch to think the tftp server is the gateway:
=> setenv gatewayip 10.50.0.42 => setenv ipaddr 10.50.0.40 => setenv netmask 255.255.0.0 => setenv serverip 10.50.0.42 => saveenv
4.2.2 updating u-boot/copying files to flash
Once the networking variables are set, you can start copying the necessary files to the switch using copy. copy uses tftp to fetch the images:
=> copy -b tftp://10.50.0.42/u-boot.bin => copy -k tftp://10.50.0.42/uImage => copy -r tftp://10.50.0.42/uInitrd2m => copy -d tftp://10.50.0.42/LB9A.dtb
The first line updates u-boot. The next three fetch the kernel image, root filesystem, and device tree, respectively.
4.2.3 modifying boot parameters
This section covers booting the switch using a manually loaded root filesystem from on-board flash. To use NFS, refer to the next section, 2.2.4.
In addition, you want to modify flash_bootcmd so that it tells the linux kernel to mount the root filesystem read-write:
=> setenv flash_bootcmd 'setenv bootargs root=/dev/ram console=ttyS0,$baudrate rw DEV_ADDR=x.x.x.x; bootm ffd00000 ff000000 ffee0000' => saveenv
Several boot parameters such as the DEV_ADDR variable used by the OF startup scripts can also be set here. The details of can be found in IndigoConfiguration.
Also, make sure that the variable bootcmd is set to run flash_bootcmd. If not, reset with setenv and save this change as well:
=> setenv bootcmd 'run flash_bootcmd' => setenv bootfile eldk-quanta => saveenv
and load the image by issuing the command boot. if all goes well, you should be at the Linux shell prompt once the switch starts up.
Note: The bootcmd parameter will be the proper value if the switch is restarted after u-boot is updated (a.k.a. after the 1st copy command). This, however, resets all of your networking variables, so you'd have to re-do the steps in 2.2.1. Basically, it is up to the tastes of whoever is re-imaging the switches to either manually set the bootcmd variable or reset all of the network parameters after reboot.
4.2.4 Using NFS with DHCP.
Reference articles:
- http://www.openflow.org/wk/index.php/IndigoQuickStartLB4G#NFS
- http://www.openflowswitch.org/wk/index.php/IndigoQuickStart3290
Here, we assume that the switch will be assigned an IP address via DHCP. It will use the assigned IP address for 1) booting via NFS, and once booted into Linux, 2) the value assigned to DEV_ADDR and the management interface eth0. It is also assumed that you have a working NFS server with the following line in /etc/exports:
/config 10.19.0.0/255.255.0.0(rw,sync,insecure,no_subtree_check)
- DHCP setup in u-boot:
=> setenv ipaddr => setenv bootargs => setenv dhcp_boot dhcp => setenv autoload no
The first two commands blank out any previously assigned IP addresses and boot arguments. The next two enable DHCP. You can test if DHCP works via the command dhcp:
=> dhcp Speed: 1000, full duplex BOOTP broadcast 1 Got error 4 DHCP client bound to address 10.50.250.6
- Set the startup script variable:
=> setenv dn_boot 'dhcp; nfs ff000000 $nfsip:$rootpath/uInitrd2m; \ setenv bootargs root=/dev/ram console=ttyS0,$baudrate DEV_ADDR=$ipaddr \ ETH0_IP=$ipaddr $extra_boot_args rw; bootm ffd00000 ff000000 ffee0000'
dhcp invokes the DHCP client we configured earlier, which sets $ipaddr. Next, the necessary image(s) are loaded via NFS. Then, bootargs are set so that the OS knows where to locate the root FS (in /dev/ram). 'rw' set mount parameters for the root FS. Both DEV_ADDR and ETH0_IP are variables used by Linux once the system boots into it; They are both set to the DHCP assigned IP address. $extra_boot_args can be set to additional variables using "setenv extra_boot_args '<VARS>'" (It's essentially a dummy variable). Finally, bootm is used to load the linux kernel, filesystem, and device tree stored on flash.
- Set additional variables. Make sure all the variables required by the startup script are defined. You may also want the set the bootcmd to boot using the new script.
=> setenv nfsip 10.19.0.10 => setenv hostname sw-sb9-da => setenv netmask 255.255.0.0 => setenv rootpath /config
- Save your settings with
saveenv.
4.3 Configuration
There are two basic ways that you can go about configuring the OpenFlow behavior of the LB9A - 1) setting OpenFlow parameters via u-boot, and 2) through the ORBIT Grid Services, though at the time that this is being written, the latter is somewhat rough around the edges. Some things to note about the OpenFlow mode LB9A:
- eth0 and eth1 as given by
ifconfig -aare eth1 and eth2 on the faceplate, respectively. The interfaces can be manipulated as with any Linux box usingifconfig. - The ssh server (dropbear) is enabled by default. Telnet can be started by invoking telnetd. In either case the default username is
root, and password isOpenFlow.
4.3.1 Using the OpenFlow CLI (OF-BCM)
OF-BCM is the OpenFlow command line supplied with the image. It can be started manually:
# /sbin/of-bcm-cli Broadcom Command Monitor: Copyright (c) 1998-2008 Broadcom Corporation Release: sdk-xgs-robo-5.6.6 built 20100905 (Sun Sep 5 23:01:38 2010) Stanford OpenFlow Monitor Platform: LB9A_MPC8541 OS: Unix (Posix) PCI unit 0: Dev 0xb538, Rev 0x11, Chip BCM56538_B0, Driver BCM56634_B0 rc: unit 0 ... OF-BCM.0>
4.3.2 Key files
The OpenFlow components of the switch rely on the following:
/etc/rc.sh- system startup script: bring uplo, mounts filesystems, loads kernel modules, ect/etc/system_config- system initialization scrit/etc/system_config- system configs unique to each switch/rc.soc,/etc/config.bcm- starts OpenFlow components/etc/find-env- defines many of the system variables
4.3.3 Grid Services
The ORBIT grid services allow you to query and configure various components of the testbed(s) through a browser from gw.orbit-lab.org. Here our focus is on the network services.
addOpenFlow
This allows you to set u-Boot environment variables without going into the gory details of u-Boot. For example, to boot a switch into OpenFlow mode, issue the following command at the navigation bar on your browser from external2 (make sure you have X11 tunneling):
http://www.orbit-lab.org/network/addOpenFlow?switch=172.16.20.8&ip=172.16.0.14&port=6633&dpid=001010201608
This points the 8th Grid data plane switch to kvm-big, the Big Switch controller at 172.16.0.14.
After thinking for a bit, the browser should return:
dpid = 001010201608 ofip = 172.16.0.14 ofp = 6633
If you get a complain that the service is busy, make sure no-body is using the serial connection to the switch e.g. using telnet to s-nr2.
—
1. I honestly don't know what it does.
2. These are educated guesses through observation, and by no means guaranteed to be what is actually happening. If anyone has an actual explanation I'd be very happy to learn about it.
3. The importance was demonstrated by a mix-up between the -b and -d flags for copy, which happily overwrote u-boot with the device tree, bricking the switch.
4. There are no sarcasm tags in Wiki notation.
Attachments (1)
-
mHT9200-06-gc.pdf
(59.6 KB
) - added by 14 years ago.
instructions on setting u-boot IP
Download all attachments as: .zip
