03-25-2010 12:25 PM - edited 03-25-2010 12:29 PM
I am trying to boot linux on both processors of the ML510 board, at the same time. I have created a .ace file with contains both .elf files. Both elf files also contain the ramdisk images. Upon powerup, both processors start booting, but one of them hangs after the "Finalizing device tree..." line while the other boots completely and is functional. Both processors were set up identically, expect one uses DIMM0, RS232_Uart_1, etc. and the other used DIMM1, RS232_Uart_2, etc. Opon creating the device trees, both memories were listed in both device tree files. I deleted the corresponding offending one from each file. Kernel configs are identical for both, the only difference being the .dts files. The interesting thing is that which ever elf file that I have listed FIRST in my .opt file (for running genace.tcl) is the one that hangs. So switching their order causes the second processor to boot right, as evidenced by the second serial port spitting out the complete boot and the first one hanging. So:
-debugdevice cpunr 1
-debugdevice cpunr 2
causes ppc440_0 to hang and ppc440_1 to work.
-debugdevice cpunr 2
-debugdevice cpunr 1
causes ppc440_1 to hang and ppc440_0 to work.
Any ideas as to what is going on? Thanks.
03-25-2010 12:51 PM
I wonder if it could have to do with resets somehow - are your resets coupled together between the two processor systems, or have you completely isolated them?
03-25-2010 01:04 PM
03-25-2010 01:06 PM
Hard to tell exactly from the block diagram, but I suspect they're connected.. Can you use two XMD sessions to loade and run each kernel independently? If so, what happens if you reset one processor from XMD? Does the other processor get reset as well?
03-25-2010 01:40 PM
I was able to get both processors running in that manner, so that is a step forward, thank you. After I get both of them running, doing a rst on the second debug window causes BOTH to stop working. Is the correct way to have 2 separate reset lines?
As a note, upon downloading the second elf file, in the debug second window, the first debug window displays:
Info: Cable is LOCKED. Retrying...
03-25-2010 03:01 PM
Thank you for your help. I know this question might be better suited for a different forum topic, but since you are familiar with my situation I wanted to ask. Do you have any ideas or pointers on how to modify the reset lines? During setup in EDK no such options were made available, or at least I didn't see them. I know that EDK is very helpful, but it also seems like EDK does
some a lot of stuff without asking/telling you. Are there ways to configure those types of hidden things(like the reset lines) in EDK? Also,I know this would be torture, but would it be possible to design a complete embedded system using the virtex5(with dual cores) without using EDK, just, for instance, the rest of the ISE design suite? It sounds painful, but if possible, you would have complete control over all of the details. Is that a valid way of thinking about it? I am new to the virtex and EDK, and am trying to figure out it all works. I just don't want to go down a path that lead in a different direction that where I want to go. Thanks again for your help.
03-25-2010 03:13 PM
Unless you have a whole lot of time on your hands, you shouldn't even consider trying to bypass EDK. It's just not an option.
That said, you do have full control over the connectivity of the embedded design within EDK. What you probably started with is something that came out of Base System Builder, or a reference design. It's just a starting point to get something up and running. Many times, the base architecture is sufficient to accomplish what you need to do. But most users need to do some customization of the system.
Look at the proc_sys_reset block - study its user guide, along with the PPC440 user guide in reference to the resets - it's all documented, and it's all fully customizable. You may need to add another proc_sys_reset block. Or you may need to design your own custom logic and add it to a pcore that can be dropped in the embedded system.
There is also the option of making the embedded system a sub-module of a larger ISE project. You can then bring signals out to the ISE top level, do you customizations there, and then feed the results back down into the EDK sub-module.
If you're new to EDK, then I would suggest that you invest in some training to get you over the hump if at all possible. It's a very powerful tool, but there is a lot to learn before becoming a power user.
02-24-2011 02:22 PM - edited 02-24-2011 02:24 PM
Terry or anyone,
I am now using dual microblaze processors on the ml510 and I am having this same problem that was mitigated on the dual PPC platform above. Although this time I have instantiated 2 proc_sys_reset modules to try and fix the issue, but it is not working. I noticed that they both take a reset line, "Debug_SYS_Rst" generated in the mdm. I assume that I did not have this issue when using the PowerPC's because the proc_sys_reset module did not have port labled MB_Reset being fed by mdm module. So I think that XDM triggers a reset in the mdm module that gets propagated to both proc_sys_reset modules every time code is loaded onto EITHER processor. The end result is that after I get one processors running, if I use XMD to download code to the other one, the first one stops working(It gets reset). I am using EDK 12.4 and version 3.00.a of proc_sys_reset. Any ideas? Is the Debug_SYS_Rst line needed or can I disconnect it and tie that port unasserted? Thanks.
02-25-2011 07:11 AM
By the time that I saw your reply, I had already changed things, and it appears to work. The single mdm module in the design has an output port called Debug_SYS_Rst which was being fed to both of my proc_sys_reset modules (through port MB_Debug_Sys_Rst on them) in parallel. I disconnected this line from both proc_sys_reset modules and now it seems to work fine; I can boot both processors now without issue from 2 different XMD terminals.
When I had just one microblaze processor running, this line was connected (BSB did it that way), but the equivalent PPC design never had that connection. I am not sure why the microblaze design had it, but it seems to function without it. The only thing that I haven't tried yet is loading the bit file from the sysace, hopefully that will still work.
09-06-2013 01:42 AM