target-sh4/README.sh4

   1 qemu target:   sh4
   2 author:        Samuel Tardieu <sam@rfc1149.net>
   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
 116 File names are hardcoded at this time. The bootloader must be stored in
 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.