On Thu, Sep 22, 2022 at 9:55 AM Pali Rohár <p...@kernel.org> wrote: > > On Wednesday 21 September 2022 16:59:41 Chris Packham wrote: > > diff --git a/arch/arm/dts/ac5-98dx35xx-rd.dts > > b/arch/arm/dts/ac5-98dx35xx-rd.dts > ... > > +/ { > > + model = "Marvell RD-AC5X Board"; > > + compatible = "marvell,rd-ac5x", "marvell,ac5x", "marvell,ac5"; > > + > > + aliases { > > + serial0 = &uart0; > ... > > + }; > ... > > + chosen { > > + stdout-path = "serial0:115200n8"; > > + }; > ... > > diff --git a/include/configs/mvebu_alleycat-5.h > > b/include/configs/mvebu_alleycat-5.h > ... > > +#define CONFIG_EXTRA_ENV_SETTINGS \ > ... > > + "console=console=ttyS0,115200 earlycon=uart8250,mmio32,0xf0512000\0"\ > > Hello! Is not this console=console= line suspicious? > > And also because default console device is selected by /chosen/stdout-path > DT property and earlycon address is also parsed from DTS, I have feeling > that specifying it on cmdline is just duplication of DTS. > > Try to boot your arm64 kernel with just "earlycon" string without > specifying uart8250,mmio32... I think that it should work fine. >
Yeah I think this is a relic. The original code had all kinds of magic for manipulating bootargs that involved pulling in the console from the environment. I think it can go as the default should come from the DTS. Anything else is up to the user to configure bootargs appropriately. > > I think that main issue here is that people just choose one board or > config file, copy it and simple modify it and letting all those historic > relict not needed in u-boot anymore. And due to this copy+paste stuff > nobody knows what is needed, what not and nobody knows answer to > important question "why it is there?". > > But I understand it. The best for developer is to take something which > works and do just simple modification for specific board to achieve > functionality. Doing more modification or trying to understand if there > is not unnecessary code consume lot of time which people do not have... > > (nothing wrong; just I'm reading code and trying to understand it what > it is doing or why it is there... and detect possible dead code patterns > :-)) I think you're right to point it out. I encounter the same thing all the time at $dayjob and try to push back against the blind copy-pasting so I should really know better (there is an amount of rebase fatigue from porting the old code).