Re: [Qemu-devel] [PATCH 1/3] sh: SE7750 board definition

Re: [Qemu-devel] [PATCH 1/3] sh: SE7750 board definition

[Shin-ichiro KAWASAKI]

Thank you for the review!
# This mail CCed to linux-sh ML expecting some comments on SE7750 flash.

Jean-Christophe PLAGNIOL-VILLARD wrote:
>> +#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
I agree.  I think it will be another patch.

>> +
>> +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 */
> please move tihs too the beginning of the function
Sure. I'll do so.

>> +    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;
>> +    }
> 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

Regards,
Shin-ichiro KAWASAKI

Re: [Qemu-devel] [PATCH 1/3] sh: SE7750 board definition

[Paul Mundt]

On Mon, Jan 12, 2009 at 12:48:02PM +0900, Shin-ichiro KAWASAKI wrote:
> >>+    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;
> >>+    }
> >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
> 
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.

Re: [Qemu-devel] [PATCH 1/3] sh: SE7750 board definition

[Nobuhiro Iwamatsu]

Paul Mundt wrote:
> On Mon, Jan 12, 2009 at 12:48:02PM +0900, Shin-ichiro KAWASAKI wrote:
>>>> +    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;
>>>> +    }
>>> 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
>>
> 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?

Best regards,
  Nobuhiro

Re: [Qemu-devel] [PATCH 1/3] sh: SE7750 board definition

[Jean-Christophe PLAGNIOL-VILLARD]

On 11:32 Tue 13 Jan     , Nobuhiro Iwamatsu wrote:
> Paul Mundt wrote:
>> On Mon, Jan 12, 2009 at 12:48:02PM +0900, Shin-ichiro KAWASAKI wrote:
>>>>> +    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;
>>>>> +    }
>>>> 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
>>>
>> 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.
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.

Best Regards,
J.

Re: [Qemu-devel] [PATCH 1/3] sh: SE7750 board definition

[Nobuhiro Iwamatsu]

Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 11:32 Tue 13 Jan     , Nobuhiro Iwamatsu wrote:
>> Paul Mundt wrote:
>>> On Mon, Jan 12, 2009 at 12:48:02PM +0900, Shin-ichiro KAWASAKI wrote:
>>>>>> +    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;
>>>>>> +    }
>>>>> 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
>>>>
>>> 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.
> 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.

I understood your comment.

Then, I do not support in each board and I think support it by the unit of IP.
Because we can be tested IP with a real machine.

BTW, because I think that qemu is CPU or userland emulator,
I don't think that complete emulation of the board is so important.

Best regards,
  Nobuhiro
Best regards,
  Nobuhiro

Re: [Qemu-devel] [PATCH 1/3] sh: SE7750 board definition

[Shin-ichiro KAWASAKI]

Nobuhiro Iwamatsu wrote:
> Paul Mundt wrote:
>> On Mon, Jan 12, 2009 at 12:48:02PM +0900, Shin-ichiro KAWASAKI wrote:
>>>>> +    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;
>>>>> +    }
>>>> 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
>>>
>> 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.


> 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?
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?


Regards,
Shin-ichiro KAWASAKI

Re: [Qemu-devel] [PATCH 1/3] sh: SE7750 board definition

[Nobuhiro Iwamatsu]

Shin-ichiro KAWASAKI wrote:
> Nobuhiro Iwamatsu wrote:
>> Paul Mundt wrote:
>>> On Mon, Jan 12, 2009 at 12:48:02PM +0900, Shin-ichiro KAWASAKI wrote:
>>>>>> +    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;
>>>>>> +    }
>>>>> 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
>>>>
>>> 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.
> 
> 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.

OK.

> 
> 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.

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?

> 
> 
>> 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?
> 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.

Best regards,
  Nobuhiro

Re: [Qemu-devel] [PATCH 1/3] sh: SE7750 board definition

[Shin-ichiro KAWASAKI]

Nobuhiro Iwamatsu wrote:
> Shin-ichiro KAWASAKI wrote:
>> Nobuhiro Iwamatsu wrote:
>>> Paul Mundt wrote:
>>>> On Mon, Jan 12, 2009 at 12:48:02PM +0900, Shin-ichiro KAWASAKI wrote:
>>>>>>> +    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;
>>>>>>> +    }
>>>>>> 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
>>>>>
>>>> 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.
>>
>> 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.
> 
> OK.
> 
>>
>> 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.
> 
> 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.

But anyway, to check how SCI console works, qemu-sh should have
another board support which uses SCI.  Is there any suggestion
about board?  One idea is to let the virtual board have it.


>>> 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?
>> 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.

> 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.


Regards,
Shin-ichiro KAWASAKI

Re: [Qemu-devel] [PATCH 1/3] sh: SE7750 board definition

[Jean-Christophe PLAGNIOL-VILLARD]

