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