A - A - A

Installing for the LART

 
Search

Power and Serial Connections

Refer to the diagram and picture to familiarise yourself with the device. The view showing the StrongARM CPU and large inductors is the 'top' of the board throughout this document.

Power is supplied to the four pin connector in the top right. The supplied power lead is wired such that it doesn't matter which way round you plug it in - polarity will be correct. (The two central pins are +ve, the two outer -ve). The red LED next to the crystals in the lower left hand corner should glow when power is applied. At 5V, initial start-up current for a lone LART is ~160mA, dropping to ~80mA after a few seconds. Note that the supply voltage is between 4V and 10V. Some documents (including the LART website at the time of writing) give an upper limit of 16V but this will damage your LART! The LT1266 can take 20V nominal, but the design uses voltage doubling so the input voltage must remain below 10V unless the PSU is changed around (which can be quite easily done)

The serial connection is the 2x3 header. This supplies two simple serial ports (ground, data out, data in). The supplied cable should be plugged in so that the lip on the blue 2x3 connector points downwards. The white 9-pin-D connector is serial port 1; the blue 9-pin-D connector is serial port 2. Plug the white connector into your host computer.

If you need to re-flash the blob loader then you need to attach the JTAG dongle to the 1x8 header. The JTAG board should be attached so that the components on it are on top - i.e. components are on the same side as the StrongARM CPU on the LART.

Using JTAG and JFlash-linux

It is possible to program flash memory through the SA-1100 JTAG interface. A utility to do this is provided. Aleph One supplied LARTs will already have had this done so you can skip to the next section.

In order to use the JTAG programmer, take the following steps:

  • connect the parallel cable to your computer's printer port;

  • connect the JTAG dongle to the cable;

  • connect the other end of the JTAG dongle to the LART, with the JTAG component side the same way up as the LART main board;

  • turn the LART on.

You can then issue the following command as root:

./Jflash-linux blob-1.0.7b

and you should see something like the following after which the LART will reset itself before running blob.

using printer port at 378
Seems to be a pair of 28F160F3, bottom boot. Good.

Starting erase for da5 bytes
Erasing block 0
Erasing done
Starting programming
Writing flash at hex address 1b0, 12.37% done
Writing flash at hex address 3d0, 27.94% done
....
Programming done
Starting verify
Verifying flash at hex address 4e0, 35.73% done
....
Verification successful!

LART JTAG reset problem

Output like this is typical of the 'JTAG reset problem':

error, failed to read device ID
ACT: 0000 0000000000000000 00000000000 0
EXP: X001 0001000010000100 00000110101 1

failed to read device ID for the SA-1100

This is solved by putting a 100 OHM resistor between pins 6 (+3.3V) and 7 (nTRST) on the JTAG connector. nTRST will thereby be pulled to +3.3V so the JTAG bus won't be able to reset itself. This modification is already done on Aleph One supplied JTAG boards as they don't work without it. You can make other modifications to have the same effect (eg connect the JTAG reset pin to the MAX811 reset chip on the LART).

Serial Monitor

The only means of communicating with a bare LART is via its serial port. You should run a suitable piece of terminal software on your host. For a GNU/Linux host we recommend Minicom, which is very capable and easy to use.

Configuring Minicom

In order to configure Minicom, take the following steps:

  1. Run it with minicom -o to get to setup.

  2. Set it to VT102, serial port ttyS0 (or ttyS1 if you are using that port) 9600baud 8N1 (8 data bits, No parity, 1 stop bit), no modem init string, no hardware handshaking.

  3. Save that as lart config. Running Minicom as minicom lart will run it up with these options.

  4. If you don't use Minicom for anything else then you can make these settings the overall default - Minicom calls it dfl - settings.

If you aren't sure which serial port you are using for the device, but your mouse or modem is in the other one then look at these thing to determine where the mouse or modem are plugged in:

  • /etc/gpm.conf will show what device gpm is using as your mouse

  • ls -l /dev/mouse is normally a link to the serial port your mouse is plugged into if you have a serial mouse

  • ls -l /dev/modem will give the same info for your modem.

If you don't have anything in either port then just try both with the following boot proceedure.

Starting up

OK, now we're ready to go.

The reset pins are at the bottom left of the board, and a jumper is supplied to do a reset. The board will remain in reset as long as the two pins are connected. You may wish to attach a switch to these pins if you are resetting a lot!

On reset you should then see (from within your serial monitor) something like:

Consider yourself LARTed!
Running from internal Flash.
Starting the memory tester...
Zeroing memory...0xD0000000
Zeroing done. Testing for aliases...
Loading kernel from flash ....... done
Loading ramdisk from flash ............... done

Note: It always says Loading kernel/ramdisk whether or not a kernel and RAMdisk are actually present. It will just hang if it tries to boot a 'blank' kernel.

