uCLinux is a derivative of the Linux 2.0 kernel that is intended for microcontrollers without memory management units (MMUs). uCLinux offers free, open-source code with no royalties; a small code footprint suitable for embedded and portable applications; a standard Linux API (with minor differences); high performance C libraries with a small footprint; and a variety of filesystems, including NFS, ext2,… MS-DOS, FAT 16/32 and others.

uClinux was created to support MMU-less microprocessors, so multitasking can be tricky. Most user applications that run on top of these devices, however, do not require multitasking. In addition, most of the binaries and source code for the uCLinux kernel have been rewritten to tighten-up and slim-down the code base. All these factors mean the uClinux kernel is significantly smaller than the original Linux 2.0 kernel. Yet it retains the main advantages of the Linux operating system: stability, superior network capability and excellent filesystem support.

uClinux comes equipped with a full TCP/IP stack, as well as support for numerous other networking protocols. Pretty much all the networking protocols are implemented. uClinux is an Internet-ready OS perfect for embedded devices.

MTPSR2-150 Hardware Overview

MTPSR2-150 hardware uses the MC68360 Quad Integrated Communication Controller (QUICC), from Motorola, as its microprocessor. The MC68360 QUICC is a versatile one-chip integrated microprocessor and peripheral combination that can be used in a variety of controller applications. It particularly excels in communication activities. The term “quad” comes from the fact that four serial communications controllers (SCCs) are located on the device. However, there are actually seven serial channels: four SCCs, two serial management controllers (SMCs) and one serial peripheral interface (SPI). For details on this semiconductor part, please refer to the user manual (see Resources).

The following list summarizes the MC68360 QUICC features:

• CPU32+ Processor
  • 32-bit Version of the CPU32 Core
  • Background Debug Mode
  • Byte-Misaligned Addressing
• Up to 32-Bit Data Bus (Dynamic Bus Sizing for 8 and 16 Bits)
• Up to 32 Address Lines (at Least 28 Always Available)
• Slave Mode to Disable CPU32+ (Allows Use with External Processors)
  • Multiple QUICCs Can Share One System Bus
  • All QUICC Features Usable in Slave Mode
• Memory Controller (Eight Banks)
  • Contains Complete Dynamic Random-Access Memory (DRAM) Controller
  • Each Bank Can Be a Chip Select or Support a DRAM Bank
  • Up to 15 Wait States
  • Glueless Interface to DRAM Single In-Line Memory Modules (SIMMs), SRAM, EPROM, Flash EPROM, etc.
  • Four CAS Lines (active low), Four WE lines (active low) and One OE line (active low)
  • Boot Chip Select Available at Reset
• Four General Purpose Timers
  • Four 16-bit Timers or Two 32-bit Timers
  • Gate Mode Can Enable/Disable Counting
• Two Independent DMAs (IDMAs)
  • Single Address Mode for Fastest Transfers
  • Buffer Chaining and Auto Buffer Modes
  • Automatically Performs Efficient Packing
  • 32-bit Internal and External Transfers
  • System Integration Module
  • Bus Monitor
  • Double Bus Fault Monitor
  • Spurious Interrupt Monitor
  • Software Watchdog
  • Periodic Interrupt Timer
  • IJTAG Test Access Port
• Interrupts
  • Seven External IRQ Lines (active low)
  • 12 Port Pins with Interrupt Capability
  • 16 Internal Interrupt Sources
  • Programmable Priorities between SCCs
  • Programmable Highest Priority Request
• Communications Processor Module (CPM)
  • RISC Controller
  • 224 Buffer Descriptors
  • Supports Continuous Mode Transmission and Reception on All
• Serial Channels
  • 2.5 KB of Dual-Port RAM
  • 14 Serial DMA (SDMA) Channels
  • Three Parallel I/O Registers with Open-Drain Capability
  • Each Serial Channel Can Have Its Own Pins (NMSI Mode)
• Four Baud Rate Generators
  • Independent
  • Allow Changes during Operation
  • Auto Baud Support Option
• Four SCCs
  • Ethernet/IEEE 802.3 Optional on SCC1 (Full 10-Mbps support)
  • HDLC/SDLC
  • Signaling System #7
  • Universal Asynchronous Receiver Transmitter (UART)
  • Binary Synchronous Communication (BISYNC)
  • Asynchronous HDLC (RAM Microcode Option)
  • V.14 (RAM Microcode Option)
  • X.21 (RAM Microcode Option)
• Two SMCs
  • UART
  • Transparent
  • General Circuit Interface (GCI) Controller
  • Can Be Connected to Time-Division Multiplexed (TDM) Channels
• One SPI
  • Supports Master and Slave Modes
  • Supports Multimaster Operation on the Same Bus
