[U-Boot] [PATCH 0/5] feature additions and fixes for da830

[U-Boot] [PATCH 0/5] feature additions and fixes for da830

[nagabhushana.netagunte at ti.com]

From: Nagabhushana netagunte <nagabhushana.netagunte@ti.com>

These set of patches enable some features and have some 
minor fixes for da830.

Nagabhushana Netagunte (5):
  da830: disable cache usage due to coherency issues
  da830: enable SPI flash boot mode
  da830: add support for NAND boot mode
  da830: modify the U-Boot prompt string
  da830: modify the MEMTEST start and end address

 board/davinci/da8xxevm/da830evm.c |   63 +++++++++++++++++++++++++++++++++++++
 include/configs/da830evm.h        |   26 +++++++++------
 2 files changed, 79 insertions(+), 10 deletions(-)

[U-Boot] [PATCH 1/5] da830: disable cache usage due to coherency issues

[nagabhushana.netagunte at ti.com]

From: Nagabhushana Netagunte <nagabhushana.netagunte@ti.com>

there are cache coherency issues when using the DAVINCI Ethernet driver,
hence caches cant be used for da830 u-boot. As per new cache management
framework,if the caches are not used in u-boot, it needs to be explicitly
indicated through macros in config file. CACHE disable is  indicated by
the following macro definitions in config file,

1. CONFIG_SYS_ICACHE_OFF
2. CONFIG_SYS_DCACHE_OFF
3. CONFIG_SYS_L2CACHE_OFF

Signed-off-by: Nagabhushana Netagunte <nagabhushana.netagunte@ti.com>
---
 include/configs/da830evm.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/include/configs/da830evm.h b/include/configs/da830evm.h
index bcf8ee0..da7d528 100644
--- a/include/configs/da830evm.h
+++ b/include/configs/da830evm.h
@@ -42,6 +42,9 @@
 #define CONFIG_SYS_HZ			1000
 #define CONFIG_SKIP_LOWLEVEL_INIT
 #define CONFIG_SYS_TEXT_BASE		0xc1080000
