Re: Qemu-PPC problems (was [Qemu-devel] Just to add one single point)
I'm fighting with cvs and haven't been able to update my build directory yet. (I've been spoiled by mercurial, where doing an update on a directory with modifications in it doesn't _eat_ the directory. And my attempt to create a mercurial copy of the cvs history with tailor so I could tracck development more easily revealed an interesting bug tailor that ate an afternoon without fixing anything. Sigh, buried in tangents...) You've given me some more avenues to pursue and I hope to get to it this weekend, but in the meantime lemme catch up with the thread... On Thursday 12 April 2007 3:56 am, J. Mayer wrote: Oh, and did you ever get the bug report on qemu-ppc not working with uClibc because Linux always zeroes r3 (return value from previous syscall, in this case exec) and qemu application emulation apparently doesn't? This is documented in linux-user/elfload.c The fact is r3 is not zeroed to follow the PowerPC ABI and then be able to launch BSD program that relies on the kernel following the ABI. If Linux does not follow the ABI requirements... If qemu is built for Linux, why would it be launching BSD programs? Possibly an #ifdef is called for here? Once again, it's been a long time I did not check, but Qemu-PPC used to be able to launch some BSD programs too. On BSD, that may be. (I don't use it.) But when running Linux programs, it doesn't match the real, documented, and consistent behavior of the Linux kernel that other software (like uClibc) has come to rely on. On Linux, it may be compliant with a theoretical standard, but it simply doesn't match reality. Again, this sounds like a job for an #ifdef. To quote from http://wall.riscom.net/books/proc/ppc/cwg/a_abi.html IBM has defined three ABIs for the PowerPC architecture: the AIX ABI for big-endian 32-bit PowerPC processors and the Windows NT and Workplace ABIs for little-endian 32-bit PowerPC processors. Other PowerPC users have defined other ABIs. As a practical matter, ABIs tend to be associated with a particular operating system or family of operating systems. Programs compiled for one ABI are frequently incompatible with programs compiled for another ABI because of the low-level strategic decisions required by an ABI. What the kernel does is set r3 to the return value of the exec call (and argc in r1), then the dynamic linker shuffles things around so r3 points to argc. When a program is statically linked, it gets r3 zeroed, as explained here: http://sources.redhat.com/ml/libc-alpha/2003-03/msg00272.html It's quite possible that command line arguments don't work when the program _is_ dynamically linked because the shuffling the dynamic linker does is going to overwrite r3 with r1. I don't know, hello world doesn't look at argc and my script only uses application emulation as a smoke test for my new cross compiler toolchain. Google brings up this as the abi document: http://refspecs.freestandards.org/elf/elfspec_ppc.pdf Which describes the registers on page 30-32. Page 38 says the return value is in r3 (and Linux is putting the return value of exec into r3, which is why they expect it to be 0 when exec worked). Page 44 does talk about the register layout you mention later, but on Linux the dynamic linker is what sets this up, not the kernel. (Whether or not the kernel should leave this to the dynamic linker is immaterial: reality is that it does. And it's been doing it this way long enough that it's not likely to change.) I sent it to you directly, but your mailserver bounces messages from mine as spam. (I apparently can't even cc you or you won't get a copy through the mailing list.) Cannot do anything about it, the mailserver is not mine. Neither is mine, alas. I'm sorry but I _never_ use custom kernels for tests, apart if I want to add traces to track a really well hiden bug. I always use stock kernels delivered with distributions or kernels I recompile under Qemu from the vanilla sources located at kernel.org, with absolutely no patch. Not all run, that's true. Some may even say that only a few run. If a stock kernel boots then it should be possible to build a kernel from source that will also boot. I'm happy to debug and document how to do so, but I'm not good at debugging firmware or bootloaders. That's what I do, but using a partitioned file system: I try to act the same as what I do when using a real PowerPC based machine. So I compile my kernel, install it and modify the yaboot configuration file to use it. My problem is that none of the other platforms I've gotten the kernel booting on (so far arm, mips, x86, x86_64, and sparc) work like this. I got them all booting kernel + unpartitioned ext2 filesystem image. I'm reluctant to go back and change all the other platforms because PowerPC currently has unique requirements due to options like -kernel not working. So far I've just deferred adding PowerPC
Re: Qemu-PPC problems (was [Qemu-devel] Just to add one single point)
On Thursday 12 April 2007 11:49 am, 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 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. Any chance of pushing that loader patch back upstream? (At least into -mm?) 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. Applying said .config to 2.6.20.6 and running make oldconfig was... interesting. Ah! You're using ARCH=ppc to build the kernel and I've been using ARCH=powerpc. I totally do not understand the difference between them, but I can adjust to that if it's a condition of making things work... (Switch _off_ CONFIG_LOCALVERSION_AUTO Hang the build indefinitely waiting for git to do who knows what...) Hey, I got a zImage.prep! 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. 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 Uncompressing Linux... Segmentation fault. But hey, it's progress. (It got that far! This is a first for me.) This is using a 2-week old qemu cvs snapshot and not using the 2.6.21-rc you mentioned, and I haven't applied your patches yet, so I'll try all that next. But I got it to say Uncompressing Linux...! This is progress!) Thank you. Rob -- Penguicon 5.0 Apr 20-22, Linux Expo/SF Convention. Bruce Schneier, Christine Peterson, Steve Jackson, Randy Milholland, Elizabeth Bear, Charlie Stross...
Re: Qemu-PPC problems (was [Qemu-devel] Just to add one single point)
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 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.
[...]
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.
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. :-(
If it would help, I can certainly provide some of my zImage files which
run with several different 2.6.x kernels.
Jason.
dot_config.gz
Description: GNU Zip compressed data
Adjust prep loader to deal with larger kernel images.
signed-off-by: Jason Wessel [EMAIL PROTECTED]
Index: linux-2.6.21-rc3/arch/ppc/boot/simple/misc.c
===
--- linux-2.6.21-rc3.orig/arch/ppc/boot/simple/misc.c
+++ linux-2.6.21-rc3/arch/ppc/boot/simple/misc.c
@@ -17,6 +17,7 @@
#include linux/types.h
#include linux/string.h
+#include asm/residual.h
#include asm/page.h
#include asm/mmu.h
#include asm/bootinfo.h
@@ -27,6 +28,7 @@
#include nonstdio.h
+#define CONFIG_RUNTIME_CMDLINE 0x17ff000
/* Default cmdline */
#ifdef CONFIG_CMDLINE
#define CMDLINE CONFIG_CMDLINE
@@ -53,7 +55,7 @@
char *avail_ram;
char *end_avail;
char *zimage_start;
-char cmd_preset[] = CMDLINE;
+char cmd_preset[256] = CMDLINE;
char cmd_buf[256];
char *cmd_line = cmd_buf;
int keyb_present = HAS_KEYB;
@@ -91,9 +93,11 @@ get_mem_size(void)
#endif
struct bi_record *
-decompress_kernel(unsigned long load_addr, int num_words, unsigned long cksum)
+decompress_kernel(unsigned long load_addr, int num_words, unsigned long cksum
+,RESIDUAL *residual, void *OFW_interface)
{
#ifdef INTERACTIVE_CONSOLE
+int do_console = 0;
int timer = 0;
char ch;
#endif
@@ -120,9 +124,12 @@ decompress_kernel(unsigned long load_add
* and we must have the correct file linked in here.
*/
TotalMemory = get_mem_size();
+ puts(TotalMemory: ); puthex(TotalMemory); puts(\n);
+ puts(TotalResid: ); puthex(residual-TotalMemory); puts(\n);
+ puts(Resid at: ); puthex((unsigned int)residual); puts(\n);
- /* assume the chunk below 8M is free */
- end_avail = (char *)0x0080;
+ /* assume the chunk below 10M is free */
+ end_avail = (char *)0x00A0;
/*
* Reveal where we were loaded at and where we
@@ -139,6 +146,13 @@ decompress_kernel(unsigned long load_add
puts(\n);
}
+ if (residual) {
+ puts(board data at: ); puthex((unsigned long)residual);
+ puts( );
+ puthex((unsigned long)((unsigned long)residual +
+ sizeof(RESIDUAL)));
+ puts(\n);
+ }
/*
* We link ourself to 0x0080. When we run, we relocate
* ourselves there. So we just need __image_begin for the
@@ -167,15 +181,21 @@ decompress_kernel(unsigned long load_add
}
#ifndef CONFIG_40x /* don't overwrite the 40x image located at 0x0040! */
- avail_ram = (char *)0x0040;
+ avail_ram = (char *)0x0050;
#endif
- end_avail = (char *)0x0080;
+ end_avail = (char *)0x00A0;
puts(avail ram: ); puthex((unsigned long)avail_ram); puts( );
puthex((unsigned long)end_avail); puts(\n);
if
Re: Qemu-PPC problems (was [Qemu-devel] Just to add one single point)
Jason Wessel wrote: 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. Jason.
Re: Qemu-PPC problems (was [Qemu-devel] Just to add one single point)
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
