Porting Linux to the M32R processor

Hirokazu TakataRenesas Technology Corp., System Core Technology Div.

4-1, Mizuhara, Itami, Hyogo, 664-0005, Japan

takata.hirokazu@renesas.com

Naoto Sugai, Hitoshi YamamotoMitsubishi Electric Corp., Information Technology R&D Center

5-1-1, Ofuna Kamakura, Kanagawa 247-8501, Japan

{sugai,hitoshiy}@isl.melco.co.jp

Abstract

We have ported a Linux system to the Renesas1

M32R processor, which is a 32-bit RISC mi-croprocessor designed for embedded systems,and with an on-chip-multiprocessor feature.

So far, both of UP (Uni-Processor) and SMP(Symmetrical Multi-Processor) kernels (basedon 2.4.19) have been ported and they are op-erating on the M32R processor. A DebianGNU/Linux based system has been also devel-oped on a diskless NFS-root environment, andmore than 300 unofficial.deb packages havealready been prepared for the M32R target.

In this paper, we describe this new architectureport in detail and explain the current status ofthe Linux/M32R project.

1Renesas Technology Corp. is a new joint semicon-ductor company established by Hitachi Ltd. and Mit-subishi Electric Corp. on April 1, 2003. It would be theindustry’s largest microcontroller (MCU) supplier in theworld. The M32R family microcontroller and its succes-sor will be continuously supplied by Renesas.

1 Introduction

A Linux platform for Renesas M32R proces-sor has been newly developed. The RenesasM32R processor is a 32-bit RISC microproces-sor, which is designed for embedded systems.It is suitable for a System-on-a-Chip (SoC) LSIdue to its compactness, high performance, andlow power dissipation. So far, the M32R fam-ily microcomputers have widely used for theproducts in a variety of fields—for example,automobiles, digital still cameras, digital videocamcorders, cellular phones, and so on.

Recently, the Linux system has begun to beused widely and employed even in the embed-ded systems. The embedded systems would bemore software-oriented systems hereafter. Themore complex and larger the embedded systemis, the more complicated the software becomesand harder to develop. In order to build thesekinds of embedded systems efficiently, it willbe more important to utilize generic OSes suchas Linux to develop software.

This is the first Linux architecture port to theM32R processor. This porting project, called a“Linux/M32R” project, has been active since

Linux Symposium 399

2000. Its goal is to prepare a Linux plat-form for the M32R processor. At first, thisLinux porting was just a feasibility study forthe new M32R processor development, and itwas started by only a few members of theM32R development team. Then, this projecthas grown to a lateral project among RenesasTechnology Corp., Renesas Solutions Corp.,and Mitsubishi Electric Corp.

In this feasibility study, we have ported notonly Linux kernel, but also whole GNU/Linuxsystem including GNU tools, libraries, andother software packages, so called “userland.”We also enhanced the M32R processor to addMMU (Memory Management Unit) facility inorder to port Linux system. And we have alsodeveloped an SMP kernel to investigate multi-processing by M32R’s on-chip-multiprocessorfeature[1]. At present, the Linux/M32R systemcan operate on the dual M32R cores in SMPmode.

In this paper, we describe this new architectureport in detail and explain about the current sta-tus of the Linux/M32R project.

2 Linux/M32R Platform for Em-bedded Systems

Recently, due to the continuous evolution ofsemiconductor technologies, it is possible tointegrate a whole system into one LSI chip, socalled “System-on-a-Chip (SoC).”

In an SoC, microprocessor core(s), peripheralI/O functions, internal memories, and user log-ics can be integrated into a single chip.

By making use of wide internal buses, an LSIcan achieve high performance which can notbe realized by combination of several general-purpose LSIs. In other words, we can optimizesystem performance and cost by using SoC, be-cause we can employ optimum hardware archi-

tecture and circuit configuration.

