EARLY_PRINTK equivalent for framebuffers.

8 messages, 3 authors, 2014-08-29 · open the first message on its own page

EARLY_PRINTK equivalent for framebuffers.

From: jonsmirl@gmail.com <hidden>
Date: 2014-08-28 19:19:39

Is there some existing way to do early printk type output to a
framebuffer that has been set up by the bootloader?  early printk is
before any device drivers are loaded.

If not, what would it take to create a way to do this? Something along
the lines of build in the fbdev library and give it an address plus
x/y layout of the buffer. Assume that everything else is set up and
anything written to the buffer will appear on the display. Then hook
into where the kernel does early printk on uarts and add in support
for this buffer. The core fbdev library implements scrolling and
graphical characters.

I'm only looking to address early boot messages so that if the kernel
fails to boot before it can get to a real video driver, the output is
still visible.

Note that you get this early output right now, but it is buffered by
the kernel until the console driver is loaded, then it gets dumped. If
you fail before that console driver loads you see nothing. The idea is
to make the output that gets lost visible.

To communicate this you need the existing fb mode line on the kernel
command line (to get x/y layout) plus the framebuffer address. Or this
info can come via the DT.

No intention to keep this display working once real display drivers
get loaded. So no touching clocks, regulators, display modes, etc....

-- 
Jon Smirl
jonsmirl@gmail.com

Re: EARLY_PRINTK equivalent for framebuffers.

From: Alexandre Courbot <hidden>
Date: 2014-08-29 01:36:00

On Thu, Aug 28, 2014 at 12:19 PM, jonsmirl@gmail.com [off-list ref] wrote:
Is there some existing way to do early printk type output to a
framebuffer that has been set up by the bootloader?  early printk is
before any device drivers are loaded.

If not, what would it take to create a way to do this? Something along
the lines of build in the fbdev library and give it an address plus
x/y layout of the buffer. Assume that everything else is set up and
anything written to the buffer will appear on the display. Then hook
into where the kernel does early printk on uarts and add in support
for this buffer. The core fbdev library implements scrolling and
graphical characters.
simplefb does something like this (implement a console on top of a
framebuffer set up by the bootloader), but I don't think you can use
it for earlyprintk. It would be a very interesting option though (and
even better if it could be used by the kernel decompression code), but
I suspect this is more involved than good old UART as you need to
manage fonts, pixel format, screen geometry, etc.

OTOH it would be very useful for some retail devices that come without
an accessible serial line, but have a framebuffer set up by the
bootloader.

Alex.

Re: EARLY_PRINTK equivalent for framebuffers.

From: jonsmirl@gmail.com <hidden>
Date: 2014-08-29 01:40:48

On Thu, Aug 28, 2014 at 9:36 PM, Alexandre Courbot [off-list ref] wrote:
On Thu, Aug 28, 2014 at 12:19 PM, jonsmirl@gmail.com [off-list ref] wrote:
quoted
Is there some existing way to do early printk type output to a
framebuffer that has been set up by the bootloader?  early printk is
before any device drivers are loaded.

If not, what would it take to create a way to do this? Something along
the lines of build in the fbdev library and give it an address plus
x/y layout of the buffer. Assume that everything else is set up and
anything written to the buffer will appear on the display. Then hook
into where the kernel does early printk on uarts and add in support
for this buffer. The core fbdev library implements scrolling and
graphical characters.
simplefb does something like this (implement a console on top of a
framebuffer set up by the bootloader), but I don't think you can use
it for earlyprintk. It would be a very interesting option though (and
simplefb is a device driver so it doesn't process the early output.
This would need to be some custom code that gets the framebuffer
address  and x/y setup very early in the boot process. I'm fairly sure
nothing like it current exists.

even better if it could be used by the kernel decompression code), but
I suspect this is more involved than good old UART as you need to
manage fonts, pixel format, screen geometry, etc.

OTOH it would be very useful for some retail devices that come without
an accessible serial line, but have a framebuffer set up by the
bootloader.

Alex.


-- 
Jon Smirl
jonsmirl@gmail.com

Re: EARLY_PRINTK equivalent for framebuffers.

From: Alexandre Courbot <hidden>
Date: 2014-08-29 01:54:18

