![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to README.sh4 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Qemu by Fabrice Bellard] / qemu / target-sh4|
Return to README.sh4 CVS log | Up to [Qemu by Fabrice Bellard] / qemu / target-sh4 |
1.1 root 1: qemu target: sh4
2: author: Samuel Tardieu <[email protected]>
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:
1.1.1.2 ! root 116: File names are hardcoded at this time. The bootloader must be stored in
1.1 root 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.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.