Message ID | 1314706560-12773-4-git-send-email-nagabhushana.netagunte@ti.com |
---|---|
State | Superseded |
Headers | show |
On 30/08/11 13:15, nagabhushana.netagunte@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). >
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@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). > > > >
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@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). >>> >>
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
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@denx.de I'd rather be led to hell than managed to heaven. >
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@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). > >>> > >> > >
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