Re: [PATCH] script/runqemu: change boot command line for qemuppc

[Bruce Ashfield <bruce.ashfield@windriver.com>]

On 11-08-22 04:21 AM, Liming Wang wrote:
> On 2011-8-20 0:28, Richard Purdie wrote:
>> On Fri, 2011-08-19 at 18:06 +0800, Liming Wang wrote:
>>> Because qemuppc has no graphic emulation, remove console=tty0
>>> and make it run into 3 run level. This can reduce boot time
>>> for qemuppc booting.
>>>
>>> Signed-off-by: Liming Wang<liming.wang@windriver.com>
>>> ---
>>> scripts/runqemu-internal | 4 ++--
>>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal
>>> index c15632d..883fa5b 100755
>>> --- a/scripts/runqemu-internal
>>> +++ b/scripts/runqemu-internal
>>> @@ -384,7 +384,7 @@ if [ "$MACHINE" = "qemuppc" ]; then
>>> BIOS=powerpc_rom.bin
>>> QEMU_UI_OPTIONS="$QEMU_UI_OPTIONS -nographic"
>>> if [ "$FSTYPE" = "ext3" -o "$FSTYPE" = "btrfs" ]; then
>>> - KERNCMDLINE="root=/dev/hda rw console=ttyS0 console=tty0
>>> $KERNEL_NETWORK_CMD mem=$QEMU_MEMORY"
>>> + KERNCMDLINE="root=/dev/hda rw console=ttyS0 3 $KERNEL_NETWORK_CMD
>>> mem=$QEMU_MEMORY"
>>> QEMUOPTIONS="$QEMU_NETWORK_CMD -cpu $CPU_SUBTYPE -M $MACHINE_SUBTYPE
>>> -bios $BIOS -hda $ROOTFS -no-reboot $QEMU_UI_OPTIONS"
>>> fi
>>> if [ "$FSTYPE" = "nfs" ]; then
>>> @@ -393,7 +393,7 @@ if [ "$MACHINE" = "qemuppc" ]; then
>>> cleanup
>>> return
>>> fi
>>> - KERNCMDLINE="root=/dev/nfs console=ttyS0 console=tty0
>>> nfsroot=$NFS_SERVER:$NFS_DIR,$UNFS_OPTS rw $KERNEL_NETWORK_CMD
>>> mem=$QEMU_MEMORY"
>>> + KERNCMDLINE="root=/dev/nfs console=ttyS0 3
>>> nfsroot=$NFS_SERVER:$NFS_DIR,$UNFS_OPTS rw $KERNEL_NETWORK_CMD
>>> mem=$QEMU_MEMORY"
>>> QEMUOPTIONS="$QEMU_NETWORK_CMD -cpu $CPU_SUBTYPE -M $MACHINE_SUBTYPE
>>> -bios $BIOS -no-reboot $QEMU_UI_OPTIONS"
>>> fi
>>> fi
>> Can we not fix the X scripts so that if an fbdev X server is in use and
> X scripts serve for all the boards. And we also can't assume all the
> boards use the same
> framebuffer device. So how to detect whether the framebuffer device
> exists is board dependent.
> Maybe we can see whether the device /dev/fb0 exists(it could be created
> manually, so we should try to open it to verify)
> or the file /proc/fb exists to confirm the framebuffer device. Anyway,
> any modification should be
> tested on all boards to see whether it works. I prefer to mark it as
> todo task in 1.1

I know I'm ok with this strategy, since time is short in the
1.1 cycle. We can always open a bugzilla item to track this,
just to be sure it isn't forgotten. Preferably we'll get a
qemuppc with a framebuffer in 1.x timeframe and we won't need
this at all. Coming up with something generic and the amount
of testing required doesn't fit the timeframe that we currently
have for 1.1.

But in the end, this is up to Richard, this is just my 2 cents
worth.

Bruce

>
> Liming Wang
>> the framebuffer device node does not exist, it just exits cleanly with a
>> suitable message and doesn't timeout on boot?
>>
>> Cheers,
>>
>> Richard
>>
>>
>