[U-Boot] [PATCHv2] omap3evm: Pass 'mem' argument to linux kernel

[Premi, Sanjeev]

>From: Tom Rini [tom.rini at gmail.com]
>Sent: Wednesday, September 28, 2011 12:59 AM
>To: Premi, Sanjeev
>Cc: u-boot at lists.denx.de
>Subject: Re: [U-Boot] [PATCHv2] omap3evm: Pass 'mem' argument to linux kernel
>
>On Tue, Sep 27, 2011 at 9:43 AM, Premi, Sanjeev <premi at ti.com> wrote:
>>> -----Original Message-----
>>> From: Tom Rini [mailto:tom.rini at gmail.com]
>>> Sent: Tuesday, September 27, 2011 9:29 PM
>>> To: Premi, Sanjeev
>>> Cc: u-boot at lists.denx.de
>>> Subject: Re: [U-Boot] [PATCHv2] omap3evm: Pass 'mem' argument
>>> to linux kernel
>>>
>>> On Tue, Sep 27, 2011 at 8:00 AM, Sanjeev Premi <premi at ti.com> wrote:
>>> > In absence of this argument, Linux kernel doesn't boot.
>>> >
>>> > Even though many newer boards support 256M, default
>>> > value has been set to 128M to ensure that default
>>> > build can boot older EVM variants.
>>> >
>>> > Signed-off-by: Sanjeev Premi <premi at ti.com>
>>>
>>> But you aren't addressing the fact you just limited everyone to 128M,
>>> which is not right.  Please make this set the value to what u-boot
>>> detects the board to have at runtime at least.
>>
>> This patch changes the static environment string compiled
>> on the host.
>>
>> These is the default value that gets the board booting up.
>> The environment variable memsize can be overwritten to 256M
>> by the boards that have more memory. So, there is no hard
>> limit.
>>
>> ...which I believe is better than kernel failing to load on old
>> boards; leaving some users clueless about failure.
>>
>> Detecting the actual memory size and then changing the environment
>> variable can be a feature, but it isn't fool proof, because many
>> applications esp on DM3730, use memory hole and would like their
>> bootargs to be different.
>
>Thanks for explaining.  Given that someone else objected to this on
>the same grounds against v1 please try and add that type of info to
>the email in the future.

I did miss the mail from Igor, and responded to him later. The patch
describes the reason for choosing 128M - which i considered sufficient.
It didn't occur to me that changes to CONFIG_BOOTARGS could/ would be
considered as hard limit - else I would have described.

~sanjeev

>
>--
>Tom
>