Supporting new interfaces in phosphor-ipmi-flash

Supporting new interfaces in phosphor-ipmi-flash

[Troy Lee]

Hi team,

For security consideration, user might want to disable AST2500/AST2600 P2A functionality by default. To compensate the effect to phosphor-ipmi-flash, we're planning to support two alternative in-band firmware upgrade over PCIe for AST2500/AST2600 (AST2520 and AST2620 are excluded):
 - Through a reserved **VGA** memory on BAR[0], or
 - Through a reserved **PCIe** shared memory on BAR[1]

The usage pretty much the same as P2A, but it runs on different BAR, offset and length.
This will involves modifying phosphor-ipmi-flash/[tools|bmc]. Should I create new **interfaces**, e.g. astpcie/astvga?

Thanks,
Troy Lee

Re: Supporting new interfaces in phosphor-ipmi-flash

[Patrick Venture]

On Wed, Jan 27, 2021 at 1:44 AM Troy Lee <troy_lee@aspeedtech.com> wrote:
>
> Hi team,
>
> For security consideration, user might want to disable AST2500/AST2600 P2A functionality by default. To compensate the effect to phosphor-ipmi-flash, we're planning to support two alternative in-band firmware upgrade over PCIe for AST2500/AST2600 (AST2520 and AST2620 are excluded):
>  - Through a reserved **VGA** memory on BAR[0], or
>  - Through a reserved **PCIe** shared memory on BAR[1]
>
> The usage pretty much the same as P2A, but it runs on different BAR, offset and length.
> This will involves modifying phosphor-ipmi-flash/[tools|bmc]. Should I create new **interfaces**, e.g. astpcie/astvga?

I'm not sure it makes sense to create new interfaces, but rather to
add optional parameters for those differences... but I've added some
people to the reply line to help answer.

>
> Thanks,
> Troy Lee
>
>

Re: Supporting new interfaces in phosphor-ipmi-flash

[Benjamin Fair]

On Wed, 27 Jan 2021 at 08:04, Patrick Venture <venture@google.com> wrote:
>
> On Wed, Jan 27, 2021 at 1:44 AM Troy Lee <troy_lee@aspeedtech.com> wrote:
> >
> > Hi team,
> >
> > For security consideration, user might want to disable AST2500/AST2600 P2A functionality by default. To compensate the effect to phosphor-ipmi-flash, we're planning to support two alternative in-band firmware upgrade over PCIe for AST2500/AST2600 (AST2520 and AST2620 are excluded):
> >  - Through a reserved **VGA** memory on BAR[0], or
> >  - Through a reserved **PCIe** shared memory on BAR[1]
> >
> > The usage pretty much the same as P2A, but it runs on different BAR, offset and length.
> > This will involves modifying phosphor-ipmi-flash/[tools|bmc]. Should I create new **interfaces**, e.g. astpcie/astvga?
>
> I'm not sure it makes sense to create new interfaces, but rather to
> add optional parameters for those differences... but I've added some
> people to the reply line to help answer.

I'd also prefer optional parameters so we can keep all these PCIe
configurations grouped together.

>
> >
> > Thanks,
> > Troy Lee
> >
> >

Re: Supporting new interfaces in phosphor-ipmi-flash

[Andrew Jeffery]

On Wed, 27 Jan 2021, at 20:13, Troy Lee wrote:
> Hi team,
> 
> For security consideration, user might want to disable AST2500/AST2600 
> P2A functionality by default. To compensate the effect to 
> phosphor-ipmi-flash, we're planning to support two alternative in-band 
> firmware upgrade over PCIe for AST2500/AST2600 (AST2520 and AST2620 are 
> excluded):
>  - Through a reserved **VGA** memory on BAR[0], or
>  - Through a reserved **PCIe** shared memory on BAR[1]
> 
> The usage pretty much the same as P2A, but it runs on different BAR, 
> offset and length.
> This will involves modifying phosphor-ipmi-flash/[tools|bmc]. Should I 
> create new **interfaces**, e.g. astpcie/astvga?
> 

