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

[Albert ARIBAUD]

Hi Sughosh,

On Tue, 13 Nov 2012 09:40:19 +0530, Sughosh Ganu
<urwithsughosh at gmail.com> wrote:

> 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

Thanks for the feedback. Meanwhile, I have found two ugly bugs which
would certainly affect execution past board_init_f(), so maybe your
hawkboard was bitten by theses; next time please try v3, which fixes
these bugs, or the latest patch version if v3 is obsolete by the time
you come back.

Enjoy your vacation!

Amicalement,
-- 
Albert.