Statistics
| Branch: | Revision:

root / target-sh4 / README.sh4 @ 5fafdf24

History | View | Annotate | Download (4.8 kB)

1
qemu target:   sh4
2
author:        Samuel Tardieu <sam@rfc1149.net>
3
last modified: Tue Dec  6 07:22:44 CET 2005
4

    
5
The sh4 target is not ready at all yet for integration in qemu. This
6
file describes the current state of implementation.
7

    
8
Most places requiring attention and/or modification can be detected by
9
looking for "XXXXX" or "assert (0)".
10

    
11
The sh4 core is located in target-sh4/*, while the 7750 peripheral
12
features (IO ports for example) are located in hw/sh7750.[ch]. The
13
main board description is in hw/shix.c, and the NAND flash in
14
hw/tc58128.[ch].
15

    
16
All the shortcomings indicated here will eventually be resolved. This
17
is a work in progress. Features are added in a semi-random order: if a
18
point is blocking to progress on booting the Linux kernel for the shix
19
board, it is addressed first; if feedback is necessary and no progress
20
can be made on blocking points until it is received, a random feature
21
is worked on.
22

    
23
Goals
24
-----
25

    
26
The primary model being worked on is the soft MMU target to be able to
27
emulate the Shix 2.0 board by Alexis Polti, described at
28
http://perso.enst.fr/~polti/realisations/shix20/
29

    
30
Ultimately, qemu will be coupled with a system C or a verilog
31
simulator to simulate the whole board functionalities.
32

    
33
A sh4 user-mode has also somewhat started but will be worked on
34
afterwards. The goal is to automate tests for GNAT (GNU Ada) compiler
35
that I ported recently to the sh4-linux target.
36

    
37
Registers
38
---------
39

    
40
16 general purpose registers are available at any time. The first 8
41
registers are banked and the non-directly visible ones can be accessed
42
by privileged instructions. In qemu, we define 24 general purpose
43
registers and the code generation use either [0-7]+[8-15] or
44
[16-23]+[8-15] depending on the MD and RB flags in the sr
45
configuration register.
46

    
47
Instructions
48
------------
49

    
50
Most sh4 instructions have been implemented. The missing ones at this
51
time are:
52
  - FPU related instructions
53
  - LDTLB to load a new MMU entry
54
  - SLEEP to put the processor in sleep mode
55

    
56
Most instructions could be optimized a lot. This will be worked on
57
after the current model is fully functional unless debugging
58
convenience requires that it is done early.
59

    
60
Many instructions did not have a chance to be tested yet. The plan is
61
to implement unit and regression testing of those in the future.
62

    
63
MMU
64
---
65

    
66
The MMU is implemented in the sh4 core. MMU management has not been
67
tested at all yet. In the sh7750, it can be manipulated through memory
68
mapped registers and this part has not yet been implemented.
69

    
70
Exceptions
71
----------
72

    
73
Exceptions are implemented as described in the sh4 reference manual
74
but have not been tested yet. They do not use qemu EXCP_ features
75
yet.
76

    
77
IRQ
78
---
79

    
80
IRQ are not implemented yet.
81

    
82
Peripheral features
83
-------------------
84

    
85
  + Serial ports
86

    
87
Configuration and use of the first serial port (SCI) without
88
interrupts is supported. Input has not yet been tested.
89

    
90
Configuration of the second serial port (SCIF) is supported. FIFO
91
handling infrastructure has been started but is not completed yet.
92

    
93
  + GPIO ports
94

    
95
GPIO ports have been implemented. A registration function allows
96
external modules to register interest in some port changes (see
97
hw/tc58128.[ch] for an example) and will be called back. Interrupt
98
generation is not yet supported but some infrastructure is in place
99
for this purpose. Note that in the current model a peripheral module
100
cannot directly simulate a H->L->H input port transition and have an
101
interrupt generated on the low level.
102

    
103
  + TC58128 NAND flash
104

    
105
TC58128 NAND flash is partially implemented through GPIO ports. It
106
supports reading from flash.
107

    
108
GDB
109
---
110

    
111
GDB remote target support has been implemented and lightly tested.
112

    
113
Files
114
-----
115

    
116
File names are hardcoded at this time. The bootloader must be stored in
117
shix_bios.bin in the current directory. The initial Linux image must
118
be stored in shix_linux_nand.bin in the current directory in NAND
119
format. Test files can be obtained from
120
http://perso.enst.fr/~polti/robot/ as well as the various datasheets I
121
use.
122

    
123
qemu disk parameter on the command line is unused. You can supply any
124
existing image and it will be ignored. As the goal is to simulate an
125
embedded target, it is not clear how this parameter will be handled in
126
the future.
127

    
128
To build an ELF kernel image from the NAND image, 16 bytes have to be
129
stripped off the end of every 528 bytes, keeping only 512 of them. The
130
following Python code snippet does it:
131

    
132
#! /usr/bin/python
133

    
134
def denand (infd, outfd):
135
    while True:
136
        d = infd.read (528)
137
        if not d: return
138
        outfd.write (d[:512])
139

    
140
if __name__ == '__main__':
141
    import sys
142
    denand (open (sys.argv[1], 'rb'),
143
            open (sys.argv[2], 'wb'))
144
   
145
Style isssues
146
-------------
147

    
148
There is currently a mix between my style (space before opening
149
parenthesis) and qemu style. This will be resolved before final
150
integration is proposed.