This is the HOST2BMC functionality in the 2600 datasheet?

It would be great to have more detail on how it works.

Andrew

Re: Supporting new interfaces in phosphor-ipmi-flash

[Troy Lee]

Hi,

The 01/28/2021 01:48, Benjamin Fair wrote:
> On Wed, 27 Jan 2021 at 08:04, Patrick Venture <venture@google.com> wrote:
> >
> > On Wed, Jan 27, 2021 at 1:44 AM Troy Lee <troy_lee@aspeedtech.com> wrote:
> > >
> > > Hi team,
> > >
> > > For security consideration, user might want to disable AST2500/AST2600 P2A functionality by default. To compensate the effect to phosphor-ipmi-flash, we're planning to support two alternative in-band firmware upgrade over PCIe for AST2500/AST2600 (AST2520 and AST2620 are excluded):
> > >  - Through a reserved **VGA** memory on BAR[0], or
> > >  - Through a reserved **PCIe** shared memory on BAR[1]
> > >
> > > The usage pretty much the same as P2A, but it runs on different BAR, offset and length.
> > > This will involves modifying phosphor-ipmi-flash/[tools|bmc]. Should I create new **interfaces**, e.g. astpcie/astvga?
> >
> > I'm not sure it makes sense to create new interfaces, but rather to
> > add optional parameters for those differences... but I've added some
> > people to the reply line to help answer.
> 
> I'd also prefer optional parameters so we can keep all these PCIe
> configurations grouped together.
> 
Understood. I'll see if I can design it as parameters, either on
compiler time or runtime. Thers is a little different in BMC side, the
ioctl might be different.

> >
> > >
> > > Thanks,
> > > Troy Lee
> > >
> > >

Thanks for suggestion,
Troy Lee

Re: Supporting new interfaces in phosphor-ipmi-flash

[Troy Lee]

Hi Andrew,

The 01/28/2021 07:14, Andrew Jeffery wrote:
> 
> 
> On Wed, 27 Jan 2021, at 20:13, Troy Lee wrote:
> > Hi team,
> > 
> > For security consideration, user might want to disable AST2500/AST2600 
> > P2A functionality by default. To compensate the effect to 
> > phosphor-ipmi-flash, we're planning to support two alternative in-band 
> > firmware upgrade over PCIe for AST2500/AST2600 (AST2520 and AST2620 are 
> > excluded):
> >  - Through a reserved **VGA** memory on BAR[0], or
> >  - Through a reserved **PCIe** shared memory on BAR[1]
> > 
> > The usage pretty much the same as P2A, but it runs on different BAR, 
> > offset and length.
> > This will involves modifying phosphor-ipmi-flash/[tools|bmc]. Should I 
> > create new **interfaces**, e.g. astpcie/astvga?
> > 
> 
> This is the HOST2BMC functionality in the 2600 datasheet?
> 
> It would be great to have more detail on how it works.
> 
> Andrew

No, it doesn't use HOST2BMC interface, it uses VGA controller's mmio.
Perhaps HOST2BMC is also a possible solution, too.

02:00.0 0300: 1a03:2000 (rev 51) (prog-if 00 [VGA controller])
        Subsystem: 1a03:2000
        Flags: bus master, medium devsel, latency 0, IRQ 16
        Memory at f6000000 (32-bit, non-prefetchable) [size=16M]  <--- Option 1
        Memory at f7040000 (32-bit, non-prefetchable) [size=128K] <--- Option 2
        I/O ports at e000 [size=128]
        Expansion ROM at 000c0000 [disabled] [size=128K]
        Capabilities: [40] Power Management version 3
        Capabilities: [50] MSI: Enable- Count=1/4 Maskable- 64bit+
        Kernel driver in use: ast
        Kernel modules: ast

Option 1 allocates a 1MB memory from the end of VGA memory, so it will
need some change to VBIOS.

