From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <arnaud.pouliquen@st.com>
Subject: Re: [EXT] Re: [RFC 2/2] rpmsg: imx: add the initial imx rpmsg support
References: <AM0PR0402MB3570E209B4940C3772D56AC98CCF0@AM0PR0402MB3570.eurprd04.prod.outlook.com>
 <03420f31-0982-4bd9-303a-60b787638775@st.com>
 <AM0PR0402MB357004D25FACA8C610F8E36C8CCE0@AM0PR0402MB3570.eurprd04.prod.outlook.com>
From: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Message-ID: <fa9b912a-43d3-5826-2bc2-9e62f77d3de8@st.com>
Date: Tue, 16 Jul 2019 15:53:23 +0200
MIME-Version: 1.0
In-Reply-To: <AM0PR0402MB357004D25FACA8C610F8E36C8CCE0@AM0PR0402MB3570.eurprd04.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
To: Richard Zhu <hongxing.zhu@nxp.com>, Oleksij Rempel <o.rempel@pengutronix.de>, "ohad@wizery.com" <ohad@wizery.com>, "bjorn.andersson@linaro.org" <bjorn.andersson@linaro.org>, "linux-remoteproc@vger.kernel.org" <linux-remoteproc@vger.kernel.org>
Cc: "loic.pallardy@st.com" <loic.pallardy@st.com>, Fabien DESSENNE <fabien.dessenne@st.com>, "elder@linaro.org" <elder@linaro.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>
List-ID: <linux-remoteproc@vger.kernel.org>



On 7/16/19 10:04 AM, Richard Zhu wrote:
>> -----Original Message-----
>> From: Arnaud Pouliquen <arnaud.pouliquen@st.com>
>> Sent: 2019年7月15日 20:16
>> To: Richard Zhu <hongxing.zhu@nxp.com>; Oleksij Rempel
>> <o.rempel@pengutronix.de>; ohad@wizery.com; bjorn.andersson@linaro.org;
>> linux-remoteproc@vger.kernel.org
>> Cc: loic.pallardy@st.com; Fabien DESSENNE <fabien.dessenne@st.com>;
>> elder@linaro.org; linux-arm-kernel@lists.infradead.org
>> Subject: [EXT] Re: [RFC 2/2] rpmsg: imx: add the initial imx rpmsg support
>>
>> On 7/15/19 10:22 AM, Richard Zhu wrote:
>>
>> <snip>
>>
>>>>>> sg693v6UjM%2BFEk7TYHxgg6RDX611%2FKfjqA%3D&amp;reserved=0
>>>>>>>
>>>>>>> M core/RTOS insists to run and manage its resources assigned by
>>>>>>> XRDC
>>>>>> standalone.
>>>>>>> All the interactions between A core and M core are transferred on
>>>>>>> RPMSG
>>>>>> channels.
>>>>>>> For example, the audio codec configuration and so on.
>>>>>>> So, what I do here is just setup the communication RPMSG channels
>>>>>>> between A core/Linux and M core/RTOS.
>>>>>>>
>>>>>>> One more concern, I'm afraid that I may mess up the current solid
>>>>>>> reproc flow and framework if  I force this implementation into the
>>>>>>> current
>>>>>> reproc drivers.
>>>>>>> So, I summit this patch-set in the end. Pre-reserved vring buffer,
>>>>>>> register virtio_device, establish the RPMSG channels lets A
>>>>>>> core/Linux and
>>>>>> M Core/RTOS can communicate with each other.
>>>>>>> That's all.
>>>>>> Your concern is valid, and as we have the same requirement, it
>>>>>> would be nice to find a common solution. That's why i propose this
>>>>>> alternative, which would have the advantage of reusing existing
>>>>>> rpmsg
>>>> implementation.
>>>>>>
>>>>>     [Richard Zhu] I looked through the codes briefly. Correct me if
>>>>> my
>>>> understand
>>>>>     is wrong.
>>>>> It seems that the A core side does a lot of manipulations to the
>>>>> remote M4
>>>> core
>>>>>     on ST32M.
>>>>> During the start/stop/recovery operations, M4 acted as slave and
>>>>> waiting
>>>> for the
>>>>>     control constructions sent from the master A core/Linux side
>>>>> although
>>>> the
>>>>>     early_boot is set.
>>>>>
>>>>> There are some differences in the relationship between A core and M
>> core.
>>>>> On ST32M: M4/RTOS would started/stopped/recovered by A core/Linux
>>>> side.
>>>>>
>>>>> In my purposed implementation, both A core/Linux and M core/RTOS
>>>> working in the real
>>>>>     independent mode.
>>>>> - M4/RTOS complete the start/stop/recovery and son on operations by
>>>>> itself,
>>>> it wouldn't
>>>>>     accept any start/stop/reset interactions from A core/Linux side.
>>>>> Same to
>>>> A core/Linux side.
>>>>> - SCFW monitors the running status of each side, would notify the
>>>>> other side,
>>>> if there is a
>>>>>     system stall at one side.
>>>>>     when the lived side receives the notification and know the other
>>>>> side is
>>>> reset,
>>>>>     It would only recover its own rpmsg stack, wait the rpmsg "ready"
>>>>> signal
>>>> of the opposite side,
>>>>>     then re-establish the rpmsg channels again.
>>>>>     A core/Linux or M core/RTOS wouldn't do the start/stop/recovery
>>>> operations on the opposite side.
>>>> On STM32MP1 we have not exactly the same strategy but it only a ST
>>>> design choice, implemented in our stm32 remoteproc driver. You should
>>>> be able to implement your expected behavior in your the imx remoteproc
>> driver.
>>>>
>>>> On STM32MP1 we manage the M4 preloaded firmware in this way:
>>>> -  On Linux stm32 remoteproc probe:
>>>>           We detect that the firmware is preloaded (early-booted filed
>>>> in DT) and set the earl_boot variable.
>>>>           we provide the resource table address to the remoteproc core
>>>> that parses it an call the stm32_rproc_start. here we do nothing as
>>>> M4 already started we just set the hold boot to freeze the M4 in case
>>>> of crash
>>>>
>>>> - On M4 crash we have not the same strategy as your one. We consider
>>>> that the M4 firmware can be corrupted and either we try to reload a
>>>> firmware which as been provided by application, or we don't let it
>>>> restarting (hold boot set on start).
>>>>
>>>> -We allow userland to stop the preloaded firmware to load and to run
>>>> a new one.
>>>>
>>>>>
>>>>> Anyway, let me do some more homework, and figure out that whether I
>>>>> can fit these into the existing remoteproc framework or not.
>>>> Sorry to give you homework... but seems (IMHO) possible to integrate
>>>> your constraint in rpmsg/remoteproc current design.
>>>>
>>> [Richard Zhu] Hi Arnaud, I still can't find a way to combine this patch-set
>> with the master/slave mode.
>>> Regarding to my understand, almost all the defined items of the struct rproc
>> is used by the master(A core/Linux) to control/manipulate the slave remote
>> slave processor.
>>> It's fine when the master(A core)/Slave(remote processor) mode is used.
>>>
>>> But it's too hard to apply the slave/master mode into this scenario.
>>> - M core/RTOS insists to run and manage its resources assigned by XRDC
>> standalone.
>> Please could you explain the dependency between XRDC management and
>> the RPMsg protocol, i don't figure out the blocking point here. So maybe i
>> missed something important.
> [Richard Zhu] There are access control managements in this use case.
> Regarding to the security reasons or something else, the XRDC arranges the HW access control managements.
> It would assign the access capabilities of the HW resources to different domains.
> Thus, the HW resource required by M4 can be reserved for M4 by XRDC.
> Same to A core/Linux side.
> Both of them, manipulate their HW resources independently, and wouldn't have the HW conflictions.
> SCFW wouldn't allow the cross-the border access.
> All of this is preconfigured in SCFW, one system control firmware on top of bootloader/Linux/and RTOS.
> 
> RPMSG protocol is used to setup the communication between A core/Linux and M core/RTOS,
> when the A core/Linux wants to use some HW resources under controlled by M core/RTOS.
> - A core/Linux would send the RPMSG to M core/RTOS.
> - Receive the results after M core/RTOS finish the execution.
> 
Ok this similar to what we proposed and has been mentioned by Oleksij:
"remoteproc: add system resource manager device" patch set
So this is handled by a client on top of rpmsg, no impact on the rpmsg 
vrings initialization and management.

