On Wed, Nov 21, 2018 at 1:26 PM Palmer Dabbelt <pal...@sifive.com> wrote: > > On Wed, 21 Nov 2018 10:32:45 PST (-0800), alistai...@gmail.com wrote: > > On Wed, Nov 21, 2018 at 10:05 AM Logan Gunthorpe <log...@deltatee.com> > > 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.
This isn't even always consistent. For example the sifive_u machine exists for 32-bit cores, but the PCIe address reported by the hardware only works for 64-bit machines. So we need a trade off between accurately modelling the hardware or having 32-bit support. > > 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? Up to you, it is your board :) I think it makes more sense to remove these generic boards (that is what the virt board is for) and model real hardware boards. Alistair
