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

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

[Liming Wang]

This patch is just a workaround to speed up boot time of qemuppc, because
qemuppc has no framebuffer support, no need to start X server for qemuppc.

Richard suggested to fix the X scripts so that if an fbdev X server is in use and
the framebuffer device node does not exist, it just exits cleanly with a
suitable message and doesn't timeout on boot.

But I think it needs more time to implement and test.
> 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

Bruce also suggests:
> 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.


Liming Wang (1):
      script/runqemu: change boot command line for qemuppc

 scripts/runqemu-internal |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

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

[Liming Wang]

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
-- 
1.7.0.4

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

[Bruce Ashfield]

On 11-08-24 04:48 AM, Liming Wang wrote:
> This patch is just a workaround to speed up boot time of qemuppc, because
> qemuppc has no framebuffer support, no need to start X server for qemuppc.
>
> Richard suggested to fix the X scripts so that if an fbdev X server is in use and
> the framebuffer device node does not exist, it just exits cleanly with a
> suitable message and doesn't timeout on boot.
>
> But I think it needs more time to implement and test.
>> 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

We need to cc Richard/Saul on this, so they can re-consider
and merge this as appropriate. But for me, I'm acking this
change.

Bruce

>
> Bruce also suggests:
>> 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.
>
>
> Liming Wang (1):
>        script/runqemu: change boot command line for qemuppc
>
>   scripts/runqemu-internal |    4 ++--
>   1 files changed, 2 insertions(+), 2 deletions(-)
>

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

[Richard Purdie]

On Wed, 2011-08-24 at 14:33 -0400, Bruce Ashfield wrote:
> On 11-08-24 04:48 AM, Liming Wang wrote:
> > This patch is just a workaround to speed up boot time of qemuppc, because
> > qemuppc has no framebuffer support, no need to start X server for qemuppc.
> >
> > Richard suggested to fix the X scripts so that if an fbdev X server is in use and
> > the framebuffer device node does not exist, it just exits cleanly with a
> > suitable message and doesn't timeout on boot.
> >
> > But I think it needs more time to implement and test.
> >> 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
> 
> We need to cc Richard/Saul on this, so they can re-consider
> and merge this as appropriate. But for me, I'm acking this
> change.

I've reluctantly merged this but I consider this a bit of a cop-out :(

Cheers,

Richard