>>> - M core/RTOS wouldn't accept the start/stop/recover/reset operations
>> issued from A core/Linux side.
>> in addition with the patch
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.or
>> g%2Flkml%2F2018%2F11%2F30%2F159&amp;data=02%7C01%7Chongxing.z
>> hu%40nxp.com%7C532e75444add4475036208d7091e426d%7C686ea1d3bc2
>> b4c6fa92cd99c5c301635%7C0%7C0%7C636987897883960797&amp;sdata=
>> Ht3%2BKbdqLn%2BIFUO8Qj23ev8uFAtd9FffOGkssm1QmlQ%3D&amp;reserv
>> ed=0 you can control this in your platform driver using the rproc->preloaded
>> variable
>>>
>>> So the parallel mode is used in my proposal, both A core/Linux and M
>> core/RTOS works in real independent mode. There is no slave/master in this
>> implementation.
>> They are independent in terms of live cycle but not in terms of communication.
>> So you still need synchronization.
>> For instance your implementation uses a mailbox to synchronize both
>> (mailbox rdb). In existing rpmsg/virtio driver similar synchronization is done
>> through a status register in the resource table plus an optional mailbox kick
>> from Linux to remote processor.
>>
>> In case the Cortex-M4 starts first:
>> - The M4 firmware starts first (managing CAN)
>> - The Linux OS starts: it just parses the resource table, creates/allocates virtio
>> rings and buffers, update the vdev status flag in the resource table and kick
>> the M4 via mailbox.
> [Richard Zhu] The vring and buffer address are defined in the DTS files.
> So, the resource table contains the clks/pwr or some other HW resources required by M4.
> It seems that the resource table is not mandatory required in this scenario, because that all the HW resources are pre-assigned and managed by XRDC already.
> 
The resource table mainly contains definitions related to the shared 
memories, no HW Peripheral (but could be used in future for this kind of 
declaration should be possible soon; https://lkml.org/lkml/2019/6/29/187).
Resource table is not mandatory, but it is the generic way to define 
rpmsg memories and probe the rpmsg bus driver. Here is an exemple of 
resource table:
https://github.com/zephyrproject-rtos/open-amp/pull/2/files#diff-65def9751b4fbc10973e184b5daa80e9

kind regards
Arnaud
> The vdev status flag is an interesting synchronization mechanism in the resource table.
> 
>> - The M4 receive the mailbox kick, checks the vdev status and start the rpmsg
>> communication.
>> This is what we have implemented on STM32MP1. And we are able to re-use
>> the same M4 firmware booted first (independent mode) or loaded by Linux.
>>
> [Richard Zhu] Thanks a lot for your kindly clarification.
> 
>>> All the items defined in the struct rproc can't be used in this scenario.
>> I would say can be ignored, but the idea is that same rproc manages both
>> scenarios.
>>> IMHO, this patch-set is just to setup one communication channel between A
>> core and M core.
>>> There are no salve remote processor instances at A core/Linux side, that can
>> be controlled and manipulated by A core/Linux.
>> Yes i agree with you, no need to manage the remote processor in your case.
>> But the goal of remoteproc is not only the management of the remote
>> processor but also the management of the shared resources (rpmsg, carveout,
>> remote processor traces...). My proposal is to bypass the management of the
>> remote processor live cycle using Loic's patches, but to keep the remoteproc
>> part handling the associated resources to be able to probe RPMsg bus driver.
>>
> [Richard Zhu] Got that, would try to follow that direction.
> Thanks.
> 
>>>
>>> Is it possible to add another folder(e.x parallel_proc) under
>> drivers/remoteproc/ to extend the current remoteproc work mode?
>>> Then, the parallel work mode can be setup in it. And the original
>> master/slave mode wouldn't messed up by the parallel mode extension.
>>> Please to feel free to give the comments.
>>> Any comments and suggestions are appreciated.
>> IMHO, That's seems to be useless, if existing solution could be adapted.
>> But I'm not the maintainer... just a contributor.
>>
> [Richard Zhu] Understand. Thanks. 😊
> 
> Best Regards
> Richard
>>
>> Best Regards
>> Arnaud
>>
>>>
>>> Thanks in advanced.
>>>
>>> Best Regards
>>> Richard Zhu
>>>
>>
>> <Snip>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=Oenh=VN=lists.infradead.org=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-7.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1
	autolearn=ham autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id B0537C76188
	for <infradead-linux-arm-kernel@archiver.kernel.org>; Tue, 16 Jul 2019 13:53:43 +0000 (UTC)
Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.kernel.org (Postfix) with ESMTPS id 859F420880
	for <infradead-linux-arm-kernel@archiver.kernel.org>; Tue, 16 Jul 2019 13:53:43 +0000 (UTC)
Authentication-Results: mail.kernel.org;
	dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="en26O06T";
	dkim=fail reason="signature verification failed" (2048-bit key) header.d=st.com header.i=@st.com header.b="D0GHWmbz"
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 859F420880
Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=st.com
Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type:
	Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive:
	List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From:
	References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date:
	Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner;
	 bh=nFlfQ5Dyit57iXp+UMlwMJkTIuCWn1/SoC7ypl6cmgQ=; b=en26O06T/F8REEYOKE6yOb0+n
	og3QmAE5rqwkPP65iyk9N4FTZQ5k/0AvHCuu7dq6wK5jj14jPFSTjvecawbe9BdzQYSz/qrZBAVAI
	WZ3TbZbTfU8JFKIhRvbQNL+fuO5H9wC+jp5HOJsDuqt9peo5gzYab1ioHJfryeXLBYWrX539bOpV5
	rMV0cmFJJ10mwenP1zihXHQYJk3Q2TYIVMtvgi74MRMDsJ9Lsi7t83+XEAhGGiuuSbZJn8+LRkBUb
	4i2dOqUzpNRUGtOmAvwrIdiX6L0u5jGoApqWzQJL4y924loCTxPJa2D8u7wfQ9TLG1WrwayYfsm3m
	e+dssaukw==;
Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org)
	by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux))
	id 1hnNtg-00027n-Ke; Tue, 16 Jul 2019 13:53:36 +0000