+#define CONFIG_SYS_ICACHE_OFF
+#define CONFIG_SYS_DCACHE_OFF
+#define CONFIG_SYS_L2CACHE_OFF
 
 /*
  * Memory Info
-- 
1.6.2.4

[U-Boot] [PATCH 1/5] da830: disable cache usage due to coherency issues

[Mike Frysinger]

On Tuesday, August 30, 2011 08:15:56 nagabhushana.netagunte at ti.com wrote:
> there are cache coherency issues when using the DAVINCI Ethernet driver,
> hence caches cant be used for da830 u-boot.

why not fix the davinci eth driver ?
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110830/684dc505/attachment.pgp 

[U-Boot] [PATCH 1/5] da830: disable cache usage due to coherency issues

[Netagunte, Nagabhushana]

Mike,

We will address cache coherency issues soon after these patches.
Earlier also, chache was disabled. Only due to new cache management Framework which was added recently, it is explicitly needed to be indicated to turn off cache. 

Since fixing the cache coherency issues with EMAC will take some time, I want this patch to go in mainline so that issue doesn't crop up for People who use u-boot.

Regards,
Nag

On Tue, Aug 30, 2011 at 20:45:58, Mike Frysinger wrote:
> On Tuesday, August 30, 2011 08:15:56 nagabhushana.netagunte at ti.com wrote:
> > there are cache coherency issues when using the DAVINCI Ethernet 
> > driver, hence caches cant be used for da830 u-boot.
> 
> why not fix the davinci eth driver ?
> -mike
> 

[U-Boot] [PATCH 1/5] da830: disable cache usage due to coherency issues

[Nick Thompson]

On 31/08/11 06:40, Netagunte, Nagabhushana wrote:
> Mike,
>
> We will address cache coherency issues soon after these patches.
> Earlier also, chache was disabled. Only due to new cache management Framework which was added recently, it is explicitly needed to be indicated to turn off cache. 
>
> Since fixing the cache coherency issues with EMAC will take some time, I want this patch to go in mainline so that issue doesn't crop up for People who use u-boot.
>
> Regards,
> Nag
>

Which device(s) does this occur on? I have a lot of OMAP-L137 (EVM and custom) boards with cache enabled and no problems tftp'ing the kernel.

On the other hand tftp and kernel CRC checking are much faster with cache enabled.

Nick.

[U-Boot] [PATCH 1/5] da830: disable cache usage due to coherency issues

[Netagunte, Nagabhushana]

Nick,

I am seeing this issue on da830/da850/dm36x/dm644x.

I agree that u-boot will be faster with cache enabled. And also, TI wants it to be enabled soon. Since so many patches are lined u, we don't up-streaming them to get hampered because of this issue. So, we are trying to push this 
Patch. We are committed come up with appropriate patch to fix the EMAC and coherency issue. 

Meanwhile, we are trying to gather info about earlier patch/changes which disabled cache so that community understands the known issue.

Also, one more engineer observed the issue with EMAC, I will send his mail to you. 

Regards,
Nag
On Wed, Aug 31, 2011 at 15:09:35, Nick Thompson wrote:
> On 31/08/11 06:40, Netagunte, Nagabhushana wrote:
> > Mike,
> >
> > We will address cache coherency issues soon after these patches.
> > Earlier also, chache was disabled. Only due to new cache management Framework which was added recently, it is explicitly needed to be indicated to turn off cache. 
> >
> > Since fixing the cache coherency issues with EMAC will take some time, I want this patch to go in mainline so that issue doesn't crop up for People who use u-boot.
> >
> > Regards,
> > Nag
> >
> 
> Which device(s) does this occur on? I have a lot of OMAP-L137 (EVM and custom) boards with cache enabled and no problems tftp'ing the kernel.
> 
> On the other hand tftp and kernel CRC checking are much faster with cache enabled.
> 
> Nick.
> 

[U-Boot] [PATCH 1/5] da830: disable cache usage due to coherency issues

[Nick Thompson]

On 14/09/11 06:54, Netagunte, Nagabhushana wrote:
> Nick,
>
> I am seeing this issue on da830/da850/dm36x/dm644x.

Strange that I have seen no issue with da830 (OMAP-L137 v1.0 & v1.1 - don't have any v2.0 yet) when tftp'ing the kernel. I do get very occasional errors, but have put this down to network packet loss.

The v1.0 and v1.1 parts do have a d-cache errata, so we only get to use the d-cache in write through mode. This would mean that TCP packet data writes by the processor would never have a coherency problem. Reads could still have an issue, but I think the explanation provided so far referred to TCP packet sending...?

This vintage of da830 will always have to use write trough mode, so there should be no issue...?

> I agree that u-boot will be faster with cache enabled. And also, TI wants it to be enabled soon. Since so many patches are lined u, we don't up-streaming them to get hampered because of this issue. So, we are trying to push this 
> Patch. We are committed come up with appropriate patch to fix the EMAC and coherency issue. 
>
> Meanwhile, we are trying to gather info about earlier patch/changes which disabled cache so that community understands the known issue.

Boot time is critical to us. I can't ship without cache enabled. I can use my own _config.h of course to work around it I think, but I don't understand why you think there is an issue to fix on da830 yet. With a working d-cache I can imagine such a problem though.

> Also, one more engineer observed the issue with EMAC, I will send his mail to you. 
>
> Regards,
> Nag
> On Wed, Aug 31, 2011 at 15:09:35, Nick Thompson wrote:
>> On 31/08/11 06:40, Netagunte, Nagabhushana wrote:
>>> Mike,
>>>
>>> We will address cache coherency issues soon after these patches.
>>> Earlier also, chache was disabled. Only due to new cache management Framework which was added recently, it is explicitly needed to be indicated to turn off cache. 
>>>
>>> Since fixing the cache coherency issues with EMAC will take some time, I want this patch to go in mainline so that issue doesn't crop up for People who use u-boot.
>>>
>>> Regards,
>>> Nag
>>>
>> Which device(s) does this occur on? I have a lot of OMAP-L137 (EVM and custom) boards with cache enabled and no problems tftp'ing the kernel.
>>
>> On the other hand tftp and kernel CRC checking are much faster with cache enabled.
>>
>> Nick.
>>

[U-Boot] [PATCH 1/5] da830: disable cache usage due to coherency issues

[Tom Rini]

On Wed, Sep 14, 2011 at 4:07 AM, Nick Thompson <nick.thompson@ge.com> wrote:
> On 14/09/11 06:54, Netagunte, Nagabhushana wrote:
>> Nick,
>>
>> I am seeing this issue on da830/da850/dm36x/dm644x.
>
> Strange that I have seen no issue with da830 (OMAP-L137 v1.0 & v1.1 - don't have any v2.0 yet) when tftp'ing the kernel. I do get very occasional errors, but have put this down to network packet loss.

Note that when there is a problem, there's no network activity.  I'd
seen this on a dm365evm, but don't have the board handy (nor did I
note the exact rev of the one I had at the time, sadly).

-- 
Tom

[U-Boot] [PATCH 1/5] da830: disable cache usage due to coherency issues

[Netagunte, Nagabhushana]

Tom,

Thanks! I had a conversation with engineer who came up with new cache management framework. Looks like he has provided patch which fixes this
Issue which got exposed because of his patches. I will test this patch 
Tomorrow and confirm. Most probably, we don't need this patch.

Regards,
Nag

On Wed, Sep 14, 2011 at 19:35:47, Tom Rini wrote:
> On Wed, Sep 14, 2011 at 4:07 AM, Nick Thompson <nick.thompson@ge.com> wrote:
> > On 14/09/11 06:54, Netagunte, Nagabhushana wrote:
> >> Nick,
> >>
> >> I am seeing this issue on da830/da850/dm36x/dm644x.
> >
> > Strange that I have seen no issue with da830 (OMAP-L137 v1.0 & v1.1 - don't have any v2.0 yet) when tftp'ing the kernel. I do get very occasional errors, but have put this down to network packet loss.
> 
> Note that when there is a problem, there's no network activity.  I'd seen this on a dm365evm, but don't have the board handy (nor did I note the exact rev of the one I had at the time, sadly).
> 
> --
> Tom
> 

[U-Boot] [PATCH 1/5] da830: disable cache usage due to coherency issues

[Mike Frysinger]

On Wednesday, August 31, 2011 01:40:26 Netagunte, Nagabhushana wrote:
> We will address cache coherency issues soon after these patches.
> Earlier also, chache was disabled. Only due to new cache management
> Framework which was added recently, it is explicitly needed to be
> indicated to turn off cache.
> 
> Since fixing the cache coherency issues with EMAC will take some time, I
> want this patch to go in mainline so that issue doesn't crop up for People
> who use u-boot.

please add something like this to your emac driver then:
#ifndef CONFIG_SYS_DCACHE_OFF
# error "this driver sucks: define CONFIG_SYS_DCACHE_OFF until it is fixed"
#endif
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110831/f01d547b/attachment.pgp 

[U-Boot] [PATCH 2/5] da830: enable SPI flash boot mode

[nagabhushana.netagunte at ti.com]

From: Nagabhushana Netagunte <nagabhushana.netagunte@ti.com>

Enable SPI flash boot mode in configuration file as default.
With the introduction of 456MHz part, SPI operating frequency
will increase and at this frequency SPI does not work correctly.
Hence reduce the default SPI speed to 30MHz from 50MHz.

Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: Nagabhushana Netagunte <nagabhushana.netagunte@ti.com>
---
 include/configs/da830evm.h |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/include/configs/da830evm.h b/include/configs/da830evm.h
index da7d528..13c3494 100644
--- a/include/configs/da830evm.h
+++ b/include/configs/da830evm.h
@@ -28,6 +28,7 @@
  * Board
  */
 #define CONFIG_DRIVER_TI_EMAC