Blob version 1.0.8-pre2, 
Copyright (C) 1999 2000 Jan-Derk Bakker and Erik Mouw
Copyright (C) 2000 Johan Pouwelse
Blob comes with ABSOLUTELY NO WARRANTY; read the GNU GPL for details.
This is free software, and you are welcome to redistribute it
under certain conditions; read the GNU GPL for details.

Autoboot in progress, press Enter to stop ...

Now press Enter within 10 seconds, otherwise it will go on to try and boot a kernel it doesn't yet have and will just hang. This should get you a blob prompt:

Autoboot aborted
Type "help" to get a list of commands
blob>

Getting a kernel and RAMdisk

There are several pre-compiled kernels available on the CD and on-line. When you want to compile your own refer to the section called Compiling a Kernel in Chapter 7. The correct default config setting for LART is: make lart_config.

Uploading a kernel and RAMdisk

In order to upload kernels via the serial port to blob you need to put them in the correct format. Blob expects uucoded files. uuencode's syntax is:

uuencode {input filename} {name in uucoded file}>
output filename

so you uucode a kernel called zImage-2.4.1-rmk1-np2 like this:

uuencode zImage-2.4.1-rmk1-np2 zImage > zImage-2.4.1-rmk1-np2.uu

At the blob prompt enter 'download kernel' to upload a kernel. Blob will respond with:

Switching to 115200 baud
you have 60 seconds to switch your terminal emulator to the same speed and
start downloading. After that blob will switch back to 9600 baud.

Switch to 115200 like it tells you (otherwise the upload would take hours). If using Minicom this is done by ALT-O, select 'Serial port setup', then E for 'Bps/Par/Bits', I for '115200'. Then Enter,Enter,Escape to get back to the prompt.

You ought to be able to use Minicom's 'ASCII upload' at this stage, but it doesn't seem to work reliably with no flow control, so we recommend you use a second virtual terminal and do:

cat zImage-2.4.1-rmk1-np2.uu > /dev/ttyS0

which simply copies the uucoded kernel to your serial port. Switch back the Minicom virtual termainl and you should see a line of dots printed as the kernel loads.

Once the upload is complete blob will print something like:

(Please switch your terminal back to 9600 baud)
Received 509300 (0x0007C574) bytes

Switch your terminal back as directed and hit return to get a blob prompt. You can check the size of the uploaded kernel by typing 'status'.

Now you need to do the same proceedure again to upload a RAMdisk. The only difference is that the blob command is 'download ramdisk' instead, and obviously you use the filename for the (uucoded) RAMdisk.

Blob has the facility to save uploaded kernels and RAMdisks into its flash RAM. However at the time of writing it is not capable of writing to the flash it is itself running from so this function only works if you have a separate bit of flash memory containing blob to plug in. It needs modifying to be able to copy itself to SRAM first and then execute from there.

Which kernel/RAMdisk to use?

There are several kernels and RAMdisks supplied on the CD, and these will be updated along with the releases. We have found that a good set of software to use at the time of writing is: blob v1.0.7b, zImage-2.4.0-rmk5-np2, and either ramdisk-lart-glibc-2.1.2.gz (for a basic RAMdisk), or ramdisk-2.4.0-rmk5-np2.gz for a bigger one including an mp3 file (which needs a KSB to play).

Booting the kernel

So finally we are ready to go. At the blob prompt enter 'boot'. It says

Starting kernel...
then if all has gone well you should see
Uncompressing Linux........
and the kernel will boot. daa-daa!

Resources

A number of useful schematics for the mainboard, kitchen sink, ethernet board and JTAG programmer are available in PDF format on the CD and from the LART website. On the CD they are all in LART/Hardware/ and only the schematics for the version of hardware in production are present. If you want to see the older schematics then you'll need to go to the website.

Mainboard

LART Revision 4 mainboard schematic

CD: /hardware/LART/Lart-rev-4.pdf.

Web: Lart-rev-4.pdf.

LART Revision 3 mainboard schematic

Lart-rev-3.pdf

Kitchen Sink Board (KSB)

CPLD U9 Revision 2

ksb_rev2.U9.pdf

CLPD U1 Revision 2

ksb_rev2_u1.pdf

Kitchen Sink Board Revision 2

ksb_rev2_u1.pdf

Ethernet Board

Ethernet Card, four channel, revision 1

ether4_rev1.pdf

Ethernet Card, single channel, revision 1

ether1_rev1.pdf

JTAG

JTAG dongle schematics

jtag-lart_schematic.pdf

JTAG dongle Bill-of-materials

jtag-lart_Rev_X1_BOM.txt

JTAG dongle hardware distribution with gerber files

jtag-lart_Rev_X1.tar.gz

Jflash

jflash-linux.tar.gz