On Fri, Jul 31, 2009 at 01:42:35PM -0500, Bill Gatliff wrote:
> Robert Schwebel wrote:
>>
>>> The question I've been looking at is: do sub-second boot times make
>>> all this a moot point? After all, if you can bring up your graphics
>>> driver in a fraction of a second and use *it* to display a splash
>>> screen, it seems like it would meet your need to give almost immediate
>>> feedback to users that the system is alive.
>>>
>>
>> Yup, that would be cool.
>>
>> However, on flash-based systems in the ARM926 / 200...400 MHz class
>> (which is still quite common) the boot time up to the point where the
>> penguin appears is still about 3...4 s [1] which is too long. So I
>> suspect until systems become faster, we'll have no other choice than
>> such as scenario.
>>
>
> Could your bootloader pre-initialize the graphics hardware to the same
> mode that the Linux driver will ultimately select, and then throw up a
> static graphic? That would give you some output until the driver itself
> comes online.
I implemented exactly this for the i.MX framebuffer last week. It works
by looking at the controllers physical screen start address, ioremapping
this address and copying the content to the newly allocated framebuffer.
Currently the driver still reinitilializes the controller with exactly
the same values. We could skip this initialization step depending on a
imxfb.preinitialized=1 command line parameter and read back
resolution/depth from the device in order to fill the fb_info struct.
This approach works good, I just wonder how acceptable it is for
mainline.
The downside of this approach is that we have to add
mem=${physical_mem - 1MB} to the command line.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
