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