|
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. |