Using mmap against aspeed-lpc-ctrl device - weird bytes :D

[Patrick Venture]

On Fri, Jan 18, 2019 at 10:52 AM Patrick Venture <venture at google.com> wrote:
>
> On Fri, Jan 18, 2019 at 10:38 AM Patrick Venture <venture at google.com> wrote:
> >
> > Just to give you some context snippets:
> >
> > System DTS snippet:
> >
> > reserved-memory {
> >  #address-cells = <1>;
> >  #size-cells = <1>;
> >  ranges;
> >  lpc_mapped_memory: region at 98000000 {
> >   no-map;
> >   reg = <0x98000000 0x00800000>; /* 8MB */
> >  };
> > };
> >
> > &lpc_ctrl {
> >  status = "okay";
> >  memory-region = <&lpc_mapped_memory>;
> >  flash = <&spi1>; // spi disabled, but needed for lpc_ctrl to probe
> > };
> >
> > So, on the BMC, it receives the host's memory map address --> so it
> > can configure the window:
> >
> > https://github.com/openbmc/phosphor-ipmi-flash/blob/master/lpc_aspeed.cpp#L42
> >
> > Then the host tool, mmap's to the host set-aside address, 4KiB, and
> > tells the BMC to copy out the 4KiB:
> >
> > https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-ipmi-flash/+/17505
>
> Reading the mapping code more closely, I see I'm setting the offset to
> the memory window -- this made sense when using /dev/mem, but for
> aspeed-lpc-ctrl maybe it should be 0.  Testing that now.

Using an offset of 0 in the mapping call, which makes sense, is
providing bytes that appear to be legitimate.

Thanks for letting me think out loud.

>
> >
> > Keep in mind, previously this was working by the BMC opening /dev/mem
> > and mapping against lpc_mapped_memory -- but now we're opening
> > aspeed-lpc-ctrl.  In the code above, regionAddress ==
> > lpc_mapped_memory, and regionSize is 64KiB.
> >
> > Can you take a look to at least sanity check this?
> >
> > It ends up copying out data that looks like this:
> >
> > 00000000  0a 00 01 00 0a 00 01 00  0a 00 01 00 0a 00 01 00  |................|
> > *
> > 00001000
> >
> > Patrick