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

Simon Glass sjg at chromium.org
Fri Mar 16 20:34:20 CET 2012


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

> (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 :-)

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

Regards,
Simon

>
> --
> Tom


More information about the U-Boot mailing list