Technical Details

Hydra Board

CPU - MC68EN302

• MC68302 - User's Manual
  The MC68302 integrates an M68000 processor with multiple communications peripherals. It consists of an M68000 microprocessor core, a system integration block(SIB), and a communication processor(CP). SIB includes interrupt controller, DMA controller, parallel I/O ports, timers, on-chip dual port RAM, system control blocks, and so on. CP includes main controller(RISC), 3 independent full-duplex serial communications controllers. And, it supports various protocols such as HDLC/SDLC, UART, BISYNC, DDCMP, etc.
  
  
• MC68EN302 - User's Manual
  The MC68EN302 is based on MC68302 with an Ethernet controller, a DRAM controller, and a JTAG interface. The Ethernet controller supports up to 10 Mbps data rates.

About the Kernel

More About the Kernel

MEMORY
        {
        flash  : ORIGIN = 0xc00000, LENGTH = 0x100000
        ram    : ORIGIN = 0x400, LENGTH = 0x800000 - 0x400
        eram   : ORIGIN = 0x800000, LENGTH = 1
        }

SECTIONS
{
        .text :
        {
        text_start = . ;
        *(.text)
        _etext = . ;
        __data_rom_start = ALIGN ( 4 ) ;
        } > flash
        .data :
        {
        __data_start = . ;
        *(.data)
        _edata = . ;
        edata = ALIGN( 0x10 ) ;
        } > ram
        .bss :
        {
        __bss_start = ALIGN( 0x10 ) ;
        __data_end = ALIGN( 0x10 ) ;
        *(.bss)
        *(COMMON)
        __bss_end = . ;
        end = ALIGN( 0x10 ) ;
        _end = ALIGN( 0x10 ) ;
        } > ram
        .eram :
        {
        _ramend = . ;
        } > eram
}

• RX, TX buffers
  Data associated with each SCC channel is stored in buffers. Each buffer is referenced by a buffer descriptor(BD). BDs are located in each SCC channel's BD table. Each BD table contains 8 BDs. Each BD has status field, data length field, and a pointer to the actual buffer.

  If the trasmission is enabled, the CP(Communication Processor) starts with the first BD in the BD tabe, periodically checking the `ready' bit. Once it is ready, it will process that BD, reading data from its buffer, doing some protocol processing and moving the resultant data to the transmit FIFO.

  When data arrives from the serial line, the CP performs certain required protocol processing on the data and moves the resultant data to the buffer pointed bu the first BD. When the next data arrives, the next BD is used for storing data.

  In the Hydra, only one BD is used for RX and TX each for simplicity. The address of the RX BD is 0xfff400, and the RX buffer is 0xfff180. And, the address of the TX BD is 0xfff440, and the TX buffer is 0xfff000. One buffer is good enough(up to 38400bps), and we've never had any problem yet. But, if we need really fast serial port, then we may need to use several BDs for the reception and transmission.
  
  

• Interrupt Mechanism
  Interrupt handling of SCC1 channel is configured in the interrupt pending register(IPR), the interrupt mask register(IMR), and the interrupt in-service register(ISR). 13th bit(from LSB) of each of these registers is used to mask or report the pending or in-service interrupt in SCC1 channel. Up to eight events can cause the SCC1 to interrupt the processor(CTS, CD, IDL, BRK, CCR, BSY, TX, RX). But, in the Hydra only TX and RX events are handled and the other events are all masked. The events are handled by SCC evnet register(SCCE1) and the SCC mask register(SCCM1).
  When the interrupt service routine is invoked, the interrupt service routine first check which event should be handled by checking SCCE1. And, then the service routine performs an appropriate actions according to the events.
  
  
• Registers
  

  SCON1	It controls SCC1's operation and selects clock source and baud rate. The device driver supports 9600, 19200, and 38400 bps. The value of SCON1 register is set to 0x0102 for 9600 bps, 0x0080 for 19200 bps, and 0x0040 for 38400 bps.
  SCM1	It's a mode register. Diagnostic mode is set to software operation where CTS, CD lines are under software control, and the receiver and the transmitter are enabled, and the channel mode is set to Asynchronous mode. (0x01bd)

  
  
• RTS, DTR lines
  Some devices like X10 transmitter uses RTS and DTR lines for signalling. To control these devices, we must be able to control RTS and DTR lines manually in the device driver. Pin 2 and 3 of the RTS jumper should be connected for the RTS to be controlled by software. Otherwise, RTS line is driven by the processors SCC1 channel and the device driver cannot control the line directly. DTR line is connected to PA8 pin and can be controlled by the device driver.
  
  
• Sample testing program for the serial port
  This sample program is echoing back to the serial port what it receives from the serial port. The assembly program is just a sort of wrapper for the c program. This program can be tested with a terminal emulater connected to the Hydra's serial port.
  echo_c2.c
  crt0.s
  

• RX, TX buffers
  The Ethernet buffer handling mechanism is pretty much the same as that of the serial port. Each buffer is referenced by buffer descriptor(BD), and BDs are located in BD table. The size of BD table can be configured by setting the BDSIZE field in the EDMA register(more information on the TABLE 4-2 in the MC68EN302 User's Manual).
  In the Hydra, BDSIZE field is set to $00, and up to 8 transmit buffers and 120 receive buffers can be used. But, only 1 buffer is used for transmission and reception each for simplicity. The address of the RX BD is 0xffec40, and the address of the TX BD is 0xffec00.
  
  
• Address recognition
  The MC68EN302 supports 64-entry internal address recognition table for receive address filtering. The address recognition logic is configured by setting AR_CNTRL register. It supports multicast, broadcast and promiscuous mode.
  The Hydra is configured to accept all broadcast frames and the multicast frames whose address is in the table.
  
  
• Interrupt mechanism
  The interrupt handling of the Ethernet port is almost the same as that of the serial port. And, the service routine figures out which event is happening by checking the INTR_EVENT register.
  
  
• Registers
  

  ECNTRL	Ethernet control register. It is set to 0x0003(ethernet enable) after setting all the other ethernet specific registers.
  EDMA	Controls DMA unit. It is set to 0x002b.
  EMRBLR	Determines the maximum size of the receive buffer. It is set to 0x0600.
  IVEC	Controls the interrupt vector generated by the Ethernet controller. It is set to 0x0050.
  INTR_MASK	Interrupt mask register. It is set to 0x0018 which enables only transmit and recieve frame interrupt. Other events like errors are all masked.
  ECNFIG	Ethernet configuration register. It is set to 0x0000.
  ETHER_TEST	Controls various manufacturing test modes. It is also set to 0x0000;
  AR_CNTRL	Controls address recognition operation. It is set to 0x4000.

  
  
• Sample testing program for the Ethernet port
  This sample program is printing out what it receives from the Ethernet port to the serial port.
  ether.c
  crt0e.s
  

For Those Who Want to Rebuild the Kernel

• At first, install toolchain.

  - Kernel/User Compiler set : 
      m68k-coff.i386-linux-libc5.tar
      m68k-pic-coff.i386-linux-libc5.tar
  

  Or, use uClinux-gcc-RH5Intel.tar for RedHat 5.x. (Actually, my system is RedHat 5.2, and I used uClinux-gcc-RH5Intel.tar.)
  When you install the compiler set, it creates /usr/local/gnu/ directory and extracts tools under that directory. Make sure that /usr/local/gnu/bin/ is on your path list. These cross compilers are built with libc.5.4.38, so make sure that your system has this version of libc.
  
  
• And, then install libraries :

      uC-libc-060199.tar.bz2
      uC-libm-060199.tar.bz2
  

  These libraries are used for building user programs.
  
  
• And, then install other tools

      coff2flt-0.3.tar.gz
      genromfs-0.3.tar.gz
  

  The binary format of user program is `flat file format'. coff2flt is used for changing `coff' binary to `flt' binary. genromfs is used for generating romfs image.
  
  
• Finally, kernel and user programs.

      not yet.
  

    genromfs-0.3/  apps/          uC-libm/
    coff2flt-0.3/  linux/         uC-libc/

    % make config
    % make depend
    % make updateromfs

About the Applications

• Web Server
  The web server running on Hydra is from uClinux distribution. The web server was really simple, only returning requested document on http request. We've added CGI capability to the web server, and the web server can run and monitor device controlling programs.

  The web server deals with `device controlling program' slight differently from usual CGI program. The `device controlling program' should have a special parameters. Here is an example of invoking and stopping `device controlling program'.

     http://hydra0f.cs.washington.edu/dev_con?deviceACT 
     http://hydra0f.cs.washington.edu/dev_con?deviceKILL 
  

  When invoking or stopping a `device controlling program', the special parameter - `deviceACT', `deviceKILL' - must be specified. The `device controlling program' is different from usual CGI programs. Usually, CGI program terminates just after returning http response to the requesting host. But, the `device controlling program' keeps running until the web server gets the `stop' request.
  (The CGI programs should not have the above special parameters as their parameter.)
  
  
• Telnet daemon
  Telnet daemon is also from uClinux distribution.
  
  
• my-FTP server
  The `my-FTP' server is used for transferring files to and from the Hydra. It doesn't use standard FTP protocol, but it uses my own file transfer protocol.
  We can use file upload page for transferring files to the Hydra.
  