Option 2 allocates a 4K memory from BMC memory space. Since the buffer
is smaller, the ipmi-blob protocol overhead will be greater.


Thanks,
Troy Lee

Re: Supporting new interfaces in phosphor-ipmi-flash

[Andrew Jeffery]

On Thu, 28 Jan 2021, at 17:59, Troy Lee wrote:
> Hi Andrew,
> 
> The 01/28/2021 07:14, Andrew Jeffery wrote:
> > 
> > 
> > On Wed, 27 Jan 2021, at 20:13, Troy Lee wrote:
> > > Hi team,
> > > 
> > > For security consideration, user might want to disable AST2500/AST2600 
> > > P2A functionality by default. To compensate the effect to 
> > > phosphor-ipmi-flash, we're planning to support two alternative in-band 
> > > firmware upgrade over PCIe for AST2500/AST2600 (AST2520 and AST2620 are 
> > > excluded):
> > >  - Through a reserved **VGA** memory on BAR[0], or
> > >  - Through a reserved **PCIe** shared memory on BAR[1]
> > > 
> > > The usage pretty much the same as P2A, but it runs on different BAR, 
> > > offset and length.
> > > This will involves modifying phosphor-ipmi-flash/[tools|bmc]. Should I 
> > > create new **interfaces**, e.g. astpcie/astvga?
> > > 
> > 
> > This is the HOST2BMC functionality in the 2600 datasheet?
> > 
> > It would be great to have more detail on how it works.
> > 
> > Andrew
> 
> No, it doesn't use HOST2BMC interface, it uses VGA controller's mmio.
> Perhaps HOST2BMC is also a possible solution, too.
> 
> 02:00.0 0300: 1a03:2000 (rev 51) (prog-if 00 [VGA controller])
>         Subsystem: 1a03:2000
>         Flags: bus master, medium devsel, latency 0, IRQ 16
>         Memory at f6000000 (32-bit, non-prefetchable) [size=16M]  <--- Option 1
>         Memory at f7040000 (32-bit, non-prefetchable) [size=128K] <--- Option 2
>         I/O ports at e000 [size=128]
>         Expansion ROM at 000c0000 [disabled] [size=128K]
>         Capabilities: [40] Power Management version 3
>         Capabilities: [50] MSI: Enable- Count=1/4 Maskable- 64bit+
>         Kernel driver in use: ast
>         Kernel modules: ast
> 
> Option 1 allocates a 1MB memory from the end of VGA memory, so it will
> need some change to VBIOS.
> 
> Option 2 allocates a 4K memory from BMC memory space. Since the buffer
> is smaller, the ipmi-blob protocol overhead will be greater.
> 

Okay. So for Option 2 we need to coordinate on the BMC by reserving memory in 
the devicetree. What's the plan there? Where's that going to be documented?

Andrew

Re: Supporting new interfaces in phosphor-ipmi-flash

[Troy Lee]

Hi Andrew,

