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

[Simon Glass]

Hi Tom,

On Fri, Mar 16, 2012 at 2:53 PM, Tom Rini <trini at ti.com> wrote:
> 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 :)

Great! Thanks for the info and your efforts on this - much appreciated!

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

Well I created this by painstakingly comparing the ordering in the
different archs and trying to come up with something reasonable.
Clearly I got it wrong, but I don't think it's a big job to figure out
the error. Hopefully it is not just an incompatibility between the
archs.

I will take a look.

Also for DEBUG, can you please tell me which file you added the DEBUG to?

Regards,
Simon

>
> --
> Tom