Hi Jesse--
--- In Jesse Off <> wrote:
>
> Hey all, been working on some draft documentation for the TS-7500 and
> thought I'd share. Not yet complete (or even proofread!), but better
> than nothing.
>
> This file is also available temporarily at
> ftp://ftp.embeddedARM.com/misc/ts7500-info.txt
>
> Give me a call if you have any specific comments or questions,
> 480-837-5200 We'll try to get something on the web here shortly!
>
> //Jesse Off
Just a few quick comments, I haven't read through in detail yet.
> ------
> The TS-7500 was released Jul. 2009 is a small embedded board with
> a CNS2132 250Mhz ARM9 CPU, Lattice XP2 5k FPGA, 64MB DDR SDRAM,
> and 4MByte SPI NOR flash chip.
>
> Hardware features include:
> *) 250Mhz Cavium ARM9 CPU core (Faraday 526)
Is there a developers manual available for this chip from Cavium?
> *) 64MByte 16-bit wide DDR SDRAM running at 125Mhz
> *) micro SD slot
> *) 4MByte SPI NOR flash chip
> *) DIO pins on the 40 pin header
> *) 2 USB 2.0 High speed (480 Mb/s) Host ports
> *) 1 USB 2.0 slave port
> *) 1 TTL serial console port (16550) on CPU
> *) 8 XUART TTL serial ports on FPGA
> *) Hardware watchdog on FPGA
> *) Optional battery backed real time clock
> *) 10/100 Mbit on-CPU ethernet
> *) Low power (395mA @ 5V or 2.0 Watt)
> *) rugged 40 pin .1" header expansion connector
> *) Fanless/heatsink-less operation up to 80C temperatures
>
> Software features include:
> *) Boots 2.6.24 Linux out-of-the-box in 2.65 seconds (to shell prompt)
Just curious, why you settled on 2.6.24, released Jan-08? Haven't looked yet,
but I guess this is all EABI? If so, you could add that as a feature in your
marketing (something most ARM developers are aware of now).
> The standard Linux environment is provided by busybox, and the
> compiled instance of busybox includes several internal commands
> listed below:
>
> # /bin/busybox --help
> BusyBox v1.14.2 (2009-08-07 14:43:48 MST) multi-call binary
> Copyright (C) 1998-2008 Erik Andersen, Rob Landley, Denys Vlasenko
> and others. Licensed under GPLv2.
Great to see this up to date! We can benefit from the hard work BB team &
community have been putting in.
> Also on the initrd are the TS-7500 specific applications: ts7500ctl,
> sdctl, spiflashctl, and xuartctl.
I found these binaries on the FTP site. Any plans to release the sources also?
They seem to be core requirements for running this card well. When the
inevitable bugs are found by customers beating on them, the TS-7500 community
could participate in solving them, rather than putting the onus back onto an
over-burdened TS support team.
> # xuartctl --help
> Usage: xuartctl [OPTION] ...
> xuartctl --port=PORT [OPTION] ... -- [COMMAND] [ARGS]
> Technologic Systems XUART core userspace driver utility.
> Example: xuartctl --server
> xuartctl --port=192.168.0.50:7350 --speed=9600 -- /bin/sh -i
> xuartctl --port=0 --test
>
> -i, --irq=N Use IRQ N as XUART IRQ (32)
> -r, --regstart=ADD Use ADD address as regstart (0x600ff100)
> -m, --memstart=ADD Use ADD address as memstart (0x60000000)
> -s, --speed=BAUD Use BAUD as default baudrate (115200)
> -o, --mode=MODE Use MODE as default mode (8n1)
> -d, --server Daemonize and run as server
> -p, --port=PORT Connect to local or remote XUART port
> -t, --test Run loopback and latency test
> -h, --help This help
>
> When run as a server, default is to listen at TCP port numbers starting at
> 7350 with 1 port per XUART channel.
>
> PORT option can be a either a number 0-7, or a HOSTNAME:TCPPORT for a
> remote TCP socket. When both --port and --server are used, a pseudo-tty
> is allocated and connected to the XUART channel and pseudo-tty processing
> continues in the background. When only --port is specified and no command
> is given, stdin and stdout are connected to the XUART channel, otherwise
> COMMAND is run as a sub-program with its stdin/stdout/stderr connected to
> the allocated pseudo-tty.
I need to do some reading & thinking on what's going on here ... in terms of
mixing UART and TCP. I tend to compartmentalize: UART == serial, TCP/IP ==
telnet, ssh, etc.
>
> # spiflashctl --help
> Usage: spiflashctl [OPTION] ...
> Technologic Systems SPI flash manipulation.
> # sdctl --help
> Usage: sdctl [OPTION] ...
> Technologic Systems SD core manipulation.
>
> General options:
> -R, --read=N Read N blocks of SD to stdout
> -W, --write=N Write N blocks to SD
> -x, --writeset=BYTE Write BYTE as value (default 0)
> -i, --writeimg=FILE Use FILE as file to write to SD
> -t, --writetest Run write speed test
> -r, --readtest Run read speed test
> -n, --random=SEED Do random seeks for tests
> -o, --noparking Disable write parking optimization
> -z, --blocksize=SZ Use SZ bytes each sdread/sdwrite call
> -E, --erasehint=SZ Use SZ bytes as erase hint
> -b, --sdboottoken=TOK Use TOK as the boot token (to quicken init)
> -a, --address=ADD Use ADD address instead of 0x13000000
> -k, --seek=SECTOR Seek to 512b sector number SECTOR
> -l, --lun=N Use N as numbered card slot (default 0)
> -S, --scanluns Scan all LUNs for cards
> -m, --nodma Don't use DMA
> -d, --nbdserver=NBDSPEC Run NBD userspace block driver server
> -h, --help This help
>
> Security/SD lock options:
> -p, --password=PASS Use PASS as password
> -c, --clear Remove password lock
> -s, --set Set password lock
> -u, --unlock Unlock temporarily
> -e, --erase Erase entire device (clears password)
> -w, --wprot Enable permanent write protect
>
> When running a NBD server, NBDSPEC is a comma separated list of
> devices and partitions for the NBD servers starting at port 7500.
> e.g. "lun0:part1,lun1:disc" corresponds to 2 NBD servers, one at port
> 7500 serving the first partition of SD lun 0, and the other at TCP
> port 7501 serving the whole disc device of SD lun #1.
Again, I need to do more reading on NBD and how you are using it. But it seems
to be quite a durable & useful interface. It continues to refined on the
kernel side, ie, a big warning on nbd.sf.net is not to use it as a client &
server on one machine, but this is solved by:
http://lwn.net/Articles/267685/ I'm not sure if that made it into your 2.6.24
kernel.
>TS-7500 specific Linux devices:
> ===============================
>
> The TS-7500 kernel is built from the same 2.6.24 Linux sources
> Cavium Networks has tested and used on their CPU evaluation boards.
Ah, OK that's how the 2.6.24 version was chosen.
> There are no Technologic Systems TS-7500 specific drivers or kernel
> support implemented. Instead, there has been userspace driver
Maybe it would be easier for you to distribute a patch set against 2.6.24,
rather than a full-size tarball.
> support implemented for the SPI NOR flash, micro SD cards,
> battery-backed real-time clock, XUART serial port channels, watchdog,
> and GPIO pins. This allows easy migration to newer 2.6 kernels
> when either Cavium or the mainline Linux kernel community creates
> them. In the past, constant Linux-internal API redesign required
> rewriting and revisiting custom drivers with each new kernel
> revision, in effect locking customers in to whatever kernel version
> was released and tested during initial product release. Being free
> to update to newer kernels in the future allows easier support of
> the new USB devices as those drivers tend to only be developed for
> the newest kernel sources.
Interesting approach, time will tell it's effectiveness. You gain some
independence, but loose in other ways. For example, sounds like there is no
rtc device driver?
> Both the SPI flash and SD card can be plugged into Linux's block
> driver subsystem via the kernel to userspace gateway driver "NBD".
> NBD stands for Network Block Driver and can actually be used to
> export the SD or SPI flash over the network to another Linux machine,
> but the way the startup scripts use the mechanism by default is to
> connect the SD flash via localhost to device nodes /dev/nbdX where
> X is the number referring to the actual NBD instance. The TS
> provided utilities "sdctl" or "spiflashctl" have --nbdserver options
> specially enabling the NBD style attachments to the internal Linux
> block layer. The default INITRD linuxrc startup script auto
Seems you should look into the patch above (unless it's in 2.6.24) to keep nbd
from locking up under memory pressure.
attached
> /dev/nbd0 through /dev/nbd4 as follows:
>
> /dev/nbd0 - whole disk device of microSD card
I see a recent patch for partitions on nbd:
http://lwn.net/Articles/276044/
This was incorporated into the kernel, and makes partition handling a little
easier.
> /dev/nbd1 - 1st partition of SD card (Windows VFAT filesystem on devkit
> card)
> /dev/nbd2 - 2nd partition of SD card (kernel partition on devkit card)
> /dev/nbd3 - 3rd partition of SD card (EXT2 initrd partition on devkit card)
> /dev/nbd4 - 4th partition of SD card (Debian EXT3 filesystem on devkit card)
With the above patch, these would become /dev/ndb0p1, /dev/nbd0p2, etc.
<snip many more lowlevel details>
Thanks for trying to get these low-level details out in a timely manner. From
the POV of a potential customer seeing your ad, and interested by the FPGA, he
might have two questions:
* Does TS release the default load of the FPGA, so I can experiment & learn a
new skill by adding my own functions?
* If not, what functions of the card will I lose if I try to develop on the
FPGA myself?
regards, ........... Charlie
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|