> It certainly used to be the case on ppc32 (and may still be) that > ppc_md.progress was called very very early, in some cases before the > MMU was set up, so we don't want to call printk from it. Falling back > to udbg_printf would be more appropriate. > > The idea of ppc_md.progress was that if you need to debug very early > boot and you have something that you can poke with absolutely minimal > setup and observe externally, you can hook that up to ppc_md.progress > and get an idea where the system is dying. Once you get to the point > where printk works then you can just use printk.
Right, printk shouldn't be called before lockdep is initialized, though I don't see a call to lockdep_init on ppc32 .. Appart from that, printk is pretty safe as long as we have some kind of translation from PAGE_OFFSET that covers the kernel text, data and bss, which we do have fairly early. I think the reasons we did that back then is that printk output will end up nowhere. Nowadays however, we have udbg console which can possibly be initialized very early too. I'd say let's keep that patch on the back burner until we get a chance to play a bit more with that stuff. Among other things, I still want to change the early initialization order of ppc32 to look more like ppc64 which would help in that are as well so ... Cheers, Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
