qemu-arm
[Top][All Lists]
Advanced

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

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


From: Joel Stanley
Subject: Re: [PATCH 2/2] hw/arm/aspeed: add Bletchley machine type
Date: Tue, 8 Mar 2022 23:07:23 +0000

On Tue, 8 Mar 2022 at 17:23, Patrick Williams <patrick@stwcx.xyz> wrote:
>
> 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.

It looks like that branch missed the 7.2 boat. Given it's imminent
release, we should update the branch to Cedric's aspeed-7.0 when 7.0
is tagged.

With this branch could do CI on Rainier (or S6Q, or transformers) with
the eMMC image. I think there's value in doing CI on both eMMC and SPI
machines.

I'd like to see a boot test added for all of the machines in CI. Most
(all?) machines will get to bmc standby by booting on a generic Qemu
machine, such as the evb.

The machines that do have more of the system modelled could boot that
instead, and in the future add further tests.

>
> 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



reply via email to

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