[U-Boot] New Oxford Semiconductor board with assertion fail in linker

[Marek Vasut <marek.vasut@gmail.com>]

> On Mon, Dec 19, 2011 at 5:26 PM, Michael Kebe <michael.kebe@gmail.com> wrote:
> > Here is the output from a bootup of the old U-Boot:
> [...]
> 
> > U-Boot 1.1.2 (Jun 24 2011 - 09:41:57)
> 
> [...]
> 
> > However even if I try to build with these addresses, the linking
> 
> > crashes with even more assertion fails:
> Everyone always feels that they need to do a big uprev in one
> giant step.  That is not an insult in any way -- I've also done the
> same thing.  But even if you get it compiled, are you ready to debug
> silent-boot-death where you don't get a single byte out the UART?
> The probability of this happening is relatively high, since your
> origin tree is so old and predates the config.mk removal stuff.
> 
> I think in a case like this, you would be well served to start with smaller
> steps, since your origin is so old.  Try moving it just to U-Boot-1_1_4 and
> see if you can make that work.  THat will ensure your process, and your
> toolchain and your install are OK.  Then maybe U-Boot-1_2_0 and then
> next to v1.3.0, then v1.3.4, then v2008.10 and so on.
> 
> In doing so, you'll have a chance to test your images along the way,
> and you'll eventually find the region in which the assertion failures
> appear for the 1st time.  Sometimes you simply can't see the problems
> by staring at the code; you really need to know at what point they
> 1st appeared.
> 
> Your patches should be largely portable, since they mostly create new
> files, and should only make small changes to existing Makefiles, etc.
> So the task is not too hard to attack incrementally.
> 
> Using "git rebase" and enabling "git rerere" in your .gitconfig will be
> something you'll want to make use of.  Once you've got a definitive
> "good" version, and a definitive "bad" version, you can even make
> use of git bisect, as long as you remember to layer on your patches
> at each bisection point before building.
> 
> It isn't an answer to your specific problem, but it is a process that
> will get you there by yourself, at your own pace.  And once you have
> a more concrete focus on what change caused your problem, then
> when you do ask for help, you will most likely get better help.
> 
... or you can just snap in a JTAG debugger, connect GDB and throw some 
break/watch points here and there ;-)

M