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

[Tom Rini]

On Fri, Mar 16, 2012 at 01:07:23PM -0700, Tom Rini wrote:
> 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?

I've found the problem, but I don't have an easy fix.  The problem is we
aren't doing things in the same order we used to.  We need gd->bd setup
before we call setup_dram_config (which is just __dram_init_banksize).
This doesn't blow up on Tegra2 as memory starts at 0.  That's not true
on TI's Cortex-A* parts and we hang :)

So my request for a V5 is to boot with DEBUG enabled and compare
CONFIG_SYS_GENERIC_BOARD=y and =n and fix the ordering issues.  I
suspect this will be complex, or at least a pain due to the unwieldyness
I was talking about before of the merged list of calls being so very
long and with PPC-specific stuff stuck in (and some ARM and so forth).

-- 
Tom