[U-Boot] [PATCH] [OneNAND IPL] OneNAND board init support

[Scott Wood]

On Sat, Sep 19, 2009 at 10:32:30AM +0900, Kyungmin Park wrote:
> On Sat, Sep 19, 2009 at 4:26 AM, Scott Wood <scottwood at freescale.com> wrote:
> > On Sat, Aug 29, 2009 at 01:00:59PM +0900, Kyungmin Park wrote:
> >>  #define READ_INTERRUPT()                                                \
> >> -     onenand_readw(THIS_ONENAND(ONENAND_REG_INTERRUPT))
> >> +                             onenand_readw(ONENAND_REG_INTERRUPT)
> >
> > You could get rid of the newline now...
> 
> It exceeds the 80 columns.

No it doesn't, anymore.  You'll note that the start of onenand_readw() in to
the right of the end of READ_INTERRUPT, so you're not saving any horizontal
space with the newline.

> >> +enum {
> >> +     ONENAND_USE_DEFAULT,
> >> +     ONENAND_USE_GENERIC,
> >> +};
> >
> > What is this?  Add a comment, and possibly more specific names.
> 
> I see redefine the specific names and comments.
> 
> >
> >> +extern int (*onenand_read_page)(ulong block, ulong page,
> >> +                             u_char *buf, int pagesize);
> >
> > Maybe use a weak function instead?  Or an #ifdef
> > CONFIG_SYS_ONENAND_BOARD_READ_PAGE that will keep the code for the
> > generic version from being in the image (it'd be nice if we could
> > optimize out replaced weak functions).  It seems especially odd that you
> > use one method for init and another for read page.
> 
> I tried to use weak function but it produces more than expected.

More than compiling both functions and choosing with a function pointer?

> as you know it got size limitation. When use the weak function. the
> apollon board will be broken. 

Broken how?  Size?

> and I don't want to use #ifdef. since Now we support two different CPUs,
> s5pc100, s5pc110. these accesses different way. s5pc100 use own OneNAND
> controller. but s5pc110 use generic OneNAND method. That's reason to
> define the function pointer.

Function pointers make sense if you want to override on a per-device basis
(i.e. multiple controller types in the same system) or dynamically
(different hardware handled by the same binary).  Are you trying to generate
one image that works on both s5pc100 and s5pc110?  That sounds pretty
luxurious for a space-constrained NAND bootstrap. :-)

> >>  /* read a page with ECC */
> >> -static inline int onenand_read_page(ulong block, ulong page,
> >> +static int generic_onenand_read_page(ulong block, ulong page,
> >>                               u_char * buf, int pagesize)
> >
> > Is the "generic" code really generic, or is it just one specific
> > controller?
> 
> The 'generic' means the original OneNAND access method. Use NOR
> interface and use OneNAND registers.
> Most and Most generic method.

OK, good; it was never clear to me just which hardware the existing onenand
code has been targeting; I had gotten the impression that it was for one of
the chips with a custom controller.

Better, though, would be to still have good separation between that
implementation and the infrastructure that is truly generic even when you
have a special controller.  This is something I don't like about the current
NAND code.

> >> +     onenand_board_init(&page_is_4KiB, &page);
> >> +#else
> >> +     onenand_generic_init(&page_is_4KiB, &page);
> >> +#endif
> >>
> >> -     if (onenand_readw(ONENAND_REG_TECHNOLOGY)) {
> >> -             pagesize = 4096; /* MLC OneNAND has 4KiB pagesize */
> >> +     if (page_is_4KiB) {
> >> +             pagesize = 4096; /* OneNAND has 4KiB pagesize */
> >>               erase_shift = 18;
> >> -     } else {
> >> -             pagesize = 2048;
> >> -             erase_shift = 17;
> >>       }
> >
> > I don't understand why you move the pagesize/erase_shift init before
> > onenand_board_init, suggesting that the init code change it if it needs
> > changing -- but then leave the page_is_4KiB stuff in the generic code.
> >
> > This should probably just be filled in by the init code without anything
> > here.
> 
> No different. basically I assume OneNAND has 2KiB pagesize and
> In special case, MLC, and 4KiB pagesize OneNAND set the 4KiB pagesize.
> 
> If you want to leave as before. no problem.
> 
> Please consider the code size

It seems to me that just having the replaceable init function fill in the
page size would be smaller than having non-replaceable code that passes a
pointer in and then decides on the basis what was written there.

> and don't want to break exsiting board support.

I don't see how this additional bit of refactoring would put other boards at
higher risk of breaking that what you're already doing.  For any board that
doesn't override onenand_board_init (and since that's a new capability,
there should not be any that do yet), you're just moving something from one
part of generic code to another.

-Scott