The 02/01/2021 07:19, Andrew Jeffery wrote:
> 
> 
> On Thu, 28 Jan 2021, at 17:59, Troy Lee wrote:
> > Hi Andrew,
> > 
> > The 01/28/2021 07:14, Andrew Jeffery wrote:
> > > 
> > > 
> > > On Wed, 27 Jan 2021, at 20:13, Troy Lee wrote:
> > > > Hi team,
> > > > 
> > > > For security consideration, user might want to disable AST2500/AST2600 
> > > > P2A functionality by default. To compensate the effect to 
> > > > phosphor-ipmi-flash, we're planning to support two alternative in-band 
> > > > firmware upgrade over PCIe for AST2500/AST2600 (AST2520 and AST2620 are 
> > > > excluded):
> > > >  - Through a reserved **VGA** memory on BAR[0], or
> > > >  - Through a reserved **PCIe** shared memory on BAR[1]
> > > > 
> > > > The usage pretty much the same as P2A, but it runs on different BAR, 
> > > > offset and length.
> > > > This will involves modifying phosphor-ipmi-flash/[tools|bmc]. Should I 
> > > > create new **interfaces**, e.g. astpcie/astvga?
> > > > 
> > > 
> > > This is the HOST2BMC functionality in the 2600 datasheet?
> > > 
> > > It would be great to have more detail on how it works.
> > > 
> > > Andrew
> > 
> > No, it doesn't use HOST2BMC interface, it uses VGA controller's mmio.
> > Perhaps HOST2BMC is also a possible solution, too.
> > 
> > 02:00.0 0300: 1a03:2000 (rev 51) (prog-if 00 [VGA controller])
> >         Subsystem: 1a03:2000
> >         Flags: bus master, medium devsel, latency 0, IRQ 16
> >         Memory at f6000000 (32-bit, non-prefetchable) [size=16M]  <--- Option 1
> >         Memory at f7040000 (32-bit, non-prefetchable) [size=128K] <--- Option 2
> >         I/O ports at e000 [size=128]
> >         Expansion ROM at 000c0000 [disabled] [size=128K]
> >         Capabilities: [40] Power Management version 3
> >         Capabilities: [50] MSI: Enable- Count=1/4 Maskable- 64bit+
> >         Kernel driver in use: ast
> >         Kernel modules: ast
> > 
> > Option 1 allocates a 1MB memory from the end of VGA memory, so it will
> > need some change to VBIOS.
> > 
> > Option 2 allocates a 4K memory from BMC memory space. Since the buffer
> > is smaller, the ipmi-blob protocol overhead will be greater.
> > 
> 
> Okay. So for Option 2 we need to coordinate on the BMC by reserving memory in 
> the devicetree. What's the plan there? Where's that going to be documented?
> 
> Andrew

You make a very good point, I should propose the design document before
finilize the implementation. 

For option 2, we need to coordinate a 4K buffer from device tree, let's
say:

```
reserved-memory {
    pcie_ssm_memory: region@98000000 {
        no-map;
        reg = <0x98000000 0x00001000>; /* 4K */
    };
};

pcie_ssm {
    compatible = "aspeed,ast2600-pcie-sharedmem";
    status = "okay";
    memory-region = <&pcie_ssm_memory>;
};
```

When initialing the pcie-sharedmem driver, the driver will fills the
reserved memory address into:
 - SCUC48 if the soc is AST2600
 - SCU194 if the soc is AST2500

When the host runs burn_my_bmc (phosphor-ipmi-flash/tool), bmc will open 
the window when recieve blobSessionOpen command by setting:
 - SCUC24[8] to 1 if the soc is AST2600
 - SCU184[8] to 1 if the soc is AST2500

The host start copy firmware image into VGA PCIe BAR[1]+0xE000 with 4K
size, then host issues a blobWrite to BMC. BMC copys the firmware data
from reserved memory region then acknowledge the host ipmi command. This
procedure will run repeatedly until all firmware image are sented.

The host sends a blobSession close to close the shared memory
window, then follows by a blobCommit to indicate the file is copyed.


