From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LNHJZ-0002eg-Hh for qemu-devel@nongnu.org; Wed, 14 Jan 2009 20:46:33 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LNHJY-0002eU-Uu for qemu-devel@nongnu.org; Wed, 14 Jan 2009 20:46:33 -0500 Received: from [199.232.76.173] (port=46208 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNHJY-0002eR-SK for qemu-devel@nongnu.org; Wed, 14 Jan 2009 20:46:32 -0500 Received: from mail.renesas.com ([202.234.163.13]:62902 helo=mail06.idc.renesas.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LNHJY-0007ZV-4Z for qemu-devel@nongnu.org; Wed, 14 Jan 2009 20:46:32 -0500 Date: Thu, 15 Jan 2009 10:46:24 +0900 From: Nobuhiro Iwamatsu Subject: Re: [Qemu-devel] [PATCH 1/3] sh: SE7750 board definition In-reply-to: <496C98EB.5040309@juno.dti.ne.jp> Sender: iwamatsu.nobuhiro@renesas.com Message-id: <496E9570.2050306@renesas.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit References: <4969B77E.7050206@juno.dti.ne.jp> <20090111130445.GA12080@game.jcrosoft.org> <496ABD72.20400@juno.dti.ne.jp> <20090112124949.GA14269@linux-sh.org> <496BFD30.30306@renesas.com> <496C98EB.5040309@juno.dti.ne.jp> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Shin-ichiro KAWASAKI Cc: Takashi Yoshii , qemu-devel@nongnu.org, "linux-sh@vger.kernel.org" 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