Received: from mx07-00178001.pphosted.com ([62.209.51.94])
 by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux))
 id 1hnNtb-00026Z-Ua
 for linux-arm-kernel@lists.infradead.org; Tue, 16 Jul 2019 13:53:34 +0000
Received: from pps.filterd (m0046037.ppops.net [127.0.0.1])
 by mx07-00178001.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id
 x6GDq8U6020278; Tue, 16 Jul 2019 15:53:26 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=st.com;
 h=subject : to : cc :
 references : from : message-id : date : mime-version : in-reply-to :
 content-type : content-transfer-encoding; s=STMicroelectronics;
 bh=CHNA4tkvEu0cJ3QFC0kdm6/Gc6q8tsA6zYPTdJ9kyFw=;
 b=D0GHWmbzX5M8MFo6PO5H+w/kYFPTWz3hLphkHFFkQNhq6GfO8EZ6zWSQWCBQB80H1ECC
 4QL18qn3kXYEvWhYcguizWm+6XKfETP2gpktd/gcwn/MDrLGLYRP7pF33NJC0ZPIqbBJ
 188OwWcF17vPSdOTM6yt8AzDtePo/7BNZEt5+jo+VdQ5eTEngGHXG7UyG+73qOpy4JXK
 yctJ94C3tOuX0a42s2C6pAgVEwTtxD6MxnyOrO940GdsoUZCBbo0R7V6mNB/vBBYq+A+
 YteujFJRZiYwCqPLf74bPAWgbuc6O/83Muz8M3eSI0mC3pserBmeOxYI4VNFRfszFxBm qw== 
Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35])
 by mx07-00178001.pphosted.com with ESMTP id 2tsdep8ukp-1
 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT);
 Tue, 16 Jul 2019 15:53:26 +0200
Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9])
 by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 6B8F834;
 Tue, 16 Jul 2019 13:53:25 +0000 (GMT)
Received: from Webmail-eu.st.com (sfhdag3node1.st.com [10.75.127.7])
 by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id D4CA72CD1;
 Tue, 16 Jul 2019 13:53:24 +0000 (GMT)
Received: from [10.48.0.131] (10.75.127.49) by SFHDAG3NODE1.st.com
 (10.75.127.7) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 16 Jul
 2019 15:53:24 +0200
Subject: Re: [EXT] Re: [RFC 2/2] rpmsg: imx: add the initial imx rpmsg support
To: Richard Zhu <hongxing.zhu@nxp.com>, Oleksij Rempel
 <o.rempel@pengutronix.de>, "ohad@wizery.com" <ohad@wizery.com>,
 "bjorn.andersson@linaro.org" <bjorn.andersson@linaro.org>,
 "linux-remoteproc@vger.kernel.org" <linux-remoteproc@vger.kernel.org>
References: <AM0PR0402MB3570E209B4940C3772D56AC98CCF0@AM0PR0402MB3570.eurprd04.prod.outlook.com>
 <03420f31-0982-4bd9-303a-60b787638775@st.com>
 <AM0PR0402MB357004D25FACA8C610F8E36C8CCE0@AM0PR0402MB3570.eurprd04.prod.outlook.com>
From: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Message-ID: <fa9b912a-43d3-5826-2bc2-9e62f77d3de8@st.com>
Date: Tue, 16 Jul 2019 15:53:23 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <AM0PR0402MB357004D25FACA8C610F8E36C8CCE0@AM0PR0402MB3570.eurprd04.prod.outlook.com>
Content-Language: en-US
X-Originating-IP: [10.75.127.49]
X-ClientProxiedBy: SFHDAG8NODE1.st.com (10.75.127.22) To SFHDAG3NODE1.st.com
 (10.75.127.7)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, ,
 definitions=2019-07-16_04:, , signatures=0
X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 
X-CRM114-CacheID: sfid-20190716_065332_352960_566A4A5E 
X-CRM114-Status: GOOD (  31.57  )
X-BeenThere: linux-arm-kernel@lists.infradead.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <linux-arm-kernel.lists.infradead.org>
List-Unsubscribe: <http://lists.infradead.org/mailman/options/linux-arm-kernel>, 
 <mailto:linux-arm-kernel-request@lists.infradead.org?subject=unsubscribe>
List-Archive: <http://lists.infradead.org/pipermail/linux-arm-kernel/>
List-Post: <mailto:linux-arm-kernel@lists.infradead.org>
List-Help: <mailto:linux-arm-kernel-request@lists.infradead.org?subject=help>
List-Subscribe: <http://lists.infradead.org/mailman/listinfo/linux-arm-kernel>, 
 <mailto:linux-arm-kernel-request@lists.infradead.org?subject=subscribe>
Cc: "linux-arm-kernel@lists.infradead.org"
 <linux-arm-kernel@lists.infradead.org>,
 Fabien DESSENNE <fabien.dessenne@st.com>,
 "loic.pallardy@st.com" <loic.pallardy@st.com>,
 "elder@linaro.org" <elder@linaro.org>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: "linux-arm-kernel" <linux-arm-kernel-bounces@lists.infradead.org>
Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org

