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 <[EMAIL PROTECTED]> Never organized
