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

[Shin-ichiro KAWASAKI <kawasaki@juno.dti.ne.jp>]

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