Messages in this thread |  | | Date | Fri, 22 Sep 2000 11:57:22 +0000 | From | Pavel Machek <> | Subject | Re: [DOC] Debugging early kernel hangs |
| |
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/
|  |