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