• Time-Slot Assigner
• Supports Two TDM Channels
• Parallel Interface Port
  • Centronics Interface Support
  • Supports Fast Connection Between QUICCs

The QUICC is comprised of three modules: the CPU32+ core, the SIM60 and the CPM. Each module utilizes the 32-bit intermodule bus (IMB).

The CPU32+ core can operate on 32-bit external operands with one bus cycle. This allows the CPU32+ core to fetch a long-word instruction in one bus cycle and to fetch two word-length instructions in one bus cycle. The CPU32+ also offers automatic byte alignment features. These features allow 16- or 32-bit data to be read or written at an odd address. The CPU32+ automatically performs the number of bus cycles required. It also offers low power consumption. It is implemented in high-speed complementary metal-oxide semiconductor (HCMOS) technology, providing low power use during normal operation.

The SIM60 integrates general-purpose features that would be useful in almost any 32-bit processor system. Although the QUICC is always a 32-bit device internally, it may be configured to operate with a 16-bit data bus. Regardless of the choice of the system bus size, dynamic bus sizing is supported. Bus sizing allows 8-, 16- and 32-bit peripherals and memory to exist in the 32-bit system bus mode; 8- and 16-bit peripherals and memory can exist in 16-bit system bus mode. System configuration and protection, breakpoint logic, slave mode, external bus interface control, memory controller and dynamic bus sizing are the major functionality of SIM60.

The CPM contains features that allow the QUICC to excel in communications and control applications. These features may be divided into three subgroups: communications processor (CP), two IDMA controllers and four general purpose timers.

The CP provides the communication features of the QUICC. Included are RISC processor, four SCCs, two SMCs, one SPI, 2.5 KB of dual-port RAM, an interrupt controller, a time slot assigner, three parallel ports, a parallel interface port, four independent baud rate generators and 14 serial DMA channels to support the SCCs, SMCs and SPI.The RISC controller is a 32-bit central controller of the communication processor module. Because its execution occurs on a separate bus that is hidden from the user, it does not impact the CPU32+ core performance. The RISC controller works with the serial channels and parallel interface port to implement the user-chosen protocols to manage the SDMA channels that transfer data between the SCCs and memory.

The RISC controller uses the peripheral bus to communicate with all of its peripherals. Each SCC has a separate receive and transmit FIFO. The SCC1 FIFOs are 32 bytes each; the other SCC FIFOs are 16 bytes each. The SMC and SPI FIFO sizes are double buffered. The PIP is a single register interface.

The following priority scheme determines the processing priority of the RISC controller:

• System Reset
• DMA Bus Error
• Commands Issued to CP
• SCC1 Rx
• SCC1 Tx
• SCC2 Rx
• SCC2 Tx
• SCC3 Rx
• SCC3 Tx
• SCC4 Rx
• SCC4 Tx
• SMC1 Rx
• SMC1 Tx
• SMC2 Rx
• SMC2 Tx
• SPI Rx
• SPI Tx
• PIP
• RISC Timer Tables

The RISC controller has an option to execute microcode from a portion of user RAM, located in the on-chip dual-port RAM. In this mode, either 512 bytes or 1,024 bytes of the user RAM cannot be accessed by the host or another bus master and are used exclusively by the RISC.

The IDMAs provide two channels of general-purpose DMA capability. They offer high speed transfers, 32-bit data movement, buffer chaining and independent request, and an acknowledge logic. The RISC controller may access the IDMA registers directly in the buffer chaining modes.

The four general purpose 16-bit timers on the QUICC can be cascaded internally to get two 32-bit timers. The QUICC also contains a periodic interval timer, bringing the total to five on-chip timers.

The features of the MTPSR2-150 hardware are summarized below:

• MC68360 processor at 33.1776MHz
• 4MB Flash>8MB SIMM DRAM
• One RJ45 command interface over SMC1 (for console)
• One Quad RJ45 LAN HUB interface over SCC1 (10 Mbps)
• One RJ45 LAN interface over SCC2 (10 Mbps)
• Two WAN interfaces over SCC3 and SCC4

For all of these reasons, the MTPSR2-150 board provided an ideal embedded system environment for porting uCLinux.

Scope of the Project

The aim of this research project was to port uCLinux (Micro-Controller Linux) to the MC68360-based MTPSR2-150 board. We intended to measure the response time of the interrupts and develop a suitable environment for applications, including real-time system on-chip embedded applications, media gateway controllers, voice over IP solutions, multimedia solutions, routers and the like.

Approach and Design

Before actually porting the 2.4.4.kernel, we had to bring up a bootloader. We also had to port the UART Driver, for a console interface, and the Ethernet driver to enable NFS.

