Skip to contentSkip to conversation

feature additions and fixes for da830

PATCH Superseded nagabhushana.netagunte at ti.com 6 participants 20 messages Aug 30, 2011 – Sep 14, 2011

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore

nagabhushana.netagunte at ti.com

author
#0 lore raw

cover feature additions and fixes for da830

From: Nagabhushana netagunte <[email protected]>

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(-)
author
#1 lore raw

PATCH 1/5 da830: disable cache usage due to coherency issues

From: Nagabhushana Netagunte <[email protected]>

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 <[email protected]>
---
 include/configs/da830evm.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)
include/configs/da830evm.h +3 -0
index bcf8ee0..da7d528 100644
@@ -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
Signature · 1 line
1.6.2.4
#2 lore raw

PATCH 1/5 da830: disable cache usage due to coherency issues

Quoted 2 lines · 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

#3 lore raw

PATCH 1/5 da830: disable cache usage due to coherency issues

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

Quoted 7 lines · Mike Frysinger
Quoted 2 lines · 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

#4 lore raw

PATCH 1/5 da830: disable cache usage due to coherency issues

Quoted 10 lines · 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

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.

#5 lore raw

PATCH 1/5 da830: disable cache usage due to coherency issues

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

Quoted 18 lines · Nick Thompson
Quoted 10 lines · 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

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.

#6 lore raw

PATCH 1/5 da830: disable cache usage due to coherency issues

Quoted 3 lines · Nagabhushana

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...?

Quoted 4 lines

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.

Quoted 22 lines

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

Regards,
Nag

Quoted 17 lines · Nick Thompson
Quoted 10 lines · 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

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.

#7 lore raw

PATCH 1/5 da830: disable cache usage due to coherency issues

Quoted 6 lines · Nick Thompson
Quoted 3 lines · Nagabhushana

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).

Signature · 1 line
Tom
#8 lore raw

PATCH 1/5 da830: disable cache usage due to coherency issues

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

Quoted 13 lines · Tom Rini
Quoted 6 lines · Nick Thompson
Quoted 3 lines · Nagabhushana

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

#9 lore raw

PATCH 1/5 da830: disable cache usage due to coherency issues

In reply to Netagunte
Quoted 8 lines · Nagabhushana

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
author
#10 lore raw

PATCH 2/5 da830: enable SPI flash boot mode

In reply to nagabhushana.netagunte at ti.com

From: Nagabhushana Netagunte <[email protected]>

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 <[email protected]>
Signed-off-by Nagabhushana Netagunte <[email protected]>
---
 include/configs/da830evm.h |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)
include/configs/da830evm.h +4 -3
index da7d528..13c3494 100644
@@ -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
Signature · 1 line
1.6.2.4
author
#11 lore raw

PATCH 3/5 da830: add support for NAND boot mode

In reply to nagabhushana.netagunte at ti.com

From: Nagabhushana Netagunte <[email protected]>

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 <[email protected]>
Signed-off-by Nagabhushana Netagunte <[email protected]>
---
 board/davinci/da8xxevm/da830evm.c |   63 +++++++++++++++++++++++++++++++++++++
 include/configs/da830evm.h        |    6 ++-
 2 files changed, 67 insertions(+), 2 deletions(-)
board/davinci/da8xxevm/da830evm.c +63 -0
index 0650653..2021e73 100644
@@ -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 */
include/configs/da830evm.h +4 -2
index 13c3494..4d50734 100644
@@ -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
Signature · 1 line
1.6.2.4
#12 lore raw

PATCH 3/5 da830: add support for NAND boot mode

Quoted 5 lines · nagabhushana.netagunte at ti.com

From: Nagabhushana Netagunte <[email protected]>

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.

Quoted 4 lines

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).

#13 lore raw

PATCH 3/5 da830: add support for NAND boot mode

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

Quoted 19 lines · Nick Thompson
Quoted 5 lines · nagabhushana.netagunte at ti.com

From: Nagabhushana Netagunte <[email protected]>

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.

Quoted 4 lines

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).

#14 lore raw

PATCH 3/5 da830: add support for NAND boot mode

Quoted 8 lines · 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

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.

Quoted 18 lines · Nick Thompson
Quoted 17 lines · nagabhushana.netagunte at ti.com
Quoted 5 lines

From: Nagabhushana Netagunte <[email protected]>

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.

Quoted 4 lines

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).

#15 lore raw

PATCH 3/5 da830: add support for NAND boot mode

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

Quoted 59 lines · Nick Thompson
Quoted 8 lines · 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

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.

Quoted 18 lines · Nick Thompson
Quoted 17 lines · nagabhushana.netagunte at ti.com
Quoted 5 lines

From: Nagabhushana Netagunte <[email protected]>

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.

Quoted 4 lines

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).

#16 lore raw

PATCH 3/5 da830: add support for NAND boot mode

In reply to Netagunte

Dear "Netagunte, Nagabhushana",

Quoted 5 lines · In message <[email protected]> you…

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

Signature · 4 lines
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.
#17 lore raw

PATCH 3/5 da830: add support for NAND boot mode

Denk,
Thanks for clarifications.

Regards,
Nag

Quoted 24 lines · Wolfgang Denk

Dear "Netagunte, Nagabhushana",

Quoted 5 lines · In message <[email protected]> you…

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

Signature · 3 lines
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.
author
#18 lore raw

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

In reply to nagabhushana.netagunte at ti.com

From: Nagabhushana Netagunte <[email protected]>

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 <[email protected]>
Signed-off-by Nagabhushana Netagunte <[email protected]>
---
 include/configs/da830evm.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
include/configs/da830evm.h +1 -1
index 4d50734..1866bab 100644
@@ -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 */
Signature · 1 line
1.6.2.4
author
#19 lore raw

PATCH 5/5 da830: modify the MEMTEST start and end address

In reply to nagabhushana.netagunte at ti.com

From: Nagabhushana Netagunte <[email protected]>

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 <[email protected]>
Signed-off-by Nagabhushana Netagunte <[email protected]>
---
 include/configs/da830evm.h |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)
include/configs/da830evm.h +4 -4
index 1866bab..f90fc4f 100644
@@ -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"
Signature · 1 line
1.6.2.4