[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