Sorry, you need to enable JavaScript to visit this website.

linux crash after PL load

Unsolved
19 posts / 0 new
jeffallred's picture
jeffallred
Junior(0)
linux crash after PL load

I have made a simple hardware design for the PL. I can load it with either JTAG or by cat'ing the file into xdevcfg. Once the hardware is loaded, it functions properly. Howver, all contact with the PS (running Linux) is gone. No terminal, no ethernet. Is it not possible to just load a bit file with no reference to the processor? Looking in the UCF there doesn't appear to be any reference to any processor specific IOs. I'm guessing that I need to route some PS dedicated pins to some specific hardware pins, but I would have thought that could be done without anything loaded into the PL at all. Any insight would be appreciated.

TimDuffy's picture
TimDuffy
Junior(1)
jeffalred,

jeffalred,

Zynq is designed around the idea that the ARM cores are the center of the IC. With that being said, the PS must be up and running before the PL can be programmed.

Can you describe further your setup and configuration of how you went about creating your project and what you loaded into the PL?

jeffallred's picture
jeffallred
Junior(0)
I used the out of the box

I used the out of the box setup for the zed. Standard Linux demo.

Then I built a bitfile (using the UCF from this website) that simply sets the LEDs based. On the switches. Built it in ISE and created a BIN file with promgen. With the PS up and running, I loaded the bitfile over jtag. The Linux terminal window quit responding as well as ping stopped responding. Same thing when I used local Linux commands to load. Each time the Linux terminal stopped but the programmed functionality in PL worked as expected.

I thought the idea was that the processor cores are not dependent on the PL.

TimDuffy's picture
TimDuffy
Junior(1)
The PS is not dependent on

The PS is not dependent on the on the PL. I am going to make the assumption that the Linux kernel is trying to talk to the AXI peripherals on a regular interval, and when you reconfigure the PL it crashes because it can't talk.

I'll take a look and see what I can come up with for a 'proper procedure'.

jeffallred's picture
jeffallred
Junior(0)
Is it possible that one of

Is it possible that one of the kernel modules is polling on the AXI?

I have no problem putting in the minimal logic that would allow linux to stay alive. Just need to know what that minimal logic is.

Thanks for checking into it.

TimDuffy's picture
TimDuffy
Junior(1)
I agree that it is probably

I agree that it is probably something along those lines. That the OLED module is pinging the SPI bus - or something like that. Can you try and unload the OLED module by executing the script in /usr/bin/oled_unload?

jeffallred's picture
jeffallred
Junior(0)
I'm away from my board right

I'm away from my board right now, but I'll give it a shot as soon as I can.

TimDuffy's picture
TimDuffy
Junior(1)
Sounds good. I am away from

Sounds good. I am away from mine as well. When I am back in front of it I'll see what else I can come up with.

jeffallred's picture
jeffallred
Junior(0)
No go. I rmmod'd the pmodoled

No go. I rmmod'd the pmodoled_gpio module and tried to load in a bit file. Still crashes.

minm's picture
minm
Junior(0)
Is this problem be solved?

Hi jeffallred, I have tried to design a simple IPcore and use it in Linux. "FSBL.elf" can load your hardware bitstream to PL. Then, your hardware must have a AXI interface and connect it to the internal AXI interface of PS.All this can be finished in Xilinx Platform Studio(XPS). http://wiki.xilinx.com/zc702-boot-from-flash this website maybe helpful.
PS. I really no good at English.Sorry for the grammar mistake :)

jeffallred's picture
jeffallred
Junior(0)
You say "your hardware must

You say "your hardware must have a AXI interface". Is this a documented requirement? Is Linux polling the AXI or does the lack of an AXI interface in the PL cause an interrupt?

It seems very dangerous to the system if loading the PL with a design that doesn't include a particular interface causes the OS to crash.

minm's picture
minm
Junior(0)
AXI is the PS‐PL Interfaces

Hi jeffallred,You must have read this document, "Zynq-7000 EPP Technical Reference Manual". In the page 32,it's to said 'there are two type of interfaces between the PL and the PS'.One is functional interfaces, the other is configuration signals. I don't know how do you connect your hardware design to PS, but if you don't use any functional interface, it's dangerous I think. My IPcore make by XPS works well, and Linux device driver works well too. It never causes the OS to crash.
PS. If you haven't read the document you can search it in www.xilinx.com.
If you think I can help you, is welcome to sent me a message for e-mail.

