[Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Laurent Vivier]

This series of patches adds a nice BIOS startup splash screen.

It adds a "-splash" option allowing to specify the picture file name (a 640x480 (or less) and true color PNG) to display. You can enable/disable fade in,
fade out and bootmenu. The time to display the image can be also given (in
seconds).

Idea and some parts of code are stollen from VirtualBox (GPLv2/CDDL).

[PATCH 1/3] Correct fw_cfg_add_callback()
[PATCH 2/3] [BIOS] Add splash image support
[PATCH 3/3] [QEMU] Add BIOS splash image

[Qemu-devel] [PATCH 1/3] Correct fw_cfg_add_callback()

[Laurent Vivier]

This patch is needed to be able to register firmware configuration
device callback.
It is already included in qemu as commit r5978.

Signed-off-by: Laurent Vivier <Laurent.Vivier@bull.net>
---
 qemu/hw/fw_cfg.c |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/qemu/hw/fw_cfg.c b/qemu/hw/fw_cfg.c
index 4e68670..c3b09c6 100644
--- a/qemu/hw/fw_cfg.c
+++ b/qemu/hw/fw_cfg.c
@@ -57,7 +57,6 @@ static void fw_cfg_write(FWCfgState *s, uint8_t value)
     FWCfgEntry *e = &s->entries[arch][s->cur_entry & FW_CFG_ENTRY_MASK];
 
     FW_CFG_DPRINTF("write %d\n", value);
-
     if (s->cur_entry & FW_CFG_WRITE_CHANNEL && s->cur_offset < e->len) {
         e->data[s->cur_offset++] = value;
         if (s->cur_offset == e->len) {
@@ -240,10 +239,12 @@ int fw_cfg_add_callback(void *opaque, uint16_t key, FWCfgCallback callback,
     FWCfgState *s = opaque;
     int arch = !!(key & FW_CFG_ARCH_LOCAL);
 
+    if (!(key & FW_CFG_WRITE_CHANNEL))
+        return 0;
+
     key &= FW_CFG_ENTRY_MASK;
 
-    if (key >= FW_CFG_MAX_ENTRY || !(key & FW_CFG_WRITE_CHANNEL)
-        || len > 65535)
+    if (key >= FW_CFG_MAX_ENTRY || len > 65535)
         return 0;
 
     s->entries[arch][key].data = data;
-- 
1.5.6.5

[Qemu-devel] [PATCH 2/3] [BIOS] Add splash image support

[Laurent Vivier]

This patch adds Qemu firmware configuration device interface to display
a splash image at BIOS startup.

Idea and some parts of code are stollen from VirtualBox.

Signed-off-by: Laurent Vivier <Laurent.Vivier@bull.net>
---
 bios/Makefile  |    4 +-
 bios/logo.c    |  206 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 bios/logo.h    |   56 +++++++++++++++
 bios/rombios.c |  125 +++++++++++++++++++++-------------
 4 files changed, 340 insertions(+), 51 deletions(-)
 create mode 100644 bios/logo.c
 create mode 100644 bios/logo.h

diff --git a/bios/Makefile b/bios/Makefile
index a2759a9..d30be7d 100644
--- a/bios/Makefile
+++ b/bios/Makefile
@@ -79,7 +79,7 @@ dist-clean: clean
 bios-clean:
 	rm -f  BIOS-bochs-*
 
-BIOS-bochs-legacy: rombios.c apmbios.S biossums rombios.h
+BIOS-bochs-legacy: rombios.c apmbios.S biossums rombios.h logo.c logo.h
 	$(GCC) $(BIOS_BUILD_DATE) -DLEGACY -E -P $< > _rombiosl_.c
 	$(BCC) -o rombiosl.s -C-c -D__i86__ -0 -S _rombiosl_.c
 	sed -e 's/^\.text//' -e 's/^\.data//' rombiosl.s > _rombiosl_.s
@@ -90,7 +90,7 @@ BIOS-bochs-legacy: rombios.c apmbios.S biossums rombios.h
 	rm -f  _rombiosl_.s
 
 
-rombios16.bin: rombios.c apmbios.S biossums rombios.h
+rombios16.bin: rombios.c apmbios.S biossums rombios.h logo.c logo.h
 	$(GCC) $(BIOS_BUILD_DATE) -E -P $< > _rombios_.c
 	$(BCC) -o rombios.s -C-c -D__i86__ -0 -S _rombios_.c
 	sed -e 's/^\.text//' -e 's/^\.data//' rombios.s > _rombios_.s
diff --git a/bios/logo.c b/bios/logo.c
new file mode 100644
index 0000000..d41eb10
--- /dev/null
+++ b/bios/logo.c
@@ -0,0 +1,206 @@
+/**
+ * Stuff for drawing the BIOS logo.
+ */
+
+/*
+ * Copyright (C) 2004-2008 Sun Microsystems, Inc.
+ *
+ * This file is part of VirtualBox Open Source Edition (OSE), as
+ * available from http://www.virtualbox.org. This file is free software;
+ * you can redistribute it and/or modify it under the terms of the GNU
+ * General Public License (GPL) as published by the Free Software
+ * Foundation, in version 2 as it comes in the "COPYING" file of the
+ * VirtualBox OSE distribution. VirtualBox OSE is distributed in the
+ * hope that it will be useful, but WITHOUT ANY WARRANTY of any kind.
+ *
+ * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa
+ * Clara, CA 95054 USA or visit http://www.sun.com if you need
+ * additional information or have any questions.
+ *
+ * QEMU/KVM port by Laurent Vivier <Laurent.Vivier@bull.net>
+ *
+ */
+
+#include "logo.h"
+
+#define BIOS_CFG_IOPORT 0x510
+#define BIOS_CFG_SIGNATURE 0x0000
+#define BIOS_CFG_SPLASH 0x4007
+
+#define WAIT_MS 16
+
+/**
+ * Set video mode (VGA).
+ * @params    New video mode.
+ */
+void set_mode(mode)
+  Bit8u mode;
+  {
+  ASM_START
+    push bp
+    mov  bp, sp
+
+      push ax
+
+      mov  ah, #0
+      mov  al, 4[bp] ; mode
+      int  #0x10
+
+      pop  ax
+
+    pop  bp
+  ASM_END
+  }
+
+Bit8u read_logo_byte(offset)
+  Bit8u offset;
+{
+    outw(BIOS_CFG_IOPORT, BIOS_CFG_SPLASH);
+    outb(BIOS_CFG_IOPORT + 1, LOGO_CMD_SET_OFFSET);
+    outb(BIOS_CFG_IOPORT + 1, offset);
+    return inb(BIOS_CFG_IOPORT + 1);
+}
+
+Bit16u read_logo_word(offset)
+  Bit8u offset;
+{
+    Bit16u word;
+    outw(BIOS_CFG_IOPORT, BIOS_CFG_SPLASH);
+    outb(BIOS_CFG_IOPORT + 1, LOGO_CMD_SET_OFFSET);
+    outb(BIOS_CFG_IOPORT + 1, offset);
+    word = inb(BIOS_CFG_IOPORT + 1);
+    word = (inb(BIOS_CFG_IOPORT + 1) << 8) | word;
+    return word;
+}
+
+void clear_screen()
+{
+// Hide cursor, clear screen and move cursor to starting position
+ASM_START
+    push bx
+    push cx
+    push dx
+
+    mov  ax, #0x100
+    mov  cx, #0x1000
+    int  #0x10
+
+    mov  ax, #0x700
+    mov  bh, #7
+    xor  cx, cx
+    mov  dx, #0x184f
+    int  #0x10
+
+    mov  ax, #0x200
+    xor  bx, bx
+    xor  dx, dx
+    int  #0x10
+
+    pop  dx
+    pop  cx
+    pop  bx
+ASM_END
+}
+
+Bit8u
+logo_enabled()
+{
+    LOGOHDR    *logo_hdr = 0;
+    Bit8u	is_fade_in, is_fade_out, uBootMenu;
+    Bit16u	logo_time;
+
+    /* check QEMU signature */
+
+    outw(BIOS_CFG_IOPORT, BIOS_CFG_SIGNATURE);
+    if (inb(BIOS_CFG_IOPORT + 1) != 'Q')
+        return 0;
+    if (inb(BIOS_CFG_IOPORT + 1) != 'E')
+        return 0;
+    if (inb(BIOS_CFG_IOPORT + 1) != 'M')
+        return 0;
+    if (inb(BIOS_CFG_IOPORT + 1) != 'U')
+        return 0;
+
+    /* check splash signature */
+
+    if (read_logo_word(&logo_hdr->u16Signature) != LOGO_HDR_MAGIC)
+        return 0;
+
+    /* Get options */
+
+    is_fade_in = read_logo_byte(&logo_hdr->fu8FadeIn);
+    is_fade_out = read_logo_byte(&logo_hdr->fu8FadeOut);
+    logo_time = read_logo_word(&logo_hdr->u16LogoMillies);
+
+    return (is_fade_in || is_fade_out || logo_time);
+}
+
+void logo_show()
+{
+    LOGOHDR    *logo_hdr = 0;
+    Bit8u is_fade_in;
+    Bit16u i;
+
+    set_mode(0x12); /* 640x480 */
+
+    is_fade_in = read_logo_byte(&logo_hdr->fu8FadeIn);
+
+    outw(BIOS_CFG_IOPORT, BIOS_CFG_SPLASH);
+    if (is_fade_in)
+    {
+        for (i = 0; i < LOGO_SHOW_STEPS; i++)
+        {
+            if (i != 0) { /* 0 means "unload image from memory" */
+              outb(BIOS_CFG_IOPORT + 1, LOGO_CMD_SHOW_BMP);
+              outb(BIOS_CFG_IOPORT + 1, i);
+            }
+            delay_ticks_and_check_for_keystroke(16 / WAIT_MS, 1);
+            if (check_for_keystroke())
+                break;
+        }
+    }
+    outb(BIOS_CFG_IOPORT + 1, LOGO_CMD_SHOW_BMP);
+    outb(BIOS_CFG_IOPORT + 1, LOGO_SHOW_STEPS);
+
+    return;
+}
+
+void logo_hide()
+{
+    LOGOHDR    *logo_hdr = 0;
+    Bit8u is_fade_out;
+    Bit16u i;
+
+    if (check_for_keystroke())
+       goto hide;
+
+    is_fade_out = read_logo_byte(&logo_hdr->fu8FadeOut);
+
+    outw(BIOS_CFG_IOPORT, BIOS_CFG_SPLASH);
+    if (is_fade_out)
+    {
+        for (i = LOGO_SHOW_STEPS; i > 0 ; i--)
+        {
+            outb(BIOS_CFG_IOPORT + 1, LOGO_CMD_SHOW_BMP);
+            outb(BIOS_CFG_IOPORT + 1, i);
+            delay_ticks_and_check_for_keystroke(16 / WAIT_MS, 1);
+            if (check_for_keystroke())
+                break;
+        }
+    }
+hide:
+    outb(BIOS_CFG_IOPORT + 1, LOGO_CMD_SHOW_BMP);
+    outb(BIOS_CFG_IOPORT + 1, 0);
+    set_mode(0x03);
+    clear_screen();
+
+    return;
+}
+
+Bit8u
+logo_display_boot_list()
+{
+    LOGOHDR    *logo_hdr = 0;
+
+    return read_logo_byte(&logo_hdr->fu8ShowBootMenu);
+}
diff --git a/bios/logo.h b/bios/logo.h
new file mode 100644
index 0000000..d7a7b80
--- /dev/null
+++ b/bios/logo.h
@@ -0,0 +1,56 @@
+/**
+ * BiosLogo - The Private BIOS Logo Interface.
+ */
+
+/*
+ * Copyright (C) 2006-2007 Sun Microsystems, Inc.
+ *
+ * This file is part of VirtualBox Open Source Edition (OSE), as
+ * available from http://www.virtualbox.org. This file is free software;
+ * you can redistribute it and/or modify it under the terms of the GNU
+ * General Public License (GPL) as published by the Free Software
+ * Foundation, in version 2 as it comes in the "COPYING" file of the
+ * VirtualBox OSE distribution. VirtualBox OSE is distributed in the
+ * hope that it will be useful, but WITHOUT ANY WARRANTY of any kind.
+ *
+ * The contents of this file may alternatively be used under the terms
+ * of the Common Development and Distribution License Version 1.0
+ * (CDDL) only, as it comes in the "COPYING.CDDL" file of the
+ * VirtualBox OSE distribution, in which case the provisions of the
+ * CDDL are applicable instead of those of the GPL.
+ *
+ * You may elect to license modified versions of this file under the
+ * terms and conditions of either the GPL or the CDDL or both.
+ *
+ * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa
+ * Clara, CA 95054 USA or visit http://www.sun.com if you need
+ * additional information or have any questions.
+ *
+ * QEMU/KVM port by Laurent Vivier <Laurent.Vivier@bull.net>
+ *
+ */
+
+#define LOGO_SHOW_STEPS      16
+
+#define LOGO_CMD_NOP         0
+#define LOGO_CMD_SET_OFFSET  0x01
+#define LOGO_CMD_SHOW_BMP    0x02
+
+typedef struct LOGOHDR
+{
+    /** Signature (LOGO_HDR_MAGIC/0x66BB). */
+    Bit16u        u16Signature;
+    /** Logo time (msec). */
+    Bit16u        u16LogoMillies;
+    /** Fade in - boolean. */
+    Bit8u         fu8FadeIn;
+    /** Fade out - boolean. */
+    Bit8u         fu8FadeOut;
+    /** Show setup - boolean. */
+    Bit8u         fu8ShowBootMenu;
+    /** Reserved / padding. */
+    Bit8u         u8Reserved;
+    /** Logo file size. */
+    Bit32u        cbLogo;
+} LOGOHDR;
+#define LOGO_HDR_MAGIC      0x66BB
diff --git a/bios/rombios.c b/bios/rombios.c
index 9a1cdd6..52a1391 100644
--- a/bios/rombios.c
+++ b/bios/rombios.c
@@ -1917,6 +1917,10 @@ shutdown_status_panic(status)
   BX_PANIC("Unimplemented shutdown status: %02x\n",(Bit8u)status);
 }
 
+#ifdef BX_QEMU
+#include "logo.c"
+#endif
+
 //--------------------------------------------------------------------------
 // print_bios_banner
 //   displays a the bios version
@@ -1924,6 +1928,10 @@ shutdown_status_panic(status)
 void
 print_bios_banner()
 {
+#ifdef BX_QEMU
+  if (logo_enabled())
+    return;
+#endif
   printf(BX_APPNAME" BIOS - build: %s\n%s\nOptions: ",
     BIOS_BUILD_DATE, bios_cvs_version_string);
   printf(
@@ -2021,65 +2029,78 @@ interactive_bootkey()
   Bit16u ss = get_SS();
   Bit16u valid_choice = 0;
 
+#ifdef BX_QEMU
+  if (logo_enabled()) {
+    LOGOHDR *logo_hdr = 0;
+    Bit16u logo_time;
+
+    logo_show();
+    logo_time = read_logo_word(&logo_hdr->u16LogoMillies);
+    if (!check_for_keystroke())
+      delay_ticks_and_check_for_keystroke(WAIT_MS, logo_time / 1000);
+    logo_hide();
+    if (!logo_display_boot_list())
+      return;
+  } else
+#endif // BX_QEMU
+  {
+    while (check_for_keystroke())
+      get_keystroke();
+    printf("Press F12 for boot menu.\n\n");
+    delay_ticks_and_check_for_keystroke(11, 5); /* ~3 seconds */
+  }
+  if (!check_for_keystroke())
+    return;
+  scan_code = get_keystroke();
+  if (scan_code != 0x58) /* F12 */
+        return;
+
   while (check_for_keystroke())
     get_keystroke();
 
-  printf("Press F12 for boot menu.\n\n");
+  printf("Select boot device:\n\n");
 
-  delay_ticks_and_check_for_keystroke(11, 5); /* ~3 seconds */
-  if (check_for_keystroke())
+  count = read_word(IPL_SEG, IPL_COUNT_OFFSET);
+  for (i = 0; i < count; i++)
   {
-    scan_code = get_keystroke();
-    if (scan_code == 0x58) /* F12 */
+    memcpyb(ss, &e, IPL_SEG, IPL_TABLE_OFFSET + i * sizeof (e), sizeof (e));
+    printf("%d. ", i+1);
+    switch(e.type)
     {
-      while (check_for_keystroke())
-        get_keystroke();
-
-      printf("Select boot device:\n\n");
-
-      count = read_word(IPL_SEG, IPL_COUNT_OFFSET);
-      for (i = 0; i < count; i++)
-      {
-        memcpyb(ss, &e, IPL_SEG, IPL_TABLE_OFFSET + i * sizeof (e), sizeof (e));
-        printf("%d. ", i+1);
-        switch(e.type)
+      case IPL_TYPE_FLOPPY:
+      case IPL_TYPE_HARDDISK:
+      case IPL_TYPE_CDROM:
+        printf("%s\n", drivetypes[e.type]);
+        break;
+      case IPL_TYPE_BEV:
+        printf("%s", drivetypes[4]);
+        if (e.description != 0)
         {
-          case IPL_TYPE_FLOPPY:
-          case IPL_TYPE_HARDDISK:
-          case IPL_TYPE_CDROM:
-            printf("%s\n", drivetypes[e.type]);
-            break;
-          case IPL_TYPE_BEV:
-            printf("%s", drivetypes[4]);
-            if (e.description != 0)
-            {
-              memcpyb(ss, &description, (Bit16u)(e.description >> 16), (Bit16u)(e.description & 0xffff), 32);
-              description[32] = 0;
-              printf(" [%S]", ss, description);
-           }
-           printf("\n");
-           break;
-        }
-      }
+          memcpyb(ss, &description, (Bit16u)(e.description >> 16), (Bit16u)(e.description & 0xffff), 32);
+          description[32] = 0;
+          printf(" [%S]", ss, description);
+       }
+       printf("\n");
+       break;
+    }
+  }
 
-      count++;
-      while (!valid_choice) {
-        scan_code = get_keystroke();
-        if (scan_code == 0x01 || scan_code == 0x58) /* ESC or F12 */
-        {
-          valid_choice = 1;
-        }
-        else if (scan_code <= count)
-        {
-          valid_choice = 1;
-          scan_code -= 1;
-          /* Set user selected device */
-          write_word(IPL_SEG, IPL_BOOTFIRST_OFFSET, scan_code);
-        }
-      }
-    printf("\n");
+  count++;
+  while (!valid_choice) {
+    scan_code = get_keystroke();
+    if (scan_code == 0x01 || scan_code == 0x58) /* ESC or F12 */
+    {
+      valid_choice = 1;
+    }
+    else if (scan_code <= count)
+    {
+      valid_choice = 1;
+      scan_code -= 1;
+      /* Set user selected device */
+      write_word(IPL_SEG, IPL_BOOTFIRST_OFFSET, scan_code);
     }
   }
+  printf("\n");
 }
 #endif // BX_ELTORITO_BOOT
 
@@ -2706,6 +2727,9 @@ void ata_detect( )
           break;
         }
 
+#ifdef BX_QEMU
+      if (!logo_enabled()) {
+#endif
       switch (type) {
         case ATA_TYPE_ATA:
           printf("ata%d %s: ",channel,slave?" slave":"master");
@@ -2727,6 +2751,9 @@ void ata_detect( )
           printf("ata%d %s: Unknown device\n",channel,slave?" slave":"master");
           break;
         }
+#ifdef BX_QEMU
+        }
+#endif
       }
     }
 
