Re: [RFC] [IP22] parsing PROM variables at startup

[Ralf Baechle <ralf@linux-mips.org>]

On Tue, Oct 13, 2009 at 08:55:12PM +0300, Dmitri Vorobiev wrote:

> I tried booting a few kernels, ranging from 2.2.1 to the current Linus
> Git, on my IP22s using an ecoff image directly, without the help of
> arcboot or tip22. It turns out that during many years (at least, since
> the times of late 2.4 series) the sizes of ecoff images have been so
> big that ARCS was not capable of reading the kernel images. Therefore,
> I'd like to claim that it's safe to assume that at least from now on,
> nobody is ever going to boot ecoffs on IP22 whatsoever, and arcboot
> and tip22 remain the only way to load Linux on an IP22 machine.

Only the very oldest IP22 firmware does not support ELF files.  In practice
those seem to be very rare - I never encountered one - and Linux
distributions are shipping a 2nd stage bootloader, so there never has
been much of a need for booting ECOFF, at least not on Indy.

> I'm leading to the following thing. Currently we have the
> arch/mips/fw/arc/cmdline.c, which assumes that the kernel could
> receive command-line parameters directly from PROM, including such
> variables as OSLoadPartition, OSLoadFilename, etc. Both arcboot and
> tip22 handle those parameters by themselves, never exposing them to
> the kernel. The latter fact is easy to see from the sources of the
> arcboot and tip22 loaders. That said, I would like to simplify
> arch/mips/fw/arc/cmdline.c::prom_init_cmdline() so that the PROM
> variables do not get any special treatment.

But keep kernels usable without a 2nd stage bootloader.  I for example
have never ever used one on my SGI hardware.

> Are you asking me why did I start touching the 13-years-old code?
> 
> There is an unpleasant bug in the current PROM command line handler.
> Namely, the CONFIG_CMDLINE, if set, is overwritten when
> prom_init_cmdline() tries to strip off some of the PROM variables, and
> it's easy to see from the code of that function. So, I thought of
> fixing that, and, simultaneously, of simplifying the overall logic by
> assuming that we never ever have to special-case the PROM variables at
> all.
> 
> Could anyone see any drawbacks in the discourse above? If not, I'll
> start making a patch.

I think nobody will claim a 13 year old quickhack can't be improved.

  Ralf