Re: [PATCH v2 2/3] microblaze: remove redundant early_printk support
On Mon, Apr 23, 2018 at 5:50 AM, Michal Simek wrote: > On 13.4.2018 16:11, Rob Herring wrote: >> On Tue, Apr 10, 2018 at 8:44 AM, Michal Simek >> 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 Cc: Michal Simek --- 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. > > Ok. Let's add it and see if there is any issue. Do you have any code > which depends on this series? No, I don't. Rob
Re: [PATCH v2 2/3] microblaze: remove redundant early_printk support
On 13.4.2018 16:11, Rob Herring wrote: > On Tue, Apr 10, 2018 at 8:44 AM, Michal Simek 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 >>> Cc: Michal Simek >>> --- >>> 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. Ok. Let's add it and see if there is any issue. Do you have any code which depends on this series? Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 2/3] microblaze: remove redundant early_printk support
On Tue, Apr 10, 2018 at 8:44 AM, Michal Simek 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 >> Cc: Michal Simek >> --- >> 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
Re: [PATCH v2 2/3] microblaze: remove redundant early_printk support
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. > > Signed-off-by: Rob Herring > Cc: Michal Simek > --- > 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? Thanks, Michal
