From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Hc5qa-00075t-LZ for qemu-devel@nongnu.org; Thu, 12 Apr 2007 16:24:48 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Hc5qZ-000743-HP for qemu-devel@nongnu.org; Thu, 12 Apr 2007 16:24:48 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hc5qZ-00073k-9z for qemu-devel@nongnu.org; Thu, 12 Apr 2007 16:24:47 -0400 Received: from bangui.magic.fr ([195.154.194.245]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Hc5mM-0008RY-Ht for qemu-devel@nongnu.org; Thu, 12 Apr 2007 16:20:26 -0400 Received: from [192.168.0.2] (ppp-36.net-723.magic.fr [80.118.184.36]) by bangui.magic.fr (8.13.1/8.13.1) with ESMTP id l3CKKFXi024888 for ; Thu, 12 Apr 2007 22:20:16 +0200 Subject: Re: Qemu-PPC problems (was [Qemu-devel] Just to add one single point) From: "J. Mayer" In-Reply-To: <461E551E.9030803@windriver.com> References: <1176026443.1516.176.camel@rapid> <200704091726.13240.rob@landley.net> <1176157950.1516.360.camel@rapid> <200704111749.09810.rob@landley.net> <1176364573.6333.25.camel@rapid> <461E551E.9030803@windriver.com> Content-Type: text/plain Date: Thu, 12 Apr 2007 22:20:18 +0200 Message-Id: <1176409219.6333.33.camel@rapid> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Thu, 2007-04-12 at 10:49 -0500, Jason Wessel wrote: > J. Mayer wrote: > > On Wed, 2007-04-11 at 17:49 -0400, Rob Landley wrote: > > > >> qemu-system-ppc -M prep -nographic -kernel zImage-powerpc -append \ > >> "console=/dev/ttyS0" > >> > > > > You cannot append anything to the command line this way, with the PPC > > firmware... > > You can append options when using yaboot, not with the -kernel option. > > Then, you should use the CONFIG_CMDLINE kernel option to add the option > > you absolutely need to boot. > > > If you do not modify the prep loader, then it is impossible to pass > arguments You can compile the kernel arguments you need into the CONFIG_CMDLINE kernel option. No need for a patch for this to work. > or load a kernel that expands to > 4meg. With respect to > using an unmodified prep loader, you have to build the boot arguments > you want into the kernel itself with the .config file options. A kernel > 4 MB ? Even on my amd64 I usually have kernels smaller than this. Is there any need to have such a big kernel for anyone ? > > [...] > > > >>> It also seems that most Linux 2.6 kernels support has been broken. It > >>> used to run too, with some versions having a great problem in > >>> frame-buffer mode (writing black on black is not really usable). Using > >>> the serial console always allowed me to follow the boot until X starts. > >>> > >> I'm trying to use serial console. > >> > > > > I tried and the kernel seem to hang before reaching the start_kernel > > routine. That why I said there may now be a CPU emulation bug that broke > > everything.... Must do more checks with a debug kernel (with traces, > > this time. Using early_printk may help a lot !). > > > > [...] > > > > > > you may try to boot kernels in PREP format as they look like regular boot partitions... > > It may help. > > > > > > While I am sure folks have the objective to be able to boot something > that is not modified, my objective was to modify the kernel to work with > qemu until that first objective is met. If you use a 2.6.21rc candidate > you can use the attached patches to boot. I provided a .config file as > well. The frame buffer is definitely broken, but I had not really > looked into why because I was more interested in simply using the ppc > instruction sets. The problem with the frame-buffer is quite simple: it works (well, it used to work, I did not check with such a recent kernel...) but the kernel uses a black font on a black background. Unfortunatelly, the reason of this bug seems not obvious (or I was not so lucky to find it !). > Note I startup with the following and it works perfectly fine with my > modified kernels: > qemu-system-ppc -nographic -kernel zImage.prep -s -M prep -append > "console=ttyS0 ip=dhcp root=/dev/nfs nfsroot=10.0.2.2:/export/ppc rw > netdev=9,0x300,eth0" > > There is a new regression between Apr 9 and Apr 10 in the QEMU CVS HEAD > where tcp checksums are failing again. :-( > I stand corrected it not the TCP check sums. The new PPC pic code does > not work so as to allow the ethernet device driver to receive packets. > I guess the question should be is if we would have expected more to work > than breaks or if different cases actually work now with the new PPC pic > code, or if they are all broken. Did it really work before this patch ? Because IRQs were broken _before_ the IRQ scheme patches, for the PREP platform, which is the reason I cannot test it. It seem to have been broken in September and the problem seems to be somewhere in the PCI bridge code... [...] -- J. Mayer Never organized