Hi!
> > >However, there's still a huge gap between the last progress() message and
> > >availability of the frame buffer device. The simple console has the
> > >advantage of outputing existing printk messages. (basically, it's a
> > >console using prom_printf).
> >
> > Something I forgot to mention about debugging using screen writes. If
> > the problem is caused by incorrect compiler output then even printk can
> > fail. Not because the C code is wrong but because the generated
> > assembler is wrong. Writing direct to screen memory is as simple as it
> > gets and gives the compiler little or no chance to get it wrong.
>
> How about the possibility to use architecture specific backends? E.g. my
> little Alpha machine has an 8-bit debugging LED port that would be very suited
> for this. Or you could use a parallel port in a similar manner (for those
> vga-less server machines...). Other machines may have a LED system display
> for displaying HEX-digits.
>
> So when you use an 8-bit value and display it as 2 hex-digits (ok that would
> be 2 assembler insns instead of one..) this kind of devices could be supported
> equally well.
I like this. LEDs on aralel port are very nice debugging device, and having
hooks in kernel for boot-progress indication would be good.
Pavel
-- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 30 2000 - 21:00:15 EST