Re: [PATCH] hw/misc/pfsoc: add fabric clocks to ioscb

[Conor Dooley <conor@kernel.org>]

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 <conor@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.dooley@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.