sh: SE7750 board definition

This patch simply provides basic SE7750 board definition.

Signed-off-by Shin-ichiro KAWASAKI <[email protected]>

Index: trunk/target-sh4/machine.c
===================================================================

target-sh4/machine.c +1 -0

@@ -5,4 +5,5 @@
 {
     qemu_register_machine(&shix_machine);
     qemu_register_machine(&r2d_machine);
+    qemu_register_machine(&se7750_machine);
 }

Index: trunk/target-sh4/translate.c
===================================================================

target-sh4/translate.c +6 -0

@@ -212,6 +212,12 @@
 
 static sh4_def_t sh4_defs[] = {
     {
+	.name = "SH7750",
+	.id = SH_CPU_SH7750,
+	.pvr = 0x04020500,
+	.prr = 0x00000000,
+	.cvr = 0x00000000,
+    }, {
 	.name = "SH7750R",
 	.id = SH_CPU_SH7750R,
 	.pvr = 0x00050000,

Index: trunk/Makefile.target
===================================================================

Makefile.target +1 -1

@@ -719,7 +719,7 @@
 CPPFLAGS += -DHAS_AUDIO
 endif
 ifeq ($(TARGET_BASE_ARCH), sh4)
-OBJS+= shix.o r2d.o sh7750.o sh7750_regnames.o tc58128.o
+OBJS+= shix.o r2d.o se.o sh7750.o sh7750_regnames.o tc58128.o
 OBJS+= sh_timer.o ptimer.o sh_serial.o sh_intc.o sh_pci.o sm501.o serial.o
 OBJS+= ide.o
 endif

Index: trunk/hw/se.c
===================================================================

hw/se.c +94 -0

@@ -0,0 +1,94 @@
+/*
+ * Hitachi ULSI Systems' evaludation boards, Solution Engine emulation.
+ *
+ * Copyright (c) 2008 Shin-ichiro KAWASAKI
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "hw.h"
+#include "sh.h"
+#include "sysemu.h"
+#include "boards.h"
+#include "sh7750_regs.h"
+
+#define SDRAM_BASE   0x0c000000 /* Physical location of SDRAM: Area 3 */
+#define SDRAM_SIZE   0x02000000
+#define ENTRY_OFFSET 0x00001000
+#define COMMAND_LINE_OFFSET 0x0000100
+
+static void se7750_init(ram_addr_t ram_size, int vga_ram_size,
+                    const char *boot_device, DisplayState * ds,
+                    const char *kernel_filename, const char *kernel_cmdline,
+                    const char *initrd_filename, const char *cpu_model)
+{
+    CPUState *env;
+    struct SH7750State *s;
+    ram_addr_t sdram_addr;
+    int kernel_size;
+    uint8 * phys_load_addr = phys_ram_base;
+
+    /* initialize CPU */
+    if (!cpu_model)
+        cpu_model = "SH7750";
+
+    env = cpu_init(cpu_model);
+    if (!env) {
+        fprintf(stderr, "Unable to find CPU definition\n");
+        exit(1);
+    }
+
+    /* Allocate memory space */
+    sdram_addr = qemu_ram_alloc(SDRAM_SIZE);
+    cpu_register_physical_memory(SDRAM_BASE, SDRAM_SIZE, sdram_addr);
+
+    /* Register peripherals */
+    s = sh7750_init(env);
+
+    /* initialization which should be done by firmware */
+    uint32_t bcr1 = 1 << 3; /* cs3 SDRAM */
+    uint16_t bcr2 = 3 << (3 * 2); /* cs3 32-bit */
+    cpu_physical_memory_write(SH7750_BCR1_A7, (uint8_t *)&bcr1, 4);
+    cpu_physical_memory_write(SH7750_BCR2_A7, (uint8_t *)&bcr2, 2);
+
+    /* Start from P2 area */
+    env->pc = SDRAM_BASE | 0xa0000000;
+
+    /* pass kernel cmdline */
+    if (kernel_cmdline) {
+        pstrcpy((char *)phys_load_addr + ENTRY_OFFSET + COMMAND_LINE_OFFSET,
+                strlen(kernel_cmdline) + 1, kernel_cmdline);
+        env->pc += 0x80000;
+        phys_load_addr += 0x80000;
+    }
+
+    /* load kernel image */
+    kernel_size = load_image(kernel_filename, phys_load_addr);
+    if (kernel_size < 0) {
+        fprintf(stderr, "qemu: could not load kernel '%s'\n", kernel_filename);
+        exit(1);
+    }
+}
+
+QEMUMachine se7750_machine = {
+    .name = "se7750",
+    .desc = "Solution Engine SH7750 board",
+    .init = se7750_init,
+    .ram_require = SDRAM_SIZE | RAMSIZE_FIXED,
+};

Index: trunk/hw/boards.h
===================================================================

hw/boards.h +3 -0

@@ -60,6 +60,9 @@
 /* r2d.c */
 extern QEMUMachine r2d_machine;
 
+/* se.c */
+extern QEMUMachine se7750_machine;
+
 /* sun4m.c */
 extern QEMUMachine ss5_machine, ss10_machine, ss600mp_machine, ss20_machine;
 extern QEMUMachine voyager_machine, ss_lx_machine, ss4_machine, scls_machine;

This patch simply provides basic SE7750 board definition.

Signed-off-by Shin-ichiro KAWASAKI <[email protected]>

Index: trunk/target-sh4/machine.c
===================================================================

target-sh4/machine.c +1 -0

@@ -5,4 +5,5 @@
 {
     qemu_register_machine(&shix_machine);
     qemu_register_machine(&r2d_machine);
+    qemu_register_machine(&se7750_machine);
 }

Index: trunk/target-sh4/translate.c
===================================================================

target-sh4/translate.c +6 -0

@@ -212,6 +212,12 @@
 
 static sh4_def_t sh4_defs[] = {
     {
+	.name = "SH7750",
+	.id = SH_CPU_SH7750,
+	.pvr = 0x04020500,
+	.prr = 0x00000000,
+	.cvr = 0x00000000,
+    }, {
 	.name = "SH7750R",
 	.id = SH_CPU_SH7750R,
 	.pvr = 0x00050000,

Index: trunk/Makefile.target
===================================================================

Makefile.target +1 -1

@@ -719,7 +719,7 @@
 CPPFLAGS += -DHAS_AUDIO
 endif
 ifeq ($(TARGET_BASE_ARCH), sh4)
-OBJS+= shix.o r2d.o sh7750.o sh7750_regnames.o tc58128.o
+OBJS+= shix.o r2d.o se.o sh7750.o sh7750_regnames.o tc58128.o
 OBJS+= sh_timer.o ptimer.o sh_serial.o sh_intc.o sh_pci.o sm501.o serial.o
 OBJS+= ide.o
 endif

Index: trunk/hw/se.c
===================================================================

hw/se.c +25 -0

@@ -0,0 +1,94 @@
+/*
+ * Hitachi ULSI Systems' evaludation boards, Solution Engine emulation.
+ *
+ * Copyright (c) 2008 Shin-ichiro KAWASAKI
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "hw.h"

hw/se.c +22 -0

+
+static void se7750_init(ram_addr_t ram_size, int vga_ram_size,
+                    const char *boot_device, DisplayState * ds,
+                    const char *kernel_filename, const char *kernel_cmdline,
+                    const char *initrd_filename, const char *cpu_model)
+{
+    CPUState *env;
+    struct SH7750State *s;
+    ram_addr_t sdram_addr;
+    int kernel_size;
+    uint8 * phys_load_addr = phys_ram_base;
+
+    /* initialize CPU */
+    if (!cpu_model)
+        cpu_model = "SH7750";
+
+    env = cpu_init(cpu_model);
+    if (!env) {
+        fprintf(stderr, "Unable to find CPU definition\n");
+        exit(1);
+    }
+

hw/se.c line 34

Quoted 5 lines

hw/se.c +4 -0

+#define SDRAM_BASE   0x0c000000 /* Physical location of SDRAM: Area 3 */
+#define SDRAM_SIZE   0x02000000
 
+#define ENTRY_OFFSET 0x00001000
+#define COMMAND_LINE_OFFSET 0x0000100

IIRC it's the case for all SH4 maybe we could define it in a header and all board to overwrite it

Quoted 25 lines

hw/se.c +25 -0

+
+static void se7750_init(ram_addr_t ram_size, int vga_ram_size,
+                    const char *boot_device, DisplayState * ds,
+                    const char *kernel_filename, const char *kernel_cmdline,
+                    const char *initrd_filename, const char *cpu_model)
+{
+    CPUState *env;
+    struct SH7750State *s;
+    ram_addr_t sdram_addr;
+    int kernel_size;
+    uint8 * phys_load_addr = phys_ram_base;
+
+    /* initialize CPU */
+    if (!cpu_model)
+        cpu_model = "SH7750";
+
+    env = cpu_init(cpu_model);
+    if (!env) {
+        fprintf(stderr, "Unable to find CPU definition\n");
+        exit(1);
+    }
+
+    /* Allocate memory space */
+    sdram_addr = qemu_ram_alloc(SDRAM_SIZE);
+    cpu_register_physical_memory(SDRAM_BASE, SDRAM_SIZE, sdram_addr);

hw/se.c line 66

Quoted 7 lines

hw/se.c +7 -0

+
+    /* Register peripherals */
+    s = sh7750_init(env);
+
+    /* initialization which should be done by firmware */
+    uint32_t bcr1 = 1 << 3; /* cs3 SDRAM */
+    uint16_t bcr2 = 3 << (3 * 2); /* cs3 32-bit */

please move tihs too the beginning of the function

Quoted 6 lines

hw/se.c +6 -0

+    cpu_physical_memory_write(SH7750_BCR1_A7, (uint8_t *)&bcr1, 4);
+    cpu_physical_memory_write(SH7750_BCR2_A7, (uint8_t *)&bcr2, 2);
+
+    /* Start from P2 area */
+    env->pc = SDRAM_BASE | 0xa0000000;
+

hw/se.c line 79

Quoted 7 lines

hw/se.c +7 -0

+    /* pass kernel cmdline */
+    if (kernel_cmdline) {
+        pstrcpy((char *)phys_load_addr + ENTRY_OFFSET + COMMAND_LINE_OFFSET,
+                strlen(kernel_cmdline) + 1, kernel_cmdline);
+        env->pc += 0x80000;
+        phys_load_addr += 0x80000;
+    }

do you known the flash model present on the real board?

Quoted 7 lines

Quoted 7 lines

hw/se.c +7 -0

+    cpu_physical_memory_write(SH7750_BCR1_A7, (uint8_t *)&bcr1, 4);
+    cpu_physical_memory_write(SH7750_BCR2_A7, (uint8_t *)&bcr2, 2);
+
+    /* Start from P2 area */
+    env->pc = SDRAM_BASE | 0xa0000000;
+
+    /* pass kernel cmdline */

Quoted 8 lines

hw/se.c line 79

Quoted 7 lines

(quoted diff) +2 -0

+    if (kernel_cmdline) {
+        pstrcpy((char *)phys_load_addr + ENTRY_OFFSET + 

COMMAND_LINE_OFFSET,

hw/se.c +4 -0

+                strlen(kernel_cmdline) + 1, kernel_cmdline);
+        env->pc += 0x80000;
+        phys_load_addr += 0x80000;
+    }

do you known the flash model present on the real board?

No, I don't.
The patches for SE7750 are all implemented using informations in linux source code.
I visited Solution Engine site (in Japanese) but could not find useful specs.
http://www.hitachi-ul.co.jp/system/SH-SE/shiyou.html

Quoted 15 lines · Shin-ichiro KAWASAKI

Quoted 7 lines

Quoted 7 lines

hw/se.c +7 -0

+    cpu_physical_memory_write(SH7750_BCR1_A7, (uint8_t *)&bcr1, 4);
+    cpu_physical_memory_write(SH7750_BCR2_A7, (uint8_t *)&bcr2, 2);
+
+    /* Start from P2 area */
+    env->pc = SDRAM_BASE | 0xa0000000;
+
+    /* pass kernel cmdline */

Quoted 8 lines

hw/se.c line 79

Quoted 7 lines

(quoted diff) +2 -0

+    if (kernel_cmdline) {
+        pstrcpy((char *)phys_load_addr + ENTRY_OFFSET + 

COMMAND_LINE_OFFSET,

hw/se.c +4 -0

+                strlen(kernel_cmdline) + 1, kernel_cmdline);
+        env->pc += 0x80000;
+        phys_load_addr += 0x80000;
+    }

do you known the flash model present on the real board?

Quoted 7 lines

No, I don't.
The patches for SE7750 are all implemented using informations in linux source code.
I visited Solution Engine site (in Japanese) but could not find useful specs.
http://www.hitachi-ul.co.jp/system/SH-SE/shiyou.html

I haven't seen one of these boards in at least 7 years, so I can't help you with specifications. Yoshii-san or Iwamatsu-san might know, though? SE7751 should have the same flash model and layout IIRC.

Quoted 23 lines · Paul Mundt

Quoted 15 lines · Shin-ichiro KAWASAKI

Quoted 7 lines

Quoted 7 lines

hw/se.c +7 -0

+    cpu_physical_memory_write(SH7750_BCR1_A7, (uint8_t *)&bcr1, 4);
+    cpu_physical_memory_write(SH7750_BCR2_A7, (uint8_t *)&bcr2, 2);
+
+    /* Start from P2 area */
+    env->pc = SDRAM_BASE | 0xa0000000;
+
+    /* pass kernel cmdline */

Quoted 8 lines

hw/se.c line 79

Quoted 7 lines

(quoted diff) +2 -0

+    if (kernel_cmdline) {
+        pstrcpy((char *)phys_load_addr + ENTRY_OFFSET +  

COMMAND_LINE_OFFSET,

hw/se.c +4 -0

+                strlen(kernel_cmdline) + 1, kernel_cmdline);
+        env->pc += 0x80000;
+        phys_load_addr += 0x80000;
+    }

do you known the flash model present on the real board?

Quoted 7 lines

No, I don't.
The patches for SE7750 are all implemented using informations in linux source code.
I visited Solution Engine site (in Japanese) but could not find useful specs.
http://www.hitachi-ul.co.jp/system/SH-SE/shiyou.html

Quoted 4 lines

I haven't seen one of these boards in at least 7 years, so I can't help you with specifications. Yoshii-san or Iwamatsu-san might know, though? SE7751 should have the same flash model and layout IIRC.

This board can not get from Hitachi-ULSI now and this is too old. I can send it later by examining the flash memory of this board. # I do not understand the meaning that supports this board ....

BTW, I have question about Qemu-sh board support. Does the developer of Qemu-SH try to support all boards? I think that it is good to make it the base of Qemu-SH by thinking about one board as virtual as MIPS.

Because first of all, I am not so interested in the support of the board. I am interested in emulation of CPU and the userland.
In the current situation, the number of supported real boards increases when the support of CPU increases. The code of the board enters whenever CPU is supported.
I think that you should decide a virtual board of SH and switch CPU.

Quoted 37 lines · Nobuhiro Iwamatsu

Quoted 23 lines · Paul Mundt

Quoted 15 lines · Shin-ichiro KAWASAKI

Quoted 7 lines

Quoted 7 lines

hw/se.c +7 -0

+    cpu_physical_memory_write(SH7750_BCR1_A7, (uint8_t *)&bcr1, 4);
+    cpu_physical_memory_write(SH7750_BCR2_A7, (uint8_t *)&bcr2, 2);
+
+    /* Start from P2 area */
+    env->pc = SDRAM_BASE | 0xa0000000;
+
+    /* pass kernel cmdline */

Quoted 8 lines

hw/se.c line 79

Quoted 7 lines

(quoted diff) +2 -0

+    if (kernel_cmdline) {
+        pstrcpy((char *)phys_load_addr + ENTRY_OFFSET +  

COMMAND_LINE_OFFSET,

hw/se.c +4 -0

+                strlen(kernel_cmdline) + 1, kernel_cmdline);
+        env->pc += 0x80000;
+        phys_load_addr += 0x80000;
+    }

do you known the flash model present on the real board?

Quoted 7 lines

No, I don't.
The patches for SE7750 are all implemented using informations in linux source code.
I visited Solution Engine site (in Japanese) but could not find useful specs.
http://www.hitachi-ul.co.jp/system/SH-SE/shiyou.html

Quoted 4 lines

I haven't seen one of these boards in at least 7 years, so I can't help you with specifications. Yoshii-san or Iwamatsu-san might know, though? SE7751 should have the same flash model and layout IIRC.

This board can not get from Hitachi-ULSI now and this is too old. I can send it later by examining the flash memory of this board. # I do not understand the meaning that supports this board ....

BTW, I have question about Qemu-sh board support. Does the developer of Qemu-SH try to support all boards? I think that it is good to make it the base of Qemu-SH by thinking about one board as virtual as MIPS.

Quoted 6 lines

Because first of all, I am not so interested in the support of the board. I am interested in emulation of CPU and the userland.
In the current situation, the number of supported real boards increases when the support of CPU increases. The code of the board enters whenever CPU is supported.
I think that you should decide a virtual board of SH and switch CPU.

A virtual board is good to test CPU and different IPs, but you can not compare the comportment of qemu against the real hard. IMHO, this is the more important part for supporting new boards.

Because first of all, I am not so interested in the support of the board. I am interested in emulation of CPU and the userland.
In the current situation, the number of supported real boards increases when the support of CPU increases. The code of the board enters whenever CPU is supported.

Quoted 5 lines · Nobuhiro Iwamatsu

Because first of all, I am not so interested in the support of the board. I am interested in emulation of CPU and the userland.
In the current situation, the number of supported real boards increases when the support of CPU increases. The code of the board enters whenever CPU is supported.

I agree. I was very surprised to find last Sunday that a simple instruction such as FMAC was not implemented. I wonder how many holes are still there.

Quoted 23 lines · Paul Mundt

Quoted 22 lines · Shin-ichiro KAWASAKI

Quoted 7 lines

Quoted 7 lines

hw/se.c +7 -0

+    cpu_physical_memory_write(SH7750_BCR1_A7, (uint8_t *)&bcr1, 4);
+    cpu_physical_memory_write(SH7750_BCR2_A7, (uint8_t *)&bcr2, 2);
+
+    /* Start from P2 area */
+    env->pc = SDRAM_BASE | 0xa0000000;
+
+    /* pass kernel cmdline */

Quoted 8 lines

hw/se.c line 79

Quoted 7 lines

(quoted diff) +2 -0

+    if (kernel_cmdline) {
+        pstrcpy((char *)phys_load_addr + ENTRY_OFFSET + 

COMMAND_LINE_OFFSET,

hw/se.c +4 -0

+                strlen(kernel_cmdline) + 1, kernel_cmdline);
+        env->pc += 0x80000;
+        phys_load_addr += 0x80000;
+    }

do you known the flash model present on the real board?

No, I don't.
The patches for SE7750 are all implemented using informations in linux source code.
I visited Solution Engine site (in Japanese) but could not find useful specs.
http://www.hitachi-ul.co.jp/system/SH-SE/shiyou.html

Quoted 4 lines

I haven't seen one of these boards in at least 7 years, so I can't help you with specifications. Yoshii-san or Iwamatsu-san might know, though? SE7751 should have the same flash model and layout IIRC.

This board can not get from Hitachi-ULSI now and this is too old. I can send it later by examining the flash memory of this board. # I do not understand the meaning that supports this board ....

BTW, I have question about Qemu-sh board support. Does the developer of Qemu-SH try to support all boards? I think that it is good to make it the base of Qemu-SH by thinking about one board as virtual as MIPS.

Because first of all, I am not so interested in the support of the board. I am interested in emulation of CPU and the userland.
In the current situation, the number of supported real boards increases when the support of CPU increases. The code of the board enters whenever CPU is supported.
I think that you should decide a virtual board of SH and switch CPU.

How about you?

Quoted 24 lines · Nobuhiro Iwamatsu

Quoted 23 lines · Paul Mundt

Quoted 22 lines · Shin-ichiro KAWASAKI

Quoted 7 lines

Quoted 7 lines

hw/se.c +7 -0

+    cpu_physical_memory_write(SH7750_BCR1_A7, (uint8_t *)&bcr1, 4);
+    cpu_physical_memory_write(SH7750_BCR2_A7, (uint8_t *)&bcr2, 2);
+
+    /* Start from P2 area */
+    env->pc = SDRAM_BASE | 0xa0000000;
+
+    /* pass kernel cmdline */

Quoted 8 lines

hw/se.c line 79

Quoted 7 lines

(quoted diff) +2 -0

+    if (kernel_cmdline) {
+        pstrcpy((char *)phys_load_addr + ENTRY_OFFSET + 

COMMAND_LINE_OFFSET,

hw/se.c +4 -0

+                strlen(kernel_cmdline) + 1, kernel_cmdline);
+        env->pc += 0x80000;
+        phys_load_addr += 0x80000;
+    }

do you known the flash model present on the real board?

No, I don't.
The patches for SE7750 are all implemented using informations in linux source code.
I visited Solution Engine site (in Japanese) but could not find useful specs.
http://www.hitachi-ul.co.jp/system/SH-SE/shiyou.html

Quoted 7 lines

Quoted 4 lines

I haven't seen one of these boards in at least 7 years, so I can't help you with specifications. Yoshii-san or Iwamatsu-san might know, though? SE7751 should have the same flash model and layout IIRC.

This board can not get from Hitachi-ULSI now and this is too old. I can send it later by examining the flash memory of this board. # I do not understand the meaning that supports this board ....

I should have explained it. To avoid messy many board support, board should be selected carefully.

I wanted a board which can test SCI (not SCIF) console emulation. I'm sure that SE7750 supports both SCI and SCIF, and it is suitable to check SCI work. For this purpose, any other board is OK if it uses SCI for console.

# The reason I stick to SCI is r2d+ board's RTC. The r2d+ board uses # SCI not for console but for SPI connection with RTC chip. Before

# thinking about RTC emulation, SCI emulation should be done.

Another reason for SE7750 is support for TOPPERS. TOPPERS is an open source realtime OS. I think QEMU will be a strong tool for TOPPERS developers. They already utilizes SkyEye, the ARM dedicated CPU simulator for board-less development. Of course SkyEye cannot be used for the work for SuperH.

Here's the list of the CPUs and boards which can run TOPPERS.
http://www.toppers.jp/en/jsp-kernel-e.html
SE7750 is the only one board which has SuperH, can run TOPPERS, and has Linux kernel's default config.

We should focus on completing SH-Linux emulation before thinking about other OSes. But if I have to add new board emulation, I think SE7750 is a good choice.

Quoted 14 lines

BTW, I have question about Qemu-sh board support. Does the developer of Qemu-SH try to support all boards? I think that it is good to make it the base of Qemu-SH by thinking about one board as virtual as MIPS.

Because first of all, I am not so interested in the support of the board. I am interested in emulation of CPU and the userland.
In the current situation, the number of supported real boards increases when the support of CPU increases. The code of the board enters whenever CPU is supported.
I think that you should decide a virtual board of SH and switch CPU.

Quoted 1 line

How about you?

Good idea. I agree that virtual board is useful. I wonder how linux kernel config will be.
Or on what kind of policy, its specs should be decided?

Quoted 25 lines · Shin-ichiro KAWASAKI

Quoted 24 lines · Nobuhiro Iwamatsu

Quoted 23 lines · Paul Mundt

Quoted 22 lines · Shin-ichiro KAWASAKI

Quoted 7 lines

Quoted 7 lines

(quoted diff) +7 -0

+    cpu_physical_memory_write(SH7750_BCR1_A7, (uint8_t *)&bcr1, 4);
+    cpu_physical_memory_write(SH7750_BCR2_A7, (uint8_t *)&bcr2, 2);
+
+    /* Start from P2 area */
+    env->pc = SDRAM_BASE | 0xa0000000;
+
+    /* pass kernel cmdline */

Quoted 8 lines

Review

Quoted 7 lines

(quoted diff) +2 -0

+    if (kernel_cmdline) {
+        pstrcpy((char *)phys_load_addr + ENTRY_OFFSET + 

COMMAND_LINE_OFFSET,

(quoted diff) +4 -0

+                strlen(kernel_cmdline) + 1, kernel_cmdline);
+        env->pc += 0x80000;
+        phys_load_addr += 0x80000;
+    }

do you known the flash model present on the real board?

No, I don't.
The patches for SE7750 are all implemented using informations in linux source code.
I visited Solution Engine site (in Japanese) but could not find useful specs.
http://www.hitachi-ul.co.jp/system/SH-SE/shiyou.html

Quoted 7 lines

Quoted 7 lines

Quoted 4 lines

I haven't seen one of these boards in at least 7 years, so I can't help you with specifications. Yoshii-san or Iwamatsu-san might know, though? SE7751 should have the same flash model and layout IIRC.

This board can not get from Hitachi-ULSI now and this is too old. I can send it later by examining the flash memory of this board. # I do not understand the meaning that supports this board ....

Flash model is 29lv160t.

Quoted 4 lines

I should have explained it. To avoid messy many board support, board should be selected carefully.

Quoted 8 lines

I wanted a board which can test SCI (not SCIF) console emulation. I'm sure that SE7750 supports both SCI and SCIF, and it is suitable to check SCI work. For this purpose, any other board is OK if it uses SCI for console.

# The reason I stick to SCI is r2d+ board's RTC. The r2d+ board uses # SCI not for console but for SPI connection with RTC chip. Before

# thinking about RTC emulation, SCI emulation should be done.

OK.

Quoted 7 lines

Another reason for SE7750 is support for TOPPERS. TOPPERS is an open source realtime OS. I think QEMU will be a strong tool for TOPPERS developers. They already utilizes SkyEye, the ARM dedicated CPU simulator for board-less development. Of course SkyEye cannot be used for the work for SuperH.

Quoted 8 lines

Here's the list of the CPUs and boards which can run TOPPERS.
http://www.toppers.jp/en/jsp-kernel-e.html
SE7750 is the only one board which has SuperH, can run TOPPERS, and has Linux kernel's default config.

We should focus on completing SH-Linux emulation before thinking about other OSes. But if I have to add new board emulation, I think SE7750 is a good choice.

I understood.
But this board can not get now and CPU is too old. And you don't have this. How do you develop this board and IP?

# Does the development of SH of Toppers still continue?

Quoted 13 lines

Quoted 13 lines

BTW, I have question about Qemu-sh board support. Does the developer of Qemu-SH try to support all boards? I think that it is good to make it the base of Qemu-SH by thinking about one board as virtual as MIPS.

Because first of all, I am not so interested in the support of the board.
I am interested in emulation of CPU and the userland.
In the current situation, the number of supported real boards increases when the support of CPU increases. The code of the board enters whenever CPU is supported.
I think that you should decide a virtual board of SH and switch CPU.

Quoted 4 lines

Quoted 1 line

How about you?

Good idea. I agree that virtual board is useful. I wonder how linux kernel config will be.
Or on what kind of policy, its specs should be decided?

I think that the Qemu-sh developer talk about it.
# Though the talk might be not settled....
Or get from other architectures (ex. MIPS).

Or I thought create of configurable mechanism to be good.

Quoted 16 lines

Quoted 7 lines

Another reason for SE7750 is support for TOPPERS. TOPPERS is an open source realtime OS. I think QEMU will be a strong tool for TOPPERS developers. They already utilizes SkyEye, the ARM dedicated CPU simulator for board-less development. Of course SkyEye cannot be used for the work for SuperH.

Quoted 8 lines

Here's the list of the CPUs and boards which can run TOPPERS.
http://www.toppers.jp/en/jsp-kernel-e.html
SE7750 is the only one board which has SuperH, can run TOPPERS, and has Linux kernel's default config.

We should focus on completing SH-Linux emulation before thinking about other OSes. But if I have to add new board emulation, I think SE7750 is a good choice.

Quoted 5 lines

I understood.
But this board can not get now and CPU is too old. And you don't have this. How do you develop this board and IP?

# Does the development of SH of Toppers still continue?

Right, the board's not available. It is a problem, even though some amount of development can be done from SH-Linux source code and chip specifications.

I posted a mail to TOPPERS users ML, and got an advice that the type of board is not so important to run TOPPERS kernel. So, now I think I should not stick to SE7750.
# Development of SH Toppers seems going.

Quoted 13 lines

Quoted 13 lines

BTW, I have question about Qemu-sh board support.

Quoted 12 lines

Does the developer of Qemu-SH try to support all boards? I think that it is good to make it the base of Qemu-SH by thinking about one board as virtual as MIPS.

Because first of all, I am not so interested in the support of the board.
I am interested in emulation of CPU and the userland.
In the current situation, the number of supported real boards increases when the support of CPU increases. The code of the board enters whenever CPU is supported.
I think that you should decide a virtual board of SH and switch CPU.

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

How about you?

Good idea. I agree that virtual board is useful. I wonder how linux kernel config will be.
Or on what kind of policy, its specs should be decided?

I think that the Qemu-sh developer talk about it.
# Though the talk might be not settled....
Or get from other architectures (ex. MIPS).

I guess you mean "hw/mips_mipssim.c". It seems emulate MIPSsim, the MIPS emulator. In a same way, "hw/sh_virtual_board.c" or "hw/sh_pseudo_machine.c" can be implemented. It will be useful to check how SH CPU cores and its SoC internal IPs work.

Quoted 1 line

Or I thought create of configurable mechanism to be good.

Once machine config file was discussed on this ML. It will be useful for qemu-sh also, I think.

Quoted 8 lines · Nobuhiro Iwamatsu

Quoted 4 lines · Paul Mundt

I haven't seen one of these boards in at least 7 years, so I can't help you with specifications. Yoshii-san or Iwamatsu-san might know, though? SE7751 should have the same flash model and layout IIRC.

This board can not get from Hitachi-ULSI now and this is too old. I can send it later by examining the flash memory of this board. # I do not understand the meaning that supports this board ....

I should have explained it. To avoid messy many board support, board should be selected carefully.

I wanted a board which can test SCI (not SCIF) console emulation. I'm sure that SE7750 supports both SCI and SCIF, and it is suitable to check SCI work. For this purpose, any other board is OK if it uses SCI for console.

# The reason I stick to SCI is r2d+ board's RTC. The r2d+ board uses # SCI not for console but for SPI connection with RTC chip. Before

# thinking about RTC emulation, SCI emulation should be done.

Another reason for SE7750 is support for TOPPERS. TOPPERS is an open source realtime OS. I think QEMU will be a strong tool for TOPPERS developers. They already utilizes SkyEye, the ARM dedicated CPU simulator for board-less development. Of course SkyEye cannot be used for the work for SuperH.

Here's the list of the CPUs and boards which can run TOPPERS.
http://www.toppers.jp/en/jsp-kernel-e.html
SE7750 is the only one board which has SuperH, can run TOPPERS, and has Linux kernel's default config.

We should focus on completing SH-Linux emulation before thinking about other OSes. But if I have to add new board emulation, I think SE7750 is a good choice.

Quoted 12 lines · Shin-ichiro KAWASAKI

Quoted 8 lines · Nobuhiro Iwamatsu

Quoted 4 lines · Paul Mundt

I haven't seen one of these boards in at least 7 years, so I can't help you with specifications. Yoshii-san or Iwamatsu-san might know, though? SE7751 should have the same flash model and layout IIRC.

This board can not get from Hitachi-ULSI now and this is too old. I can send it later by examining the flash memory of this board. # I do not understand the meaning that supports this board ....

I should have explained it. To avoid messy many board support, board should be selected carefully.

Quoted 9 lines

I wanted a board which can test SCI (not SCIF) console emulation. I'm sure that SE7750 supports both SCI and SCIF, and it is suitable to check SCI work. For this purpose, any other board is OK if it uses SCI for console.

# The reason I stick to SCI is r2d+ board's RTC. The r2d+ board uses # SCI not for console but for SPI connection with RTC chip. Before

# thinking about RTC emulation, SCI emulation should be done.

SCI is pretty much a relic at this point. No current hardware uses it, and there isn't much point in spending too much effort supporting legacy hardware. R2D does use the SCI for SPI bitbang for the RTC, but all other SH platforms either use the SH-RTC directly or something hanging off of I2C. SPI bitbang is pretty much a corner case for the SH platforms, it would be much more useful to see SH-RTC emulation. R2D is basically the only platform that wants SCI anyways.

Quoted 6 lines

Another reason for SE7750 is support for TOPPERS. TOPPERS is an open source realtime OS. I think QEMU will be a strong tool for TOPPERS developers. They already utilizes SkyEye, the ARM dedicated CPU simulator for board-less development. Of course SkyEye cannot be used for the work for SuperH.

Quoted 9 lines

Here's the list of the CPUs and boards which can run TOPPERS.
http://www.toppers.jp/en/jsp-kernel-e.html
SE7750 is the only one board which has SuperH, can run TOPPERS, and has Linux kernel's default config.

We should focus on completing SH-Linux emulation before thinking about other OSes. But if I have to add new board emulation, I think SE7750 is a good choice.

Supporting other OSes is good, but standardizing on SE7750 doesn't seem like it will really help anything, given all of the legacy SH-4 stuff it drags along with it. If we are going to standardize on a board, it should be something current, something that is readily available in hardware, and something that people are actively using. The SE7750 does not meet any of these requirements, nor does any other SH-4. Something like the SH7785LCR board on the other hand does.

I also don't see much point in catering to OSes that don't support hardware manufactured this century. If the TOPPERS and BSD people want to toy around with legacy support, they are welcome to, but QEMU certainly doesn't have much to gain by spending time on this.

Now, I hope that we would reach a consensus about the spec of new standard board for SH-4A. SH7785LCR is a choice. And, as Iwamatsu-san suggested, a virtual generic board is another choice. I'm not sure SH7785LCR's hardware spec is available or not. (Does anyone know it?) If it is, I push SH7785LCR. Otherwise, virtual board sounds good.

Quoted 5 lines

Now, I hope that we would reach a consensus about the spec of new standard board for SH-4A. SH7785LCR is a choice. And, as Iwamatsu-san suggested, a virtual generic board is another choice. I'm not sure SH7785LCR's hardware spec is available or not. (Does anyone know it?) If it is, I push SH7785LCR. Otherwise, virtual board sounds good.

I recommend against using a virtual board. It means you have to maintain both qemu and a kernel port. The mips virtual board suffered exactly this fate, and IIUC is likely to be removed fairly soon.

Quoted 11 lines · Paul Brook

Quoted 7 lines

Now, I hope that we would reach a consensus about the spec of new standard board for SH-4A. SH7785LCR is a choice. And, as Iwamatsu-san suggested, a
virtual generic board is another choice. I'm not sure SH7785LCR's hardware
spec is available or not. (Does anyone know it?) If it is, I push SH7785LCR. Otherwise, virtual board sounds good.

I recommend against using a virtual board. It means you have to maintain both qemu and a kernel port. The mips virtual board suffered exactly this fate, and IIUC is likely to be removed fairly soon.

Thank you for your comment. As you pointed out, we need to maintain kernel config for virtual board. SH-Linux developpers' help is important. I guess we can expect Iwamatsu-san's help :) And once Paul Mundt supported special kernel configuration for QEMU-SH kindly.

I try to clarify the difference of real board and virtual board, as follows.

* Real board

- We can compare the emulated system with the real board. The specification is not vague, and deffects can be investitated by comaparison.

- No need to maintain kernel, and it can avoid the risk the maintenance work would be terminated, as Paul Brook pointed out.

* Virtual board

- It decreases the number of supported boards, and avoid messy many board supports. SuperH series have many CPU sub tyepes, and as number of supported CPU types increase, number of suppoted boards will increase. (Iwamatsu-san pointed it out.)

- It avoids rare peripheral support by QEMU. Sometimes embedded boards have rare peripheral on it.

    e.g.) RTL8139B (below Rev.C). on R2D+.
          http://lists.gnu.org/archive/html/qemu-devel/2008-12/msg00961.html

If we make the virtual board have standard peripheral (e.g. RTL8139C), we can reuse peripheral implemenation qualified with other board for other CPU arch, and avoid messy many type peripheral support.

I'm not sure if QEMU's policy exists or not for this kind of choice.

We can support both of them in the future. But I think it is important to make consensus which should be the default and standard for QEMU-SH, to decide to which we'll try to contribute.

I'd like to your comments on them.

Quoted 28 lines · Shin-ichiro KAWASAKI

Quoted 10 lines · Paul Brook

Quoted 7 lines

Now, I hope that we would reach a consensus about the spec of new standard board for SH-4A. SH7785LCR is a choice. And, as Iwamatsu-san suggested, a
virtual generic board is another choice. I'm not sure SH7785LCR's hardware
spec is available or not. (Does anyone know it?) If it is, I push SH7785LCR. Otherwise, virtual board sounds good.

I recommend against using a virtual board. It means you have to maintain both qemu and a kernel port. The mips virtual board suffered exactly this fate, and IIUC is likely to be removed fairly soon.

Thank you for your comment. As you pointed out, we need to maintain kernel config for virtual board. SH-Linux developpers' help is important. I guess we can expect Iwamatsu-san's help :) And once Paul Mundt supported special kernel configuration for QEMU-SH kindly.

I try to clarify the difference of real board and virtual board, as follows.

* Real board

- We can compare the emulated system with the real board. The specification is not vague, and deffects can be investitated by comaparison.

- No need to maintain kernel, and it can avoid the risk the maintenance work would be terminated, as Paul Brook pointed out.

Quoted 7 lines

* Virtual board

- It decreases the number of supported boards, and avoid messy many board supports. SuperH series have many CPU sub tyepes, and as number of supported CPU types increase, number of suppoted boards will increase. (Iwamatsu-san pointed it out.)

This depends roughly on the level of support you are looking for. You can use the generic machine vector with any CPU you want and simply stick with the on-chip peripherals without having to make any board modifications. This should be sufficient for the simple case, especially if you are interested in testing different CPUs, but will not help you if you are looking for more complete board support.

Quoted 10 lines

- It avoids rare peripheral support by QEMU. Sometimes embedded boards have rare peripheral on it.

    e.g.) RTL8139B (below Rev.C). on R2D+.
          http://lists.gnu.org/archive/html/qemu-devel/2008-12/msg00961.html

If we make the virtual board have standard peripheral (e.g. RTL8139C), we can reuse peripheral implemenation qualified with other board for other CPU arch, and avoid messy many type peripheral support.

I'm not sure if QEMU's policy exists or not for this kind of choice.

Quoted 7 lines

We can support both of them in the future. But I think it is important to make consensus which should be the default and standard for QEMU-SH, to decide to which we'll try to contribute.

I'd like to your comments on them.

From the kernel point of view, whether we add a new machine type for

emulated boards or not doesn't really matter, it mostly depends on how people are going to be using it, and what level of change you are looking for. I will add as many defconfigs and boards as people want as long as there are users for them anyways.

Anyways, I think there is value in supporting both. Emulating real hardware is especially helpful if you want to compare and contrast the environment between emulation and an existing platform, as well as allowing people without access to real hardware to develop against the emulated environment with testing conducted on real hardware as it becomes available.

Real hardware on the other hand is quite restrictive, and there are a lot of interesting features and capabilities that exist on some boards/CPUs but not others, limiting the amount of testing that can be performed. If people want to provide a virtual board that is pretty feature heavy to try and help with regression testing and so on, that would also be pretty useful.

I wouldn't worry about it too much anyways. If there is something you are specifically interested on working on in QEMU, there is no real reason why we can't accomodate that in the kernel too, it just depends on the code changes you want. We do want people to experiment with both on a regular basis anyways, so I have no real interest in setting any sort of policy on this subject. ;-)

Quoted 4 lines

I also don't see much point in catering to OSes that don't support hardware manufactured this century. If the TOPPERS and BSD people want to toy around with legacy support, they are welcome to, but QEMU certainly doesn't have much to gain by spending time on this.

I've just heard that newest TOPPERS (TOPPERS/ASP) supports SH-4A.

Now, I hope that we would reach a consensus about the spec of new standard board for SH-4A. SH7785LCR is a choice. And, as Iwamatsu-san suggested, a virtual generic board is another choice. I'm not sure SH7785LCR's hardware spec is available or not. (Does anyone know it?) If it is, I push SH7785LCR. Otherwise, virtual board sounds good.