| 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 "abort()". | 
 |  | 
 | 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. |