For Those who want to Write Applications for the Hydra

• Forking a new process
  When forking a new process, use `vfork()' system call. (`fork()' is not supported.)
  
  
• Program size
  The size of a program must not exceed 64K. To support multi-tasking without virtual memory, the uClinux uses relative addressing for user space programs. And, in relative addressing, the code size cannot be larger than 64K. So, be careful not to write to large program.
  
  
• Unsupported libraries
  Not all the library functions are supported. If some library functions you want to use are not supported by the uc-libraries, you can add that functions into the library.
  
  
• Compiling application
  The compiler for compiling programs is `m68k-pic-coff-gcc', and the linker is `m68k-pic-coff-ld'. The format of the binary generated from the linker is `coff', but only `flt' binary is runnable on uClinux. So, we have to convert `coff' binary into `flt' binary, and coff2flt is used for that.
  Here is an example of Makefile.

  CC = m68k-pic-coff-gcc
  LD = m68k-pic-coff-ld
  CFLAGS = -O2 -m68000 -g -fno-builtin -msoft-float -D__linux__ -DEMBED -I../../uC
  -libc/include -I../../uC-libm
  LDFLAGS = --embedded-relocs -T ../arch/embed/user.ld ../arch/embed/crt0.o
  LIBS = ../../uC-libc/libc.a /usr/local/gnu/lib/gcc-lib/m68k-pic-coff/2.7.2.2-pic
  -010298/libgcc.a
  
  %.o: %.c
          $(CC) $(CFLAGS) $< -c
  
  all: sample
  
  sample: sample.o
          $(LD) $(LDFLAGS) $^ $(LIBS) -o $@.coff
          ../../coff2flt-0.3/coff2flt -o $@ $@.coff
  
  clean:
          rm -f *.o *.coff sample
  

• Writing CGI program
  The CGI program for the Hydra is almost the same as that for other linux machines. One thing different from other CGI programs is that you don't need to write the HTML header(Content-type : text/html\n\n) to stdout.