From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LRc5n-00034J-49 for qemu-devel@nongnu.org; Mon, 26 Jan 2009 19:46:15 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LRc5m-00033y-E3 for qemu-devel@nongnu.org; Mon, 26 Jan 2009 19:46:14 -0500 Received: from [199.232.76.173] (port=43190 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LRc5m-00033v-9z for qemu-devel@nongnu.org; Mon, 26 Jan 2009 19:46:14 -0500 Received: from mta23.gyao.ne.jp ([125.63.38.249]:51539 helo=mx.gate01.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LRc5l-0007HM-He for qemu-devel@nongnu.org; Mon, 26 Jan 2009 19:46:14 -0500 Date: Tue, 27 Jan 2009 09:43:12 +0900 From: Paul Mundt Subject: Re: sh: Virtual Board or Real board? (was Re: [Qemu-devel] [PATCH 1/3] sh: SE7750 board definition) Message-ID: <20090127004312.GC3835@linux-sh.org> References: <4969B77E.7050206@juno.dti.ne.jp> <20090121090424.GC14537@linux-sh.org> <4977527A.70104@juno.dti.ne.jp> <200901211706.09350.paul@codesourcery.com> <497AAB40.7010608@juno.dti.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <497AAB40.7010608@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 , Nobuhiro Iwamatsu , qemu-devel@nongnu.org, "linux-sh@vger.kernel.org" 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. ;-)