x86 Splash Screen WinCE 6 R3 RRS feed

  • Question

  • I'm struggling to reduce the amount of time that the LCD screen is blank during the boot sequence in order to provide "comfort" to the customer that the system is indeed powered on and booting correctly.

    I'm using Qseven Intel Atom processor boards running WinCE 6 R3.  I can use both the Intel EMGD driver and the VGA Flat driver.

    The various manufactures provide ways to embed a boot image into the BIOS and so this displays a short time after power on and then is removed when the BIOS Bootloader (built in Visual Studio) takes over and displays a splash screen while loading the NK.bin into RAM.  Up until the end of this I am happy.

    However at the end of the BIOS Bootloader the screen goes black and remains this way for quite some time until the main desktop image appears through explorer.  I have tried extensively to prevent the clearing of the framebuffer around the time of the jump to the start of NK.bin but have been unsucessful.  If I place some code in OEM Init I can write "garbage" to the screen or at least put a colour band on it which will persist until the main desktop appears.  However it would seem that I would need to recreate aspects of the display driver in OEMInit in order to display something here.

    It would be easier if I could somehow remove the video or framebuffer reset that is happening at the end of the BIOS Bootloader or in the very early stages of the NK.bin execution process as this would allow the splash screen to persist up until (or close to) the time the display driver loads and the desktop image is shown.

    Is this possible?  I'm using the Intel GOLD BSP (CE6 R3).

     Does anyone have any detailed experience with x86 systems and splashscreens? 

    Tuesday, August 14, 2012 2:16 AM

All replies

  • Not sure if this will help you, but what I usually do is:

    1. Reserve a memory area as frame buffer in eboot.bib and config.bib (same physical memory area)
    2. Initialize the display driver in the bootloader (in your case biosloader) and show splash image asap (usually a few ms after power is applied)
    3. Load CE kernel from flash and jump to it (don't touch the display registers!)
    4. DO NOT reinitialize the display (registers) in CE display driver (not necessary as it is all setup correctly already by the bootloader)
    5. Windows CE uses the same memory as framebuffer, so not a single flicker from splash screeen to desktop drawing

    If you have the source of the biosloader (you do, right?) and the source of the display driver then you should be able to do the same.

    Good luck,

    Michel Verhagen, eMVP
    Check out my blog:

    Microsoft Embedded Partner
    Consultancy, training and development services.

    Tuesday, August 14, 2012 2:39 AM
  • Hi Michel,

    Thanks for your reply.

    Just clarifying you noticed I'm using an x86 platform.  When you said "show splash image asap (usually a few ms after power is applied)".

    My platform shows the bios loader splash screen a few seconds after power on - not a few ms.  Showing something in the millisecond range isn't possible on a system with BIOS is it hence it sounds to me like you mixed it up with an ARM based system when indeed it is possible to show something extremely quickly after power on.

    There is a BIOS splash image that appears 7 seconds after power on.  The BIOS loader splash appears at around 15 seconds and the desktop at the 25 - 30 second mark.  I doubt I can do anything about the first 7 seconds but I am trying to have something showing between the BIOS loader and the windows desktop.

    Now what you say about not reinitilizing the frame buffer makes sense - except that it is being reinitilized sometime between the

    if (ImgAddr != 0)


    statement in the BIOS loader and OEMInit during the NK.bin startup.  Can you tell me how I can prevent this happening?

    The framebuffer is reserved in config.bib as:

    FRAMEBUF  800A0000  00020000  RESERVED

    In boot.bib the items are as follows:

    BLDR 00001000  00005000   RAMIMAGE    ; Size should be evenly divisible by 512b.
     BPB     00007C00  00000070   RESERVED    ; BIOS parameter block data and DPT.
     VESA    00008000  00001000   RESERVED    ; VESA work RAM.
    ; RAM     00009000  00001900   RAM
    ; SCACHE  0000A900  00000200   RESERVED    ; Sector cache.
    ; STACK 0000AB00  00001500   RESERVED    ; Stack base will be set to 0x7FFC to leave 0x8000 free.
     RAM     00009000  00002200   RAM
     SCACHE  0000B200  00000200   RESERVED    ; This is where the FAT sector chains are read.
     STACK 0000B400  00001500   RESERVED    ; The SP is set in Startup.asm.
     READBUF 0000C900  00003700   RESERVED    ; Data from disk is read into this buffer first.

    So it appears there is nothing that corresponds.  This would be the equivalent file to eboot.bib since I don't use Eboot?

    But the BIOS  provided framebuffer is the same as the FRAMEBUF reserved in CE so presumably that gets passed through OK.

    I don't have the source for the Intel EMGD driver but do for the VGA flat driver.

    Tuesday, August 14, 2012 3:32 AM
  • Showing something in the millisecond range isn't possible on a system with BIOS

    Why not? You could replace the entire BIOS with the BIOSLoader and have a splash screen up in ms after power up. Do you need the PC BIOS? Windows CE doesn't...

    It's all up to you really. Sounds to me like you are not in full control of the entire control path from power up to CE load, and thus you won't be able to do what you want until you are. Replace the BIOS with your own BIOSLoader, then initialize the screen first thing you do, show a splash screen, load CE and don't initialize or reset the display controller.

    I am indeed working mostly on ARM (and left the outdated x86 architecture behind years ago, phew!).

    Good luck,

    Michel Verhagen, eMVP
    Check out my blog:

    Microsoft Embedded Partner
    Consultancy, training and development services.

    Tuesday, August 14, 2012 3:48 AM
  • I suppose I'll have to go back to the drawing board to see what can be sped up at the start of the process too.  Currently the BIOS loader only gets actioned once the BIOS has finished doing its thing.  So if I can shave off that 7 seconds at the start that would be good too.  But I'm sure this won't be easy.

    I work on ARM too almost exclusively and are familiar with how to display splashscreens during the boot process that way.  But unfortunately in this project it is the client that has chosen the architecture.  :-(

    Tuesday, August 14, 2012 4:16 AM
  • You could always try to "educate the customer" :)

    Good luck,

    Michel Verhagen, eMVP
    Check out my blog:

    Microsoft Embedded Partner
    Consultancy, training and development services.

    Tuesday, August 14, 2012 4:20 AM
  • In the meantime -

    If there's anyone who has knowledge about persisting the framebuffer all the way through bios loader until the display driver loads I'd appreciate hearing how this is achieved.  What things can cause it to be cleared?


    Tuesday, August 14, 2012 11:02 AM
  • Take out the code that is marked with a comment:  // Initialize requested video mode

    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG

    Eurotech Inc.

    Tuesday, August 14, 2012 12:53 PM
  • Hi Bruce, Michel

    I had already tried your suggestion and was unsuccessful.  However I have now got to the root of my problem.  The BIOS Loader changes were not succesful due to the lack of the debug.exe application in Windows 7.  This is due to no depreciation of the application since there's no 16bit support in Win7 presumably.  There is a line "debug bldr < fixjmp.scr" that was failing with only a warning and for some reason the old bldr file was not being overwritten.

    I manually ran the debug step on a Windows XP machine and now the bldr (with the final Initialize requested video mode as suggested above commented out) works correctly and leaves the video framebuffer alone.

    Thanks for the help and suggestions.  Always good to bounce ideas off other people.

    Wednesday, August 15, 2012 8:04 AM