+#define CONFIG_USE_SPIFLASH
 
 /*
  * SoC Configuration
@@ -148,8 +149,8 @@
 #define CONFIG_DAVINCI_SPI
 #define CONFIG_SYS_SPI_BASE		DAVINCI_SPI0_BASE
 #define CONFIG_SYS_SPI_CLK		clk_get(DAVINCI_SPI0_CLKID)
-#define CONFIG_SF_DEFAULT_SPEED		50000000
-#define CONFIG_SYS_ENV_SPI_MAX_HZ	CONFIG_SF_DEFAULT_SPEED
+#define CONFIG_SF_DEFAULT_SPEED		30000000
+#define CONFIG_ENV_SPI_MAX_HZ		CONFIG_SF_DEFAULT_SPEED
 #endif
 
 /*
@@ -204,7 +205,6 @@
 #define CONFIG_CMD_MEMORY
 #undef CONFIG_CMD_FPGA
 #undef CONFIG_CMD_SETGETDCR
-#define CONFIG_CMD_EEPROM
 
 #ifndef CONFIG_DRIVER_TI_EMAC
 #undef CONFIG_CMD_NET
@@ -226,6 +226,7 @@
 #undef CONFIG_CMD_IMLS
 #undef CONFIG_CMD_FLASH
 #define CONFIG_CMD_SPI
+#define CONFIG_CMD_SF
 #define CONFIG_CMD_SAVEENV
 #endif
 
-- 
1.6.2.4

[U-Boot] [PATCH 3/5] da830: add support for NAND boot mode

[nagabhushana.netagunte at ti.com]

From: Nagabhushana Netagunte <nagabhushana.netagunte@ti.com>

Add support for enabling NAND boot mode in configuration file and
add correspanding pinmux support, nand initialize function in board file.
Since the environment variable are stored in first block
CONFIG_ENV_OFFSET is set to offset 0 from (512 << 10) and also the
size required for environment variables not more than 10KB
the CONFIG_ENV_SIZE is set to 10KB from (512 << 10).

Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: Nagabhushana Netagunte <nagabhushana.netagunte@ti.com>
---
 board/davinci/da8xxevm/da830evm.c |   63 +++++++++++++++++++++++++++++++++++++
 include/configs/da830evm.h        |    6 ++-
 2 files changed, 67 insertions(+), 2 deletions(-)

diff --git a/board/davinci/da8xxevm/da830evm.c b/board/davinci/da8xxevm/da830evm.c
index 0650653..2021e73 100644
--- a/board/davinci/da8xxevm/da830evm.c
+++ b/board/davinci/da8xxevm/da830evm.c
@@ -40,6 +40,8 @@
 #include <asm/arch/emif_defs.h>
 #include <asm/arch/emac_defs.h>
 #include <asm/io.h>
+#include <nand.h>
+#include <asm/arch/nand_defs.h>
 #include <asm/arch/davinci_misc.h>
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -98,6 +100,56 @@ static const struct pinmux_config i2c_pins[] = {
 	{ pinmux(8), 2, 4 }
 };
 
+#ifdef CONFIG_USE_NAND
+/* NAND pin muxer settings */
+const struct pinmux_config aemif_pins[] = {
+	{ pinmux(13), 1, 6 },
+	{ pinmux(13), 1, 7 },
+	{ pinmux(14), 1, 0 },
+	{ pinmux(14), 1, 1 },
+	{ pinmux(14), 1, 2 },
+	{ pinmux(14), 1, 3 },
+	{ pinmux(14), 1, 4 },
+	{ pinmux(14), 1, 5 },
+	{ pinmux(14), 1, 6 },
+	{ pinmux(14), 1, 7 },
+	{ pinmux(15), 1, 0 },
+	{ pinmux(15), 1, 1 },
+	{ pinmux(15), 1, 2 },
+	{ pinmux(15), 1, 3 },
+	{ pinmux(15), 1, 4 },
+	{ pinmux(15), 1, 5 },
+	{ pinmux(15), 1, 6 },
+	{ pinmux(15), 1, 7 },
+	{ pinmux(16), 1, 0 },
+	{ pinmux(16), 1, 1 },
+	{ pinmux(16), 1, 2 },
+	{ pinmux(16), 1, 3 },
+	{ pinmux(16), 1, 4 },
+	{ pinmux(16), 1, 5 },
+	{ pinmux(16), 1, 6 },
+	{ pinmux(16), 1, 7 },
+	{ pinmux(17), 1, 0 },
+	{ pinmux(17), 1, 1 },
+	{ pinmux(17), 1, 2 },
+	{ pinmux(17), 1, 3 },
+	{ pinmux(17), 1, 4 },
+	{ pinmux(17), 1, 5 },
+	{ pinmux(17), 1, 6 },
+	{ pinmux(17), 1, 7 },
+	{ pinmux(18), 1, 0 },
+	{ pinmux(18), 1, 1 },
+	{ pinmux(18), 1, 2 },
+	{ pinmux(18), 1, 3 },
+	{ pinmux(18), 1, 4 },
+	{ pinmux(18), 1, 5 },
+	{ pinmux(18), 1, 6 },
+	{ pinmux(18), 1, 7 },
+	{ pinmux(10), 1, 0 }
+};
+#endif
+
+
 /* USB0_DRVVBUS pin muxer settings */
 static const struct pinmux_config usb_pins[] = {
 	{ pinmux(9), 1, 1 }
@@ -114,6 +166,7 @@ static const struct pinmux_resource pinmuxes[] = {
 #endif
 #ifdef CONFIG_USE_NAND
 	PINMUX_ITEM(emifa_nand_pins),
+	PINMUX_ITEM(aemif_pins),
 #endif
 #if defined(CONFIG_DRIVER_TI_EMAC)
 	PINMUX_ITEM(emac_pins),
@@ -184,6 +237,16 @@ int board_init(void)
 	return(0);
 }
 
+
+#ifdef CONFIG_NAND_DAVINCI
+int board_nand_init(struct nand_chip *nand)
+{
+	davinci_nand_init(nand);
+
+	return 0;
+}
+#endif
+
 #if defined(CONFIG_DRIVER_TI_EMAC)
 
 #define PHY_SW_I2C_ADDR	0x5f /* Address of PHY on i2c bus */
diff --git a/include/configs/da830evm.h b/include/configs/da830evm.h
index 13c3494..4d50734 100644
--- a/include/configs/da830evm.h
+++ b/include/configs/da830evm.h
@@ -107,9 +107,11 @@
 #define CONFIG_NAND_DAVINCI
 #define CONFIG_SYS_NO_FLASH
 #define CONFIG_ENV_IS_IN_NAND		/* U-Boot env in NAND Flash  */
-#define CONFIG_ENV_OFFSET		(512 << 10)
-#define CONFIG_ENV_SIZE			(512 << 10)
+#define CONFIG_ENV_OFFSET		0x0 /* Block 0--not used by bootcode */
+#define CONFIG_ENV_SIZE			(10 << 10) /* 10KB */
+#define CONFIG_SYS_NAND_USE_FLASH_BBT
 #define CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST
+#define CONFIG_SYS_NAND_PAGE_2K
 #define CONFIG_SYS_NAND_CS		3
 #define CONFIG_SYS_NAND_BASE		DAVINCI_ASYNC_EMIF_DATA_CE3_BASE
 #define CONFIG_SYS_NAND_PAGE_2K
-- 
1.6.2.4

[U-Boot] [PATCH 3/5] da830: add support for NAND boot mode

[Nick Thompson]

On 30/08/11 13:15, nagabhushana.netagunte at ti.com wrote:
> From: Nagabhushana Netagunte <nagabhushana.netagunte@ti.com>
>
> Add support for enabling NAND boot mode in configuration file and
> add correspanding pinmux support, nand initialize function in board file.
> Since the environment variable are stored in first block

My environment variables are not stored in the first block. Where does your
assumption stem from?

If I use this patch on my boards here, they will all "loose" their environment.

By moving env you are creating a compatibility issue for boards that already
use NAND.

> CONFIG_ENV_OFFSET is set to offset 0 from (512 << 10) and also the
> size required for environment variables not more than 10KB
> the CONFIG_ENV_SIZE is set to 10KB from (512 << 10).
>

[U-Boot] [PATCH 3/5] da830: add support for NAND boot mode

[Netagunte, Nagabhushana]

I am just curious, since this patch adds NAND boot mode for the
First time in denx git, how this affects you? Are you storing
ENV variables in NAND during some other boot mode? In fact we are
Adding other boot mode in this patch set. How come you are using
Denx tree to flash bios on your da830 board?

Regards,
Nag

On Wed, Aug 31, 2011 at 14:26:42, Nick Thompson wrote:
> On 30/08/11 13:15, nagabhushana.netagunte at ti.com wrote:
> > From: Nagabhushana Netagunte <nagabhushana.netagunte@ti.com>
> >
> > Add support for enabling NAND boot mode in configuration file and add 
> > correspanding pinmux support, nand initialize function in board file.
> > Since the environment variable are stored in first block
> 
> My environment variables are not stored in the first block. Where does your assumption stem from?
> 
> If I use this patch on my boards here, they will all "loose" their environment.
> 
> By moving env you are creating a compatibility issue for boards that already use NAND.
> 
> > CONFIG_ENV_OFFSET is set to offset 0 from (512 << 10) and also the 
> > size required for environment variables not more than 10KB the 
> > CONFIG_ENV_SIZE is set to 10KB from (512 << 10).
> >
> 
> 

[U-Boot] [PATCH 3/5] da830: add support for NAND boot mode

[Nick Thompson]

On 05/09/11 09:26, Netagunte, Nagabhushana wrote:
> I am just curious, since this patch adds NAND boot mode for the
> First time in denx git, how this affects you? Are you storing
> ENV variables in NAND during some other boot mode? In fact we are
> Adding other boot mode in this patch set. How come you are using
> Denx tree to flash bios on your da830 board?
>
> Regards,
> Nag

We use SPI boot to load dspais and then a modified UBL from FLASH. Our
UBL is then capable of loading u-boot from either SPI or NAND depending
on a switch setting. Both U-Boot images can be different or the same.

Either way the env settings are in nand. U-boot can already handle NAND
env if configured correctly.

U-Boot already has NAND support too of course and can load the kernel
from a variety of sources, including NAND. 'nboot' and 'nand read' can
both be used for that.

All the above can work on da830evm with a NAND board connected to
the expansion bus connectors. Nothing has changed in U-Boot other
than in our (not yet published) _config file.

Defining CONFIG_USE_NAND in there is enough to turn NAND support on
and our UBL configures *all* the pinmuxes fof the board. Using the UBL
always used to be the TI recommended way to configure pinmuxes AFAIK.

Of course pinmux set up can also be added in the board file, though we
have not bothered, since UBL *must* have already done it if it loads
U-Boot from NAND.

Note that the end of the config file also has:

#ifdef CONFIG_MTD_PARTITIONS
#define MTDIDS_DEFAULT        "nand0=davinci_nand.1"
#define PART_BOOT        "512k(bootloader)ro,"
#define PART_PARAMS        "512k(params)ro,"
#define PART_KERNEL        "4m(kernel),"
#define PART_REST        "-(filesystem)"
#define MTDPARTS_DEFAULT        \
    "mtdparts=davinci_nand.1:" PART_BOOT PART_PARAMS PART_KERNEL PART_REST
#endif

...where params is (for U-Boot) used for env and bootloader typically
relates to U-Boot.

I don't know what 'bios' refers to in your question. I'm also a bit unsure
what you mean by 'adds NAND boot mode for the first time', given that
the processor boot mode has little say on where U-Boot or Linux are
loaded from and we've been using standard U-Boot features to load data
from NAND for nearly two years now.

Nick.

> On Wed, Aug 31, 2011 at 14:26:42, Nick Thompson wrote:
>> On 30/08/11 13:15, nagabhushana.netagunte at ti.com wrote:
>>> From: Nagabhushana Netagunte <nagabhushana.netagunte@ti.com>
>>>
>>> Add support for enabling NAND boot mode in configuration file and add 
>>> correspanding pinmux support, nand initialize function in board file.
>>> Since the environment variable are stored in first block
>> My environment variables are not stored in the first block. Where does your assumption stem from?
>>
>> If I use this patch on my boards here, they will all "loose" their environment.
>>
>> By moving env you are creating a compatibility issue for boards that already use NAND.
>>
>>> CONFIG_ENV_OFFSET is set to offset 0 from (512 << 10) and also the 
>>> size required for environment variables not more than 10KB the 
>>> CONFIG_ENV_SIZE is set to 10KB from (512 << 10).
>>>
>>

[U-Boot] [PATCH 3/5] da830: add support for NAND boot mode

[Netagunte, Nagabhushana]

Nick,

Thanks for details about UBL's role in this case. We will look at this
And come back with appropriate patch.

Sudhakar,

Please consider this mail. This talks about UBL's role in configuring 
2nd block of NAND for ENV variables.

Thanks,
Nag 

On Mon, Sep 05, 2011 at 14:47:17, Nick Thompson wrote:
> On 05/09/11 09:26, Netagunte, Nagabhushana wrote:
> > I am just curious, since this patch adds NAND boot mode for the First 
> > time in denx git, how this affects you? Are you storing ENV variables 
> > in NAND during some other boot mode? In fact we are Adding other boot 
> > mode in this patch set. How come you are using Denx tree to flash bios 
> > on your da830 board?
> >
> > Regards,
> > Nag
> 
> We use SPI boot to load dspais and then a modified UBL from FLASH. Our UBL is then capable of loading u-boot from either SPI or NAND depending on a switch setting. Both U-Boot images can be different or the same.
> 
> Either way the env settings are in nand. U-boot can already handle NAND env if configured correctly.
> 
> U-Boot already has NAND support too of course and can load the kernel from a variety of sources, including NAND. 'nboot' and 'nand read' can both be used for that.
> 
> All the above can work on da830evm with a NAND board connected to the expansion bus connectors. Nothing has changed in U-Boot other than in our (not yet published) _config file.
> 
> Defining CONFIG_USE_NAND in there is enough to turn NAND support on and our UBL configures *all* the pinmuxes fof the board. Using the UBL always used to be the TI recommended way to configure pinmuxes AFAIK.
> 
> Of course pinmux set up can also be added in the board file, though we have not bothered, since UBL *must* have already done it if it loads U-Boot from NAND.
> 
> Note that the end of the config file also has:
> 
> #ifdef CONFIG_MTD_PARTITIONS
> #define MTDIDS_DEFAULT        "nand0=davinci_nand.1"
> #define PART_BOOT        "512k(bootloader)ro,"
> #define PART_PARAMS        "512k(params)ro,"
> #define PART_KERNEL        "4m(kernel),"
> #define PART_REST        "-(filesystem)"
> #define MTDPARTS_DEFAULT        \
>     "mtdparts=davinci_nand.1:" PART_BOOT PART_PARAMS PART_KERNEL PART_REST #endif
> 
> ...where params is (for U-Boot) used for env and bootloader typically relates to U-Boot.
> 
> I don't know what 'bios' refers to in your question. I'm also a bit unsure what you mean by 'adds NAND boot mode for the first time', given that the processor boot mode has little say on where U-Boot or Linux are loaded from and we've been using standard U-Boot features to load data from NAND for nearly two years now.
> 
> Nick.
> 
> > On Wed, Aug 31, 2011 at 14:26:42, Nick Thompson wrote:
> >> On 30/08/11 13:15, nagabhushana.netagunte at ti.com wrote:
> >>> From: Nagabhushana Netagunte <nagabhushana.netagunte@ti.com>
> >>>
> >>> Add support for enabling NAND boot mode in configuration file and 
> >>> add correspanding pinmux support, nand initialize function in board file.
> >>> Since the environment variable are stored in first block
> >> My environment variables are not stored in the first block. Where does your assumption stem from?
> >>
> >> If I use this patch on my boards here, they will all "loose" their environment.
> >>
> >> By moving env you are creating a compatibility issue for boards that already use NAND.
> >>
> >>> CONFIG_ENV_OFFSET is set to offset 0 from (512 << 10) and also the 
> >>> size required for environment variables not more than 10KB the 
> >>> CONFIG_ENV_SIZE is set to 10KB from (512 << 10).
> >>>
> >>
> 
> 

[U-Boot] [PATCH 3/5] da830: add support for NAND boot mode

[Wolfgang Denk]

Dear "Netagunte, Nagabhushana",

In message <B85A65D85D7EB246BE421B3FB0FBB59302573721FB@dbde02.ent.ti.com> you wrote:
> I am just curious, since this patch adds NAND boot mode for the
> First time in denx git, how this affects you? Are you storing
> ENV variables in NAND during some other boot mode? In fact we are
> Adding other boot mode in this patch set. How come you are using
> Denx tree to flash bios on your da830 board?

Please note that there is not such things as "denx git" or "Denx
tree".

There is mainline code,  and there are out of tree ports.

The fact that we happen to host the mainline repositories is just
convenience (and a result of Sourceforge being too slow to use and too
slow to adapt new technologies).

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 at denx.de
I'd rather be led to hell than managed to heaven.

[U-Boot] [PATCH 3/5] da830: add support for NAND boot mode

[Netagunte, Nagabhushana]

Denk,
Thanks for clarifications.

Regards,
Nag
On Mon, Sep 05, 2011 at 14:56:04, Wolfgang Denk wrote:
> Dear "Netagunte, Nagabhushana",
> 
> In message <B85A65D85D7EB246BE421B3FB0FBB59302573721FB@dbde02.ent.ti.com> you wrote:
> > I am just curious, since this patch adds NAND boot mode for the First 
> > time in denx git, how this affects you? Are you storing ENV variables 
> > in NAND during some other boot mode? In fact we are Adding other boot 
> > mode in this patch set. How come you are using Denx tree to flash bios 
> > on your da830 board?
> 
> Please note that there is not such things as "denx git" or "Denx tree".
> 
> There is mainline code,  and there are out of tree ports.
> 
> The fact that we happen to host the mainline repositories is just convenience (and a result of Sourceforge being too slow to use and too slow to adapt new technologies).
> 
> 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 at denx.de I'd rather be led to hell than managed to heaven.
> 

[U-Boot] [PATCH 4/5] da830: modify the U-Boot prompt string

[nagabhushana.netagunte at ti.com]

From: Nagabhushana Netagunte <nagabhushana.netagunte@ti.com>

Modify U-boot promt string from 'DA830-evm >' to 'U-Boot >' as
there are many variants of da830 based boards which have diffrent
names such as L137, AM1707 etc.

Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: Nagabhushana Netagunte <nagabhushana.netagunte@ti.com>
---
 include/configs/da830evm.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/configs/da830evm.h b/include/configs/da830evm.h
index 4d50734..1866bab 100644
--- a/include/configs/da830evm.h
+++ b/include/configs/da830evm.h
@@ -168,7 +168,7 @@
 #undef CONFIG_MISC_INIT_R
 #undef CONFIG_BOOTDELAY
 #define CONFIG_BOOTFILE		"uImage" /* Boot file name */
-#define CONFIG_SYS_PROMPT	"DA830-evm > " /* Command Prompt */
+#define CONFIG_SYS_PROMPT	"U-Boot > " /* Command Prompt */
 #define CONFIG_SYS_CBSIZE	1024 /* Console I/O Buffer Size	*/
 #define CONFIG_SYS_PBSIZE	(CONFIG_SYS_CBSIZE+sizeof(CONFIG_SYS_PROMPT)+16)
 #define CONFIG_SYS_MAXARGS	16 /* max number of command args */
-- 
1.6.2.4

[U-Boot] [PATCH 5/5] da830: modify the MEMTEST start and end address

[nagabhushana.netagunte at ti.com]

From: Nagabhushana Netagunte <nagabhushana.netagunte@ti.com>

Modify the MEMTEST start and end address. The memtest range was overlapping the
CONFIG_SYS_LOAD_ADDR which causes the uImage to be corrupt.Also, modify the
size for which mtest is run to 32MB from 16MB.

Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: Nagabhushana Netagunte <nagabhushana.netagunte@ti.com>
---
 include/configs/da830evm.h |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/configs/da830evm.h b/include/configs/da830evm.h
index 1866bab..f90fc4f 100644
--- a/include/configs/da830evm.h
+++ b/include/configs/da830evm.h
@@ -52,8 +52,8 @@
  */
 #define CONFIG_SYS_MALLOC_LEN	(0x10000 + 1*1024*1024) /* malloc() len */
 #define PHYS_SDRAM_1			0xc0000000 /* SDRAM Start */
-#define CONFIG_SYS_MEMTEST_START	PHYS_SDRAM_1 /* memtest start addr */
-#define CONFIG_SYS_MEMTEST_END 	(PHYS_SDRAM_1 + 16*1024*1024) /* 16MB test */
+#define CONFIG_SYS_MEMTEST_START	(PHYS_SDRAM_1 + 0x2000000)
+#define CONFIG_SYS_MEMTEST_END		(CONFIG_SYS_MEMTEST_START + 32 << 20)
 #define CONFIG_NR_DRAM_BANKS	1 /* we have 1 bank of DRAM */
 #define CONFIG_STACKSIZE	(256*1024) /* regular stack */
 
@@ -173,7 +173,7 @@
 #define CONFIG_SYS_PBSIZE	(CONFIG_SYS_CBSIZE+sizeof(CONFIG_SYS_PROMPT)+16)
 #define CONFIG_SYS_MAXARGS	16 /* max number of command args */
 #define CONFIG_SYS_BARGSIZE	CONFIG_SYS_CBSIZE /* Boot Args Buffer Size */
-#define CONFIG_SYS_LOAD_ADDR	(CONFIG_SYS_MEMTEST_START + 0x700000)
+#define CONFIG_SYS_LOAD_ADDR	(PHYS_SDRAM_1 + 0x700000)
 #define CONFIG_VERSION_VARIABLE
 #define CONFIG_AUTO_COMPLETE	/* Won't work with hush so far, may be later */
 #define CONFIG_SYS_HUSH_PARSER
@@ -186,7 +186,7 @@
 /*
  * Linux Information
  */
-#define LINUX_BOOT_PARAM_ADDR	(CONFIG_SYS_MEMTEST_START + 0x100)
+#define LINUX_BOOT_PARAM_ADDR	(PHYS_SDRAM_1 + 0x100)
 #define CONFIG_CMDLINE_TAG
 #define CONFIG_SETUP_MEMORY_TAGS
 #define CONFIG_BOOTARGS		"mem=32M console=ttyS2,115200n8 root=/dev/mtdblock/2 rw noinitrd ip=dhcp"
-- 
1.6.2.4