[PATCH v3 6/6] arm: mvebu: Add RD-AC5X board

Chris Packham judge.packham at gmail.com
Thu Sep 22 01:08:13 CEST 2022


On Thu, Sep 22, 2022 at 9:55 AM Pali Rohár <pali at 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).


More information about the U-Boot mailing list