-- 
1.5.6.5

[Qemu-devel] [PATCH 3/3] [QEMU] Add BIOS splash image

[Laurent Vivier]

This patch adds to qemu the function needed to display a splash image under
BIOS control through the firmware control device.

It adds a "-splash" option allowing to specify the picture file name (a .PNG)
to display. You can enable/disable a fade in, fade out and the bootmenu. The
time to display the image can be also given (in seconds).

Signed-off-by: Laurent Vivier <Laurent.Vivier@bull.net>
---
 qemu/Makefile.target      |    2 +-
 qemu/configure            |   19 +++
 qemu/hw/bootmenu_pixmap.h |  231 +++++++++++++++++++++++++++++++++++++
 qemu/hw/fw_cfg.h          |    1 +
 qemu/hw/pc.c              |  276 ++++++++++++++++++++++++++++++++++++++++++++-
 qemu/sysemu.h             |    1 +
 qemu/vl.c                 |   19 +++
 7 files changed, 545 insertions(+), 4 deletions(-)
 create mode 100644 qemu/hw/bootmenu_pixmap.h

diff --git a/qemu/Makefile.target b/qemu/Makefile.target
index d6a6479..65f0252 100644
--- a/qemu/Makefile.target
+++ b/qemu/Makefile.target
@@ -894,7 +894,7 @@ firmware.o: firmware.c
 endif
 
 $(QEMU_PROG): $(OBJS) ../libqemu_common.a libqemu.a $(DEPLIBS)
-	$(CC) $(LDFLAGS) -o $@ $^ $(LIBS) $(SDL_LIBS) $(COCOA_LIBS) $(CURSES_LIBS) $(BRLAPI_LIBS) $(VDE_LIBS)
+	$(CC) $(LDFLAGS) -o $@ $^ $(LIBS) $(SDL_LIBS) $(COCOA_LIBS) $(PNGLITE_LIBS) $(CURSES_LIBS) $(BRLAPI_LIBS) $(VDE_LIBS)
 
 endif # !CONFIG_USER_ONLY
 
diff --git a/qemu/configure b/qemu/configure
index 1f8b9b4..7f20a4b 100755
--- a/qemu/configure
+++ b/qemu/configure
@@ -833,6 +833,19 @@ else
 fi
 
 ##########################################
+# libpnglite check
+
+cat > $TMPC << EOF
+#include <pnglite.h>
+int main(void) { (void)png_init(NULL, NULL); return 0; }
+EOF
+if $cc $ARCH_CFLAGS -o $TMPE ${OS_CFLAGS} $TMPC -lz -lpnglite 2> /dev/null ; then
+    pnglite=yes
+else
+    pnglite=no
+fi
+
+##########################################
 # SDL probe
 
 sdl_too_old=no
@@ -1187,6 +1200,7 @@ echo "SDL support       $sdl"
 if test "$sdl" != "no" ; then
     echo "SDL static link   $sdl_static"
 fi
+echo "pnglite support   $pnglite"
 echo "curses support    $curses"
 echo "mingw32 support   $mingw32"
 echo "Audio drivers     $audio_drv_list"
@@ -1477,6 +1491,11 @@ if test "$cocoa" = "yes" ; then
   echo "#define CONFIG_COCOA 1" >> $config_h
   echo "CONFIG_COCOA=yes" >> $config_mak
 fi
+if test "$pnglite" = "yes" ; then
+  echo "#define CONFIG_PNGLITE 1" >> $config_h
+  echo "CONFIG_PNGLITE=yes" >> $config_mak
+  echo "PNGLITE_LIBS=-lpnglite" >> $config_mak
+fi
 if test "$curses" = "yes" ; then
   echo "#define CONFIG_CURSES 1" >> $config_h
   echo "CONFIG_CURSES=yes" >> $config_mak
