Porting uCLinux to the MC68360-Based MTPSR2-150 Board
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 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.
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.
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.
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.
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
236452322100137042712210013440145681581611284
Worst Overall Interrupt Response Time: 15816
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.
MC68360 Quad Integrated Communications Controller User's Manual, from Motorola
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.
