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: Cédric Le Goater
Subject: Re: [PATCH 2/2] hw/arm/aspeed: add Bletchley machine type
Date: Tue, 8 Mar 2022 09:14:07 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0


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

Thanks,

C.



reply via email to

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