DMA Kernel panics

Question

Hi,

over the past few days, I desperately tried to build my own bootloader kernel etc. without using Petalinux, because I already have my own ecosystem based on Yocto and meta-xilinx.

I started with all git HEADs for U-Boot, ATF and the Linux kernel and wanted to use U-Boot as an SPL. Which didn't work at all, because the newest git HEAD of U-Boot actually needs a PMU firmware in version 0.3 which is nowhere to be found. That's very annoying!

So I fell back to older releases of all the components which were 2016.4. I managed to get a fully working FSBL, U-Boot 2016.4 with ATF and Linux 2016.4. When including the PMU firmware in the boot image, the 4.6 kernel breaks because the SD-Card controller fails to initialize. It works without loading a custom PMU firmware. I can't use the current 4.9 kernel, because this in turn needs a PMU firmware with version 0.3. AAAHHH!

Okay, back to kernel 4.6 without a PMU firmware then. It booted up into my userland and I was quite happy. But after a while of using the system on this kernel, I get a bunch of kernel panics caused from different DMA operations happening in different components. Sometimes the SD-Card fails, sometimes the MACB NIC driver. Even the slightest bit of load on the network card causes a fatal kernel panic in the interrupt context.

Then I tried Petalinux 2016.4. I can't get this to work properly either. First the U-Boot complained about a messed up memory config in the device tree (https://www.xilinx.com/support/answers/68390.html) which I eventually managed to fix by editing the correct dts file which doesn't get overwritten by the generation tools. But then I can't properly boot the system, because the U-Boot confuses the first SHDC controller with the second one. Even though I boot from the external card, it always wants to load the kernel from the eMMC.

I basically gave up for now. Is there *any* combination of compoenents that work at all on this chip and which do not immediately crash?

Former Member · Accepted Answer

I finally fixed the kernel panic issue. The mistake I made is a bit embarrassing though: I copied the device-tree from a ZCU102 and modified it to fit the Ultrazed-EG on an IOCC, but what I forgot to change was the memory node. The ZCU102 has 4GB RAM, the Ultrazed-EG only has 2GB. Of course this leads so memory corruption sooner or later. Especially if your test case is downloading a large file via HTTP to the SD which causes a lot of data to be written into the filesystem cache. Funnily enough I tested a generated device-tree as well, but I only put that on the SD-Card for u-boot to load. But u-boot has its own device-tree which it uses by itself. And that one still contained the 4GB memory config. When u-boot loads a device-tree from the SD and jumps into the kernel it patches the memory-node in the just loaded (and correct) tree to contain the wrong memory config. That's why I never suspected the device-tree to be the culprit. I still don't know why Petalinux 2016.4 didn't work for me and was so unstable because it only uses generated (and thereby hopefully correct) device trees, but at this point I don't care anymore. A big thanks goes out to Invincea Labs. Using their code to build a known-working Image and replacing components in my image one by one made it possible for me to pin down the issue to the BOOT.bin and finally to u-boot.

DMA Kernel panics

Top Replies