[U-Boot] [PATCHv2] omap3evm: Pass 'mem' argument to linux kernel
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(-)
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" \
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 "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
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
participants (4)
-
Premi, Sanjeev -
Sanjeev Premi
-
Tom Rini -
Wolfgang Denk