Re: [PATCH 2/2] hw/arm/aspeed: add Bletchley machine type

[Patrick Williams <patrick@stwcx.xyz>]

[-- Attachment #1: Type: text/plain, Size: 1999 bytes --]

On Tue, Mar 08, 2022 at 09:14:07AM +0100, Cédric Le Goater wrote:
> 
> >> There are two flash devices on the FMC. I can fix it inline since
> >> it is the only change I would request.
> > 
> > Yes, there are.  I think all of the Facebook systems have dual FMC, for
> > redundancy in hardware, but we can get by in QEMU with just a single one.
> 
> yes, the kernel will complain though and I don't know how robust
> the spi-nor based driver is. I think you sent a patch for a related
> issue.
> 
> The newer spi-mem driver should be fine.

Oh yes.  I already forgot that I'm running with that patch since Joel added it
to our backport 5.15 branch.  One of the reasons I wrote that patch was to make
QEMU not kpanic. :(

>   
> > I'll see however you fix it up and see I can update all the other systems as
> > well.  
> 
> ok. may be for 7.1 then.
> 
> > We have an internal patch to expand the CS on FMC to 2 but we haven't
> > upstreamed it yet and I'm worried it will break some users w.r.t. the CLI
> > changing for adding images.  
> 
> Yes. That's the problem. I am afraid some CI systems will break with
> these change in a newer QEMU. The command line options will need to
> adapt.

My recollection is that the Romulus CI uses a branch of QEMU that at this point
is rather old anyhow.  We should be able to fix up the CI scripts at the same
time we upgrade.

Are you or Andrew J maintaining that branch?

> > My recollection is that the Romulus CI on OpenBMC relies on the PNOR 
> > being the 2nd argument.
> 
> That's the initial assumption made years ago. First mtd device is FMC,
> second is the PNOR. It is reaching its limits.
> 
> I am looking at improving the command line argument to support:
> 
>    -drive file=<file>,format=raw,id=drive0 -device mx66l1g45g,bus=ssi.0,drive=drive0
> 
> which we would clearly define the topology. Adding a cs=[0-5] or and
> addr=[0-5] is the next step.

Seems fine to me.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]