On Thu, Aug 28, 2014 at 6:40 PM, jonsmirl@gmail.com [off-list ref] wrote:
On Thu, Aug 28, 2014 at 9:36 PM, Alexandre Courbot [off-list ref] wrote:
quoted
On Thu, Aug 28, 2014 at 12:19 PM, jonsmirl@gmail.com [off-list ref] wrote:
quoted
Is there some existing way to do early printk type output to a
framebuffer that has been set up by the bootloader?  early printk is
before any device drivers are loaded.

If not, what would it take to create a way to do this? Something along
the lines of build in the fbdev library and give it an address plus
x/y layout of the buffer. Assume that everything else is set up and
anything written to the buffer will appear on the display. Then hook
into where the kernel does early printk on uarts and add in support
for this buffer. The core fbdev library implements scrolling and
graphical characters.
simplefb does something like this (implement a console on top of a
framebuffer set up by the bootloader), but I don't think you can use
it for earlyprintk. It would be a very interesting option though (and
simplefb is a device driver so it doesn't process the early output.
This would need to be some custom code that gets the framebuffer
address  and x/y setup very early in the boot process. I'm fairly sure
nothing like it current exists.
You're right AFAICT. And although simplefb shares part of of idea it
also doesn't operate at the required level. Also contrary to what I
said it also does not implement a console, but just a framebuffer
device on top of which you need some more logic before you can think
about displaying strings.

It seems like what would be needed is an early platform driver that
would operate like earlyprintk, with some extra parameters to specify
the FB's location and properties. Such a driver would be very
simplistic though, and I don't think we could have things like a
smooth transition with the "real" console, although I guess that's not
the goal here.

Re: EARLY_PRINTK equivalent for framebuffers.

From: jonsmirl@gmail.com <hidden>
Date: 2014-08-29 02:00:14

On Thu, Aug 28, 2014 at 9:54 PM, Alexandre Courbot [off-list ref] wrote:
On Thu, Aug 28, 2014 at 6:40 PM, jonsmirl@gmail.com [off-list ref] wrote:
quoted
On Thu, Aug 28, 2014 at 9:36 PM, Alexandre Courbot [off-list ref] wrote:
quoted
On Thu, Aug 28, 2014 at 12:19 PM, jonsmirl@gmail.com [off-list ref] wrote:
quoted
Is there some existing way to do early printk type output to a
framebuffer that has been set up by the bootloader?  early printk is
before any device drivers are loaded.

If not, what would it take to create a way to do this? Something along
the lines of build in the fbdev library and give it an address plus
x/y layout of the buffer. Assume that everything else is set up and
anything written to the buffer will appear on the display. Then hook
into where the kernel does early printk on uarts and add in support
for this buffer. The core fbdev library implements scrolling and
graphical characters.
simplefb does something like this (implement a console on top of a
framebuffer set up by the bootloader), but I don't think you can use
it for earlyprintk. It would be a very interesting option though (and
simplefb is a device driver so it doesn't process the early output.
This would need to be some custom code that gets the framebuffer
address  and x/y setup very early in the boot process. I'm fairly sure
nothing like it current exists.
You're right AFAICT. And although simplefb shares part of of idea it
also doesn't operate at the required level. Also contrary to what I
said it also does not implement a console, but just a framebuffer
device on top of which you need some more logic before you can think
about displaying strings.
turn on fbconsole support and it should work.
It seems like what would be needed is an early platform driver that
would operate like earlyprintk, with some extra parameters to specify
the FB's location and properties. Such a driver would be very
simplistic though, and I don't think we could have things like a
smooth transition with the "real" console, although I guess that's not
the goal here.


-- 
Jon Smirl
jonsmirl@gmail.com

Re: EARLY_PRINTK equivalent for framebuffers.

From: Alexandre Courbot <hidden>
Date: 2014-08-29 02:05:16

On Thu, Aug 28, 2014 at 7:00 PM, jonsmirl@gmail.com [off-list ref] wrote:
On Thu, Aug 28, 2014 at 9:54 PM, Alexandre Courbot [off-list ref] wrote:
quoted
On Thu, Aug 28, 2014 at 6:40 PM, jonsmirl@gmail.com [off-list ref] wrote:
quoted
On Thu, Aug 28, 2014 at 9:36 PM, Alexandre Courbot [off-list ref] wrote:
quoted
On Thu, Aug 28, 2014 at 12:19 PM, jonsmirl@gmail.com [off-list ref] wrote:
quoted
Is there some existing way to do early printk type output to a
framebuffer that has been set up by the bootloader?  early printk is
before any device drivers are loaded.

If not, what would it take to create a way to do this? Something along
the lines of build in the fbdev library and give it an address plus
x/y layout of the buffer. Assume that everything else is set up and
anything written to the buffer will appear on the display. Then hook
into where the kernel does early printk on uarts and add in support
for this buffer. The core fbdev library implements scrolling and
graphical characters.
simplefb does something like this (implement a console on top of a
framebuffer set up by the bootloader), but I don't think you can use
it for earlyprintk. It would be a very interesting option though (and
simplefb is a device driver so it doesn't process the early output.
This would need to be some custom code that gets the framebuffer
address  and x/y setup very early in the boot process. I'm fairly sure
nothing like it current exists.
You're right AFAICT. And although simplefb shares part of of idea it
also doesn't operate at the required level. Also contrary to what I
said it also does not implement a console, but just a framebuffer
device on top of which you need some more logic before you can think
about displaying strings.
turn on fbconsole support and it should work.
Yeah, but my point was, that I don't think you can use fbconsole that
early in the kernel?

Re: EARLY_PRINTK equivalent for framebuffers.

From: jonsmirl@gmail.com <hidden>
Date: 2014-08-29 02:09:20

On Thu, Aug 28, 2014 at 10:05 PM, Alexandre Courbot [off-list ref] wrote:
On Thu, Aug 28, 2014 at 7:00 PM, jonsmirl@gmail.com [off-list ref] wrote:
quoted
On Thu, Aug 28, 2014 at 9:54 PM, Alexandre Courbot [off-list ref] wrote:
quoted
On Thu, Aug 28, 2014 at 6:40 PM, jonsmirl@gmail.com [off-list ref] wrote:
quoted
On Thu, Aug 28, 2014 at 9:36 PM, Alexandre Courbot [off-list ref] wrote:
quoted
On Thu, Aug 28, 2014 at 12:19 PM, jonsmirl@gmail.com [off-list ref] wrote:
quoted
Is there some existing way to do early printk type output to a
framebuffer that has been set up by the bootloader?  early printk is
before any device drivers are loaded.

If not, what would it take to create a way to do this? Something along
the lines of build in the fbdev library and give it an address plus
x/y layout of the buffer. Assume that everything else is set up and
anything written to the buffer will appear on the display. Then hook
into where the kernel does early printk on uarts and add in support
for this buffer. The core fbdev library implements scrolling and
graphical characters.
simplefb does something like this (implement a console on top of a
framebuffer set up by the bootloader), but I don't think you can use
it for earlyprintk. It would be a very interesting option though (and
simplefb is a device driver so it doesn't process the early output.
This would need to be some custom code that gets the framebuffer
address  and x/y setup very early in the boot process. I'm fairly sure
nothing like it current exists.
You're right AFAICT. And although simplefb shares part of of idea it
also doesn't operate at the required level. Also contrary to what I
said it also does not implement a console, but just a framebuffer
device on top of which you need some more logic before you can think
about displaying strings.
turn on fbconsole support and it should work.
Yeah, but my point was, that I don't think you can use fbconsole that
early in the kernel?
You can't. But all of the needed code is sitting there in fbconsole.
There is just a small bit missing to make an early console work.
Mainly just the bit about address of buffer and x/y layout.


-- 
Jon Smirl
jonsmirl@gmail.com

Re: EARLY_PRINTK equivalent for framebuffers.

From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: 2014-08-29 08:51:28

Hi Jon,

On Thu, Aug 28, 2014 at 9:19 PM, jonsmirl@gmail.com [off-list ref] wrote:
Is there some existing way to do early printk type output to a
framebuffer that has been set up by the bootloader?  early printk is
before any device drivers are loaded.
arch/m68k/kernel/head.S does this on Mac.

ISTR offb also used to do that on PPC, or perhaps it was the
old PowerMac console driver we had before that.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help