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