Re: Qemu-PPC problems (was [Qemu-devel] Just to add one single point)

[J. Mayer]

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 <address@hidden>
Never organized