[U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx
From: Sandeep Paulraj s-paulraj@ti.com
This patch removes the asm/sizes.h header file from being included in the DaVinci SOC configs. References to SZ_xx have been replaced by appropriate bit shifted values.
Signed-off-by: Sandeep Paulraj s-paulraj@ti.com --- The "asm/sizes.h" header file has the phrase "All rights reserved" and i don't see a patch to rectify this. Also i gather from e-mails on the list that Wolfgang does not like these references to "SZ_xx". It appears to me that this file has a good chance of being removed from the repository. Thus this patch removes a dependency on this file. include/configs/davinci_dm355evm.h | 9 ++++----- include/configs/davinci_dm365evm.h | 9 ++++----- include/configs/davinci_dvevm.h | 5 ++--- include/configs/davinci_schmoogie.h | 3 +-- include/configs/davinci_sffsdr.h | 3 +-- include/configs/davinci_sonata.h | 3 +-- 6 files changed, 13 insertions(+), 19 deletions(-)
diff --git a/include/configs/davinci_dm355evm.h b/include/configs/davinci_dm355evm.h index c35f5c9..4e3415f 100644 --- a/include/configs/davinci_dm355evm.h +++ b/include/configs/davinci_dm355evm.h @@ -19,7 +19,6 @@
#ifndef __CONFIG_H #define __CONFIG_H -#include <asm/sizes.h>
/* Spectrum Digital TMS320DM355 EVM board */ #define DAVINCI_DM355EVM @@ -40,7 +39,7 @@ /* Memory Info */ #define CONFIG_NR_DRAM_BANKS 1 #define PHYS_SDRAM_1 0x80000000 -#define PHYS_SDRAM_1_SIZE SZ_128M +#define PHYS_SDRAM_1_SIZE (128 << 20) /* 128 MiB */
/* Serial Driver info: UART0 for console */ #define CONFIG_SYS_NS16550 @@ -130,7 +129,7 @@ #define CONFIG_SYS_PROMPT_HUSH_PS2 "> " #define CONFIG_SYS_LONGHELP
-#define CONFIG_ENV_SIZE SZ_16K +#define CONFIG_ENV_SIZE (16 << 10) /* 16 KiB */
/* NYET -- #define CONFIG_BOOTDELAY 5 */ #define CONFIG_BOOTCOMMAND \ @@ -146,8 +145,8 @@ #define CONFIG_NET_RETRY_COUNT 10
/* U-Boot memory configuration */ -#define CONFIG_STACKSIZE SZ_256K /* regular stack */ -#define CONFIG_SYS_MALLOC_LEN SZ_512K /* malloc() arena */ +#define CONFIG_STACKSIZE (256 << 10) /* 256 KiB */ +#define CONFIG_SYS_MALLOC_LEN (1 << 20) /* 1 MiB*/ #define CONFIG_SYS_GBL_DATA_SIZE 128 /* for initial data */ #define CONFIG_SYS_MEMTEST_START 0x87000000 /* physical address */ #define CONFIG_SYS_MEMTEST_END 0x88000000 /* test 16MB RAM */ diff --git a/include/configs/davinci_dm365evm.h b/include/configs/davinci_dm365evm.h index 47cb554..72eccb9 100644 --- a/include/configs/davinci_dm365evm.h +++ b/include/configs/davinci_dm365evm.h @@ -18,7 +18,6 @@
#ifndef __CONFIG_H #define __CONFIG_H -#include <asm/sizes.h>
/* Spectrum Digital TMS320DM365 EVM board */ #define DAVINCI_DM365EVM @@ -38,7 +37,7 @@ /* Memory Info */ #define CONFIG_NR_DRAM_BANKS 1 #define PHYS_SDRAM_1 0x80000000 -#define PHYS_SDRAM_1_SIZE SZ_128M +#define PHYS_SDRAM_1_SIZE (128 << 20) /* 128 MiB */
/* Serial Driver info: UART0 for console */ #define CONFIG_SYS_NS16550 @@ -125,7 +124,7 @@ #define CONFIG_SYS_LONGHELP
#ifdef CONFIG_NAND_DAVINCI -#define CONFIG_ENV_SIZE SZ_256K +#define CONFIG_ENV_SIZE (256 << 10) /* 256 KiB */ #define CONFIG_ENV_IS_IN_NAND #define CONFIG_ENV_OFFSET 0x3C0000 #undef CONFIG_ENV_IS_IN_FLASH @@ -143,8 +142,8 @@ #define CONFIG_TIMESTAMP
/* U-Boot memory configuration */ -#define CONFIG_STACKSIZE SZ_256K /* regular stack */ -#define CONFIG_SYS_MALLOC_LEN SZ_1M /* malloc() arena */ +#define CONFIG_STACKSIZE (256 << 10) /* 256 KiB */ +#define CONFIG_SYS_MALLOC_LEN (1 << 20) /* 1 MiB */ #define CONFIG_SYS_GBL_DATA_SIZE 128 /* for initial data */ #define CONFIG_SYS_MEMTEST_START 0x87000000 /* physical address */ #define CONFIG_SYS_MEMTEST_END 0x88000000 /* test 16MB RAM */ diff --git a/include/configs/davinci_dvevm.h b/include/configs/davinci_dvevm.h index 96b6afc..af669bc 100644 --- a/include/configs/davinci_dvevm.h +++ b/include/configs/davinci_dvevm.h @@ -19,7 +19,6 @@
#ifndef __CONFIG_H #define __CONFIG_H -#include <asm/sizes.h>
/* * Define this to make U-Boot skip low level initialization when loaded @@ -120,7 +119,7 @@ #define CONFIG_ENV_IS_IN_NAND /* U-Boot env in NAND Flash */ #ifdef CONFIG_SYS_NAND_SMALLPAGE #define CONFIG_ENV_SECT_SIZE 512 /* Env sector Size */ -#define CONFIG_ENV_SIZE SZ_16K +#define CONFIG_ENV_SIZE (16 << 10) /* 16 KiB */ #define CONFIG_MTD_PARTITIONS #define CONFIG_CMD_MTDPARTS #define MTDIDS_DEFAULT \ @@ -129,7 +128,7 @@ "mtdparts=davinci_nand.0:384k(bootloader)ro,4m(kernel),-(filesystem)" #else #define CONFIG_ENV_SECT_SIZE 2048 /* Env sector Size */ -#define CONFIG_ENV_SIZE SZ_128K +#define CONFIG_ENV_SIZE (128 << 10) /* 128 KiB */ #endif #define CONFIG_SKIP_LOWLEVEL_INIT /* U-Boot is loaded by a bootloader */ #define CONFIG_SKIP_RELOCATE_UBOOT /* to a proper address, init done */ diff --git a/include/configs/davinci_schmoogie.h b/include/configs/davinci_schmoogie.h index 7909569..9384cdd 100644 --- a/include/configs/davinci_schmoogie.h +++ b/include/configs/davinci_schmoogie.h @@ -19,7 +19,6 @@
#ifndef __CONFIG_H #define __CONFIG_H -#include <asm/sizes.h>
/*=======*/ /* Board */ @@ -86,7 +85,7 @@ #define CONFIG_NAND_DAVINCI #define CONFIG_ENV_IS_IN_NAND /* U-Boot env in NAND Flash */ #define CONFIG_ENV_SECT_SIZE 2048 /* Env sector Size */ -#define CONFIG_ENV_SIZE SZ_128K +#define CONFIG_ENV_SIZE (128 << 10) /* 128 KiB */ #define CONFIG_SKIP_LOWLEVEL_INIT /* U-Boot is loaded by a bootloader */ #define CONFIG_SKIP_RELOCATE_UBOOT /* to a proper address, init done */ #define CONFIG_SYS_NAND_BASE 0x02000000 diff --git a/include/configs/davinci_sffsdr.h b/include/configs/davinci_sffsdr.h index 531baf1..71d48fb 100644 --- a/include/configs/davinci_sffsdr.h +++ b/include/configs/davinci_sffsdr.h @@ -22,7 +22,6 @@
#ifndef __CONFIG_H #define __CONFIG_H -#include <asm/sizes.h>
/* Board */ #define SFFSDR @@ -81,7 +80,7 @@ #define CONFIG_NAND_DAVINCI #define CONFIG_ENV_IS_IN_NAND /* U-Boot env in NAND Flash */ #define CONFIG_ENV_SECT_SIZE 2048 /* Env sector Size */ -#define CONFIG_ENV_SIZE SZ_128K +#define CONFIG_ENV_SIZE (128 << 10) /* 128 KiB */ #define CONFIG_SKIP_LOWLEVEL_INIT /* U-Boot is loaded by a bootloader */ #define CONFIG_SKIP_RELOCATE_UBOOT /* to a proper address, init done */ #define CONFIG_SYS_NAND_BASE 0x02000000 diff --git a/include/configs/davinci_sonata.h b/include/configs/davinci_sonata.h index 82901b3..5a55c56 100644 --- a/include/configs/davinci_sonata.h +++ b/include/configs/davinci_sonata.h @@ -19,7 +19,6 @@
#ifndef __CONFIG_H #define __CONFIG_H -#include <asm/sizes.h>
/* * Define this to make U-Boot skip low level initialization when loaded @@ -119,7 +118,7 @@ #define CONFIG_SYS_NO_FLASH #define CONFIG_ENV_IS_IN_NAND /* U-Boot env in NAND Flash */ #define CONFIG_ENV_SECT_SIZE 512 /* Env sector Size */ -#define CONFIG_ENV_SIZE SZ_16K +#define CONFIG_ENV_SIZE (16 << 10) /* 16 KiB */ #define CONFIG_SKIP_LOWLEVEL_INIT /* U-Boot is loaded by a bootloader */ #define CONFIG_SKIP_RELOCATE_UBOOT /* to a proper address, init done */ #define CONFIG_SYS_NAND_BASE 0x02000000
Dear s-paulraj@ti.com,
In message 1252434246-19517-1-git-send-email-s-paulraj@ti.com you wrote:
From: Sandeep Paulraj s-paulraj@ti.com
This patch removes the asm/sizes.h header file from being included in the DaVinci SOC configs. References to SZ_xx have been replaced by appropriate bit shifted values.
Signed-off-by: Sandeep Paulraj s-paulraj@ti.com
Note that this patch actually changes the configuration:
--- a/include/configs/davinci_dm355evm.h +++ b/include/configs/davinci_dm355evm.h
...
/* U-Boot memory configuration */ -#define CONFIG_STACKSIZE SZ_256K /* regular stack */ -#define CONFIG_SYS_MALLOC_LEN SZ_512K /* malloc() arena */ +#define CONFIG_STACKSIZE (256 << 10) /* 256 KiB */ +#define CONFIG_SYS_MALLOC_LEN (1 << 20) /* 1 MiB*/
as it increases the malloc() arena size form 512 to 1024 KiB.
Assuming this was done intentionally:
Acked-by: Wolfgang Denk wd@denx.de
Best regards,
Wolfgang Denk
-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: Tuesday, September 08, 2009 2:51 PM To: Paulraj, Sandeep Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx
Dear s-paulraj@ti.com,
In message 1252434246-19517-1-git-send-email-s-paulraj@ti.com you wrote:
From: Sandeep Paulraj s-paulraj@ti.com
This patch removes the asm/sizes.h header file from being included in the DaVinci SOC configs. References to SZ_xx have been replaced by appropriate bit shifted values.
Signed-off-by: Sandeep Paulraj s-paulraj@ti.com
Note that this patch actually changes the configuration:
--- a/include/configs/davinci_dm355evm.h +++ b/include/configs/davinci_dm355evm.h
...
/* U-Boot memory configuration */ -#define CONFIG_STACKSIZE SZ_256K /* regular stack */ -#define CONFIG_SYS_MALLOC_LEN SZ_512K /* malloc()
arena */
+#define CONFIG_STACKSIZE (256 << 10) /* 256 KiB */ +#define CONFIG_SYS_MALLOC_LEN (1 << 20) /* 1 MiB*/
as it increases the malloc() arena size form 512 to 1024 KiB.
Assuming this was done intentionally:
[Sandeep] Yes this was intentional because for NANDs with large block sizes(256 KiB), if this is not increased we will get "out of memory" errors.
Acked-by: Wolfgang Denk wd@denx.de
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Work 8 hours, sleep 8 hours; but not the same 8 hours.
Wolfgang,
Now how do I handle this? Should I make a next branch and push this patch to the next branch or push it directly to the master.
Assuming this was done intentionally:
[Sandeep] Yes this was intentional because for NANDs with large block sizes(256 KiB), if this is not increased we will get "out of memory" errors.
Acked-by: Wolfgang Denk wd@denx.de
Thanks, Sandeep
Dear Sandeep,
In message 0554BEF07D437848AF01B9C9B5F0BC5D92568101@dlee01.ent.ti.com you wrote:
Now how do I handle this? Should I make a next branch and push this patch to the next branch or push it directly to the master.
The merge window is open, so you can push this to master (and when you think enough patches have been stacked and/or time has come you send a pull request to Tom).
Best regards,
Wolfgang Denk
Paulraj, Sandeep wrote:
-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: Tuesday, September 08, 2009 2:51 PM To: Paulraj, Sandeep Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx
Dear s-paulraj@ti.com,
In message 1252434246-19517-1-git-send-email-s-paulraj@ti.com you wrote:
From: Sandeep Paulraj s-paulraj@ti.com
This patch removes the asm/sizes.h header file from being included in the DaVinci SOC configs. References to SZ_xx have been replaced by appropriate bit shifted values.
Signed-off-by: Sandeep Paulraj s-paulraj@ti.com
Note that this patch actually changes the configuration:
--- a/include/configs/davinci_dm355evm.h +++ b/include/configs/davinci_dm355evm.h
...
/* U-Boot memory configuration */ -#define CONFIG_STACKSIZE SZ_256K /* regular stack */ -#define CONFIG_SYS_MALLOC_LEN SZ_512K /* malloc()
arena */
+#define CONFIG_STACKSIZE (256 << 10) /* 256 KiB */ +#define CONFIG_SYS_MALLOC_LEN (1 << 20) /* 1 MiB*/
as it increases the malloc() arena size form 512 to 1024 KiB.
Assuming this was done intentionally:
[Sandeep] Yes this was intentional because for NANDs with large block sizes(256 KiB), if this is not increased we will get "out of memory" errors.
Acked-by: Wolfgang Denk wd@denx.de
Then this change needs to be a separate patch.
Nak Tom
Why is this change being made at all? Seems a lot more awkward to define (1 << 20) than SZ_1MB. SZ_1MB reads a lot easier.
--jc
On Tue, Sep 8, 2009 at 3:09 PM, Tom Tom.Rix@windriver.com wrote:
Paulraj, Sandeep wrote:
-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: Tuesday, September 08, 2009 2:51 PM To: Paulraj, Sandeep Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx
Dear s-paulraj@ti.com,
In message 1252434246-19517-1-git-send-email-s-paulraj@ti.com you
wrote:
From: Sandeep Paulraj s-paulraj@ti.com
This patch removes the asm/sizes.h header file from being included in the DaVinci SOC configs. References to SZ_xx have been replaced by appropriate bit shifted values.
Signed-off-by: Sandeep Paulraj s-paulraj@ti.com
Note that this patch actually changes the configuration:
--- a/include/configs/davinci_dm355evm.h +++ b/include/configs/davinci_dm355evm.h
...
/* U-Boot memory configuration */ -#define CONFIG_STACKSIZE SZ_256K /* regular stack */ -#define CONFIG_SYS_MALLOC_LEN SZ_512K /* malloc()
arena */
+#define CONFIG_STACKSIZE (256 << 10) /* 256 KiB */ +#define CONFIG_SYS_MALLOC_LEN (1 << 20) /* 1 MiB*/
as it increases the malloc() arena size form 512 to 1024 KiB.
Assuming this was done intentionally:
[Sandeep] Yes this was intentional because for NANDs with large block
sizes(256 KiB), if this is not increased we will get "out of memory" errors.
Acked-by: Wolfgang Denk wd@denx.de
Then this change needs to be a separate patch.
Nak Tom _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Jc,
Did you read what I wrote below the --- line in the patch itself?
Wolfgang wants to get rid of these references. He expressed this some time back. If he decides to get rid of this file altogether this will lead to compilation failures.
Thanks, Sandeep
________________________________ From: jcwren@gmail.com [mailto:jcwren@gmail.com] On Behalf Of J.C. Wren Sent: Tuesday, September 08, 2009 3:15 PM To: Tom Cc: Paulraj, Sandeep; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx
Why is this change being made at all? Seems a lot more awkward to define (1 << 20) than SZ_1MB. SZ_1MB reads a lot easier.
--jc On Tue, Sep 8, 2009 at 3:09 PM, Tom <Tom.Rix@windriver.commailto:Tom.Rix@windriver.com> wrote: Paulraj, Sandeep wrote:
-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.demailto:wd@denx.de] Sent: Tuesday, September 08, 2009 2:51 PM To: Paulraj, Sandeep Cc: u-boot@lists.denx.demailto:u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx
Dear s-paulraj@ti.commailto:s-paulraj@ti.com,
In message <1252434246-19517-1-git-send-email-s-paulraj@ti.commailto:1252434246-19517-1-git-send-email-s-paulraj@ti.com> you wrote:
From: Sandeep Paulraj <s-paulraj@ti.commailto:s-paulraj@ti.com>
This patch removes the asm/sizes.h header file from being included in the DaVinci SOC configs. References to SZ_xx have been replaced by appropriate bit shifted values.
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.commailto:s-paulraj@ti.com>
Note that this patch actually changes the configuration:
--- a/include/configs/davinci_dm355evm.h +++ b/include/configs/davinci_dm355evm.h
...
/* U-Boot memory configuration */ -#define CONFIG_STACKSIZE SZ_256K /* regular stack */ -#define CONFIG_SYS_MALLOC_LEN SZ_512K /* malloc()
arena */
+#define CONFIG_STACKSIZE (256 << 10) /* 256 KiB */ +#define CONFIG_SYS_MALLOC_LEN (1 << 20) /* 1 MiB*/
as it increases the malloc() arena size form 512 to 1024 KiB.
Assuming this was done intentionally:
[Sandeep] Yes this was intentional because for NANDs with large block sizes(256 KiB), if this is not increased we will get "out of memory" errors.
Acked-by: Wolfgang Denk <wd@denx.demailto:wd@denx.de>
Then this change needs to be a separate patch.
Nak Tom _______________________________________________ U-Boot mailing list U-Boot@lists.denx.demailto:U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
I saw this comment: "Also i gather from e-mails on the list that Wolfgang does not like these references to "SZ_xx". Maybe that discussion took place before I joined the list.
If he wants it that way, fine. But that doesn't explain the "why". What's so offensive about the SZ_* defines?
--jc
On Tue, Sep 8, 2009 at 3:20 PM, Paulraj, Sandeep s-paulraj@ti.com wrote:
Jc,
Did you read what I wrote below the --- line in the patch itself?
Wolfgang wants to get rid of these references. He expressed this some time back.
If he decides to get rid of this file altogether this will lead to compilation failures.
Thanks,
Sandeep
*From:* jcwren@gmail.com [mailto:jcwren@gmail.com] *On Behalf Of *J.C. Wren *Sent:* Tuesday, September 08, 2009 3:15 PM *To:* Tom *Cc:* Paulraj, Sandeep; u-boot@lists.denx.de
*Subject:* Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx
Why is this change being made at all? Seems a lot more awkward to define (1 << 20) than SZ_1MB. SZ_1MB reads a lot easier.
--jc
On Tue, Sep 8, 2009 at 3:09 PM, Tom Tom.Rix@windriver.com wrote:
Paulraj, Sandeep wrote:
-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: Tuesday, September 08, 2009 2:51 PM To: Paulraj, Sandeep Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx
Dear s-paulraj@ti.com,
In message 1252434246-19517-1-git-send-email-s-paulraj@ti.com you
wrote:
From: Sandeep Paulraj s-paulraj@ti.com
This patch removes the asm/sizes.h header file from being included in the DaVinci SOC configs. References to SZ_xx have been replaced by appropriate bit shifted values.
Signed-off-by: Sandeep Paulraj s-paulraj@ti.com
Note that this patch actually changes the configuration:
--- a/include/configs/davinci_dm355evm.h +++ b/include/configs/davinci_dm355evm.h
...
/* U-Boot memory configuration */ -#define CONFIG_STACKSIZE SZ_256K /* regular stack */ -#define CONFIG_SYS_MALLOC_LEN SZ_512K /* malloc()
arena */
+#define CONFIG_STACKSIZE (256 << 10) /* 256 KiB */ +#define CONFIG_SYS_MALLOC_LEN (1 << 20) /* 1 MiB*/
as it increases the malloc() arena size form 512 to 1024 KiB.
Assuming this was done intentionally:
[Sandeep] Yes this was intentional because for NANDs with large block
sizes(256 KiB), if this is not increased we will get "out of memory" errors.
Acked-by: Wolfgang Denk wd@denx.de
Then this change needs to be a separate patch.
Nak Tom
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Jc,
Wolfgang is the best person to answer your question.
Also read this http://lists.denx.de/pipermail/u-boot/2009-September/059794.html
The way I look at things, any new patches or files with such references are going to get comments from him.
I will be submitting patches based on his suggestion above so just removing such references to make things consistent across all DaVinci SOCs.
As I said before if the concerned header files are removed at least DaVinci SOCs will not be affected.
Thanks, Sandeep
________________________________ From: jcwren@gmail.com [mailto:jcwren@gmail.com] On Behalf Of J.C. Wren Sent: Tuesday, September 08, 2009 3:28 PM To: Paulraj, Sandeep Cc: Tom; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx
I saw this comment: "Also i gather from e-mails on the list that Wolfgang does not like these references to "SZ_xx". Maybe that discussion took place before I joined the list.
If he wants it that way, fine. But that doesn't explain the "why". What's so offensive about the SZ_* defines?
--jc On Tue, Sep 8, 2009 at 3:20 PM, Paulraj, Sandeep <s-paulraj@ti.commailto:s-paulraj@ti.com> wrote:
Jc,
Did you read what I wrote below the --- line in the patch itself?
Wolfgang wants to get rid of these references. He expressed this some time back.
If he decides to get rid of this file altogether this will lead to compilation failures.
Thanks,
Sandeep
________________________________
From: jcwren@gmail.commailto:jcwren@gmail.com [mailto:jcwren@gmail.commailto:jcwren@gmail.com] On Behalf Of J.C. Wren Sent: Tuesday, September 08, 2009 3:15 PM To: Tom Cc: Paulraj, Sandeep; u-boot@lists.denx.demailto:u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx
Why is this change being made at all? Seems a lot more awkward to define (1 << 20) than SZ_1MB. SZ_1MB reads a lot easier.
--jc
On Tue, Sep 8, 2009 at 3:09 PM, Tom <Tom.Rix@windriver.commailto:Tom.Rix@windriver.com> wrote:
Paulraj, Sandeep wrote:
-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.demailto:wd@denx.de] Sent: Tuesday, September 08, 2009 2:51 PM To: Paulraj, Sandeep Cc: u-boot@lists.denx.demailto:u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx
Dear s-paulraj@ti.commailto:s-paulraj@ti.com,
In message <1252434246-19517-1-git-send-email-s-paulraj@ti.commailto:1252434246-19517-1-git-send-email-s-paulraj@ti.com> you wrote:
From: Sandeep Paulraj <s-paulraj@ti.commailto:s-paulraj@ti.com>
This patch removes the asm/sizes.h header file from being included in the DaVinci SOC configs. References to SZ_xx have been replaced by appropriate bit shifted values.
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.commailto:s-paulraj@ti.com>
Note that this patch actually changes the configuration:
--- a/include/configs/davinci_dm355evm.h +++ b/include/configs/davinci_dm355evm.h
...
/* U-Boot memory configuration */ -#define CONFIG_STACKSIZE SZ_256K /* regular stack */ -#define CONFIG_SYS_MALLOC_LEN SZ_512K /* malloc()
arena */
+#define CONFIG_STACKSIZE (256 << 10) /* 256 KiB */ +#define CONFIG_SYS_MALLOC_LEN (1 << 20) /* 1 MiB*/
as it increases the malloc() arena size form 512 to 1024 KiB.
Assuming this was done intentionally:
[Sandeep] Yes this was intentional because for NANDs with large block sizes(256 KiB), if this is not increased we will get "out of memory" errors.
Acked-by: Wolfgang Denk <wd@denx.demailto:wd@denx.de>
Then this change needs to be a separate patch.
Nak Tom
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.demailto:U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
J.C. Wren wrote:
I saw this comment: "Also i gather from e-mails on the list that Wolfgang does not like these references to "SZ_xx". Maybe that discussion took place before I joined the list.
If he wants it that way, fine. But that doesn't explain the "why". What's so offensive about the SZ_* defines?
--jc
Hi J.C.,
The SZ_* defines turns a simple math problem into a two finger problem... every time you see them, you need to put your finger in the code and look them up, only to find (1 << n), have to stick a second finger in the code, and have to do the math anyway.
One REALLY BAD problem is that idiots have been known to mis-define them rather than fix the code that uses them (seriously!). By using (1 << 20) directly, it removes that temptation.
A lesser problem is that they don't do anything, you still have to figure out that 1 << 20 is 1MiB. All they do is defer the pain.
You will also find other silliness, e.g. generating SZ_31M: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/27048/focus=27139 This silliness is the road to insanity: SZ_30M and SZ_29M and SZ_28.125M. (OK, I exaggerated on that last one. It would actually be SZ_28_125M.)
HTH, gvb
[snip]
On Tue, Sep 8, 2009 at 4:07 PM, Jerry Van Baren gerald.vanbaren@ge.comwrote:
J.C. Wren wrote:
I saw this comment: "Also i gather from e-mails on the list that Wolfgang does not like these references to "SZ_xx". Maybe that discussion took place before I joined the list.
If he wants it that way, fine. But that doesn't explain the "why". What's so offensive about the SZ_* defines?
--jc
Hi J.C.,
The SZ_* defines turns a simple math problem into a two finger problem... every time you see them, you need to put your finger in the code and look them up, only to find (1 << n), have to stick a second finger in the code, and have to do the math anyway.
One REALLY BAD problem is that idiots have been known to mis-define them rather than fix the code that uses them (seriously!). By using (1 << 20) directly, it removes that temptation.
A lesser problem is that they don't do anything, you still have to figure out that 1 << 20 is 1MiB. All they do is defer the pain.
You will also find other silliness, e.g. generating SZ_31M: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/27048/focus=27139 This silliness is the road to insanity: SZ_30M and SZ_29M and SZ_28.125M. (OK, I exaggerated on that last one. It would actually be SZ_28_125M.)
HTH, gvb
[snip]
Excellent explanation. Thank you.
I do like this (from the email link): (31 * 1024 * 1024). And it appears not to give Wolfgang indigestion :)
--jc
Dear "J.C. Wren",
In message 17434f2e0909081312r3fe4523ej66ed4fc0275fa148@mail.gmail.com you wrote:
Excellent explanation. Thank you.
Indeed. Thanks to gvb.
I'd just like to add that you also never know if SZ_1M is 1024*1024 or 1000*1000.
I do like this (from the email link): (31 * 1024 * 1024). And it appears not to give Wolfgang indigestion :)
It is probably the preferred form in many cases, line length permitting :-) "31 << 20" is a bit shorter, but it's just a personal preference, not something I consider better in any way.
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
Dear "J.C. Wren",
In message 17434f2e0909081312r3fe4523ej66ed4fc0275fa148@mail.gmail.com you wrote:
Excellent explanation. Thank you.
Indeed. Thanks to gvb.
I'd just like to add that you also never know if SZ_1M is 1024*1024 or 1000*1000.
I do like this (from the email link): (31 * 1024 * 1024). And it appears not to give Wolfgang indigestion :)
It is probably the preferred form in many cases, line length permitting :-) "31 << 20" is a bit shorter, but it's just a personal
s/3// ;-)
preference, not something I consider better in any way.
Best regards,
Wolfgang Denk
Another objection: Company A makes their favorite SZ_* defines but Company B defines them as SIZE_* but Company C defines them as...
...and we end up with the same mess as INT32 vs. WORD vs. int32_t defines (C99 tackled that, finally, but not all the mess has been cleaned up yet, 10 years later).
Best regards, gvb
Dear Jerry Van Baren,
In message 4AA6C913.7000004@ge.com you wrote:
I'd just like to add that you also never know if SZ_1M is 1024*1024 or 1000*1000.
I do like this (from the email link): (31 * 1024 * 1024). And it appears not to give Wolfgang indigestion :)
It is probably the preferred form in many cases, line length permitting :-) "31 << 20" is a bit shorter, but it's just a personal
s/3// ;-)
No. I intended to state that "31 << 20" is a bit shorter than "(31 * 1024 * 1024)".
With your substitution, it would also be much less :-)
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
Dear Jerry Van Baren,
In message 4AA6C913.7000004@ge.com you wrote:
I'd just like to add that you also never know if SZ_1M is 1024*1024 or 1000*1000.
I do like this (from the email link): (31 * 1024 * 1024). And it appears not to give Wolfgang indigestion :)
It is probably the preferred form in many cases, line length permitting :-) "31 << 20" is a bit shorter, but it's just a personal
s/3// ;-)
No. I intended to state that "31 << 20" is a bit shorter than "(31 * 1024 * 1024)".
With your substitution, it would also be much less :-)
D'OH! Indeed. My "thinko", not your typo. :-D I already have the glasses, maybe I need contacts too. ;-)
Best regards,
Wolfgang Denk
gvb
participants (7)
-
J.C. Wren -
Jerry Van Baren -
Jerry Van Baren -
Paulraj, Sandeep -
s-paulraj＠ti.com
-
Tom -
Wolfgang Denk