| Message ID | 1317135653-13435-1-git-send-email-premi@ti.com |
|---|---|
| State | Changes Requested |
| Headers | show |
On Tue, Sep 27, 2011 at 8:00 AM, Sanjeev Premi <premi@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@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.
> -----Original Message----- > From: Tom Rini [mailto:tom.rini@gmail.com] > Sent: Tuesday, September 27, 2011 9:29 PM > To: Premi, Sanjeev > Cc: u-boot@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@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@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. ~sanjeev > > -- > Tom >
On Tue, Sep 27, 2011 at 9:43 AM, Premi, Sanjeev <premi@ti.com> wrote: >> -----Original Message----- >> From: Tom Rini [mailto:tom.rini@gmail.com] >> Sent: Tuesday, September 27, 2011 9:29 PM >> To: Premi, Sanjeev >> Cc: u-boot@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@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@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.
>From: Tom Rini [tom.rini@gmail.com] >Sent: Wednesday, September 28, 2011 12:59 AM >To: Premi, Sanjeev >Cc: u-boot@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@ti.com> wrote: >>> -----Original Message----- >>> From: Tom Rini [mailto:tom.rini@gmail.com] >>> Sent: Tuesday, September 27, 2011 9:29 PM >>> To: Premi, Sanjeev >>> Cc: u-boot@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@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@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 >
Dear Sanjeev Premi, In message <1317135653-13435-1-git-send-email-premi@ti.com> you 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@ti.com> > --- > Changes since v1: > Removed the string terminators "\0" from > definition of mmcargs and nandargs. > > include/configs/omap3_evm.h | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) My questions remain: why cannot we simple remove these mem+ settings which cause only harm? Best regards, Wolfgang Denk
Dear "Premi, Sanjeev", In message <B85A65D85D7EB246BE421B3FB0FBB59302577A8A4D@dbde02.ent.ti.com> you wrote: > > 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. Why the hell would you ever want to do that? U-Boot is capable of auto-detecting the actual RAM sioze and passing correct information to Linux, so why do you meddle with this? Best regards, Wolfgang Denk
diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h index 7af30c2..c399515 100644 --- a/include/configs/omap3_evm.h +++ b/include/configs/omap3_evm.h @@ -200,11 +200,14 @@ "loadaddr=0x82000000\0" \ "usbtty=cdc_acm\0" \ "mmcdev=0\0" \ + "memsize=128M\0" \ "console=ttyO0,115200n8\0" \ "mmcargs=setenv bootargs console=${console} " \ + "mem=${memsize} " \ "root=/dev/mmcblk0p2 rw " \ "rootfstype=ext3 rootwait\0" \ "nandargs=setenv bootargs console=${console} " \ + "mem=${memsize} " \ "root=/dev/mtdblock4 rw " \ "rootfstype=jffs2\0" \ "loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \
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@ti.com> --- Changes since v1: Removed the string terminators "\0" from definition of mmcargs and nandargs. include/configs/omap3_evm.h | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)