[RFC] Dynamic boot logo

[RFC] Dynamic boot logo

[Rodolfo Giometti]

Hello,

I'd like to have some suggestions from you about how I can implement
the "dynamic boot logo" feature in Linux reading the logo from the
flash memory.

In my custom board, using u-boot I read a compressed bitmap from the
flash memory and then I use it to display the logo, so users just have
to change flash content in order to change then boot logo without
recompiling u-boot.

Could it be possible in Linux also? Which could be, in your opinion,
the best way to solve this problem?

Thanks in advance,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail:    giometti@enneenne.com
Linux Device Driver                             giometti@gnudd.com
Embedded Systems                     		giometti@linux.it
UNIX programming                     phone:     +39 349 2432127

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: [RFC] Dynamic boot logo

[hinko.kocevar]

Rodolfo Giometti wrote:
> Hello,
> 
> I'd like to have some suggestions from you about how I can implement
> the "dynamic boot logo" feature in Linux reading the logo from the
> flash memory.

We would like to have this feature on my embedded system too! Currently 
we are using bitmap file converted to standard header file and then 
compiled in the kernel, which is not flexible at all.

> 
> In my custom board, using u-boot I read a compressed bitmap from the
> flash memory and then I use it to display the logo, so users just have
> to change flash content in order to change then boot logo without
> recompiling u-boot.
> 
> Could it be possible in Linux also? Which could be, in your opinion,
> the best way to solve this problem?

Maybe you could access the same flash memory from the Linux too - using 
either physical or virtual address space, eg. by I/O or memory mapping it.
Another way could be using a dedicated kernel module for the job - eg. 
you compile the graphic support in the module and the when update is 
needed only module can be replaced in the file system leaving kernel 
intact (at least while kernel version does not change).

In our case, a) we can not use boot loader and, b) we use kernel with 
module support disabled, so these variants were not tested on our side.

HTH,
hinko


-- 
ÄŒETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar@cetrtapot.si
Http: www.cetrtapot.si


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: [RFC] Dynamic boot logo

[Rodolfo Giometti]

On Mon, Aug 06, 2007 at 09:53:24AM +0200, hinko.kocevar@cetrtapot.si wrote:
> 
> We would like to have this feature on my embedded system too! Currently 
> we are using bitmap file converted to standard header file and then 
> compiled in the kernel, which is not flexible at all.

Yes, I see.

> Maybe you could access the same flash memory from the Linux too - using 
> either physical or virtual address space, eg. by I/O or memory mapping it.

Yes, I know, but _how_ can I do it? :) In u-boot is very easy but in
Linux I still haven't found a good way to do so.

> Another way could be using a dedicated kernel module for the job - eg. 
> you compile the graphic support in the module and the when update is 
> needed only module can be replaced in the file system leaving kernel 
> intact (at least while kernel version does not change).

This is not solve the problem, you still need a compilation stage. I
wish avoiding it. And, on the other hand, you cannot load a kernel
module since you don't mount a root filesystem which is very late
during boot.

Ciao,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail:    giometti@enneenne.com
Linux Device Driver                             giometti@gnudd.com
Embedded Systems                     		giometti@linux.it
UNIX programming                     phone:     +39 349 2432127

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: [RFC] Dynamic boot logo

[hinko.kocevar]

Rodolfo Giometti wrote:
> On Mon, Aug 06, 2007 at 09:53:24AM +0200, hinko.kocevar@cetrtapot.si wrote:
>> We would like to have this feature on my embedded system too! Currently 
>> we are using bitmap file converted to standard header file and then 
>> compiled in the kernel, which is not flexible at all.
> 
> Yes, I see.
> 
>> Maybe you could access the same flash memory from the Linux too - using 
>> either physical or virtual address space, eg. by I/O or memory mapping it.
> 
> Yes, I know, but _how_ can I do it? :) In u-boot is very easy but in
> Linux I still haven't found a good way to do so.

I'm almost certain that your architecture (whatever it may be) uses I/O 
and/or memory mapped memory for certain purposes. Best way to see how it 
is done would be to look at the drivers that are used on your architecture.
The bottom line is that ioremap() and friends could be used in 
combination with ioread/iowrite and/or readb/writeb primitives to map 
and later access the block of memory.

If you need some kernel programming pointers try reading Linux device 
drivers 3 (http://lwn.net/Kernel/LDD3/) or similar book. Also 
subscribing to the kernelnewbies mailing list could help with kernel basics.

> 
>> Another way could be using a dedicated kernel module for the job - eg. 
>> you compile the graphic support in the module and the when update is 
>> needed only module can be replaced in the file system leaving kernel 
>> intact (at least while kernel version does not change).
> 
> This is not solve the problem, you still need a compilation stage. I
> wish avoiding it. And, on the other hand, you cannot load a kernel
> module since you don't mount a root filesystem which is very late
> during boot.

You are right. I totally missed that part of the procedure although you 
could use initrd or initramfs for the job (but that does not remove the 
need to recompile the kernel when new module is being deployed).

Regards,
Hinko


-- 
ÄŒETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar@cetrtapot.si
Http: www.cetrtapot.si


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: [RFC] Dynamic boot logo

[Rodolfo Giometti]

On Mon, Aug 06, 2007 at 02:34:22PM +0200, hinko.kocevar@cetrtapot.si wrote:
> 
> I'm almost certain that your architecture (whatever it may be) uses I/O 
> and/or memory mapped memory for certain purposes. Best way to see how it 
> is done would be to look at the drivers that are used on your architecture.
> The bottom line is that ioremap() and friends could be used in 
> combination with ioread/iowrite and/or readb/writeb primitives to map 
> and later access the block of memory.

It's not so easy as may appear... using ioremap() & friends is not
enought since flash memories may have different interfaces to the
CPU. So the best way, IMHO, is accessing to flash memory by using the
MTD interface... however I need also a gunzip() procedure and a way to
decode BMP images in a compatibility manner for the current Linux's
logo support.

Ciao,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail:    giometti@enneenne.com
Linux Device Driver                             giometti@gnudd.com
Embedded Systems                     		giometti@linux.it
UNIX programming                     phone:     +39 349 2432127

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/