[U-Boot] [PATCH v2 0/2] Factorize ARM startup code as mush as possible.

[Sughosh Ganu]

hi Albert,

On Sat, Nov 10, 2012 at 8:00 PM, Albert ARIBAUD
<albert.u.boot at aribaud.net>wrote:

> Hi Sughosh,
>
> On Thu, 8 Nov 2012 19:50:28 +0530, Sughosh Ganu
> <urwithsughosh at gmail.com> wrote:
>
> > hi Albert,
> >
> > On Mon Nov 05, 2012 at 01:09:25PM +0530, Sughosh Ganu wrote:
> > > On Sun Nov 04, 2012 at 10:38:32AM -0700, Tom Rini wrote:
> > > > On Sun, Nov 04, 2012 at 12:43:12PM +0100, Albert ARIBAUD wrote:
> > > >
> > > > > Hi Tom,
> > > > >
> > > > > On Sun,  4 Nov 2012 12:32:03 +0100, Albert ARIBAUD
> > > > > <albert.u.boot at aribaud.net> wrote:
> > > > >
> > > > > > The goal of this series is to scrub the start.S files
> > > > > > which have proliferated across arch/arm and eliminate
> > > > > > code redundancy.
> > > > >
> > > > > I know this came a bit late in early nov 4th, but I really would
> like
> > > > > it to be considered for 2013.01. Would you agree to make an
> exception
> > > > > for it? Thanks in advance.
> > > >
> > > > If you can collect a diverse set of Tested-by's, yes.
> > >
> > > I have not gone through the patch, but will test it in a day or two on
> > > the hawkboard, and report the findings.
> > >
> > > The hawkboard comes with the arm926ejs core, so that part of the code
> > > would be tested.
> >
> > I tried the 1st patch of the series, and with that u-boot does not
> > come up on the board. It is also printing out some random values for
> > the dram and nand sizes.
> >
> > The patch was applied on top of commit 1cc619be8b7. Also, with the
> > mentioned commit, u-boot boots up fine on the board. Also to be noted
> > is that the spl image compiled with these changes is booting up fine,
> > loading the main u-boot image, and jumping to it -- the issue is with
> > booting the main u-boot image.
>
> Thanks Sughosh. Can you build an U-Boot with the following defined
> in the hawkboard.h config file?
>
> #define DEBUG
> #if defined(CONFIG_SPL_BUILD) && ! defined (__ASSEMBLY__)
> static inline int printf(const char *fmt, ...)
> {
>         return 0;
> }
> #endif
>
> Note: only the #define DEBUG matter to me, but with it alone, SPL build
> fails due to some code now requiring printf(). This is why I add a
> dummy printf definition for C code during SPL build -- ASM code does not
> need printf() and actually chokes on the definition, hence the
> condition on __ASSEMBLY__.
>
> This debug U-Boot should print a lot more info. Can you please try it
> and copy/paste its output here? Thanks in advance.
>

Unfortunately i am currently on vacation, with no access to the board, and
would be able to try out your suggested changes only after   i am back, by
the end of next week. In the meantime, i am also trying to get myself a
jtag debugger -- it is quite frustrating to provide half baked information.

I had tried enabling DEBUG in the board.c file, and with that, i saw that
board_init_f completes, and the board hangs after returning from the
function. Now i really need a debugger to figure out where exactly is the
problem, as it could be in the relocation part, or while trying to jump to
the board_init_r after having relocated the code. Hopefully, with a jtag
debugger, i will be able to provide you a lot more info.

-sughosh