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.
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?
Hi,
I would start by using PCE to create a configuration containing a single core + its CTI. You need to choose the core that will run uboot - probably core_0 but you may have to experiment a bit. Then connect DS-5 to just that core and see if you get more success and a stable debug environment. If uboot only uses this one core and you dont need trace capability you will have all you need for uboot debug.
Just to add some further questions to my colleague Lukas's tutorial links....
I understand that the Pactron Sherwood board uses a Marvell MV78460 Quad-core ARM v7-compliant processor.
If this is correct, then I am intrigued as to how the processor identifies itself, are you able to share this with us ?
The processor is designed by Marvell (rather than ARM) so it may behave slightly differently to how we might expect when debugging.
Can you also tell us in a bit more detail please what is happening when you do try to set a breakpoint, single-step u-boot ?
Thanks,
Stuart
Thank you for the suggestions. I havent watched those videos as it seems like, yes, core_0 is the active core. I can connect to it but its unable to find the entry point, also it doesnt seems to stop at any breakpoints.
I am trying to debug the problem where u-boot is in little endian and kernel is compiled in a big endian. U-boot hangs with "Starting kernel ..." message.
Please see my reply to Lukas's answer. I will try to add in as I go.
I was able to get a debug platform, with warnings, using the PCE. Which as I understand should be sufficient for debug but not trace.
mahmad said:I was able to get a debug platform, with warnings, using the PCE. Which as I understand should be sufficient for debug but not trace.
That's correct.
So it doesn't stop at any breakpoints then ? Are these hardware ones or software ones ?
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.
Excellent mahmad, thanks for letting us know and I'll bear your answer in mind for any future queries like this.
Regards,