File:  [Qemu by Fabrice Bellard] / qemu / target-sh4 / README.sh4
Revision (vendor branch): download - view: text, annotated - select for diffs
Tue Apr 24 16:47:44 2018 UTC (3 years, 9 months ago) by root
Branches: qemu, MAIN
CVS tags: qemu0125, qemu0124, qemu0123, qemu0122, qemu0121, qemu0120, qemu0111, qemu0110, qemu0105, qemu0104, qemu0103, qemu0102, qemu0101, qemu0100, qemu0091, HEAD
qemu 0.9.1

    1: qemu target:   sh4
    2: author:        Samuel Tardieu <>
    3: last modified: Tue Dec  6 07:22:44 CET 2005
    5: The sh4 target is not ready at all yet for integration in qemu. This
    6: file describes the current state of implementation.
    8: Most places requiring attention and/or modification can be detected by
    9: looking for "XXXXX" or "assert (0)".
   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].
   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.
   23: Goals
   24: -----
   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
   30: Ultimately, qemu will be coupled with a system C or a verilog
   31: simulator to simulate the whole board functionalities.
   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.
   37: Registers
   38: ---------
   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.
   47: Instructions
   48: ------------
   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
   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.
   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.
   63: MMU
   64: ---
   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.
   70: Exceptions
   71: ----------
   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.
   77: IRQ
   78: ---
   80: IRQ are not implemented yet.
   82: Peripheral features
   83: -------------------
   85:   + Serial ports
   87: Configuration and use of the first serial port (SCI) without
   88: interrupts is supported. Input has not yet been tested.
   90: Configuration of the second serial port (SCIF) is supported. FIFO
   91: handling infrastructure has been started but is not completed yet.
   93:   + GPIO ports
   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.
  103:   + TC58128 NAND flash
  105: TC58128 NAND flash is partially implemented through GPIO ports. It
  106: supports reading from flash.
  108: GDB
  109: ---
  111: GDB remote target support has been implemented and lightly tested.
  113: Files
  114: -----
  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: as well as the various datasheets I
  121: use.
  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.
  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:
  132: #! /usr/bin/python
  134: def denand (infd, outfd):
  135:     while True:
  136:         d = (528)
  137:         if not d: return
  138:         outfd.write (d[:512])
  140: if __name__ == '__main__':
  141:     import sys
  142:     denand (open (sys.argv[1], 'rb'),
  143:             open (sys.argv[2], 'wb'))
  145: Style isssues
  146: -------------
  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.