On Sat, Nov 12, 2022 at 08:37:38AM +0800, Bin Meng wrote: > Hi Conor, > > On Sat, Nov 12, 2022 at 8:31 AM Conor Dooley <co...@kernel.org> wrote: > > > > On Thu, Nov 10, 2022 at 12:18:44AM +0100, Philippe Mathieu-Daudé wrote: > > > Hi Conor, > > > > > > On 9/11/22 20:08, Conor Dooley wrote: > > > > From: Conor Dooley <conor.doo...@microchip.com> > > > > > > > > @@ -168,6 +170,10 @@ static void mchp_pfsoc_ioscb_realize(DeviceState > > > > *dev, Error **errp) > > > > "mchp.pfsoc.ioscb.cfg", > > > > IOSCB_SUBMOD_REG_SIZE); > > > > memory_region_add_subregion(&s->container, IOSCB_CFG_BASE, > > > > &s->cfg); > > > > + memory_region_init_io(&s->ccc, OBJECT(s), &mchp_pfsoc_dummy_ops, s, > > > > + "mchp.pfsoc.ioscb.ccc", IOSCB_CCC_REG_SIZE); > > > > + memory_region_add_subregion(&s->container, IOSCB_CCC_BASE, > > > > &s->ccc); > > > > > > Unrelated but using the TYPE_UNIMPLEMENTED_DEVICE would ease tracing all > > > these block accesses, as the block name would appear before the > > > address/size. See for example aspeed_mmio_map_unimplemented(); > > > > Certainly looks like a nice idea, and I gave it a go but kept running > > into issues due to my lack of understanding of QEMU :) I'm going to add > > this to my todo pile - while I have a v2 of this lined up, I'd rather > > not hold up adding the regions that prevent booting Linux etc as I > > fumble around trying to understand the hierarchy of devices required to > > set up something similar to your aspeed example. > > > > Do you plan to bring QEMU support to the latest MSS_LINUX configuration [1]
"Yes". Our goal is to merge both the LINUX and BAREMETAL configurations in an upcoming reference design release. Notably absent from anything that I have sent here is any changes to the DDR configuration (and that and how the PCI root port is connected to the MSS are the only real differences between the two). Currently, the LINUX one has 2 GiB of DDR at 0x10_0000_0000 & that's what the vendor kernel uses. None of upstream Linux, U-Boot or QEMU support that configuration. The baremetal one has 1 GiB at 0x8000_0000 and 1 GiB at 0x10_0000_0000. When the two are merged, it'll be 1 GiB at 0x8000_0000 and 1 GiB at 0x10_4000_0000 - there's currently a v2022.10 reference design job file on [1] that's got this configuration but we are waiting for a corresponding release of Libero to properly release the tcl scripts etc. We're upstreaming U-Boot and Linux support for that configuration at the moment - but it's just a dts change there so no real concern about breaking any backwards compat as the older devicetrees will continue to work. > Currently QEMU is supporting the MSS_BAREMETAL configuration. Do you > think it makes sense to support both? > [1] https://github.com/polarfire-soc/icicle-kit-reference-design I was kinda hoping to leave that part of things as-is for now and wait for the merged configuration. My main question with that is: do the older reference design configurations need to remain supported? The PCI root port stuff likely doesn't matter since it's not modelled (yet) by QEMU anyway but the DDR bit is going to be incompatible. The addresses at which DDR lies are controlled by the seg registers. These are briefly documented in the TRM (4.5 Segmentation Blocks) but IMO pretty badly explained there. IIUC, for bare metal applications that's set by the HAL from the XML exported by MSS configurator & for anything started via the HSS, the HSS does it instead. I was thinking something like defaulting the DDR configuration to the new, merged configuration & then if someone writes to the seg registers (which, IIUC, a bare-metal app does) changing the addresses at which QEMU places the DDR at runtime. That's what the hardware does, but I have put approximately zero thought into how to implement that. Without something like that, idk how we'd keep both newer and older reference designs working in QEMU. > Do you plan to bring QEMU support to the latest MSS_LINUX configuration Either way, any plans are dependant on me finding the time. I'm mostly just upstreaming the small changes that I need to make so that QEMU remains usable as a debugging tool for Linux stuff. Thanks, Conor.
