qemu target:   sh4author:        Samuel Tardieu <sam@rfc1149.net>last modified: Tue Dec  6 07:22:44 CET 2005The sh4 target is not ready at all yet for integration in qemu. Thisfile describes the current state of implementation.Most places requiring attention and/or modification can be detected bylooking for "XXXXX" or "assert (0)".The sh4 core is located in target-sh4/*, while the 7750 peripheralfeatures (IO ports for example) are located in hw/sh7750.[ch]. Themain board description is in hw/shix.c, and the NAND flash inhw/tc58128.[ch].All the shortcomings indicated here will eventually be resolved. Thisis a work in progress. Features are added in a semi-random order: if apoint is blocking to progress on booting the Linux kernel for the shixboard, it is addressed first; if feedback is necessary and no progresscan be made on blocking points until it is received, a random featureis worked on.Goals-----The primary model being worked on is the soft MMU target to be able toemulate the Shix 2.0 board by Alexis Polti, described athttp://perso.enst.fr/~polti/realisations/shix20/Ultimately, qemu will be coupled with a system C or a verilogsimulator to simulate the whole board functionalities.A sh4 user-mode has also somewhat started but will be worked onafterwards. The goal is to automate tests for GNAT (GNU Ada) compilerthat I ported recently to the sh4-linux target.Registers---------16 general purpose registers are available at any time. The first 8registers are banked and the non-directly visible ones can be accessedby privileged instructions. In qemu, we define 24 general purposeregisters and the code generation use either [0-7]+[8-15] or[16-23]+[8-15] depending on the MD and RB flags in the srconfiguration register.Instructions------------Most sh4 instructions have been implemented. The missing ones at thistime are:  - FPU related instructions  - LDTLB to load a new MMU entry  - SLEEP to put the processor in sleep modeMost instructions could be optimized a lot. This will be worked onafter the current model is fully functional unless debuggingconvenience requires that it is done early.Many instructions did not have a chance to be tested yet. The plan isto implement unit and regression testing of those in the future.MMU---The MMU is implemented in the sh4 core. MMU management has not beentested at all yet. In the sh7750, it can be manipulated through memorymapped registers and this part has not yet been implemented.Exceptions----------Exceptions are implemented as described in the sh4 reference manualbut have not been tested yet. They do not use qemu EXCP_ featuresyet.IRQ---IRQ are not implemented yet.Peripheral features-------------------  + Serial portsConfiguration and use of the first serial port (SCI) withoutinterrupts is supported. Input has not yet been tested.Configuration of the second serial port (SCIF) is supported. FIFOhandling infrastructure has been started but is not completed yet.  + GPIO portsGPIO ports have been implemented. A registration function allowsexternal modules to register interest in some port changes (seehw/tc58128.[ch] for an example) and will be called back. Interruptgeneration is not yet supported but some infrastructure is in placefor this purpose. Note that in the current model a peripheral modulecannot directly simulate a H->L->H input port transition and have aninterrupt generated on the low level.  + TC58128 NAND flashTC58128 NAND flash is partially implemented through GPIO ports. Itsupports 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 inshix_bios.bin in the current directory. The initial Linux image mustbe stored in shix_linux_nand.bin in the current directory in NANDformat. Test files can be obtained fromhttp://perso.enst.fr/~polti/robot/ as well as the various datasheets Iuse.qemu disk parameter on the command line is unused. You can supply anyexisting image and it will be ignored. As the goal is to simulate anembedded target, it is not clear how this parameter will be handled inthe future.To build an ELF kernel image from the NAND image, 16 bytes have to bestripped off the end of every 528 bytes, keeping only 512 of them. Thefollowing Python code snippet does it:#! /usr/bin/pythondef 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 openingparenthesis) and qemu style. This will be resolved before finalintegration is proposed.