UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
1,520 Views
Registered: ‎11-10-2014

Accessing PL through Petalinux 2017.4 freezes PS, but through uboot works

Jump to solution

I'm not one to ask questions, but I've been fighting Xilinx' tools for days now, and I'm finally at the point where I'm very much out of my league (and out of time to learn things on my own).

My goal for as far as it's relevant for my current problem is to get some form of Linux running on a TE0720 (= XC7Z020 CLG484-2) to serve pretty much only as a convenient way to program and communicate with the PL over Ethernet. After beating Petalinux 2017.4's installer into submission I managed to get a Petalinux build to boot on the board. My problem right now is that /dev/mem isn't working the way I'm expecting it to.

Basically, accessing M_AXI_GP0/1 (physical address 0x40000000..0xBFFFFFFF) through /dev/mem results in a freeze of the PS, without any kernel prints on the UART, that only a hard board reset or power cycle will recover from.

The logical conclusion would be that there is something wrong with the AXI slaves connected to those ports, leaving the PS waiting for an AXI response that isn't coming for some reason. But after ~two days of debugging my own stuff I found out that:
 - a bitstream with just autoconfigured Xilinx IP connected to M_AXI_GP0 and M_AXI_GP1 (block RAM controllers + dual port block RAM) reproduces the problem.
 - accessing the addresses from u-boot's shell actually works just fine.

So as far as I know I've pretty much ruled out everything aside from the kernel messing something up. That's something that I don't know much about, being primarily a VHDL guy.

Additional information that may or may not be helpful/related:

I'm using an in-house tool to access /dev/mem, which really just mmaps a portion of /dev/mem and exposes it over TCP. I know this tool works on the PYNQ image, because it's used extensively by the MSc students in our group. Nevertheless, I tried to reproduce it from the command line with dd/skip, but interestingly enough that gives me a bad address error for anything above 0x30000000 (or something close to that number). Of course dd doesn't mmap /dev/mem like you're supposed to, but other than that I'm not sure where that barrier is coming from.

 

I also tried just using the PYNQ image (since that amounted to nothing more than swapping out uSD cards), but unfortunately the PYNQ board is too different for that to boot at all. I'm guessing the UART is at different MIOs, or maybe the 400 and 484 packages are more different than I'm expecting them to be. The initial PYNQ bitstream would cause problems later anyway.

I've noticed that the kernel is ignoring the "memory" device tree entry, or at least is overriding it; whatever I set the range to, it defaults to <0x0 0x40000000> (the whole 1GiB DDR memory) when read through /prov/device-tree. The reason I know this is that I'm reserving DDR for PL use, which I ended up doing using a "reserved-memory" node for. When I realized the 0x40000000 barrier wasn't due to broken hardware I also tried extending the memory and reserved memory regions to encompass everything up to 0xC0000000, with no discernible change in behavior. In case it matters, the reserved memory region is set to <0x20000000 0x20000000> and I've confirmed that it is working by observing that /proc/meminfo now only reports 512MiB total and observing obvious uninitialized DDR garbage in that address range.

The only nonstandard things in my Petalinux build right now are, for as far as I'm aware, the reserved memory region in the device tree, and that I have the rootfs on the second partition of the card instead of baked into the image so I don't have to reupload my memory access server program using scp every time the board crashes (and I'm hoping to make it autostart later when everything is stable).

uname -a in case anyone wants to know the exact kernel version:
Linux test_boot 4.9.0-xilinx-v2017.4 #1 SMP PREEMPT Thu Mar 22 16:25:06 CET 2018 armv7l GNU/Linux

Looking through the forums here I saw some people were having problems because the PS-PL level shifters were disabled for some reason, and even though those people also couldn't access the PL from u-boot I did verify that 0xF8000900 reads back as 0x0000000F from within Linux, so the kernel isn't botching that at startup for some silly reason.

 

The PL clock I'm using is configured to 100MHz. I'm pretty sure that is (still) configured correctly after Linux boots, or at least it was in my earlier tests with my PL logic; it forwards the clock as an LVDS pair for an ASIC, which I was able to discern through the noise on my poor little 100MHz bandwidth scope, sort of.

Does anyone have any idea where I can even start looking at this point? Any and all help is appreciated.

 

- Jeroen

0 Kudos
1 Solution

Accepted Solutions
1,767 Views
Registered: ‎11-10-2014

Re: Accessing PL through Petalinux 2017.4 freezes PS, but through uboot works

Jump to solution

I've managed to solve the problems I was having by pretty much just starting everything from scratch (both the Vivado project and Petalinux build).

 

To anyone with similar issues:

 

I think stuff went wrong for me because I originally built a kernel with a hardware definition file from a PL project with just a PS in the block diagram with no busses attached, and never (fully) rebuilt it for an HDF that had. I also confirmed using the JTAG interface that the kernel was actively breaking something; somewhere around the time udev loads accesses stopped working (+/- a second or so). The first access fails gracefully with a timeout, after which the interconnect is left in a bad state and responds with only an error code until reboot. Finally, I found that my device tree initially did not have an entry for the M_AXI_GP0 when it should have had, but adding that to the kernel I had originally compiled wasn't enough to fix it. Maybe some driver wasn't being compiled into it because Petalinux figured it wasn't needed?

 

In any case, godspeed.

View solution in original post

0 Kudos
4 Replies
1,768 Views
Registered: ‎11-10-2014

Re: Accessing PL through Petalinux 2017.4 freezes PS, but through uboot works

Jump to solution

I've managed to solve the problems I was having by pretty much just starting everything from scratch (both the Vivado project and Petalinux build).

 

To anyone with similar issues:

 

I think stuff went wrong for me because I originally built a kernel with a hardware definition file from a PL project with just a PS in the block diagram with no busses attached, and never (fully) rebuilt it for an HDF that had. I also confirmed using the JTAG interface that the kernel was actively breaking something; somewhere around the time udev loads accesses stopped working (+/- a second or so). The first access fails gracefully with a timeout, after which the interconnect is left in a bad state and responds with only an error code until reboot. Finally, I found that my device tree initially did not have an entry for the M_AXI_GP0 when it should have had, but adding that to the kernel I had originally compiled wasn't enough to fix it. Maybe some driver wasn't being compiled into it because Petalinux figured it wasn't needed?

 

In any case, godspeed.

View solution in original post

0 Kudos
Scholar vanmierlo
Scholar
1,431 Views
Registered: ‎06-10-2008

Re: Accessing PL through Petalinux 2017.4 freezes PS, but through uboot works

Jump to solution

Whenever you make changes to the Zynq configuration in your Block Design, you need to export these changed settings to an HDF and import them into your Petalinux project. All these settings correspond to register settings in the ARM hardware and its peripherals. And it is the FSBL that configures those registers with the information found in the HDF.

0 Kudos
Contributor
Contributor
1,093 Views
Registered: ‎05-22-2018

Re: Accessing PL through Petalinux 2017.4 freezes PS, but through uboot works

Jump to solution

Hi @vanmierlo:
How to manually update those registers to avoid changing of FSBL everytime?

 

Thanks.

0 Kudos
Scholar vanmierlo
Scholar
1,079 Views
Registered: ‎06-10-2008

Re: Accessing PL through Petalinux 2017.4 freezes PS, but through uboot works

Jump to solution

Well, you could let the kernel driver patch things up. Or you might even be able to change the registers from user space with root privileges, but I would not recommend that. And would you want to find out what set of register modifications are required for your new Vivado Zynq configuration?

0 Kudos