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