Sequence diagram:
```
 +-------------+                                         +------------+
 | burn my bmc |                                         | ipmi hostd |
 +-------------+                                         +------------+
        |                                                       |
        |             blobOpen                                  |
        +------------------------------------------------------>+
        |                                                       |
        |             blobSessionOpen                          +-+
        +----------------------------------------------------->| |
        |                                                      | +-+ IOCTL OpenWindow
        |                            +-----------------+       | | | SCUC24[8] = 1
        |                            | PCIe Shared Mem |       | | | (SCU184[8] = 1)
        |                            | BAR[1] + 0xE000 <-------+ <-+
        |                            +-----------------+       | |
        |                                     |                | |
        |             blobSession ACK         |                | |
        +<-----------------------------------------------------+-+
        |                                     |                 |
+---------------------------------------------------------------------+
|loop/  |                                     |                 |     |
+---+   | memcpy(BAR[1]+0xE000, IMG+offset, size)               |     |
|       +------------------------------------>+                 |     |
|       |             blobWrite               |                +-+    |
|       +----------------------------------------------------->| |    |
|       |                                     |    memcpy()    | |    |
|       |                                     +<---------------+ |    |
|       |             blobWrite ACK           |                | |    |
|       +<-----------------------------------------------------+-+    |
|       |                                     |                 |     |
|       |                                     |                 |     |
|       |                                     |                 |     |
+---------------------------------------------------------------------+
        |                                     |                 |
        |             blobSessionClose        |                +-+
        +----------------------------------------------------->+ +-+ IOCTL CloseWindow
        |                                     |                | | | SCUC24[8] = 0
        |                                     |                | | | (SCU184[8] = 0)
        |                                     |                | +<+
        |                                     |                | |
        |                                     X<---------------+-+
        |             blobCommit                                |
        +------------------------------------------------------->
        |                                                       |
        |                                                       |
        |                                                       |
        +                                                       +
```

Thanks,
Troy Lee

Re: Supporting new interfaces in phosphor-ipmi-flash

[Troy Lee]

Hi Team,

While I'm evaluating the performance for the design, I notice that the
maximum IPMI through/put over KCS / IPMB / LAN is about 120 command per
second. Does anyone know where the bottleneck is?

If we wants to send 64MB image through 4K memory buffer, it takes 2^14
ipmi blobWrite commands. With the through/put mentioned above, it will
need about 2 min to send just "IPMI" commands. The image copy to memory
just takes few seconds. I'd like to know if I could do anything to
improve the IPMI through/put.

Thanks,
Troy Lee

The 02/01/2021 15:37, Troy Lee wrote:
> Hi Andrew,
> 
> You make a very good point, I should propose the design document before
> finilize the implementation. 
> 
> For option 2, we need to coordinate a 4K buffer from device tree, let's
> say:
> 
> ```
> reserved-memory {
>     pcie_ssm_memory: region@98000000 {
>         no-map;
>         reg = <0x98000000 0x00001000>; /* 4K */
>     };
> };
> 
> pcie_ssm {
>     compatible = "aspeed,ast2600-pcie-sharedmem";
>     status = "okay";
>     memory-region = <&pcie_ssm_memory>;
> };
> ```
> 
> When initialing the pcie-sharedmem driver, the driver will fills the
> reserved memory address into:
>  - SCUC48 if the soc is AST2600
>  - SCU194 if the soc is AST2500
> 
> When the host runs burn_my_bmc (phosphor-ipmi-flash/tool), bmc will open 
> the window when recieve blobSessionOpen command by setting:
>  - SCUC24[8] to 1 if the soc is AST2600
>  - SCU184[8] to 1 if the soc is AST2500
> 
> The host start copy firmware image into VGA PCIe BAR[1]+0xE000 with 4K
> size, then host issues a blobWrite to BMC. BMC copys the firmware data
> from reserved memory region then acknowledge the host ipmi command. This
> procedure will run repeatedly until all firmware image are sented.
> 
> The host sends a blobSession close to close the shared memory
> window, then follows by a blobCommit to indicate the file is copyed.
> 
> 
> Sequence diagram:
> ```
>  +-------------+                                         +------------+
>  | burn my bmc |                                         | ipmi hostd |
>  +-------------+                                         +------------+
>         |                                                       |
>         |             blobOpen                                  |
>         +------------------------------------------------------>+
>         |                                                       |
>         |             blobSessionOpen                          +-+
>         +----------------------------------------------------->| |
>         |                                                      | +-+ IOCTL OpenWindow
>         |                            +-----------------+       | | | SCUC24[8] = 1
>         |                            | PCIe Shared Mem |       | | | (SCU184[8] = 1)
>         |                            | BAR[1] + 0xE000 <-------+ <-+
>         |                            +-----------------+       | |
>         |                                     |                | |
>         |             blobSession ACK         |                | |
>         +<-----------------------------------------------------+-+
>         |                                     |                 |
> +---------------------------------------------------------------------+
> |loop/  |                                     |                 |     |
> +---+   | memcpy(BAR[1]+0xE000, IMG+offset, size)               |     |
> |       +------------------------------------>+                 |     |
> |       |             blobWrite               |                +-+    |
> |       +----------------------------------------------------->| |    |
> |       |                                     |    memcpy()    | |    |
> |       |                                     +<---------------+ |    |
> |       |             blobWrite ACK           |                | |    |
> |       +<-----------------------------------------------------+-+    |
> |       |                                     |                 |     |
> |       |                                     |                 |     |
> |       |                                     |                 |     |
> +---------------------------------------------------------------------+
>         |                                     |                 |
>         |             blobSessionClose        |                +-+
>         +----------------------------------------------------->+ +-+ IOCTL CloseWindow
>         |                                     |                | | | SCUC24[8] = 0
>         |                                     |                | | | (SCU184[8] = 0)
>         |                                     |                | +<+
>         |                                     |                | |
>         |                                     X<---------------+-+
>         |             blobCommit                                |
>         +------------------------------------------------------->
>         |                                                       |
>         |                                                       |
>         |                                                       |
>         +                                                       +
> ```
> 
> Thanks,
> Troy Lee

