From: Shin-ichiro KAWASAKI <kawasaki@juno.dti.ne.jp>
To: Paul Mundt <lethal@linux-sh.org>,
qemu-devel@nongnu.org,
Takashi Yoshii <yoshii.takashi@renesas.com>,
Nobuhiro Iwamatsu <iwamatsu.nobuhiro@renesas.com>,
"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>
Subject: Re: [Qemu-devel] [PATCH 1/3] sh: SE7750 board definition
Date: Thu, 22 Jan 2009 01:51:06 +0900 [thread overview]
Message-ID: <4977527A.70104@juno.dti.ne.jp> (raw)
In-Reply-To: <20090121090424.GC14537@linux-sh.org>
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
next prev parent reply other threads:[~2009-01-21 16:51 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-11 9:10 [Qemu-devel] [PATCH 1/3] sh: SE7750 board definition Shin-ichiro KAWASAKI
2009-01-11 12:57 ` Edgar E. Iglesias
2009-01-11 13:04 ` Jean-Christophe PLAGNIOL-VILLARD
2009-01-12 3:48 ` Shin-ichiro KAWASAKI
2009-01-12 12:49 ` Paul Mundt
2009-01-13 2:32 ` Nobuhiro Iwamatsu
2009-01-13 6:28 ` Jean-Christophe PLAGNIOL-VILLARD
2009-01-15 1:25 ` Nobuhiro Iwamatsu
2009-01-13 7:46 ` Laurent Desnogues
2009-01-24 17:59 ` Shin-ichiro KAWASAKI
2009-01-13 13:36 ` Shin-ichiro KAWASAKI
2009-01-15 1:46 ` Nobuhiro Iwamatsu
2009-01-17 10:45 ` Shin-ichiro KAWASAKI
2009-01-17 11:16 ` Jean-Christophe PLAGNIOL-VILLARD
2009-01-21 9:04 ` Paul Mundt
2009-01-21 16:51 ` Shin-ichiro KAWASAKI [this message]
2009-01-21 17:06 ` Paul Brook
2009-01-24 5:46 ` sh: Virtual Board or Real board? (was Re: [Qemu-devel] [PATCH 1/3] sh: SE7750 board definition) Shin-ichiro KAWASAKI
2009-01-27 0:43 ` Paul Mundt
2009-02-01 13:50 ` Shin-ichiro KAWASAKI
2009-01-21 19:01 ` [Qemu-devel] [PATCH 1/3] sh: SE7750 board definition Jean-Christophe PLAGNIOL-VILLARD
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4977527A.70104@juno.dti.ne.jp \
--to=kawasaki@juno.dti.ne.jp \
--cc=iwamatsu.nobuhiro@renesas.com \
--cc=lethal@linux-sh.org \
--cc=linux-sh@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=yoshii.takashi@renesas.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).