0

I was, until recently able to boot qemu-system-ppc (v1.7.0) using a customized cross compiled Linux kernel and BusyBox. I even posted it here: qemu kernel debugging with KGDB

However I am unable to do so now with v2.0.2. The command I use to invoke qemu is the very same I used previously

qemu-system-ppc -M mpc8544ds -m 512 -kernel zImage -s -nographic -initrd busyboxfs.img -append "root=/dev/ram rdinit=/bin/sh kgdboc=ttyS0,115200 kgdbwait

can anyone help me see the console log so I can understand if it is indeed booting and if not what is the problem. I've tried without the kgdb arguments to the kernel but still all I see is blank.

Community
  • 1
  • 1
AjB
  • 890
  • 13
  • 34

1 Answers1

2

You might want to have a look at Buildroot (http://www.buildroot.org) : we have three PowerPC defconfigs that boot fine under recent versions of Qemu, including 2.0.2 and 2.1.2.

See especially the qemu_ppc_g3beige_defconfig, which boots fine under Qemu 2.1.2, the qemu_ppc_mpc8544ds_defconfig, which boots fine under Qemu 2.0.2, and qemu_ppc_virtex_ml507_defconfig, which boots fine under Qemu 2.1.2.

Thomas Petazzoni
  • 5,636
  • 17
  • 25
  • To be honest here, I've never used buildroot before. These defconfigs, as you mention, is perhaps a set of patches that will configure buildroot to generate the toolchain,rootfs, kernel image and bootloader. Right? I'll try it sometime from now, but what if I;d want to localize the problem in my case? Out of these components required to boot an image, what if one of them is faulty? How would we identify failing component? I'm using emdebian as toolchain, busybox as rootfs. Qemu uses openBIOS if I'm correct. May be my kernel could be faulty but in that case i shd see some console logs at least. – AjB Oct 20 '14 at 12:47
  • I'm now using the defconfig you specified. However I specified the 2.6.32 version of the kernel. Now the cross compiler is apparently treating all warnings as errors (which is good and may be the newer kernel versions might have fixed it) so my 2.6.32 kernel build is failing. To overcome this I tried adding `-Wno-error` to top level kernel makefile but to no avail. I was forced to add `-w` to ignore all warnings. Is there a way I can prevent the cross compiler from treating all warnings as errors? Perhaps using CFLAGS? Where to add them? – AjB Oct 23 '14 at 03:55