• State Suggested Answer
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 122 subscribers
  • Views 8726 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DS-5 debug on Marvell PCE errors/warnings

mahmad

Hello,

I am using Dstream with a Pactron sherwood board with Marvell armada xp, since there isnt an existing platform in DS-5 I tried PCE and got warnings about several components not having a connection e.g. CSTFunnel. I read in another discussion that could be caused if I ran the PCE in uboot, since it only powers on one core. So I got linux to run and did the configuration again but with same results.

My goal is to debug u-boot and kernel, so I can figure out how to switch the kernel to big endian properly(as I understand u-boot doesnt need to be BE). Due to some limitations in the u-boot, I have to make the switch in kernel.

So, do these warnings only limit the trace and linux application debug? Or also the bare metal? I have tried just proceeding with the warning and I can make a connection but I run into trouble when I try to set a break point and step through u-boot.

I am very new to this environment please do let me know if I can provide further information?

Parents
  • 0 in reply to Stuart Hirons

    Either or.

    Using breakpoints I can stop the execution before from when I boot up the board till autoboot countdown start in u-boot.

    The other way I was able to stop was using watchpoints for addresses that I know will be accessed.

    The reason that I understand so far is because the u-boot has an additional header or two(specific to Marvell)  before the main u-boot gets executed, and that the main code is at an offset from the headers. So the symbol file needs to be loaded again with an offset.

    I have tried the offset that I think is correct using PC and the disassembly, which seems to work. I used a HW breakpoint to stop at the do_bootm_linux and then carefully step through till u-boot enters kernel.

    Everything seems to be in order for me to be able to debug the big endian kernel.

    Thank you all for the input.

Reply
  • 0 in reply to Stuart Hirons

    Either or.

    Using breakpoints I can stop the execution before from when I boot up the board till autoboot countdown start in u-boot.

    The other way I was able to stop was using watchpoints for addresses that I know will be accessed.

    The reason that I understand so far is because the u-boot has an additional header or two(specific to Marvell)  before the main u-boot gets executed, and that the main code is at an offset from the headers. So the symbol file needs to be loaded again with an offset.

    I have tried the offset that I think is correct using PC and the disassembly, which seems to work. I used a HW breakpoint to stop at the do_bootm_linux and then carefully step through till u-boot enters kernel.

    Everything seems to be in order for me to be able to debug the big endian kernel.

    Thank you all for the input.

Children