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@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