We have developed code for an inexpensive embedded processor to run 10 BaseT ethernet to VME communications for our CSC electronic card slow control. The processor chosen was a Dynatem D360 (specs below) which sells for less than 800 dollars in quantity.
D360 68360 Based 3U VMEbus Communications Controller Card
We have recently ported a stripped down version of linux to the Dynatem D-360 crate computer. uClinux is a derivative of Linux 2.0 kernel intended for microcontrollers without Memory Management Units (MMUs). A gnu gcc cross compiler exists for our machine so basically anything you can do in normal linux you can do on the dynatem machine.
For a user the D-360 feels much like a normal linux machine. The linux login and directories are stripped down versions of the normal linux root directories. The console/keyboard is driven through a serial port on the D-360 connected to a V220 terminal or any V220 emmulator (e.g. hyperterm on a windows PC). Alternately one can ftp into the machine.
We have NSF mounted a hard drive. The operating system takes up about 1Meg of our 4Meg memory. One can compile programs on this hard drive from a PC and run them from the uClinux prompt on the D-360. The compiler is just the normal gnu gcc compiler set up for a Motorolla CPU32 machine. We have effortlessly compiled several programs and run them on this machine.
The machine can boot either from SROM (1 Meg) or EPROM (1 Meg). You turn the machine on and it boots in about 8 seconds.
Since this is linux for MMUs there are a few caveats. Certain multitasking can be tricky. The program fork() is replaced with vfork(). A fork will take place but the main program will wait for the forked program to return before continuing. We don't believe this is a problem since we intend this mainly as a communications machine.
The Dynatem D360 presently talks to our XLINX VME-JTAG interface chip. The processor plus chip was able to program FE XLINX FPGA's at a continuous rate of
A LINUX socket program which communicates with the D360. It is set up for JTAG control but is easily modified. We should all try to use these processor when testing slow control communications.
Since there are no direct mounted disks on the D-360, one has a choice of ROM disks or NFS mounted disks. We have chosen to mount /bin, /dev, /etc as a ROM disk for speed considerations. This eats up about 500k of 1Meg FLASH (SRAM) space. It we get tight for kernel space we can NFS mount these root files and regain this 500k of FLASH.
Basically you order the computer (email us for details...configuration options). For now it is probably best you let us set up the machine. This is an embedded system so from you we need:
NFS mount information:
(Information is above stored in ROM file /etc/rc)
The gnu cross compiler (run on a linux pc to produce 68360 code) can be obtained at this site. It is basically the gcc compiler (version latter than 2.7.0) configured for the Motorolla CPU32 or 68332 processors. Once the compiler is working from the PC you compile the program on the D-360 NSF mounted disk. The program is then run from the D-360 linux prompt. There are a few subtle tricks (e.g. 1) getting LIBC for the 68332, 2) converting COFF to binary files) which we can help you with. One can get it running in less than an hour.
The operating system uClinux was ported to the Motorola 68360 in 1999 by Michael Leslie of Lineo corporation. The original kernel code can be found at this site. It took several weeks of hacking to get this code to run on the Dynatem D-360. We will give CMS muon members a copy of the hacked kernel code in a tar file if requested.
There is little reason for anyone to get into modifying the kernel. Here things can be quite a bit messier than Linux compiling on a PC. Details of the M68360 processor are a must. If you decide to venture forth though you first need a debugger that connects to the Motorolla CPU's debugger port. This allow you to process c-code and assembler code step by step to observe the CPU's internal registers. Fortunately a very good debugger is available free, based on the gnu GDB debugger. You need to buy an interface cable but these can be easily made or purchased (ask us).
There are two methods to permanently store the operating system so that it automatically boots on power up. One can burn a 1 Meg EPROM. A far superior method is to burn it into the 1 Meg D-360 Flash Rom. We have made the choice to burn the SROM by running a program directly on the D-360. We will provide these programs to those who wish to reburn their ROMFS or FLASH memory.
The D-360 has two onboard features which have not been added to
the Kernel so at present don't work. The D-360 has a sophisticated real time clock (
Additionally the D-360 has the ability for a VME write directly into Dual Port Ram. VME can also set an interupt (once again IRQ3). Once again we have not written an interrupt handler for these options.
If anyone wants to use any of these options please let us know. It is probably a weeks worth of work to modify the linux kernel to support either of these special options.
Chang has written a line by line explaination of all of the above. It is quite detailed and you need some unix/imbedded system information to follow it (see ucLinux how to ).
Send Chang EMAIL