Hi Tom, On Fri, Mar 16, 2012 at 2:53 PM, Tom Rini <tr...@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 <tr...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
