qemu-riscv
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-riscv] [Qemu-devel] [PATCH for-3.2 v7 5/6] hw/riscv/sifive_u:


From: Palmer Dabbelt
Subject: Re: [Qemu-riscv] [Qemu-devel] [PATCH for-3.2 v7 5/6] hw/riscv/sifive_u: Connect the Xilinx PCIe
Date: Wed, 21 Nov 2018 13:26:54 -0800 (PST)

On Wed, 21 Nov 2018 10:32:45 PST (-0800), address@hidden wrote:
On Wed, Nov 21, 2018 at 10:05 AM Logan Gunthorpe <address@hidden> wrote:



On 2018-11-21 10:02 a.m., Alistair Francis wrote:
> Connect the Xilinx PCIe device based on the information in the device
> tree stored in the ROM of the HiFish Unleashed board.

I only briefly tested this patch but could not get any PCI devices to
come up with the sifive_u machine. Depending on the kernel I tried, it
either failed to initialize a Xilinx PCIe (likely due to a mismatch with
the DT) or it appears to successfully initialize a Microsemi device but
did not enumerate any devices underneath.

That seems like either a kernel or bbl issue.

You need to make sure that bbl doesn't edit the device tree (to add
the Microsemi device or remove the Xilinx one) and ensure your kernel
supports the Xilinx one.


In any case, it would be nice if the Microsemi/Xilinx confusion was at
least explained in the commit message.

What should we say? The QEMU machine accurately models the real
hardware which reports a Xilinx PCIe. The confusion generally appears
above QEMU where people are used to using the MicroSemi one.

I think the real issue here is that "sifive_u" doesn't actually fully describe the device we're trying to emulate. Is it a:

* Generic SiFive U core? In that case we just have a 64-bit core and essentially no devices. This is kind of useless. * A HiFive Unleashed? In that case there's no PCIe, as it requires an expansion board.
* A HiFive Unleashed + VC707?  Here we have Xilinx PCIe.
* A HiFive Unleashed + Microsemi Expansion?  Here have Microsemi PCIe.

There's a tradeoff between accurately emulating the hardware and blowing up the amount of targets we support in QEMU. We went through this discussion before and ended up where we are now, but maybe it's best to go have the discussion again?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]