The LART is a small yet powerful embedded computer capable of running Linux. Its performance is around 250 MIPS while consuming less than 1 Watt of power. In a standard configuration it holds 32MB DRAM and 4MB Flash ROM, which is sufficient for a Linux kernel and a sizeable ramdisk image.

What does LART stand for?

LART stands for Linux Advanced Radio Terminal. That's what we officially call it anyway; as with all four-letter acronyms, it is just possible that LART is overloaded.

Can I run any other OS on the LART than Linux?

LART should be able to support any OS that has an ARM port and doesn't require special hardware gadgets. Operating systems like NetBSD, pSOS and Inferno are some examples; see http://www.arm.com/ and http://developer.intel.com/design/strong/ for a more complete overview. It's even possible to port WinCE, although we can't imagine why anyone would want to.

Do you sell LARTs?

We are very sorry, but we don't sell LARTs. We are a university, and the LART is just a research tool. We have no plans (read: no time) to make the LART commercially available ourselves. However, all CAD files are available, so if you would like to produce LARTs yourself (and possibly sell them), feel free. If you do decide to produce LARTs commercially, drop us a line so we can link to you.

Update: A number of excess LART boards are available through Remote12. Check the news page for more information.

What are the licensing conditions for LART?

All CAD files required for building LART are available under the closest we could get to an Open/Free Hardware License (see the LICENSE file). All software and kernel patches are released under the GNU GPL.

What is the difference between LART and PLEB?

Executive summary:

if you want the smallest size and weight, go for Photon/PLEB;
if you want the lowest power, maximum number of add-ons or a modular design that will keep being updated for at least two more years, go for the LART.

Here is The Long Story^TM.

When are you going to release the Gerber files for the XXXX board?

As soon as we're confident that it works. We use the following release cycle:

Design the board.
Design a PCB layout.
Build up a prototype.
Electrically test the prototype. If it doesn't burn, release the schematics.
Test the individual parts of the board by writing a linux driver for it. If it doesn't break, release the Gerber files.

Why can't I burn the kernel/ramdisk to flash in blob?

Complicated story. The problem is that you can't burn the flash while running code from that flash at the same time. The LART team solves this by having an external flash board that is mapped at address 0x00000000 and at the same time remaps the internal flash at 0x08000000 (hence the names internal and external flash in blob). Of course this is just a kludge, blob just has to relocate itself to RAM. However, this is something that we haven't been able to do, compiling with -fPIC is not enough. We're still working on it.

However, there is a workaround: burn the flash from Linux. You need a recent Linux kernel (2.4.0-test4-np1 or newer) with the flash_mem module compiled. Here's how:

Burn blob in the flash.
Power up the board.
Download kernel.
Download ramdisk.
Boot linux.
Log in as root.
Switch to 115200 baud (stty ispeed 115200 does the trick).
Download flash_mem module and insmod it into the kernel
Make flash drivers: mknod /dev/flashX b 60 X, where X is the flash partition number. Look in linux/drivers/block/flash_mem.h for the definitions for your platform.
Download the kernel (using zmodem in Minicom).
Write the kernel to flash: dd if=zImage of=/dev/flashX
Repeat last two steps for the ramdisk

It is possible that you have to make room for the ramdisk image, possibly by creating a second ramdisk.

Update: The ARM flash_mem module is no longer supported, use the SA1100 MTD Flash driver instead.

I have a general question about XXXX, should I ask the individual developers?

Please don't, the LART core team is already swamped in email. General questions should be asked on mailing lists, simply because using a mailing list improves your chances of getting an answer. Here is a small list to select which mailing list to use. Questions about:

LART in general: LART mailing list
Blob: LART mailing list
the ARM linux kernel: linux-arm-kernel mailing list
all ARM linux issues except the kernel: linux-arm mailing list
all SA1100 or SA1110 issues: sa1100-linux mailing list
the linux kernel in general: linux-kernel mailing list

If you ask a question on one of these lists, don't CC to a member of the LART core team; there is at least one member of the core team subscribed to each of the above mailing lists. Also avoid cross posting between several mailing lists, unless you really know what you are doing. And please read the mailing list archives before you post, your question might already be answered and considered a FAQ.

I sent an email message to one of the LART core team members but I didn't get a reply. Isn't that rude?

Maybe. The LART core team gets quite a lot of LART related email, and in order to get something done, we don't reply to all messages. Especially if your question is a FAQ or if it could have been asked on a mailing list (see question 9), your chances of getting a reply are very low.

26 Oct 2005