On Tue, Apr 10, 2018 at 8:44 AM, Michal Simek <michal.si...@xilinx.com> wrote: > Hi Rob, > > On 28.3.2018 04:06, Rob Herring wrote: >> With earlycon support now enabled, the arch specific early_printk support >> can be removed. > > earlycon is not the full replacement of early_printk support as is > designed right now. > Definitely current early_printk is pretty old and contains code > duplication but it starts much earlier then earlycon.
Yes, essentially it's after MMU enabling rather than before. But it is still before any h/w specific setup (dependent on the DT) which is where one would typically fail to boot. Generally, I've found before DT unflattening to be early enough. What can go wrong at this early stage? Memory is flaky or you've passed in bad memory ranges or image locations. An earlier console may or may not help there and those problems are easier to debug in the bootloader. So it is a question of what you want to maintain. >> Signed-off-by: Rob Herring <r...@kernel.org> >> Cc: Michal Simek <mon...@monstr.eu> >> --- >> v2: >> - Fix booting. The setup_memory call needed to be before the >> parse_early_param call. > > What's the reason for calling setup_memory before parse_early_param? > Is there any dependency? Yes, either fixmap or ioremap (in your case) has to be functional when earlycon is setup which happens via parse_early_param. Rob