[U-Boot] Breakage on arm/next

[apgmoorthy]

Hi Scott,

> >>>
> >>> Hunk 2:
> >>> +       if (FLEXONENAND(this)) {
> >>> +               env_addr <<= 1;
> >>> +               instr.len <<=
> >> onenand_mtd.eraseregions[0].numblocks == 1 ?
> >>> +                               2 : 1;
> >>> +       }
> >>>
> >>> This should not break any other Board with OneNAND support. 
> >> Please comment.
> >>> (Somehow I still feel Macros can be Cleaner way.)
> >> Why is the address automatically doubled on flex?  I think this 
> >> really needs to be something board-specified.
> >>
> > Please excuse me for the Delay.
> > 
> > Flex-OneNAND device's erasesize itself is double considered 
> to OneNAND.
> 
> That doesn't mean that all data you're storing is double the 
> size.  A board may want to keep the byte offset the same, and 
> let the block number change.
> 
> > Like , In SLC region of Flex-OneNAND size is 256K and in 
> MLC region it 
> > is 512K. In case of OneNAND erasesize is 128K and it is just SLC.
> 
> Suppose I have a 256K U-Boot.  I want CONFIG_ENV_ADDR to be 
> 256K regardless, which would be block 1 for flex SLC or block 
> 2 for regular OneNAND.
> 
> If I have a 512K U-Boot, then the byte offset would be the 
> same for MLC as well.

You are right , Sorry , I missed it. This is one of the scenarios which compelled us 
to use seperate Flex-OneNAND Env Macros different from OneNANDs , when 
suggesting a alternative somehow missed it.

Going back to the suggestion you have given couple of mails back in the same chain.
That there should be a macro which should return the ENV size for Flex.
In that case i just saw something like below should do.

Hunk 1:
env_addr += CONFIG_ENV_ADDR & (onenand_mtd.eraseregions[0].erasesize-1);

Hunk 2:
env_addr += CONFIG_ENV_ADDR & (onenand_mtd.eraseregions[0].erasesize-1);
instr.len = onenand_mtd.eraseregions[0].erasesize;
instr.len <<= onenand_mtd.eraseregions[0].numblocks == 1 ? 1 : 0;

Please comment.

With Regards
 Moorthy