In such an SoC, a microprocessor core is akey part; therefore, the more compact andhigher performance microprocessor is signif-icantly required. To make such a high per-formance embedded processor core, not onlyin circuit and process technology but also ar-chitectural breakthrough is necessary. Espe-cially, multiprocessor technology is importanteven for the embedded processor, because itcan improve processor performance and lowersystem power dissipation by increasing proces-sor number scalably and without increasing op-erating clock frequency.

For an SoC with embedded microprocessor,software is also a key point. The more sys-tem is highly functional, the more software willbe complex and there is an increasing demandfor shortening development time of SoC. Un-der such circumstance, recently the Linux OSbecomes to be adopted for embedded systems.Linux platform makes it easy to port applica-tion programs developed on a PC/EWS to thetarget system. We believe that a full-featuredLinux system will come into wide use in em-bedded systems, because embedded systemswill become more functional and higher per-formance system will be required.

In the development of embedded systems,it is important to tune system performancefrom both hardware and software points ofview. Therefore, we used M32R softmacroand FPGA (Field Programmable Gate Array)devices to implement an evaluation board forrapid system prototyping. FPGA devices areslow, but make it possible to develop a systemin short turn-around time.

In this feasibility study, to construct a Linuxplatform, we ported Linux to the M32R archi-tecture, and validated the hardware system ar-chitecture through the porting, and developedthe software development environment.

Linux Symposium 400

R0

R1

R2

R3

R4

R5

R6

R7

R8

R9

R10

R11

R12

R13

R14 (link register)

R15 (stack pointer)

0 31

General Purpose Registers

PC

0 31

Control Registers

CR0 (PSW)

CR1 (CBR)

CR2 (SPI)

CR3 (SPU)

CR5 (EVB)

CR6 (BPC)

0 31

Program Counter

0 8 63

Accumulators

processor status word

condition bit register

interrupt stack pointer

user stack pointer

EIT vector base register

backup PC

A0

A1

Figure 1: M32R register architecture

2.1 M32R architecture

The M32R is a 32-bit RISC microprocessor,and employs load-store architecture like otherRISC processors. Therefore, memory accessis executed by only load and store instruc-tions and logical and arithmetic operation isexecuted among registers. Except for multi-ply and divide instructions, most of instruc-tions can be executed in one clock, and instruc-tion completion does not depend on the the in-struction issuing order (out-of-order comple-tion). The M32R supports DSP operation in-structions such as multiply and accumulate in-structions.

Figure 1 shows the M32R register architec-ture. The M32R has sixteen 32-bit general pur-pose registers (R0∼ R15) and 56-bit accumu-lators for the multiply and accumulate opera-tions. R14 is also used as a link register (LR)which keeps return address for a subroutinecall. There are two stack pointer registers, SPI(interrupt stack pointer) and SPU (user stackpointer). The CPU core selects one of them asa current stack pointer (R15; SP) by the SM(stack mode) bit of the PSW (processor statusword).

2.2 M32R softmacro

The M32R softmacro is a compact micropro-cessor, developed to integrate into a SoC. It isa full synthesizable Verilog-HDL model and ithas an excellent feature that the core does notdepend on a specific process technology. Dueto a synchronous edge-triggered design, it hasgood affinity to EDA tools.

This M32R softmacro is so compact that it canbe mapped into one FPGA. Utilizing such anM32R softmacro, we developed software on aprototype hardware and co-designed hardwareand software simultaneously.

To port Linux to the M32R, some enhance-ment of the M32R softmacro core was needed;processor mode (user mode and supervisormode) was introduced and an MMU modulewas newly supported.

• TLB (Translation Lookaside Buffer): in-struction/data TLBs are full-associative,32-entries each, respectively.

• page size : 4kB/16kB/64kB (user page),4MB (large page)

2.3 Integrated debugging function and SDI

The integrated debugging function is a signifi-cant characteristic of the M32R family micro-computer. The M32R common debugging in-terface, called as SDI (Scalable Debug Inter-face), is utilized via five JTAG pins; the in-ternal debug functions are controlled throughthese debug pins.

