Re: [microblaze-uclinux] early printk support for microblaze

[Yasushi SHOJI <yashi@xxxxxxxxxxxxxxxxx>]

Hi David and John,

At Fri, 20 Feb 2004 11:06:31 +1000,
John Williams wrote:
> 
> David McCullough wrote:
> > Jivin John Williams lays it down ...
> > 
> >>Yasushi SHOJI wrote:
> >>
> >>>if you apply the patch it produce boot log like the above. note that
> >>>the top part of boot log is duplicated. The reason I said was that I
> >>>misunderstood what CON_PRINTBUFFER is for.
> >>>
> >>>it might be better to redirect early printk's out put to debug uart if
> >>>the platform has one.  what do you think?
> >>
> >>OK, i'm slowly catching up!  Sorry, I'd never heard of early printk 
> >>before - but a google search suggests it's a capability to use printk() 
> >>before the kernel calls console_init(), is that right?
> >>
> >>What I don't understand, is why it is necessary?  Any printk() output 
> >>that is sent before calling console_init() gets buffered, and is output 
> >>eventually.
> >>
> >>Or should pre-console_init() printk's be output immediately, in case the 
> >>kernel hangs/crashes before console_init()?

yup, when I messed around with boot memory allocator, kernel died
without any printk outputs.

> > Early printk is (from what I have seen) a hack for debugging new
> > platforms that do not make it that far through the boot for
> > CON_PRINTBUFFER to kick in.
> > 
> > It's always a bit messy IMO.
> > 
> > What you probably want is a config option.  If EARLY_PRINTK is set,
> > don't set CON_PRINTBUFFER and have the two work it out so that you do
> > not get the output twice.

I couldn't find one console driver which changes flag with ifdef
EARLY_PRINTK.  I've never used early printk on other arch, so don't
know how it puts message out.

> OK, I think I see what's happening now.
> 
> Yashi - near the top of xmbserial.c there's already some debug output 
> routines left-over from a while ago:
> 
> db_print(char *);
> db_printnum(int);
> 
> They can be called from head.S - much earlier than printk will ever work.

yup.  I also created db_print_hex(). ;)

yes db_print*() are very useful, but there are so many printk()
already in main stream kernel for debugging purpose. (most of them are
for error messages) why do we want to put db_print() and friends to do
the same stuff?

> However, if you are keen for early printk - is there a reasonably clean 
> way to just modify xmb_serial, instead of introducing the new console 
> driver early_printk.c?

i've never tried but i don't think it works.  because, xmb_serial is
too complex, that is, it uses interrupt, scheduler, and etc.

[...]

> PS Once the dust settles on this early printk stuff we should move 
> xmb_serial.[ch] into /drivers/char where they belong, and probably 
> rename them to xul_serial in the process.

do you also want to change function/variable prefix for consistency?

regards,
--
         yashi
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/