[U-Boot] U-Boot 1.3.1 booting problem

[Jerry Van Baren <gerald.vanbaren@ge.com>]

Martin Hejnfelt wrote:
> Jerry Van Baren wrote:
>> pugazh mahalingam wrote:
>>   
>>> Hi,
>>> I'm porting u-boot-1.3.1. on a MPC8548PC processor and I'm using the start.S
>>> file of u-boot-1.1.4.
>>> But I encounter booting problems.. The processor cannot bootup .. its going
>>> to hang state ..
>>> I used start.S of u-boot-1.1.4 since it works fine for u-boot-1.1.4 ..
>>> please help in this regard ..
>>>
>>> thanks ..
>>>
>>> regards
>>> pugazh
>>>     
>> Hi pugazh,
>>
>>  From your description, it sounds like you took 1.3.1, discarded its 
>> start.S, and simply tried to replace it with the start.S from 1.1.4.
>>
>> If that is what you are attempting, it isn't surprising it doesn't work.
>>
>> (Listen to Kumar's advice: you should go all the way to the latest code.)
>>
>> If you are trying to pull your port forward from 1.1.4, you are going to 
>> have to understand what the differences are between 1.1.4 and 1.3.1 (or 
>> newer).  There just aren't any shortcuts.
>>
>> Time to crank up your JTAG debugger and see where the code is stopping 
>> and why.
>>
>> You can (theoretically) use git-bisect to figure out where booting 
>> breaks in the series of changesets from 1.1.4 to 1.3.1.  It isn't going 
>> to be fast because you are talking years of changes (and I'm guessing 
>> your board isn't in the standard u-boot tree, which may cause you grief 
>> too).
>>
>> We really cannot help you much, you basically have given us no useful 
>> data: "It's broken and there are lots of changes."  We're good, but we 
>> aren't *that* good.  :-(  Sorry.
>>
>> Good luck,
>> gvb
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>>   
> I just went through somewhat the same procedure as I had to port a 
> custom AT91RM9200EK based board from U-boot 1.1.4 to 1.3.4. I tried the 
> same method of just replacing files, that is surely a no go, since you 
> never know what was changed in all the other files included and 
> whatnot... The first method was finding the place in the release chain 
> where my system broke, which in my example was in the switch from 1.2.0 
> to 1.3.0. I then worked my way through the differences in the versions, 
> where I saw the most crucial differences also lied in the start.S file, 
> but the way I debugged myself through this was the use of the three LEDs 
> on my board, which I could turn on and off and work my way through the 
> code, find "crash points", resolve these and continue on... This was 
> tiresome and all in all it took me 1? week to get the port up and 
> running, so it's not something that you do overnight.
> 
> Good luck,
> 
> Martin Hejnfelt

Hi Martin,

Thank you for the update.  I vaguely recalled someone else (you) taking 
this journey fairly recently but was unable to find it in the archives.

It sounds like you followed what I (parroting others) suggested in my 
previous message: find the place in "time" where the code breaks and 
then dig into understanding the code changes coupled with debug tools.

Finding can be done by brute force, but git bisect is probably the most 
efficient.

Debug tools can be as simple as LEDs[1], but a JTAG debugger is 
generally more efficient.

Best regards,
gvb

[1] I work with a hardware wizard who can debug anything with just a 
logic probe.
   <http://en.wikipedia.org/wiki/Logic_probe>
We joke about him and his "sonic screwdriver".
   <http://en.wikipedia.org/wiki/Sonic_screwdriver>