diff --git a/qemu/hw/bootmenu_pixmap.h b/qemu/hw/bootmenu_pixmap.h
new file mode 100644
index 0000000..a33ddb4
--- /dev/null
+++ b/qemu/hw/bootmenu_pixmap.h
@@ -0,0 +1,231 @@
+/*  GIMP header image file format (INDEXED): /home/vivierl/Desktop/Press F12 for boot menu.h  */
+
+#define SPLASH_BOOTMENU_WIDTH 216
+#define SPLASH_BOOTMENU_HEIGHT 16
+
+static char bootmenu_pixmap[] = {
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,
+	1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,1,1,1,1,1,1,1,0,0,0,
+	0,0,1,1,0,0,0,0,0,1,1,1,1,1,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,1,1,1,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,1,
+	1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,
+	0,1,1,0,0,1,1,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,1,1,0,0,1,1,0,0,0,
+	0,1,1,1,0,0,0,0,1,1,0,0,0,1,1,0,
+	0,0,0,0,0,0,0,0,0,0,0,1,1,0,1,1,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
+	1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,1,1,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,
+	0,1,1,0,0,1,1,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,1,1,0,0,0,1,0,0,0,
+	1,1,1,1,0,0,0,0,0,0,0,0,0,1,1,0,
+	0,0,0,0,0,0,0,0,0,0,0,1,1,0,0,1,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
+	1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,1,1,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,
+	0,1,1,0,0,1,1,0,0,1,1,0,1,1,1,0,
+	0,0,0,1,1,1,1,1,0,0,0,0,1,1,1,1,
+	1,0,0,0,0,1,1,1,1,1,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,1,1,0,1,0,0,0,0,0,
+	0,0,1,1,0,0,0,0,0,0,0,0,1,1,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,1,1,0,0,0,
+	0,0,0,0,1,1,1,1,1,0,0,0,1,1,0,1,
+	1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
+	1,1,1,0,0,0,0,0,1,1,1,1,1,0,0,0,
+	0,1,1,1,1,1,0,0,0,1,1,1,1,1,1,0,
+	0,0,0,0,0,0,0,0,0,0,0,1,1,1,0,0,
+	1,1,0,0,0,1,1,1,1,1,0,0,0,1,1,0,
+	1,1,1,0,0,0,1,1,0,0,1,1,0,0,0,0,
+	0,0,0,0,0,0,0,0,
+	0,1,1,1,1,1,0,0,0,0,1,1,1,0,1,1,
+	0,0,1,1,0,0,0,1,1,0,0,1,1,0,0,0,
+	1,1,0,0,1,1,0,0,0,1,1,0,0,0,0,0,
+	0,0,0,0,0,0,0,1,1,1,1,0,0,0,0,0,
+	0,0,1,1,0,0,0,0,0,0,0,1,1,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,1,1,1,1,0,0,
+	0,0,0,1,1,0,0,0,1,1,0,0,0,1,1,1,
+	0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,1,
+	1,0,1,1,0,0,0,1,1,0,0,0,1,1,0,0,
+	1,1,0,0,0,1,1,0,0,0,0,1,1,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,1,1,1,1,1,
+	1,1,1,0,1,1,0,0,0,1,1,0,0,0,1,1,
+	0,0,1,1,0,0,1,1,0,0,1,1,0,0,0,0,
+	0,0,0,0,0,0,0,0,
+	0,1,1,0,0,0,0,0,0,0,1,1,0,0,1,1,
+	0,0,1,1,1,1,1,1,1,0,0,0,1,1,0,0,
+	0,0,0,0,0,1,1,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,1,1,0,1,0,0,0,0,0,
+	0,0,1,1,0,0,0,0,0,0,1,1,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,1,1,0,0,0,
+	0,0,0,1,1,0,0,0,1,1,0,0,0,1,1,0,
+	0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,1,
+	1,0,0,1,1,0,0,1,1,0,0,0,1,1,0,0,
+	1,1,0,0,0,1,1,0,0,0,0,1,1,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,1,1,0,1,1,
+	0,1,1,0,1,1,1,1,1,1,1,0,0,0,1,1,
+	0,0,1,1,0,0,1,1,0,0,1,1,0,0,0,0,
+	0,0,0,0,0,0,0,0,
+	0,1,1,0,0,0,0,0,0,0,1,1,0,0,0,0,
+	0,0,1,1,0,0,0,0,0,0,0,0,0,1,1,1,
+	0,0,0,0,0,0,1,1,1,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,1,1,0,0,0,0,0,0,0,
+	0,0,1,1,0,0,0,0,0,1,1,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,1,1,0,0,0,
+	0,0,0,1,1,0,0,0,1,1,0,0,0,1,1,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
+	1,0,0,1,1,0,0,1,1,0,0,0,1,1,0,0,
+	1,1,0,0,0,1,1,0,0,0,0,1,1,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,1,1,0,1,1,
+	0,1,1,0,1,1,0,0,0,0,0,0,0,0,1,1,
+	0,0,1,1,0,0,1,1,0,0,1,1,0,0,0,0,
+	0,0,0,0,0,0,0,0,
+	0,1,1,0,0,0,0,0,0,0,1,1,0,0,0,0,
+	0,0,1,1,0,0,0,0,0,0,0,0,0,0,0,1,
+	1,0,0,0,0,0,0,0,1,1,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,1,1,0,0,0,0,0,0,0,
+	0,0,1,1,0,0,0,0,1,1,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,1,1,0,0,0,
+	0,0,0,1,1,0,0,0,1,1,0,0,0,1,1,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
+	1,0,0,1,1,0,0,1,1,0,0,0,1,1,0,0,
+	1,1,0,0,0,1,1,0,0,0,0,1,1,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,1,1,0,1,1,
+	0,1,1,0,1,1,0,0,0,0,0,0,0,0,1,1,
+	0,0,1,1,0,0,1,1,0,0,1,1,0,0,0,0,
+	0,0,0,0,0,0,0,0,
+	0,1,1,0,0,0,0,0,0,0,1,1,0,0,0,0,
+	0,0,1,1,0,0,0,1,1,0,0,1,1,0,0,0,
+	1,1,0,0,1,1,0,0,0,1,1,0,0,0,0,0,
+	0,0,0,0,0,0,0,1,1,0,0,0,0,0,0,0,
+	0,0,1,1,0,0,0,0,1,1,0,0,0,1,1,0,
+	0,0,0,0,0,0,0,0,0,0,0,1,1,0,0,0,
+	0,0,0,1,1,0,0,0,1,1,0,0,0,1,1,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
+	1,0,0,1,1,0,0,1,1,0,0,0,1,1,0,0,
+	1,1,0,0,0,1,1,0,0,0,0,1,1,0,1,1,
+	0,0,0,0,0,0,0,0,0,0,0,1,1,0,1,1,
+	0,1,1,0,1,1,0,0,0,1,1,0,0,0,1,1,
+	0,0,1,1,0,0,1,1,0,0,1,1,0,0,0,0,
+	0,0,1,1,0,0,0,0,
+	1,1,1,1,0,0,0,0,0,1,1,1,1,0,0,0,
+	0,0,0,1,1,1,1,1,0,0,0,0,1,1,1,1,
+	1,0,0,0,0,1,1,1,1,1,0,0,0,0,0,0,
+	0,0,0,0,0,0,1,1,1,1,0,0,0,0,0,0,
+	1,1,1,1,1,1,0,0,1,1,1,1,1,1,1,0,
+	0,0,0,0,0,0,0,0,0,0,1,1,1,1,0,0,
+	0,0,0,0,1,1,1,1,1,0,0,0,1,1,1,1,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
+	1,1,1,1,0,0,0,0,1,1,1,1,1,0,0,0,
+	0,1,1,1,1,1,0,0,0,0,0,0,1,1,1,0,
+	0,0,0,0,0,0,0,0,0,0,0,1,1,0,1,1,
+	0,1,1,0,0,1,1,1,1,1,0,0,0,0,1,1,
+	0,0,1,1,0,0,0,1,1,1,0,1,1,0,0,0,
+	0,0,1,1,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+	0,0,0,0,0,0,0,0
+	};
diff --git a/qemu/hw/fw_cfg.h b/qemu/hw/fw_cfg.h
index ef8f378..41fdde8 100644
--- a/qemu/hw/fw_cfg.h
+++ b/qemu/hw/fw_cfg.h
@@ -8,6 +8,7 @@
 #define FW_CFG_NOGRAPHIC        0x04
 #define FW_CFG_NB_CPUS          0x05
 #define FW_CFG_MACHINE_ID       0x06
+#define FW_CFG_SPLASH           (FW_CFG_WRITE_CHANNEL | 0x07)
 #define FW_CFG_MAX_ENTRY        0x10
 
 #define FW_CFG_WRITE_CHANNEL    0x4000
diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
index 3cf5a73..74ba523 100644
--- a/qemu/hw/pc.c
+++ b/qemu/hw/pc.c
@@ -36,6 +36,9 @@
 #include "virtio-blk.h"
 #include "virtio-balloon.h"
 #include "device-assignment.h"
+#ifdef CONFIG_PNGLITE
+#include <pnglite.h>
+#endif
 
 #include "qemu-kvm.h"
 
@@ -423,7 +426,256 @@ static void bochs_bios_write(void *opaque, uint32_t addr, uint32_t val)
     }
 }
 
