]> git.proxmox.com Git - mirror_qemu.git/blame - target-sh4/README.sh4
kvm: Cleanup unmap condition in kvm_set_phys_mem (Jan Kiszka)
[mirror_qemu.git] / target-sh4 / README.sh4
CommitLineData
27c7ca7e
FB
1qemu target: sh4
2author: Samuel Tardieu <sam@rfc1149.net>
3last modified: Tue Dec 6 07:22:44 CET 2005
4
5The sh4 target is not ready at all yet for integration in qemu. This
6file describes the current state of implementation.
7
8Most places requiring attention and/or modification can be detected by
9looking for "XXXXX" or "assert (0)".
10
11The sh4 core is located in target-sh4/*, while the 7750 peripheral
12features (IO ports for example) are located in hw/sh7750.[ch]. The
13main board description is in hw/shix.c, and the NAND flash in
14hw/tc58128.[ch].
15
16All the shortcomings indicated here will eventually be resolved. This
17is a work in progress. Features are added in a semi-random order: if a
18point is blocking to progress on booting the Linux kernel for the shix
19board, it is addressed first; if feedback is necessary and no progress
20can be made on blocking points until it is received, a random feature
21is worked on.
22
23Goals
24-----
25
26The primary model being worked on is the soft MMU target to be able to
27emulate the Shix 2.0 board by Alexis Polti, described at
28http://perso.enst.fr/~polti/realisations/shix20/
29
30Ultimately, qemu will be coupled with a system C or a verilog
31simulator to simulate the whole board functionalities.
32
33A sh4 user-mode has also somewhat started but will be worked on
34afterwards. The goal is to automate tests for GNAT (GNU Ada) compiler
35that I ported recently to the sh4-linux target.
36
37Registers
38---------
39
4016 general purpose registers are available at any time. The first 8
41registers are banked and the non-directly visible ones can be accessed
42by privileged instructions. In qemu, we define 24 general purpose
43registers 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
45configuration register.
46
47Instructions
48------------
49
50Most sh4 instructions have been implemented. The missing ones at this
51time are:
52 - FPU related instructions
53 - LDTLB to load a new MMU entry
54 - SLEEP to put the processor in sleep mode
55
56Most instructions could be optimized a lot. This will be worked on
57after the current model is fully functional unless debugging
58convenience requires that it is done early.
59
60Many instructions did not have a chance to be tested yet. The plan is
61to implement unit and regression testing of those in the future.
62
63MMU
64---
65
66The MMU is implemented in the sh4 core. MMU management has not been
67tested at all yet. In the sh7750, it can be manipulated through memory
68mapped registers and this part has not yet been implemented.
69
70Exceptions
71----------
72
73Exceptions are implemented as described in the sh4 reference manual
74but have not been tested yet. They do not use qemu EXCP_ features
75yet.
76
77IRQ
78---
79
80IRQ are not implemented yet.
81
82Peripheral features
83-------------------
84
85 + Serial ports
86
87Configuration and use of the first serial port (SCI) without
88interrupts is supported. Input has not yet been tested.
89
90Configuration of the second serial port (SCIF) is supported. FIFO
91handling infrastructure has been started but is not completed yet.
92
93 + GPIO ports
94
95GPIO ports have been implemented. A registration function allows
96external modules to register interest in some port changes (see
97hw/tc58128.[ch] for an example) and will be called back. Interrupt
98generation is not yet supported but some infrastructure is in place
99for this purpose. Note that in the current model a peripheral module
100cannot directly simulate a H->L->H input port transition and have an
101interrupt generated on the low level.
102
103 + TC58128 NAND flash
104
105TC58128 NAND flash is partially implemented through GPIO ports. It
106supports reading from flash.
107
108GDB
109---
110
111GDB remote target support has been implemented and lightly tested.
112
113Files
114-----
115
9f083493 116File names are hardcoded at this time. The bootloader must be stored in
27c7ca7e
FB
117shix_bios.bin in the current directory. The initial Linux image must
118be stored in shix_linux_nand.bin in the current directory in NAND
119format. Test files can be obtained from
120http://perso.enst.fr/~polti/robot/ as well as the various datasheets I
121use.
122
123qemu disk parameter on the command line is unused. You can supply any
124existing image and it will be ignored. As the goal is to simulate an
125embedded target, it is not clear how this parameter will be handled in
126the future.
127
128To build an ELF kernel image from the NAND image, 16 bytes have to be
129stripped off the end of every 528 bytes, keeping only 512 of them. The
130following Python code snippet does it:
131
132#! /usr/bin/python
133
134def denand (infd, outfd):
135 while True:
136 d = infd.read (528)
137 if not d: return
138 outfd.write (d[:512])
139
140if __name__ == '__main__':
141 import sys
142 denand (open (sys.argv[1], 'rb'),
143 open (sys.argv[2], 'wb'))
3b46e624 144
27c7ca7e
FB
145Style isssues
146-------------
147
148There is currently a mix between my style (space before opening
149parenthesis) and qemu style. This will be resolved before final
150integration is proposed.