[PATCH] target/sh4: Remove old README.sh4 file

[PATCH] target/sh4: Remove old README.sh4 file

[Thomas Huth]

This file didn't have any non-trivial update since it was initially
added in 2006, and looking at the content, it seems incredibly outdated,
saying e.g. "The sh4 target is not ready at all yet for integration in
qemu" or "A sh4 user-mode has also somewhat started but will be worked
on afterwards"... Sounds like nobody is interested in this README file
anymore, so let's simply remove it now.

Signed-off-by: Thomas Huth <thuth@redhat.com>
---
 target/sh4/README.sh4 | 150 ------------------------------------------
 1 file changed, 150 deletions(-)
 delete mode 100644 target/sh4/README.sh4

diff --git a/target/sh4/README.sh4 b/target/sh4/README.sh4
deleted file mode 100644
index a192ca7540..0000000000
--- a/target/sh4/README.sh4
+++ /dev/null
@@ -1,150 +0,0 @@
-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 "abort()".
-
-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
-https://web.archive.org/web/20070917001736/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.
-- 
2.27.0

Re: [PATCH] target/sh4: Remove old README.sh4 file

[Peter Maydell]

On Tue, 29 Mar 2022 at 16:22, Thomas Huth <thuth@redhat.com> wrote:
>
> This file didn't have any non-trivial update since it was initially
> added in 2006, and looking at the content, it seems incredibly outdated,
> saying e.g. "The sh4 target is not ready at all yet for integration in
> qemu" or "A sh4 user-mode has also somewhat started but will be worked
> on afterwards"... Sounds like nobody is interested in this README file
> anymore, so let's simply remove it now.
>
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---

Reviewed-by: Peter Maydell <peter.maydell@linaro.org>

thanks
-- PMM

Re: [PATCH] target/sh4: Remove old README.sh4 file

[Richard Henderson]

On 3/29/22 09:19, Thomas Huth wrote:
> This file didn't have any non-trivial update since it was initially
> added in 2006, and looking at the content, it seems incredibly outdated,
> saying e.g. "The sh4 target is not ready at all yet for integration in
> qemu" or "A sh4 user-mode has also somewhat started but will be worked
> on afterwards"... Sounds like nobody is interested in this README file
> anymore, so let's simply remove it now.
> 
> Signed-off-by: Thomas Huth<thuth@redhat.com>
> ---
>   target/sh4/README.sh4 | 150 ------------------------------------------
>   1 file changed, 150 deletions(-)
>   delete mode 100644 target/sh4/README.sh4

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

Re: [PATCH] target/sh4: Remove old README.sh4 file

[Yoshinori Sato]

On Wed, 30 Mar 2022 00:19:55 +0900,
Thomas Huth wrote:
> 
> This file didn't have any non-trivial update since it was initially
> added in 2006, and looking at the content, it seems incredibly outdated,
> saying e.g. "The sh4 target is not ready at all yet for integration in
> qemu" or "A sh4 user-mode has also somewhat started but will be worked
> on afterwards"... Sounds like nobody is interested in this README file
> anymore, so let's simply remove it now.
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
>  target/sh4/README.sh4 | 150 ------------------------------------------
>  1 file changed, 150 deletions(-)
>  delete mode 100644 target/sh4/README.sh4
> 
> diff --git a/target/sh4/README.sh4 b/target/sh4/README.sh4
> deleted file mode 100644
> index a192ca7540..0000000000
> --- a/target/sh4/README.sh4
> +++ /dev/null
> @@ -1,150 +0,0 @@
> -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 "abort()".
> -
> -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
> -https://web.archive.org/web/20070917001736/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.
> -- 
> 2.27.0
> 

Reviewed-by: Yoshinori Sato <ysato@users.sourceforge.jp>

-- 
Yosinori Sato

Re: [PATCH] target/sh4: Remove old README.sh4 file

[Laurent Vivier]

Le 29/03/2022 à 17:19, Thomas Huth a écrit :
> This file didn't have any non-trivial update since it was initially
> added in 2006, and looking at the content, it seems incredibly outdated,
> saying e.g. "The sh4 target is not ready at all yet for integration in
> qemu" or "A sh4 user-mode has also somewhat started but will be worked
> on afterwards"... Sounds like nobody is interested in this README file
> anymore, so let's simply remove it now.
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
>   target/sh4/README.sh4 | 150 ------------------------------------------
>   1 file changed, 150 deletions(-)
>   delete mode 100644 target/sh4/README.sh4
> 
> diff --git a/target/sh4/README.sh4 b/target/sh4/README.sh4
> deleted file mode 100644
> index a192ca7540..0000000000
> --- a/target/sh4/README.sh4
> +++ /dev/null
> @@ -1,150 +0,0 @@
> -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 "abort()".
> -
> -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
> -https://web.archive.org/web/20070917001736/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.

Applied to my trivial-patches branch.

Thanks,
Laurent