>From: Tom Rini [[email protected]] >Sent: Wednesday, September 28, 2011 12:59 AM >To: Premi, Sanjeev >Cc: [email protected] >Subject: Re: [U-Boot] [PATCHv2] omap3evm: Pass 'mem' argument to linux kernel > >On Tue, Sep 27, 2011 at 9:43 AM, Premi, Sanjeev <[email protected]> wrote: >>> -----Original Message----- >>> From: Tom Rini [mailto:[email protected]] >>> Sent: Tuesday, September 27, 2011 9:29 PM >>> To: Premi, Sanjeev >>> Cc: [email protected] >>> Subject: Re: [U-Boot] [PATCHv2] omap3evm: Pass 'mem' argument >>> to linux kernel >>> >>> On Tue, Sep 27, 2011 at 8:00 AM, Sanjeev Premi <[email protected]> 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 <[email protected]> >>> >>> 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 > _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