Using the JTAG interface defined as IEEE1149.1, internal debug function can be used.No on-chip or on-board memory to store mon-itor programs is necessary, because such moni-tor programs can be provided and executed viaJTAG pins.

Linux Symposium 401

3 Porting Linux to the M32R

The Linux system consists of not only theLinux kernel, but also the GNU toolchain andlibraries. Of course, a target hardware environ-ment is also necessary to execute Linux.

Therefore we had to accomplish the followingtasks:

• Porting the Linux kernel

• Development of Linux/M32R platforms(M32R FPGA board, etc.)

• Enhancement of the GNU toolchain

• Porting libraries (GNU C library, etc.)

• Userland; preparing software packages

Actually, in the Linux/M32R development,these tasks have developed concurrently.

3.1 Porting Kernel to the M32R

In the Linux kernel, the architecture-dependentportion is clearly distinguished. Therefore, incase of a new architecture port, all you need todo is prepare only architecture dependent code,which is far less than whole Linux code. Inthe M32R case,include/asm-m32r/ andarch/m32r/ are needed.

To be more precise, we can prepare thearchitecture-dependent portion in reference tothe other architecture implementation. How-ever, it has some difficulties in rewriting theseportions:

asm function : It was very difficult to portsome headers in which asm statementis extensively used, because an insuf-ficient and inadequate rewriting easilycause bugs which are very hard to debug.

function inlining : In the Linux source code,function inlining is heavily used. We cannot disable the compiler’s inline optimiza-tion function to compile the kernel source,but a buggy toolchain sometimes causes asevere problem in optimization.

In this porting, we started with a minimumconfiguration kernel. We prepared stub rou-tines, built and checked the kernel operation,and gradually added files ofkernel/ , mm/,fs/ , and other directories. When we startedkernel porting, there was no evaluation board.So, we made use of GNU M32R simulator toport a kernel at first.

The GNU simulator was very useful at the ini-tial stage of kernel porting, though it does notsupport MMU. It had also good characteris-tics that downloading was quite fast comparingwith evaluation board and C source level debugwas possible.

Employing the simulator and initrd image ofromfs root filesystem, it is possible to developand debug kernel’s basic operation, such asscheduling, initialization and memory manage-ment. Indeed, the demand loading is per-formed after/sbin/init is executed by aexecve() system call at the end of kernelboot sequence ofinit() .

At first, we started to port the kernel 2.2.16.The current stable version of the M32R kernelis 2.4.19 and now we are developing 2.5 serieskernel for the M32R.

3.1.1 System Call Interface

In the M32R kernel, like other processors, asystem call is handled by a system call trapinterface. In the system call interface (syscallI/F), all general purpose registers and accumu-lators are pushed onto the kernel stack to save

Linux Symposium 402

System Call : TRAP#2R7 : System Call NumberR0 .. R6 : arg0 .. arg6 (max. 7 arguments)

User Process

User Stack (SPU)

Kernel

Kernel Stack (SPI)

System CallExecution

System CallInvocation TRAP#2

Change Stack Pointer

Figure 2: System call interface

the context.

In Fig. 2, the syscall ABI (Application BinaryInterface) for the M32R is shown. Two stackpointers, kernel stack (SPI) and user stack(SPU), are switched over by software at the en-try point of syscall I/F routine, because stackpointers do not change automatically byTRAPinstruction. In order to switch stack point-ers without working register and avoid multi-ple TLB miss exception,CLRPSWinstructionis newly introduced.

The stack frame formed by the syscall I/F rou-tine is shown in Fig. 3. It should be notedthat there is a special system call in Linux,like sys_clone(), that has particular interfacepassing a stack top address as a first argu-ment. Therefore, we employ a parameter pass-ing method: The stack top address (∗pt_regs)is always put onto the stack as a implicit stackparameter like the SuperH implementation.