Re: Supporting new interfaces in phosphor-ipmi-flash

[Andrew Jeffery]

On Tue, 9 Feb 2021, at 19:36, Troy Lee wrote:
> Hi Team,
> 
> While I'm evaluating the performance for the design, I notice that the
> maximum IPMI through/put over KCS / IPMB / LAN is about 120 command per
> second. Does anyone know where the bottleneck is?

So a few thoughts:

There are a some hints on performance profiling in the wiki:

https://github.com/openbmc/openbmc/wiki/Performance-Profiling-in-OpenBMC

However, I'd start by inspecting the message timings on D-Bus. You can capture
the D-Bus traffic on the BMC with:

```shell
# busctl capture > /tmp/dbus.pcap
```

After that, run your image transfer test. Once the transfer completes, stop the
capture and copy the pcap file off the BMC.

One approach to analysing the capture is to use Wireshark[1]. However, I've
found that for this kind of exploratory stuff, scripting the filtering and
output can give useful results. On that front I've written dbus-pcap:

https://github.com/openbmc/openbmc-tools/tree/master/dbus-pcap

which can spit out the messages in JSON format if necessary and it takes
standard D-Bus match rules for filtering as optional positional arguments:

https://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-routing-match-rules

If the overhead is not dominated by the IPC on its own, it's probably time to
start inspecting specific processes with `perf`. The wiki talks a little more
about that.

Hope that helps.

Andrew

[1] https://www.wireshark.org/

Re: Supporting new interfaces in phosphor-ipmi-flash

[Troy Lee]

Hi Andrew,

The 02/15/2021 07:26, Andrew Jeffery wrote:
> 
> 
> On Tue, 9 Feb 2021, at 19:36, Troy Lee wrote:
> > Hi Team,
> > 
> > While I'm evaluating the performance for the design, I notice that the
> > maximum IPMI through/put over KCS / IPMB / LAN is about 120 command per
> > second. Does anyone know where the bottleneck is?
> 
> So a few thoughts:
> 
> There are a some hints on performance profiling in the wiki:
> 
> https://github.com/openbmc/openbmc/wiki/Performance-Profiling-in-OpenBMC
> 
> However, I'd start by inspecting the message timings on D-Bus. You can capture
> the D-Bus traffic on the BMC with:
> 
> ```shell
> # busctl capture > /tmp/dbus.pcap
> ```
> 
> After that, run your image transfer test. Once the transfer completes, stop the
> capture and copy the pcap file off the BMC.
> 
> One approach to analysing the capture is to use Wireshark[1]. However, I've
> found that for this kind of exploratory stuff, scripting the filtering and
> output can give useful results. On that front I've written dbus-pcap:
> 
> https://github.com/openbmc/openbmc-tools/tree/master/dbus-pcap
The tool is very useful, I used to use dbus-monitor and inspect message
traffic by eyes only.

