Hi Brian,
- Chuck: I didn't realize you read this mailing list. But either way, are
you telling me to comment out the disabling of the debug registers so the BDI retains control?
...
I can single step my way through the display_options functions, and it says it's trying to write out the serial port (of which it isnt quite connected yet so I can't quite verify that yet), but if i set a break point at display_options, and let the CPU continue, it will never return to me.
If you can single step to get to display_options but not set a brkpt there and hit it, then one possibility is that the debug regs are still being modified in such a way that either a) HW brkpts are being disabled or b) the HW brkpts are being changed. The best logical way I would approach this is to start at the beginning, and take smaller "leaps" (say 10 or 20 lines of code) with HW brkpts. As you approach display_options, if what you say is correct, at some point the brkpt will not occur correctly. The area of code covered by that last "leap" you should look at. Don't leap over function calls, go into them. Finally, keep in mind that your architecture limits the number of HW brkpts in force at any time. Come to think of it, that could be your problem right there.
For a preemptive question, once I get U-Boot up and running, I had a linux kernel running on the Ebony dev kit -- do you experts forsee any porting that will have to be done with that over to the custom platform?
Definitely. You can take this part of the discussion over to the linuxppc list. But plan on changing the .config, adding to the arch/ppc/platforms/ dir, potentially writing/modifying driver code (e.g. you may need to enter an MTD map, etc.), among many other possible changes.
Chuck Meade The PTR Group, Inc. www.ThePTRGroup.com