CgpPbiA3LzE2LzE5IDEwOjA0IEFNLCBSaWNoYXJkIFpodSB3cm90ZToKPj4gLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0KPj4gRnJvbTogQXJuYXVkIFBvdWxpcXVlbiA8YXJuYXVkLnBvdWxpcXVl
bkBzdC5jb20+Cj4+IFNlbnQ6IDIwMTnlubQ35pyIMTXml6UgMjA6MTYKPj4gVG86IFJpY2hhcmQg
Wmh1IDxob25neGluZy56aHVAbnhwLmNvbT47IE9sZWtzaWogUmVtcGVsCj4+IDxvLnJlbXBlbEBw
ZW5ndXRyb25peC5kZT47IG9oYWRAd2l6ZXJ5LmNvbTsgYmpvcm4uYW5kZXJzc29uQGxpbmFyby5v
cmc7Cj4+IGxpbnV4LXJlbW90ZXByb2NAdmdlci5rZXJuZWwub3JnCj4+IENjOiBsb2ljLnBhbGxh
cmR5QHN0LmNvbTsgRmFiaWVuIERFU1NFTk5FIDxmYWJpZW4uZGVzc2VubmVAc3QuY29tPjsKPj4g
ZWxkZXJAbGluYXJvLm9yZzsgbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCj4+
IFN1YmplY3Q6IFtFWFRdIFJlOiBbUkZDIDIvMl0gcnBtc2c6IGlteDogYWRkIHRoZSBpbml0aWFs
IGlteCBycG1zZyBzdXBwb3J0Cj4+Cj4+IE9uIDcvMTUvMTkgMTA6MjIgQU0sIFJpY2hhcmQgWmh1
IHdyb3RlOgo+Pgo+PiA8c25pcD4KPj4KPj4+Pj4+IHNnNjkzdjZVak0lMkJGRWs3VFlIeGdnNlJE
WDYxMSUyRktmanFBJTNEJmFtcDtyZXNlcnZlZD0wCj4+Pj4+Pj4KPj4+Pj4+PiBNIGNvcmUvUlRP
UyBpbnNpc3RzIHRvIHJ1biBhbmQgbWFuYWdlIGl0cyByZXNvdXJjZXMgYXNzaWduZWQgYnkKPj4+
Pj4+PiBYUkRDCj4+Pj4+PiBzdGFuZGFsb25lLgo+Pj4+Pj4+IEFsbCB0aGUgaW50ZXJhY3Rpb25z
IGJldHdlZW4gQSBjb3JlIGFuZCBNIGNvcmUgYXJlIHRyYW5zZmVycmVkIG9uCj4+Pj4+Pj4gUlBN
U0cKPj4+Pj4+IGNoYW5uZWxzLgo+Pj4+Pj4+IEZvciBleGFtcGxlLCB0aGUgYXVkaW8gY29kZWMg
Y29uZmlndXJhdGlvbiBhbmQgc28gb24uCj4+Pj4+Pj4gU28sIHdoYXQgSSBkbyBoZXJlIGlzIGp1
c3Qgc2V0dXAgdGhlIGNvbW11bmljYXRpb24gUlBNU0cgY2hhbm5lbHMKPj4+Pj4+PiBiZXR3ZWVu
IEEgY29yZS9MaW51eCBhbmQgTSBjb3JlL1JUT1MuCj4+Pj4+Pj4KPj4+Pj4+PiBPbmUgbW9yZSBj
b25jZXJuLCBJJ20gYWZyYWlkIHRoYXQgSSBtYXkgbWVzcyB1cCB0aGUgY3VycmVudCBzb2xpZAo+
Pj4+Pj4+IHJlcHJvYyBmbG93IGFuZCBmcmFtZXdvcmsgaWYgIEkgZm9yY2UgdGhpcyBpbXBsZW1l
bnRhdGlvbiBpbnRvIHRoZQo+Pj4+Pj4+IGN1cnJlbnQKPj4+Pj4+IHJlcHJvYyBkcml2ZXJzLgo+
Pj4+Pj4+IFNvLCBJIHN1bW1pdCB0aGlzIHBhdGNoLXNldCBpbiB0aGUgZW5kLiBQcmUtcmVzZXJ2
ZWQgdnJpbmcgYnVmZmVyLAo+Pj4+Pj4+IHJlZ2lzdGVyIHZpcnRpb19kZXZpY2UsIGVzdGFibGlz
aCB0aGUgUlBNU0cgY2hhbm5lbHMgbGV0cyBBCj4+Pj4+Pj4gY29yZS9MaW51eCBhbmQKPj4+Pj4+
IE0gQ29yZS9SVE9TIGNhbiBjb21tdW5pY2F0ZSB3aXRoIGVhY2ggb3RoZXIuCj4+Pj4+Pj4gVGhh
dCdzIGFsbC4KPj4+Pj4+IFlvdXIgY29uY2VybiBpcyB2YWxpZCwgYW5kIGFzIHdlIGhhdmUgdGhl
IHNhbWUgcmVxdWlyZW1lbnQsIGl0Cj4+Pj4+PiB3b3VsZCBiZSBuaWNlIHRvIGZpbmQgYSBjb21t
b24gc29sdXRpb24uIFRoYXQncyB3aHkgaSBwcm9wb3NlIHRoaXMKPj4+Pj4+IGFsdGVybmF0aXZl
LCB3aGljaCB3b3VsZCBoYXZlIHRoZSBhZHZhbnRhZ2Ugb2YgcmV1c2luZyBleGlzdGluZwo+Pj4+
Pj4gcnBtc2cKPj4+PiBpbXBsZW1lbnRhdGlvbi4KPj4+Pj4+Cj4+Pj4+ICAgICBbUmljaGFyZCBa
aHVdIEkgbG9va2VkIHRocm91Z2ggdGhlIGNvZGVzIGJyaWVmbHkuIENvcnJlY3QgbWUgaWYKPj4+
Pj4gbXkKPj4+PiB1bmRlcnN0YW5kCj4+Pj4+ICAgICBpcyB3cm9uZy4KPj4+Pj4gSXQgc2VlbXMg
dGhhdCB0aGUgQSBjb3JlIHNpZGUgZG9lcyBhIGxvdCBvZiBtYW5pcHVsYXRpb25zIHRvIHRoZQo+
Pj4+PiByZW1vdGUgTTQKPj4+PiBjb3JlCj4+Pj4+ICAgICBvbiBTVDMyTS4KPj4+Pj4gRHVyaW5n
IHRoZSBzdGFydC9zdG9wL3JlY292ZXJ5IG9wZXJhdGlvbnMsIE00IGFjdGVkIGFzIHNsYXZlIGFu
ZAo+Pj4+PiB3YWl0aW5nCj4+Pj4gZm9yIHRoZQo+Pj4+PiAgICAgY29udHJvbCBjb25zdHJ1Y3Rp
b25zIHNlbnQgZnJvbSB0aGUgbWFzdGVyIEEgY29yZS9MaW51eCBzaWRlCj4+Pj4+IGFsdGhvdWdo
Cj4+Pj4gdGhlCj4+Pj4+ICAgICBlYXJseV9ib290IGlzIHNldC4KPj4+Pj4KPj4+Pj4gVGhlcmUg
YXJlIHNvbWUgZGlmZmVyZW5jZXMgaW4gdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIEEgY29yZSBh
bmQgTQo+PiBjb3JlLgo+Pj4+PiBPbiBTVDMyTTogTTQvUlRPUyB3b3VsZCBzdGFydGVkL3N0b3Bw
ZWQvcmVjb3ZlcmVkIGJ5IEEgY29yZS9MaW51eAo+Pj4+IHNpZGUuCj4+Pj4+Cj4+Pj4+IEluIG15
IHB1cnBvc2VkIGltcGxlbWVudGF0aW9uLCBib3RoIEEgY29yZS9MaW51eCBhbmQgTSBjb3JlL1JU
T1MKPj4+PiB3b3JraW5nIGluIHRoZSByZWFsCj4+Pj4+ICAgICBpbmRlcGVuZGVudCBtb2RlLgo+
Pj4+PiAtIE00L1JUT1MgY29tcGxldGUgdGhlIHN0YXJ0L3N0b3AvcmVjb3ZlcnkgYW5kIHNvbiBv
biBvcGVyYXRpb25zIGJ5Cj4+Pj4+IGl0c2VsZiwKPj4+PiBpdCB3b3VsZG4ndAo+Pj4+PiAgICAg
YWNjZXB0IGFueSBzdGFydC9zdG9wL3Jlc2V0IGludGVyYWN0aW9ucyBmcm9tIEEgY29yZS9MaW51
eCBzaWRlLgo+Pj4+PiBTYW1lIHRvCj4+Pj4gQSBjb3JlL0xpbnV4IHNpZGUuCj4+Pj4+IC0gU0NG
VyBtb25pdG9ycyB0aGUgcnVubmluZyBzdGF0dXMgb2YgZWFjaCBzaWRlLCB3b3VsZCBub3RpZnkg
dGhlCj4+Pj4+IG90aGVyIHNpZGUsCj4+Pj4gaWYgdGhlcmUgaXMgYQo+Pj4+PiAgICAgc3lzdGVt
IHN0YWxsIGF0IG9uZSBzaWRlLgo+Pj4+PiAgICAgd2hlbiB0aGUgbGl2ZWQgc2lkZSByZWNlaXZl
cyB0aGUgbm90aWZpY2F0aW9uIGFuZCBrbm93IHRoZSBvdGhlcgo+Pj4+PiBzaWRlIGlzCj4+Pj4g
cmVzZXQsCj4+Pj4+ICAgICBJdCB3b3VsZCBvbmx5IHJlY292ZXIgaXRzIG93biBycG1zZyBzdGFj
aywgd2FpdCB0aGUgcnBtc2cgInJlYWR5Igo+Pj4+PiBzaWduYWwKPj4+PiBvZiB0aGUgb3Bwb3Np
dGUgc2lkZSwKPj4+Pj4gICAgIHRoZW4gcmUtZXN0YWJsaXNoIHRoZSBycG1zZyBjaGFubmVscyBh
Z2Fpbi4KPj4+Pj4gICAgIEEgY29yZS9MaW51eCBvciBNIGNvcmUvUlRPUyB3b3VsZG4ndCBkbyB0
aGUgc3RhcnQvc3RvcC9yZWNvdmVyeQo+Pj4+IG9wZXJhdGlvbnMgb24gdGhlIG9wcG9zaXRlIHNp
ZGUuCj4+Pj4gT24gU1RNMzJNUDEgd2UgaGF2ZSBub3QgZXhhY3RseSB0aGUgc2FtZSBzdHJhdGVn
eSBidXQgaXQgb25seSBhIFNUCj4+Pj4gZGVzaWduIGNob2ljZSwgaW1wbGVtZW50ZWQgaW4gb3Vy
IHN0bTMyIHJlbW90ZXByb2MgZHJpdmVyLiBZb3Ugc2hvdWxkCj4+Pj4gYmUgYWJsZSB0byBpbXBs
ZW1lbnQgeW91ciBleHBlY3RlZCBiZWhhdmlvciBpbiB5b3VyIHRoZSBpbXggcmVtb3RlcHJvYwo+
PiBkcml2ZXIuCj4+Pj4KPj4+PiBPbiBTVE0zMk1QMSB3ZSBtYW5hZ2UgdGhlIE00IHByZWxvYWRl
ZCBmaXJtd2FyZSBpbiB0aGlzIHdheToKPj4+PiAtICBPbiBMaW51eCBzdG0zMiByZW1vdGVwcm9j
IHByb2JlOgo+Pj4+ICAgICAgICAgICBXZSBkZXRlY3QgdGhhdCB0aGUgZmlybXdhcmUgaXMgcHJl
bG9hZGVkIChlYXJseS1ib290ZWQgZmlsZWQKPj4+PiBpbiBEVCkgYW5kIHNldCB0aGUgZWFybF9i
b290IHZhcmlhYmxlLgo+Pj4+ICAgICAgICAgICB3ZSBwcm92aWRlIHRoZSByZXNvdXJjZSB0YWJs
ZSBhZGRyZXNzIHRvIHRoZSByZW1vdGVwcm9jIGNvcmUKPj4+PiB0aGF0IHBhcnNlcyBpdCBhbiBj
YWxsIHRoZSBzdG0zMl9ycHJvY19zdGFydC4gaGVyZSB3ZSBkbyBub3RoaW5nIGFzCj4+Pj4gTTQg
YWxyZWFkeSBzdGFydGVkIHdlIGp1c3Qgc2V0IHRoZSBob2xkIGJvb3QgdG8gZnJlZXplIHRoZSBN
NCBpbiBjYXNlCj4+Pj4gb2YgY3Jhc2gKPj4+Pgo+Pj4+IC0gT24gTTQgY3Jhc2ggd2UgaGF2ZSBu
b3QgdGhlIHNhbWUgc3RyYXRlZ3kgYXMgeW91ciBvbmUuIFdlIGNvbnNpZGVyCj4+Pj4gdGhhdCB0
aGUgTTQgZmlybXdhcmUgY2FuIGJlIGNvcnJ1cHRlZCBhbmQgZWl0aGVyIHdlIHRyeSB0byByZWxv
YWQgYQo+Pj4+IGZpcm13YXJlIHdoaWNoIGFzIGJlZW4gcHJvdmlkZWQgYnkgYXBwbGljYXRpb24s
IG9yIHdlIGRvbid0IGxldCBpdAo+Pj4+IHJlc3RhcnRpbmcgKGhvbGQgYm9vdCBzZXQgb24gc3Rh
cnQpLgo+Pj4+Cj4+Pj4gLVdlIGFsbG93IHVzZXJsYW5kIHRvIHN0b3AgdGhlIHByZWxvYWRlZCBm
aXJtd2FyZSB0byBsb2FkIGFuZCB0byBydW4KPj4+PiBhIG5ldyBvbmUuCj4+Pj4KPj4+Pj4KPj4+
Pj4gQW55d2F5LCBsZXQgbWUgZG8gc29tZSBtb3JlIGhvbWV3b3JrLCBhbmQgZmlndXJlIG91dCB0
aGF0IHdoZXRoZXIgSQo+Pj4+PiBjYW4gZml0IHRoZXNlIGludG8gdGhlIGV4aXN0aW5nIHJlbW90
ZXByb2MgZnJhbWV3b3JrIG9yIG5vdC4KPj4+PiBTb3JyeSB0byBnaXZlIHlvdSBob21ld29yay4u
LiBidXQgc2VlbXMgKElNSE8pIHBvc3NpYmxlIHRvIGludGVncmF0ZQo+Pj4+IHlvdXIgY29uc3Ry
YWludCBpbiBycG1zZy9yZW1vdGVwcm9jIGN1cnJlbnQgZGVzaWduLgo+Pj4+Cj4+PiBbUmljaGFy
ZCBaaHVdIEhpIEFybmF1ZCwgSSBzdGlsbCBjYW4ndCBmaW5kIGEgd2F5IHRvIGNvbWJpbmUgdGhp
cyBwYXRjaC1zZXQKPj4gd2l0aCB0aGUgbWFzdGVyL3NsYXZlIG1vZGUuCj4+PiBSZWdhcmRpbmcg
dG8gbXkgdW5kZXJzdGFuZCwgYWxtb3N0IGFsbCB0aGUgZGVmaW5lZCBpdGVtcyBvZiB0aGUgc3Ry
dWN0IHJwcm9jCj4+IGlzIHVzZWQgYnkgdGhlIG1hc3RlcihBIGNvcmUvTGludXgpIHRvIGNvbnRy
b2wvbWFuaXB1bGF0ZSB0aGUgc2xhdmUgcmVtb3RlCj4+IHNsYXZlIHByb2Nlc3Nvci4KPj4+IEl0
J3MgZmluZSB3aGVuIHRoZSBtYXN0ZXIoQSBjb3JlKS9TbGF2ZShyZW1vdGUgcHJvY2Vzc29yKSBt
b2RlIGlzIHVzZWQuCj4+Pgo+Pj4gQnV0IGl0J3MgdG9vIGhhcmQgdG8gYXBwbHkgdGhlIHNsYXZl
L21hc3RlciBtb2RlIGludG8gdGhpcyBzY2VuYXJpby4KPj4+IC0gTSBjb3JlL1JUT1MgaW5zaXN0
cyB0byBydW4gYW5kIG1hbmFnZSBpdHMgcmVzb3VyY2VzIGFzc2lnbmVkIGJ5IFhSREMKPj4gc3Rh
bmRhbG9uZS4KPj4gUGxlYXNlIGNvdWxkIHlvdSBleHBsYWluIHRoZSBkZXBlbmRlbmN5IGJldHdl
ZW4gWFJEQyBtYW5hZ2VtZW50IGFuZAo+PiB0aGUgUlBNc2cgcHJvdG9jb2wsIGkgZG9uJ3QgZmln
dXJlIG91dCB0aGUgYmxvY2tpbmcgcG9pbnQgaGVyZS4gU28gbWF5YmUgaQo+PiBtaXNzZWQgc29t
ZXRoaW5nIGltcG9ydGFudC4KPiBbUmljaGFyZCBaaHVdIFRoZXJlIGFyZSBhY2Nlc3MgY29udHJv
bCBtYW5hZ2VtZW50cyBpbiB0aGlzIHVzZSBjYXNlLgo+IFJlZ2FyZGluZyB0byB0aGUgc2VjdXJp
dHkgcmVhc29ucyBvciBzb21ldGhpbmcgZWxzZSwgdGhlIFhSREMgYXJyYW5nZXMgdGhlIEhXIGFj
Y2VzcyBjb250cm9sIG1hbmFnZW1lbnRzLgo+IEl0IHdvdWxkIGFzc2lnbiB0aGUgYWNjZXNzIGNh
cGFiaWxpdGllcyBvZiB0aGUgSFcgcmVzb3VyY2VzIHRvIGRpZmZlcmVudCBkb21haW5zLgo+IFRo
dXMsIHRoZSBIVyByZXNvdXJjZSByZXF1aXJlZCBieSBNNCBjYW4gYmUgcmVzZXJ2ZWQgZm9yIE00
IGJ5IFhSREMuCj4gU2FtZSB0byBBIGNvcmUvTGludXggc2lkZS4KPiBCb3RoIG9mIHRoZW0sIG1h
bmlwdWxhdGUgdGhlaXIgSFcgcmVzb3VyY2VzIGluZGVwZW5kZW50bHksIGFuZCB3b3VsZG4ndCBo
YXZlIHRoZSBIVyBjb25mbGljdGlvbnMuCj4gU0NGVyB3b3VsZG4ndCBhbGxvdyB0aGUgY3Jvc3Mt
dGhlIGJvcmRlciBhY2Nlc3MuCj4gQWxsIG9mIHRoaXMgaXMgcHJlY29uZmlndXJlZCBpbiBTQ0ZX
LCBvbmUgc3lzdGVtIGNvbnRyb2wgZmlybXdhcmUgb24gdG9wIG9mIGJvb3Rsb2FkZXIvTGludXgv
YW5kIFJUT1MuCj4gCj4gUlBNU0cgcHJvdG9jb2wgaXMgdXNlZCB0byBzZXR1cCB0aGUgY29tbXVu
aWNhdGlvbiBiZXR3ZWVuIEEgY29yZS9MaW51eCBhbmQgTSBjb3JlL1JUT1MsCj4gd2hlbiB0aGUg
QSBjb3JlL0xpbnV4IHdhbnRzIHRvIHVzZSBzb21lIEhXIHJlc291cmNlcyB1bmRlciBjb250cm9s
bGVkIGJ5IE0gY29yZS9SVE9TLgo+IC0gQSBjb3JlL0xpbnV4IHdvdWxkIHNlbmQgdGhlIFJQTVNH
IHRvIE0gY29yZS9SVE9TLgo+IC0gUmVjZWl2ZSB0aGUgcmVzdWx0cyBhZnRlciBNIGNvcmUvUlRP
UyBmaW5pc2ggdGhlIGV4ZWN1dGlvbi4KPiAKT2sgdGhpcyBzaW1pbGFyIHRvIHdoYXQgd2UgcHJv
cG9zZWQgYW5kIGhhcyBiZWVuIG1lbnRpb25lZCBieSBPbGVrc2lqOgoicmVtb3RlcHJvYzogYWRk
IHN5c3RlbSByZXNvdXJjZSBtYW5hZ2VyIGRldmljZSIgcGF0Y2ggc2V0ClNvIHRoaXMgaXMgaGFu
ZGxlZCBieSBhIGNsaWVudCBvbiB0b3Agb2YgcnBtc2csIG5vIGltcGFjdCBvbiB0aGUgcnBtc2cg
CnZyaW5ncyBpbml0aWFsaXphdGlvbiBhbmQgbWFuYWdlbWVudC4KCj4+PiAtIE0gY29yZS9SVE9T
IHdvdWxkbid0IGFjY2VwdCB0aGUgc3RhcnQvc3RvcC9yZWNvdmVyL3Jlc2V0IG9wZXJhdGlvbnMK
Pj4gaXNzdWVkIGZyb20gQSBjb3JlL0xpbnV4IHNpZGUuCj4+IGluIGFkZGl0aW9uIHdpdGggdGhl
IHBhdGNoCj4+IGh0dHBzOi8vZXVyMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v
P3VybD1odHRwcyUzQSUyRiUyRmxrbWwub3IKPj4gZyUyRmxrbWwlMkYyMDE4JTJGMTElMkYzMCUy
RjE1OSZhbXA7ZGF0YT0wMiU3QzAxJTdDaG9uZ3hpbmcuego+PiBodSU0MG54cC5jb20lN0M1MzJl
NzU0NDRhZGQ0NDc1MDM2MjA4ZDcwOTFlNDI2ZCU3QzY4NmVhMWQzYmMyCj4+IGI0YzZmYTkyY2Q5
OWM1YzMwMTYzNSU3QzAlN0MwJTdDNjM2OTg3ODk3ODgzOTYwNzk3JmFtcDtzZGF0YT0KPj4gSHQz
JTJCS2JkcUxuJTJCSUZVTzhRajIzZXY4dUZBdGQ5RmZmT0drc3NtMVFtbFElM0QmYW1wO3Jlc2Vy
dgo+PiBlZD0wIHlvdSBjYW4gY29udHJvbCB0aGlzIGluIHlvdXIgcGxhdGZvcm0gZHJpdmVyIHVz
aW5nIHRoZSBycHJvYy0+cHJlbG9hZGVkCj4+IHZhcmlhYmxlCj4+Pgo+Pj4gU28gdGhlIHBhcmFs
bGVsIG1vZGUgaXMgdXNlZCBpbiBteSBwcm9wb3NhbCwgYm90aCBBIGNvcmUvTGludXggYW5kIE0K
Pj4gY29yZS9SVE9TIHdvcmtzIGluIHJlYWwgaW5kZXBlbmRlbnQgbW9kZS4gVGhlcmUgaXMgbm8g
c2xhdmUvbWFzdGVyIGluIHRoaXMKPj4gaW1wbGVtZW50YXRpb24uCj4+IFRoZXkgYXJlIGluZGVw
ZW5kZW50IGluIHRlcm1zIG9mIGxpdmUgY3ljbGUgYnV0IG5vdCBpbiB0ZXJtcyBvZiBjb21tdW5p
Y2F0aW9uLgo+PiBTbyB5b3Ugc3RpbGwgbmVlZCBzeW5jaHJvbml6YXRpb24uCj4+IEZvciBpbnN0
YW5jZSB5b3VyIGltcGxlbWVudGF0aW9uIHVzZXMgYSBtYWlsYm94IHRvIHN5bmNocm9uaXplIGJv
dGgKPj4gKG1haWxib3ggcmRiKS4gSW4gZXhpc3RpbmcgcnBtc2cvdmlydGlvIGRyaXZlciBzaW1p
bGFyIHN5bmNocm9uaXphdGlvbiBpcyBkb25lCj4+IHRocm91Z2ggYSBzdGF0dXMgcmVnaXN0ZXIg
aW4gdGhlIHJlc291cmNlIHRhYmxlIHBsdXMgYW4gb3B0aW9uYWwgbWFpbGJveCBraWNrCj4+IGZy
b20gTGludXggdG8gcmVtb3RlIHByb2Nlc3Nvci4KPj4KPj4gSW4gY2FzZSB0aGUgQ29ydGV4LU00
IHN0YXJ0cyBmaXJzdDoKPj4gLSBUaGUgTTQgZmlybXdhcmUgc3RhcnRzIGZpcnN0IChtYW5hZ2lu
ZyBDQU4pCj4+IC0gVGhlIExpbnV4IE9TIHN0YXJ0czogaXQganVzdCBwYXJzZXMgdGhlIHJlc291
cmNlIHRhYmxlLCBjcmVhdGVzL2FsbG9jYXRlcyB2aXJ0aW8KPj4gcmluZ3MgYW5kIGJ1ZmZlcnMs
IHVwZGF0ZSB0aGUgdmRldiBzdGF0dXMgZmxhZyBpbiB0aGUgcmVzb3VyY2UgdGFibGUgYW5kIGtp
Y2sKPj4gdGhlIE00IHZpYSBtYWlsYm94Lgo+IFtSaWNoYXJkIFpodV0gVGhlIHZyaW5nIGFuZCBi
dWZmZXIgYWRkcmVzcyBhcmUgZGVmaW5lZCBpbiB0aGUgRFRTIGZpbGVzLgo+IFNvLCB0aGUgcmVz
b3VyY2UgdGFibGUgY29udGFpbnMgdGhlIGNsa3MvcHdyIG9yIHNvbWUgb3RoZXIgSFcgcmVzb3Vy
Y2VzIHJlcXVpcmVkIGJ5IE00Lgo+IEl0IHNlZW1zIHRoYXQgdGhlIHJlc291cmNlIHRhYmxlIGlz
IG5vdCBtYW5kYXRvcnkgcmVxdWlyZWQgaW4gdGhpcyBzY2VuYXJpbywgYmVjYXVzZSB0aGF0IGFs
bCB0aGUgSFcgcmVzb3VyY2VzIGFyZSBwcmUtYXNzaWduZWQgYW5kIG1hbmFnZWQgYnkgWFJEQyBh
bHJlYWR5Lgo+IApUaGUgcmVzb3VyY2UgdGFibGUgbWFpbmx5IGNvbnRhaW5zIGRlZmluaXRpb25z
IHJlbGF0ZWQgdG8gdGhlIHNoYXJlZCAKbWVtb3JpZXMsIG5vIEhXIFBlcmlwaGVyYWwgKGJ1dCBj
b3VsZCBiZSB1c2VkIGluIGZ1dHVyZSBmb3IgdGhpcyBraW5kIG9mIApkZWNsYXJhdGlvbiBzaG91
bGQgYmUgcG9zc2libGUgc29vbjsgaHR0cHM6Ly9sa21sLm9yZy9sa21sLzIwMTkvNi8yOS8xODcp
LgpSZXNvdXJjZSB0YWJsZSBpcyBub3QgbWFuZGF0b3J5LCBidXQgaXQgaXMgdGhlIGdlbmVyaWMg
d2F5IHRvIGRlZmluZSAKcnBtc2cgbWVtb3JpZXMgYW5kIHByb2JlIHRoZSBycG1zZyBidXMgZHJp
dmVyLiBIZXJlIGlzIGFuIGV4ZW1wbGUgb2YgCnJlc291cmNlIHRhYmxlOgpodHRwczovL2dpdGh1
Yi5jb20vemVwaHlycHJvamVjdC1ydG9zL29wZW4tYW1wL3B1bGwvMi9maWxlcyNkaWZmLTY1ZGVm
OTc1MWI0ZmJjMTA5NzNlMTg0YjVkYWE4MGU5CgpraW5kIHJlZ2FyZHMKQXJuYXVkCj4gVGhlIHZk
ZXYgc3RhdHVzIGZsYWcgaXMgYW4gaW50ZXJlc3Rpbmcgc3luY2hyb25pemF0aW9uIG1lY2hhbmlz
bSBpbiB0aGUgcmVzb3VyY2UgdGFibGUuCj4gCj4+IC0gVGhlIE00IHJlY2VpdmUgdGhlIG1haWxi
b3gga2ljaywgY2hlY2tzIHRoZSB2ZGV2IHN0YXR1cyBhbmQgc3RhcnQgdGhlIHJwbXNnCj4+IGNv
bW11bmljYXRpb24uCj4+IFRoaXMgaXMgd2hhdCB3ZSBoYXZlIGltcGxlbWVudGVkIG9uIFNUTTMy
TVAxLiBBbmQgd2UgYXJlIGFibGUgdG8gcmUtdXNlCj4+IHRoZSBzYW1lIE00IGZpcm13YXJlIGJv
b3RlZCBmaXJzdCAoaW5kZXBlbmRlbnQgbW9kZSkgb3IgbG9hZGVkIGJ5IExpbnV4Lgo+Pgo+IFtS
aWNoYXJkIFpodV0gVGhhbmtzIGEgbG90IGZvciB5b3VyIGtpbmRseSBjbGFyaWZpY2F0aW9uLgo+
IAo+Pj4gQWxsIHRoZSBpdGVtcyBkZWZpbmVkIGluIHRoZSBzdHJ1Y3QgcnByb2MgY2FuJ3QgYmUg
dXNlZCBpbiB0aGlzIHNjZW5hcmlvLgo+PiBJIHdvdWxkIHNheSBjYW4gYmUgaWdub3JlZCwgYnV0
IHRoZSBpZGVhIGlzIHRoYXQgc2FtZSBycHJvYyBtYW5hZ2VzIGJvdGgKPj4gc2NlbmFyaW9zLgo+
Pj4gSU1ITywgdGhpcyBwYXRjaC1zZXQgaXMganVzdCB0byBzZXR1cCBvbmUgY29tbXVuaWNhdGlv
biBjaGFubmVsIGJldHdlZW4gQQo+PiBjb3JlIGFuZCBNIGNvcmUuCj4+PiBUaGVyZSBhcmUgbm8g
c2FsdmUgcmVtb3RlIHByb2Nlc3NvciBpbnN0YW5jZXMgYXQgQSBjb3JlL0xpbnV4IHNpZGUsIHRo
YXQgY2FuCj4+IGJlIGNvbnRyb2xsZWQgYW5kIG1hbmlwdWxhdGVkIGJ5IEEgY29yZS9MaW51eC4K
Pj4gWWVzIGkgYWdyZWUgd2l0aCB5b3UsIG5vIG5lZWQgdG8gbWFuYWdlIHRoZSByZW1vdGUgcHJv
Y2Vzc29yIGluIHlvdXIgY2FzZS4KPj4gQnV0IHRoZSBnb2FsIG9mIHJlbW90ZXByb2MgaXMgbm90
IG9ubHkgdGhlIG1hbmFnZW1lbnQgb2YgdGhlIHJlbW90ZQo+PiBwcm9jZXNzb3IgYnV0IGFsc28g
dGhlIG1hbmFnZW1lbnQgb2YgdGhlIHNoYXJlZCByZXNvdXJjZXMgKHJwbXNnLCBjYXJ2ZW91dCwK
Pj4gcmVtb3RlIHByb2Nlc3NvciB0cmFjZXMuLi4pLiBNeSBwcm9wb3NhbCBpcyB0byBieXBhc3Mg
dGhlIG1hbmFnZW1lbnQgb2YgdGhlCj4+IHJlbW90ZSBwcm9jZXNzb3IgbGl2ZSBjeWNsZSB1c2lu
ZyBMb2ljJ3MgcGF0Y2hlcywgYnV0IHRvIGtlZXAgdGhlIHJlbW90ZXByb2MKPj4gcGFydCBoYW5k
bGluZyB0aGUgYXNzb2NpYXRlZCByZXNvdXJjZXMgdG8gYmUgYWJsZSB0byBwcm9iZSBSUE1zZyBi
dXMgZHJpdmVyLgo+Pgo+IFtSaWNoYXJkIFpodV0gR290IHRoYXQsIHdvdWxkIHRyeSB0byBmb2xs
b3cgdGhhdCBkaXJlY3Rpb24uCj4gVGhhbmtzLgo+IAo+Pj4KPj4+IElzIGl0IHBvc3NpYmxlIHRv
IGFkZCBhbm90aGVyIGZvbGRlcihlLnggcGFyYWxsZWxfcHJvYykgdW5kZXIKPj4gZHJpdmVycy9y
ZW1vdGVwcm9jLyB0byBleHRlbmQgdGhlIGN1cnJlbnQgcmVtb3RlcHJvYyB3b3JrIG1vZGU/Cj4+
PiBUaGVuLCB0aGUgcGFyYWxsZWwgd29yayBtb2RlIGNhbiBiZSBzZXR1cCBpbiBpdC4gQW5kIHRo
ZSBvcmlnaW5hbAo+PiBtYXN0ZXIvc2xhdmUgbW9kZSB3b3VsZG4ndCBtZXNzZWQgdXAgYnkgdGhl
IHBhcmFsbGVsIG1vZGUgZXh0ZW5zaW9uLgo+Pj4gUGxlYXNlIHRvIGZlZWwgZnJlZSB0byBnaXZl
IHRoZSBjb21tZW50cy4KPj4+IEFueSBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIGFwcHJl
Y2lhdGVkLgo+PiBJTUhPLCBUaGF0J3Mgc2VlbXMgdG8gYmUgdXNlbGVzcywgaWYgZXhpc3Rpbmcg
c29sdXRpb24gY291bGQgYmUgYWRhcHRlZC4KPj4gQnV0IEknbSBub3QgdGhlIG1haW50YWluZXIu
Li4ganVzdCBhIGNvbnRyaWJ1dG9yLgo+Pgo+IFtSaWNoYXJkIFpodV0gVW5kZXJzdGFuZC4gVGhh
bmtzLiDwn5iKCj4gCj4gQmVzdCBSZWdhcmRzCj4gUmljaGFyZAo+Pgo+PiBCZXN0IFJlZ2FyZHMK
Pj4gQXJuYXVkCj4+Cj4+Pgo+Pj4gVGhhbmtzIGluIGFkdmFuY2VkLgo+Pj4KPj4+IEJlc3QgUmVn
YXJkcwo+Pj4gUmljaGFyZCBaaHUKPj4+Cj4+Cj4+IDxTbmlwPgoKX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGludXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxp
c3QKbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZy
YWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtYXJtLWtlcm5lbAo=