> 
> which can spit out the messages in JSON format if necessary and it takes
> standard D-Bus match rules for filtering as optional positional arguments:
> 
> https://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-routing-match-rules
> 
> If the overhead is not dominated by the IPC on its own, it's probably time to
> start inspecting specific processes with `perf`. The wiki talks a little more
> about that.
> 
> Hope that helps.
> 
> Andrew
> 
> [1] https://www.wireshark.org/

It roughly takes 8ms to process a blobWrite command. I'll see if any thing 
I can help to improve or it is a limitation.

```
# OBMC OEM BlobTransfer blobWrite
1613620034.097539:
CookedMessage(header=CookedHeader(fixed=FixedHeader(endian=108, type=1, flags=0, version=1, length=32, cookie=107), fields=[Field(type=<MessageFieldType.PATH: 1>, data='/xyz/openbmc_project/Ipmi'), Field(type=<MessageFieldType.MEMBER: 3>, data='execute'), Field(type=<MessageFieldType.INTERFACE: 2>, data='xyz.openbmc_project.Ipmi.Server'), Field(type=<MessageFieldType.DESTINATION: 6>, data='xyz.openbmc_project.Ipmi.Host'), Field(type=<MessageFieldType.SIGNATURE: 8>, data='yyyaya{sv}'), Field(type=<MessageFieldType.SENDER: 7>, data=':1.75')]), body=[46, 0, 128, [207, 194, 0, 4, 211, 39, 84, 226, 0, 0, 64, 0, 0, 0, 16, 0], []])

# Cascaded Checking User Priviledge, not sure where it introduced, but
# it shows on every command even with in-band channel
1613620034.097977:
CookedMessage(header=CookedHeader(fixed=FixedHeader(endian=108, type=1, flags=0, version=1, length=10, cookie=224), fields=[Field(type=<MessageFieldType.PATH: 1>, data='/org/freedesktop/DBus'), Field(type=<MessageFieldType.MEMBER: 3>, data='GetConnectionUnixUser'), Field(type=<MessageFieldType.INTERFACE: 2>, data='org.freedesktop.DBus'), Field(type=<MessageFieldType.DESTINATION: 6>, data='org.freedesktop.DBus'), Field(type=<MessageFieldType.SIGNATURE: 8>, data='s'), Field(type=<MessageFieldType.SENDER: 7>, data=':1.72')]), body=[':1.75'])

# Method returns for checking user priviledge
1613620034.098058:
CookedMessage(header=CookedHeader(fixed=FixedHeader(endian=108, type=2, flags=1, version=1, length=4, cookie=4294967295), fields=[Field(type=<MessageFieldType.REPLY_SERIAL: 5>, data=224), Field(type=<MessageFieldType.SENDER: 7>, data='org.freedesktop.DBus'), Field(type=<MessageFieldType.DESTINATION: 6>, data=':1.72'), Field(type=<MessageFieldType.SIGNATURE: 8>, data='u')]), body=[0])

# Method returns for OBMC OEM BlobTransfer blobWrite
1613620034.106147:
CookedMessage(header=CookedHeader(fixed=FixedHeader(endian=108, type=2, flags=1, version=1, length=11, cookie=225), fields=[Field(type=<MessageFieldType.REPLY_SERIAL: 5>, data=107), Field(type=<MessageFieldType.DESTINATION: 6>, data=':1.75'), Field(type=<MessageFieldType.SIGNATURE: 8>, data='(yyyyay)'), Field(type=<MessageFieldType.SENDER: 7>, data=':1.72')]), body=[[47, 0, 128, 0, [207, 194, 0]]])
```

Thanks,
Troy Lee