Re: [Qemu-devel] Powerpc regressions?

[Rob Landley]

On Sunday 02 August 2009 07:25:45 Alexander Graf wrote:
> On 02.08.2009, at 12:04, Aurelien Jarno wrote:
> > On Sun, Aug 02, 2009 at 12:40:53AM -0500, Rob Landley wrote:
> >> On Monday 13 July 2009 07:25:45 Aurelien Jarno wrote:
> >>>> If changing my kernel .config so I build a new kernel that works
> >>>> with the
> >>>> new qemu is my only alternative, I'm happy to do that.  But I don't
> >>>> currently have a working kernel .config, and don't understand why
> >>>> the old
> >>>> one broke or how to avoid being hit by similar changes in future.
> >>>
> >>> I am using the Debian kernel and it works fine, please find
> >>> attached the
> >>> .config attached.
> >>
> >> Finally got back in a position to spend some more time on this.
> >> Sorry for the
> >> delay.
> >>
> >> Ok, I'm trying just to boot to a command prompt with a serial
> >> console and IDE
> >> /dev/hda.  (Or funky scsi IDE /dev/sda in a pinch.)
> >>
> >> Your .config is for a 2.6.26 kernel and I'm building 2.6.30, so I
> >> have to run
> >> make oldconfig against it (and just hit enter on everything to take
> >> the
> >> defaults).  Also, I'm not using an initramfs at the moment, so
> >> presumably
> >> anything that's in a module can go because it won't get loaded
> >> before I get a
> >> shell prompt anyway, so I can yank anything config =m, and the module
> >> infrastructure itself, to simplify things a bit.
> >>
> >> That gave me the (much smaller) attached .config, which _should_
> >> work the same
> >> as yours, I hope?  Note that CONFIG_SERIAL_8250_CONSOLE is on, so I
> >> should be
> >> able to get a serial console, which is my first target: get boot
> >> messages from
> >> this kernel.
> >>
> >> I built a kernel using the attached .config and my existing powerpc
> >> toolchain
> >> (which built a kernel that booted under older qemu), and attempted
> >> to boot the
> >> result under current git (28e738dcb81d):
> >>
> >> qemu-system-ppc -M g3beige -nographic -no-reboot -kernel zImage-
> >> powerpc
> >> -hda image-powerpc.sqf -append "root=/dev/hda rw init=/usr/sbin/
> >> init.sh
> >> panic=1 PATH=/usr/bin console=ttyS0 "
> >>
> >>>> =============================================================
> >>>> OpenBIOS 1.0 [Jul 5 2009 17:36]
> >>>> Configuration device id QEMU version 1 machine id 2
> >>>> CPUs: 1
> >>>> Memory: 128M
> >>>> UUID: 00000000-0000-0000-0000-000000000000
> >>>> CPU type PowerPC,750
> >>
> >> Welcome to OpenBIOS v1.0 built on Jul 5 2009 17:36
> >>
> >>>> [ppc] Kernel already loaded (0x01000000 + 0x0039bef0) (initrd
> >>>> 0x00000000 +
> >>
> >> 0x00000000)
> >>
> >>>> [ppc] Kernel command line: root=/dev/hda rw init=/usr/sbin/
> >>>> init.sh panic=1
> >>
> >> PATH=/usr/bin console=ttyS0
> >> OF stdout device is: 
> >> /address@hidden/address@hidden/address@hidden/address@hidden
> >> Preparing to boot Linux version 2.6.30 (address@hidden) (gcc
> >> version 4.2.1)
> >> #1 Sat Aug 1 17:35:12 CDT 2009
> >> command line: root=/dev/hda rw init=/usr/sbin/init.sh panic=1 PATH=/
> >> usr/bin
> >> console=ttyS0
> >> memory layout at init:
> >>  alloc_bottom : 013a0000
> >>  alloc_top    : 08000000
> >>  alloc_top_hi : 08000000
> >>  rmo_top      : 08000000
> >>  ram_top      : 08000000
> >> found display   : /address@hidden/QEMU,address@hidden, opening... done
> >> copying OF device tree...
> >> Building dt strings...
> >> Building dt structure...
> >> Device tree strings 0x013a1000 -> 0x013a1383
> >> Device tree struct  0x013a2000 -> 0x013a4000
> >> Calling quiesce...
> >> returning from prom_init
> >>
> >> At which point it exits and I get the prompt back.
> >
> > I think using console=ttyPZ0 which is the serial port name on PowerPC
> > will give you more details.

Yup, that gave me boot messages.  Thanks.

Huh.  It used ttyS0 with the other .config (I at least got boot messages), I 
wonder why that changed?  (Just confirmed that this .config has the driver for 
a 
16550a built in.  And the name "ttyS0" for the first serial device is 
presumably about as genric as using eth1 for the first wired ethernet 
device...)

Ok, switch on squashfs, boot with:

qemu-system-c -M g3beige -nographic -no-reboot -kernel zImage-powerpc -hda 
image-powerpc.sqf -append "root=/dev/hda rw init=/usr/bin/hello-static panic=1 
PATH=/usr/bin console=ttyPZ0"

And it hangs.

I'm using a statically linked "hello world" program linked against uClibc as 
my init (attached), and it hangs after printing the first two characters of 
"hello world".

Well, I suppose that's progress.

Any suggestions?

> Also try "-vnc :5 -serial mon:stdio" instead of -nographic.

When I get these targets working, I drive builds on them with things like:

./run-from-build.sh $1 << 'EOF'
                #
# Smoke test for the compiler
gcc -s /usr/src/thread-hello2.c -lpthread -o /tmp/hello &&
/tmp/hello
sync
exit
EOF

(The first line of spaces is because linux kernel 16550a serial chip 
initialization flushes the queue, eating anywhere up to the first 16 bytes of 
input data.)

Therefore, I prefer to test what I'd like to actually _use_.  The -nographic 
option can make qemu act like a normal, more or less scriptable process.  
Other display options don't, they all expect to interact with a human (unless 
you want to do something fancy with the virtual network to work around it).

> Alex

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds

.config.zip
Description: Zip archive

hello-static
Description: application/executable