From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A8044C433EF for ; Wed, 13 Oct 2021 13:30:18 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0DBEE610E6 for ; Wed, 13 Oct 2021 13:30:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0DBEE610E6 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 745F783347; Wed, 13 Oct 2021 15:30:15 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=konsulko.com header.i=@konsulko.com header.b="ulZhkxkk"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 9D6BF83373; Wed, 13 Oct 2021 15:30:13 +0200 (CEST) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 617D983246 for ; Wed, 13 Oct 2021 15:30:08 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qk1-x72f.google.com with SMTP id c7so2170763qka.2 for ; Wed, 13 Oct 2021 06:30:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=pZsiTuShjwu0ODaR9VQ3XHEw8dOpJEOTf+e75TLoNbs=; b=ulZhkxkkKgIweFk1JlePG1qvalVGaQn9JhSvIjCCsirByBtlKD1ywdAHLdDhCxUbcC 4aV7mssriBQKHOtVP6qCwj1fHeNQ4vEy8GmNGBX5pwNwOKpqzzIzHzaCm54wcXwlh1IK YdaY9sYMgL9yuzT8d9Toc0C9plgW0uXjmLDBA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=pZsiTuShjwu0ODaR9VQ3XHEw8dOpJEOTf+e75TLoNbs=; b=czCkYQCp9nnr250+QbpE5sv9+XbQtDHgnHNzS3coOBX4jTxQDTmo0woJ1/sxMnZuHb R0PjrpExoDNvT6fY86W88lCnVWOFOoJLKgWvtzXWb1abHGuMTn5CzfGg+pDjFT/TPIoU axKb5kE63K5uT2w0GLI4xGZoTHpbl7KF+S+pdbBgJalJb6nF8SdKWXa1JUvDLnszoMO3 C2n1C27rklU4rOsVdxGysVy45f+t1SkgivIRe2O1nxct38sDq/BmNrupSlGsotvCq7Vo z4pF2VC7drRV4vY6i2iZNdHiTi4SF8Y93rqEU8fbZ3g40PaFwSumw0+YWI0Y4mWvkFNy AZWA== X-Gm-Message-State: AOAM532ZreSr48/rrKNuGbMO5Q7W0j86zlXGONYQkxs5ibO0hYIq6UT4 gzGavAGqp4ukl24azAyxcNrrqA== X-Google-Smtp-Source: ABdhPJycHUlPdRlNz4fg1THVEr1NzZFemL+qS6gjEvAArcGC7Ke89AbK3udVMYIGcwTtFIRPT9eOmw== X-Received: by 2002:a37:a2c1:: with SMTP id l184mr14320606qke.71.1634131807065; Wed, 13 Oct 2021 06:30:07 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-e98d-c49f-f596-1fb5.res6.spectrum.com. [2603:6081:7b01:cbda:e98d:c49f:f596:1fb5]) by smtp.gmail.com with ESMTPSA id z14sm446729qki.108.2021.10.13.06.30.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Oct 2021 06:30:06 -0700 (PDT) Date: Wed, 13 Oct 2021 09:30:04 -0400 From: Tom Rini To: =?iso-8859-1?Q?Fran=E7ois?= Ozog Cc: Bin Meng , Mark Kettenis , Rick Chen , Simon Glass , bill.mills@linaro.org, ilias.apalodimas@linaro.org, marcel.ziswiler@toradex.com, seanga2@gmail.com, u-boot@lists.denx.de, xypron.glpk@gmx.de Subject: Re: [PATCH v3 3/3] RFC: doc: Add documentation about devicetree usage Message-ID: <20211013133004.GM7964@bill-the-cat> References: <20210910123420.GL12964@bill-the-cat> <5614507a14906226@bloch.sibelius.xs4all.nl> <20210910211737.GB12964@bill-the-cat> <561450ac28c24b92@bloch.sibelius.xs4all.nl> <20210910224448.GD12964@bill-the-cat> <20210918131816.GM8579@bill-the-cat> <20211013125539.GK7964@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6IeHAMkZHKx0vIy5" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean --6IeHAMkZHKx0vIy5 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 13, 2021 at 03:12:02PM +0200, Fran=C3=A7ois Ozog wrote: > Le mer. 13 oct. 2021 =C3=A0 14:55, Tom Rini a =C3=A9= crit : >=20 > > On Wed, Oct 13, 2021 at 10:15:02AM +0200, Fran=C3=A7ois Ozog wrote: > > > Le sam. 18 sept. 2021 =C3=A0 15:18, Tom Rini a = =C3=A9crit : > > > > > > > On Sat, Sep 18, 2021 at 03:38:45AM -0600, Simon Glass wrote: > > > > > Hi, > > > > > > > > > > On Fri, 10 Sept 2021 at 16:44, Tom Rini wrot= e: > > > > > > > > > > > > On Sat, Sep 11, 2021 at 12:09:40AM +0200, Mark Kettenis wrote: > > > > > > > > Date: Fri, 10 Sep 2021 17:17:37 -0400 > > > > > > > > From: Tom Rini > > > > > > > > > > > > > > > > On Fri, Sep 10, 2021 at 11:12:20PM +0200, Mark Kettenis wro= te: > > > > > > > > > > Date: Fri, 10 Sep 2021 08:34:20 -0400 > > > > > > > > > > From: Tom Rini > > > > > > > > > > > > > > > > > > > > On Fri, Sep 10, 2021 at 10:38:17AM +0200, Heinrich > > Schuchardt > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 9/9/21 10:10 PM, Simon Glass wrote: > > > > > > > > > > > > At present some of the ideas and techniques behind > > > > devicetree in U-Boot > > > > > > > > > > > > are assumed, implied or unsaid. Add some documentat= ion > > to > > > > cover how > > > > > > > > > > > > devicetree is build, how it can be modified and the > > rules > > > > about using > > > > > > > > > > > > the various CONFIG_OF_... options. > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > > > > > Reviewed-by: Marcel Ziswiler < > > marcel.ziswiler@toradex.com> > > > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > > > > > > > Changes in v3: > > > > > > > > > > > > - Fix typos linst suppled receive EFL > > > > > > > > > > > > - Drop 'and' before 'self-defeating' > > > > > > > > > > > > - Reword mention of control of QEMU's devicetree > > generation > > > > > > > > > > > > - Add mention of dropping CONFIG_OF_BOARD > > > > > > > > > > > > - Clarify the 'Once this bug is fixed' paragraph a = bit > > > > > > > > > > > > - Expand ways that CONFIG_OF_PRIOR_STAGE can support > > the > > > > U-Boot devicetree > > > > > > > > > > > > - Add a note at the top explaining that his patch > > covers > > > > 'now', not 'future' > > > > > > > > > > > > - Add note 'Note: Some boards use a devicetree in > > U-Boot > > > > which does not match' > > > > > > > > > > > > > > > > > > > > > > > > Changes in v2: > > > > > > > > > > > > - Fix typos per Sean (thank you!) and a few others > > > > > > > > > > > > - Add a 'Use of U-Boot /config node' section > > > > > > > > > > > > - Drop mention of dm-verity since that actually uses > > the > > > > kernel cmdline > > > > > > > > > > > > - Explain that OF_BOARD will still work after these > > > > changes (in > > > > > > > > > > > > 'Once this bug is fixed...' paragraph) > > > > > > > > > > > > - Expand a bit on the reason why the 'Current > > situation' > > > > is bad > > > > > > > > > > > > - Clarify in a second place that Linux and U-Boot u= se > > the > > > > same devicetree > > > > > > > > > > > > in 'To be clear, while U-Boot...' > > > > > > > > > > > > - Expand on why we should have rules for other > > projects in > > > > > > > > > > > > 'Devicetree in another project' > > > > > > > > > > > > - Add a comment as to why devicetree in U-Boot is n= ot > > 'bad > > > > design' > > > > > > > > > > > > - Reword 'in-tree U-Boot devicetree' to 'devicetree > > source > > > > in U-Boot' > > > > > > > > > > > > - Rewrite 'Devicetree generated on-the-fly in anoth= er > > > > project' to cover > > > > > > > > > > > > points raised on v1 > > > > > > > > > > > > - Add 'Why does U-Boot have its nodes and propertie= s?' > > > > > > > > > > > > - Add 'Why not have two devicetrees?' > > > > > > > > > > > > > > > > > > > > > > > > doc/develop/index.rst | 1 + > > > > > > > > > > > > doc/develop/package/devicetree.rst | 583 > > > > +++++++++++++++++++++++++++++ > > > > > > > > > > > > doc/develop/package/index.rst | 1 + > > > > > > > > > > > > 3 files changed, 585 insertions(+) > > > > > > > > > > > > create mode 100644 doc/develop/package/devicetree= =2Erst > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/doc/develop/index.rst > > b/doc/develop/index.rst > > > > > > > > > > > > index 83c929babda..d5ad8f9fe53 100644 > > > > > > > > > > > > --- a/doc/develop/index.rst > > > > > > > > > > > > +++ b/doc/develop/index.rst > > > > > > > > > > > > @@ -36,6 +36,7 @@ Packaging > > > > > > > > > > > > :maxdepth: 1 > > > > > > > > > > > > > > > > > > > > > > > > package/index > > > > > > > > > > > > + package/devicetree > > > > > > > > > > > > > > > > > > > > > > > > Testing > > > > > > > > > > > > ------- > > > > > > > > > > > > diff --git a/doc/develop/package/devicetree.rst > > > > b/doc/develop/package/devicetree.rst > > > > > > > > > > > > new file mode 100644 > > > > > > > > > > > > index 00000000000..b1bd310d906 > > > > > > > > > > > > --- /dev/null > > > > > > > > > > > > +++ b/doc/develop/package/devicetree.rst > > > > > > > > > > > > @@ -0,0 +1,583 @@ > > > > > > > > > > > > +.. SPDX-License-Identifier: GPL-2.0+ > > > > > > > > > > > > + > > > > > > > > > > > > +Updating the devicetree > > > > > > > > > > > > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > > > + > > > > > > > > > > > > +Note: This documentation describes how things are > > today, > > > > mostly, with some > > > > > > > > > > > > +mention of things that need to be fixed. It is not > > > > intended to point the way to > > > > > > > > > > > > +what might be done in the future. That should be t= he > > > > subject of discussions on > > > > > > > > > > > > +the mailing list. > > > > > > > > > > > > + > > > > > > > > > > > > +U-Boot uses devicetree for runtime configuration a= nd > > > > storing required blobs or > > > > > > > > > > > > +any other information it needs to operate. It is > > possible > > > > to update the > > > > > > > > > > > > +devicetree separately from actually building U-Boo= t. > > This > > > > provides a good degree > > > > > > > > > > > > +of control and flexibility for firmware that uses > > U-Boot > > > > in conjunction with > > > > > > > > > > > > +other project. > > > > > > > > > > > > + > > > > > > > > > > > > +There are many reasons why it is useful to modify = the > > > > devicetree after building > > > > > > > > > > > > +it: > > > > > > > > > > > > + > > > > > > > > > > > > +- Configuration can be changed, e.g. which UART to= use > > > > > > > > > > > > +- A serial number can be added > > > > > > > > > > > > +- Public keys can be added to allow image verifica= tion > > > > > > > > > > > > +- Console output can be changed (e.g. to select > > serial or > > > > vidconsole) > > > > > > > > > > > > + > > > > > > > > > > > > +This section describes how to work with devicetree= to > > > > accomplish your goals. > > > > > > > > > > > > + > > > > > > > > > > > > +See also :doc:`../devicetree/control` for a basic > > summary > > > > of the available > > > > > > > > > > > > +features. > > > > > > > > > > > > + > > > > > > > > > > > > + > > > > > > > > > > > > +Devicetree source > > > > > > > > > > > > +----------------- > > > > > > > > > > > > + > > > > > > > > > > > > +Every board in U-Boot must include a devicetree > > > > sufficient to build and boot > > > > > > > > > > > > +that board on suitable hardware (or emulation). Th= is > > is > > > > specified using the > > > > > > > > > > > > +`CONFIG DEFAULT_DEVICE_TREE` option. > > > > > > > > > > > > + > > > > > > > > > > > > + > > > > > > > > > > > > +Current situation (August 2021) > > > > > > > > > > > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > > > > > > > + > > > > > > > > > > > > +As an aside, at present U-Boot allows > > > > `CONFIG_DEFAULT_DEVICE_TREE` to be empty, > > > > > > > > > > > > +e.g. if `CONFIG_OF_BOARD` or `CONFIG_OF_PRIOR_STAG= E` > > are > > > > used. This has > > > > > > > > > > > > +unfortunately created an enormous amount of confus= ion > > and > > > > some wasted effort. > > > > > > > > > > > > +This was not intended and this bug will be fixed s= oon. > > > > > > > > > > > > + > > > > > > > > > > > > +Some of the problems created are: > > > > > > > > > > > > + > > > > > > > > > > > > +- It is not obvious that the devicetree is coming = =66rom > > > > another project > > > > > > > > > > > > + > > > > > > > > > > > > +- There is no way to see even a sample devicetree = for > > > > these platform in U-Boot, > > > > > > > > > > > > + so it is hard to know what is going on, e.g. whi= ch > > > > devices are typically > > > > > > > > > > > > + present > > > > > > > > > > > > + > > > > > > > > > > > > +- The other project may not provide a way to suppo= rt > > > > U-Boot's requirements for > > > > > > > > > > > > + devicetree, such as the /config node. Note: On t= he > > > > U-Boot mailing list, this > > > > > > > > > > > > + was only discovered after weeks of discussion and > > > > confusion > > > > > > > > > > > > + > > > > > > > > > > > > +- For QEMU specifically, consulting two QEMU source > > files > > > > is required, for which > > > > > > > > > > > > + there are no references in U-Boot documentation.= The > > > > code is generating a > > > > > > > > > > > > + devicetree, with some control from command-line > > args, > > > > but it is not clear > > > > > > > > > > > > + how to add properties required by U-Boot. > > > > > > > > > > > > + > > > > > > > > > > > > +Specifically on the changes in U-Boot: > > > > > > > > > > > > + > > > > > > > > > > > > +- `CONFIG_OF_BOARD` was added in rpi_patch_ for > > Raspberry > > > > Pi, which does have > > > > > > > > > > > > + an in-tree devicetree, but this feature has since > > been > > > > used for boards that > > > > > > > > > > > > + don't > > > > > > > > > > > > +- `CONFIG_OF_PRIOR_STAGE` was added in bcm_patch_ = as > > part > > > > of a larger Broadcom > > > > > > > > > > > > + change with a tag indicating it only affected one > > > > board, so the change in > > > > > > > > > > > > + behaviour was not noticed at the time. It has si= nce > > > > been used by RISC-V qemu > > > > > > > > > > > > + boards. > > > > > > > > > > > > + > > > > > > > > > > > > +Note: It is not clear that we actually need both of > > > > these. Possibly > > > > > > > > > > > > +`CONFIG_OF_BOARD` can be dropped. > > > > > > > > > > > > + > > > > > > > > > > > > +Once this bug is fixed, CONFIG_OF_BOARD and > > > > CONFIG_OF_PRIOR_STAGE will override > > > > > > > > > > > > > > > > > > > > > > What does "bug" refer to? Above you describe the curr= ent > > > > design not a bug. > > > > > > > > > > > > > > > > > > > > The bug is that we have two options to provide seemingly > > the > > > > same > > > > > > > > > > functionality. Is there a functional difference between > > > > CONFIG_OF_BOARD > > > > > > > > > > and CONFIG_OF_PRIOR_STAGE ? > > > > > > > > > > > > > > > > > > With CONFIG_OF_BOARD there is a function that returns the > > > > pointer to > > > > > > > > > the DTB, so you can do all sort of things with it. > > > > > > > > > > > > > > > > > > With CONFIG_OF_PRIOR_STAGE there is a variable that you n= eed > > to > > > > set in > > > > > > > > > low-level code to point at the DTB and there is a pre-def= ined > > > > function > > > > > > > > > that returns that pointer. > > > > > > > > > > > > > > > > > > CONFIG_OF_BOARD is more flexible than CONFIG_OF_PRIOR_STA= GE, > > but > > > > if > > > > > > > > > the only thing you want to do is to pass on a DTB that is > > passed > > > > in a > > > > > > > > > CPU register to U-Boot then CONFIG_OF_PRIOR_STAGE is prob= ably > > > > easier > > > > > > > > > to use. > > > > > > > > > > > > > > > > > > I'm not convinced there is a bug here. > > > > > > > > > > > > > > > > Thanks for explaining. Couldn't CONFIG_OF_PRIOR_STAGE be > > > > rewritten as > > > > > > > > an implementation of CONFIG_OF_BOARD, possibly at the same = or > > less > > > > > > > > overall code size? That I think is the potential bug. > > > > > > > > > > > > > > Probably a little bit more code: > > > > > > > > > > > > > > void * > > > > > > > board_fdt_blob_setup(void) > > > > > > > { > > > > > > > return (void *)(uintptr_t)prior_stage_fdt_address; > > > > > > > } > > > > > > > > > > > > Tiny bit more. Probably worth doing to make the choices cleare= r on > > > > > > which to select when? Bin, Rick, thoughts on this since riscv = is > > the > > > > > > main user of CONFIG_OF_PRIOR_STAGE at this point? > > > > > > > > > > Bin, Rick? > > > > > > > > > > What is the prior stage in the RISC-V stage? Could we get it to s= et > > up > > > > > a bloblist? Then we can add a devicetree in there, with the optio= n to > > > > > add more things in future. > > > > > > > > I'm suggesting we don't need to do anything upstream of us, just re= work > > > > things to use the other hook for "provided a DTB by caller, use it"= , so > > > > that we have a single hook for that. > > > > > > What was the rationale in posting in kernel.org ( > > > > > https://lore.kernel.org/all/20211003125134.2.I7733f5a849476e908cc51f0c7= 1b8a594337fbbdf@changeid/ > > > ) and not in U-Boot knowing there is still no consensus on the big > > picture ? > > > > Well, because we need to get our bindings reviewed and made official, > > and that looked like a reasonable place and choice to start with? v2 > > cc'd a different set of lists, at Rob's suggestion. >=20 > making it =E2=80=9C Official=E2=80=9D does not necessarily mean in the Li= nux DT. What would > you think with a hardware description file that comes with U-Boot, No? A project-specific binding is only valid within the project. So unless it's a linux,foo binding it's not "Linux DT", it's generic. Part of the point in pushing this up for real review is that IF we want to be passed this information then it needs to be a real official and reviewed binding. And that process in turn meanings convincing other (generally skeptical) people it's a good idea. And maybe that it should take a more generic approach. > LinuxBoot and EDK2 config options ? No need for Linux to know about those > U-Boot internal config? Why would those U-Boot elements be passed down to > any OS ? I don't see the harm? > Do you expect to have bootloader specific behavior in distros ? And I don't see where you're coming from with this point. > TF-A makes the binding official and standardized in its own documentation. > U-Boot can and should do the same. That's not a standard, that's project documentation. Heck, the impression I've got now on re-skimming that cot binding from TF-A is that it's a FIT image, with verified boot type information, by another name (and a few tweaks/enhancements, certainly). That seems like yet another missed opportunity. To put things another way, it seems like everyone has some project-specific one-offs for how to configure the information that's needed to get a functional system going. Maybe if bindings were upstreamed we'd been in a better place and projects would be using more common features, and not just the ones inherited from Linux. --=20 Tom --6IeHAMkZHKx0vIy5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmFm31gACgkQFHw5/5Y0 tyx52wv/cO/+sv5P75xeWK6/hYn0NJi4fe5oPb3iIsWE2tSM01Om2dXfC9Pf4hj4 Z+/svZq2CxYC62JT7bDnk0wZ5QmZTmZDUKn6p0hGhV8C9UN2QsDkckVYM1X2zbPC DQGTt1qEWOEMtLgi5DlG0qC8tB85F9sc6HFFCA7fRytOX1uPP/0+dKkdqdv+4Jpa JDot053zu/hYVXtmHvxsjDhth4HTASOh0LyxaUtLpDKljuviSS5dcP9rOwDbPzLE C2Xh9ONwkwY+XqdzPJykq0Km9X+VWLZXt6h6IcG/vWJQBsJCxATyUb4hRqp8eHtK Sf7ImeoVOIaJdO3bvRhP/WeTN4qJcrJokBHEeucHU+kFdvEDQgploD1d/URUMU86 c774+3OCpsstGfewETcUQbGOZ3GDxD0hoY2eDWaJptkMn6L/4EFHqAsEw6yHT+RP NvYITEV3okRRQIL7zmTAb4VjandwUemWfsWDlv9726FIfnpGQHXOvkkR4ejDJM9u VYq8pu2m =J4bu -----END PGP SIGNATURE----- --6IeHAMkZHKx0vIy5--