Hi yyliang, I also want to program the PL while the Arm processor is running.I got the information from my FAE to analyze the First Stage Boot Loader. If there is not such a program available, we will build our own. What is your status here? Bahne
We can boot this on the Zedboard, but unfortunately, LAN does not connect to a 100 Mbit Switch, which is a problem as we need LAN to load additional files to the target at runtime.
Is there a way to change the Zedboard LAN configuration from 1GBit to 100Mbit, or is this an inherent design feature (so we need to connect to a 1Gbit capable switch) ?
Running the 14.5 / 2013.1 release as proposed by farseer works, but unfortunately the PS will hang (or die: no UART, no ethernet) as soon as we load a proper bit file into /dev/xdevcfg
Does the bitfile loaded possibly cause the PS to die, or is PS independent from PL here, so we have to look for bugs in the drivers?
I have been working on this same problem. I believe the new PL program must have ALL hardware that the kernel expect/has loaded.
But even then it does not seem to work properly.
If it not important to change the PL logic while the PS is running you can also try to make a new boot.bin file using the fsbl, u-boot and your own .bit file.
This is how I currently am able to make new hardware and use Linux to configure it.
The solution, as far as I can observe, is: it makes a difference whether the system initially starts from a BOOT.BIN that does contain PL logic or it starts from a BOOT.BIN that does not contain PL logic. In that first case, PS will always hang/die as soon as /dev/xdevcfg is loaded, in the latter case loading new PL at runtime is no problem. So we will start the system with PS-only BOOT.BIN, then load PL from Linux, then run the application.
Further, we switched to git://github.com/Xilinx/linux-xlnx.git for now, though there is no audio support with it. I'm not sure, whether this helped in solving the /dev/xdevcfg related problems, and we will check the https://github.com/analogdevicesinc/linux/tree/audio_zynq kernel again, as soon as we get back to solve audio access.
I'm seeing the same problem as most of you guys have mentioned. Linux always hangs after I send a PL bin file to /dev/xdevcfg, yet the new PL config works well. It makes no difference whether there is an initial PL configuration or not when the zynq board boots.
One thing to mention. My PL design is totally isolated from the PS. It does not talk to the PS whatsoever.
I'm using the latest kernel source from the Xilinx github.
If you have drivers in the kernel or otherwise loaded that need things in PL, you get the problems as described.
The fix is to build these drivers as modules, i.e. an "m" in the menuconfig, and load them AFTER programming the PL.
If you want to replace the logic, you can either use partial reconfiguration (vivado) and leave the parts intact that you need, or unload the related modules before replacing the logic.
For an example, use "my" OE zynq layer and it will set things up so that it boots without logic and activates the HDMI and audio components later on, after loading the bistream from the rootfs.