In order to port the above two drivers, some changes, two of them major, were made to the available uCLinux source code. First, the kernel image was configured to run from RAM (the appropriate option was selected during make menuconfig). Second, a RAM disk was used as the root filesystem. The RAM disk image was built and inked along with the uCLinux kernel image. This was achieved by doing the following:

• The makefile under the directory arch/m68knommu/platform/68360 was modified to link to the RAM disk image.
• The file ram.ld under the directory arch/m68knommu/platform/68360/uCquicc was changed to statically locate the RAM disk image in the uCLinux kernel image. Also the MEMORY section in this file was changed, per the board specifications.
• The function setup_arch() was changed to initialize the global variables initrd_start and initrd_end appropriately.
• The serial_console_setup() function was recoded to initialize serial management controller 1 (SMC1) to operate in UART mode instead of serial management controller 2 (SMC2). In the MTPSR2-150 board, the SMC2 has no interface to the external world.
• The Config.in file in the directory path drivers/net was changed to include the option to compile the Ethernet driver along with the uCLinux kernel. The QUAD RJ45 LAN HUB interface was initialized to be used as the Ethernet interface at 10Mbps.
• The function old_reloc(), which performs relocation for application images of type binary flat format (version 2), was modified to extract the proper type and offset information to perform relocation.
• The function m68k_fork() was recoded to call m68k_vfork(). This was done to support execution of commands such as ls and mv from the shell.

The uCLinux kernel image is in executable linkable format (ELF). This image is downloaded to the target hardware using the JTAG interface supported by the target hardware. The parallel port of the PC is interfaced to the JTAG using BDM connector cable. The GNU Debugger (GDB) on the host system is used to download the code onto the target hardware. GDB also is used to debug the kernel image.

The uncompressed uCLinux kernel image is downloaded to the DRAM and is given the execution control. The size of the uCLinux kernel image is 970KB, constituting text segments (599KB), data segments (109KB) and bss segments (262KB). The compressed RAM disk image is statically located in the data segment.

The bootup time for the uCLinux kernel is 24 seconds. A shell is the only application started after kernel initialization completes.

Interrupt Response Time Measurement

To measure response time, we used an SAB80C535 (80535 for short) microcontroller board, along with 1488 and 1489 chips to convert TTL voltage levels to RS-232 voltage levels and back.

The target system (MC68360 board) running uCLinux had one RS-232 serial port, and a special driver was written for this. This driver had a line status interrupt service routine. Whenever the CTS signal on the port turns high, the driver toggles the RTS in response.

The CTS signal to the serial port on the target system is made high through an output pin of the 80535. The MC68360 board running uCLinux, in response to this interrupt, makes RTS high. The time difference between these two events gives the interrupt response time of the target system.

Immediately after bringing CTS high, the 80535 starts polling the RTS pin, where it expects the response as often as possible. The 80535 runs a time counter by incrementing a register.

• When the response is received on the RTS pin (becomes high), the response time for that particular iteration is compared with a stored value (which starts at zero). If the present iteration response time is greater than the stored value, the present iteration response time is copied in the store.
• This loop is run as many times as required while load is put on the target MC68360 board running uCLinux system.
• When all the iterations are finished, the stored value will be the worst response time of the target uCLinux system.

Observations

The following list shows the observations for the interrupt response time for MTPSR2-150 board based on an MC68360. The readings indicate worst case response times in 10 iterations. Each iteration consisted of many interrupts and their responses, and the worst response is recorded.

uCLinux on MC68360

2364
5232
2100
13704
2712
2100
13440
14568
15816
11284

Worst Overall Interrupt Response Time: 15816

Conclusion

The interrupt response latency is not only high but also varies widely. Multitech is currently engaged in getting the real-time modules from RTLinux to run on the uCLinux port. With this we expect to achieve good performance, real-time Linux running on the hardware.

Resources

MC68360 Quad Integrated Communications Controller User's Manual, from Motorola

---

About the author: M.Venkatakrishnan is a member of the Embedded System Group of Multitech Software Systems, India. He is responsible for implementing and testing various embedded operating system projects based on ARM, Motorola and Intel processors.

“In Aginotech, we have developed embedded applications over normal Linux and RTLinux, based on Intel/Motorola/ARM/MIPS platforms. We have been successful in developing some critical expertise, which has made us capable of tapping any opportunity to build several applications over these platforms. We have earned expertise with audio/video applications, LAN/WAN bridging and remote debugging.”

---

Copyright © 2002 Specialized Systems Consultants, Inc., publishers of the monthly magazine Linux Journal. All rights reserved. Embedded Linux Journal Online is a cooperative project of Linux Journal and LinuxDevices.com.

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.