On Sun, Dec 08, 2019 at 11:19:33PM -0800, Guenter Roeck wrote: > On 12/8/19 10:42 PM, Michal Simek wrote: > > Hi, +Edgar > > > > > > On 08. 12. 19 23:38, Guenter Roeck wrote: > > > On Fri, Oct 18, 2019 at 06:07:31PM +0200, Michael Tretter wrote: > > > > From: Rajan Vaja <rajan.vaja@xxxxxxxxxx> > > > > > > > > Add firmware DT node in ZynqMP device tree. This node > > > > uses bindings as per new firmware interface driver. > > > > > > > > Signed-off-by: Rajan Vaja <rajanv@xxxxxxxxxx> > > > > Signed-off-by: Michal Simek <michal.simek@xxxxxxxxxx> > > > > Signed-off-by: Michael Tretter <m.tretter@xxxxxxxxxxxxxx> > > > > > > With this patch applied in the mainline kernel, the qemu xlnx-zcu102 > > > emulation crashes (see below). Any idea what it might take to get > > > qemu back to working ? > > > > Driver talks through ATF to PMU unit(microblaze). I don't think A53+MB > > concept is working with mainline qemu. But crash is too hard. It should Yes, QEMU doesn't support the Cortex-A53s along with the PMU MicroBlaze. My workaround when using upstream QEMU is a modified DT without the PMU firmware and with fixed-clock nodes. > > be no response from PMU and then this panic. > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/xilinx/zynqmp.c?h=v5.5-rc1#n728 > > > > Isn't that a bit harsh too ? Normally one would print an error message > and abort driver instantiation. I agree, it would be nice if ATF & kernel drivers would somehow handle this more gracefully. Cheers, Edgar > > It sounds like you are saying that qemu's xlnx-zcu102 emulation is > no longer supported and expected to crash the kernel. Is this a > correct assumption ? If so, I'll drop it from my list of tests. > > Thanks, > Guenter