PS- PL boot

If you want to run linux and a custom bit file on the PS then:
1. boot Linux without any hardware ip in PS (no AXI based peripheral)
2. after linux boots load bit file through jtag
3. then run linux application by downloading elf file to linux file system using remote ARM run app.
Note: This is only to test PS & PL independently.
Ideally before Linux would start booting. all peripherals on PL should be ideally present. Does this make sense?

jeffallred's picture
jeffallred
Junior(0)
PS-PL boot

I know this thread has been inactive for a long time, but I want to revive it.

If I allow the FSBL to load the PL and then later reload the PL using JTAG I always get a Linux crash. I have even tried taking the standard bit files from the reference design and using them.

I'm interested in two things: First, I want to be able to reconfigure the PL at will. And second, the process of placing the bit file into the image for the FSBL is a bit time consuming.

Has anyone been able to reconfigure the PL under Linux without a crash?

deaxman's picture
deaxman
Junior(0)
I have this problem as well

When you load the program to the PL does the Diligent logo disapear from the display? I have this proglem too, it's like linux crashes whenever I try to load a simple bit file, I've tried both ways of loading the file (jtag and usb) and neither work, I haven't tried loading it through the terminal yet.

deaxman's picture
deaxman
Junior(0)
Maybe a solution?

Did you ever solve this problem? Part of me thinks that it is because whenever I load the bit files for the FPGA (PL) and PS i bypass the PS (ARM) in iMPACT because I can't find the correct configuration file. I am assuming that this will do nothing at all to the currect configuration of the PS/arm processor but it could be that programming in any way resets everything and that in order to have linux be reloaded it must be set in the configuration under the ARM PROCESSOR portion of the JTAG chain in iMPACT or whatever else you may be using to program it.

ejubenville's picture
ejubenville
Junior(0)
Device tree vs. XPS memory map

Although the claim is that the PS and PL are independent, my intuition tells me that isn't the case. Booting with Linux requires a device tree binary file on the SD card so that the OS can know which peripherals are defined, their addresses, etc. It uses that information to load and run drivers. The peripheral addresses seem to be defined within XPS. If I change the addresses in XPS, build a new bitstream and load it, wouldn't I reasonably expect Linux to have a fit? Additionally, if there are any drivers actively talking to hardware, and the PL goes through a reset at the start or completion of the bitstream load, wouldn't I reasonably expect the OS to experience an AXI bus error? The idea that the PS and PL are independent doesn't seem like it is possible to me.

heelancd's picture
heelancd
Junior(0)
Same problem in QNX

Bump

I'm running a QNX port to the Zedboard (from a ZC702 version). I have a PL configuration file that uses the GP and ACP interfaces for interrupts and reading values from some BRAM using a CDMA.

Everything runs great when I boot and the FSBL configures the logic. If I try and reconfigure the PL with the exact same PL configuration (bin file instead of a bit file), QNX still runs fine. But as soon as I try to access anything over the AXI, the whole system hangs as described above.

Does anyone have any insight to this? Could it be a problem with the silicon revision shipped with the Zedboard...? I haven't seen anyone else describing this scenario on other forums except for a random errata case when you try and access OCM and DDR from the PL at the same time (which I'm not doing).

Looking at the FSBL code compared to the Linux and QNX PL drivers, there seems to be a PL "initialization" that happens at boot. I'm wondering if something like that might be necessary when reconfiguring...

I guess it could also be a problem with my PL design. Maybe a reset isn't going to every piece from the PS, so the PL is cranking away while the PS tries to reconfigure the PL. I wouldn't think this would result in a system crash, but this new kind of SoC has some strange quirks to it.

Anyone else make any progress?

heelancd's picture
heelancd
Junior(0)
Quick follow-up

I just found this forum discussion:

http://forums.xilinx.com/t5/Embedded-Linux/Zynq-Loading-bitfile-into-FPG...

Sounds similar to what we're describing. I've been using the promgen method so I'm going to double check my command options. If there's nothing there, I'm going to try the bootgen method. I'll report back if I have any success.