According to the ABI of the M32R gcc com-piler, the first 4 arguments are passed by regis-ters and the following arguments are passed bystack. Therefore, the∗pt_regs parameter canbe accessed as the eighth parameter on the ker-

R4R5R6

*pt_regsR0R1R2R3R7R8R9

R10R11R12

syscall_nrACC0HACC0LACC1HACC1LPSWBPCSPUR13LRSPI

ORIG_R0

+0x00+0x04+0x08+0x0c+0x10+0x14+0x18+0x1c+0x20+0x24+0x28+0x2c+0x30+0x34+0x38+0x3c+0x40+0x44+0x48+0x4c+0x50+0x54+0x58+0x5c+0x60+0x64

Lower Address

Upper Address

Stack Top; SPI(= pt_regs)

Figure 3: Stack frame formed by a system call

nel stack.

The syscall_nr and ORIG_R0 field areused for the signal operations. When a sys-tem call is issued, its system call number isstored intoR7 and trap instruction is executed.syscall_nr also holds the system call num-ber in order to determine if a signal handler iscalled from a system call routine or not. Be-cause theR0 field might be changed to the re-turn value of a system call,ORIG_R0 keepsthe original value ofR0 in preparation to restartthe system call.

3.1.2 Memory Management

Linux manages the system memory bypaging.In the M32R kernel, the page size is 4kB likethe other architecture.

Linux Symposium 403

TLB miss handler

access exception handler

do_page_fault()

handle_mmu_fault()

(1) TLB miss exception(2) access exception

reexecute afterthe execution of exception handlers

MMU exception!

Figure 4: Exception handling for the demand-loading operation

In demand loading and copy-on-write opera-tions, a physical memory page can be newlymapped when apage faulthappens. Such apage fault is handled by bothTLB miss handlerandaccess exception handler(Fig. 4).

demand loading : If an instruction fetch oroperand access to the address which is notregistered in page table, an MMU excep-tion happens. In case of a TLB miss ex-ception, TLB miss handler is called. Tolighten the TLB miss handling operation,TLB handler only sets TLB entries. Pagemapping and page-table setting operationsare to be handled by the access exceptionhandler; For accessing a page which doesnot exist in the page table, the TLB misshandler sets the TLB entry’s attribute tonot-accessible at first. After that, sincethe memory access causes an access ex-ception due to not-accessible, access ex-ception handler deal with the page tableoperations.

copy-on-write : In Linux, copying a processby fork() and reading a page in read-only mode are handled as a copy-on-writeoperation to reduce vain copy operations.For such a copy-on-write operation, TLBmiss handler and access exception handlerare used like a demand loading operation.

The M32R’s data cache (D-cache) is indexedand tagged physically. So, it does not have totake care the cache aliasing. Therefore the D-cache is flushed only for a signal handler gen-eration and a trampoline code generation.

