From 27c7ca7e7750063f6e83e4d126bbd4de2d83f79e Mon Sep 17 00:00:00 2001 From: bellard Date: Thu, 27 Apr 2006 21:32:09 +0000 Subject: SHIX board emulation (Samuel Tardieu) git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@1862 c046a42c-6fe2-441c-8c8c-71466251a162 --- target-sh4/README.sh4 | 150 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 150 insertions(+) create mode 100644 target-sh4/README.sh4 (limited to 'target-sh4/README.sh4') diff --git a/target-sh4/README.sh4 b/target-sh4/README.sh4 new file mode 100644 index 0000000..b887175 --- /dev/null +++ b/target-sh4/README.sh4 @@ -0,0 +1,150 @@ +qemu target: sh4 +author: Samuel Tardieu +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 harcoded 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. -- cgit v1.1