Gen 3.2 SBC Configuration
From Seamonster
Gen 3.2
- General Microservers, Vexcel Microservers, Quick Reference, Data Acquisition, Middleware
- Components GPS, SBC
- Configuration Microserver, SBC, SD Card, Power
- Operation Communication Protocol (SBC <--> uc), SBC Operations, Agent
- Operation (background) Task Manager "milo", config files, MACRO
- Microcontroller Microcontroller, Firmware, Skeleton firmware
- Evaluation 2008 Cairn relay failure evaluation, Lab evaluation, Eval-Firmware, BPMS, Source notes
- PCS Board PCS Board Design, Voltage Monitoring Circuit
Gen 3.1
- Gen 3.1 Kernel Upgrade and Field Notes (Spring 2007)
- Gen 3.1 Microserver, README, Schematics
- Gen 3.1 Task Manager "milo", GPS, Firmware
Microcontroller-related
Other Microserver-Related
Introduction
The configuration of the Microserver Single Board Computer (SBC) requires two steps: Root pivot to boot from an SD card, and configuration of the Linux environment on the file system living on the SD card. Both are described on this page and subsidiary pages. The latter also includes configuration of a WiFi Ethernet Bridge, by default a LinkSys WET54G.
- Root pivot
- SBC configuration
- Other procedures including SD card replication
- Hardware notes
- Configuration process log
Root Pivot
These steps are intended to get you, the user, to a Debian Linux login prompt on a Microserver SBC. The login as root will have no password, initially, and you should be able to see a 512MB disk partition which about half-full of the actual Linux filesystem contents.
Root pivot 1: Get current kernel and initial ramdisk
The objective here is to obtain the current version of two files, "zImage" and "initrd". These are to be placed on a (typically Linux-type) server for access via trivial-ftp (tftp) from the Single Board Computer.
Go to this link. Read and follow the instructions assiduously. You will need to download two files: A Linux kernel and an initial ramdisk. Note that the size of your TS-7260 FLASH determines which kernel to download. A TS7260-64-32F device for example has a 32MB NAND flash chip and will use kernel file zImage-7260-ts11.
These files will be accessed via Ethernet connection from the TS-7260 to the "server" box. If using Linux they may be placed in the tftp directory. Getting this to work may require some effort on the server box as root.
Example 1: Circa 2004 on an HP laptop running Suze Linux we were obliged to create a /srv/tftp directory sim-linked to /tftpboot.
Example 2: See the TFTP Server page at the SEAMONSTER wiki. tftp was enabled on machines at the Natural Sciences Research Lab (NSRL) where the kernel for the 32MB NAND flash and initrd are available from /srv/tftp.
Root pivot 2: Physical configuration
The purpose of this step is twofold: Connect the SBC to the server so it can pull the files located above, and connect the SBC to a terminal so that you can enter commands (using RedBoot>) to configure the root pivot process.
The Ethernet direct-cable operation that follows can be skipped if both the Ethernet tftp host and the microserver are connected to respective wireless bridges (LinkSys WET54G for example).
The direct Ethernet connection setup:
- Unplug the TS-7260 Ethernet cable if one is attached (for example to the VuS internal Ethernet WiFi bridge).
- Connect a short-plug non-crossover Ethernet cable from the TS7260 to a tftp server.
- Verify the ip address on the Ethernet tftp host (make sure no conflict with TS-7260). Relevant UNIX command is
# ifconfig
- Establish a serial connection terminal into the TS-7260. For example:
- Attach a serial cable to the serial port of the SBC
- Connect the other end to a machine running (Linux: minicom / PC: hyperterm)
- Ensure the terminal settings are 8N1 and 115k baud
- The goal is to read/write on the TS console port.
- When the TS-7260 is powered up its onboard LEDs will blink a couple of times and a console message should appear on the terminal.
- When allowed to run to completion the TS will boot to a faux-Linux application called "Busy Box". Note that during boot a plus sign '+' appears momentarily. By hitting control-C at this time, the boot to Busy Box will be interrupted and instead a RedBoot> prompt will appear. From Wikipedia: "RedBoot is an open source application that uses the eCos real-time operating system Hardware Abstraction Layer to provide bootstrap firmware for embedded systems. RedBoot is used in both product development and in deployed products in the field.RedBoot allows download and execution of embedded applications." This is what we want to use to configure the root pivot.
- From RedBoot> you should be able to ping your server using its ip address.
Root pivot 3: Update the kernel
Warning: If a root pivot has already been done on this TS-7260 (for example an earlier kernel), the flash memory may contain an improper kernel/initrd combination that must be deleted before proceeding.
Warning: File sizes change with revisions. It is necessary to verify the (decimal or hexidecimal) lengths and locations during root pivot configuration for the files you have. To emphasize this we use "variable substitution" nomenclature in what follows."
Tip: See Section 3.1 below for an alternative method for pulling files over to the SBC from a server, using xmodem.
Upon booting to the + and hitting ctrl-C to get to the RedBoot> prompt, issue:
RedBoot> ip_address -l 192.168.1.1/24 -h 192.168.1.52
This assigns both local and host ip addresses which are used in the load command (to obtain zImage and initrd files).
For Monsters: Plug the sbc into the uas network. Use a uas network address for the SBC, for instance 137.229.208.225/24. Use the ip address for nsrl1 for the host (-h):
ip_address -l 137.229.208.225/24 -h 137.229.208.19
On the old HP laptop server using ip address 192.168.1.52: On occasion a "Can't connect" error from RedBoot> appears. A fix was to simply issue (on the HP server):
# ifconfig eth0 down
(to shut down that ip address) and
# ifconfig eth0 192.168.1.53 up
to establish a new ip address. The TS could see this fine.
Use "fis" to see the contents of flash memory and if necessary delete unwanted files.
RedBoot> fis list Name FLASH addr Mem addr Length Entry point (reserved) 0x60000000 0x60000000 0x01D04000 0x00000000 RedBoot 0x61D04000 0x61D04000 0x00040000 0x00000000 initrd 0x61D44000 0x00600000 0x00070000 0x00600000 RedBoot config 0x61FF8000 0x61FF8000 0x00001000 0x00000000 FIS directory 0x61FFC000 0x61FFC000 0x00004000 0x00000000
In the above listing there is an entry for initrd. This is (let's say) the old initrd and it must be deleted. IF there happened to be other files called 'zImage' and 'vmlinux' that also needed to be cleared the following would accomplish this:
RedBoot> fis delete initrd RedBoot> fis delete vmlinux RedBoot> fis delete zImage
Do another 'fis list' to ensure the files are gone. The new images: initrd and zImage can now be loaded in from the Ethernet tftp host, starting with initrd.
Using: RAMDISKLOADADDRESS = 0x00600000 (5/13/2008)
RedBoot> load -r -b RAMDISKLOADADDRESS ts7260-sdcard-initrd-1.03.gz Using default protocol (TFTP) Raw file loaded 0x00600000-0x0066d81d, assumed entry at 0x00600000
This is some version (1.03) which will change in the future with newer releases. Note that the file size is 0x6d81d bytes. This value is used in the fis create command as the argument to the -l switch. We now "name" this section of memory:
Using RAMDISKLENGTH = 0x6d81d we have:
RedBoot> fis create -b RAMDISKLOADADDRESS -l RAMDISKLENGTH initrd
Proceed in exactly the same way to load in and fis create the zImage linux kernel.
RedBoot> load -r -b 0x00218000 zImage-7260-ts11 Using default protocol (TFTP) Raw file loaded 0x00218000-0x002beb4f, assumed entry at 0x00218000
Here the subtraction to get file length is trickier: 0x2beb4f - 0x218000 = 0xa6b4f so the file has hex-size 0xa6b4f.
Using KERNELLENGTH = 0xa6b4f Using KERNELLOADADDRESS = 0x00218000
RedBoot> fis create -b KERNELLOADADDRESS -l KERNELLENGTH zImage RedBoot> fis list Name FLASH addr Mem addr Length Entry point (reserved) 0x60000000 0x60000000 0x01D04000 0x00000000 RedBoot 0x61D04000 0x61D04000 0x00040000 0x00000000 initrd 0x61D44000 0x00600000 0x00070000 0x00600000 zImage 0x61DB4000 0x00218000 0x000A8000 0x00218000 RedBoot config 0x61FF8000 0x61FF8000 0x00001000 0x00000000 FIS directory 0x61FFC000 0x61FFC000 0x00004000 0x00000000
This time the subtraction is a little harder but not too bad, and the fis create command runs fine. Both initrd and zImage are there in the fis table and we can proceed with the fcon configuration procedure. This creates a table called boot_script_data using a rather klunky type-it-in interface.
The following construction can be used to do hex arithmetic for file size calculations:
% echo "obase=16;`ls -l zImage-7260-ts11 | cut -d' ' -f7`" | bc
A6B50
Warning: The values for file size can be determined by differencing (start address and end address + 1) or (start address and end address). The difference will be one; the numbers given here (using the latter case) worked but be aware of this small point if difficulties are encountered.
Root pivot 3.1: Alternative file grab using xmodem
Courtesy Will Otte, Vanderbilt:
Can also use xmodem to transfer the kernel and initrd, which is probably a heck of a lot less trouble than messing around with tftp and ip addresses. It is pretty simple:
pass -m xmodem to the load command instead of a file name, then tell your serial client to start the xmodem transfer, e.g.:
RedBoot> load -r -b base_address -m xmodem C
...and when you see the C, you may tell your server to start the transfer.
Root pivot 4: Update the boot_script_data root pivot table
Warning: There is no way around this I know of: You must specify a console address (serial port) for the configuration of the root pivot command that lives in the boot_script_data table. This probably initially refers to COM1 by means of the string "console=ttyAM0,115200" string. At a later date you may wish to move this console to COM2 in which case the string becomes "console=ttyAM1,115200". The ttyAM number is one less than the COM number. For now what follows keeps the console on COM1 / ttyAM0. The point is (a) it is confusing and (b) you may have to repeat this process later to point the console at COM2. The purpose of doing so is to leave COM1 open for access to the microserver GPS.
First I will describe what is necessary, then I will provide a screen capture of the text of this happening.
You will use the 'fcon' command to first view a table called boot_script_data and then re-write its contents. This table consists of a series of commands, and doing a root pivot to your SD card / Debian OS requires three such commands. They are: (1) fis load <init ramdisk>, (2) fis load <kernel>, and (3) exec for 'execute' the kernel / ramdisk combination.
In order to type in the long 'exec' line of the table you may need to play around with the terminal settings. The initial printout of the boot_script_data table could contain anything, where each table entry is preceded by "..". I used an example where the content doesn't matter. What does matter is that after the table prints you are given a ">>" prompt where you type in the new table in its entirety. You must type in all three lines (with proper substitutions as above) and then hit return creating a blankline indicating you are done. At this point you can confirm the change (y) or exit without changing (n). You can use this procedure to verify that the table you entered previously is correct; just hit return and then n<return> to keep the table the way it is. After this you can type 'reset' at the RedBoot> prompt to restart the system (and hopefully boot to the SD card Debian OS).
RedBoot> fcon boot_script_data boot_script_data: .. fis load initrd .. fis load vmlinux .. exec -r SOMEVALUE -s SOMEVALUE -b SOMEVALUE -l SOMEVALUE -c "console=ttyAM0,115200 root=/dev/ram0 init=/linuxrc rw" Enter script, terminate with empty line >> fis load zImage >> fis load initrd >> exec -r RAMDISKLOADADDRESS -s RAMDISKLENGTH -b KERNELLOADADDRESS -l KERNELLENGTH -c "console=ttyAM0,115200 root=/dev/ram0 init=/linuxrc rw" >> Update RedBoot non-volatile configuration - continue (y/n)? y RedBoot> reset
Configuring the SBC
Everything from here down assumes the SBC is properly booting to its Debian Linux filesystem on a 512MB SD card plugged into the card slot on the SBC board. The character '#' at the beginning of a command is never actually typed. It indicates the command is issued as root. Likewise for '%' which indicates the command is issued as user brick. To indicate the action 'open a file in an editor' I use the command vi. Your editor may vary.
Warning: Sometimes the SD card can be jarred inwards and this releases it on a spring load. It will appear to be "in" but will be disconnected.
File system and boot process
In this section we want to take care of the following:
- Ensure the SBC has a good ip address for use in a sensor web
- Enable root login on COM2 (without actually redirecting the console to COM2)
- Establish a root password
- Create a second user called "brick"
- Configure brick's home directory to include ftp upload/download directories, a source directory and a bin directory
- Configure root's home directory including subdirectories bin, tmp, and usb
- Load in several program files, build them, and install them in /root/bin
- Configure a task manager to run on boot (at run-level 2) that will handshake with the uc (microcontroller) and turn on the WiFi bridge
- Configure the WiFi bridge, enabling wireless access to the microserver
Set SBC ip address
# vi /etc/network/interfaces
Getting the ip address correct is simple for both ts-Linux and for Debian. For ts-Linux the file to modify is in /etc/sysconfig as noted in the User's Manual. In the Debian variant, for example for if you want the SBC ip address to be 192.168.1.21, you would edit /etc/network/interfaces to have an eth0 entry like this:
auto eth0
iface eth0 inet static
address 192.168.1.21
netmask 255.255.255.0
The 'auto eth0' line is necessary to configure this connection automatically on boot.
Enable root login on COM2
- vi /etc/securetty
Replicate the line referencing ttyAM0 to an identical line immediately following in which ttyAM0 has been changed to ttyAM1.
Establish brick account and passwords
- adduser brick
Can make root password and brick password anything appropriate.
Set to UAS network and install programs
- Set bricks to be on UAS network (137.229.208.XXX).
>> pico /etc/network/interfaces address 137.229.208.XXX network 137.229.208.0 netmask 255.255.255.0 gateway 137.229.208.1
- Edit /etc/resolv.conf so that Domain Name Service (DNS) is setup to convert domain names to IP addresses.
>> pico /etc/resolv.conf search jun.alaska.edu nameserver 137.229.196.94 nameserver 137.229.10.39 nameserver 137.229.253.183
- Update the general software package on the bricks
>> apt-get update
- Install 'python' (br54 already had python)
>> apt-get install python
- Install 'less'
>> apt-get install less
- Install ssh
>> apt-get install ssh
- Install 'rsync', edit sshd_conf file so 'PasswordAuthentication' is 'no', then kill and restart process.
>> apt-get install rsync >> pico /etc/ssh/sshd_conf >> ps auxww | grep sshd >> kill -9 PID (PID is determined from last command) >> which sshd >> /usr/sbin/sshd
- Change the hostname of each brick to brick53, brick54, or brick55, then restart.
>> pico /etc/hostname >> pico /etc/hosts on first line: brickIP brick##>>> (ex: 192.168.1.55 brick55) >> shutdown -r now
- Setup keyless ssh and rsync. Generate keys if necessary, rename keys, move keys to remote machine, generate 'authorized_keys' file, add keys to 'authorized_keys' file, test, do all of this again but this time sending the remote keys to the local machine. If everything has been done properly the ssh at the last step should not prompt you for a password, nor should future ssh or scp.
root@brick##:/root/.ssh/ >> ssh-keygen -trsa (after issuing command, hit enter though all the prompts) root@brick##:/root/.ssh/ >> cp id_rsa.pub id_rsa_##.pub (where ## = brick's #) root@brick##:/root/.ssh/ >> scp id_rsa_##.pub seamonster@seamonster.jun.alaska.edu:/home/seamonster/.ssh/ root@brick##:/root/.ssh/ >> ssh seamonster@seamonster.jun.alaska.edu seamonster@production >> cd /home/seamonster/.ssh/ seamonster@production:/home/seamonster/.ssh/ >> cat id_rsa_##.pub >> authorized_keys
Then the other way around:
seamonster@production:.ssh/ >> ssh-keygen -trsa (after issuing command, hit enter though all the prompts) seamonster@production:.ssh/ >> cp id_rsa.pub id_rsa_seamonster.pub seamonster@production:.ssh/ >> scp id_rsa_seamonster.pub root@137.229.208.1##:/root/.ssh/ seamonster@production:.ssh/ >> ssh root@137.229.208.1## root@brick## >> cd /root/.ssh/ root@brick##:/root/.ssh/ >> cat id_rsa_seamonster.pub >> authorized_keys
Now test out the ssh for both:
root@brick##:/root/.ssh/ >> ssh seamonster@seamonster.jun.alaska.edu (this should not ask for a password anymore) seamonster@production >> ssh root@17.229.208.1## (this should not ask for a password anymore)
- Setup Br53 to power a 12V Linksys WRT54G router and amp upon boot instead of a WET54G bridge and amp. This involves modifying the 'updown' script.
root@brick53:/home/brick/src >> pico updown.c Under the -----2----- section, edit the 'ucInterface 2 6' string to read 'ucInterface 2 132' root@brick53:/home/brick/src >> make updown root@brick53:/home/brick/src >> cd ../bin root@brick53:/home/brick/bin >> mv updown /root/bin root@brick53:~/ >> shutdown -r now Check that the voltage of JP7 on the PCS shoots up to 12V after a little after the unit has restarted.
Build file system structure
# mkdir /root/bin
etcetera per below. Then
# su brick
and issue
% mkdir /home/brick/uploads
etcetera per below. Ensure user brick owns all /home/brick subdirectories and likewise for user root and /root.
/root/
/tmp
/data
/bin
/src
/usb -> /mnt/usbDrive
/home/brick/
/bin
/src
/uploads (ensure world-read/writable using '# chmod a+w /home/brick/uploads')
/downloads (ensure world-read/writable using '# chmod a+w /home/brick/downloads')
/mnt/usbDrive
We also need a file that contains the id for each microserver, to do that open a file called /root/bricknum (with vi or pico) and just enter the two digit id.
vi /root/bricknum
Load source files, build, install
Transfer the files listed below to /home/brick/uploads. To do this, checkout the 'Gen32_src' directory from subversion onto a machine (for exampble SEAMONSTER):
svn co http://seamonster.jun.alaska.edu/svn/seamonster/Gen32_src/
If the directory already exists, just cd into it and type
svn up
to update the files. Cd into the Gen32_src directory and type (this moves all the files to the uS)
scp * brick@137.229.208.1#:./uploads/
Now ssh into the uS and move the files to the indicated destination. To move all the .c and .h files just type
# cd /home/brick/uploads # mv *.c /home/brick/src # mv *.h /home/brick/src
In the case where files are moved to /root locations, also issue
# chown root:root file
once the file is relocated. root executables in /root/bin should also be checked to ensure they are executable. In the case where a destination is not given assume it is the same as the previous line. Many (hopefully all) of these files may be found at the subversion code repository: http://seamonster.jun.alaska.edu/websvn/. Click on 'seamonster' and on 'Gen32_src'.
FILE DESTINATION root.bashrc --> /root/.bashrc brick.bashrc /home/brick/.bashrc brick.bashrc.generic brick.config /root date.default /root makefile /home/brick/src gps.c /home/brick/src gps.h /home/brick/src milo.c /home/brick/src milo.h /home/brick/src updown.c /home/brick/src updown.h /home/brick/src ucInterface.c /home/brick/src ucInterface.h /home/brick/src BridgeOn.c /home/brick/src BridgeOff.c /home/brick/src testUCI.c /home/brick/src testUCI.h /home/brick/src dio.c /home/brick/src dio.h /home/brick/src adc.c /home/brick/src adc.h /home/brick/src cMonitor.c /home/brick/src cMonitor.h /home/brick/src portfix.c /home/brick/src bc.c /home/brick/src bc.h /home/brick/src adhoc /home/brick/bin and /root/bin (2 copies)
Build all executables corresponding to '.c' files:
% cd /home/brick/src % make gps % make ucInterface % ...etc...
Copy the executables to /root/bin
# cp /home/brick/bin/* /root/bin # chown root:root /root/bin/* # chmod a+x /root/bin/*
Configure a task manager to run on boot
There are two configuration directories (using this recipe) relevant to running a program automatically on boot:
/etc/init.d /etc/rc2.d
The first will hold a script file that will execute the program we want (we'll call it Agent and it will have some command-line arguments). The second directory will hold an oddly-named symbolic link to the script file. Let us begin by setting up that script file. First, delete any existing script files in /etc/init.d that you do not want to run. Next, edit the script you want, for example using
# vi /etc/init.d/Agent
The file you create should read (verbatim):
#! /bin/sh # updown: basic task manager PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin (/root/bin/Agent) &
Notice that if you want to include command line arguments they should be inside the parentheses on line 4, like this:
(/root/bin/Agent 1 1 6 9 0 3 4 2 5) &
Before ensuring that /root/bin/Agent exists, take care of that sym-link that resides in /etc/rc2.d:
# ln -s /etc/init.d/Agent /etc/rc2.d/S99Agent
When the kernel goes into run-level 2 during boot the sym-link will point to /etc/init.d/Agent. This in turn will run the program /root/bin/Agent. This in turn will (typically) talk to the microcontroller and generally handle the time management tasks for the microserver. After a period of time the Agent program may halt the system for a sleep interval to conserve power. To prevent this from happening you can log on to the system and kill the Agent process:
# ps -ef
(note the process id for 'Agent'; suppose it is 349)
# kill -9 349
The system should now be stable with no Agent threatening to shut it down. There is an un-addressed question here as well: How do you log in wirelessly if the Agent has not turned on the WiFi? There are a couple approaches to this problem including:
- Connect directly to COM1 or COM2 using a serial cable (or to the USB port) and log in using a terminal emulator like Hyperterm.
- Alter the microcontroller edip settings to a WiFi-ON-ALWAYS setting
- Wait until Agent turns on the WiFi, log on, kill Agent; WiFi should remain ON
- Set up Agent to look for a First Time On file; the idea is that Agent will see this file and turn on the WiFi for say 10 minutes before deleting that First Time On file and going into normal operation. This gives 10 minutes to log on wirelessly etcetera.
The Agent program is discussed in detail on this page; this is a simple version of the MACRO concept of an Agent. It also corresponds roughly to what we called the "milo" task manager in the Gen 3.1 microserver pages.
Configure the WiFi bridge, enabling wireless access to the microserver
We are (6/2008) using the LinkSys WET54G Wireless Ethernet Bridge. This needs to be configured using its native web browser.
CONFIG INSTRUCTIONS: SHORT VERSION
- Connect, Log in to WET 54G at ip address 192.168.1.226; uname blank (or admin), pword admin
- Change ip address (e.g. 192.168.1.230), subnet 255.255.255.0, Gateway: Any
- Set SSID to linksys, Ad-Hoc mode ch11, Mode Mixed, Security off, Apply
- Log in to the new ip address to ensure everything is ok
CONFIG INSTRUCTIONS: LONG VERSION
- Reset WET 54G to ip address 192.168.1.226 (hold down Reset button for 10 seconds)
- Ensure device has good power. If there is a crossover/straight switch it should be on crossover. The cable would then be normal, not crossover.
- Connect the Ethernet cable to a computer with a browser, ensure this computer is on the 192.168.1 subnet.
- Connect to the Bridge using a web browser with the appropriate ip address: 192.168.1.226 (as of 5/2008).
- The login is admin and the password is admin OR the login is blank and the password is admin.
- Change IP address to 192.168.1.XXX (e.g. bricknum + 200)
- Note this ip address somewhere visible using permanent ink, as well as in a document describing the sensor web configuration.
- Set Subnet Mask 255.255.255.0
- Gateway should not matter; 192.168.1.1 is fine, so is 0.0.0.0.
- Set SSID: linksys
- Warning: Default may be Linksys; make it linksys with a lower-case ell. This is for back-compatibility with Gen-2 WET-11s.
- Set Network Type to Ad-Hoc, Channel to 11
- Mode: 802.11b/g Mixed
- Note: This is also for back-compatibility with Gen-2 WET-11s. Pure-802.11G is fine.
- Keep Security Disabled
- Click <Apply>, wait about 15 seconds.
- Re-login using admin/admin or " "/admin.
- Verify that the settings are correct; look at Setup and Status pages both.
Reboot and check all of the above are ok
Go!
Mounting a USB drive
If a USB "thumb" drive is connected to the USB port, you can see how this was viewed during the boot process using the command
# dmesg
For example:
# dmesg <a lot of text...> Initializing USB Mass Storage driver... usb.c: registered new driver usb-storage scsi0 : SCSI emulation for USB Mass Storage devices Vendor: JetFlash Model: TS2GJF2A/120 Rev: 8.07 Type: Direct-Access ANSI SCSI revision: 02 Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0 SCSI device sda: 4030462 512-byte hdwr sectors (2064 MB) sda: Write Protect is off /dev/scsi/host0/bus0/target0/lun0: p1 WARNING: USB Mass Storage data integrity not assured USB Mass Storage device found at 2 USB Mass Storage support registered.
This looks pretty reasonable. However the drive does not auto-mount, necessarily. This can be done on the command line:
# mount /dev/scsi/host0/bus0/target0/lun0/part1 /mnt/usbDrive
I believe the "unmount" command would be:
# umount /mnt/usbDrive
but this needs verification. I'm also not sure at the moment whether /mnt/usbDrive must pre-exist. If so it should be created as root using mkdir. One can also create a symbolic link to this location for example in the root home directory as follows:
# ln -s /mnt/usbDrive /root/usb
# cd /root/usb
# df .
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/scsi/host0/bus0/target0/lun0/part1
2014912 0 2014912 0% /mnt/cf_archive
There we have 2GB of storage. Check this by writing a file to the USB drive and ensuring it is there. Also from the USB directory the df command can always be used to verify that the mount is working properly. When it fails it is possible to wind up in the proper directory which is merely a sub-directory on the SD card.
The mount process can be done using an alias, e.g. defined in /root/.bashrc. However this alias should not be assumed 'available' to programs that wish to access the USB drive. Correct is to create a script in /root/bin or use a system("mount ...") call (C programs) or equivalent.
Advanced configuration
This section is reserved for the following topics (and more as the arise...)
- Installing a mote serial forwarder
- Installing a serial port data accumulator
- Installing cron job machinery to routinely push data and pull operational updates
- Installign Alert machinery to determine if an Alert condition exists based on sensory input (low power, data readings, etc)
- Installing MACRO machinery
Other procedures
These procedures catch ancillary and non-critical aspects of Microserver operation. This includes power conservation measures, console re-direct to free up COM1 for GPS use, and so on.
Other procedures 1: Redirect console to COM2
To root-pivot on boot to the SD card with COM2 as the dedicated console requires three steps. First: Return to the boot_script_data table configuration described above and use 'ttyAM1' instead of 'ttyAM0' as noted. Second, as done above in the SBC configuration steps, an entry must be created for ttyAM1 in the /etc/securetty file. The third step, actually optional, is to configure the J2 and J4 jumpers on the SBC board. This will require removing the PCS board from above the SBC to easily access JP2 and JP4.
The JP2/JP4 jumpers determine where the initial RedBoot> interaction goes (COM1 or COM2) and the subsequent entry into the boot_script_data table from the RedBoot> prompt determines where the rest of the boot message (for the Debian Linux kernel) goes. The latter includes the login prompt that was used above to reach into the SD card file system and do all of that configuration.
Jumpers are little two-pin headers coming off a printed circuit board. To 'jump' them means to attach a little plastic rectangle with metal inside that shorts the two pins together. Jump J2 and J4 if you wish to direct the initial boot message (including RedBoot> access) to COM2. Jump J2 only to use COM1. For more information see the TS-7260 technical manuals (and a few notes follow in the hardware notes below).
Other procedures 2: Turning On/Off the USB, Ethernet, clocking down the processor
Other procedures 3: Loading new modules
The directory /lib/modules contains subdirectories which contain all the modules. (Modules are utility programs that do stuff like mount the CF drive.) The subdirectory name corresponds to the current version of the kernel which in turn can be seen by issuing the 'uname -r' command.
root@ts7000:root# uname -r 2.4.26-ts11 root@ts7000:root# ls /lib/modules 2.4.26-ts10/
Note the mismatch. We must find the appropriate 2.4.26-ts11 directory and install it in /lib/modules. This file is available from Technologic Systems and can be placed in the ftp directory of the Ethernet-connected host. Why not the tftp directory? Because in order to install this directory on /lib/modules which is located on the SD card we have to boot the new Linux kernel where we have ftp but not necessarily tftp available.
ftp 192.168.1.52 ftp> (log in) ftp> bin ftp> get 2.4.26-ts11.tar ftp> quit
Now move the tar-file to /lib/modules and unpack it
# mv 2.4.26-ts11.tar /lib/modules # cd /lib/modules # tar -xvf 2.4.26-ts11.tar <verbose output> # rm 2.4.26-ts11.tar # shutdown -r now
And now after rebooting the system should have no trouble seeing the CF drive, fixing the fiasco that precipitated this whole update rigamarole.
Here are some follow-on module notes of interest:
- Ensure that root owns the /lib/modules/2.4.26-ts11 directory recursively.
# chown -R root:root /lib/modules
- Just as above with 'updown' running on login, the same method can be used to auto-mount a USB drive
- The /etc/init.d/usbMount file might need to load all the necessary modules, e.g.:
#!/bin/sh # cf_archive_mount start some modules to enable CF-USB drive insmod usbcore insmod pcipool insmod usb-ohci insmod usb-ohci-ep93xx insmod scsi_mod insmod sd_mod insmod usb-storage insmod fat insmod vfat
From the Linux-Arm-Guide: "Generally, all the log files of the Linux OS are stored on the /var/log/ directory. Therefore, important system messages such as the kernel boot or some applications (HTTP server) outputs can be viewed by inspecting the log files."
Other procedures 4: Shell customization
This section incomplete. Note there is this potentially useful bash construction:
if [-f /etc/bashrc ]; then
. /etc/bashrc
fi
Other procedures 5: SD Card replication
To make multiple copies of the SD image for use on other SBCs: We use (on Ubuntu Linux, using "sudo" (super user do))
% sudo copy -rfp SOURCE_DRIVE DESTINATION_DRIVE
Software Configuration
Logan 14:17, 5 June 2008 (PDT) Bricks 53, 54, and 55 have been configured in the following manners:
- Set bricks to be on UAS network (137.229.208.XXX).
>> pico /etc/networking/interfaces address 137.229.208.XXX network 137.229.208.0 netmask 255.255.255.0 gateway 137.229.208.1
- Edit /etc/resolv.conf so that Domain Name Service (DNS) is setup to convert domain names to IP addresses.
>> pico /etc/resolv.conf search jun.alaska.edu nameserver 137.229.196.94 nameserver 137.229.10.39 nameserver 137.229.253.183
- Update the general software package on the bricks
>> apt-get update
- Install 'python' (br54 already had python)
>> apt-get install python
- Install 'less'
>> apt-get install less
- Install ssh
>> apt-get install ssh
- Install 'rsync', edit sshd.conf file so 'PasswordAuthentication' is 'no', then kill and restart process.
>> apt-get install rsync >> pico /etc/ssh/sshd.conf >> ps auxww | grep sshd >> kill -9 (sshd PID determined from last command) >> which sshd >> /usr/sbin/sshd
- Edited crontab from SVN so that housekeeping runs every day at 0:00 and so that uS data router runs every four hours.
- Copy 'brickmove' folder from SEAMONSTER to bricks (includes crontab, housekeeping, and uS data routing scripts)
>> rsync -rav brickmove root@brick-IP:/root/
- Change the hostname of each brick to brick53, brick54, or brick55, then restart.
>> pico /etc/hostname >> pico /etc/hosts on first line: brickIP brick##>>> (ex: 192.168.1.55 brick55) >> shutdown -r now
- Setup keyless ssh and rsync. Generate keys if necessary (as per above), rename keys, move keys to remote machine, generate 'authorized_keys' file, add keys to 'authorized_keys' file, test, do all of this again but this time sending the remote keys to the local machine. If everything has been done properly the rsync at the last step should not prompt you for a password, nor should future ssh or scp.
user@local:/user/.ssh/ >> cp id_rsa.pub id_rsa_##.pub (where ## = bricks #)
user@local:/user/.ssh/ >> scp id_rsa_##.pub user@remoteIP:/home/user/.ssh/ ('/home/seamonster/.ssh/ was used for the server and '/root/.ssh/' was used for the bricks)
user@local:/user/.ssh/ >> ssh user@remoteIP
user@remote >> cd /home/user/.ssh/
user@remote:/home/user/.ssh/ >> echo > authorized_keys
user@remote:/home/user/.ssh/ >> cat id_rsa_##.pub >> authorized_keys
user@remote:/home/user/.ssh/ >> rsync -rav test_file user@localIP
- Setup Br53 to power a 12V Linksys WRT54G router and amp upon boot instead of a WET54G bridge and amp. This involves modifying the 'updown' script.
root@brick53:/home/brick/src >> pico updown Under the -----2----- section, edit the 'ucInterface 2 6' string to read 'ucInterface 2 132' root@brick53:/home/brick/src >> make updown root@brick53:/home/brick/src >> cd ../bin root@brick53:/home/brick/bin >> mv updown /root/bin root@brick53:~/ >> shutdown -r now Check that the voltage of JP7 on the PCS shoots up to 12V after a little after the unit has restarted.
Hardware Notes
- The standoffs above the WiFi bridge enclosure may be loose enough to provide some "fitting" play, in order to get the SBC and PCS boards in place.
- It is a good idea to ensure that the SD card is seated prior to installing the SBC.
- Jumpers on the TS-7260 SBC
- JP1 Recovery mechanism: Forces boot to Serial Port COM1. Leave open.
- JP2 Enable Serial Console. COM1 is used as the Console if JP4 is not installed. Leave jumped.
- JP3 Write Enable Flash: Remove this jumper to write protect the Flash drive. (Leave jumped; could remove for field operation.)
- JP4 Console swapped to COM2 (Requires JP2 installed.)
- JP5 Test Jumper for factory-test mode. (Leave open.)
- JP6 User Jumper. (Leave open.)
What we did to configure
This is a procedural log that goes along with what is above (but does not take its place!):
- Edited the /etc/securetty to include ttyAM1 so COM2 can be used as a console.
- Modified the /etc/network/interfaces eth0 entry to make this board 192.168.1.138
- Created /home/brick/bin, /src, /uploads, /downloads
- Set up an Ethernet connection in order to import files
- Imported the source files and makefile (updown, bc, ucInterface, bridgeOn, bridgeOff, etc)
- Made a sym-link from /etc/rc2.d/S99updown to /etc/init.d/updown.
- Created /etc/init.d/updown to run /root/bin/updown on boot and did a chmod a+x /etc/init.d/updown
- Moved across: adc, bc, bridgeOff, bridgeOn, cMonitor, checksum, dio, gps, makefile, milo, portfix, ucInterface, updown
- Modified updown to keep the bridge ON for one hour (60 --> 3600 seconds of sleep)
- made all of the above to /home/brick/src/
- moved all of these to /root/bin and did chown root:root *; all files are executable.
- Got the WiFi Bridge configured
- Get the SBC / PCS stack in place with the DIO and LCD ribbon cables on
- Made sure all power connections were ok
- Booted with a good Bridge+Amp power up