To simplify and speed up the cache flushingoperations for trampoline code, a special cacheflush trap handler (trap#12) is established in theM32R kernel.

3.1.3 SMP support

In Linux 2.4, multiprocessing performance issignificantly improved compared with Linux2.2 or before, because the kernel locking foraccessing resources is finer.

To implement such a kernel locking on SMPkernel, spinlock is generally used for mutualexclusion control. But the M32R has noatomic test-and-set instruction, the spinlockoperations can be implemented withLOCKandUNLOCKinstructions in the M32R kernel.

The LOCK and UNLOCKinstructions are aload and store instructions for mutual exclu-sion operation, respectively.LOCKacquiresand keeps a privilege to access the CPU busuntil UNLOCKinstruction is executed. Access-ing a lock variable byLOCK/UNLOCKinstruc-tion pair under a disabled interruption condi-tion, we implemented an atomic access.

Figure 5 shows an M32R on-chip-multiprocessor prototype chip. Linux SMPkernel can be executed on the on-chip mul-tiprocessor system. On-chip multiprocessormight be a mainstream in near future even inembedded systems, because multiprocessorsystem can enhance the CPU performancewithout increasing operating clock frequencyand power dissipation. In this chip, two M32Rcores are integrated and each has its own cachefor good scalability.

Linux Symposium 404

(a) Chip (b) CPU

Figure 5: A micrograph of an on-chip-multiprocessor M32R prototype chip

3.2 Development of Linux/M32R Platform

To execute full-featured Linux OS, an MMUis necessary; therefore, we developed a newM32R softmacro core with an MMU and madean evaluation board “Mappi,” which used FP-GAs to map the M32R softmacro core, as aLinux/M32R platform.

As shown in Fig. 6, the Mappi evaluationboard consists of two stacked boards. The up-per board is a CPU board and the lower boardis an extension board. The CPU board has noreal CPU chip, but it has two large FPGAs onit. We employ the M32R softmacro core andmap it onto the FPGAs.

The Mappi board is a very flexible system forprototyping. If we have to modify a CPU orother integrated peripherals, we can immedi-ately change and fix them by modifying theirVerilog-HDL model.

At first, we could only useinitrd andbusybox on it, because the Mappi systemhad only a CPU board and it had only 4MBSRAMs. After the extension board was devel-oped, more memory (SDRAM), Ethernet, and

PC-card I/F became available. So, we intro-duced NFS and improved the porting environ-ment. It was Dec. 2001 that we succeededin booting via a network using the extensionboard.

Utilizing the M32R’s SDI function and JTAG-ICE, mentioned before, we can download anddebug a target program via JTAG port. Itis much faster than a serial connection be-cause the Debug DMA function is used fordownloading and refering internal resources.Of cource, it is also possible to set hardwarebreakpoints for the PC break and the accessbreak via SDI.

Generally speaking, it is too difficult to de-velop and debug software programs on an un-steady hardware which is under development.But, we could debug and continued to developthe system by using the SDI debugger, becausethe SDI debugger made it possible to accessthe hardware resources directly and it was veryuseful for the kernel debugging.

Finally, we constructed an SMP environmentto execute the SMP kernel, mapping the M32Rsoftmacro cores to two FPGAs on the Mappi

Linux Symposium 405

CPU

Mem BIU

FPGA#0

I/O

FPGA#1

UserLogic

CPU Board

DisplayCont. LAN

Extension Board

PC-card

FlashROM 4MB

SDRAM 64MB

Figure 6: Mappi: the M32R FPGA evaluation board; it has the M32R softmacro on FPGA (CPU,MMU, Cache, SDI, SDRAMC, UART, Timer), FPGA Xilinx XCV2000E×2, SDRAM(64MB),FlashROM, 10BaseT Ethernet, Serial 2ch, PC-card slot×2, and Display I/F(VGA)

CPU board; concretely, we replaced the userlogic portion in FPGA#1 shown in Fig. 6with an another M32R core with a bus arbitor,and modified the ICU (Interrupt Control Unit)to support inter-processor interruption for themultiprocessor.

After the M32R prototype on-chip-multiprocessor chip was developed, theLinux/M32R system including userland appli-cations has been mainly developed by usingthe real chip, because the operating clockfrequency of the M32R FPGA is 25MHz butthe M32R chip can run more than 10 timesfaster.

3.3 M32R GNU toolchain enhancement

The GNU toolchain is necessary to develop theLinux kernel and a variety of Linux applicationprograms. When we started the Linux port-ing, we had only Cygnus’s (now it’s Red Hat,Inc.) GNUPro™m32r-elf toolchain. It wassufficient for the kernel development; how-ever, it could not be applicable to user applica-tion development on Linux, because in a mod-ern UNIX system a dynamic linking method

is strongly required to build a compact systemand achieve higher runtime performance. (Al-though a static linked program is much fasterthan a dynamic linked program if the programsize is small. The bigger a program becomes,the larger cache miss penalty would be.)

We enhanced the M32R GNU toolchain to sup-port shared libraries:

• Change BFD library to support dynamiclinking; some relocations were added fordynamic linking.

• Change GCC and Binutils to support PIC(Position Independent Code).

Because the version of the GNUpro m32r-elfgcc was 2.8 and too old, we had to upgradeand develop a new m32r-linux toolchain. Weapplied GNUpro patch to the gcc of the FSFversion and developed GCC (v2.95.4, v3.0,v3.2.2) and Binutils (v2.11.92, v2.13.90).

In a prologue portion of a C function, the fol-lowing code is generated when the-fPIC op-tion is specified.

Linux Symposium 406

; PROLOGUEpush r12push lrbl .+4 ; get the next instruction’s

; PC address to lrld24 r12,#_GLOBAL_OFFSET_TABLE_add r12,lr

We also modified BFD libraries to supportdynamic linking. We referenced the i386implementation and supported the ELF dy-namic linking. In the ELF object format [3],GOT (Global Offset Table) and PLT (Proce-dure Linkage Table) are used for the dynamiclinking. In the M32R implementation, theGOT is refered by R12 relative addressing andthe RELA type relocation is emoployed. Likea IA-32 implementation, the code fragment ofPLT refers the GOT to determine the symboladdress, because it is suitable and efficient forthe M32R’s cache which can be simply flushedwhole caching data.

As for GDB, we enhanced it to support a newremote targetm32rsdi to use the SDI remoteconnection. By using the gdb, we can do a re-mote debugging of the kernel in C source-level.In the latest version ofm32r-linux-gdb/m32r-linux-insight (v5.3), we haveemployed aSDI server that engages in ac-cessing the JTAG port of the ICE/emmulatorconnected with the parallel port of the host PC.This gdb makes it possible to debug using SDI,communicating with the SDI server in back-ground. Though the SDI server requires priv-ileged access to use parallel port, we can usegdb in user mode.

3.4 Porting GNU C library

The GNU C library is the most fundamentallibrary, which is necessary to execute a varietykind of application programs. So we decided toport it to implement full-featured Linux systemfor a study, though its footprint is too large fora tiny embedded system.

We started to port glibc-2.2.3 (v2.2.3) in earystage of the Linux/M32R porting, it was aboutthe same time that the kernel’s scheduler beganto work.

Then, the glibc for the M32R have been devel-oped step by step;

• Check by a statically linked program, forexample,hello.c (newlib version→glibc version).

• Build a shared library version of glibc andcheck by dynamically linked programs,hello.c, busybox, etc.

• Port the LinuxThreads library to supportPthreads (POSIX thread).

The latest version of the glibc for the M32Ris glibc-2.2.5 (v2.2.5). It also supports aLinuxThreads library, that implements POSIX1003.1c kernel threads for Linux. In this Lin-uxThreads library, we implemented fast user-level mutual exclusion using the Lamport’salgorithm [2], because the system call im-plementation was quite slow due to contextswitching.

After the glibc porting was finished, we startedto build various kind of software. But it hastaken several months to implement and debugthe following:

• Fixup operations of the user_copy rou-tines in the kernel

• Resolve the relocation by a dynamiclinker ld-linux.so

• Signal handling

Especially, the dynamic linking operation wasthe one of the most difficult portions in this

Linux Symposium 407

GNU/Linux system porting, because the dy-namic linker/loader resolved global symbolsand subroutine function addresses in runtime.Furthermore, the dynamic linker itself is alsoa shared library, so we can not debug it inC source-level. However, we debugged thelinker, making use of a simulator, a SDI de-bugger, and all kinds of things.

3.5 Userland

For the sake of preparing software packagesand making the Linux/M32R distributable, webuilt major software packages.

We chose the Debian GNU/Linux as a base dis-tribution, because it is well-managed and all ofthe package sources are open and published.In Debian, using command programs such asdpkg andapt , it is possible to manage abun-dant software packages easily.

To build a binary package for the M32R, wedid as the following:

1. Expand the source tree from the Debiansource package (*.dsc and *.orig.tar.gz)

2. Rebuild a binary package by using adpkg- buildpackage command,specifying the target architecture tom32r(dpkg-buildpackage -a m32r-t m32r-linux ).

So far, more than 300 unofficial.deb pack-ages have been prepared for the M32R target,including the basic commands, such as self-tools and shells, utilities, package managementtools (dpkg , apt ), and application programsas follows:

adduser, anacron, apt, base-files, bash, bc,binutils, bison, boa, bsdgames, bsdutils, busy-box, coreutils, cpp-3.2, cvs, debianutils, de-

Figure 7: A snapshot of the desktop image ofX; the window manager isAfterStep

vfsd, diff, dpkg, e2fsprogs, elvis-tiny, ex-pect, file, fileutils, findutils, flex, ftp, g++-3.2, gcc-3,2, grep, gzip, hostname, klogd, less,libc6, locales, login, lynx, m4, make, mawk,modutils, mount, nbd-client, net-tools, net-base, netkit-inetd, netkit-ping, passwd, perl-base, perl-modules, portmap, procps, rsh-client, rsh-server, samba, sash, sed, strace,sysklogd, tar, tcl8.3, tcpd, tcsh, telnet, textu-tils, util-linux, wu-ftpd, . . .

Most of these packages were developed underthe cross environment, except some softwarepackages, such as Perl, Xserver, gcc, etc. Be-cause they had to be configured in the targetenvironment. Therefore, self tools were nec-essary in order to build packages under theself environment. Fortunately, by using.debpackages anddpkg-cross commands, thesame package files can be completely sharedbetween the self and the cross environment.

Regarding the GUI environment, we haveported some window systems (X, Microwin-dows, Qt-Embedded). We ported them eas-ily using a framebuffer device. Figure 7 is asample screen snapshot of X desktop image.gears and bounce are demonstration pro-

Linux Symposium 408

grams of the Mesa-3.2 3D-graphics library.

4 Evaluation

The Linux/M32R system’s conformance havebeen checked and validated by using the LSB(Linux Standard Base) testsuites, which areopen testsuites and based on the LSB Specifi-cation 1.2 [5]. In this validation, we comparedthe following two environments.

Linux/M32Rbased on the Debian GNU/Linux (sid)linux-2.4.19 (m32r_2_4_19_20030109)glibc-2.2.5 (libc6_2.2.5-6.4_m32r.deb)gcc-3.0 (self gcc; m32r-20021112)

RedHat7.3 2

linux-2.4.18-10 (kernel-2.4.18-10.i686.rpm)glibc-2.2.5 (glibc-2.2.5-42.i686.rpm)gcc-2.96

The result of validation is shown in Table 1.Judging from the result, the LSB conformanceof the Linux/M32R is no less good than theRedHat Linux 7.3, because the original De-bian distribution has basically good LSB con-formance and quality.

5 Future work

To apply the Linux/M32R to embedded sys-tems, it is indispensable to tune and shrink thewhole system more and more. As for the ker-nel, particulary, tuning and improving realtimeperformance will be strongly required.

At present, we are porting the Linux 2.5 se-ries kernel for the M32R in order to supportthe state of the art kernel features, such as

2The kernel and glibc are upgraded and differentfrom the original Red Hat 7.3 distribution.

O(1) scheduler, the preemptible kernel, the no-MMU support, the NUMA support, and so on.

We are also planning to utilize DMA functionand internal SRAM to increase Linux systemperformance. And for the high-end embeddedsystems, we intend to continuously focus onthe SMP kernel for the on-chip-multiprocessor.

6 Summary

To build a Linux platform, we have porteda GNU/Linux system to the M32R processor.In this work, a hardware/software co-designmethodology was employed, using a full syn-thesizable M32R softmacro core to accelerateLinux/M32R development. To develop SoC ina short time, such a hardware and software co-design and co-debugging methodology will be-come more important hereafter.

Linux will play a great role in the field of notonly PC servers but also embedded systems inthe near future. Through the feasibility study,we believe that the Open Source will providea quite large impact on developing embeddedsystem design and development. If we have op-portunity, we hope to publish the Linux/M32Rand M32R GNU toolchain.

7 Acknowledgements

The authors greatly acknowledge the collabo-ration and valuable discussion with the M32Rdevelopment team [1] and thank Takeo Taka-hashi, Kazuhiro Inaoka, and Takeshi Aoki fortheir special contributions, and we would alsolike to thank Dr. Toru Shimizu and HiroyukiKondo for their promotion of the M32R pro-cessor development project.

Linux Symposium 409

ANSI.os POSIX.os LSB.os RedHat7.3Section ANSI.hdr

F MPOSIX.hdr

F M F MTotal

Total

Expect 386 1244 1244 394 1600 1600 908 908 8284 8284Total

Actual 386 1244 1244 394 1600 1600 908 908 8284 8284Succeeded 176 1112 86 207 1333 0 695 0 3609 3583Failed 4 0 0 5 2 0 49 0 60 45Warnings 0 12 0 0 5 0 2 0 19 18FIP 2 0 0 2 2 0 1 0 7 7Unresolved 0 0 0 0 0 0 5 0 5 4Uninitiated 0 0 0 0 0 0 0 0 0 0Unsupported 203 0 0 179 72 0 59 0 513 513Untested 0 4 0 0 7 0 39 0 50 43NotInUse 1 116 1158 1 179 1600 58 908 4021 4021

Key: F:function, M:macro; FIP: Further Information Provided

Table 1: LSB 1.2 testsuites result

References

[1] Satoshi Kaneko, Katsunori Sawai, NorioMasui, Koichi Ishimi, Teruyuki Itou,Masayuki Satou, Hiroyuki Kondo, NaotoOkumura, Yukari Takata, Hirokazu Takata,Mamoru Sakugawa, Takashi Higuchi,Sugako Ohtani, Kei Sakamoto, NaoshiIshikawa, Masami Nakajima, ShunichiIwata, Kiyoshi Hayase, Satoshi Nakano,Sachiko Nakazawa, Osamu Tomisawa,Toru Shimizu,A 600MHz Single-ChipMultiprocessor with 4.8GB/s InternalShared Pipelined Bus and 512kB InternalMemory, Proceedings of 2003International Solid-State CircuitsConference, 14.5.

[2] Laslie Lamport,A Fast Mutual ExclusionAlgorithm, ACM Trans. on ComputerSystem, Vol. 5, No. 1, Feb. 1987, pp. 1-11.

[3] Executable and Linkable Format (ELF),http://www.cs.northwestern.edu/~pdinda/ics-f01/doc/elf.pdf

[4] Debian GNU/Linux,http://www.debian.org/

[5] LSB testsuites, http://www.linuxbase.org/test/ ,ftp://ftp.freestandards.org/pub/lsb/test_suites/released-1.2.0/runtime/

Proceedings of theLinux Symposium

July 23th–26th, 2003Ottawa, Ontario

Canada

Conference Organizers

Andrew J. Hutton,Steamballoon, Inc.Stephanie Donovan,Linux SymposiumC. Craig Ross,Linux Symposium

Review Committee

Alan Cox,Red Hat, Inc.Andi Kleen,SuSE, GmbHMatthew Wilcox,Hewlett-PackardGerrit Huizenga,IBMAndrew J. Hutton,Steamballoon, Inc.C. Craig Ross,Linux SymposiumMartin K. Petersen,Wild Open Source, Inc.

Proceedings Formatting Team

John W. Lockhart,Red Hat, Inc.

Authors retain copyright to all submitted papers, but have granted unlimited redistribution rightsto all as a condition of submission.