>>>
>>> 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.
>>
>> 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.
my the TOPPERS dev could help us to have a common board to use it as reference


>>> 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?
>>> 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.
>
>> 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.
I've in mind to use fdt to describe the board
when implementating the qemu sh generic board

Best Regards,
J.

Re: [Qemu-devel] [PATCH 1/3] sh: SE7750 board definition

[Paul Mundt]

On Tue, Jan 13, 2009 at 10:36:43PM +0900, Shin-ichiro KAWASAKI wrote:
> Nobuhiro Iwamatsu wrote:
> >Paul Mundt wrote:
> >>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.
> 
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.

> 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.
> 
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.

Re: [Qemu-devel] [PATCH 1/3] sh: SE7750 board definition

[Shin-ichiro KAWASAKI]

Paul Mundt wrote:
> On Tue, Jan 13, 2009 at 10:36:43PM +0900, Shin-ichiro KAWASAKI wrote:
>> Nobuhiro Iwamatsu wrote:
>>> Paul Mundt wrote:
>>>> 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.
>>
> 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.

I checked SH7785 spec, and found that it does not support SCI.
# SCIF, SIOF, and HSPI are the supported serial interfaces.
You are right.  SCI is obsolete.    I'll postpone the work on SCI and RTC
for R2D until some necessity comes out (or forever).

>> 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.
>>
> 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.
One of TOPPERS developer gave me an advice not to stick to old boards.
One SCIF and one TMU is the minimal requirement for TOPPERS.  Then, almost
all boards are suitable.  Now I have no reason to push old SE7750 as the
standard board.  Sorry for my pointless reasoning.

# SE7750 support is not useful as a standard board, but it is as a test platform
# of movca.l/ocbi patch.  That patch may be pendent for a while...

> 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.


Regards,
Shin-ichiro KAWASAKI

Re: [Qemu-devel] [PATCH 1/3] sh: SE7750 board definition

[Paul Brook]

> 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.

Paul

sh: Virtual Board or Real board? (was Re: [Qemu-devel] [PATCH 1/3]

[Shin-ichiro KAWASAKI]

Paul Brook wrote:
>> 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.


Regards,
Shin-ichiro KAWASAKI

Re: sh: Virtual Board or Real board? (was Re: [Qemu-devel] [PATCH 1/3] sh: SE7750 board definition)

[Paul Mundt]

On Sat, Jan 24, 2009 at 02:46:40PM +0900, Shin-ichiro KAWASAKI wrote:
> Paul Brook wrote:
> >>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.)
> 
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.

> - 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.
> 
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. ;-)

Re: sh: Virtual Board or Real board? (was Re: [Qemu-devel] [PATCH

[Shin-ichiro KAWASAKI]

Paul Mundt wrote:
> On Sat, Jan 24, 2009 at 02:46:40PM +0900, Shin-ichiro KAWASAKI wrote:
>> Paul Brook wrote:
>>>> 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.)
>>
> 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.
Thank you.  Your explanation clarifies the relation between purpose and
target board.  I guess Iwamatsu-san's purpose is not board emulation but
CPU. Then virtual board is suitable for it.

My current purpose is to utilize QEMU to analyze SH system behavior mainly
for debug purpose. (Performance analysis with QEMU is my interest also, but
I do not expect exact analysis result.)  Anyway, I'd like to compare QEMU-SH
system and real SH board to see what QEMU can do, and what QEMU cannot. Then
I wanted to complete R2D+ board emulation.  But R2D+ is obsolete now, and
SH7785LCR will be my next choice.


>> - 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.
>>
>>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.

I agree.  Board-less software development is very powerful use case of
QEMU.  I thank to QEMU developers, and hope that SH developers would
enjoy it too, in near future.

> 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. ;-)

I see.  My current understanding is as follows.

 - Both virtual and real boards will provide benefit for SH software developers,
   in different ways.
 - There is no restriction to add sh-linux defconfigs for virtual board, because
   there exist some sh-linux users those who expect it. : e.g.) Iwamatsu-san 
 - Anyway, we need new board support for QEMU-SH, because R2D+ is obsolete.
   (I do not much about 'shix' board, but I guess it is obsolete too.)

Then I'll begin to consider on SH7785LCR board emulation.  If someone is working
on it, please let me know.  I'll try to help it, or consider on virtual board
to avoid duplicated work.

# Of course, more advices on this issue are welcome.


Regards,
Shin-ichiro KAWASAKI

Re: [Qemu-devel] [PATCH 1/3] sh: SE7750 board definition

[Jean-Christophe PLAGNIOL-VILLARD]

>> 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.
The SH7785LCR is a good choice for the SH-4A
The RSK7203 will be a good choice for the SH-2A

The virtual board will be a good choice for IP test and integration test

Best Regards,
J.