qemu target:   sh4

author:        Samuel Tardieu <sam@rfc1149.net>

last modified: Tue Dec  6 07:22:44 CET 2005

The sh4 target is not ready at all yet for integration in qemu. This

file describes the current state of implementation.

Most places requiring attention and/or modification can be detected by

looking for "XXXXX" or "assert (0)".

The sh4 core is located in target-sh4/*, while the 7750 peripheral

features (IO ports for example) are located in hw/sh7750.[ch]. The

main board description is in hw/shix.c, and the NAND flash in

hw/tc58128.[ch].

All the shortcomings indicated here will eventually be resolved. This

is a work in progress. Features are added in a semi-random order: if a

point is blocking to progress on booting the Linux kernel for the shix

board, it is addressed first; if feedback is necessary and no progress

can be made on blocking points until it is received, a random feature

is worked on.

Goals

-----

The primary model being worked on is the soft MMU target to be able to

emulate the Shix 2.0 board by Alexis Polti, described at

http://perso.enst.fr/~polti/realisations/shix20/

Ultimately, qemu will be coupled with a system C or a verilog

simulator to simulate the whole board functionalities.

A sh4 user-mode has also somewhat started but will be worked on

afterwards. The goal is to automate tests for GNAT (GNU Ada) compiler

that I ported recently to the sh4-linux target.

Registers

---------

16 general purpose registers are available at any time. The first 8

registers are banked and the non-directly visible ones can be accessed

by privileged instructions. In qemu, we define 24 general purpose

registers and the code generation use either [0-7]+[8-15] or

[16-23]+[8-15] depending on the MD and RB flags in the sr

configuration register.

Instructions

------------

Most sh4 instructions have been implemented. The missing ones at this

time are:

  - FPU related instructions

  - LDTLB to load a new MMU entry

  - SLEEP to put the processor in sleep mode

Most instructions could be optimized a lot. This will be worked on

after the current model is fully functional unless debugging

convenience requires that it is done early.

Many instructions did not have a chance to be tested yet. The plan is

to implement unit and regression testing of those in the future.

MMU

---

The MMU is implemented in the sh4 core. MMU management has not been

tested at all yet. In the sh7750, it can be manipulated through memory

mapped registers and this part has not yet been implemented.

Exceptions

----------

Exceptions are implemented as described in the sh4 reference manual

but have not been tested yet. They do not use qemu EXCP_ features

yet.

IRQ

---

IRQ are not implemented yet.

Peripheral features

-------------------

  + Serial ports

Configuration and use of the first serial port (SCI) without

interrupts is supported. Input has not yet been tested.

Configuration of the second serial port (SCIF) is supported. FIFO

handling infrastructure has been started but is not completed yet.

  + GPIO ports

GPIO ports have been implemented. A registration function allows

external modules to register interest in some port changes (see

hw/tc58128.[ch] for an example) and will be called back. Interrupt

generation is not yet supported but some infrastructure is in place

for this purpose. Note that in the current model a peripheral module

cannot directly simulate a H->L->H input port transition and have an

interrupt generated on the low level.

  + TC58128 NAND flash

TC58128 NAND flash is partially implemented through GPIO ports. It

supports reading from flash.

GDB

---

GDB remote target support has been implemented and lightly tested.

Files

-----

File names are hardcoded at this time. The bootloader must be stored in

shix_bios.bin in the current directory. The initial Linux image must

be stored in shix_linux_nand.bin in the current directory in NAND

format. Test files can be obtained from

http://perso.enst.fr/~polti/robot/ as well as the various datasheets I

use.

qemu disk parameter on the command line is unused. You can supply any

existing image and it will be ignored. As the goal is to simulate an

embedded target, it is not clear how this parameter will be handled in

the future.

To build an ELF kernel image from the NAND image, 16 bytes have to be

stripped off the end of every 528 bytes, keeping only 512 of them. The

following Python code snippet does it:

#! /usr/bin/python

def denand (infd, outfd):

    while True:

        d = infd.read (528)

        if not d: return

        outfd.write (d[:512])

if __name__ == '__main__':

    import sys

    denand (open (sys.argv[1], 'rb'),

            open (sys.argv[2], 'wb'))

Style isssues

-------------

There is currently a mix between my style (space before opening

parenthesis) and qemu style. This will be resolved before final

integration is proposed.