[PATCH] ARM: move memory layout sanity checking before meminfo initialization

[Colin Cross]

On Fri, Jul 15, 2011 at 2:07 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Fri, Jul 15, 2011 at 01:58:37PM -0700, Colin Cross wrote:
>> On Fri, Jul 15, 2011 at 11:13 AM, Russell King - ARM Linux
>> <linux at arm.linux.org.uk> wrote:
>> > On Fri, Jul 15, 2011 at 10:35:14AM -0700, Colin Cross wrote:
>> >> CMDLINE_EXTEND solves a real problem, and when it's not solved in the
>> >> kernel, it ends up getting solved in every bootloader.  Every
>> >> kernel/board requires some command line options (like "console="), and
>> >> every bootloader ends up passing some special options.
>> >
>> > And yet again, if you have a kernel with a built-in console= setting,
>> > there is _no_ _way_ to disable that console via the kernel command
>> > line.
>> >
>> > So what if some of your platforms need one console, others need a different
>> > console, but must not use the first one...
>> >
>> > Do we need nomem= and noconsole= options too?  Or do we just do the
>> > sane thing and get rid of CMDLINE_EXTEND - or insist that stuff like
>> > console= and mem= options are never built-in ?
>> >
>>
>> The source of the problem is that there are two kinds of options mixed
>> together into one command line:
>> 1.  Options that are specific to the kernel and board (console, mem, etc.)
>> 2.  Options that tell the kernel information that only the bootloader
>> knows (Tegra needs to know where the bootloader put signed resume code
>> to be executed by a slave processor, some devices need to get a MAC
>> address from the bootloader)
>>
>> For kernels that are designed to run on a single board, the kernel
>> options can go into the built-in command line, the bootloader options
>> can be concatenated with CONFIG_CMDLINE_EXTEND, and everything works
>> great (unless I forget to remove the mem= option from the bootloader
>> options).
>
> I'm sorry at this point I'm having a hard time taking this seriously.
> Really.
>
> Your boot loader doesn't know how much memory is there?  Or if it does
> you've chosen not to use ATAG_MEM to pass that information to the kernel,
> but instead provide it via the command line.  And then you complain that
> two overlapping mem= arguments cause the kernel to explode.

Obviously, this is wrong.  I said it was a mistake to pass overlapping
mem=, I fixed where I was passing it in twice, the bootloader is
passing the correct ATAG_MEM, and the only remaining mem= will go away
as soon as all the drivers use memblock_remove to get their memory out
of the kernel mapping.  But for now, I have a reduced mem= in the
kernel built-in command line, because the problem is a kernel problem
- drivers needing contiguous memory removed from the mapping.

> Sorry, I can't take you seriously if that's what you're doing.
>
> ATAG_MEM is there for the boot loader to pass the memory information to
> the kernel.  mem= is there to allow overriding that information.
>
> We don't need yet another way to override memory information.  We need
> people sanely using what's there already.
>
> NO FIX.

My initial offer was a patch that makes an incorrect overlapping mem=
command line print a warning and ignore it, instead of doing something
that is guaranteed to crash the kernel in an obscure way.  I'll post a
patch.

The thread has devolved into a generic command line problem - how to
pass completely unrelated options from the bootloader to the kernel
without also having to pass in every other option that the kernel
requires to boot.  I have a solution that works for my case
(CMDLINE_EXTEND), I was trying to offer a solution that would work for
me while also working for multi-board kernels, but I'm happy to drop
it.