by Guest »
Eli,
Thanks. I'll try to clarify and respond...
* When I jtag config (not boot from config flash) with the x4-lane-modified Xillydemo, the host shows some BIOS info on the monitor. Under other circumstances, this BIOS info is followed by linux boot info. But in this case, after the BIOS info comes nothing. Shortly thereafter the monitor powers off for lack of incoming signal. I believe either the BIOS is never finishing or linux boot is never getting past the very early stages. I suspect BIOS for this reason. When boot order was to boot from a PCIe/104 nic first, the BIOS message trying to boot from the nic was stuck showing. The BIOS was stuck. When boot order was to boot from disk first, we got the monitor power off as described. My theory was that the PCIe bus was getting [somehow hung up, no specific knowledge] and this made the BIOS get stuck trying to boot from the nic. During this time, however, the VIO on the FPGA showed that the FPGA's low level Xilinx PCIe code had the link UP. So the PCIe bus wasn't totally messed up, just a little messed up. To recap, the link was up but the bus seems hung. Subsequently, I took the working Xilinx demo and commented out the "app"lication. Then that one started hanging the host boot as well. This makes me think that the PCIe bus is getting hung up due to some higher level transaction situation, at a level above "link up", and at a level that the Xilinx demo "app"lication and analogously the xillybus_core handle. Call both those "applications". So these applications must do some transactions and when they fail to do so or fail to do it right, the PCIe bus gets hung up enough, even though the link is up, to hang the remainder of the boot.
* You have said *indirectly* that the xillybus_core *should* be agnostic about number of lanes. Thanks for the info. You're surely correct, but in spite of that my testing is strongly suggesting otherwise. I will keep this conflict of info in mind.
* You've pointed to the ZC706 bundle as having a xillybus_core known tested and working on a Kintex-7 with 4 lines. Great. I'll go swap it out and see if that helps. I'll let you know the results.
* You discuss the timing of FPGA configuration versus PC booting. We are up-to-speed on that. We have reliable config-from-flash occurring after cold start. However, we've found and researched to confirm that the jtag connection must be disconnected at re-power, and we're using the working Xilinx PCIe demo in the config memory. We've all said that the FPGA must be configured in advance, and our research/experiments tell us this is because it is the BIOS that does PCIe enumeration only at cold start. Given a good cold start and PCIe enumeration, we've successfully re-configured the FPGA via jtag, and then found as predicted that merely a warm start gets it up again. That's for a working bitstream, of course.
-Helmut
Eli,
Thanks. I'll try to clarify and respond...
* When I jtag config (not boot from config flash) with the x4-lane-modified Xillydemo, the host shows some BIOS info on the monitor. Under other circumstances, this BIOS info is followed by linux boot info. But in this case, after the BIOS info comes nothing. Shortly thereafter the monitor powers off for lack of incoming signal. I believe either the BIOS is never finishing or linux boot is never getting past the very early stages. I suspect BIOS for this reason. When boot order was to boot from a PCIe/104 nic first, the BIOS message trying to boot from the nic was stuck showing. The BIOS was stuck. When boot order was to boot from disk first, we got the monitor power off as described. My theory was that the PCIe bus was getting [somehow hung up, no specific knowledge] and this made the BIOS get stuck trying to boot from the nic. During this time, however, the VIO on the FPGA showed that the FPGA's low level Xilinx PCIe code had the link UP. So the PCIe bus wasn't totally messed up, just a little messed up. To recap, the link was up but the bus seems hung. Subsequently, I took the working Xilinx demo and commented out the "app"lication. Then that one started hanging the host boot as well. This makes me think that the PCIe bus is getting hung up due to some higher level transaction situation, at a level above "link up", and at a level that the Xilinx demo "app"lication and analogously the xillybus_core handle. Call both those "applications". So these applications must do some transactions and when they fail to do so or fail to do it right, the PCIe bus gets hung up enough, even though the link is up, to hang the remainder of the boot.
* You have said *indirectly* that the xillybus_core *should* be agnostic about number of lanes. Thanks for the info. You're surely correct, but in spite of that my testing is strongly suggesting otherwise. I will keep this conflict of info in mind.
* You've pointed to the ZC706 bundle as having a xillybus_core known tested and working on a Kintex-7 with 4 lines. Great. I'll go swap it out and see if that helps. I'll let you know the results.
* You discuss the timing of FPGA configuration versus PC booting. We are up-to-speed on that. We have reliable config-from-flash occurring after cold start. However, we've found and researched to confirm that the jtag connection must be disconnected at re-power, and we're using the working Xilinx PCIe demo in the config memory. We've all said that the FPGA must be configured in advance, and our research/experiments tell us this is because it is the BIOS that does PCIe enumeration only at cold start. Given a good cold start and PCIe enumeration, we've successfully re-configured the FPGA via jtag, and then found as predicted that merely a warm start gets it up again. That's for a working bitstream, of course.
-Helmut