Re: libflash questions mostly relating to P9 bringup

[Cyril Bur <cyrilbur@gmail.com>]

On Tue, 2016-10-11 at 17:55 +1100, Joel Stanley wrote:
> On Sat, Sep 24, 2016 at 11:41 AM, Xo Wang <xow@google.com> wrote:
> > 
> > Hi folks,
> > 
> > I'm under the impression for P9 bringup we're sticking with BMC-
> > side
> > MMIO to set up host PNOR access (as in what the host is booting
> > from
> > over LPC). I see—and agree—that we're not gonna have MTD working by
> > the time we need to boot early machines:
> > https://github.com/openbmc/openbmc/issues/553
> 
> We have mtd support written and in testing. I plan to land it this
> week.
> 
> I would like us to be able to disable /dev/mem access soon. pflash is
> one area where we almost have the bits in place, so I think we should
> push to go straight to the correct solution.
> 
> > 
> > 
> > What does libflash-based PNOR control look like? I mean the hacky
> > way
> > we're gonna use for the next month. This is how I *think* it works.
> > 
> > booting the host:
> > 1) the SMC SPI flash master auto-detects (?) how to read like the
> > FMC
> > 2) Swiss Army aspeed.c do_x_setup() enables LPC/AHB bridge to the
> > SPI
> > flash window
> > Is that it? Doesn't involve MTD or pflash at all and it just works?
> 
> Yes, I think so.
> 
> > 
> > 
> > updating PNOR from BMC:
> > 1) org.openbmc.control.Flash's update method calls op-flasher
> > 2) org.openbmc.control.Flasher invokes libflash erase and program
> > 3) libflash arch_flash_arm_io.h (?) and friends
> >   a. know how to talk to the flash controller (BMC_DIRECT)
> >   b. map AHB, GPIO, and SMC window from /dev/mem
> >   c. know the size of the host PNOR? (it looks hardcoded)
> 
> I suspect it uses the ffs header to determine the pnor size, but I do
> not know that code well.
> 

The ffs header has sizes but you could of course flash an ffs partition
smaller than the total flash and then the ffs size wouldn't be the
total size. If you mean the size of the flash, there are various
mechanisms, in this case (PNOR from BMC) libflash has a mapping between
flash chip ID and total size which it can report up to tools like
pflash.

Ideally this access method will go away in favour of the BMC kernel
exposing the flash through /dev/mtd

In the case where you would want to know this on the host then it
should be in the device-tree and subsequently exposed by the powernv
flash driver (https://github.com/open-power/linux/blob/master/drivers/m
td/devices/powernv_flash.c) though /proc/mtd

> > 
> > 
> > updating PNOR from host:
> > 1) whatever calls pflash on host
> > 2) host libflash powerpc_io.c and friends poke BMC registers over
> > LPC
> >   a. write whatever LPC stuff that turns on iLPC2AHB, then use that
> > to
> > set GPIO and SMC window to LPC for host access
> >   b. powerpc_io.c also overwrites the LPC/AHB bridge mapping
> > (previous
> > set by BMC kernel) with its own desired config
> 
> Hacky. Not really supported.

I should apologise, if we're talking about https://github.com/open-powe
r/skiboot/blob/master/external/pflash/powerpc_io.c, we shouldn't. That
code isn't used anymore and I doubt it will work. I'll send patches to
remove it!

Currently updating PNOR from the host, Joel is correct, it isn't really
supported by openbmc. Of course it can be done through /dev/mtd exposed
by host linux (https://github.com/open-power/linux/blob/master/drivers/
mtd/devices/powernv_flash.c) and backed by a driver in skiboot. I
really hope that all pflash binaries around today know how to do this.

> 
> > 
> > 
> > Can somebody review that I got all this right? I saw some
> > conflicting
> > information in https://github.com/openbmc/linux/issues/51
> > 
> > Other questions:
> > - what's the plan for "booting the host" and "updating PNOR from
> > BMC?"
> 
> We plan to expose the contents with an in-memory copy of the
> firmware.
> 
> > 
> > - is it worth extending the current libflash to read BMC & PNOR
> > size,
> > window, etc from device tree?
> > - what does arch_flash_powerpc.c do? It looks like a whole other
> > access method with a host-side MTD device.

Hopefully I've answered that...

> > 
> > thanks
> > xo
> > _______________________________________________
> > openbmc mailing list
> > openbmc@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/openbmc