-static void bochs_bios_init(void)
+#ifdef CONFIG_PNGLITE
+struct logo_header {
+    uint16_t        signature;
+    uint16_t        duration;
+    uint8_t         fadein;
+    uint8_t         fadeout;
+    uint8_t         bootmenu;
+    uint8_t         pad;
+    uint32_t        size;
+};
+
+#define LOGO_HDR_MAGIC	0x66BB
+
+struct splash_info {
+    uint16_t data;
+    DisplayState *ds;
+    int width;
+    int height;
+    struct logo_header *logo;
+};
+
+#define LOGO_CMD_NOP		0x00
+#define LOGO_CMD_SET_OFFSET	0x01
+#define LOGO_CMD_SHOW_BMP	0x02
+#define 	LOGO_SHOW_STEPS	16
+
+#define SPLASH_WIDTH    640
+#define SPLASH_HEIGHT   480
+#define SPLASH_BPP      4
+#define SPLASH_DURATION 2000
+
+#include "bootmenu_pixmap.h"
+
+static void splash_show_info(struct splash_info *info, int step)
+{
+    int i, j;
+    uint8_t *d;
+    int origin_x, origin_y;
+
+    origin_y = ds_get_height(info->ds) - SPLASH_BOOTMENU_HEIGHT;
+    origin_x = (ds_get_width(info->ds) - SPLASH_BOOTMENU_WIDTH) / 2;
+
+    d = ds_get_data(info->ds);
+    d += origin_y * ds_get_linesize(info->ds);
+    d += origin_x * ds_get_bits_per_pixel(info->ds) / 8;
+
+    for (i = 0; i < SPLASH_BOOTMENU_HEIGHT; i++) {
+        for (j = 0; j < SPLASH_BOOTMENU_WIDTH; j++ ) {
+            if (bootmenu_pixmap[i * SPLASH_BOOTMENU_WIDTH + j])
+                switch(ds_get_bits_per_pixel(info->ds)) {
+                case 32:
+                    d[j * 4] = d[j * 4 + 1] = d[j * 4 + 2] =
+                                    255 * step / LOGO_SHOW_STEPS;
+                    break;
+                case 24:
+                    d[j * 3] = d[j * 3 + 1] = d[j * 3 + 2] =
+                                    255 * step / LOGO_SHOW_STEPS;
+                    break;
+            }
+        }
+        d += ds_get_linesize(info->ds);
+    }
+
+    dpy_update(info->ds, origin_x, origin_y,
+               SPLASH_BOOTMENU_WIDTH, SPLASH_BOOTMENU_HEIGHT);
+}
+
+static void splash_show(struct splash_info *info, int step)
+{
+    int i, j;
+    uint8_t *d, *s;
+    int origin_x, origin_y;
+
+    if (ds_get_width(info->ds) < SPLASH_WIDTH ||
+        ds_get_height(info->ds) < SPLASH_HEIGHT ||
+        ds_get_bits_per_pixel(info->ds) < 24)
+	return;
+
+    origin_y = (ds_get_height(info->ds) - info->height) / 2;
+    origin_x = (ds_get_width(info->ds) - info->width) / 2;
+    d = ds_get_data(info->ds);
+    d += origin_y * ds_get_linesize(info->ds);
+    d += origin_x * ds_get_bits_per_pixel(info->ds) / 8;
+    s = (uint8_t*)info->logo + sizeof(struct logo_header);
+    for (i = 0; i < info->height; i++) {
+        for (j = 0; j < info->width; j++ ) {
+	    int r, g, b;
+            b = s[j * SPLASH_BPP + 0];
+            g = s[j * SPLASH_BPP + 1];
+            r = s[j * SPLASH_BPP + 2];
+            r = r * step / LOGO_SHOW_STEPS;
+            g = g * step / LOGO_SHOW_STEPS;
+            b = b * step / LOGO_SHOW_STEPS;
+            switch(ds_get_bits_per_pixel(info->ds)) {
+            case 32:
+                d[j * 4] = r; d[j * 4 + 1] = g; d[j * 4 + 2] = b;
+                break;
+            case 24:
+                d[j * 3] = r; d[j * 3 + 1] = g; d[j * 3] = b;
+                break;
+            }
+        }
+        s += info->width * 4;
+        d += ds_get_linesize(info->ds);
+    }
+
+    if (info->logo->bootmenu)
+        splash_show_info(info, step);
+
+    dpy_update(info->ds, origin_x, origin_y, info->width, info->height);
+}
+
+static void splash_load(struct splash_info *info)
+{
+    int len;
+    png_t png;
+    char buf[128];
+    char file[1024];
+    static const char * const params[] = { "file", "fadein", "fadeout",
+                                           "duration", "bootmenu", NULL };
+
+    if (check_params(buf, sizeof(buf), params, splash_image) < 0) {
+         fprintf(stderr, "qemu: unknown parameter '%s' in '%s'\n",
+                         buf, splash_image);
+         return;
+    }
+
+    if (!get_param_value(file, sizeof(file), "file", splash_image))
+        return;
+
+    /* load splash image */
+
+    png_init(qemu_malloc, qemu_free);
+
+    if (png_open_file(&png, file) != PNG_NO_ERROR)
+        return;
+
+    if (png.bpp != SPLASH_BPP || png.width > SPLASH_WIDTH ||
+        png.height > SPLASH_HEIGHT) {
+        fprintf(stderr, "qemu: splash image %s is greater than %dx%dx%d\n",
+                file, SPLASH_WIDTH, SPLASH_HEIGHT, SPLASH_BPP * 8);
+        return;
+    }
+
+    len = png.width * png.height * png.bpp + sizeof(struct logo_header);
+    info->logo = qemu_malloc(len);
+    if (info->logo == NULL) {
+        png_close_file(&png);
+        fprintf(stderr, "qemu: cannot allocate memory for %s\n", file);
+        return;
+    }
+
+    if (png_get_data(&png,
+                     (uint8_t*)info->logo +
+                     sizeof(struct logo_header)) != PNG_NO_ERROR) {
+        fprintf(stderr, "Cannot load splash screen %s\n", buf);
+        free(info->logo);
+        info->logo = NULL;
+        png_close_file(&png);
+        return;
+    }
+    png_close_file(&png);
+
+    info->width = png.width;
+    info->height = png.height;
+    info->logo->signature = cpu_to_le16(LOGO_HDR_MAGIC);
+    info->logo->size = cpu_to_le32(len);
+
+    info->logo->fadein = 1;
+    if (get_param_value(buf, sizeof(buf), "fadein", splash_image)) {
+        if (!strcmp(buf, "off"))
+            info->logo->fadein = 0;
+        else if (strcmp(buf, "on"))
+            fprintf(stderr, "qemu: '%s' invalid splash option\n", splash_image);
+    }
+
+    info->logo->fadeout = 1;
+    if (get_param_value(buf, sizeof(buf), "fadeout", splash_image)) {
+        if (!strcmp(buf, "off"))
+            info->logo->fadeout = 0;
+        else if (strcmp(buf, "on"))
+            fprintf(stderr, "qemu: '%s' invalid splash option\n", splash_image);
+    }
+
+    info->logo->bootmenu = 1;
+    if (get_param_value(buf, sizeof(buf), "bootmenu", splash_image)) {
+        if (!strcmp(buf, "off"))
+            info->logo->bootmenu = 0;
+        else if (strcmp(buf, "on"))
+            fprintf(stderr, "qemu: '%s' invalid splash option\n", splash_image);
+    }
+
+    info->logo->duration = SPLASH_DURATION;
+    if (get_param_value(buf, sizeof(buf), "duration", splash_image)) {
+        int duration = strtol(buf, NULL, 0);
+        if (duration != 0 || errno != EINVAL)
+            info->logo->duration = duration * 1000;
+    }
+}
+
+/* free splash image */
+
+static void splash_unload(struct splash_info *info)
+{
+    if (info->logo)
+        free(info->logo);
+
+    info->logo = NULL;
+}
+
+static void splash_controller(void *opaque, uint8_t *data)
+{
+    struct splash_info *info = (struct splash_info *)opaque;
+    uint16_t cmd = *(uint16_t*)data;
+
+    switch (cmd & 0x00FF) {
+
+    case LOGO_CMD_NOP:
+        break;
+
+    case LOGO_CMD_SHOW_BMP:
+        cmd >>= 8;
+        if (info->logo == NULL) {
+            splash_load(info);
+            if (info->logo == NULL)
+                break;
+        }
+        splash_show(info, cmd);
+        if (cmd == 0)
+            splash_unload(info);
+        break;
+
+    case LOGO_CMD_SET_OFFSET:
+        if (info->logo == NULL) {
+            splash_load(info);
+            if (info->logo == NULL)
+                break;
+        }
+        cmd >>= 8;
+        if (cmd >= info->logo->size)
+            break;
+        memcpy(&info->data, ((char*)info->logo) + cmd,
+               sizeof(info->data));
+        break;
+
+    }
+}
+#endif /* CONFIG_PNGLITE */
+
+static void bochs_bios_init(DisplayState *ds)
 {
     void *fw_cfg;
 
@@ -441,6 +693,24 @@ static void bochs_bios_init(void)
     fw_cfg = fw_cfg_init(BIOS_CFG_IOPORT, BIOS_CFG_IOPORT + 1, 0, 0);
     fw_cfg_add_i32(fw_cfg, FW_CFG_ID, 1);
     fw_cfg_add_i64(fw_cfg, FW_CFG_RAM_SIZE, (uint64_t)ram_size);
+
+#ifdef CONFIG_PNGLITE
+    if (!nographic && splash_image) {
+        struct splash_info *splash;
+
+        splash = qemu_mallocz(sizeof(*splash));
+        if (!splash)
+            return;
+
+        splash->ds = ds;
+        splash->logo = NULL;
+
+        if (!fw_cfg_add_callback(fw_cfg, FW_CFG_SPLASH,
+                                 splash_controller, splash,
+                                 &splash->data, sizeof(splash->data)))
+            qemu_free(splash);
+    }
+#endif /* CONFIG_PNGLITE */
 }
 
 /* Generate an initial boot sector which sets state and jump to
@@ -977,8 +1247,6 @@ static void pc_init1(ram_addr_t ram_size, int vga_ram_size,
     cpu_register_physical_memory((uint32_t)(-bios_size),
                                  bios_size, bios_offset | IO_MEM_ROM);
 
-    bochs_bios_init();
-
     cpu_irq = qemu_allocate_irqs(pic_irq_request, NULL, 1);
     i8259 = i8259_init(cpu_irq[0]);
     ferr_irq = i8259[13];
@@ -1020,6 +1288,8 @@ static void pc_init1(ram_addr_t ram_size, int vga_ram_size,
         }
     }
 
+    bochs_bios_init(ds);
+
     rtc_state = rtc_init(0x70, i8259[8]);
 
     qemu_register_boot_set(pc_boot_set, rtc_state);
diff --git a/qemu/sysemu.h b/qemu/sysemu.h
index 5abda5c..ff8669b 100644
--- a/qemu/sysemu.h
+++ b/qemu/sysemu.h
@@ -99,6 +99,7 @@ extern int win2k_install_hack;
 extern int alt_grab;
 extern int usb_enabled;
 extern int smp_cpus;
+extern char *splash_image;
 extern int cursor_hide;
 extern int graphic_rotate;
 extern int no_quit;
diff --git a/qemu/vl.c b/qemu/vl.c
index 7b58605..01aea0f 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -228,6 +228,9 @@ int usb_enabled = 0;
 const char *assigned_devices[MAX_DEV_ASSIGN_CMDLINE];
 int assigned_devices_index;
 int smp_cpus = 1;
+#ifdef CONFIG_PNGLITE
+char *splash_image = NULL;
+#endif
 const char *vnc_display;
 int acpi_enabled = 1;
 int fd_bootchk = 1;
@@ -3986,6 +3989,11 @@ static void help(int exitcode)
 #ifdef TARGET_I386
            "-win2k-hack     use it when installing Windows 2000 to avoid a disk full bug\n"
 #endif
+#ifdef CONFIG_PNGLITE
+           "-splash file=name.png[,fadein=on|off][,fadeout=on|off]\n"
+           "        [,bootmenu=on|off][,duration=seconds]\n"
+           "                display a splash image at BIOS startup\n"
+#endif
            "-usb            enable the USB driver (will be the default soon)\n"
            "-usbdevice name add the host or guest USB device 'name'\n"
 #if defined(TARGET_PPC) || defined(TARGET_SPARC)
@@ -4195,6 +4203,9 @@ enum {
     QEMU_OPTION_kernel_kqemu,
     QEMU_OPTION_enable_kvm,
     QEMU_OPTION_win2k_hack,
+#ifdef CONFIG_PNGLITE
+    QEMU_OPTION_splash,
+#endif
     QEMU_OPTION_usb,
     QEMU_OPTION_usbdevice,
     QEMU_OPTION_smp,
@@ -4323,6 +4334,9 @@ static const QEMUOption qemu_options[] = {
 #endif
     { "pidfile", HAS_ARG, QEMU_OPTION_pidfile },
     { "win2k-hack", 0, QEMU_OPTION_win2k_hack },
+#ifdef CONFIG_PNGLITE
+    { "splash", HAS_ARG, QEMU_OPTION_splash },
+#endif
     { "usbdevice", HAS_ARG, QEMU_OPTION_usbdevice },
     { "smp", HAS_ARG, QEMU_OPTION_smp },
     { "vnc", HAS_ARG, QEMU_OPTION_vnc },
@@ -5234,6 +5248,11 @@ int main(int argc, char **argv)
                 win2k_install_hack = 1;
                 break;
 #endif
+#ifdef CONFIG_PNGLITE
+            case QEMU_OPTION_splash:
+                splash_image = optarg;
+                break;
+#endif
 #ifdef USE_KQEMU
             case QEMU_OPTION_no_kqemu:
                 kqemu_allowed = 0;
-- 
1.5.6.5

Re: [Qemu-devel] [PATCH 3/3] [QEMU] Add BIOS splash image

[Andreas Färber]

Am 16.12.2008 um 16:20 schrieb Laurent Vivier:

> This patch adds to qemu the function needed to display a splash  
> image under
> BIOS control through the firmware control device.
>
> It adds a "-splash" option allowing to specify the picture file name  
> (a .PNG)
> to display. You can enable/disable a fade in, fade out and the  
> bootmenu. The
> time to display the image can be also given (in seconds).
>
> Signed-off-by: Laurent Vivier <Laurent.Vivier@bull.net>
> ---
> qemu/Makefile.target      |    2 +-
> qemu/configure            |   19 +++
> qemu/hw/bootmenu_pixmap.h |  231 +++++++++++++++++++++++++++++++++++++
> qemu/hw/fw_cfg.h          |    1 +
> qemu/hw/pc.c              |  276 ++++++++++++++++++++++++++++++++++++ 
> ++++++++-
> qemu/sysemu.h             |    1 +
> qemu/vl.c                 |   19 +++
> 7 files changed, 545 insertions(+), 4 deletions(-)

This is lacking documentation.

Andreas

Re: [Qemu-devel] [PATCH 3/3] [QEMU] Add BIOS splash image

[Laurent Vivier]

Le 16 déc. 08 à 16:33, Andreas Färber a écrit :

>
> Am 16.12.2008 um 16:20 schrieb Laurent Vivier:
>
>> This patch adds to qemu the function needed to display a splash  
>> image under
>> BIOS control through the firmware control device.
>>
>> It adds a "-splash" option allowing to specify the picture file  
>> name (a .PNG)
>> to display. You can enable/disable a fade in, fade out and the  
>> bootmenu. The
>> time to display the image can be also given (in seconds).
>>
>> Signed-off-by: Laurent Vivier <Laurent.Vivier@bull.net>
>> ---
>> qemu/Makefile.target      |    2 +-
>> qemu/configure            |   19 +++
>> qemu/hw/bootmenu_pixmap.h |  231 +++++++++++++++++++++++++++++++++++ 
>> ++
>> qemu/hw/fw_cfg.h          |    1 +
>> qemu/hw/pc.c              |  276 +++++++++++++++++++++++++++++++++++ 
>> +++++++++-
>> qemu/sysemu.h             |    1 +
>> qemu/vl.c                 |   19 +++
>> 7 files changed, 545 insertions(+), 4 deletions(-)
>
> This is lacking documentation.

I agree, but I'm lazy and I was wondering if someone could really be  
interested by this functionality. If so, I'll write it.

Regards,
Laurent
----------------------- Laurent Vivier ----------------------
"The best way to predict the future is to invent it."
- Alan Kay

Re: [Qemu-devel] [PATCH 3/3] [QEMU] Add BIOS splash image

[Blue Swirl]

On 12/16/08, Laurent Vivier <Laurent.Vivier@bull.net> wrote:
> This patch adds to qemu the function needed to display a splash image under
>  BIOS control through the firmware control device.
>
>  It adds a "-splash" option allowing to specify the picture file name (a .PNG)
>  to display. You can enable/disable a fade in, fade out and the bootmenu. The
>  time to display the image can be also given (in seconds).

Nice. But shouldn't this be more generic, I think we want to use this
on OpenBIOS/Sparc (or PPC) too?

Re: [Qemu-devel] [PATCH 3/3] [QEMU] Add BIOS splash image

[Laurent Vivier]

Le 16 déc. 08 à 17:16, Blue Swirl a écrit :

> On 12/16/08, Laurent Vivier <Laurent.Vivier@bull.net> wrote:
>> This patch adds to qemu the function needed to display a splash  
>> image under
>> BIOS control through the firmware control device.
>>
>> It adds a "-splash" option allowing to specify the picture file  
>> name (a .PNG)
>> to display. You can enable/disable a fade in, fade out and the  
>> bootmenu. The
>> time to display the image can be also given (in seconds).
>
> Nice. But shouldn't this be more generic, I think we want to use this
> on OpenBIOS/Sparc (or PPC) too?

I think it is generic as it uses the firmware configuration device, we  
have just to modify openbios to use it (I think sparc uses it to have  
ram size).
The only possible issue with this patch is it depends on libpnglite to  
read the file.

The "bootmenu=off" can be an alias to "auto-boot?=true"

Regards,
Laurent
----------------------- Laurent Vivier ----------------------
"The best way to predict the future is to invent it."
- Alan Kay

Re: [Qemu-devel] [PATCH 3/3] [QEMU] Add BIOS splash image

[Blue Swirl]

On 12/16/08, Laurent Vivier <laurent@lvivier.info> wrote:
>
>  Le 16 déc. 08 à 17:16, Blue Swirl a écrit :
>
>
>
> > On 12/16/08, Laurent Vivier <Laurent.Vivier@bull.net> wrote:
> >
> > > This patch adds to qemu the function needed to display a splash image
> under
> > > BIOS control through the firmware control device.
> > >
> > > It adds a "-splash" option allowing to specify the picture file name (a
> .PNG)
> > > to display. You can enable/disable a fade in, fade out and the bootmenu.
> The
> > > time to display the image can be also given (in seconds).
> > >
> >
> > Nice. But shouldn't this be more generic, I think we want to use this
> > on OpenBIOS/Sparc (or PPC) too?
> >
>
>  I think it is generic as it uses the firmware configuration device, we have
> just to modify openbios to use it (I think sparc uses it to have ram size).
>  The only possible issue with this patch is it depends on libpnglite to read
> the file.

I meant that most of the code should not reside in pc.c, but in a common file.

>  The "bootmenu=off" can be an alias to "auto-boot?=true"

I missed the bootmenu part, how does it work?

Re: [Qemu-devel] [PATCH 3/3] [QEMU] Add BIOS splash image

[Laurent Vivier]

Le 16 déc. 08 à 18:41, Blue Swirl a écrit :

> On 12/16/08, Laurent Vivier <laurent@lvivier.info> wrote:
>>
>> Le 16 déc. 08 à 17:16, Blue Swirl a écrit :
>>
>>
>>
>>> On 12/16/08, Laurent Vivier <Laurent.Vivier@bull.net> wrote:
>>>
>>>> This patch adds to qemu the function needed to display a splash  
>>>> image
>> under
>>>> BIOS control through the firmware control device.
>>>>
>>>> It adds a "-splash" option allowing to specify the picture file  
>>>> name (a
>> .PNG)
>>>> to display. You can enable/disable a fade in, fade out and the  
>>>> bootmenu.
>> The
>>>> time to display the image can be also given (in seconds).
>>>>
>>>
>>> Nice. But shouldn't this be more generic, I think we want to use  
>>> this
>>> on OpenBIOS/Sparc (or PPC) too?
>>>
>>
>> I think it is generic as it uses the firmware configuration device,  
>> we have
>> just to modify openbios to use it (I think sparc uses it to have  
>> ram size).
>> The only possible issue with this patch is it depends on libpnglite  
>> to read
>> the file.
>
> I meant that most of the code should not reside in pc.c, but in a  
> common file.

Yes, I just understood that it was what you meant. Perhaps in a  
"splash.c" file...
>
>> The "bootmenu=off" can be an alias to "auto-boot?=true"
>
> I missed the bootmenu part, how does it work?

It disables the "Press F12 to select a boot device" part.

Laurent
----------------------- Laurent Vivier ----------------------
"The best way to predict the future is to invent it."
- Alan Kay

Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Blue Swirl]

On 12/16/08, Laurent Vivier <Laurent.Vivier@bull.net> wrote:
> This series of patches adds a nice BIOS startup splash screen.
>
>  It adds a "-splash" option allowing to specify the picture file name (a 640x480 (or less) and true color PNG) to display. You can enable/disable fade in,
>  fade out and bootmenu. The time to display the image can be also given (in
>  seconds).
>
>  Idea and some parts of code are stollen from VirtualBox (GPLv2/CDDL).
>
>  [PATCH 1/3] Correct fw_cfg_add_callback()
>  [PATCH 2/3] [BIOS] Add splash image support
>  [PATCH 3/3] [QEMU] Add BIOS splash image

On second thought, there is no Gtk/Qt GUI because that is supposed to
be external to Qemu. By the same logic, why should there be any splash
screen? The external GUI can probably show it as easily using the same
Gtk/Qt/whatever. The control channel may still be needed.

Alternatively the BIOS could load the image and fade parameters from a
new ROM or from the configuration device and draw it to screen. This
would need some PNG support to BIOS, or that the image stored in raw
form.

Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Anthony Liguori]

Blue Swirl wrote:
> On 12/16/08, Laurent Vivier <Laurent.Vivier@bull.net> wrote:
>   
>> This series of patches adds a nice BIOS startup splash screen.
>>
>>  It adds a "-splash" option allowing to specify the picture file name (a 640x480 (or less) and true color PNG) to display. You can enable/disable fade in,
>>  fade out and bootmenu. The time to display the image can be also given (in
>>  seconds).
>>
>>  Idea and some parts of code are stollen from VirtualBox (GPLv2/CDDL).
>>
>>  [PATCH 1/3] Correct fw_cfg_add_callback()
>>  [PATCH 2/3] [BIOS] Add splash image support
>>  [PATCH 3/3] [QEMU] Add BIOS splash image
>>     
>
> On second thought, there is no Gtk/Qt GUI because that is supposed to
> be external to Qemu. By the same logic, why should there be any splash
> screen? The external GUI can probably show it as easily using the same
> Gtk/Qt/whatever.

You need it to be consistent on the SDL/VNC display.

Modern BIOSes have splash screens.  I don't see why our BIOS shouldn't 
have one too.

>  The control channel may still be needed.
>
> Alternatively the BIOS could load the image and fade parameters from a
> new ROM or from the configuration device and draw it to screen. This
> would need some PNG support to BIOS, or that the image stored in raw
> form.
>   

Yeah, having QEMU render to the VGA directly is a bit ugly.  It would be 
nicer if the BIOS actually rendered the image but I'm not sure I think 
we should reject the patch just because it doesn't.

Regards,

Anthony Liguori


> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   

Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Blue Swirl]

On 12/16/08, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Blue Swirl wrote:
>
> > On 12/16/08, Laurent Vivier <Laurent.Vivier@bull.net> wrote:
> >
> >
> > > This series of patches adds a nice BIOS startup splash screen.
> > >
> > >  It adds a "-splash" option allowing to specify the picture file name (a
> 640x480 (or less) and true color PNG) to display. You can enable/disable
> fade in,
> > >  fade out and bootmenu. The time to display the image can be also given
> (in
> > >  seconds).
> > >
> > >  Idea and some parts of code are stollen from VirtualBox (GPLv2/CDDL).
> > >
> > >  [PATCH 1/3] Correct fw_cfg_add_callback()
> > >  [PATCH 2/3] [BIOS] Add splash image support
> > >  [PATCH 3/3] [QEMU] Add BIOS splash image
> > >
> > >
> >
> > On second thought, there is no Gtk/Qt GUI because that is supposed to
> > be external to Qemu. By the same logic, why should there be any splash
> > screen? The external GUI can probably show it as easily using the same
> > Gtk/Qt/whatever.
> >
>
>  You need it to be consistent on the SDL/VNC display.

Oh, I didn't consider the VNC case. Then it may be difficult for the
GUI to manage the boot screen.

>  Modern BIOSes have splash screens.  I don't see why our BIOS shouldn't have
> one too.
>
> >  The control channel may still be needed.
> >
> > Alternatively the BIOS could load the image and fade parameters from a
> > new ROM or from the configuration device and draw it to screen. This
> > would need some PNG support to BIOS, or that the image stored in raw
> > form.
> >
> >
>
>  Yeah, having QEMU render to the VGA directly is a bit ugly.  It would be
> nicer if the BIOS actually rendered the image but I'm not sure I think we
> should reject the patch just because it doesn't.

Actually this way the image can be in full color even if the emulated
device was an EGA in text mode.

Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Laurent Vivier]

Le mardi 16 décembre 2008 à 22:46 +0200, Blue Swirl a écrit :
> On 12/16/08, Anthony Liguori <anthony@codemonkey.ws> wrote:
> > Blue Swirl wrote:

> > >  The control channel may still be needed.
> > >
> > > Alternatively the BIOS could load the image and fade parameters from a
> > > new ROM or from the configuration device and draw it to screen. This
> > > would need some PNG support to BIOS, or that the image stored in raw
> > > form.
> > >
> > >
> >
> >  Yeah, having QEMU render to the VGA directly is a bit ugly.  It would be
> > nicer if the BIOS actually rendered the image but I'm not sure I think we
> > should reject the patch just because it doesn't.
> 
> Actually this way the image can be in full color even if the emulated
> device was an EGA in text mode.

And you can provide the image name on the command line, and complexity
is in Qemu, not in BIOS.

But in fact, my first idea was to read the image data from the
configuration device (which is always possible with LOGO_CMD_OFFSET),
but when I saw how it has been done in VirtualBox, I though it was a
good idea.

But I agree, it's ugly.

Regards,
Laurent
-- 
------------------ Laurent.Vivier@bull.net  ------------------
"Tout ce qui est impossible reste à accomplir"    Jules Verne
"Things are only impossible until they're not" Jean-Luc Picard

Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Carl-Daniel Hailfinger]

On 16.12.2008 22:51, Laurent Vivier wrote:
> Le mardi 16 décembre 2008 à 22:46 +0200, Blue Swirl a écrit :
>   
>> On 12/16/08, Anthony Liguori <anthony@codemonkey.ws> wrote:
>>     
>>> Blue Swirl wrote:
>>>       
>
>   
>>>>  The control channel may still be needed.
>>>>
>>>> Alternatively the BIOS could load the image and fade parameters from a
>>>> new ROM or from the configuration device and draw it to screen. This
>>>> would need some PNG support to BIOS, or that the image stored in raw
>>>> form.
>>>>
>>>>
>>>>         
>>>  Yeah, having QEMU render to the VGA directly is a bit ugly.  It would be
>>> nicer if the BIOS actually rendered the image but I'm not sure I think we
>>> should reject the patch just because it doesn't.
>>>       
>> Actually this way the image can be in full color even if the emulated
>> device was an EGA in text mode.
>>     
>
> And you can provide the image name on the command line, and complexity
> is in Qemu, not in BIOS.
>   

If one of the goals of QEMU is to be somewhat similar to hardware, this
should be done in the BIOS.

What happens if the BIOS provides a splash screen? Will it override the
QEMU splash screen?

> But in fact, my first idea was to read the image data from the
> configuration device (which is always possible with LOGO_CMD_OFFSET),
> but when I saw how it has been done in VirtualBox, I though it was a
> good idea.
>   

Modern x86 BIOSes read the splash screen from the BIOS ROM and the
settings from NVRAM (sometimes the BIOS ROM is used for that as well by
reflashing a sector of the ROM on every boot).

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Laurent Vivier]

Le mercredi 17 décembre 2008 à 01:10 +0100, Carl-Daniel Hailfinger a
écrit :
> On 16.12.2008 22:51, Laurent Vivier wrote:
> > Le mardi 16 décembre 2008 à 22:46 +0200, Blue Swirl a écrit :
> >   
> >> On 12/16/08, Anthony Liguori <anthony@codemonkey.ws> wrote:
> >>     
> >>> Blue Swirl wrote:
> >>>       
> >
> >   
> >>>>  The control channel may still be needed.
> >>>>
> >>>> Alternatively the BIOS could load the image and fade parameters from a
> >>>> new ROM or from the configuration device and draw it to screen. This
> >>>> would need some PNG support to BIOS, or that the image stored in raw
> >>>> form.
> >>>>
> >>>>
> >>>>         
> >>>  Yeah, having QEMU render to the VGA directly is a bit ugly.  It would be
> >>> nicer if the BIOS actually rendered the image but I'm not sure I think we
> >>> should reject the patch just because it doesn't.
> >>>       
> >> Actually this way the image can be in full color even if the emulated
> >> device was an EGA in text mode.
> >>     
> >
> > And you can provide the image name on the command line, and complexity
> > is in Qemu, not in BIOS.
> >   
> 
> If one of the goals of QEMU is to be somewhat similar to hardware, this
> should be done in the BIOS.

A lot of things in Qemu are already not similar to hardware: virtio,
firmware configuration device, instruction timing...

> What happens if the BIOS provides a splash screen? Will it override the
> QEMU splash screen?

Yes. The BIOS asks Qemu to display the image... or not.

> > But in fact, my first idea was to read the image data from the
> > configuration device (which is always possible with LOGO_CMD_OFFSET),
> > but when I saw how it has been done in VirtualBox, I though it was a
> > good idea.
> >   
> 
> Modern x86 BIOSes read the splash screen from the BIOS ROM and the
> settings from NVRAM (sometimes the BIOS ROM is used for that as well by
> reflashing a sector of the ROM on every boot).

A BIOS, by definition, is not modern... ;-)
(Openfirmware is...)

Laurent
-- 
------------------ Laurent.Vivier@bull.net  ------------------
"Tout ce qui est impossible reste à accomplir"    Jules Verne
"Things are only impossible until they're not" Jean-Luc Picard

Re: [Bochs-developers] [Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Carl-Daniel Hailfinger]

On 17.12.2008 14:09, Laurent Vivier wrote:
> Le mercredi 17 décembre 2008 à 01:10 +0100, Carl-Daniel Hailfinger a
> écrit :
>   
>> On 16.12.2008 22:51, Laurent Vivier wrote:
>>     
>>> Le mardi 16 décembre 2008 à 22:46 +0200, Blue Swirl a écrit :
>>>   
>>>       
>>>> On 12/16/08, Anthony Liguori <anthony@codemonkey.ws> wrote:
>>>>     
>>>>         
>>>>> Blue Swirl wrote:
>>>>>       
>>>>>           
>>>   
>>>       
>>>>>>  The control channel may still be needed.
>>>>>>
>>>>>> Alternatively the BIOS could load the image and fade parameters from a
>>>>>> new ROM or from the configuration device and draw it to screen. This
>>>>>> would need some PNG support to BIOS, or that the image stored in raw
>>>>>> form.
>>>>>>
>>>>>>
>>>>>>         
>>>>>>             
>>>>>  Yeah, having QEMU render to the VGA directly is a bit ugly.  It would be
>>>>> nicer if the BIOS actually rendered the image but I'm not sure I think we
>>>>> should reject the patch just because it doesn't.
>>>>>       
>>>>>           
>>>> Actually this way the image can be in full color even if the emulated
>>>> device was an EGA in text mode.
>>>>     
>>>>         
>>> And you can provide the image name on the command line, and complexity
>>> is in Qemu, not in BIOS.
>>>   
>>>       
>> If one of the goals of QEMU is to be somewhat similar to hardware, this
>> should be done in the BIOS.
>>     
>
> A lot of things in Qemu are already not similar to hardware: virtio,
> firmware configuration device, instruction timing...
>
>   
>> What happens if the BIOS provides a splash screen? Will it override the
>> QEMU splash screen?
>>     
>
> Yes. The BIOS asks Qemu to display the image... or not.
>   

What happens if you run a native BIOS/EFI/whatever for the hardware
emulated in QEMU? Some people try to do exactly that.


>>> But in fact, my first idea was to read the image data from the
>>> configuration device (which is always possible with LOGO_CMD_OFFSET),
>>> but when I saw how it has been done in VirtualBox, I though it was a
>>> good idea.
>>>   
>>>       
>> Modern x86 BIOSes read the splash screen from the BIOS ROM and the
>> settings from NVRAM (sometimes the BIOS ROM is used for that as well by
>> reflashing a sector of the ROM on every boot).
>>     
>
> A BIOS, by definition, is not modern... ;-)
>   

Agreed.


> (Openfirmware is...)
>   

Even EFI is more modern than OpenFirmware. However, the most important
question here is how you quantify modernness ;-)

Speaking as a coreboot (really modern x86 firmware) developer, I'd like
to keep the number of workarounds for QEMU hardware quirks to a minimum.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

Re: [Bochs-developers] [Qemu-devel] [PATCH 0/3] Add BIOS splashimage support

[Sebastian Herbszt]

Carl-Daniel Hailfinger wrote:
> On 16.12.2008 22:51, Laurent Vivier wrote:
>> But in fact, my first idea was to read the image data from the
>> configuration device (which is always possible with LOGO_CMD_OFFSET),
>> but when I saw how it has been done in VirtualBox, I though it was a
>> good idea.

Vbox used MMIO and port I/O before moving the splash support to the VGA device.

> Modern x86 BIOSes read the splash screen from the BIOS ROM and the
> settings from NVRAM (sometimes the BIOS ROM is used for that as well by
> reflashing a sector of the ROM on every boot).

I think Vbox used run-length encoding for the innotek logo bitmap. Its size was
about 10 KB. If this could be used for Bochs we could put the logo into rombios32.bin
and load it from the 0xe000 segment. This should be comparable to other BIOSes.

- Sebastian

Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Daniel P. Berrange]

On Tue, Dec 16, 2008 at 02:28:29PM -0600, Anthony Liguori wrote:
> Blue Swirl wrote:
> >On 12/16/08, Laurent Vivier <Laurent.Vivier@bull.net> wrote:
> >  
> >>This series of patches adds a nice BIOS startup splash screen.
> >>
> >> It adds a "-splash" option allowing to specify the picture file name (a 
> >> 640x480 (or less) and true color PNG) to display. You can enable/disable 
> >> fade in,
> >> fade out and bootmenu. The time to display the image can be also given 
> >> (in
> >> seconds).
> >>
> >> Idea and some parts of code are stollen from VirtualBox (GPLv2/CDDL).
> >>
> >> [PATCH 1/3] Correct fw_cfg_add_callback()
> >> [PATCH 2/3] [BIOS] Add splash image support
> >> [PATCH 3/3] [QEMU] Add BIOS splash image
> >>    
> >
> >On second thought, there is no Gtk/Qt GUI because that is supposed to
> >be external to Qemu. By the same logic, why should there be any splash
> >screen? The external GUI can probably show it as easily using the same
> >Gtk/Qt/whatever.
> 
> You need it to be consistent on the SDL/VNC display.
> 
> Modern BIOSes have splash screens.  I don't see why our BIOS shouldn't 
> have one too.

Crap PC BIOSes have splash screens because they're horribly slow
and otherwise printing lots of irrelevant scary junk at users. The 
best BIOS 'splash' screen is one which never appears unless there 
is a boot failure, and gets control to the OS as quickly as possible.
IMHO a better goal is reducing the time until the OS / bootloader is
able to take over all management of the display.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Paul Brook]

> > Modern BIOSes have splash screens.  I don't see why our BIOS shouldn't
> > have one too.
>
> Crap PC BIOSes have splash screens because they're horribly slow
> and otherwise printing lots of irrelevant scary junk at users. The
> best BIOS 'splash' screen is one which never appears unless there
> is a boot failure, and gets control to the OS as quickly as possible.
> IMHO a better goal is reducing the time until the OS / bootloader is
> able to take over all management of the display.

I agree. The qemu bios init process takes almost no time.

The only reason it takes a noticeable amount of time is that we have a 
deliberate delay in there to allow the user to access the boot menu.
I'm not convinced this menu is actually very useful in practice, It's 
something that should probably be delegated to your management utility and/or 
be optional.

Paul

Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Jan Kiszka]

Paul Brook wrote:
>>> Modern BIOSes have splash screens.  I don't see why our BIOS shouldn't
>>> have one too.
>> Crap PC BIOSes have splash screens because they're horribly slow
>> and otherwise printing lots of irrelevant scary junk at users. The
>> best BIOS 'splash' screen is one which never appears unless there
>> is a boot failure, and gets control to the OS as quickly as possible.
>> IMHO a better goal is reducing the time until the OS / bootloader is
>> able to take over all management of the display.
> 
> I agree. The qemu bios init process takes almost no time.
> 
> The only reason it takes a noticeable amount of time is that we have a 
> deliberate delay in there to allow the user to access the boot menu.
> I'm not convinced this menu is actually very useful in practice, It's 
> something that should probably be delegated to your management utility and/or 
> be optional.

Yes, please. I hate this artificial delay, specifically as I have to do
a lot of short boot tests where this contributes noticeably to their
execution time. But, as usual, it didn't hurt enough to make me hack a
patch yet. I'm willing to do this if we can agree on how it should be done.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 26
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Gleb Natapov]

On Wed, Dec 17, 2008 at 02:45:38PM +0100, Jan Kiszka wrote:
> Paul Brook wrote:
> >>> Modern BIOSes have splash screens.  I don't see why our BIOS shouldn't
> >>> have one too.
> >> Crap PC BIOSes have splash screens because they're horribly slow
> >> and otherwise printing lots of irrelevant scary junk at users. The
> >> best BIOS 'splash' screen is one which never appears unless there
> >> is a boot failure, and gets control to the OS as quickly as possible.
> >> IMHO a better goal is reducing the time until the OS / bootloader is
> >> able to take over all management of the display.
> > 
> > I agree. The qemu bios init process takes almost no time.
> > 
> > The only reason it takes a noticeable amount of time is that we have a 
> > deliberate delay in there to allow the user to access the boot menu.
> > I'm not convinced this menu is actually very useful in practice, It's 
> > something that should probably be delegated to your management utility and/or 
> > be optional.
> 
> Yes, please. I hate this artificial delay, specifically as I have to do
> a lot of short boot tests where this contributes noticeably to their
> execution time. But, as usual, it didn't hurt enough to make me hack a
> patch yet. I'm willing to do this if we can agree on how it should be done.
> 
Add "-bootmenu" option to qmeu and pass it to BIOS via fw confing interface?

--
			Gleb.

Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Jan Kiszka]

Gleb Natapov wrote:
> On Wed, Dec 17, 2008 at 02:45:38PM +0100, Jan Kiszka wrote:
>> Paul Brook wrote:
>>>>> Modern BIOSes have splash screens.  I don't see why our BIOS shouldn't
>>>>> have one too.
>>>> Crap PC BIOSes have splash screens because they're horribly slow
>>>> and otherwise printing lots of irrelevant scary junk at users. The
>>>> best BIOS 'splash' screen is one which never appears unless there
>>>> is a boot failure, and gets control to the OS as quickly as possible.
>>>> IMHO a better goal is reducing the time until the OS / bootloader is
>>>> able to take over all management of the display.
>>> I agree. The qemu bios init process takes almost no time.
>>>
>>> The only reason it takes a noticeable amount of time is that we have a 
>>> deliberate delay in there to allow the user to access the boot menu.
>>> I'm not convinced this menu is actually very useful in practice, It's 
>>> something that should probably be delegated to your management utility and/or 
>>> be optional.
>> Yes, please. I hate this artificial delay, specifically as I have to do
>> a lot of short boot tests where this contributes noticeably to their
>> execution time. But, as usual, it didn't hurt enough to make me hack a
>> patch yet. I'm willing to do this if we can agree on how it should be done.
>>
> Add "-bootmenu" option to qmeu and pass it to BIOS via fw confing interface?

Sounds good to me. Qemu bits are already done, but now I'm stuck on
setting up the bochs bios environment. Probably I'm blind, but I can't
find a proper reference, telling me against which version the qemu bios
patch is. Currently, it does not apply against bochs CVS head.

BTW, why does qemu not carry all bochs bios source? For reference, but
also to fully comply with the LGPL (pointing to the original source is
not sufficient when delivering binaries - like e.g. bios.bin...).

Jan

-- 
Siemens AG, Corporate Technology, CT SE 26
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Jan Kiszka]

Jan Kiszka wrote:
> ...
> BTW, why does qemu not carry all bochs bios source? For reference, but
> also to fully comply with the LGPL (pointing to the original source is
> not sufficient when delivering binaries - like e.g. bios.bin...).

OK, reading the diff more carefully told me that it's release 2.3.7.
Nevertheless, it remains "unclean" /wrt LGPL terms. And it is unhandy
for development.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 26
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Paul Brook]

> BTW, why does qemu not carry all bochs bios source? For reference, but
> also to fully comply with the LGPL (pointing to the original source is
> not sufficient when delivering binaries - like e.g. bios.bin...).

If this is really an issue, then I strongly suggest we fix it by moving the 
bios into its own project, and have everyone fetch it from there.

Paul

Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Jan Kiszka]

Paul Brook wrote:
>> BTW, why does qemu not carry all bochs bios source? For reference, but
>> also to fully comply with the LGPL (pointing to the original source is
>> not sufficient when delivering binaries - like e.g. bios.bin...).
> 
> If this is really an issue, then I strongly suggest we fix it by moving the 
> bios into its own project, and have everyone fetch it from there.

Qemu distributes binaries that have been generated from LGPLed sources
(this is at least the case for bochs, one would have to check the
situation for the other firmware images), so it has to provide the
corresponding source code according to the license terms. But if any
bochs copyright holder will ever sue a qemu maintainer on this is a
different question.

Nevertheless, we should keep in mind that anyone else who redistributes
qemu has to comply to this terms as well, thus currently has to patch
the "license bug" out of tree. At least from this perspective, it would
be nice to fix it - however this may happen in details (wasn't there
also some idea to switch to SeaBIOS due to build simplifications, or was
this only on the kvm list?).

Jan

-- 
Siemens AG, Corporate Technology, CT SE 26
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Anthony Liguori]

Jan Kiszka wrote:
> Paul Brook wrote:
>   
>>> BTW, why does qemu not carry all bochs bios source? For reference, but
>>> also to fully comply with the LGPL (pointing to the original source is
>>> not sufficient when delivering binaries - like e.g. bios.bin...).
>>>       
>> If this is really an issue, then I strongly suggest we fix it by moving the 
>> bios into its own project, and have everyone fetch it from there.
>>     
>
> Qemu distributes binaries that have been generated from LGPLed sources
> (this is at least the case for bochs, one would have to check the
> situation for the other firmware images), so it has to provide the
> corresponding source code according to the license terms.

You are not qualified to make the statement "has to".  This is a legal 
issue and depends on how the GPL is interpreted.  The FSF provides a set 
of guidelines and so does Debian.  Debian's guidelines are more 
extreme.  If you look at the FSF FAQ on this subject, the main issue is 
ensuring that the source code is always available.

Since Bochs is on SF, as long as we ensure that the version we base on 
is always available, you could certainly conclude that's enough.

But please, this is not an issue worth even discussing here.  It is only 
relevant for people distributing QEMU and it's up to those people to 
consult with their legal teams to determine whether they need to do 
anything special.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Jan Kiszka]

Anthony Liguori wrote:
> Jan Kiszka wrote:
>> Paul Brook wrote:
>>  
>>>> BTW, why does qemu not carry all bochs bios source? For reference, but
>>>> also to fully comply with the LGPL (pointing to the original source is
>>>> not sufficient when delivering binaries - like e.g. bios.bin...).
>>>>       
>>> If this is really an issue, then I strongly suggest we fix it by
>>> moving the bios into its own project, and have everyone fetch it from
>>> there.
>>>     
>>
>> Qemu distributes binaries that have been generated from LGPLed sources
>> (this is at least the case for bochs, one would have to check the
>> situation for the other firmware images), so it has to provide the
>> corresponding source code according to the license terms.
> 
> You are not qualified to make the statement "has to".  This is a legal
> issue and depends on how the GPL is interpreted.  The FSF provides a set
> of guidelines and so does Debian.  Debian's guidelines are more
> extreme.  If you look at the FSF FAQ on this subject, the main issue is
> ensuring that the source code is always available.
> 
> Since Bochs is on SF, as long as we ensure that the version we base on
> is always available, you could certainly conclude that's enough.

Well, I guess we are both not qualified to finally judge over this. But
this is not my point.

> 
> But please, this is not an issue worth even discussing here.  It is only
> relevant for people distributing QEMU and it's up to those people to
> consult with their legal teams to determine whether they need to do
> anything special.

And why complicating things downstream when it can be fixed upstream?
Because it is only a legal issue? As a redistributor of OSS who cares a
lot about such issues, you have a lot of "fun" getting things right when
upstream forgot it.

But as it looks like, there is a consensus on changing the situation
anyway. And up to now, no animal should have been harmed, too.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 26
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Anthony Liguori]

Jan Kiszka wrote:
> Anthony Liguori wrote:
>   
>> But please, this is not an issue worth even discussing here.  It is only
>> relevant for people distributing QEMU and it's up to those people to
>> consult with their legal teams to determine whether they need to do
>> anything special.
>>     
>
> And why complicating things downstream when it can be fixed upstream?
> Because it is only a legal issue? As a redistributor of OSS who cares a
> lot about such issues, you have a lot of "fun" getting things right when
> upstream forgot it.
>   

I don't want to mirror Bochs source code in QEMU.  That's a lot of 
commit noise, and broken version control history.  I'm setting up a git 
repo of Bochs that contains the source we use.  I'm doing this primarily 
to make it more sane for us to maintain patches against Bochs and to 
update the bios.bin without waiting for releases.  This is also what the 
FSF FAQ recommends.

It doesn't help "downstream" but it's what is most useful for us.

Regards,

Anthony Liguori

> But as it looks like, there is a consensus on changing the situation
> anyway. And up to now, no animal should have been harmed, too.
>
> Jan
>
>   

Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Andreas Färber]

Am 17.12.2008 um 17:35 schrieb Jan Kiszka:

> Paul Brook wrote:
>>> BTW, why does qemu not carry all bochs bios source? For reference,  
>>> but
>>> also to fully comply with the LGPL (pointing to the original  
>>> source is
>>> not sufficient when delivering binaries - like e.g. bios.bin...).
>>
>> If this is really an issue, then I strongly suggest we fix it by  
>> moving the
>> bios into its own project, and have everyone fetch it from there.
>
> Qemu distributes binaries that have been generated from LGPLed sources
> (this is at least the case for bochs, one would have to check the
> situation for the other firmware images), so it has to provide the
> corresponding source code according to the license terms.

The GPL v2 allows several methods for distributing source code.  
Providing them alongside binaries is one option (3.a), providing it on  
request on some medium is another (3.b).
http://www.opensource.org/licenses/gpl-2.0.php

GPLv3 further allows to link to external source locations (6.d).
http://www.opensource.org/licenses/gpl-3.0.html

IANAL.

Andreas

Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Anthony Liguori]

Paul Brook wrote:
>> BTW, why does qemu not carry all bochs bios source? For reference, but
>> also to fully comply with the LGPL (pointing to the original source is
>> not sufficient when delivering binaries - like e.g. bios.bin...).
>>     
>
> If this is really an issue, then I strongly suggest we fix it by moving the 
> bios into its own project, and have everyone fetch it from there.
>   

This would be the best solution.  How do the bochs folks feel about this?

Regards,

Anthony Liguori

> Paul
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   

Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Sebastian Herbszt]

Anthony Liguori wrote:
> Paul Brook wrote:
>>> BTW, why does qemu not carry all bochs bios source? For reference, but
>>> also to fully comply with the LGPL (pointing to the original source is
>>> not sufficient when delivering binaries - like e.g. bios.bin...).
>>>     
>>
>> If this is really an issue, then I strongly suggest we fix it by moving the 
>> bios into its own project, and have everyone fetch it from there.
>>   
> 
> This would be the best solution.  How do the bochs folks feel about this?

There is the pcbios project available at http://savannah.nongnu.org/projects/pcbios
It seems fairly out of date tho. Volker, you happen to know the status?

- Sebastian

Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Volker Ruppert]

Hi all!

> > This would be the best solution.  How do the bochs folks feel about this?
>
> There is the pcbios project available at
> http://savannah.nongnu.org/projects/pcbios It seems fairly out of date tho.
> Volker, you happen to know the status?

The PCBIOS project was based on the Bochs BIOS and started by Alex Beregszaszi 
in summer 2005. He was the project admin and I was a normal project member. 
We wanted to continue the Bochs BIOS development as a separate project. A few 
weeks later I no longer had CVS write access. I had a look at the project 
page on Savannah and found 0 members! I don't know what happend there. Alex 
had no time to take care of it and some time later he disappeared. So I 
continued the Bochs BIOS development inside of the Bochs project as usual.

--
Thanks

Volker

Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[H. Peter Anvin]

Volker Ruppert wrote:
> Hi all!
> 
>>> This would be the best solution.  How do the bochs folks feel about this?
>> There is the pcbios project available at
>> http://savannah.nongnu.org/projects/pcbios It seems fairly out of date tho.
>> Volker, you happen to know the status?
> 
> The PCBIOS project was based on the Bochs BIOS and started by Alex Beregszaszi 
> in summer 2005. He was the project admin and I was a normal project member. 
> We wanted to continue the Bochs BIOS development as a separate project. A few 
> weeks later I no longer had CVS write access. I had a look at the project 
> page on Savannah and found 0 members! I don't know what happend there. Alex 
> had no time to take care of it and some time later he disappeared. So I 
> continued the Bochs BIOS development inside of the Bochs project as usual.
> 

So I guess it comes down to: should we re-try to set up a separate BIOS
project?

This is a fairly big deal... there are by now a number of consumers of
this BIOS beyond Bochs: at least Qemu, KVM, and Coreboot all use it.  As
such, it would be highly advantageous if the core project was separate
and maintained in a DSCM (e.g. git or hg) so that a consumer who needs
to maintain their own tweaks can do so in a sane manner.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Carl-Daniel Hailfinger]

On 17.12.2008 14:55, Gleb Natapov wrote:
> On Wed, Dec 17, 2008 at 02:45:38PM +0100, Jan Kiszka wrote:
>   
>> Paul Brook wrote:
>>     
>>>>> Modern BIOSes have splash screens.  I don't see why our BIOS shouldn't
>>>>> have one too.
>>>>>           
>>>> Crap PC BIOSes have splash screens because they're horribly slow
>>>> and otherwise printing lots of irrelevant scary junk at users. The
>>>> best BIOS 'splash' screen is one which never appears unless there
>>>> is a boot failure, and gets control to the OS as quickly as possible.
>>>> IMHO a better goal is reducing the time until the OS / bootloader is
>>>> able to take over all management of the display.
>>>>         
>>> I agree. The qemu bios init process takes almost no time.
>>>
>>> The only reason it takes a noticeable amount of time is that we have a 
>>> deliberate delay in there to allow the user to access the boot menu.
>>> I'm not convinced this menu is actually very useful in practice, It's 
>>> something that should probably be delegated to your management utility and/or 
>>> be optional.
>>>       
>> Yes, please. I hate this artificial delay, specifically as I have to do
>> a lot of short boot tests where this contributes noticeably to their
>> execution time. But, as usual, it didn't hurt enough to make me hack a
>> patch yet. I'm willing to do this if we can agree on how it should be done.
>>
>>     
> Add "-bootmenu" option to qmeu and pass it to BIOS via fw confing interface?
>   

If you pick NVRAM (RTC battery data storage) for this config item,
traditional BIOS and coreboot and EFI and OFW can pick it up without
problems. Plus, it is the traditional way to store splash screen settings.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Gerd Hoffmann]

Jan Kiszka wrote:
> Yes, please. I hate this artificial delay, specifically as I have to do
> a lot of short boot tests where this contributes noticeably to their
> execution time. But, as usual, it didn't hurt enough to make me hack a
> patch yet. I'm willing to do this if we can agree on how it should be done.

Show the boot menu only on case no "-boot whatever" cmd line option is
present?

cheers,
  Gerd

Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Jan Kiszka]

Gerd Hoffmann wrote:
> Jan Kiszka wrote:
>> Yes, please. I hate this artificial delay, specifically as I have to do
>> a lot of short boot tests where this contributes noticeably to their
>> execution time. But, as usual, it didn't hurt enough to make me hack a
>> patch yet. I'm willing to do this if we can agree on how it should be done.
> 
> Show the boot menu only on case no "-boot whatever" cmd line option is
> present?

I would say only when there is -bootmenu as Gleb suggested. I'm half
done with this approach already.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 26
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Kevin Wolf]

Jan Kiszka schrieb:
> Gerd Hoffmann wrote:
>> Jan Kiszka wrote:
>>> Yes, please. I hate this artificial delay, specifically as I have to do
>>> a lot of short boot tests where this contributes noticeably to their
>>> execution time. But, as usual, it didn't hurt enough to make me hack a
>>> patch yet. I'm willing to do this if we can agree on how it should be done.
>> Show the boot menu only on case no "-boot whatever" cmd line option is
>> present?
> 
> I would say only when there is -bootmenu as Gleb suggested. I'm half
> done with this approach already.

I like Gerd's approach better as it doesn't introduce yet another
command line parameter. It makes sense to me that you don't want a menu
if you specify -boot.

Kevin

Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Daniel P. Berrange]

On Wed, Dec 17, 2008 at 04:04:57PM +0100, Kevin Wolf wrote:
> Jan Kiszka schrieb:
> > Gerd Hoffmann wrote:
> >> Jan Kiszka wrote:
> >>> Yes, please. I hate this artificial delay, specifically as I have to do
> >>> a lot of short boot tests where this contributes noticeably to their
> >>> execution time. But, as usual, it didn't hurt enough to make me hack a
> >>> patch yet. I'm willing to do this if we can agree on how it should be done.
> >> Show the boot menu only on case no "-boot whatever" cmd line option is
> >> present?
> > 
> > I would say only when there is -bootmenu as Gleb suggested. I'm half
> > done with this approach already.
> 
> I like Gerd's approach better as it doesn't introduce yet another
> command line parameter. It makes sense to me that you don't want a menu
> if you specify -boot.

Actually no it doesn't. The reason the original author wrote this 
boot menu patch was explicitly so that if you had used a '-boot d'
arg, you could do a one-time override from the BIOS screen.

One other alternative to added a brand new arg is to just allow an extra
meta-character in -boot arg to indicate that it should prompt or not

  -boot d    (use cdrom)

vs

  -boot d+   (default cdrom, prompt to allow override)

but perhaps that's a bit obtuse

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

[Qemu-devel] Re: [PATCH 0/3] Add BIOS splash image support

[Jan Kiszka]

Daniel P. Berrange wrote:
> On Wed, Dec 17, 2008 at 04:04:57PM +0100, Kevin Wolf wrote:
>> Jan Kiszka schrieb:
>>> Gerd Hoffmann wrote:
>>>> Jan Kiszka wrote:
>>>>> Yes, please. I hate this artificial delay, specifically as I have to do
>>>>> a lot of short boot tests where this contributes noticeably to their
>>>>> execution time. But, as usual, it didn't hurt enough to make me hack a
>>>>> patch yet. I'm willing to do this if we can agree on how it should be done.
>>>> Show the boot menu only on case no "-boot whatever" cmd line option is
>>>> present?
>>> I would say only when there is -bootmenu as Gleb suggested. I'm half
>>> done with this approach already.
>> I like Gerd's approach better as it doesn't introduce yet another
>> command line parameter. It makes sense to me that you don't want a menu
>> if you specify -boot.
> 
> Actually no it doesn't. The reason the original author wrote this 
> boot menu patch was explicitly so that if you had used a '-boot d'
> arg, you could do a one-time override from the BIOS screen.
> 
> One other alternative to added a brand new arg is to just allow an extra
> meta-character in -boot arg to indicate that it should prompt or not
> 
>   -boot d    (use cdrom)
> 
> vs
> 
>   -boot d+   (default cdrom, prompt to allow override)
> 
> but perhaps that's a bit obtuse
> 

-boot d,ask would make more sense to me (as it is more verbose).

BTW, a few interruptions later I meanwhile had the chance to realize
that QEMU's bios.diff does not yet carry and fw_cfg bits, right? Does
its binary include them? Or is this currently kvm-only stuff?

<confused> Jan

Re: [Qemu-devel] Re: [PATCH 0/3] Add BIOS splash image support

[Gildas]

>> One other alternative to added a brand new arg is to just allow an extra
>> meta-character in -boot arg to indicate that it should prompt or not
>>
>>   -boot d    (use cdrom)
>>
>> vs
>>
>>   -boot d+   (default cdrom, prompt to allow override)
>>
>> but perhaps that's a bit obtuse
>>
>
> -boot d,ask would make more sense to me (as it is more verbose).

I think "ask" or even "m" for menu is easier to understand than a "+"

With this option, there would be 4 different cases at boot time:

no "-boot" option: show boot menu
-boot ask or -boot m: show boot menu
-boot d: use cdrom, no boot menu
-boot d,ask or -boot m: default cdrom, prompt to allow override

I would also like to remind you the boot_set option in the monitor
which allow one to change the values from the -boot parameter at run
time.

Another alternative might just be to lower the wait time to 1 or 2s...

Gildas

Re: [Qemu-devel] Re: [PATCH 0/3] Add BIOS splash image support

[M. Warner Losh]

In message: <b2ace7f20812170906p5140b3b6lc77ba0821e48dd68@mail.gmail.com>
            Gildas <gildas.ml@gmail.com> writes:
: >> One other alternative to added a brand new arg is to just allow an extra
: >> meta-character in -boot arg to indicate that it should prompt or not
: >>
: >>   -boot d    (use cdrom)
: >>
: >> vs
: >>
: >>   -boot d+   (default cdrom, prompt to allow override)
: >>
: >> but perhaps that's a bit obtuse
: >>
: >
: > -boot d,ask would make more sense to me (as it is more verbose).
: 
: I think "ask" or even "m" for menu is easier to understand than a "+"
: 
: With this option, there would be 4 different cases at boot time:
: 
: no "-boot" option: show boot menu
: -boot ask or -boot m: show boot menu
: -boot d: use cdrom, no boot menu
: -boot d,ask or -boot m: default cdrom, prompt to allow override
: 
: I would also like to remind you the boot_set option in the monitor
: which allow one to change the values from the -boot parameter at run
: time.
: 
: Another alternative might just be to lower the wait time to 1 or 2s...

I'd suggest that 'menu' is better than 'm' here, unless there's some
reason we're constrained to a single drive letter.

Warner

Re: [Qemu-devel] Re: [PATCH 0/3] Add BIOS splash image support

[Gleb Natapov]

> 
> BTW, a few interruptions later I meanwhile had the chance to realize
> that QEMU's bios.diff does not yet carry and fw_cfg bits, right? Does
> its binary include them? Or is this currently kvm-only stuff?
> 
> <confused> Jan
> 
AFAIK Anthony merges latest version of the BIOS in qemu now. I hope it
will commit it soon.

--
			Gleb.

Re: [Qemu-devel] Re: [PATCH 0/3] Add BIOS splash image support

[Anthony Liguori]

Gleb Natapov wrote:
>> BTW, a few interruptions later I meanwhile had the chance to realize
>> that QEMU's bios.diff does not yet carry and fw_cfg bits, right? Does
>> its binary include them? Or is this currently kvm-only stuff?
>>
>> <confused> Jan
>>
>>     
> AFAIK Anthony merges latest version of the BIOS in qemu now. I hope it
> will commit it soon.
>   

I'm mirroring the Bochs CVS tree into git right now which I will then 
post to a repo on repo.or.cz.  This way, we can keep track of the 
changeset in that repo.  Otherwise, we have no way of keeping track of 
which revision we're based on without using a formal release.

Regards,

Anthony Liguori

> --
> 			Gleb.
>
>
>   

[Qemu-devel] Re: Re: [PATCH 0/3] Add BIOS splash image support

[Sebastian Herbszt]

Anthony Liguori wrote:
> Gleb Natapov wrote:
>>> BTW, a few interruptions later I meanwhile had the chance to realize
>>> that QEMU's bios.diff does not yet carry and fw_cfg bits, right? Does
>>> its binary include them? Or is this currently kvm-only stuff?
>>>
>>> <confused> Jan
>>>
>>>     
>> AFAIK Anthony merges latest version of the BIOS in qemu now. I hope it
>> will commit it soon.
>>   
> 
> I'm mirroring the Bochs CVS tree into git right now which I will then 
> post to a repo on repo.or.cz.  This way, we can keep track of the 
> changeset in that repo.  Otherwise, we have no way of keeping track of 
> which revision we're based on without using a formal release.

It is also available at http://git.kernel.org/?p=virt/bochs/bochs.git

- Sebastian

[Qemu-devel] Re: [PATCH 0/3] Add BIOS splash image support

[Anthony Liguori]

Sebastian Herbszt wrote:
> Anthony Liguori wrote:
>> Gleb Natapov wrote:
>>>> BTW, a few interruptions later I meanwhile had the chance to realize
>>>> that QEMU's bios.diff does not yet carry and fw_cfg bits, right? Does
>>>> its binary include them? Or is this currently kvm-only stuff?
>>>>
>>>> <confused> Jan
>>>>
>>>>     
>>> AFAIK Anthony merges latest version of the BIOS in qemu now. I hope it
>>> will commit it soon.
>>>   
>>
>> I'm mirroring the Bochs CVS tree into git right now which I will then 
>> post to a repo on repo.or.cz.  This way, we can keep track of the 
>> changeset in that repo.  Otherwise, we have no way of keeping track 
>> of which revision we're based on without using a formal release.
>
> It is also available at http://git.kernel.org/?p=virt/bochs/bochs.git

And just when I finally got things setup.

Thanks, I'll switch over to that.

Regards,

Anthony Liguori

> - Sebastian
>

Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Daniel P. Berrange]

On Wed, Dec 17, 2008 at 01:18:57PM +0000, Paul Brook wrote:
> > > Modern BIOSes have splash screens.  I don't see why our BIOS shouldn't
> > > have one too.
> >
> > Crap PC BIOSes have splash screens because they're horribly slow
> > and otherwise printing lots of irrelevant scary junk at users. The
> > best BIOS 'splash' screen is one which never appears unless there
> > is a boot failure, and gets control to the OS as quickly as possible.
> > IMHO a better goal is reducing the time until the OS / bootloader is
> > able to take over all management of the display.
> 
> I agree. The qemu bios init process takes almost no time.
> 
> The only reason it takes a noticeable amount of time is that we have a 
> deliberate delay in there to allow the user to access the boot menu.
> I'm not convinced this menu is actually very useful in practice, It's 
> something that should probably be delegated to your management utility and/or 
> be optional.

I agree - if you've not got an easy way to switch boot devices already,
then that's a bug in the management app being used. So a way to turn off
this BIOS boot menu would be benefical.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support

[Kevin O'Connor]

On Tue, Dec 16, 2008 at 10:06:54PM +0200, Blue Swirl wrote:
> On 12/16/08, Laurent Vivier <Laurent.Vivier@bull.net> wrote:
> > This series of patches adds a nice BIOS startup splash screen.
> >
> >  It adds a "-splash" option allowing to specify the picture file name (a 640x480 (or less) and true color PNG) to display. You can enable/disable fade in,
> >  fade out and bootmenu. The time to display the image can be also given (in
> >  seconds).
> >
> >  Idea and some parts of code are stollen from VirtualBox (GPLv2/CDDL).
> Alternatively the BIOS could load the image and fade parameters from a
> new ROM or from the configuration device and draw it to screen. This
> would need some PNG support to BIOS, or that the image stored in raw
> form.

I also think the BIOS should either fully handle the splash screen, or
bochs/qemu should fully handle it.  I don't think it makes sense to
put part of the code in the bios and part in the emulator.

-Kevin

[Qemu-devel] Re: [Bochs-developers] [PATCH 0/3] Add BIOS splash image support

[Sebastian Herbszt]

Laurent Vivier wrote:
> This series of patches adds a nice BIOS startup splash screen.
>
> It adds a "-splash" option allowing to specify the picture file name (a 640x480 (or less) and true color PNG) to 
> display. You can enable/disable fade in,
> fade out and bootmenu. The time to display the image can be also given (in
> seconds).
>
> Idea and some parts of code are stollen from VirtualBox (GPLv2/CDDL).

rombios.c is LGPL. Can we mix it with GPLv2/CDDL code without any downsides?

- Sebastian

[Qemu-devel] Re: [Bochs-developers] [PATCH 0/3] Add BIOS splash image support

[Laurent Vivier]

Le mercredi 17 décembre 2008 à 22:58 +0100, Sebastian Herbszt a écrit :
> Laurent Vivier wrote:
> > This series of patches adds a nice BIOS startup splash screen.
> >
> > It adds a "-splash" option allowing to specify the picture file name (a 640x480 (or less) and true color PNG) to 
> > display. You can enable/disable fade in,
> > fade out and bootmenu. The time to display the image can be also given (in
> > seconds).
> >
> > Idea and some parts of code are stollen from VirtualBox (GPLv2/CDDL).
> 
> rombios.c is LGPL. Can we mix it with GPLv2/CDDL code without any downsides?

Good question. But the GPLv2 code is not in rombios.c (but in logo.h,
logo.c) and moreover VirtualBox uses the same rombios.c with their GPLv2
logo.[ch]... perhaps we can ask Sun lawyers ;-) ?
I'm the author of all the code added to rombios.c to manage splash
screen and I agree to put this under LGPL. For the logo.[ch], I keep
only approximately 20% of original VirtualBox code (data structure, to
set vga mode, to clear screen and some name), if needed I can rewrite
this to put logo.[ch] under LGPL.

Regards,
Laurent
-- 
------------------ Laurent.Vivier@bull.net  ------------------
"Tout ce qui est impossible reste à accomplir"    Jules Verne
"Things are only impossible until they're not" Jean-Luc Picard