[U-Boot] [PATCH v4 0/27] Create generic board init for ARM, x86, PPC

[Tom Rini]

On Fri, Mar 16, 2012 at 12:34:20PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, Mar 16, 2012 at 12:23 PM, Tom Rini <trini at ti.com> wrote:
> > On Wed, Mar 14, 2012 at 07:15:57PM -0700, Simon Glass wrote:
> >
> >> This series creates a generic board.c implementation which contains
> >> the essential functions of the major arch/xxx/lib/board.c files.
> >
> > Let me start by saying that I agree with the premise, please read any
> > inflection/tone as that of someone trying to debug a problem only :)
> 
> Understood :-)
> 
> >
> > I'm trying to test this on omap4_panda right now and I'm running into a
> > problem where we hang setting up gd->bd->bi_dram[0]. ?I don't see why
> > this isn't being set (some quick peeking around and SPL is behaving
> > normally and doing its configure of DRAM and so forth). ?But I also
> > can't debug this problem as easily as I would like because:
> > (a) despite DEBUG being defined, none of the debug() prints are printing
> > (my printf's are)
> 
> There is only one macro that affects that - make sure #define DEBUG is
> above #include common.h or maybe just change them to printf() to work
> this out...

I've gone and changed them to printf's, and a lot of stuff I would
expect to see, I don't.  On tegra, can you do a before/after debug build
and see what board_init_f shows?

> > (b) I assume this is because there's so much reconciliation needed
> > still, but the file is an unwieldy mess. ?In fact, as I'm writing this
> > and debugging at the same time, it seems reserve_board isn't being
> > called, but it's compiled in, in the non-SPL case. ?I'm not seeing
> > what's up...
> 
> I split out the SPL stuff because it wasn't exactly clear to me what
> was different between SPL and normal start-up. Only recently did I get
> a board that supports SPL, and I was planning on looking at this soon.
> I can't give any specific guidance other than persistence and good
> debug tools :-)

Actually, what I'm seeing is more "is this generic or ARM or x86 or PPC
code?"  There's a lot of that merging that needs doing still and I guess
that's part of the mess.

> But please do let me know how you get on, and thanks for looking at
> it. This effort is worthy but not easy.

I'll post patches for omap4_panda and then hopefully omap3_beagle, or
die trying :)

-- 
Tom