* Re: [PATCH] PowerPC 44x: use machine_device_initcall() instead of device_initcall() for warp_nand
From: Grant Likely @ 2008-04-04 18:49 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20080404182437.GA18185@ru.mvista.com>
On Fri, Apr 4, 2008 at 12:24 PM, Valentine Barshak
<vbarshak@ru.mvista.com> wrote:
> With a multiplatform kernel, once built we always have warp_setup_nand_flash() called
> and NDFC probed, no matter what machine we actually run on. This potentially can cause
> problems (such as kernel crash), since NDFC is probed at a warp-predefined address.
> Using machine_device_initcall() NAND devices are registered if we run on a warp only.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> arch/powerpc/platforms/44x/warp-nand.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletion(-)
>
> --- linux-2.6.orig/arch/powerpc/platforms/44x/warp-nand.c 2008-03-06 14:39:46.000000000 +0300
> +++ linux-2.6.bld/arch/powerpc/platforms/44x/warp-nand.c 2008-04-04 22:03:36.000000000 +0400
> @@ -11,6 +11,7 @@
> #include <linux/mtd/partitions.h>
> #include <linux/mtd/nand.h>
> #include <linux/mtd/ndfc.h>
> +#include <asm/machdep.h>
>
> #ifdef CONFIG_MTD_NAND_NDFC
>
> @@ -100,6 +101,6 @@ static int warp_setup_nand_flash(void)
>
> return 0;
> }
> -device_initcall(warp_setup_nand_flash);
> +machine_device_initcall(warp, warp_setup_nand_flash);
>
> #endif
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [kvm-ppc-devel] [PATCH] [v2] Add idle wait support for 44x platforms
From: Segher Boessenkool @ 2008-04-04 18:47 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <835D8B13-CF90-4013-A172-8243BF93DE52@pobox.com>
>> + msr_save = mfmsr();
>> + /* set wait state MSR */
>> + mtmsr(msr_save|MSR_WE|MSR_EE|MSR_CE);
>
> Did we decide to drop MSR_DE?
>
>> + /* return to initial state */
>> + mtmsr(msr_save);
>
> It may be my paranoia but I'm pretty sure you need the isync() after
> _both_ mtmsr()s
> Certainly can't hurt.
It hurts because it spreads the paranoia. Cargo cult.
Please add a comment that explains _why_ you need a context
synchronising
instruction here. The POWER ISA 2.05 says that the requirements for
changing the WE bit are implementation dependent, both before and after
the mtmsr, so the safe thing to do would be to use the "big hammer"
isync
both before and after each of these mtmsrs. A sync before entering wait
state might be needed as well, dunno. Either way, comment please :-)
Segher
^ permalink raw reply
* [PATCH] PowerPC 44x: use machine_device_initcall() instead of device_initcall() for warp_nand
From: Valentine Barshak @ 2008-04-04 18:24 UTC (permalink / raw)
To: linuxppc-dev
With a multiplatform kernel, once built we always have warp_setup_nand_flash() called
and NDFC probed, no matter what machine we actually run on. This potentially can cause
problems (such as kernel crash), since NDFC is probed at a warp-predefined address.
Using machine_device_initcall() NAND devices are registered if we run on a warp only.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/platforms/44x/warp-nand.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
--- linux-2.6.orig/arch/powerpc/platforms/44x/warp-nand.c 2008-03-06 14:39:46.000000000 +0300
+++ linux-2.6.bld/arch/powerpc/platforms/44x/warp-nand.c 2008-04-04 22:03:36.000000000 +0400
@@ -11,6 +11,7 @@
#include <linux/mtd/partitions.h>
#include <linux/mtd/nand.h>
#include <linux/mtd/ndfc.h>
+#include <asm/machdep.h>
#ifdef CONFIG_MTD_NAND_NDFC
@@ -100,6 +101,6 @@ static int warp_setup_nand_flash(void)
return 0;
}
-device_initcall(warp_setup_nand_flash);
+machine_device_initcall(warp, warp_setup_nand_flash);
#endif
^ permalink raw reply
* [PATCH] [POWERPC] pasemi: Minor cleanups of iommu code
From: Olof Johansson @ 2008-04-04 18:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: pasemi-linux
Clean up the pwrficient iommu code a bit. It was using u32 *-based offsets
for registers, which can be confusing when comparing to the manual.
Generated binaries from the code is unchanged from before.
---
This will be pushed to for-2.6.26 of pasemi.git, so no signed-off here.
diff --git a/arch/powerpc/platforms/pasemi/iommu.c b/arch/powerpc/platforms/pasemi/iommu.c
index 5803f11..86967bd 100644
--- a/arch/powerpc/platforms/pasemi/iommu.c
+++ b/arch/powerpc/platforms/pasemi/iommu.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2005-2007, PA Semi, Inc
+ * Copyright (C) 2005-2008, PA Semi, Inc
*
* Maintained by: Olof Johansson <olof@lixom.net>
*
@@ -27,7 +27,6 @@
#include <asm/abs_addr.h>
#include <asm/firmware.h>
-
#define IOBMAP_PAGE_SHIFT 12
#define IOBMAP_PAGE_SIZE (1 << IOBMAP_PAGE_SHIFT)
#define IOBMAP_PAGE_MASK (IOBMAP_PAGE_SIZE - 1)
@@ -35,13 +34,13 @@
#define IOB_BASE 0xe0000000
#define IOB_SIZE 0x3000
/* Configuration registers */
-#define IOBCAP_REG 0x10
-#define IOBCOM_REG 0x40
+#define IOBCAP_REG 0x40
+#define IOBCOM_REG 0x100
/* Enable IOB address translation */
#define IOBCOM_ATEN 0x00000100
/* Address decode configuration register */
-#define IOB_AD_REG 0x53
+#define IOB_AD_REG 0x14c
/* IOBCOM_AD_REG fields */
#define IOB_AD_VGPRT 0x00000e00
#define IOB_AD_VGAEN 0x00000100
@@ -56,13 +55,13 @@
#define IOB_AD_TRNG_2G 0x00000001
#define IOB_AD_TRNG_128G 0x00000003
-#define IOB_TABLEBASE_REG 0x55
+#define IOB_TABLEBASE_REG 0x154
/* Base of the 64 4-byte L1 registers */
-#define IOB_XLT_L1_REGBASE 0xac0
+#define IOB_XLT_L1_REGBASE 0x2b00
/* Register to invalidate TLB entries */
-#define IOB_AT_INVAL_TLB_REG 0xb40
+#define IOB_AT_INVAL_TLB_REG 0x2d00
/* The top two bits of the level 1 entry contains valid and type flags */
#define IOBMAP_L1E_V 0x40000000
@@ -76,7 +75,7 @@
#define IOBMAP_L2E_V 0x80000000
#define IOBMAP_L2E_V_CACHED 0xc0000000
-static u32 __iomem *iob;
+static void __iomem *iob;
static u32 iob_l1_emptyval;
static u32 iob_l2_emptyval;
static u32 *iob_l2_base;
@@ -219,7 +218,7 @@ int __init iob_init(struct device_node *dn)
for (i = 0; i < 64; i++) {
/* Each L1 covers 32MB, i.e. 8K entries = 32K of ram */
regword = IOBMAP_L1E_V | (__pa(iob_l2_base + i*0x2000) >> 12);
- out_le32(iob+IOB_XLT_L1_REGBASE+i, regword);
+ out_le32(iob+IOB_XLT_L1_REGBASE+i*4, regword);
}
/* set 2GB translation window, based at 0 */
^ permalink raw reply related
* Re: [PATCH] PowerPC: MPIC ack interrupts at mpic_teardown_this_cpu()
From: Olof Johansson @ 2008-04-04 18:03 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <9d19fecb0ef172995b7ce3a317ee3c0d@kernel.crashing.org>
On Fri, Apr 04, 2008 at 07:38:27PM +0200, Segher Boessenkool wrote:
>>>> We really need to ack interrupts at mpic_teardown, since
>>>> not all platforms reset mpic at kernel start-up. For example,
>>>> kexec'ed kernel hangs on P.A. Semi if mpic_eoi() isn't called.
>>>>
>>>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>>>> ---
>>>
>>> Would be interesting to find out why it hangs tho... it shouldn't .
>>
>> I haven't reproduced the problem and looked at hardware state yet, but
>> I
>> would expect it to be because the openpic won't send another interrupt
>> until the previous is EOI'd, and the IPI is never EOI'd as far as I
>> can tell.
>>
>> The XICS code does it explicitly already. I'm surprised it doesn't
>> break
>> on the 970-based platforms actually...
>
> platforms/maple/setup.c and platforms/powermac/pic.c use
> MPIC_WANTS_RESET.
> Is there a reason why we don't do that on every MPIC? If there is such
> a reason, the default should be to reset, only pseries and chrp and cell
> and now pasemi do not use it. It's the only sane way to get an MPIC
> into
> a sane known state starting from <whatever> state.
I used to have the reset there on pasemi but due to some other issues I
ended up taking it out.
It's not like doing a final EOI is a big deal, I really don't see why
there's hassle about this patch.
-Olof
^ permalink raw reply
* Re: [PATCH] PowerPC: MPIC ack interrupts at mpic_teardown_this_cpu()
From: Segher Boessenkool @ 2008-04-04 17:38 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20080404052955.GC11799@lixom.net>
>>> We really need to ack interrupts at mpic_teardown, since
>>> not all platforms reset mpic at kernel start-up. For example,
>>> kexec'ed kernel hangs on P.A. Semi if mpic_eoi() isn't called.
>>>
>>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>>> ---
>>
>> Would be interesting to find out why it hangs tho... it shouldn't .
>
> I haven't reproduced the problem and looked at hardware state yet, but
> I
> would expect it to be because the openpic won't send another interrupt
> until the previous is EOI'd, and the IPI is never EOI'd as far as I
> can tell.
>
> The XICS code does it explicitly already. I'm surprised it doesn't
> break
> on the 970-based platforms actually...
platforms/maple/setup.c and platforms/powermac/pic.c use
MPIC_WANTS_RESET.
Is there a reason why we don't do that on every MPIC? If there is such
a reason, the default should be to reset, only pseries and chrp and cell
and now pasemi do not use it. It's the only sane way to get an MPIC
into
a sane known state starting from <whatever> state.
Segher
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Grant Likely @ 2008-04-04 17:25 UTC (permalink / raw)
To: Josh Boyer; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <1207329303.6518.16.camel@weaponx>
On Fri, Apr 4, 2008 at 11:15 AM, Josh Boyer > > I really like the
idea. It would probably make sense to organize it in
> > the same way as the platforms are done today, i.e. per processor/platform
> > family. And then have shared/merged configs in the main config directory.
>
> Yes. I was thinking the same already for 4xx. Essentially:
>
> configs/ppc44x_defconfig
> configs/ppc40x_defconfig
> configs/44x/<board>_defconfig
> configs/40x/<board>_defconfig
Sounds logical. I'm cool with this.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Josh Boyer @ 2008-04-04 17:15 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20080404163858.GA25717@lixom.net>
On Fri, 2008-04-04 at 11:38 -0500, Olof Johansson wrote:
> On Fri, Apr 04, 2008 at 10:14:34AM -0600, Grant Likely wrote:
> > On Fri, Apr 4, 2008 at 10:11 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > > > > I'm thinking 'optimized' defconfigs should go into a subdirectory.
> > > > >
> > > > > This requires a change to the top-level Makefile and shepherding this
> > > > > change upstream. Could we perhaps try to avoid this by having optimized
> > > > > defconfigs in the form of, for example:
> > >
> > > I don't think changes are required to put them in a subdir:
> > >
> > > $ mkdir arch/powerpc/configs/optimized
> > > $ cp arch/powerpc/configs/mpc5200_defconfig
> > > arch/powerpc/configs/optimized/lite5200_defconfig
> > > $ make optimized/lite5200_defconfig
> > >
> > > This works for me.
> >
> > However, I'm not sure what the naming scheme should be for subdirectories.
> >
> > board vendor?
> > host processor?
> > just one big directory for board specific defconfigs?
> >
> > Olof, Kumar, Josh; any thoughts?
> >
> > Not that it matters much; files are easy to move around later.
>
> I really like the idea. It would probably make sense to organize it in
> the same way as the platforms are done today, i.e. per processor/platform
> family. And then have shared/merged configs in the main config directory.
Yes. I was thinking the same already for 4xx. Essentially:
configs/ppc44x_defconfig
configs/ppc40x_defconfig
configs/44x/<board>_defconfig
configs/40x/<board>_defconfig
josh
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Olof Johansson @ 2008-04-04 16:38 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40804040914s3f682e37r16b4cb299e2fc97e@mail.gmail.com>
On Fri, Apr 04, 2008 at 10:14:34AM -0600, Grant Likely wrote:
> On Fri, Apr 4, 2008 at 10:11 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > > > I'm thinking 'optimized' defconfigs should go into a subdirectory.
> > > >
> > > > This requires a change to the top-level Makefile and shepherding this
> > > > change upstream. Could we perhaps try to avoid this by having optimized
> > > > defconfigs in the form of, for example:
> >
> > I don't think changes are required to put them in a subdir:
> >
> > $ mkdir arch/powerpc/configs/optimized
> > $ cp arch/powerpc/configs/mpc5200_defconfig
> > arch/powerpc/configs/optimized/lite5200_defconfig
> > $ make optimized/lite5200_defconfig
> >
> > This works for me.
>
> However, I'm not sure what the naming scheme should be for subdirectories.
>
> board vendor?
> host processor?
> just one big directory for board specific defconfigs?
>
> Olof, Kumar, Josh; any thoughts?
>
> Not that it matters much; files are easy to move around later.
I really like the idea. It would probably make sense to organize it in
the same way as the platforms are done today, i.e. per processor/platform
family. And then have shared/merged configs in the main config directory.
-Olof
^ permalink raw reply
* [PATCH] [v4] Add idle wait support for 44x platforms
From: Jerone Young @ 2008-04-04 16:28 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kvm-ppc-devel
2 files changed, 87 insertions(+), 1 deletion(-)
arch/powerpc/platforms/44x/Makefile | 2
arch/powerpc/platforms/44x/idle.c | 86 +++++++++++++++++++++++++++++++++++
- adds MSR_DE to MSRs to enable while in wait state
This patch adds the ability for the CPU to go into wait state while in cpu_idle loop. This helps virtulization solutions know when the guest Linux kernel is in an idle state. There are two ways to do it.
1) Command line
idle=spin <-- CPU will spin (this is the default)
idle=wait <-- set CPU into wait state when idle
2) The device tree will be checked for the "/hypervisor" node
If this node is seen it will use "wait" for idle, so that
the hypervisor can know when guest Linux kernel it is in
an idle state.
This patch, unlike the last, isolates the code to 44x platforms.
Signed-off-by: Jerone Young <jyoung5@us.ibm.com>
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -1,4 +1,4 @@ obj-$(CONFIG_44x) := misc_44x.o
-obj-$(CONFIG_44x) := misc_44x.o
+obj-$(CONFIG_44x) := misc_44x.o idle.o
obj-$(CONFIG_EBONY) += ebony.o
obj-$(CONFIG_TAISHAN) += taishan.o
obj-$(CONFIG_BAMBOO) += bamboo.o
diff --git a/arch/powerpc/platforms/44x/idle.c b/arch/powerpc/platforms/44x/idle.c
new file mode 100644
--- /dev/null
+++ b/arch/powerpc/platforms/44x/idle.c
@@ -0,0 +1,86 @@
+/*
+ * Copyright 2008 IBM Corp.
+ *
+ * Based on arch/powerpc/platforms/pasemi/idle.c:
+ * Copyright (C) 2006-2007 PA Semi, Inc
+ *
+ * Added by: Jerone Young <jyoung5@us.ibm.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include <linux/of.h>
+#include <linux/kernel.h>
+#include <asm/machdep.h>
+
+static int current_mode;
+
+struct sleep_mode {
+ char *name;
+ void (*entry)(void);
+};
+
+static void ppc44x_idle(void)
+{
+ unsigned long msr_save;
+
+ msr_save = mfmsr();
+ /* set wait state MSR */
+ mtmsr(msr_save|MSR_WE|MSR_EE|MSR_CE|MSR_DE);
+ isync();
+ /* return to initial state */
+ mtmsr(msr_save);
+ isync();
+}
+
+static struct sleep_mode modes[] = {
+ { .name = "spin", .entry = NULL },
+ { .name = "wait", .entry = &ppc44x_idle },
+};
+
+int __init ppc44x_idle_init(void)
+{
+ void *func = modes[current_mode].entry;
+ struct device_node *node;
+
+ node = of_find_node_by_path("/hypervisor");
+ if (node) {
+ /* if we find /hypervisor node is in device tree,
+ set idle mode to wait */
+ func = &ppc44x_idle; /* wait */
+ of_node_put(node);
+ }
+
+ ppc_md.power_save = func;
+ return 0;
+}
+
+arch_initcall(ppc44x_idle_init);
+
+static int __init idle_param(char *p)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(modes); i++) {
+ if (!strcmp(modes[i].name, p)) {
+ current_mode = i;
+ break;
+ }
+ }
+
+ return 0;
+}
+
+early_param("idle", idle_param);
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Grant Likely @ 2008-04-04 16:14 UTC (permalink / raw)
To: Bartlomiej Sieka; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <fa686aa40804040911o63e2e3efg2d9a74fff082fb16@mail.gmail.com>
On Fri, Apr 4, 2008 at 10:11 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > > I'm thinking 'optimized' defconfigs should go into a subdirectory.
> > >
> > > This requires a change to the top-level Makefile and shepherding this
> > > change upstream. Could we perhaps try to avoid this by having optimized
> > > defconfigs in the form of, for example:
>
> I don't think changes are required to put them in a subdir:
>
> $ mkdir arch/powerpc/configs/optimized
> $ cp arch/powerpc/configs/mpc5200_defconfig
> arch/powerpc/configs/optimized/lite5200_defconfig
> $ make optimized/lite5200_defconfig
>
> This works for me.
However, I'm not sure what the naming scheme should be for subdirectories.
board vendor?
host processor?
just one big directory for board specific defconfigs?
Olof, Kumar, Josh; any thoughts?
Not that it matters much; files are easy to move around later.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Grant Likely @ 2008-04-04 16:11 UTC (permalink / raw)
To: Bartlomiej Sieka; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <47F60D5D.5090402@semihalf.com>
On Fri, Apr 4, 2008 at 5:13 AM, Bartlomiej Sieka <tur@semihalf.com> wrote:
>
> Bartlomiej Sieka wrote:
>
> > Hi Grant,
> >
> > Grant Likely wrote:
> > > I'm thinking 'optimized' defconfigs should go into a subdirectory.
> >
> > This requires a change to the top-level Makefile and shepherding this
> > change upstream. Could we perhaps try to avoid this by having optimized
> > defconfigs in the form of, for example:
I don't think changes are required to put them in a subdir:
$ mkdir arch/powerpc/configs/optimized
$ cp arch/powerpc/configs/mpc5200_defconfig
arch/powerpc/configs/optimized/lite5200_defconfig
$ make optimized/lite5200_defconfig
This works for me.
>
> Grant,
>
> Any thoughts on the above?
Sorry I didn't reply earlier
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [kvm-ppc-devel] [PATCH] [v2] Add idle wait support for 44x platforms
From: Hollis Blanchard @ 2008-04-04 15:56 UTC (permalink / raw)
To: jyoung5; +Cc: kvm-ppc-devel, linuxppc-dev, Jimi Xenidis
In-Reply-To: <1207323761.6634.6.camel@thinkpadL>
On Friday 04 April 2008 10:42:41 Jerone Young wrote:
> > > +{
> > > +=A0=A0=A0unsigned long msr_save;
> > > +
> > > +=A0=A0=A0msr_save =3D mfmsr();
> > > +=A0=A0=A0/* set wait state MSR */
> > > +=A0=A0=A0mtmsr(msr_save|MSR_WE|MSR_EE|MSR_CE);
> >
> > Did we decide to drop MSR_DE?
>
> Hollis argued it down on an earlier email on kvm-ppc-devel. Though I did
> have it in one of the earlier patches.
I didn't comment either way. However, looking at the 440 user manual now, i=
t=20
seems clear that DE should be set to allow JTAG debugger events.
=2D-=20
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* [PATCH] [v3] Add idle wait support for 44x platforms
From: Jerone Young @ 2008-04-04 15:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kvm-ppc-devel
2 files changed, 87 insertions(+), 1 deletion(-)
arch/powerpc/platforms/44x/Makefile | 2
arch/powerpc/platforms/44x/idle.c | 86 +++++++++++++++++++++++++++++++++++
This patch adds the ability for the CPU to go into wait state while in cpu_idle loop. This helps virtulization solutions know when the guest Linux kernel is in an idle state. There are two ways to do it.
1) Command line
idle=spin <-- CPU will spin (this is the default)
idle=wait <-- set CPU into wait state when idle
2) The device tree will be checked for the "/hypervisor" node
If this node is seen it will use "wait" for idle, so that
the hypervisor can know when guest Linux kernel it is in
an idle state.
This patch, unlike the last, isolates the code to 44x platforms.
Signed-off-by: Jerone Young <jyoung5@us.ibm.com>
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -1,4 +1,4 @@ obj-$(CONFIG_44x) := misc_44x.o
-obj-$(CONFIG_44x) := misc_44x.o
+obj-$(CONFIG_44x) := misc_44x.o idle.o
obj-$(CONFIG_EBONY) += ebony.o
obj-$(CONFIG_TAISHAN) += taishan.o
obj-$(CONFIG_BAMBOO) += bamboo.o
diff --git a/arch/powerpc/platforms/44x/idle.c b/arch/powerpc/platforms/44x/idle.c
new file mode 100644
--- /dev/null
+++ b/arch/powerpc/platforms/44x/idle.c
@@ -0,0 +1,86 @@
+/*
+ * Copyright 2008 IBM Corp.
+ *
+ * Based on arch/powerpc/platforms/pasemi/idle.c:
+ * Copyright (C) 2006-2007 PA Semi, Inc
+ *
+ * Added by: Jerone Young <jyoung5@us.ibm.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include <linux/of.h>
+#include <linux/kernel.h>
+#include <asm/machdep.h>
+
+static int current_mode;
+
+struct sleep_mode {
+ char *name;
+ void (*entry)(void);
+};
+
+static void ppc44x_idle(void)
+{
+ unsigned long msr_save;
+
+ msr_save = mfmsr();
+ /* set wait state MSR */
+ mtmsr(msr_save|MSR_WE|MSR_EE|MSR_CE);
+ isync();
+ /* return to initial state */
+ mtmsr(msr_save);
+ isync();
+}
+
+static struct sleep_mode modes[] = {
+ { .name = "spin", .entry = NULL },
+ { .name = "wait", .entry = &ppc44x_idle },
+};
+
+int __init ppc44x_idle_init(void)
+{
+ void *func = modes[current_mode].entry;
+ struct device_node *node;
+
+ node = of_find_node_by_path("/hypervisor");
+ if (node) {
+ /* if we find /hypervisor node is in device tree,
+ set idle mode to wait */
+ func = &ppc44x_idle; /* wait */
+ of_node_put(node);
+ }
+
+ ppc_md.power_save = func;
+ return 0;
+}
+
+arch_initcall(ppc44x_idle_init);
+
+static int __init idle_param(char *p)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(modes); i++) {
+ if (!strcmp(modes[i].name, p)) {
+ current_mode = i;
+ break;
+ }
+ }
+
+ return 0;
+}
+
+early_param("idle", idle_param);
^ permalink raw reply
* Re: [kvm-ppc-devel] [PATCH] [v2] Add idle wait support for 44x platforms
From: Jerone Young @ 2008-04-04 15:42 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <835D8B13-CF90-4013-A172-8243BF93DE52@pobox.com>
On Fri, 2008-04-04 at 08:36 -0400, Jimi Xenidis wrote:
> On Apr 4, 2008, at 3:06 AM, Jerone Young wrote:
>
> > # HG changeset patch
> > # User Jerone Young <jyoung5@us.ibm.com>
> > # Date 1207292108 18000
> > # Node ID afed3e5de82ab6c0ac8d6ceeb0292b6c41ece1ed
> > # Parent a5b2aebbc6ebd2439c655f1c047ed7e3c1991ec1
> > [v2] Add idle wait support for 44x platforms
> >
> > This patch adds the ability for the CPU to go into wait state while
> > in cpu_idle loop. This helps virtulization solutions know when the
> > guest Linux kernel is in an idle state. There are two ways to do it.
> >
> > 1) Command line
> > idle=spin <-- CPU will spin (this is the default)
> > idle=wait <-- set CPU into wait state when idle
> >
> > 2) The device tree will be checked for the "/hypervisor" node
> > If this node is seen it will use "wait" for idle, so that
> > the hypervisor can know when guest Linux kernel it is in
> > an idle state.
> >
> > This patch, unlike the last, isolates the code to 44x platforms.
> >
> > Signed-off-by: Jerone Young <jyoung5@us.ibm.com>
> >
> > diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/
> > platforms/44x/Makefile
> > --- a/arch/powerpc/platforms/44x/Makefile
> > +++ b/arch/powerpc/platforms/44x/Makefile
> > @@ -1,4 +1,4 @@ obj-$(CONFIG_44x) := misc_44x.o
> > -obj-$(CONFIG_44x) := misc_44x.o
> > +obj-$(CONFIG_44x) := misc_44x.o idle.o
> > obj-$(CONFIG_EBONY) += ebony.o
> > obj-$(CONFIG_TAISHAN) += taishan.o
> > obj-$(CONFIG_BAMBOO) += bamboo.o
> > diff --git a/arch/powerpc/platforms/44x/idle.c b/arch/powerpc/
> > platforms/44x/idle.c
> > new file mode 100644
> > --- /dev/null
> > +++ b/arch/powerpc/platforms/44x/idle.c
> > @@ -0,0 +1,84 @@
> > +/*
> > + * Copyright 2008 IBM Corp.
> > + *
> > + * Derived from pasemi/idle.c
> > + * by Olof Johansson <olof@lixom.net>
> > + *
> > + * Added by: Jerone Young <jyoung5@us.ibm.com>
> > + *
> > + * This program is free software; you can redistribute it and/or
> > modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > + * along with this program; if not, write to the Free Software
> > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
> > 02111-1307 USA
> > + *
> > + */
> > +
> > +#include <linux/of.h>
> > +#include <linux/kernel.h>
> > +#include <asm/machdep.h>
> > +
> > +static int current_mode = 0;
>
> Doesn't matter if the 0 is functionally redundant or pleasing to your
> eye, it is the "Linux way" to leave out the " = 0", so just do it
> please.
>
Ok this can be removed.
> > +
> > +struct sleep_mode {
> > + char *name;
> > + void (*entry)(void);
> > +};
> > +
> > +static void ppc44x_idle(void)
> Perhaps "ppc44x_wait" is more appropriate?
> > +{
> > + unsigned long msr_save;
> > +
> > + msr_save = mfmsr();
> > + /* set wait state MSR */
> > + mtmsr(msr_save|MSR_WE|MSR_EE|MSR_CE);
>
> Did we decide to drop MSR_DE?
Hollis argued it down on an earlier email on kvm-ppc-devel. Though I did
have it in one of the earlier patches.
>
> > + /* return to initial state */
> > + mtmsr(msr_save);
>
> It may be my paranoia but I'm pretty sure you need the isync() after
> _both_ mtmsr()s
> Certainly can't hurt.
I could add this back. Though everyone had already agreed on it without
it. So figured it was safer to go witout it. But I can add it back.
>
> > +}
> > +
> > +static struct sleep_mode modes[] = {
> > + { .name = "spin", .entry = NULL },
> > + { .name = "wait", .entry = &ppc44x_idle },
> > +};
> > +
> > +int __init ppc44x_idle_init(void)
> > +{
> > + void *func = modes[current_mode].entry;
> > + struct device_node *node;
> > +
> > + node = of_find_node_by_path("/hypervisor");
> > + if (node) {
> > + /* if we find /hypervisor node is in device tree,
> > + set idle mode to wait */
> > + func = &ppc44x_idle; /* wait */
> > + of_node_put(node);
> > + }
> > +
> > + ppc_md.power_save = func;
> > + return 0;
> > +}
> > +
> > +arch_initcall(ppc44x_idle_init);
>
> IIRC, this would over-ride the idle_param() below, is that the
> intended behavior?
Yes. At the moment if it detects a hypervisor in the kernel tree it
overrides what the command line says.
>
> > +
> > +static int __init idle_param(char *p)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < sizeof(modes)/ARRAY_SIZE(modes); i++) {
>
> It is supposed to be:
> for (i = 0; i < ARRAY_SIZE(modes); i++) {
> What you have will actually eval to 0 and would have never checked
> anything :)
Ouch. My bad. Wasn't thinking when I added that.
>
> > + if (!strcmp(modes[i].name, p)) {
> > + current_mode = i;
> > + break;
> > + }
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +early_param("idle", idle_param);
> >
> > ----------------------------------------------------------------------
> > ---
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/
> > marketplace
> > _______________________________________________
> > kvm-ppc-devel mailing list
> > kvm-ppc-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel
>
^ permalink raw reply
* Re: Help required on MPC82XX USB Host controller Development using m82xx-hcd.
From: Amarendra_Reddy @ 2008-04-04 14:47 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200803270956.12203.laurentp@cse-semaphore.com>
Hi Laurent,
Thanks for your reply.
Most of the modules of the new product(based on Kernrel 2.6.10) are
completed, except for the USB module. Hence we have to work with the kernre=
l
2.6.10 even for USB module.
We integrated cmp2usb project into Kernel 2.6.10, and with some
modifications and compiled the kernel successfully.
When pendrive is inserted into the USB port we are facing the below
mentioned problems.
(sorry for a lengthy posting)
We would be thankful if you / anyone could suggest us with some solution or
idea or an alternative approach.
Given below is the Console Output=20
CASE 1: When pendrive is inserted "Directly to USB port of the 8272ADS
board".
CASE 2: When pendrive is inserted on an "External hub which is conntected t=
o
USB port of 8272ADS board".
Output from console:
CASE 1: Pendrive Directly connected to uSB port of the 8272ADS board
USB Universal Host Controller Interface driver v2.2
Registering platform device 'mpc82xx-hcd.3'. Parent at platform
=3D> driver mpc82xx-hcd, 2005
mpc82xx-hcd mpc82xx-hcd.3: PQ2 intergrated USB controller v0.1
mpc82xx-hcd mpc82xx-hcd.3: new USB bus registered, assigned bus number 1
usb usb1: Product: PQ2 intergrated USB controller v0.1
usb usb1: Manufacturer: Linux 2.6.10_mvl401-8272ads mpc82xx-hcd
usb usb1: SerialNumber: mpc82xx-hcd.3
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
PQ2USB: debug file creation
........after SANDISK pendrive inserted.........
usb 1-1: new full speed USB device using mpc82xx-hcd and address 2
usb 1-1: Product: U3 Cruzer Micro
usb 1-1: Manufacturer: SanDisk Corporation
Oops: Exception in kernel mode, sig: 4 [#1]
........after unknown/generic manufacturer's pendrive inserted.......
usb 1-1: new full speed USB device using mpc82xx-hcd and address 2
usb 1-1: device descriptor read/64, error -110
usb 1-1: device descriptor read/64, error -110
usb 1-1: new full speed USB device using mpc82xx-hcd and address 3
usb 1-1: device descriptor read/64, error -110
usb 1-1: device descriptor read/64, error -110
usb 1-1: new full speed USB device using mpc82xx-hcd and address 4
usb 1-1: device not accepting address 4, error -110
usb 1-1: new full speed USB device using mpc82xx-hcd and address 5
usb 1-1: device not accepting address 5, error -110
CASE 2: Pendrive is inserted on an "External hub which is conntected to USB
port of 8272ADS board".
USB Universal Host Controller Interface driver v2.2
sl811: driver sl811-hcd, 19 May 2005
Registering platform device 'mpc82xx-hcd.3'. Parent at platform
=3D> driver mpc82xx-hcd, 2005
mpc82xx-hcd mpc82xx-hcd.3: PQ2 intergrated USB controller v0.1
mpc82xx-hcd mpc82xx-hcd.3: new USB bus registered, assigned bus number 1
usb usb1: Product: PQ2 intergrated USB controller v0.1
usb usb1: Manufacturer: Linux 2.6.10_mvl401-8272ads mpc82xx-hcd
usb usb1: SerialNumber: mpc82xx-hcd.3
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
PQ2USB: debug file creation
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
.......after SANDISK pendrive inserted........
usb 1-1.3: new full speed USB device using mpc82xx-hcd and address 3
usb 1-1.3: Product: U3 Cruzer Micro
usb 1-1.3: Manufacturer: SanDisk Corporation
usb 1-1.3: can't set config #1, error -110
hub 1-1:1.0: cannot disable port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: Cannot enable port 3. Maybe the USB cable is bad?
hub 1-1:1.0: cannot disable port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: Cannot enable port 3. Maybe the USB cable is bad?
hub 1-1:1.0: cannot disable port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: Cannot enable port 3. Maybe the USB cable is bad?
hub 1-1:1.0: cannot disable port 3 (err =3D -110)
hub 1-1:1.0: cannot disable port 3 (err =3D -110)
hub 1-1:1.0: hub_port_status failed (err =3D -110)
........after unknown manufacturer's pendrive inserted...........
usb 1-1.1: new full speed USB device using mpc82xx-hcd and address 7
usb 1-1.1: Product: Mass Storage Device
usb 1-1.1: Manufacturer: Generic
usb 1-1.1: SerialNumber: 6EOG5LAF
scsi0 : SCSI emulation for USB Mass Storage devices
floating point used in kernel (task=3Dc0306050, pc=3Dc022a5f8)
Oops: Exception in kernel mode, sig: 4 [#1]
Thanks & Regards
Amarendra Reddy
--------------------------------------------------------
Laurent Pinchart-4 wrote:
>=20
> Hi Amarendra,
>=20
> On Wednesday 26 March 2008 17:11, Amarendra_Reddy wrote:
>>=20
>> Hi all,
>>=20
>> We are working on implementation of the USB host controller driver for
>> the
>> MPC8272ADS (eval board).=20
>>=20
>> The USB Host controller on MPC8272 chip is neither UHCI nor OHCI
>> compliant.=20
>>=20
>> We downloaded the project cpm2usb and the patches created by Mr.Mike
>> Rapoport from http://cpm2usb.sourceforge.net
>>=20
>> We integrated the 'm82xx-hcd' into the 2.6.10 source with few changes to
>> usb
>> data structures (usb_hcd,usb_device,usb_host_endpoint) and to struct
>> hc_driver. Also updated the function ''tx_err' present in m82xx-hcd.c.
>=20
> The cpm2usb project isn't maintained. If possible you should upgrade to a
> more=20
> recent kernel and switch to the powerpc architecture where a new USB
> driver=20
> called fhci is available.
>=20
> The MPC872ADS is supported in recent kernels so switching shouldn't be to=
o=20
> difficult.
>=20
> Best regards,
>=20
> --=20
> Laurent Pinchart
> CSE Semaphore Belgium
>=20
> Chauss=C3=A9e de Bruxelles, 732A
> B-1410 Waterloo
> Belgium
>=20
> T +32 (2) 387 42 59
> F +32 (2) 387 42 75
>=20
> =20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
--=20
View this message in context: http://www.nabble.com/Help-on-MPC82XX-USB-Hos=
t-controller-Development-using-m82xx-hcd.-tp16304553p16491756.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: cpu_clock confusion (was: printk time confusion?)
From: Ingo Molnar @ 2008-04-04 14:46 UTC (permalink / raw)
To: Johannes Berg
Cc: linuxppc-dev list, Arnd Bergmann, Linux Kernel list,
Benjamin Herrenschmidt
In-Reply-To: <1207240450.3797.22.camel@johannes.berg>
* Johannes Berg <johannes@sipsolutions.net> wrote:
> Hi,
>
> > > Not sure whether the lockdep patches or something else is causing this
> > > as I haven't checked w/o the patches yet, but I seem to be having some
> > > confusion of printk timestamps:
> >
> > Tried reverting the patches ?
>
> That didn't help, so it's not the lockdep patches causing it. I'm still
> seeing printk timestamps like this:
>
> [ 2.764009 (3/3)]
> [ 4.272241 (2/2)]
> [ 4.272322 (2/2)]
> [ 4.272375 (2/2)]
> [ 2.948002 (3/3)]
>
> As you can see, I added printk_cpu and smp_processor_id() to the
> printk timestamp output and thus it is obvious that the different
> times come from different CPUs.
the fixes are queued for v2.6.26. You can pick them up from
sched-devel/latest as well:
http://people.redhat.com/mingo/sched-devel.git/README
Ingo
^ permalink raw reply
* Re: [kvm-ppc-devel] [PATCH] Add idle wait support for 44x platforms
From: Hollis Blanchard @ 2008-04-04 14:33 UTC (permalink / raw)
To: jyoung5; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <1207288799.6971.11.camel@thinkpadL>
On Friday 04 April 2008 00:59:59 Jerone Young wrote:
> On Thu, 2008-04-03 at 21:00 -0500, Josh Boyer wrote:
> > On Thu, 03 Apr 2008 17:43:02 -0500
> >
> > Jerone Young <jyoung5@us.ibm.com> wrote:
> > > # HG changeset patch
> > > # User Jerone Young <jyoung5@us.ibm.com>
> > > # Date 1207262487 18000
> > > # Node ID 7226bef216680748a50327900572c2fbc3e762b0
> > > # Parent =A0a5b2aebbc6ebd2439c655f1c047ed7e3c1991ec1
> >
> > As a complete and unrelated side note to the actual patch, wtf is this
> > hg stuff? =A0I can't really tell what tree you're even basing this off =
of.
>
> hehe...I primary use hg as it's just much easier to deal with. Yes I do
> go through the conversion. But it is worth it. The patches I send are in
> git format.
By the way, you can use "hg email --plain" to avoid confusing the=20
unenlightened. ;) The Mercurial changeset data won't be useful here=20
anyways...
In reply to an earlier unrelated comment, there is also "hg email --diffsta=
t".
=2D-=20
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* [PATCH/RFC] via-pmu: remove mdelays from suspend/resume code
From: Johannes Berg @ 2008-04-03 15:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
I don't see a reason for either of those mdelay()s, is there any? Works
fine for me without them...
johannes
---
drivers/macintosh/via-pmu.c | 20 +++-----------------
1 file changed, 3 insertions(+), 17 deletions(-)
--- everything.orig/drivers/macintosh/via-pmu.c 2008-04-03 17:27:29.000000000 +0200
+++ everything/drivers/macintosh/via-pmu.c 2008-04-03 17:28:23.000000000 +0200
@@ -2165,8 +2165,6 @@ static void pmac_suspend_disable_irqs(vo
static int powerbook_sleep(suspend_state_t state)
{
- int error = 0;
-
/* Wait for completion of async requests */
while (!batt_req.complete)
pmu_poll();
@@ -2183,25 +2181,15 @@ static int powerbook_sleep(suspend_state
switch (pmu_kind) {
case PMU_OHARE_BASED:
- error = powerbook_sleep_3400();
- break;
+ return powerbook_sleep_3400();
case PMU_HEATHROW_BASED:
case PMU_PADDINGTON_BASED:
- error = powerbook_sleep_grackle();
- break;
+ return powerbook_sleep_grackle();
case PMU_KEYLARGO_BASED:
- error = powerbook_sleep_Core99();
- break;
+ return powerbook_sleep_Core99();
default:
return -ENOSYS;
}
-
- if (error)
- return error;
-
- mdelay(100);
-
- return 0;
}
static void pmac_suspend_enable_irqs(void)
@@ -2210,8 +2198,6 @@ static void pmac_suspend_enable_irqs(voi
adb_int_pending = 1;
via_pmu_interrupt(0, NULL);
- mdelay(10);
-
/* Call platform functions marked "on wake" */
pmac_pfunc_base_resume();
pmac_pfunc_i2c_resume();
^ permalink raw reply
* Oops MPC8343 @ 2.6.25-rc7
From: Andre Schwarz @ 2008-04-04 13:06 UTC (permalink / raw)
To: linux-ppc list
All,
I'm having trouble booting a MPC8343 into a recent 2.6.25-rc7 kernel.
Kernel config has been reduced to a minimum : no PCI, no netwoking, i2c,
spi ...
dts has been reduced to the CPU, soc and ipic nodes.
U-Boot fills out dtb correctly - as far as I can see.
Kernel crashes on various "of_" functions regarding to call trace.
There's also strange messages :
WARNING: Estimating decrementer frequency (not found)
WARNING: Estimating processor frequency (not found)
They're coming from "generic_calibrate_decr()" in kernel/time.c.
Looks like there something basically wrong with my dtb
location/processing, since the "timebase-frequency" is present and valid :
cpus {
#address-cells = <0x00000001>;
#size-cells = <0x00000000>;
PowerPC,8343@0 {
device_type = "cpu";
reg = <0x00000000>;
d-cache-line-size = <0x00000020>;
i-cache-line-size = <0x00000020>;
d-cache-size = <0x00008000>;
i-cache-size = <0x00008000>;
timebase-frequency = <0x03f940aa>;
bus-frequency = <0x0fe502a8>;
clock-frequency = <0x17d783fc>;
};
};
Any hints ?
regards,
Andre Schwarz
Matrix Vision
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
^ permalink raw reply
* [PATCH] ehea: Fix DLPAR memory add support
From: Thomas Klein @ 2008-04-04 13:04 UTC (permalink / raw)
To: Jeff Garzik
Cc: Jan-Bernd Themann, netdev, Hannes Hering, linux-kernel, linux-ppc,
Christoph Raisch, Stefan Roscher
This patch fixes two weaknesses in send/receive packet handling which may
lead to kernel panics during DLPAR memory add operations.
Signed-off-by: Thomas Klein <tklein@de.ibm.com>
---
diff -Nurp -X dontdiff linux-2.6.25-rc8/drivers/net/ehea/ehea.h patched_kernel/drivers/net/ehea/ehea.h
--- linux-2.6.25-rc8/drivers/net/ehea/ehea.h 2008-04-01 21:44:26.000000000 +0200
+++ patched_kernel/drivers/net/ehea/ehea.h 2008-04-03 15:36:36.000000000 +0200
@@ -40,7 +40,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0089"
+#define DRV_VERSION "EHEA_0090"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
@@ -371,6 +371,7 @@ struct ehea_port_res {
struct ehea_q_skb_arr rq2_skba;
struct ehea_q_skb_arr rq3_skba;
struct ehea_q_skb_arr sq_skba;
+ int sq_skba_size;
spinlock_t netif_queue;
int queue_stopped;
int swqe_refill_th;
diff -Nurp -X dontdiff linux-2.6.25-rc8/drivers/net/ehea/ehea_main.c patched_kernel/drivers/net/ehea/ehea_main.c
--- linux-2.6.25-rc8/drivers/net/ehea/ehea_main.c 2008-04-01 21:44:26.000000000 +0200
+++ patched_kernel/drivers/net/ehea/ehea_main.c 2008-04-03 15:36:36.000000000 +0200
@@ -349,7 +349,8 @@ static void ehea_refill_rq1(struct ehea_
pr->rq1_skba.os_skbs = 0;
if (unlikely(test_bit(__EHEA_STOP_XFER, &ehea_driver_flags))) {
- pr->rq1_skba.index = index;
+ if (nr_of_wqes > 0)
+ pr->rq1_skba.index = index;
pr->rq1_skba.os_skbs = fill_wqes;
return;
}
@@ -1464,7 +1465,9 @@ static int ehea_init_port_res(struct ehe
init_attr->act_nr_rwqes_rq2,
init_attr->act_nr_rwqes_rq3);
- ret = ehea_init_q_skba(&pr->sq_skba, init_attr->act_nr_send_wqes + 1);
+ pr->sq_skba_size = init_attr->act_nr_send_wqes + 1;
+
+ ret = ehea_init_q_skba(&pr->sq_skba, pr->sq_skba_size);
ret |= ehea_init_q_skba(&pr->rq1_skba, init_attr->act_nr_rwqes_rq1 + 1);
ret |= ehea_init_q_skba(&pr->rq2_skba, init_attr->act_nr_rwqes_rq2 + 1);
ret |= ehea_init_q_skba(&pr->rq3_skba, init_attr->act_nr_rwqes_rq3 + 1);
@@ -2621,6 +2624,22 @@ void ehea_purge_sq(struct ehea_qp *orig_
}
}
+void ehea_flush_sq(struct ehea_port *port)
+{
+ int i;
+
+ for (i = 0; i < port->num_def_qps + port->num_add_tx_qps; i++) {
+ struct ehea_port_res *pr = &port->port_res[i];
+ int swqe_max = pr->sq_skba_size - 2 - pr->swqe_ll_count;
+ int k = 0;
+ while (atomic_read(&pr->swqe_avail) < swqe_max) {
+ msleep(5);
+ if (++k == 20)
+ break;
+ }
+ }
+}
+
int ehea_stop_qps(struct net_device *dev)
{
struct ehea_port *port = netdev_priv(dev);
@@ -2845,6 +2864,7 @@ static void ehea_rereg_mrs(struct work_s
if (dev->flags & IFF_UP) {
down(&port->port_lock);
netif_stop_queue(dev);
+ ehea_flush_sq(port);
ret = ehea_stop_qps(dev);
if (ret) {
up(&port->port_lock);
^ permalink raw reply
* Re: [kvm-ppc-devel] [PATCH] [v2] Add idle wait support for 44x platforms
From: Jimi Xenidis @ 2008-04-04 12:36 UTC (permalink / raw)
To: Jerone Young; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <afed3e5de82ab6c0ac8d.1207292794@thinkpadL>
On Apr 4, 2008, at 3:06 AM, Jerone Young wrote:
> # HG changeset patch
> # User Jerone Young <jyoung5@us.ibm.com>
> # Date 1207292108 18000
> # Node ID afed3e5de82ab6c0ac8d6ceeb0292b6c41ece1ed
> # Parent a5b2aebbc6ebd2439c655f1c047ed7e3c1991ec1
> [v2] Add idle wait support for 44x platforms
>
> This patch adds the ability for the CPU to go into wait state while
> in cpu_idle loop. This helps virtulization solutions know when the
> guest Linux kernel is in an idle state. There are two ways to do it.
>
> 1) Command line
> idle=spin <-- CPU will spin (this is the default)
> idle=wait <-- set CPU into wait state when idle
>
> 2) The device tree will be checked for the "/hypervisor" node
> If this node is seen it will use "wait" for idle, so that
> the hypervisor can know when guest Linux kernel it is in
> an idle state.
>
> This patch, unlike the last, isolates the code to 44x platforms.
>
> Signed-off-by: Jerone Young <jyoung5@us.ibm.com>
>
> diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/
> platforms/44x/Makefile
> --- a/arch/powerpc/platforms/44x/Makefile
> +++ b/arch/powerpc/platforms/44x/Makefile
> @@ -1,4 +1,4 @@ obj-$(CONFIG_44x) := misc_44x.o
> -obj-$(CONFIG_44x) := misc_44x.o
> +obj-$(CONFIG_44x) := misc_44x.o idle.o
> obj-$(CONFIG_EBONY) += ebony.o
> obj-$(CONFIG_TAISHAN) += taishan.o
> obj-$(CONFIG_BAMBOO) += bamboo.o
> diff --git a/arch/powerpc/platforms/44x/idle.c b/arch/powerpc/
> platforms/44x/idle.c
> new file mode 100644
> --- /dev/null
> +++ b/arch/powerpc/platforms/44x/idle.c
> @@ -0,0 +1,84 @@
> +/*
> + * Copyright 2008 IBM Corp.
> + *
> + * Derived from pasemi/idle.c
> + * by Olof Johansson <olof@lixom.net>
> + *
> + * Added by: Jerone Young <jyoung5@us.ibm.com>
> + *
> + * This program is free software; you can redistribute it and/or
> modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
> 02111-1307 USA
> + *
> + */
> +
> +#include <linux/of.h>
> +#include <linux/kernel.h>
> +#include <asm/machdep.h>
> +
> +static int current_mode = 0;
Doesn't matter if the 0 is functionally redundant or pleasing to your
eye, it is the "Linux way" to leave out the " = 0", so just do it
please.
> +
> +struct sleep_mode {
> + char *name;
> + void (*entry)(void);
> +};
> +
> +static void ppc44x_idle(void)
Perhaps "ppc44x_wait" is more appropriate?
> +{
> + unsigned long msr_save;
> +
> + msr_save = mfmsr();
> + /* set wait state MSR */
> + mtmsr(msr_save|MSR_WE|MSR_EE|MSR_CE);
Did we decide to drop MSR_DE?
> + /* return to initial state */
> + mtmsr(msr_save);
It may be my paranoia but I'm pretty sure you need the isync() after
_both_ mtmsr()s
Certainly can't hurt.
> +}
> +
> +static struct sleep_mode modes[] = {
> + { .name = "spin", .entry = NULL },
> + { .name = "wait", .entry = &ppc44x_idle },
> +};
> +
> +int __init ppc44x_idle_init(void)
> +{
> + void *func = modes[current_mode].entry;
> + struct device_node *node;
> +
> + node = of_find_node_by_path("/hypervisor");
> + if (node) {
> + /* if we find /hypervisor node is in device tree,
> + set idle mode to wait */
> + func = &ppc44x_idle; /* wait */
> + of_node_put(node);
> + }
> +
> + ppc_md.power_save = func;
> + return 0;
> +}
> +
> +arch_initcall(ppc44x_idle_init);
IIRC, this would over-ride the idle_param() below, is that the
intended behavior?
> +
> +static int __init idle_param(char *p)
> +{
> + int i;
> +
> + for (i = 0; i < sizeof(modes)/ARRAY_SIZE(modes); i++) {
It is supposed to be:
for (i = 0; i < ARRAY_SIZE(modes); i++) {
What you have will actually eval to 0 and would have never checked
anything :)
> + if (!strcmp(modes[i].name, p)) {
> + current_mode = i;
> + break;
> + }
> + }
> +
> + return 0;
> +}
> +
> +early_param("idle", idle_param);
>
> ----------------------------------------------------------------------
> ---
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/
> marketplace
> _______________________________________________
> kvm-ppc-devel mailing list
> kvm-ppc-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel
^ permalink raw reply
* Re: Linuxppc-embedded Digest, Vol 44, Issue 17
From: William Feng @ 2008-04-04 12:15 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <mailman.403.1207310047.11702.linuxppc-embedded@ozlabs.org>
Hi Janhan,
Yes, it is confiemed. Thanks for your advise!
Regards
William Feng
Landscape Co, LTD.
--------------------------------------------------
From: <linuxppc-embedded-request@ozlabs.org>
Sent: Friday, April 04, 2008 7:54 PM
To: <linuxppc-embedded@ozlabs.org>
Subject: Linuxppc-embedded Digest, Vol 44, Issue 17
> Send Linuxppc-embedded mailing list submissions to
> linuxppc-embedded@ozlabs.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> or, via email, send a message with subject or body 'help' to
> linuxppc-embedded-request@ozlabs.org
>
> You can reach the person managing the list at
> linuxppc-embedded-owner@ozlabs.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Linuxppc-embedded digest..."
>
>
> Today's Topics:
>
> 1. Re: Xilinx LLTEMAC driver issues (Johann Baudy)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 4 Apr 2008 11:54:01 +0000
> From: "Johann Baudy" <johaahn@gmail.com>
> Subject: Re: Xilinx LLTEMAC driver issues
> To: MingLiu <eemingliu@hotmail.com>
> Cc: John Linn <john.linn@xilinx.com>, git <git@xilinx.com>,
> linuxppc-embedded@ozlabs.org
> Message-ID:
> <7e0dd21a0804040454i6ef73980mce1a14f7e8d3c281@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Dear Ming,
>
> I've made this test on EDK 9.2 + ll_temac 1.00.b + lltemac hw patch
> (ftp://ftp.xilinx.com/pub/applications/misc/tx_ll_if_edk10_1.zip
> (still up))+ ll_temac driver patch.
> I'm currently working on a 10.1 rebase. (ongoing...)
>
> Best regards,
> Johann
>
>
> On Fri, Apr 4, 2008 at 10:11 AM, MingLiu <eemingliu@hotmail.com> wrote:
>>
>> Dear Johann,
>> Thanks for the prompt reply.
>>
>> Actually I am using EDK 10.1 evaluation version. According to Xilinx's
>> answer, they said the problem will be fixed in 10.1 already.
>> Unfortunately I
>> still met it in my design.
>>
>> Do you happen to still have the file tx_ii_if.zip? I cannot download it
>> from Xilinx any more. Thank you so much if you can give me a copy.
>>
>> BR
>> Ming
>>
>>
>> > Date: Fri, 4 Apr 2008 09:53:07 +0000
>> > From: johaahn@gmail.com
>> > To: eemingliu@hotmail.com
>>
>> > Subject: Re: Xilinx LLTEMAC driver issues
>> > CC: mh@omnisys.se; linuxppc-embedded@ozlabs.org; john.linn@xilinx.com;
>> git@xilinx.com
>>
>>
>> >
>> > Hi Ming,
>> >
>> > I've already used netperf (without NFS) successfully.
>> > Are you using 1.00.b and 9.2, if yes look at AR #29708.
>> >
>> > Best regards,
>> > Johann
>> >
>> > On Fri, Apr 4, 2008 at 9:36 AM, MingLiu <eemingliu@hotmail.com> wrote:
>> > >
>> > > Dear Johann,
>> > > Previously I said this patch helps for the checksum error problem.
>> > > But
>> now
>> > > I found some new issues. Yes. at least with this patch, something is
>> better
>> > > and at least we can use the hardware checksum offloading to do
>> something,
>> > > for example I can mount the NFS root file system. However when I try
>> > > to
>> > > measure the ethernet bandwidth with netperf, something goes wrong and
>> the
>> > > NFS mount will be broken. I guess this is because of the large bulk
>> > > data
>> > > transfer and maybe thus it triggers the checksum problem to happen.
>> > >
>> > > Do you have the same situation? Or someone else has the same problem?
>> > > I
>> > > will appreciate if you can share your experience. Thanks a lot.
>> > >
>> > > BR
>> > > Ming
>> > >
>> > >
>> > >
>> > > ________________________________
>> > > Date: Wed, 2 Apr 2008 07:20:43 +0000
>> > > From: johaahn@gmail.com
>> > > To: mh@omnisys.se
>> > >
>> > > Subject: Re: Xilinx LLTEMAC driver issues
>> > > CC: linuxppc-embedded@ozlabs.org; John.Linn@xilinx.com;
>> > > git@xilinx.com
>> > >
>> > >
>> > >
>> > > I've solved this checksum offloading issue with this below patch.
>> > > It may help, if you need performance. It certainly needs review but
>> > > it
>> works
>> > > on my side.
>> > >
>> > > --- xilinxgit/drivers/net/xilinx
>> > > _lltemac/xlltemac_main.c.orig 2008-03-21 09:11:43.000000000 +0100
>> > > +++ xilinxgit/drivers/net/xilinx_lltemac/xlltemac_main.c 2008-03-21
>> > > 09:24:23.000000000 +0100
>> > > @@ -133,7 +133,7 @@
>> > > (XLlDma_mBdRead((BdPtr), XLLDMA_BD_STSCTRL_USR0_OFFSET)) &
>> > > 0xFFFFFFFE )
>> > >
>> > > #define BdCsumSetup(BdPtr, Start, Insert) \
>> > > - XLlDma_mBdWrite((BdPtr), XLLDMA_BD_USR1_OFFSET, (Start) << 16 |
>> > > (Insert))
>> > > + XLlDma_mBdWrite((BdPtr), XLLDMA_BD_USR1_OFFSET, ((Start) << 16) |
>> > > (Insert))
>> > >
>> > > /* Used for debugging */
>> > > #define BdCsumInsert(BdPtr) \
>> > > @@ -1540,7 +1541,7 @@ static int xenet_DmaSend_internal(struct
>> > > /*
>> > > * if tx checksum offloading is enabled, when the ethernet stack
>> > > * wants us to perform the checksum in hardware,
>> > > - * skb->ip_summed is CHECKSUM_COMPLETE. Otherwise skb->ip_summed is
>> > > + * skb->ip_summed is CHECKSUM_PARTIAL. Otherwise skb->ip_summed is
>> > > * CHECKSUM_NONE, meaning the checksum is already done, or
>> > > * CHECKSUM_UNNECESSARY, meaning checksumming is turned off (e.g.
>> > > * loopback interface)
>> > > @@ -1565,9 +1566,11 @@ static int xenet_DmaSend_internal(struct
>> > > * skb_transport_header(skb) points to the beginning of the ip header
>> > > *
>> > > */
>> > > - if (skb->ip_summed == CHECKSUM_COMPLETE) {
>> > > + if (skb->ip_summed == CHECKSUM_PARTIAL) {
>> > > +
>> > > + unsigned int csum_start_off = skb_transport_offset(skb);
>> > > + unsigned int csum_index_off = csum_start_off + skb->csum_offset;
>> > >
>> > > - unsigned char *raw = skb_transport_header(skb);
>> > > #if 0
>> > > {
>> > > unsigned int csum = _xenet_tx_csum(skb);
>> > > @@ -1578,9 +1581,8 @@ static int xenet_DmaSend_internal(struct
>> > > }
>> > > #else
>> > > BdCsumEnable(bd_ptr);
>> > > - BdCsumSetup(bd_ptr, raw - skb->data,
>> > > - (raw - skb->data) + skb->csum);
>> > > -
>> > > + BdCsumSetup(bd_ptr, csum_start_off,
>> > > + csum_index_off);
>> > > #endif
>> > > lp->tx_hw_csums++;
>> > > }
>> > > @@ -3277,7 +3279,7 @@ static int __devinit xtenet_of_probe(str
>> > > struct resource *r_irq = &r_irq_struct; /* Interrupt resources */
>> > > struct resource *r_mem = &r_mem_struct; /* IO mem resources */
>> > > struct xlltemac_platform_data *pdata = &pdata_struct;
>> > > - void *mac_address;
>> > > + const void *mac_address;
>> > > int rc = 0;
>> > > const phandle *llink_connected_handle;
>> > > struct device_node *llink_connected_node;
>> > >
>> > >
>> > > On Mon, Mar 31, 2008 at 11:10 AM, Magnus Hjorth <mh@omnisys.se>
>> > > wrote:
>> > >
>> > > Deactivating checksum offloading helped a lot! I still have some
>> > > packet
>> loss
>> > > and not the best performance (TFTP transfer about 100 kbyte/s) but at
>> least
>> > > it works.
>> > >
>> > > Thanks!
>> > >
>> > > //Magnus
>> > >
>> > >
>> > >
>> > >
>> > > > -----Original Message-----
>> > > > From: rza1 [mailto:rza1@so-logic.net]
>> > > > Sent: den 31 mars 2008 11:14
>> > > > To: Magnus Hjorth
>> > > > Cc: John Linn; git; linuxppc-embedded@ozlabs.org
>> > > > Subject: Re: Xilinx LLTEMAC driver issues
>> > > >
>> > > > Hi Magnus,
>> > > >
>> > > > 1.
>> > > > I am using nearly the same versions then you and got the same
>> > > > problems
>> > > > too ;-).
>> > > > I think there are some problems with the checksum offloading.
>> > > > Try to sniff the some packages (e.g. wireshark)...
>> > > > For me ICMP (ping) worked but udp and tcp not (because off a wrong
>> > > > checksum in the transport layer).
>> > > > A quick solution is to just deactivate checksum offloading.
>> > > >
>> > > > 2.
>> > > > I remember some problems with Virtex-4 presamples too.
>> > > > There where problems with the hard-temac wrapper. You had to use
>> 1.00.a
>> > > > and not b version.
>> > > > But I don't have these problems with the EDK 9.2sp2/ISE9.2sp3
>> > > > anymore.
>> > > >
>> > > > all the best,
>> > > > Robert
>> > > >
>> > > > Magnus Hjorth wrote:
>> > > > > Hi John,
>> > > > >
>> > > > > Thanks for the very fast reply! Right now I'm not at work so I
>> > > > > don't
>> > > > > have the board or EDK here to test anything.
>> > > > >
>> > > > > I'm using checksum offload, but I don't know if DRE is enabled or
>> not. I
>> > > > > can't recall seeing any setting to enable/disable DRE..
>> > > > >
>> > > > > A few things that crossed my mind:
>> > > > >
>> > > > > Last year I did a design with EDK 8.2, back then there was an
>> > > > > issue
>> with
>> > > > > the ML403 boards having an old revision of the FPGA which wasn't
>> > > > > compatible with some versions of the IP core. There are no such
>> version
>> > > > > issues with the xps_ll_temac?
>> > > > >
>> > > > > I don't think that I had phy-addr set in the DTS file. Will test
>> that on
>> > > > > Monday.
>> > > > >
>> > > > > Best regards,
>> > > > > Magnus
>> > > > >
>> > > > >
>> > > > > On Sat, 2008-03-29 at 07:58 -0600, John Linn wrote:
>> > > > >
>> > > > >> Hi Magnus,
>> > > > >>
>> > > > >> Sorry to hear you're having problems with it.
>> > > > >>
>> > > > >> I am doing testing on an ML405 which is the same board but with
>> > > > >> a
>> > > bigger
>> > > > FPGA, but with ppc arch and I don't see this issue. I have done
>> limited
>> > > testing
>> > > > with powerpc arch and the LL TEMAC, but I didn't see this issue
>> > > > there
>> > > either.
>> > > > Powerpc arch is definitely less mature in my experience than the
>> > > > ppc
>> arch.
>> > > I'll
>> > > > do a quick test with my powerpc arch and make sure again I'm not
>> seeing
>> > > it.
>> > > > >>
>> > > > >> My kernel is from the Xilinx Git tree, but there have been a
>> > > > >> number
>> of
>> > > > changes we have pushed out so I don't know how long ago you pulled
>> from
>> > > the Git
>> > > > tree.
>> > > > >>
>> > > > >> My EDK project is 10.1 so it's a little newer. I am using LL
>> > > > >> TEMAC
>> > > 1.01a so
>> > > > it's a little newer. I reviewed the change log for the LL TEMAC and
>> don't
>> > > see
>> > > > any big problems that were fixed in the newer versions, more new
>> features.
>> > > I'll
>> > > > check with some others here to see if I missed something there.
>> > > > >>
>> > > > >> I am using DMA also, but no DRE or checksum offload. You didn't
>> > > > >> say
>> > > anything
>> > > > about those. I'm going to insert my mhs file that describes my
>> > > > system
>> to
>> > > let you
>> > > > compare your system configuration. It's not clear to me yet if you
>> have a
>> > > h/w or
>> > > > s/w problem.
>> > > > >>
>> > > > >> I'll also insert some of my device tree with the LL TEMAC so you
>> can
>> > > compare
>> > > > (ignore 16550 stuff as we are still working on that).
>> > > > >>
>> > > > >> Since you can't ping reliably I would probably focus on that
>> > > > >> since
>> it's
>> > > > simpler than the other issues you're seeing.
>> > > > >>
>> > > > >> Thanks,
>> > > > >> John
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >> #
>> > > >
>> > >
>> ##############################################################################
>> > > > >> # Created by Base System Builder Wizard for Xilinx EDK 10.1.1
>> > > > >> Build
>> > > > EDK_K_SP1.1
>> > > > >> # Thu Feb 14 14:11:12 2008
>> > > > >> # Target Board: Xilinx Virtex 4 ML405 Evaluation Platform Rev 1
>> > > > >> # Family: virtex4
>> > > > >> # Device: xc4vfx20
>> > > > >> # Package: ff672
>> > > > >> # Speed Grade: -10
>> > > > >> # Processor: ppc405_0
>> > > > >> # Processor clock frequency: 300.00 MHz
>> > > > >> # Bus clock frequency: 100.00 MHz
>> > > > >> # On Chip Memory : 8 KB
>> > > > >> # Total Off Chip Memory : 128 MB
>> > > > >> # - DDR_SDRAM = 128 MB
>> > > > >> #
>> > > >
>> > >
>> ##############################################################################
>> > > > >> PARAMETER VERSION = 2.1.0
>> > > > >>
>> > > > >>
>> > > > >> PORT fpga_0_RS232_Uart_sin_pin = fpga_0_RS232_Uart_sin, DIR = I
>> > > > >> PORT fpga_0_RS232_Uart_sout_pin = fpga_0_RS232_Uart_sout, DIR =
>> > > > >> O
>> > > > >> PORT fpga_0_LEDs_4Bit_GPIO_IO_pin = fpga_0_LEDs_4Bit_GPIO_IO,
>> > > > >> DIR =
>> > > IO, VEC
>> > > > = [0:3]
>> > > > >> PORT fpga_0_IIC_EEPROM_Scl_pin = fpga_0_IIC_EEPROM_Scl, DIR = IO
>> > > > >> PORT fpga_0_IIC_EEPROM_Sda_pin = fpga_0_IIC_EEPROM_Sda, DIR = IO
>> > > > >> PORT fpga_0_SysACE_CompactFlash_SysACE_CLK_pin =
>> > > > fpga_0_SysACE_CompactFlash_SysACE_CLK, DIR = I
>> > > > >> PORT fpga_0_SysACE_CompactFlash_SysACE_MPA_pin =
>> > > > fpga_0_SysACE_CompactFlash_SysACE_MPA, DIR = O, VEC = [6:1]
>> > > > >> PORT fpga_0_SysACE_CompactFlash_SysACE_MPD_pin =
>> > > > fpga_0_SysACE_CompactFlash_SysACE_MPD, DIR = IO, VEC = [15:0]
>> > > > >> PORT fpga_0_SysACE_CompactFlash_SysACE_CEN_pin =
>> > > > fpga_0_SysACE_CompactFlash_SysACE_CEN, DIR = O
>> > > > >> PORT fpga_0_SysACE_CompactFlash_SysACE_OEN_pin =
>> > > > fpga_0_SysACE_CompactFlash_SysACE_OEN, DIR = O
>> > > > >> PORT fpga_0_SysACE_CompactFlash_SysACE_WEN_pin =
>> > > > fpga_0_SysACE_CompactFlash_SysACE_WEN, DIR = O
>> > > > >> PORT fpga_0_SysACE_CompactFlash_SysACE_MPIRQ_pin =
>> > > > fpga_0_SysACE_CompactFlash_SysACE_MPIRQ, DIR = I
>> > > > >> PORT fpga_0_DDR_SDRAM_DDR_Clk_pin = fpga_0_DDR_SDRAM_DDR_Clk,
>> > > > >> DIR =
>> O
>> > > > >> PORT fpga_0_DDR_SDRAM_DDR_Clk_n_pin =
>> > > > >> fpga_0_DDR_SDRAM_DDR_Clk_n,
>> DIR
>> > > = O
>> > > > >> PORT fpga_0_DDR_SDRAM_DDR_Addr_pin = fpga_0_DDR_SDRAM_DDR_Addr,
>> > > > >> DIR
>> =
>> > > O, VEC
>> > > > = [12:0]
>> > > > >> PORT fpga_0_DDR_SDRAM_DDR_BankAddr_pin =
>> > > fpga_0_DDR_SDRAM_DDR_BankAddr, DIR
>> > > > = O, VEC = [1:0]
>> > > > >> PORT fpga_0_DDR_SDRAM_DDR_CAS_n_pin =
>> > > > >> fpga_0_DDR_SDRAM_DDR_CAS_n,
>> DIR
>> > > = O
>> > > > >> PORT fpga_0_DDR_SDRAM_DDR_CE_pin = fpga_0_DDR_SDRAM_DDR_CE, DIR
>> > > > >> = O
>> > > > >> PORT fpga_0_DDR_SDRAM_DDR_CS_n_pin = fpga_0_DDR_SDRAM_DDR_CS_n,
>> > > > >> DIR
>> =
>> > > O
>> > > > >> PORT fpga_0_DDR_SDRAM_DDR_RAS_n_pin =
>> > > > >> fpga_0_DDR_SDRAM_DDR_RAS_n,
>> DIR
>> > > = O
>> > > > >> PORT fpga_0_DDR_SDRAM_DDR_WE_n_pin = fpga_0_DDR_SDRAM_DDR_WE_n,
>> > > > >> DIR
>> =
>> > > O
>> > > > >> PORT fpga_0_DDR_SDRAM_DDR_DM_pin = fpga_0_DDR_SDRAM_DDR_DM, DIR
>> > > > >> =
>> O,
>> > > VEC =
>> > > > [3:0]
>> > > > >> PORT fpga_0_DDR_SDRAM_DDR_DQS = fpga_0_DDR_SDRAM_DDR_DQS, DIR =
>> > > > >> IO,
>> > > VEC =
>> > > > [3:0]
>> > > > >> PORT fpga_0_DDR_SDRAM_DDR_DQ = fpga_0_DDR_SDRAM_DDR_DQ, DIR =
>> > > > >> IO,
>> VEC
>> > > =
>> > > > [31:0]
>> > > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_TXD_0_pin =
>> > > > fpga_0_TriMode_MAC_GMII_GMII_TXD_0, DIR = O, VEC = [7:0]
>> > > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_TX_EN_0_pin =
>> > > > fpga_0_TriMode_MAC_GMII_GMII_TX_EN_0, DIR = O
>> > > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_TX_ER_0_pin =
>> > > > fpga_0_TriMode_MAC_GMII_GMII_TX_ER_0, DIR = O
>> > > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_TX_CLK_0_pin =
>> > > > fpga_0_TriMode_MAC_GMII_GMII_TX_CLK_0, DIR = O
>> > > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_RXD_0_pin =
>> > > > fpga_0_TriMode_MAC_GMII_GMII_RXD_0, DIR = I, VEC = [7:0]
>> > > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_RX_DV_0_pin =
>> > > > fpga_0_TriMode_MAC_GMII_GMII_RX_DV_0, DIR = I
>> > > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_RX_ER_0_pin =
>> > > > fpga_0_TriMode_MAC_GMII_GMII_RX_ER_0, DIR = I
>> > > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_RX_CLK_0_pin =
>> > > > fpga_0_TriMode_MAC_GMII_GMII_RX_CLK_0, DIR = I
>> > > > >> PORT fpga_0_TriMode_MAC_GMII_MII_TX_CLK_0_pin =
>> > > > fpga_0_TriMode_MAC_GMII_MII_TX_CLK_0, DIR = I
>> > > > >> PORT fpga_0_TriMode_MAC_GMII_MDIO_0_pin =
>> > > fpga_0_TriMode_MAC_GMII_MDIO_0,
>> > > > DIR = IO
>> > > > >> PORT fpga_0_TriMode_MAC_GMII_MDC_0_pin =
>> > > fpga_0_TriMode_MAC_GMII_MDC_0, DIR
>> > > > = O
>> > > > >> PORT fpga_0_TriMode_MAC_GMII_TemacPhy_RST_n_pin =
>> > > > fpga_0_TriMode_MAC_GMII_TemacPhy_RST_n, DIR = O
>> > > > >> PORT sys_clk_pin = dcm_clk_s, DIR = I, SIGIS = CLK, CLK_FREQ =
>> > > 100000000
>> > > > >> PORT sys_rst_pin = sys_rst_s, DIR = I, RST_POLARITY = 0, SIGIS =
>> RST
>> > > > >>
>> > > > >>
>> > > > >> BEGIN ppc405_virtex4
>> > > > >> PARAMETER INSTANCE = ppc405_0
>> > > > >> PARAMETER HW_VER = 2.01.a
>> > > > >> PARAMETER C_FASTEST_PLB_CLOCK = DPLB1
>> > > > >> PARAMETER C_IDCR_BASEADDR = 0b0100000000
>> > > > >> PARAMETER C_IDCR_HIGHADDR = 0b0111111111
>> > > > >> BUS_INTERFACE JTAGPPC = jtagppc_0_0
>> > > > >> BUS_INTERFACE IPLB0 = plb
>> > > > >> BUS_INTERFACE DPLB0 = plb
>> > > > >> BUS_INTERFACE IPLB1 = ppc405_0_iplb1
>> > > > >> BUS_INTERFACE DPLB1 = ppc405_0_dplb1
>> > > > >> BUS_INTERFACE RESETPPC = ppc_reset_bus
>> > > > >> PORT CPMC405CLOCK = proc_clk_s
>> > > > >> PORT EICC405EXTINPUTIRQ = EICC405EXTINPUTIRQ
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN jtagppc_cntlr
>> > > > >> PARAMETER INSTANCE = jtagppc_0
>> > > > >> PARAMETER HW_VER = 2.01.a
>> > > > >> BUS_INTERFACE JTAGPPC0 = jtagppc_0_0
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN plb_v46
>> > > > >> PARAMETER INSTANCE = plb
>> > > > >> PARAMETER C_DCR_INTFCE = 0
>> > > > >> PARAMETER C_NUM_CLK_PLB2OPB_REARB = 100
>> > > > >> PARAMETER HW_VER = 1.02.a
>> > > > >> PORT PLB_Clk = sys_clk_s
>> > > > >> PORT SYS_Rst = sys_bus_reset
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN xps_bram_if_cntlr
>> > > > >> PARAMETER INSTANCE = xps_bram_if_cntlr_1
>> > > > >> PARAMETER HW_VER = 1.00.a
>> > > > >> PARAMETER C_SPLB_NATIVE_DWIDTH = 64
>> > > > >> PARAMETER C_BASEADDR = 0xffffe000
>> > > > >> PARAMETER C_HIGHADDR = 0xffffffff
>> > > > >> BUS_INTERFACE SPLB = plb
>> > > > >> BUS_INTERFACE PORTA = xps_bram_if_cntlr_1_port
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN bram_block
>> > > > >> PARAMETER INSTANCE = plb_bram_if_cntlr_1_bram
>> > > > >> PARAMETER HW_VER = 1.00.a
>> > > > >> BUS_INTERFACE PORTA = xps_bram_if_cntlr_1_port
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN xps_uart16550
>> > > > >> PARAMETER INSTANCE = RS232_Uart
>> > > > >> PARAMETER HW_VER = 2.00.a
>> > > > >> PARAMETER C_IS_A_16550 = 1
>> > > > >> PARAMETER C_BASEADDR = 0x83e00000
>> > > > >> PARAMETER C_HIGHADDR = 0x83e0ffff
>> > > > >> BUS_INTERFACE SPLB = plb
>> > > > >> PORT sin = fpga_0_RS232_Uart_sin
>> > > > >> PORT sout = fpga_0_RS232_Uart_sout
>> > > > >> PORT IP2INTC_Irpt = RS232_Uart_IP2INTC_Irpt
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN xps_gpio
>> > > > >> PARAMETER INSTANCE = LEDs_4Bit
>> > > > >> PARAMETER HW_VER = 1.00.a
>> > > > >> PARAMETER C_INTERRUPT_PRESENT = 1
>> > > > >> PARAMETER C_GPIO_WIDTH = 4
>> > > > >> PARAMETER C_IS_DUAL = 0
>> > > > >> PARAMETER C_IS_BIDIR = 1
>> > > > >> PARAMETER C_ALL_INPUTS = 0
>> > > > >> PARAMETER C_BASEADDR = 0x81400000
>> > > > >> PARAMETER C_HIGHADDR = 0x8140ffff
>> > > > >> BUS_INTERFACE SPLB = plb
>> > > > >> PORT GPIO_IO = fpga_0_LEDs_4Bit_GPIO_IO
>> > > > >> PORT IP2INTC_Irpt = LEDs_4Bit_IP2INTC_Irpt
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN xps_iic
>> > > > >> PARAMETER INSTANCE = IIC_EEPROM
>> > > > >> PARAMETER HW_VER = 2.00.a
>> > > > >> PARAMETER C_CLK_FREQ = 100000000
>> > > > >> PARAMETER C_IIC_FREQ = 100000
>> > > > >> PARAMETER C_TEN_BIT_ADR = 0
>> > > > >> PARAMETER C_BASEADDR = 0x81600000
>> > > > >> PARAMETER C_HIGHADDR = 0x8160ffff
>> > > > >> BUS_INTERFACE SPLB = plb
>> > > > >> PORT Scl = fpga_0_IIC_EEPROM_Scl
>> > > > >> PORT Sda = fpga_0_IIC_EEPROM_Sda
>> > > > >> PORT IIC2INTC_Irpt = IIC_EEPROM_IIC2INTC_Irpt
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN xps_sysace
>> > > > >> PARAMETER INSTANCE = SysACE_CompactFlash
>> > > > >> PARAMETER HW_VER = 1.00.a
>> > > > >> PARAMETER C_MEM_WIDTH = 16
>> > > > >> PARAMETER C_BASEADDR = 0x83600000
>> > > > >> PARAMETER C_HIGHADDR = 0x8360ffff
>> > > > >> BUS_INTERFACE SPLB = plb
>> > > > >> PORT SysACE_CLK = fpga_0_SysACE_CompactFlash_SysACE_CLK
>> > > > >> PORT SysACE_MPA = fpga_0_SysACE_CompactFlash_SysACE_MPA_split
>> > > > >> PORT SysACE_MPD = fpga_0_SysACE_CompactFlash_SysACE_MPD
>> > > > >> PORT SysACE_CEN = fpga_0_SysACE_CompactFlash_SysACE_CEN
>> > > > >> PORT SysACE_OEN = fpga_0_SysACE_CompactFlash_SysACE_OEN
>> > > > >> PORT SysACE_WEN = fpga_0_SysACE_CompactFlash_SysACE_WEN
>> > > > >> PORT SysACE_MPIRQ = fpga_0_SysACE_CompactFlash_SysACE_MPIRQ
>> > > > >> PORT SysACE_IRQ = SysACE_CompactFlash_SysACE_IRQ
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN mpmc
>> > > > >> PARAMETER INSTANCE = DDR_SDRAM
>> > > > >> PARAMETER HW_VER = 4.00.a
>> > > > >> PARAMETER C_NUM_PORTS = 3
>> > > > >> PARAMETER C_MEM_PARTNO = HYB25D512160BE-5
>> > > > >> PARAMETER C_MEM_DATA_WIDTH = 32
>> > > > >> PARAMETER C_MEM_DQS_WIDTH = 4
>> > > > >> PARAMETER C_MEM_DM_WIDTH = 4
>> > > > >> PARAMETER C_MEM_TYPE = DDR
>> > > > >> PARAMETER C_NUM_IDELAYCTRL = 2
>> > > > >> PARAMETER C_IDELAYCTRL_LOC = IDELAYCTRL_X0Y3-IDELAYCTRL_X0Y2
>> > > > >> PARAMETER C_PIM0_BASETYPE = 2
>> > > > >> PARAMETER C_PIM1_BASETYPE = 2
>> > > > >> PARAMETER C_PIM2_BASETYPE = 3
>> > > > >> PARAMETER C_MPMC_CLK0_PERIOD_PS = 10000
>> > > > >> PARAMETER C_SDMA2_PI2LL_CLK_RATIO = 1
>> > > > >> PARAMETER C_MPMC_BASEADDR = 0x00000000
>> > > > >> PARAMETER C_MPMC_HIGHADDR = 0x07ffffff
>> > > > >> PARAMETER C_SDMA_CTRL_BASEADDR = 0x84600000
>> > > > >> PARAMETER C_SDMA_CTRL_HIGHADDR = 0x8460ffff
>> > > > >> BUS_INTERFACE SPLB0 = ppc405_0_iplb1
>> > > > >> BUS_INTERFACE SPLB1 = ppc405_0_dplb1
>> > > > >> BUS_INTERFACE SDMA_LL2 = TriMode_MAC_GMII_LLINK0
>> > > > >> BUS_INTERFACE SDMA_CTRL2 = plb
>> > > > >> PORT DDR_Addr = fpga_0_DDR_SDRAM_DDR_Addr
>> > > > >> PORT DDR_BankAddr = fpga_0_DDR_SDRAM_DDR_BankAddr
>> > > > >> PORT DDR_CAS_n = fpga_0_DDR_SDRAM_DDR_CAS_n
>> > > > >> PORT DDR_CE = fpga_0_DDR_SDRAM_DDR_CE
>> > > > >> PORT DDR_CS_n = fpga_0_DDR_SDRAM_DDR_CS_n
>> > > > >> PORT DDR_RAS_n = fpga_0_DDR_SDRAM_DDR_RAS_n
>> > > > >> PORT DDR_WE_n = fpga_0_DDR_SDRAM_DDR_WE_n
>> > > > >> PORT DDR_DM = fpga_0_DDR_SDRAM_DDR_DM
>> > > > >> PORT DDR_DQS = fpga_0_DDR_SDRAM_DDR_DQS
>> > > > >> PORT DDR_DQ = fpga_0_DDR_SDRAM_DDR_DQ
>> > > > >> PORT DDR_Clk = fpga_0_DDR_SDRAM_DDR_Clk
>> > > > >> PORT DDR_Clk_n = fpga_0_DDR_SDRAM_DDR_Clk_n
>> > > > >> PORT MPMC_Clk0 = sys_clk_s
>> > > > >> PORT MPMC_Clk90 = DDR_SDRAM_mpmc_clk_90_s
>> > > > >> PORT SDMA2_Clk = sys_clk_s
>> > > > >> PORT MPMC_Clk_200MHz = clk_200mhz_s
>> > > > >> PORT MPMC_Rst = sys_periph_reset
>> > > > >> PORT SDMA2_Rx_IntOut = DDR_SDRAM_SDMA2_Rx_IntOut
>> > > > >> PORT SDMA2_Tx_IntOut = DDR_SDRAM_SDMA2_Tx_IntOut
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN xps_ll_temac
>> > > > >> PARAMETER INSTANCE = TriMode_MAC_GMII
>> > > > >> PARAMETER HW_VER = 1.01.a
>> > > > >> PARAMETER C_SPLB_CLK_PERIOD_PS = 10000
>> > > > >> PARAMETER C_PHY_TYPE = 1
>> > > > >> PARAMETER C_NUM_IDELAYCTRL = 4
>> > > > >> PARAMETER C_IDELAYCTRL_LOC = IDELAYCTRL_X1Y1-IDELAYCTRL_X1Y3-
>> > > > IDELAYCTRL_X2Y2-IDELAYCTRL_X2Y3
>> > > > >> PARAMETER C_TEMAC_TYPE = 1
>> > > > >> PARAMETER C_BUS2CORE_CLK_RATIO = 1
>> > > > >> PARAMETER C_BASEADDR = 0x81c00000
>> > > > >> PARAMETER C_HIGHADDR = 0x81c0ffff
>> > > > >> BUS_INTERFACE SPLB = plb
>> > > > >> BUS_INTERFACE LLINK0 = TriMode_MAC_GMII_LLINK0
>> > > > >> PORT GMII_TXD_0 = fpga_0_TriMode_MAC_GMII_GMII_TXD_0
>> > > > >> PORT GMII_TX_EN_0 = fpga_0_TriMode_MAC_GMII_GMII_TX_EN_0
>> > > > >> PORT GMII_TX_ER_0 = fpga_0_TriMode_MAC_GMII_GMII_TX_ER_0
>> > > > >> PORT GMII_TX_CLK_0 = fpga_0_TriMode_MAC_GMII_GMII_TX_CLK_0
>> > > > >> PORT GMII_RXD_0 = fpga_0_TriMode_MAC_GMII_GMII_RXD_0
>> > > > >> PORT GMII_RX_DV_0 = fpga_0_TriMode_MAC_GMII_GMII_RX_DV_0
>> > > > >> PORT GMII_RX_ER_0 = fpga_0_TriMode_MAC_GMII_GMII_RX_ER_0
>> > > > >> PORT GMII_RX_CLK_0 = fpga_0_TriMode_MAC_GMII_GMII_RX_CLK_0
>> > > > >> PORT MII_TX_CLK_0 = fpga_0_TriMode_MAC_GMII_MII_TX_CLK_0
>> > > > >> PORT MDIO_0 = fpga_0_TriMode_MAC_GMII_MDIO_0
>> > > > >> PORT MDC_0 = fpga_0_TriMode_MAC_GMII_MDC_0
>> > > > >> PORT TemacPhy_RST_n = fpga_0_TriMode_MAC_GMII_TemacPhy_RST_n
>> > > > >> PORT GTX_CLK_0 = temac_clk_s
>> > > > >> PORT REFCLK = clk_200mhz_s
>> > > > >> PORT LlinkTemac0_CLK = sys_clk_s
>> > > > >> PORT TemacIntc0_Irpt = TriMode_MAC_GMII_TemacIntc0_Irpt
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN util_bus_split
>> > > > >> PARAMETER INSTANCE = SysACE_CompactFlash_util_bus_split_0
>> > > > >> PARAMETER HW_VER = 1.00.a
>> > > > >> PARAMETER C_SIZE_IN = 7
>> > > > >> PARAMETER C_LEFT_POS = 0
>> > > > >> PARAMETER C_SPLIT = 6
>> > > > >> PORT Sig = fpga_0_SysACE_CompactFlash_SysACE_MPA_split
>> > > > >> PORT Out1 = fpga_0_SysACE_CompactFlash_SysACE_MPA
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN plb_v46
>> > > > >> PARAMETER INSTANCE = ppc405_0_iplb1
>> > > > >> PARAMETER HW_VER = 1.02.a
>> > > > >> PORT PLB_Clk = sys_clk_s
>> > > > >> PORT SYS_Rst = sys_bus_reset
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN plb_v46
>> > > > >> PARAMETER INSTANCE = ppc405_0_dplb1
>> > > > >> PARAMETER HW_VER = 1.02.a
>> > > > >> PORT PLB_Clk = sys_clk_s
>> > > > >> PORT SYS_Rst = sys_bus_reset
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN clock_generator
>> > > > >> PARAMETER INSTANCE = clock_generator_0
>> > > > >> PARAMETER HW_VER = 2.00.a
>> > > > >> PARAMETER C_EXT_RESET_HIGH = 1
>> > > > >> PARAMETER C_CLKIN_FREQ = 100000000
>> > > > >> PARAMETER C_CLKOUT0_FREQ = 100000000
>> > > > >> PARAMETER C_CLKOUT0_BUF = TRUE
>> > > > >> PARAMETER C_CLKOUT0_PHASE = 0
>> > > > >> PARAMETER C_CLKOUT0_GROUP = DCM0
>> > > > >> PARAMETER C_CLKOUT1_FREQ = 100000000
>> > > > >> PARAMETER C_CLKOUT1_BUF = TRUE
>> > > > >> PARAMETER C_CLKOUT1_PHASE = 90
>> > > > >> PARAMETER C_CLKOUT1_GROUP = DCM0
>> > > > >> PARAMETER C_CLKOUT2_FREQ = 300000000
>> > > > >> PARAMETER C_CLKOUT2_BUF = TRUE
>> > > > >> PARAMETER C_CLKOUT2_PHASE = 0
>> > > > >> PARAMETER C_CLKOUT2_GROUP = DCM0
>> > > > >> PARAMETER C_CLKOUT3_FREQ = 200000000
>> > > > >> PARAMETER C_CLKOUT3_BUF = TRUE
>> > > > >> PARAMETER C_CLKOUT3_PHASE = 0
>> > > > >> PARAMETER C_CLKOUT3_GROUP = NONE
>> > > > >> PARAMETER C_CLKOUT4_FREQ = 125000000
>> > > > >> PARAMETER C_CLKOUT4_BUF = TRUE
>> > > > >> PARAMETER C_CLKOUT4_PHASE = 0
>> > > > >> PARAMETER C_CLKOUT4_GROUP = NONE
>> > > > >> PORT CLKOUT0 = sys_clk_s
>> > > > >> PORT CLKOUT1 = DDR_SDRAM_mpmc_clk_90_s
>> > > > >> PORT CLKOUT2 = proc_clk_s
>> > > > >> PORT CLKOUT3 = clk_200mhz_s
>> > > > >> PORT CLKOUT4 = temac_clk_s
>> > > > >> PORT CLKIN = dcm_clk_s
>> > > > >> PORT LOCKED = Dcm_all_locked
>> > > > >> PORT RST = net_gnd
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN proc_sys_reset
>> > > > >> PARAMETER INSTANCE = proc_sys_reset_0
>> > > > >> PARAMETER HW_VER = 2.00.a
>> > > > >> PARAMETER C_EXT_RESET_HIGH = 0
>> > > > >> BUS_INTERFACE RESETPPC0 = ppc_reset_bus
>> > > > >> PORT Slowest_sync_clk = sys_clk_s
>> > > > >> PORT Dcm_locked = Dcm_all_locked
>> > > > >> PORT Ext_Reset_In = sys_rst_s
>> > > > >> PORT Bus_Struct_Reset = sys_bus_reset
>> > > > >> PORT Peripheral_Reset = sys_periph_reset
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN xps_intc
>> > > > >> PARAMETER INSTANCE = xps_intc_0
>> > > > >> PARAMETER HW_VER = 1.00.a
>> > > > >> PARAMETER C_BASEADDR = 0x81800000
>> > > > >> PARAMETER C_HIGHADDR = 0x8180ffff
>> > > > >> BUS_INTERFACE SPLB = plb
>> > > > >> PORT Irq = EICC405EXTINPUTIRQ
>> > > > >> PORT Intr = RS232_Uart_IP2INTC_Irpt & LEDs_4Bit_IP2INTC_Irpt &
>> > > > IIC_EEPROM_IIC2INTC_Irpt & SysACE_CompactFlash_SysACE_IRQ &
>> > > > TriMode_MAC_GMII_TemacIntc0_Irpt & DDR_SDRAM_SDMA2_Rx_IntOut &
>> > > > DDR_SDRAM_SDMA2_Tx_IntOut
>> > > > >> END
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >> #address-cells = <1>;
>> > > > >> #size-cells = <1>;
>> > > > >> compatible = "xlnx,virtex";
>> > > > >> model = "testing";
>> > > > >> DDR_SDRAM: memory@0 {
>> > > > >> device_type = "memory";
>> > > > >> reg = < 0 8000000 >;
>> > > > >> } ;
>> > > > >> chosen {
>> > > > >> bootargs = "console=ttyS0,9600 ip=on
>> > > > nfsroot=172.16.40.76:/v2pclients/jhl26,tcp";
>> > > > >> linux,stdout-path = "/plb@0/serial@83e00000";
>> > > > >> } ;
>> > > > >> cpus {
>> > > > >> #address-cells = <1>;
>> > > > >> #cpus = <1>;
>> > > > >> #size-cells = <0>;
>> > > > >> ppc405_0: cpu@0 {
>> > > > >> clock-frequency = <11e1a300>;
>> > > > >> compatible = "PowerPC,405", "ibm,ppc405";
>> > > > >> d-cache-line-size = <20>;
>> > > > >> d-cache-size = <4000>;
>> > > > >> device_type = "cpu";
>> > > > >> i-cache-line-size = <20>;
>> > > > >> i-cache-size = <4000>;
>> > > > >> model = "PowerPC,405";
>> > > > >> reg = <0>;
>> > > > >> timebase-frequency = <11e1a300>;
>> > > > >> xlnx,apu-control = <de00>;
>> > > > >> xlnx,apu-udi-1 = <a18983>;
>> > > > >> xlnx,apu-udi-2 = <a38983>;
>> > > > >> xlnx,apu-udi-3 = <a589c3>;
>> > > > >> xlnx,apu-udi-4 = <a789c3>;
>> > > > >> xlnx,apu-udi-5 = <a98c03>;
>> > > > >> xlnx,apu-udi-6 = <ab8c03>;
>> > > > >> xlnx,apu-udi-7 = <ad8c43>;
>> > > > >> xlnx,apu-udi-8 = <af8c43>;
>> > > > >> xlnx,deterministic-mult = <0>;
>> > > > >> xlnx,disable-operand-forwarding = <1>;
>> > > > >> xlnx,fastest-plb-clock = "DPLB0";
>> > > > >> xlnx,generate-plb-timespecs = <1>;
>> > > > >> xlnx,mmu-enable = <1>;
>> > > > >> xlnx,pvr-high = <0>;
>> > > > >> xlnx,pvr-low = <0>;
>> > > > >> } ;
>> > > > >> } ;
>> > > > >> plb: plb@0 {
>> > > > >> #address-cells = <1>;
>> > > > >> #size-cells = <1>;
>> > > > >> compatible = "xlnx,plb-v46-1.02.a";
>> > > > >> ranges ;
>> > > > >> IIC_EEPROM: i2c@81600000 {
>> > > > >> compatible = "xlnx,xps-iic-2.00.a";
>> > > > >> interrupt-parent = <&xps_intc_0>;
>> > > > >> interrupts = < 4 2 >;
>> > > > >> reg = < 81600000 10000 >;
>> > > > >> xlnx,clk-freq = <5f5e100>;
>> > > > >> xlnx,family = "virtex4";
>> > > > >> xlnx,gpo-width = <1>;
>> > > > >> xlnx,iic-freq = <186a0>;
>> > > > >> xlnx,scl-inertial-delay = <0>;
>> > > > >> xlnx,sda-inertial-delay = <0>;
>> > > > >> xlnx,ten-bit-adr = <0>;
>> > > > >> } ;
>> > > > >> LEDs_4Bit: gpio@81400000 {
>> > > > >> compatible = "xlnx,xps-gpio-1.00.a";
>> > > > >> interrupt-parent = <&xps_intc_0>;
>> > > > >> interrupts = < 5 2 >;
>> > > > >> reg = < 81400000 10000 >;
>> > > > >> xlnx,all-inputs = <0>;
>> > > > >> xlnx,all-inputs-2 = <0>;
>> > > > >> xlnx,dout-default = <0>;
>> > > > >> xlnx,dout-default-2 = <0>;
>> > > > >> xlnx,family = "virtex4";
>> > > > >> xlnx,gpio-width = <4>;
>> > > > >> xlnx,interrupt-present = <1>;
>> > > > >> xlnx,is-bidir = <1>;
>> > > > >> xlnx,is-bidir-2 = <1>;
>> > > > >> xlnx,is-dual = <0>;
>> > > > >> xlnx,tri-default = <ffffffff>;
>> > > > >> xlnx,tri-default-2 = <ffffffff>;
>> > > > >> } ;
>> > > > >> RS232_Uart: serial@83e00000 {
>> > > > >> compatible = "xlnx,xps-uart16550-2.00.a";
>> > > > >> // compatible = "ns16550";
>> > > > >> device_type = "serial";
>> > > > >> interrupt-parent = <&xps_intc_0>;
>> > > > >> interrupts = < 6 2 >;
>> > > > >> reg = < 83e00000 10000 >;
>> > > > >> current-speed = <d#9600>;
>> > > > >> clock-frequency = <d#100000000>; /* added
>> > > > by jhl */
>> > > > >> reg-shift = <2>;
>> > > > >> xlnx,family = "virtex4";
>> > > > >> xlnx,has-external-rclk = <0>;
>> > > > >> xlnx,has-external-xin = <0>;
>> > > > >> xlnx,is-a-16550 = <1>;
>> > > > >> } ;
>> > > > >> SysACE_CompactFlash: sysace@83600000 {
>> > > > >> compatible = "xlnx,xps-sysace-1.00.a";
>> > > > >> interrupt-parent = <&xps_intc_0>;
>> > > > >> interrupts = < 3 2 >;
>> > > > >> reg = < 83600000 10000 >;
>> > > > >> xlnx,family = "virtex4";
>> > > > >> xlnx,mem-width = <10>;
>> > > > >> } ;
>> > > > >> TriMode_MAC_GMII: xps-ll-temac@81c00000 {
>> > > > >> #address-cells = <1>;
>> > > > >> #size-cells = <1>;
>> > > > >> compatible = "xlnx,compound";
>> > > > >> ethernet@81c00000 {
>> > > > >> compatible = "xlnx,xps-ll-temac-
>> > > > 1.01.a";
>> > > > >> device_type = "network";
>> > > > >> interrupt-parent =
>> > > > <&xps_intc_0>;
>> > > > >> interrupts = < 2 2 >;
>> > > > >> llink-connected = <&PIM2>;
>> > > > >> local-mac-address = [ 02 00 00
>> > > > 00 00 01 ];
>> > > > >> reg = < 81c00000 40 >;
>> > > > >> xlnx,bus2core-clk-ratio = <1>;
>> > > > >> xlnx,phy-type = <1>;
>> > > > >> xlnx,phyaddr = <1>;
>> > > > >> xlnx,rxcsum = <0>;
>> > > > >> xlnx,rxfifo = <1000>;
>> > > > >> xlnx,temac-type = <1>;
>> > > > >> xlnx,txcsum = <0>;
>> > > > >> xlnx,txfifo = <1000>;
>> > > > >> } ;
>> > > > >> } ;
>> > > > >> mpmc@0 {
>> > > > >> #address-cells = <1>;
>> > > > >> #size-cells = <1>;
>> > > > >> compatible = "xlnx,mpmc-4.00.a";
>> > > > >> PIM2: sdma@84600100 {
>> > > > >> compatible = "xlnx,ll-dma-
>> > > > 1.00.a";
>> > > > >> interrupt-parent =
>> > > > <&xps_intc_0>;
>> > > > >> interrupts = < 1 2 0 2 >;
>> > > > >> reg = < 84600100 80 >;
>> > > > >> } ;
>> > > > >> } ;
>> > > > >> xps_bram_if_cntlr_1: xps-bram-if-cntlr@ffffe000 {
>> > > > >> compatible = "xlnx,xps-bram-if-cntlr-
>> > > > 1.00.a";
>> > > > >> reg = < ffffe000 2000 >;
>> > > > >> xlnx,family = "virtex4";
>> > > > >> } ;
>> > > > >> xps_intc_0: interrupt-controller@81800000 {
>> > > > >> #interrupt-cells = <2>;
>> > > > >> compatible = "xlnx,xps-intc-1.00.a";
>> > > > >> interrupt-controller ;
>> > > > >> reg = < 81800000 10000 >;
>> > > > >> xlnx,num-intr-inputs = <7>;
>> > > > >> } ;
>> > > > >> } ;
>> > > > >> ppc405_0_dplb1: plb@1 {
>> > > > >> #address-cells = <1>;
>> > > > >> #size-cells = <1>;
>> > > > >> compatible = "xlnx,plb-v46-1.02.a";
>> > > > >> ranges ;
>> > > > >> } ;
>> > > > >> } ;
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >> -----Original Message-----
>> > > > >> From: Magnus Hjorth [mailto:mh@omnisys.se]
>> > > > >> Sent: Saturday, March 29, 2008 6:54 AM
>> > > > >> To: git
>> > > > >> Cc: linuxppc-embedded@ozlabs.org
>> > > > >> Subject: Xilinx LLTEMAC driver issues
>> > > > >>
>> > > > >> Hi,
>> > > > >>
>> > > > >> I'm having some networking troubles with the Xilinx LLTEMAC
>> > > > >> driver
>> from
>> > > the
>> > > > >> Xilinx Linux git tree (powerpc arch) on an ML403 board.
>> > > > >> EDK9.2SP2,
>> > > > >> xps_ll_temac v1.00.b
>> > > > >>
>> > > > >> The weird thing is, that it sort of half works. It successfully
>> makes a
>> > > DHCP
>> > > > >> request and gets its IP address. I tried setting up a tftpd
>> > > > >> server,
>> and
>> > > I can
>> > > > >> see UDP requests coming in but the response doesn't seem to come
>> out. I
>> > > also
>> > > > >> tried running a TCP server on the board, and it can see and
>> > > > >> accept
>> > > incoming
>> > > > >> connections but after that no data seems to get through. I can
>> > > > >> ping
>> out
>> > > and
>> > > > >> get around 40% packet loss.
>> > > > >>
>> > > > >> Looking at /proc/interrupts, I can see both TxDma interrupts and
>> RxDma
>> > > > >> interrupts. No eth0 interrupts but that seems to be OK judging
>> > > > >> by
>> the
>> > > driver
>> > > > >> source comments. Ifconfig shows no collistions, no dropped
>> > > > >> packets,
>> no
>> > > > errors,
>> > > > >> so the system seems to think that everything is OK.
>> > > > >>
>> > > > >> Clues anyone? I'm starting to run out of ideas...
>> > > > >>
>> > > > >> Best regards,
>> > > > >> Magnus
>> > > > >>
>> > > > >>
>> > > > >> --
>> > > > >>
>> > > > >> Magnus Hjorth, M.Sc.
>> > > > >> Omnisys Instruments AB
>> > > > >> Gruvgatan 8
>> > > > >> SE-421 30 V?stra Fr?lunda, SWEDEN
>> > > > >> Phone: +46 31 734 34 09
>> > > > >> Fax: +46 31 734 34 29
>> > > > >> http://www.omnisys.se
>> > > > >>
>> > > > >
>> > > > > _______________________________________________
>> > > > > Linuxppc-embedded mailing list
>> > > > > Linuxppc-embedded@ozlabs.org
>> > > > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>> > > _______________________________________________
>> > > Linuxppc-embedded mailing list
>> > > Linuxppc-embedded@ozlabs.org
>> > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>> > >
>> > >
>> > > --
>> > > Johann Baudy
>> > > johaahn@gmail.com
>> > > ________________________________
>> > > ? Windows Live Spaces ??????????????? ???????
>> >
>> >
>> >
>> > --
>> > Johann Baudy
>> > johaahn@gmail.com
>>
>>
>> ________________________________
>> ? Windows Live Spaces ??????????????? ???????
>
>
>
> --
> Johann Baudy
> johaahn@gmail.com
>
> ------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> End of Linuxppc-embedded Digest, Vol 44, Issue 17
> *************************************************
>
^ permalink raw reply
* Re: Xilinx LLTEMAC driver issues
From: Johann Baudy @ 2008-04-04 11:54 UTC (permalink / raw)
To: MingLiu; +Cc: John Linn, git, linuxppc-embedded
In-Reply-To: <BAY138-W4276EDB68CBD5D0991BBACB2F60@phx.gbl>
RGVhciBNaW5nLAoKSSd2ZSBtYWRlIHRoaXMgdGVzdCBvbiBFREsgOS4yICsgbGxfdGVtYWMgMS4w
MC5iICsgbGx0ZW1hYyBodyBwYXRjaAooZnRwOi8vZnRwLnhpbGlueC5jb20vcHViL2FwcGxpY2F0
aW9ucy9taXNjL3R4X2xsX2lmX2VkazEwXzEuemlwCihzdGlsbCB1cCkpKyBsbF90ZW1hYyBkcml2
ZXIgcGF0Y2guCkknbSBjdXJyZW50bHkgd29ya2luZyBvbiBhIDEwLjEgcmViYXNlLiAob25nb2lu
Zy4uLikKCkJlc3QgcmVnYXJkcywKSm9oYW5uCgoKT24gRnJpLCBBcHIgNCwgMjAwOCBhdCAxMDox
MSBBTSwgTWluZ0xpdSA8ZWVtaW5nbGl1QGhvdG1haWwuY29tPiB3cm90ZToKPgo+ICBEZWFyIEpv
aGFubiwKPiAgVGhhbmtzIGZvciB0aGUgcHJvbXB0IHJlcGx5Lgo+Cj4gIEFjdHVhbGx5IEkgYW0g
dXNpbmcgRURLIDEwLjEgZXZhbHVhdGlvbiB2ZXJzaW9uLiBBY2NvcmRpbmcgdG8gWGlsaW54J3MK
PiBhbnN3ZXIsIHRoZXkgc2FpZCB0aGUgcHJvYmxlbSB3aWxsIGJlIGZpeGVkIGluIDEwLjEgYWxy
ZWFkeS4gVW5mb3J0dW5hdGVseSBJCj4gc3RpbGwgbWV0IGl0IGluIG15IGRlc2lnbi4KPgo+ICBE
byB5b3UgaGFwcGVuIHRvIHN0aWxsIGhhdmUgdGhlIGZpbGUgdHhfaWlfaWYuemlwPyBJIGNhbm5v
dCBkb3dubG9hZCBpdAo+IGZyb20gWGlsaW54IGFueSBtb3JlLiBUaGFuayB5b3Ugc28gbXVjaCBp
ZiB5b3UgY2FuIGdpdmUgbWUgYSBjb3B5Lgo+Cj4gIEJSCj4gIE1pbmcKPgo+Cj4gPiBEYXRlOiBG
cmksIDQgQXByIDIwMDggMDk6NTM6MDcgKzAwMDAKPiA+IEZyb206IGpvaGFhaG5AZ21haWwuY29t
Cj4gPiBUbzogZWVtaW5nbGl1QGhvdG1haWwuY29tCj4KPiA+IFN1YmplY3Q6IFJlOiBYaWxpbngg
TExURU1BQyBkcml2ZXIgaXNzdWVzCj4gPiBDQzogbWhAb21uaXN5cy5zZTsgbGludXhwcGMtZW1i
ZWRkZWRAb3psYWJzLm9yZzsgam9obi5saW5uQHhpbGlueC5jb207Cj4gZ2l0QHhpbGlueC5jb20K
Pgo+Cj4gPgo+ID4gSGkgTWluZywKPiA+Cj4gPiBJJ3ZlIGFscmVhZHkgdXNlZCBuZXRwZXJmICh3
aXRob3V0IE5GUykgc3VjY2Vzc2Z1bGx5Lgo+ID4gQXJlIHlvdSB1c2luZyAxLjAwLmIgYW5kIDku
MiwgaWYgeWVzIGxvb2sgYXQgQVIgIzI5NzA4Lgo+ID4KPiA+IEJlc3QgcmVnYXJkcywKPiA+IEpv
aGFubgo+ID4KPiA+IE9uIEZyaSwgQXByIDQsIDIwMDggYXQgOTozNiBBTSwgTWluZ0xpdSA8ZWVt
aW5nbGl1QGhvdG1haWwuY29tPiB3cm90ZToKPiA+ID4KPiA+ID4gRGVhciBKb2hhbm4sCj4gPiA+
IFByZXZpb3VzbHkgSSBzYWlkIHRoaXMgcGF0Y2ggaGVscHMgZm9yIHRoZSBjaGVja3N1bSBlcnJv
ciBwcm9ibGVtLiBCdXQKPiBub3cKPiA+ID4gSSBmb3VuZCBzb21lIG5ldyBpc3N1ZXMuIFllcy4g
YXQgbGVhc3Qgd2l0aCB0aGlzIHBhdGNoLCBzb21ldGhpbmcgaXMKPiBiZXR0ZXIKPiA+ID4gYW5k
IGF0IGxlYXN0IHdlIGNhbiB1c2UgdGhlIGhhcmR3YXJlIGNoZWNrc3VtIG9mZmxvYWRpbmcgdG8g
ZG8KPiBzb21ldGhpbmcsCj4gPiA+IGZvciBleGFtcGxlIEkgY2FuIG1vdW50IHRoZSBORlMgcm9v
dCBmaWxlIHN5c3RlbS4gSG93ZXZlciB3aGVuIEkgdHJ5IHRvCj4gPiA+IG1lYXN1cmUgdGhlIGV0
aGVybmV0IGJhbmR3aWR0aCB3aXRoIG5ldHBlcmYsIHNvbWV0aGluZyBnb2VzIHdyb25nIGFuZAo+
IHRoZQo+ID4gPiBORlMgbW91bnQgd2lsbCBiZSBicm9rZW4uIEkgZ3Vlc3MgdGhpcyBpcyBiZWNh
dXNlIG9mIHRoZSBsYXJnZSBidWxrIGRhdGEKPiA+ID4gdHJhbnNmZXIgYW5kIG1heWJlIHRodXMg
aXQgdHJpZ2dlcnMgdGhlIGNoZWNrc3VtIHByb2JsZW0gdG8gaGFwcGVuLgo+ID4gPgo+ID4gPiBE
byB5b3UgaGF2ZSB0aGUgc2FtZSBzaXR1YXRpb24/IE9yIHNvbWVvbmUgZWxzZSBoYXMgdGhlIHNh
bWUgcHJvYmxlbT8gSQo+ID4gPiB3aWxsIGFwcHJlY2lhdGUgaWYgeW91IGNhbiBzaGFyZSB5b3Vy
IGV4cGVyaWVuY2UuIFRoYW5rcyBhIGxvdC4KPiA+ID4KPiA+ID4gQlIKPiA+ID4gTWluZwo+ID4g
Pgo+ID4gPgo+ID4gPgo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+ID4g
PiBEYXRlOiBXZWQsIDIgQXByIDIwMDggMDc6MjA6NDMgKzAwMDAKPiA+ID4gRnJvbTogam9oYWFo
bkBnbWFpbC5jb20KPiA+ID4gVG86IG1oQG9tbmlzeXMuc2UKPiA+ID4KPiA+ID4gU3ViamVjdDog
UmU6IFhpbGlueCBMTFRFTUFDIGRyaXZlciBpc3N1ZXMKPiA+ID4gQ0M6IGxpbnV4cHBjLWVtYmVk
ZGVkQG96bGFicy5vcmc7IEpvaG4uTGlubkB4aWxpbnguY29tOyBnaXRAeGlsaW54LmNvbQo+ID4g
Pgo+ID4gPgo+ID4gPgo+ID4gPiBJJ3ZlIHNvbHZlZCB0aGlzIGNoZWNrc3VtIG9mZmxvYWRpbmcg
aXNzdWUgd2l0aCB0aGlzIGJlbG93IHBhdGNoLgo+ID4gPiBJdCBtYXkgaGVscCwgaWYgeW91IG5l
ZWQgcGVyZm9ybWFuY2UuIEl0IGNlcnRhaW5seSBuZWVkcyByZXZpZXcgYnV0IGl0Cj4gd29ya3MK
PiA+ID4gb24gbXkgc2lkZS4KPiA+ID4KPiA+ID4gLS0tIHhpbGlueGdpdC9kcml2ZXJzL25ldC94
aWxpbngKPiA+ID4gX2xsdGVtYWMveGxsdGVtYWNfbWFpbi5jLm9yaWcgMjAwOC0wMy0yMSAwOTox
MTo0My4wMDAwMDAwMDAgKzAxMDAKPiA+ID4gKysrIHhpbGlueGdpdC9kcml2ZXJzL25ldC94aWxp
bnhfbGx0ZW1hYy94bGx0ZW1hY19tYWluLmMgMjAwOC0wMy0yMQo+ID4gPiAwOToyNDoyMy4wMDAw
MDAwMDAgKzAxMDAKPiA+ID4gQEAgLTEzMyw3ICsxMzMsNyBAQAo+ID4gPiAoWExsRG1hX21CZFJl
YWQoKEJkUHRyKSwgWExMRE1BX0JEX1NUU0NUUkxfVVNSMF9PRkZTRVQpKSAmCj4gPiA+IDB4RkZG
RkZGRkUgKQo+ID4gPgo+ID4gPiAjZGVmaW5lIEJkQ3N1bVNldHVwKEJkUHRyLCBTdGFydCwgSW5z
ZXJ0KSBcCj4gPiA+IC0gWExsRG1hX21CZFdyaXRlKChCZFB0ciksIFhMTERNQV9CRF9VU1IxX09G
RlNFVCwgKFN0YXJ0KSA8PCAxNiB8Cj4gPiA+IChJbnNlcnQpKQo+ID4gPiArIFhMbERtYV9tQmRX
cml0ZSgoQmRQdHIpLCBYTExETUFfQkRfVVNSMV9PRkZTRVQsICgoU3RhcnQpIDw8IDE2KSB8Cj4g
PiA+IChJbnNlcnQpKQo+ID4gPgo+ID4gPiAvKiBVc2VkIGZvciBkZWJ1Z2dpbmcgKi8KPiA+ID4g
I2RlZmluZSBCZENzdW1JbnNlcnQoQmRQdHIpIFwKPiA+ID4gQEAgLTE1NDAsNyArMTU0MSw3IEBA
IHN0YXRpYyBpbnQgeGVuZXRfRG1hU2VuZF9pbnRlcm5hbChzdHJ1Y3QKPiA+ID4gLyoKPiA+ID4g
KiBpZiB0eCBjaGVja3N1bSBvZmZsb2FkaW5nIGlzIGVuYWJsZWQsIHdoZW4gdGhlIGV0aGVybmV0
IHN0YWNrCj4gPiA+ICogd2FudHMgdXMgdG8gcGVyZm9ybSB0aGUgY2hlY2tzdW0gaW4gaGFyZHdh
cmUsCj4gPiA+IC0gKiBza2ItPmlwX3N1bW1lZCBpcyBDSEVDS1NVTV9DT01QTEVURS4gT3RoZXJ3
aXNlIHNrYi0+aXBfc3VtbWVkIGlzCj4gPiA+ICsgKiBza2ItPmlwX3N1bW1lZCBpcyBDSEVDS1NV
TV9QQVJUSUFMLiBPdGhlcndpc2Ugc2tiLT5pcF9zdW1tZWQgaXMKPiA+ID4gKiBDSEVDS1NVTV9O
T05FLCBtZWFuaW5nIHRoZSBjaGVja3N1bSBpcyBhbHJlYWR5IGRvbmUsIG9yCj4gPiA+ICogQ0hF
Q0tTVU1fVU5ORUNFU1NBUlksIG1lYW5pbmcgY2hlY2tzdW1taW5nIGlzIHR1cm5lZCBvZmYgKGUu
Zy4KPiA+ID4gKiBsb29wYmFjayBpbnRlcmZhY2UpCj4gPiA+IEBAIC0xNTY1LDkgKzE1NjYsMTEg
QEAgc3RhdGljIGludCB4ZW5ldF9EbWFTZW5kX2ludGVybmFsKHN0cnVjdAo+ID4gPiAqIHNrYl90
cmFuc3BvcnRfaGVhZGVyKHNrYikgcG9pbnRzIHRvIHRoZSBiZWdpbm5pbmcgb2YgdGhlIGlwIGhl
YWRlcgo+ID4gPiAqCj4gPiA+ICovCj4gPiA+IC0gaWYgKHNrYi0+aXBfc3VtbWVkID09IENIRUNL
U1VNX0NPTVBMRVRFKSB7Cj4gPiA+ICsgaWYgKHNrYi0+aXBfc3VtbWVkID09IENIRUNLU1VNX1BB
UlRJQUwpIHsKPiA+ID4gKwo+ID4gPiArIHVuc2lnbmVkIGludCBjc3VtX3N0YXJ0X29mZiA9IHNr
Yl90cmFuc3BvcnRfb2Zmc2V0KHNrYik7Cj4gPiA+ICsgdW5zaWduZWQgaW50IGNzdW1faW5kZXhf
b2ZmID0gY3N1bV9zdGFydF9vZmYgKyBza2ItPmNzdW1fb2Zmc2V0Owo+ID4gPgo+ID4gPiAtIHVu
c2lnbmVkIGNoYXIgKnJhdyA9IHNrYl90cmFuc3BvcnRfaGVhZGVyKHNrYik7Cj4gPiA+ICNpZiAw
Cj4gPiA+IHsKPiA+ID4gdW5zaWduZWQgaW50IGNzdW0gPSBfeGVuZXRfdHhfY3N1bShza2IpOwo+
ID4gPiBAQCAtMTU3OCw5ICsxNTgxLDggQEAgc3RhdGljIGludCB4ZW5ldF9EbWFTZW5kX2ludGVy
bmFsKHN0cnVjdAo+ID4gPiB9Cj4gPiA+ICNlbHNlCj4gPiA+IEJkQ3N1bUVuYWJsZShiZF9wdHIp
Owo+ID4gPiAtIEJkQ3N1bVNldHVwKGJkX3B0ciwgcmF3IC0gc2tiLT5kYXRhLAo+ID4gPiAtIChy
YXcgLSBza2ItPmRhdGEpICsgc2tiLT5jc3VtKTsKPiA+ID4gLQo+ID4gPiArIEJkQ3N1bVNldHVw
KGJkX3B0ciwgY3N1bV9zdGFydF9vZmYsCj4gPiA+ICsgY3N1bV9pbmRleF9vZmYpOwo+ID4gPiAj
ZW5kaWYKPiA+ID4gbHAtPnR4X2h3X2NzdW1zKys7Cj4gPiA+IH0KPiA+ID4gQEAgLTMyNzcsNyAr
MzI3OSw3IEBAIHN0YXRpYyBpbnQgX19kZXZpbml0IHh0ZW5ldF9vZl9wcm9iZShzdHIKPiA+ID4g
c3RydWN0IHJlc291cmNlICpyX2lycSA9ICZyX2lycV9zdHJ1Y3Q7IC8qIEludGVycnVwdCByZXNv
dXJjZXMgKi8KPiA+ID4gc3RydWN0IHJlc291cmNlICpyX21lbSA9ICZyX21lbV9zdHJ1Y3Q7IC8q
IElPIG1lbSByZXNvdXJjZXMgKi8KPiA+ID4gc3RydWN0IHhsbHRlbWFjX3BsYXRmb3JtX2RhdGEg
KnBkYXRhID0gJnBkYXRhX3N0cnVjdDsKPiA+ID4gLSB2b2lkICptYWNfYWRkcmVzczsKPiA+ID4g
KyBjb25zdCB2b2lkICptYWNfYWRkcmVzczsKPiA+ID4gaW50IHJjID0gMDsKPiA+ID4gY29uc3Qg
cGhhbmRsZSAqbGxpbmtfY29ubmVjdGVkX2hhbmRsZTsKPiA+ID4gc3RydWN0IGRldmljZV9ub2Rl
ICpsbGlua19jb25uZWN0ZWRfbm9kZTsKPiA+ID4KPiA+ID4KPiA+ID4gT24gTW9uLCBNYXIgMzEs
IDIwMDggYXQgMTE6MTAgQU0sIE1hZ251cyBIam9ydGggPG1oQG9tbmlzeXMuc2U+IHdyb3RlOgo+
ID4gPgo+ID4gPiBEZWFjdGl2YXRpbmcgY2hlY2tzdW0gb2ZmbG9hZGluZyBoZWxwZWQgYSBsb3Qh
IEkgc3RpbGwgaGF2ZSBzb21lIHBhY2tldAo+IGxvc3MKPiA+ID4gYW5kIG5vdCB0aGUgYmVzdCBw
ZXJmb3JtYW5jZSAoVEZUUCB0cmFuc2ZlciBhYm91dCAxMDAga2J5dGUvcykgYnV0IGF0Cj4gbGVh
c3QKPiA+ID4gaXQgd29ya3MuCj4gPiA+Cj4gPiA+IFRoYW5rcyEKPiA+ID4KPiA+ID4gLy9NYWdu
dXMKPiA+ID4KPiA+ID4KPiA+ID4KPiA+ID4KPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQo+ID4gPiA+IEZyb206IHJ6YTEgW21haWx0bzpyemExQHNvLWxvZ2ljLm5ldF0KPiA+ID4g
PiBTZW50OiBkZW4gMzEgbWFycyAyMDA4IDExOjE0Cj4gPiA+ID4gVG86IE1hZ251cyBIam9ydGgK
PiA+ID4gPiBDYzogSm9obiBMaW5uOyBnaXQ7IGxpbnV4cHBjLWVtYmVkZGVkQG96bGFicy5vcmcK
PiA+ID4gPiBTdWJqZWN0OiBSZTogWGlsaW54IExMVEVNQUMgZHJpdmVyIGlzc3Vlcwo+ID4gPiA+
Cj4gPiA+ID4gSGkgTWFnbnVzLAo+ID4gPiA+Cj4gPiA+ID4gMS4KPiA+ID4gPiBJIGFtIHVzaW5n
IG5lYXJseSB0aGUgc2FtZSB2ZXJzaW9ucyB0aGVuIHlvdSBhbmQgZ290IHRoZSBzYW1lIHByb2Js
ZW1zCj4gPiA+ID4gdG9vIDstKS4KPiA+ID4gPiBJIHRoaW5rIHRoZXJlIGFyZSBzb21lIHByb2Js
ZW1zIHdpdGggdGhlIGNoZWNrc3VtIG9mZmxvYWRpbmcuCj4gPiA+ID4gVHJ5IHRvIHNuaWZmIHRo
ZSBzb21lIHBhY2thZ2VzIChlLmcuIHdpcmVzaGFyaykuLi4KPiA+ID4gPiBGb3IgbWUgSUNNUCAo
cGluZykgd29ya2VkIGJ1dCB1ZHAgYW5kIHRjcCBub3QgKGJlY2F1c2Ugb2ZmIGEgd3JvbmcKPiA+
ID4gPiBjaGVja3N1bSBpbiB0aGUgdHJhbnNwb3J0IGxheWVyKS4KPiA+ID4gPiBBIHF1aWNrIHNv
bHV0aW9uIGlzIHRvIGp1c3QgZGVhY3RpdmF0ZSBjaGVja3N1bSBvZmZsb2FkaW5nLgo+ID4gPiA+
Cj4gPiA+ID4gMi4KPiA+ID4gPiBJIHJlbWVtYmVyIHNvbWUgcHJvYmxlbXMgd2l0aCBWaXJ0ZXgt
NCBwcmVzYW1wbGVzIHRvby4KPiA+ID4gPiBUaGVyZSB3aGVyZSBwcm9ibGVtcyB3aXRoIHRoZSBo
YXJkLXRlbWFjIHdyYXBwZXIuIFlvdSBoYWQgdG8gdXNlCj4gMS4wMC5hCj4gPiA+ID4gYW5kIG5v
dCBiIHZlcnNpb24uCj4gPiA+ID4gQnV0IEkgZG9uJ3QgaGF2ZSB0aGVzZSBwcm9ibGVtcyB3aXRo
IHRoZSBFREsgOS4yc3AyL0lTRTkuMnNwMyBhbnltb3JlLgo+ID4gPiA+Cj4gPiA+ID4gYWxsIHRo
ZSBiZXN0LAo+ID4gPiA+IFJvYmVydAo+ID4gPiA+Cj4gPiA+ID4gTWFnbnVzIEhqb3J0aCB3cm90
ZToKPiA+ID4gPiA+IEhpIEpvaG4sCj4gPiA+ID4gPgo+ID4gPiA+ID4gVGhhbmtzIGZvciB0aGUg
dmVyeSBmYXN0IHJlcGx5ISBSaWdodCBub3cgSSdtIG5vdCBhdCB3b3JrIHNvIEkgZG9uJ3QKPiA+
ID4gPiA+IGhhdmUgdGhlIGJvYXJkIG9yIEVESyBoZXJlIHRvIHRlc3QgYW55dGhpbmcuCj4gPiA+
ID4gPgo+ID4gPiA+ID4gSSdtIHVzaW5nIGNoZWNrc3VtIG9mZmxvYWQsIGJ1dCBJIGRvbid0IGtu
b3cgaWYgRFJFIGlzIGVuYWJsZWQgb3IKPiBub3QuIEkKPiA+ID4gPiA+IGNhbid0IHJlY2FsbCBz
ZWVpbmcgYW55IHNldHRpbmcgdG8gZW5hYmxlL2Rpc2FibGUgRFJFLi4KPiA+ID4gPiA+Cj4gPiA+
ID4gPiBBIGZldyB0aGluZ3MgdGhhdCBjcm9zc2VkIG15IG1pbmQ6Cj4gPiA+ID4gPgo+ID4gPiA+
ID4gTGFzdCB5ZWFyIEkgZGlkIGEgZGVzaWduIHdpdGggRURLIDguMiwgYmFjayB0aGVuIHRoZXJl
IHdhcyBhbiBpc3N1ZQo+IHdpdGgKPiA+ID4gPiA+IHRoZSBNTDQwMyBib2FyZHMgaGF2aW5nIGFu
IG9sZCByZXZpc2lvbiBvZiB0aGUgRlBHQSB3aGljaCB3YXNuJ3QKPiA+ID4gPiA+IGNvbXBhdGli
bGUgd2l0aCBzb21lIHZlcnNpb25zIG9mIHRoZSBJUCBjb3JlLiBUaGVyZSBhcmUgbm8gc3VjaAo+
IHZlcnNpb24KPiA+ID4gPiA+IGlzc3VlcyB3aXRoIHRoZSB4cHNfbGxfdGVtYWM/Cj4gPiA+ID4g
Pgo+ID4gPiA+ID4gSSBkb24ndCB0aGluayB0aGF0IEkgaGFkIHBoeS1hZGRyIHNldCBpbiB0aGUg
RFRTIGZpbGUuIFdpbGwgdGVzdAo+IHRoYXQgb24KPiA+ID4gPiA+IE1vbmRheS4KPiA+ID4gPiA+
Cj4gPiA+ID4gPiBCZXN0IHJlZ2FyZHMsCj4gPiA+ID4gPiBNYWdudXMKPiA+ID4gPiA+Cj4gPiA+
ID4gPgo+ID4gPiA+ID4gT24gU2F0LCAyMDA4LTAzLTI5IGF0IDA3OjU4IC0wNjAwLCBKb2huIExp
bm4gd3JvdGU6Cj4gPiA+ID4gPgo+ID4gPiA+ID4+IEhpIE1hZ251cywKPiA+ID4gPiA+Pgo+ID4g
PiA+ID4+IFNvcnJ5IHRvIGhlYXIgeW91J3JlIGhhdmluZyBwcm9ibGVtcyB3aXRoIGl0Lgo+ID4g
PiA+ID4+Cj4gPiA+ID4gPj4gSSBhbSBkb2luZyB0ZXN0aW5nIG9uIGFuIE1MNDA1IHdoaWNoIGlz
IHRoZSBzYW1lIGJvYXJkIGJ1dCB3aXRoIGEKPiA+ID4gYmlnZ2VyCj4gPiA+ID4gRlBHQSwgYnV0
IHdpdGggcHBjIGFyY2ggYW5kIEkgZG9uJ3Qgc2VlIHRoaXMgaXNzdWUuIEkgaGF2ZSBkb25lCj4g
bGltaXRlZAo+ID4gPiB0ZXN0aW5nCj4gPiA+ID4gd2l0aCBwb3dlcnBjIGFyY2ggYW5kIHRoZSBM
TCBURU1BQywgYnV0IEkgZGlkbid0IHNlZSB0aGlzIGlzc3VlIHRoZXJlCj4gPiA+IGVpdGhlci4K
PiA+ID4gPiBQb3dlcnBjIGFyY2ggaXMgZGVmaW5pdGVseSBsZXNzIG1hdHVyZSBpbiBteSBleHBl
cmllbmNlIHRoYW4gdGhlIHBwYwo+IGFyY2guCj4gPiA+IEknbGwKPiA+ID4gPiBkbyBhIHF1aWNr
IHRlc3Qgd2l0aCBteSBwb3dlcnBjIGFyY2ggYW5kIG1ha2Ugc3VyZSBhZ2FpbiBJJ20gbm90Cj4g
c2VlaW5nCj4gPiA+IGl0Lgo+ID4gPiA+ID4+Cj4gPiA+ID4gPj4gTXkga2VybmVsIGlzIGZyb20g
dGhlIFhpbGlueCBHaXQgdHJlZSwgYnV0IHRoZXJlIGhhdmUgYmVlbiBhIG51bWJlcgo+IG9mCj4g
PiA+ID4gY2hhbmdlcyB3ZSBoYXZlIHB1c2hlZCBvdXQgc28gSSBkb24ndCBrbm93IGhvdyBsb25n
IGFnbyB5b3UgcHVsbGVkCj4gZnJvbQo+ID4gPiB0aGUgR2l0Cj4gPiA+ID4gdHJlZS4KPiA+ID4g
PiA+Pgo+ID4gPiA+ID4+IE15IEVESyBwcm9qZWN0IGlzIDEwLjEgc28gaXQncyBhIGxpdHRsZSBu
ZXdlci4gSSBhbSB1c2luZyBMTCBURU1BQwo+ID4gPiAxLjAxYSBzbwo+ID4gPiA+IGl0J3MgYSBs
aXR0bGUgbmV3ZXIuIEkgcmV2aWV3ZWQgdGhlIGNoYW5nZSBsb2cgZm9yIHRoZSBMTCBURU1BQyBh
bmQKPiBkb24ndAo+ID4gPiBzZWUKPiA+ID4gPiBhbnkgYmlnIHByb2JsZW1zIHRoYXQgd2VyZSBm
aXhlZCBpbiB0aGUgbmV3ZXIgdmVyc2lvbnMsIG1vcmUgbmV3Cj4gZmVhdHVyZXMuCj4gPiA+IEkn
bGwKPiA+ID4gPiBjaGVjayB3aXRoIHNvbWUgb3RoZXJzIGhlcmUgdG8gc2VlIGlmIEkgbWlzc2Vk
IHNvbWV0aGluZyB0aGVyZS4KPiA+ID4gPiA+Pgo+ID4gPiA+ID4+IEkgYW0gdXNpbmcgRE1BIGFs
c28sIGJ1dCBubyBEUkUgb3IgY2hlY2tzdW0gb2ZmbG9hZC4gWW91IGRpZG4ndCBzYXkKPiA+ID4g
YW55dGhpbmcKPiA+ID4gPiBhYm91dCB0aG9zZS4gSSdtIGdvaW5nIHRvIGluc2VydCBteSBtaHMg
ZmlsZSB0aGF0IGRlc2NyaWJlcyBteSBzeXN0ZW0KPiB0bwo+ID4gPiBsZXQgeW91Cj4gPiA+ID4g
Y29tcGFyZSB5b3VyIHN5c3RlbSBjb25maWd1cmF0aW9uLiBJdCdzIG5vdCBjbGVhciB0byBtZSB5
ZXQgaWYgeW91Cj4gaGF2ZSBhCj4gPiA+IGgvdyBvcgo+ID4gPiA+IHMvdyBwcm9ibGVtLgo+ID4g
PiA+ID4+Cj4gPiA+ID4gPj4gSSdsbCBhbHNvIGluc2VydCBzb21lIG9mIG15IGRldmljZSB0cmVl
IHdpdGggdGhlIExMIFRFTUFDIHNvIHlvdQo+IGNhbgo+ID4gPiBjb21wYXJlCj4gPiA+ID4gKGln
bm9yZSAxNjU1MCBzdHVmZiBhcyB3ZSBhcmUgc3RpbGwgd29ya2luZyBvbiB0aGF0KS4KPiA+ID4g
PiA+Pgo+ID4gPiA+ID4+IFNpbmNlIHlvdSBjYW4ndCBwaW5nIHJlbGlhYmx5IEkgd291bGQgcHJv
YmFibHkgZm9jdXMgb24gdGhhdCBzaW5jZQo+IGl0J3MKPiA+ID4gPiBzaW1wbGVyIHRoYW4gdGhl
IG90aGVyIGlzc3VlcyB5b3UncmUgc2VlaW5nLgo+ID4gPiA+ID4+Cj4gPiA+ID4gPj4gVGhhbmtz
LAo+ID4gPiA+ID4+IEpvaG4KPiA+ID4gPiA+Pgo+ID4gPiA+ID4+Cj4gPiA+ID4gPj4KPiA+ID4g
PiA+PiAjCj4gPiA+ID4KPiA+ID4KPiAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKPiA+ID4gPiA+PiAj
IENyZWF0ZWQgYnkgQmFzZSBTeXN0ZW0gQnVpbGRlciBXaXphcmQgZm9yIFhpbGlueCBFREsgMTAu
MS4xIEJ1aWxkCj4gPiA+ID4gRURLX0tfU1AxLjEKPiA+ID4gPiA+PiAjIFRodSBGZWIgMTQgMTQ6
MTE6MTIgMjAwOAo+ID4gPiA+ID4+ICMgVGFyZ2V0IEJvYXJkOiBYaWxpbnggVmlydGV4IDQgTUw0
MDUgRXZhbHVhdGlvbiBQbGF0Zm9ybSBSZXYgMQo+ID4gPiA+ID4+ICMgRmFtaWx5OiB2aXJ0ZXg0
Cj4gPiA+ID4gPj4gIyBEZXZpY2U6IHhjNHZmeDIwCj4gPiA+ID4gPj4gIyBQYWNrYWdlOiBmZjY3
Mgo+ID4gPiA+ID4+ICMgU3BlZWQgR3JhZGU6IC0xMAo+ID4gPiA+ID4+ICMgUHJvY2Vzc29yOiBw
cGM0MDVfMAo+ID4gPiA+ID4+ICMgUHJvY2Vzc29yIGNsb2NrIGZyZXF1ZW5jeTogMzAwLjAwIE1I
ego+ID4gPiA+ID4+ICMgQnVzIGNsb2NrIGZyZXF1ZW5jeTogMTAwLjAwIE1Iego+ID4gPiA+ID4+
ICMgT24gQ2hpcCBNZW1vcnkgOiA4IEtCCj4gPiA+ID4gPj4gIyBUb3RhbCBPZmYgQ2hpcCBNZW1v
cnkgOiAxMjggTUIKPiA+ID4gPiA+PiAjIC0gRERSX1NEUkFNID0gMTI4IE1CCj4gPiA+ID4gPj4g
Iwo+ID4gPiA+Cj4gPiA+Cj4gIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjCj4gPiA+ID4gPj4gUEFSQU1F
VEVSIFZFUlNJT04gPSAyLjEuMAo+ID4gPiA+ID4+Cj4gPiA+ID4gPj4KPiA+ID4gPiA+PiBQT1JU
IGZwZ2FfMF9SUzIzMl9VYXJ0X3Npbl9waW4gPSBmcGdhXzBfUlMyMzJfVWFydF9zaW4sIERJUiA9
IEkKPiA+ID4gPiA+PiBQT1JUIGZwZ2FfMF9SUzIzMl9VYXJ0X3NvdXRfcGluID0gZnBnYV8wX1JT
MjMyX1VhcnRfc291dCwgRElSID0gTwo+ID4gPiA+ID4+IFBPUlQgZnBnYV8wX0xFRHNfNEJpdF9H
UElPX0lPX3BpbiA9IGZwZ2FfMF9MRURzXzRCaXRfR1BJT19JTywgRElSID0KPiA+ID4gSU8sIFZF
Qwo+ID4gPiA+ID0gWzA6M10KPiA+ID4gPiA+PiBQT1JUIGZwZ2FfMF9JSUNfRUVQUk9NX1NjbF9w
aW4gPSBmcGdhXzBfSUlDX0VFUFJPTV9TY2wsIERJUiA9IElPCj4gPiA+ID4gPj4gUE9SVCBmcGdh
XzBfSUlDX0VFUFJPTV9TZGFfcGluID0gZnBnYV8wX0lJQ19FRVBST01fU2RhLCBESVIgPSBJTwo+
ID4gPiA+ID4+IFBPUlQgZnBnYV8wX1N5c0FDRV9Db21wYWN0Rmxhc2hfU3lzQUNFX0NMS19waW4g
PQo+ID4gPiA+IGZwZ2FfMF9TeXNBQ0VfQ29tcGFjdEZsYXNoX1N5c0FDRV9DTEssIERJUiA9IEkK
PiA+ID4gPiA+PiBQT1JUIGZwZ2FfMF9TeXNBQ0VfQ29tcGFjdEZsYXNoX1N5c0FDRV9NUEFfcGlu
ID0KPiA+ID4gPiBmcGdhXzBfU3lzQUNFX0NvbXBhY3RGbGFzaF9TeXNBQ0VfTVBBLCBESVIgPSBP
LCBWRUMgPSBbNjoxXQo+ID4gPiA+ID4+IFBPUlQgZnBnYV8wX1N5c0FDRV9Db21wYWN0Rmxhc2hf
U3lzQUNFX01QRF9waW4gPQo+ID4gPiA+IGZwZ2FfMF9TeXNBQ0VfQ29tcGFjdEZsYXNoX1N5c0FD
RV9NUEQsIERJUiA9IElPLCBWRUMgPSBbMTU6MF0KPiA+ID4gPiA+PiBQT1JUIGZwZ2FfMF9TeXNB
Q0VfQ29tcGFjdEZsYXNoX1N5c0FDRV9DRU5fcGluID0KPiA+ID4gPiBmcGdhXzBfU3lzQUNFX0Nv
bXBhY3RGbGFzaF9TeXNBQ0VfQ0VOLCBESVIgPSBPCj4gPiA+ID4gPj4gUE9SVCBmcGdhXzBfU3lz
QUNFX0NvbXBhY3RGbGFzaF9TeXNBQ0VfT0VOX3BpbiA9Cj4gPiA+ID4gZnBnYV8wX1N5c0FDRV9D
b21wYWN0Rmxhc2hfU3lzQUNFX09FTiwgRElSID0gTwo+ID4gPiA+ID4+IFBPUlQgZnBnYV8wX1N5
c0FDRV9Db21wYWN0Rmxhc2hfU3lzQUNFX1dFTl9waW4gPQo+ID4gPiA+IGZwZ2FfMF9TeXNBQ0Vf
Q29tcGFjdEZsYXNoX1N5c0FDRV9XRU4sIERJUiA9IE8KPiA+ID4gPiA+PiBQT1JUIGZwZ2FfMF9T
eXNBQ0VfQ29tcGFjdEZsYXNoX1N5c0FDRV9NUElSUV9waW4gPQo+ID4gPiA+IGZwZ2FfMF9TeXNB
Q0VfQ29tcGFjdEZsYXNoX1N5c0FDRV9NUElSUSwgRElSID0gSQo+ID4gPiA+ID4+IFBPUlQgZnBn
YV8wX0REUl9TRFJBTV9ERFJfQ2xrX3BpbiA9IGZwZ2FfMF9ERFJfU0RSQU1fRERSX0NsaywgRElS
ID0KPiBPCj4gPiA+ID4gPj4gUE9SVCBmcGdhXzBfRERSX1NEUkFNX0REUl9DbGtfbl9waW4gPSBm
cGdhXzBfRERSX1NEUkFNX0REUl9DbGtfbiwKPiBESVIKPiA+ID4gPSBPCj4gPiA+ID4gPj4gUE9S
VCBmcGdhXzBfRERSX1NEUkFNX0REUl9BZGRyX3BpbiA9IGZwZ2FfMF9ERFJfU0RSQU1fRERSX0Fk
ZHIsIERJUgo+ID0KPiA+ID4gTywgVkVDCj4gPiA+ID4gPSBbMTI6MF0KPiA+ID4gPiA+PiBQT1JU
IGZwZ2FfMF9ERFJfU0RSQU1fRERSX0JhbmtBZGRyX3BpbiA9Cj4gPiA+IGZwZ2FfMF9ERFJfU0RS
QU1fRERSX0JhbmtBZGRyLCBESVIKPiA+ID4gPiA9IE8sIFZFQyA9IFsxOjBdCj4gPiA+ID4gPj4g
UE9SVCBmcGdhXzBfRERSX1NEUkFNX0REUl9DQVNfbl9waW4gPSBmcGdhXzBfRERSX1NEUkFNX0RE
Ul9DQVNfbiwKPiBESVIKPiA+ID4gPSBPCj4gPiA+ID4gPj4gUE9SVCBmcGdhXzBfRERSX1NEUkFN
X0REUl9DRV9waW4gPSBmcGdhXzBfRERSX1NEUkFNX0REUl9DRSwgRElSID0gTwo+ID4gPiA+ID4+
IFBPUlQgZnBnYV8wX0REUl9TRFJBTV9ERFJfQ1Nfbl9waW4gPSBmcGdhXzBfRERSX1NEUkFNX0RE
Ul9DU19uLCBESVIKPiA9Cj4gPiA+IE8KPiA+ID4gPiA+PiBQT1JUIGZwZ2FfMF9ERFJfU0RSQU1f
RERSX1JBU19uX3BpbiA9IGZwZ2FfMF9ERFJfU0RSQU1fRERSX1JBU19uLAo+IERJUgo+ID4gPiA9
IE8KPiA+ID4gPiA+PiBQT1JUIGZwZ2FfMF9ERFJfU0RSQU1fRERSX1dFX25fcGluID0gZnBnYV8w
X0REUl9TRFJBTV9ERFJfV0VfbiwgRElSCj4gPQo+ID4gPiBPCj4gPiA+ID4gPj4gUE9SVCBmcGdh
XzBfRERSX1NEUkFNX0REUl9ETV9waW4gPSBmcGdhXzBfRERSX1NEUkFNX0REUl9ETSwgRElSID0K
PiBPLAo+ID4gPiBWRUMgPQo+ID4gPiA+IFszOjBdCj4gPiA+ID4gPj4gUE9SVCBmcGdhXzBfRERS
X1NEUkFNX0REUl9EUVMgPSBmcGdhXzBfRERSX1NEUkFNX0REUl9EUVMsIERJUiA9IElPLAo+ID4g
PiBWRUMgPQo+ID4gPiA+IFszOjBdCj4gPiA+ID4gPj4gUE9SVCBmcGdhXzBfRERSX1NEUkFNX0RE
Ul9EUSA9IGZwZ2FfMF9ERFJfU0RSQU1fRERSX0RRLCBESVIgPSBJTywKPiBWRUMKPiA+ID4gPQo+
ID4gPiA+IFszMTowXQo+ID4gPiA+ID4+IFBPUlQgZnBnYV8wX1RyaU1vZGVfTUFDX0dNSUlfR01J
SV9UWERfMF9waW4gPQo+ID4gPiA+IGZwZ2FfMF9UcmlNb2RlX01BQ19HTUlJX0dNSUlfVFhEXzAs
IERJUiA9IE8sIFZFQyA9IFs3OjBdCj4gPiA+ID4gPj4gUE9SVCBmcGdhXzBfVHJpTW9kZV9NQUNf
R01JSV9HTUlJX1RYX0VOXzBfcGluID0KPiA+ID4gPiBmcGdhXzBfVHJpTW9kZV9NQUNfR01JSV9H
TUlJX1RYX0VOXzAsIERJUiA9IE8KPiA+ID4gPiA+PiBQT1JUIGZwZ2FfMF9UcmlNb2RlX01BQ19H
TUlJX0dNSUlfVFhfRVJfMF9waW4gPQo+ID4gPiA+IGZwZ2FfMF9UcmlNb2RlX01BQ19HTUlJX0dN
SUlfVFhfRVJfMCwgRElSID0gTwo+ID4gPiA+ID4+IFBPUlQgZnBnYV8wX1RyaU1vZGVfTUFDX0dN
SUlfR01JSV9UWF9DTEtfMF9waW4gPQo+ID4gPiA+IGZwZ2FfMF9UcmlNb2RlX01BQ19HTUlJX0dN
SUlfVFhfQ0xLXzAsIERJUiA9IE8KPiA+ID4gPiA+PiBQT1JUIGZwZ2FfMF9UcmlNb2RlX01BQ19H
TUlJX0dNSUlfUlhEXzBfcGluID0KPiA+ID4gPiBmcGdhXzBfVHJpTW9kZV9NQUNfR01JSV9HTUlJ
X1JYRF8wLCBESVIgPSBJLCBWRUMgPSBbNzowXQo+ID4gPiA+ID4+IFBPUlQgZnBnYV8wX1RyaU1v
ZGVfTUFDX0dNSUlfR01JSV9SWF9EVl8wX3BpbiA9Cj4gPiA+ID4gZnBnYV8wX1RyaU1vZGVfTUFD
X0dNSUlfR01JSV9SWF9EVl8wLCBESVIgPSBJCj4gPiA+ID4gPj4gUE9SVCBmcGdhXzBfVHJpTW9k
ZV9NQUNfR01JSV9HTUlJX1JYX0VSXzBfcGluID0KPiA+ID4gPiBmcGdhXzBfVHJpTW9kZV9NQUNf
R01JSV9HTUlJX1JYX0VSXzAsIERJUiA9IEkKPiA+ID4gPiA+PiBQT1JUIGZwZ2FfMF9UcmlNb2Rl
X01BQ19HTUlJX0dNSUlfUlhfQ0xLXzBfcGluID0KPiA+ID4gPiBmcGdhXzBfVHJpTW9kZV9NQUNf
R01JSV9HTUlJX1JYX0NMS18wLCBESVIgPSBJCj4gPiA+ID4gPj4gUE9SVCBmcGdhXzBfVHJpTW9k
ZV9NQUNfR01JSV9NSUlfVFhfQ0xLXzBfcGluID0KPiA+ID4gPiBmcGdhXzBfVHJpTW9kZV9NQUNf
R01JSV9NSUlfVFhfQ0xLXzAsIERJUiA9IEkKPiA+ID4gPiA+PiBQT1JUIGZwZ2FfMF9UcmlNb2Rl
X01BQ19HTUlJX01ESU9fMF9waW4gPQo+ID4gPiBmcGdhXzBfVHJpTW9kZV9NQUNfR01JSV9NRElP
XzAsCj4gPiA+ID4gRElSID0gSU8KPiA+ID4gPiA+PiBQT1JUIGZwZ2FfMF9UcmlNb2RlX01BQ19H
TUlJX01EQ18wX3BpbiA9Cj4gPiA+IGZwZ2FfMF9UcmlNb2RlX01BQ19HTUlJX01EQ18wLCBESVIK
PiA+ID4gPiA9IE8KPiA+ID4gPiA+PiBQT1JUIGZwZ2FfMF9UcmlNb2RlX01BQ19HTUlJX1RlbWFj
UGh5X1JTVF9uX3BpbiA9Cj4gPiA+ID4gZnBnYV8wX1RyaU1vZGVfTUFDX0dNSUlfVGVtYWNQaHlf
UlNUX24sIERJUiA9IE8KPiA+ID4gPiA+PiBQT1JUIHN5c19jbGtfcGluID0gZGNtX2Nsa19zLCBE
SVIgPSBJLCBTSUdJUyA9IENMSywgQ0xLX0ZSRVEgPQo+ID4gPiAxMDAwMDAwMDAKPiA+ID4gPiA+
PiBQT1JUIHN5c19yc3RfcGluID0gc3lzX3JzdF9zLCBESVIgPSBJLCBSU1RfUE9MQVJJVFkgPSAw
LCBTSUdJUyA9Cj4gUlNUCj4gPiA+ID4gPj4KPiA+ID4gPiA+Pgo+ID4gPiA+ID4+IEJFR0lOIHBw
YzQwNV92aXJ0ZXg0Cj4gPiA+ID4gPj4gUEFSQU1FVEVSIElOU1RBTkNFID0gcHBjNDA1XzAKPiA+
ID4gPiA+PiBQQVJBTUVURVIgSFdfVkVSID0gMi4wMS5hCj4gPiA+ID4gPj4gUEFSQU1FVEVSIENf
RkFTVEVTVF9QTEJfQ0xPQ0sgPSBEUExCMQo+ID4gPiA+ID4+IFBBUkFNRVRFUiBDX0lEQ1JfQkFT
RUFERFIgPSAwYjAxMDAwMDAwMDAKPiA+ID4gPiA+PiBQQVJBTUVURVIgQ19JRENSX0hJR0hBRERS
ID0gMGIwMTExMTExMTExCj4gPiA+ID4gPj4gQlVTX0lOVEVSRkFDRSBKVEFHUFBDID0ganRhZ3Bw
Y18wXzAKPiA+ID4gPiA+PiBCVVNfSU5URVJGQUNFIElQTEIwID0gcGxiCj4gPiA+ID4gPj4gQlVT
X0lOVEVSRkFDRSBEUExCMCA9IHBsYgo+ID4gPiA+ID4+IEJVU19JTlRFUkZBQ0UgSVBMQjEgPSBw
cGM0MDVfMF9pcGxiMQo+ID4gPiA+ID4+IEJVU19JTlRFUkZBQ0UgRFBMQjEgPSBwcGM0MDVfMF9k
cGxiMQo+ID4gPiA+ID4+IEJVU19JTlRFUkZBQ0UgUkVTRVRQUEMgPSBwcGNfcmVzZXRfYnVzCj4g
PiA+ID4gPj4gUE9SVCBDUE1DNDA1Q0xPQ0sgPSBwcm9jX2Nsa19zCj4gPiA+ID4gPj4gUE9SVCBF
SUNDNDA1RVhUSU5QVVRJUlEgPSBFSUNDNDA1RVhUSU5QVVRJUlEKPiA+ID4gPiA+PiBFTkQKPiA+
ID4gPiA+Pgo+ID4gPiA+ID4+IEJFR0lOIGp0YWdwcGNfY250bHIKPiA+ID4gPiA+PiBQQVJBTUVU
RVIgSU5TVEFOQ0UgPSBqdGFncHBjXzAKPiA+ID4gPiA+PiBQQVJBTUVURVIgSFdfVkVSID0gMi4w
MS5hCj4gPiA+ID4gPj4gQlVTX0lOVEVSRkFDRSBKVEFHUFBDMCA9IGp0YWdwcGNfMF8wCj4gPiA+
ID4gPj4gRU5ECj4gPiA+ID4gPj4KPiA+ID4gPiA+PiBCRUdJTiBwbGJfdjQ2Cj4gPiA+ID4gPj4g
UEFSQU1FVEVSIElOU1RBTkNFID0gcGxiCj4gPiA+ID4gPj4gUEFSQU1FVEVSIENfRENSX0lOVEZD
RSA9IDAKPiA+ID4gPiA+PiBQQVJBTUVURVIgQ19OVU1fQ0xLX1BMQjJPUEJfUkVBUkIgPSAxMDAK
PiA+ID4gPiA+PiBQQVJBTUVURVIgSFdfVkVSID0gMS4wMi5hCj4gPiA+ID4gPj4gUE9SVCBQTEJf
Q2xrID0gc3lzX2Nsa19zCj4gPiA+ID4gPj4gUE9SVCBTWVNfUnN0ID0gc3lzX2J1c19yZXNldAo+
ID4gPiA+ID4+IEVORAo+ID4gPiA+ID4+Cj4gPiA+ID4gPj4gQkVHSU4geHBzX2JyYW1faWZfY250
bHIKPiA+ID4gPiA+PiBQQVJBTUVURVIgSU5TVEFOQ0UgPSB4cHNfYnJhbV9pZl9jbnRscl8xCj4g
PiA+ID4gPj4gUEFSQU1FVEVSIEhXX1ZFUiA9IDEuMDAuYQo+ID4gPiA+ID4+IFBBUkFNRVRFUiBD
X1NQTEJfTkFUSVZFX0RXSURUSCA9IDY0Cj4gPiA+ID4gPj4gUEFSQU1FVEVSIENfQkFTRUFERFIg
PSAweGZmZmZlMDAwCj4gPiA+ID4gPj4gUEFSQU1FVEVSIENfSElHSEFERFIgPSAweGZmZmZmZmZm
Cj4gPiA+ID4gPj4gQlVTX0lOVEVSRkFDRSBTUExCID0gcGxiCj4gPiA+ID4gPj4gQlVTX0lOVEVS
RkFDRSBQT1JUQSA9IHhwc19icmFtX2lmX2NudGxyXzFfcG9ydAo+ID4gPiA+ID4+IEVORAo+ID4g
PiA+ID4+Cj4gPiA+ID4gPj4gQkVHSU4gYnJhbV9ibG9jawo+ID4gPiA+ID4+IFBBUkFNRVRFUiBJ
TlNUQU5DRSA9IHBsYl9icmFtX2lmX2NudGxyXzFfYnJhbQo+ID4gPiA+ID4+IFBBUkFNRVRFUiBI
V19WRVIgPSAxLjAwLmEKPiA+ID4gPiA+PiBCVVNfSU5URVJGQUNFIFBPUlRBID0geHBzX2JyYW1f
aWZfY250bHJfMV9wb3J0Cj4gPiA+ID4gPj4gRU5ECj4gPiA+ID4gPj4KPiA+ID4gPiA+PiBCRUdJ
TiB4cHNfdWFydDE2NTUwCj4gPiA+ID4gPj4gUEFSQU1FVEVSIElOU1RBTkNFID0gUlMyMzJfVWFy
dAo+ID4gPiA+ID4+IFBBUkFNRVRFUiBIV19WRVIgPSAyLjAwLmEKPiA+ID4gPiA+PiBQQVJBTUVU
RVIgQ19JU19BXzE2NTUwID0gMQo+ID4gPiA+ID4+IFBBUkFNRVRFUiBDX0JBU0VBRERSID0gMHg4
M2UwMDAwMAo+ID4gPiA+ID4+IFBBUkFNRVRFUiBDX0hJR0hBRERSID0gMHg4M2UwZmZmZgo+ID4g
PiA+ID4+IEJVU19JTlRFUkZBQ0UgU1BMQiA9IHBsYgo+ID4gPiA+ID4+IFBPUlQgc2luID0gZnBn
YV8wX1JTMjMyX1VhcnRfc2luCj4gPiA+ID4gPj4gUE9SVCBzb3V0ID0gZnBnYV8wX1JTMjMyX1Vh
cnRfc291dAo+ID4gPiA+ID4+IFBPUlQgSVAySU5UQ19JcnB0ID0gUlMyMzJfVWFydF9JUDJJTlRD
X0lycHQKPiA+ID4gPiA+PiBFTkQKPiA+ID4gPiA+Pgo+ID4gPiA+ID4+IEJFR0lOIHhwc19ncGlv
Cj4gPiA+ID4gPj4gUEFSQU1FVEVSIElOU1RBTkNFID0gTEVEc180Qml0Cj4gPiA+ID4gPj4gUEFS
QU1FVEVSIEhXX1ZFUiA9IDEuMDAuYQo+ID4gPiA+ID4+IFBBUkFNRVRFUiBDX0lOVEVSUlVQVF9Q
UkVTRU5UID0gMQo+ID4gPiA+ID4+IFBBUkFNRVRFUiBDX0dQSU9fV0lEVEggPSA0Cj4gPiA+ID4g
Pj4gUEFSQU1FVEVSIENfSVNfRFVBTCA9IDAKPiA+ID4gPiA+PiBQQVJBTUVURVIgQ19JU19CSURJ
UiA9IDEKPiA+ID4gPiA+PiBQQVJBTUVURVIgQ19BTExfSU5QVVRTID0gMAo+ID4gPiA+ID4+IFBB
UkFNRVRFUiBDX0JBU0VBRERSID0gMHg4MTQwMDAwMAo+ID4gPiA+ID4+IFBBUkFNRVRFUiBDX0hJ
R0hBRERSID0gMHg4MTQwZmZmZgo+ID4gPiA+ID4+IEJVU19JTlRFUkZBQ0UgU1BMQiA9IHBsYgo+
ID4gPiA+ID4+IFBPUlQgR1BJT19JTyA9IGZwZ2FfMF9MRURzXzRCaXRfR1BJT19JTwo+ID4gPiA+
ID4+IFBPUlQgSVAySU5UQ19JcnB0ID0gTEVEc180Qml0X0lQMklOVENfSXJwdAo+ID4gPiA+ID4+
IEVORAo+ID4gPiA+ID4+Cj4gPiA+ID4gPj4gQkVHSU4geHBzX2lpYwo+ID4gPiA+ID4+IFBBUkFN
RVRFUiBJTlNUQU5DRSA9IElJQ19FRVBST00KPiA+ID4gPiA+PiBQQVJBTUVURVIgSFdfVkVSID0g
Mi4wMC5hCj4gPiA+ID4gPj4gUEFSQU1FVEVSIENfQ0xLX0ZSRVEgPSAxMDAwMDAwMDAKPiA+ID4g
PiA+PiBQQVJBTUVURVIgQ19JSUNfRlJFUSA9IDEwMDAwMAo+ID4gPiA+ID4+IFBBUkFNRVRFUiBD
X1RFTl9CSVRfQURSID0gMAo+ID4gPiA+ID4+IFBBUkFNRVRFUiBDX0JBU0VBRERSID0gMHg4MTYw
MDAwMAo+ID4gPiA+ID4+IFBBUkFNRVRFUiBDX0hJR0hBRERSID0gMHg4MTYwZmZmZgo+ID4gPiA+
ID4+IEJVU19JTlRFUkZBQ0UgU1BMQiA9IHBsYgo+ID4gPiA+ID4+IFBPUlQgU2NsID0gZnBnYV8w
X0lJQ19FRVBST01fU2NsCj4gPiA+ID4gPj4gUE9SVCBTZGEgPSBmcGdhXzBfSUlDX0VFUFJPTV9T
ZGEKPiA+ID4gPiA+PiBQT1JUIElJQzJJTlRDX0lycHQgPSBJSUNfRUVQUk9NX0lJQzJJTlRDX0ly
cHQKPiA+ID4gPiA+PiBFTkQKPiA+ID4gPiA+Pgo+ID4gPiA+ID4+IEJFR0lOIHhwc19zeXNhY2UK
PiA+ID4gPiA+PiBQQVJBTUVURVIgSU5TVEFOQ0UgPSBTeXNBQ0VfQ29tcGFjdEZsYXNoCj4gPiA+
ID4gPj4gUEFSQU1FVEVSIEhXX1ZFUiA9IDEuMDAuYQo+ID4gPiA+ID4+IFBBUkFNRVRFUiBDX01F
TV9XSURUSCA9IDE2Cj4gPiA+ID4gPj4gUEFSQU1FVEVSIENfQkFTRUFERFIgPSAweDgzNjAwMDAw
Cj4gPiA+ID4gPj4gUEFSQU1FVEVSIENfSElHSEFERFIgPSAweDgzNjBmZmZmCj4gPiA+ID4gPj4g
QlVTX0lOVEVSRkFDRSBTUExCID0gcGxiCj4gPiA+ID4gPj4gUE9SVCBTeXNBQ0VfQ0xLID0gZnBn
YV8wX1N5c0FDRV9Db21wYWN0Rmxhc2hfU3lzQUNFX0NMSwo+ID4gPiA+ID4+IFBPUlQgU3lzQUNF
X01QQSA9IGZwZ2FfMF9TeXNBQ0VfQ29tcGFjdEZsYXNoX1N5c0FDRV9NUEFfc3BsaXQKPiA+ID4g
PiA+PiBQT1JUIFN5c0FDRV9NUEQgPSBmcGdhXzBfU3lzQUNFX0NvbXBhY3RGbGFzaF9TeXNBQ0Vf
TVBECj4gPiA+ID4gPj4gUE9SVCBTeXNBQ0VfQ0VOID0gZnBnYV8wX1N5c0FDRV9Db21wYWN0Rmxh
c2hfU3lzQUNFX0NFTgo+ID4gPiA+ID4+IFBPUlQgU3lzQUNFX09FTiA9IGZwZ2FfMF9TeXNBQ0Vf
Q29tcGFjdEZsYXNoX1N5c0FDRV9PRU4KPiA+ID4gPiA+PiBQT1JUIFN5c0FDRV9XRU4gPSBmcGdh
XzBfU3lzQUNFX0NvbXBhY3RGbGFzaF9TeXNBQ0VfV0VOCj4gPiA+ID4gPj4gUE9SVCBTeXNBQ0Vf
TVBJUlEgPSBmcGdhXzBfU3lzQUNFX0NvbXBhY3RGbGFzaF9TeXNBQ0VfTVBJUlEKPiA+ID4gPiA+
PiBQT1JUIFN5c0FDRV9JUlEgPSBTeXNBQ0VfQ29tcGFjdEZsYXNoX1N5c0FDRV9JUlEKPiA+ID4g
PiA+PiBFTkQKPiA+ID4gPiA+Pgo+ID4gPiA+ID4+IEJFR0lOIG1wbWMKPiA+ID4gPiA+PiBQQVJB
TUVURVIgSU5TVEFOQ0UgPSBERFJfU0RSQU0KPiA+ID4gPiA+PiBQQVJBTUVURVIgSFdfVkVSID0g
NC4wMC5hCj4gPiA+ID4gPj4gUEFSQU1FVEVSIENfTlVNX1BPUlRTID0gMwo+ID4gPiA+ID4+IFBB
UkFNRVRFUiBDX01FTV9QQVJUTk8gPSBIWUIyNUQ1MTIxNjBCRS01Cj4gPiA+ID4gPj4gUEFSQU1F
VEVSIENfTUVNX0RBVEFfV0lEVEggPSAzMgo+ID4gPiA+ID4+IFBBUkFNRVRFUiBDX01FTV9EUVNf
V0lEVEggPSA0Cj4gPiA+ID4gPj4gUEFSQU1FVEVSIENfTUVNX0RNX1dJRFRIID0gNAo+ID4gPiA+
ID4+IFBBUkFNRVRFUiBDX01FTV9UWVBFID0gRERSCj4gPiA+ID4gPj4gUEFSQU1FVEVSIENfTlVN
X0lERUxBWUNUUkwgPSAyCj4gPiA+ID4gPj4gUEFSQU1FVEVSIENfSURFTEFZQ1RSTF9MT0MgPSBJ
REVMQVlDVFJMX1gwWTMtSURFTEFZQ1RSTF9YMFkyCj4gPiA+ID4gPj4gUEFSQU1FVEVSIENfUElN
MF9CQVNFVFlQRSA9IDIKPiA+ID4gPiA+PiBQQVJBTUVURVIgQ19QSU0xX0JBU0VUWVBFID0gMgo+
ID4gPiA+ID4+IFBBUkFNRVRFUiBDX1BJTTJfQkFTRVRZUEUgPSAzCj4gPiA+ID4gPj4gUEFSQU1F
VEVSIENfTVBNQ19DTEswX1BFUklPRF9QUyA9IDEwMDAwCj4gPiA+ID4gPj4gUEFSQU1FVEVSIENf
U0RNQTJfUEkyTExfQ0xLX1JBVElPID0gMQo+ID4gPiA+ID4+IFBBUkFNRVRFUiBDX01QTUNfQkFT
RUFERFIgPSAweDAwMDAwMDAwCj4gPiA+ID4gPj4gUEFSQU1FVEVSIENfTVBNQ19ISUdIQUREUiA9
IDB4MDdmZmZmZmYKPiA+ID4gPiA+PiBQQVJBTUVURVIgQ19TRE1BX0NUUkxfQkFTRUFERFIgPSAw
eDg0NjAwMDAwCj4gPiA+ID4gPj4gUEFSQU1FVEVSIENfU0RNQV9DVFJMX0hJR0hBRERSID0gMHg4
NDYwZmZmZgo+ID4gPiA+ID4+IEJVU19JTlRFUkZBQ0UgU1BMQjAgPSBwcGM0MDVfMF9pcGxiMQo+
ID4gPiA+ID4+IEJVU19JTlRFUkZBQ0UgU1BMQjEgPSBwcGM0MDVfMF9kcGxiMQo+ID4gPiA+ID4+
IEJVU19JTlRFUkZBQ0UgU0RNQV9MTDIgPSBUcmlNb2RlX01BQ19HTUlJX0xMSU5LMAo+ID4gPiA+
ID4+IEJVU19JTlRFUkZBQ0UgU0RNQV9DVFJMMiA9IHBsYgo+ID4gPiA+ID4+IFBPUlQgRERSX0Fk
ZHIgPSBmcGdhXzBfRERSX1NEUkFNX0REUl9BZGRyCj4gPiA+ID4gPj4gUE9SVCBERFJfQmFua0Fk
ZHIgPSBmcGdhXzBfRERSX1NEUkFNX0REUl9CYW5rQWRkcgo+ID4gPiA+ID4+IFBPUlQgRERSX0NB
U19uID0gZnBnYV8wX0REUl9TRFJBTV9ERFJfQ0FTX24KPiA+ID4gPiA+PiBQT1JUIEREUl9DRSA9
IGZwZ2FfMF9ERFJfU0RSQU1fRERSX0NFCj4gPiA+ID4gPj4gUE9SVCBERFJfQ1NfbiA9IGZwZ2Ff
MF9ERFJfU0RSQU1fRERSX0NTX24KPiA+ID4gPiA+PiBQT1JUIEREUl9SQVNfbiA9IGZwZ2FfMF9E
RFJfU0RSQU1fRERSX1JBU19uCj4gPiA+ID4gPj4gUE9SVCBERFJfV0VfbiA9IGZwZ2FfMF9ERFJf
U0RSQU1fRERSX1dFX24KPiA+ID4gPiA+PiBQT1JUIEREUl9ETSA9IGZwZ2FfMF9ERFJfU0RSQU1f
RERSX0RNCj4gPiA+ID4gPj4gUE9SVCBERFJfRFFTID0gZnBnYV8wX0REUl9TRFJBTV9ERFJfRFFT
Cj4gPiA+ID4gPj4gUE9SVCBERFJfRFEgPSBmcGdhXzBfRERSX1NEUkFNX0REUl9EUQo+ID4gPiA+
ID4+IFBPUlQgRERSX0NsayA9IGZwZ2FfMF9ERFJfU0RSQU1fRERSX0Nsawo+ID4gPiA+ID4+IFBP
UlQgRERSX0Nsa19uID0gZnBnYV8wX0REUl9TRFJBTV9ERFJfQ2xrX24KPiA+ID4gPiA+PiBQT1JU
IE1QTUNfQ2xrMCA9IHN5c19jbGtfcwo+ID4gPiA+ID4+IFBPUlQgTVBNQ19DbGs5MCA9IEREUl9T
RFJBTV9tcG1jX2Nsa185MF9zCj4gPiA+ID4gPj4gUE9SVCBTRE1BMl9DbGsgPSBzeXNfY2xrX3MK
PiA+ID4gPiA+PiBQT1JUIE1QTUNfQ2xrXzIwME1IeiA9IGNsa18yMDBtaHpfcwo+ID4gPiA+ID4+
IFBPUlQgTVBNQ19Sc3QgPSBzeXNfcGVyaXBoX3Jlc2V0Cj4gPiA+ID4gPj4gUE9SVCBTRE1BMl9S
eF9JbnRPdXQgPSBERFJfU0RSQU1fU0RNQTJfUnhfSW50T3V0Cj4gPiA+ID4gPj4gUE9SVCBTRE1B
Ml9UeF9JbnRPdXQgPSBERFJfU0RSQU1fU0RNQTJfVHhfSW50T3V0Cj4gPiA+ID4gPj4gRU5ECj4g
PiA+ID4gPj4KPiA+ID4gPiA+PiBCRUdJTiB4cHNfbGxfdGVtYWMKPiA+ID4gPiA+PiBQQVJBTUVU
RVIgSU5TVEFOQ0UgPSBUcmlNb2RlX01BQ19HTUlJCj4gPiA+ID4gPj4gUEFSQU1FVEVSIEhXX1ZF
UiA9IDEuMDEuYQo+ID4gPiA+ID4+IFBBUkFNRVRFUiBDX1NQTEJfQ0xLX1BFUklPRF9QUyA9IDEw
MDAwCj4gPiA+ID4gPj4gUEFSQU1FVEVSIENfUEhZX1RZUEUgPSAxCj4gPiA+ID4gPj4gUEFSQU1F
VEVSIENfTlVNX0lERUxBWUNUUkwgPSA0Cj4gPiA+ID4gPj4gUEFSQU1FVEVSIENfSURFTEFZQ1RS
TF9MT0MgPSBJREVMQVlDVFJMX1gxWTEtSURFTEFZQ1RSTF9YMVkzLQo+ID4gPiA+IElERUxBWUNU
UkxfWDJZMi1JREVMQVlDVFJMX1gyWTMKPiA+ID4gPiA+PiBQQVJBTUVURVIgQ19URU1BQ19UWVBF
ID0gMQo+ID4gPiA+ID4+IFBBUkFNRVRFUiBDX0JVUzJDT1JFX0NMS19SQVRJTyA9IDEKPiA+ID4g
PiA+PiBQQVJBTUVURVIgQ19CQVNFQUREUiA9IDB4ODFjMDAwMDAKPiA+ID4gPiA+PiBQQVJBTUVU
RVIgQ19ISUdIQUREUiA9IDB4ODFjMGZmZmYKPiA+ID4gPiA+PiBCVVNfSU5URVJGQUNFIFNQTEIg
PSBwbGIKPiA+ID4gPiA+PiBCVVNfSU5URVJGQUNFIExMSU5LMCA9IFRyaU1vZGVfTUFDX0dNSUlf
TExJTkswCj4gPiA+ID4gPj4gUE9SVCBHTUlJX1RYRF8wID0gZnBnYV8wX1RyaU1vZGVfTUFDX0dN
SUlfR01JSV9UWERfMAo+ID4gPiA+ID4+IFBPUlQgR01JSV9UWF9FTl8wID0gZnBnYV8wX1RyaU1v
ZGVfTUFDX0dNSUlfR01JSV9UWF9FTl8wCj4gPiA+ID4gPj4gUE9SVCBHTUlJX1RYX0VSXzAgPSBm
cGdhXzBfVHJpTW9kZV9NQUNfR01JSV9HTUlJX1RYX0VSXzAKPiA+ID4gPiA+PiBQT1JUIEdNSUlf
VFhfQ0xLXzAgPSBmcGdhXzBfVHJpTW9kZV9NQUNfR01JSV9HTUlJX1RYX0NMS18wCj4gPiA+ID4g
Pj4gUE9SVCBHTUlJX1JYRF8wID0gZnBnYV8wX1RyaU1vZGVfTUFDX0dNSUlfR01JSV9SWERfMAo+
ID4gPiA+ID4+IFBPUlQgR01JSV9SWF9EVl8wID0gZnBnYV8wX1RyaU1vZGVfTUFDX0dNSUlfR01J
SV9SWF9EVl8wCj4gPiA+ID4gPj4gUE9SVCBHTUlJX1JYX0VSXzAgPSBmcGdhXzBfVHJpTW9kZV9N
QUNfR01JSV9HTUlJX1JYX0VSXzAKPiA+ID4gPiA+PiBQT1JUIEdNSUlfUlhfQ0xLXzAgPSBmcGdh
XzBfVHJpTW9kZV9NQUNfR01JSV9HTUlJX1JYX0NMS18wCj4gPiA+ID4gPj4gUE9SVCBNSUlfVFhf
Q0xLXzAgPSBmcGdhXzBfVHJpTW9kZV9NQUNfR01JSV9NSUlfVFhfQ0xLXzAKPiA+ID4gPiA+PiBQ
T1JUIE1ESU9fMCA9IGZwZ2FfMF9UcmlNb2RlX01BQ19HTUlJX01ESU9fMAo+ID4gPiA+ID4+IFBP
UlQgTURDXzAgPSBmcGdhXzBfVHJpTW9kZV9NQUNfR01JSV9NRENfMAo+ID4gPiA+ID4+IFBPUlQg
VGVtYWNQaHlfUlNUX24gPSBmcGdhXzBfVHJpTW9kZV9NQUNfR01JSV9UZW1hY1BoeV9SU1Rfbgo+
ID4gPiA+ID4+IFBPUlQgR1RYX0NMS18wID0gdGVtYWNfY2xrX3MKPiA+ID4gPiA+PiBQT1JUIFJF
RkNMSyA9IGNsa18yMDBtaHpfcwo+ID4gPiA+ID4+IFBPUlQgTGxpbmtUZW1hYzBfQ0xLID0gc3lz
X2Nsa19zCj4gPiA+ID4gPj4gUE9SVCBUZW1hY0ludGMwX0lycHQgPSBUcmlNb2RlX01BQ19HTUlJ
X1RlbWFjSW50YzBfSXJwdAo+ID4gPiA+ID4+IEVORAo+ID4gPiA+ID4+Cj4gPiA+ID4gPj4gQkVH
SU4gdXRpbF9idXNfc3BsaXQKPiA+ID4gPiA+PiBQQVJBTUVURVIgSU5TVEFOQ0UgPSBTeXNBQ0Vf
Q29tcGFjdEZsYXNoX3V0aWxfYnVzX3NwbGl0XzAKPiA+ID4gPiA+PiBQQVJBTUVURVIgSFdfVkVS
ID0gMS4wMC5hCj4gPiA+ID4gPj4gUEFSQU1FVEVSIENfU0laRV9JTiA9IDcKPiA+ID4gPiA+PiBQ
QVJBTUVURVIgQ19MRUZUX1BPUyA9IDAKPiA+ID4gPiA+PiBQQVJBTUVURVIgQ19TUExJVCA9IDYK
PiA+ID4gPiA+PiBQT1JUIFNpZyA9IGZwZ2FfMF9TeXNBQ0VfQ29tcGFjdEZsYXNoX1N5c0FDRV9N
UEFfc3BsaXQKPiA+ID4gPiA+PiBQT1JUIE91dDEgPSBmcGdhXzBfU3lzQUNFX0NvbXBhY3RGbGFz
aF9TeXNBQ0VfTVBBCj4gPiA+ID4gPj4gRU5ECj4gPiA+ID4gPj4KPiA+ID4gPiA+PiBCRUdJTiBw
bGJfdjQ2Cj4gPiA+ID4gPj4gUEFSQU1FVEVSIElOU1RBTkNFID0gcHBjNDA1XzBfaXBsYjEKPiA+
ID4gPiA+PiBQQVJBTUVURVIgSFdfVkVSID0gMS4wMi5hCj4gPiA+ID4gPj4gUE9SVCBQTEJfQ2xr
ID0gc3lzX2Nsa19zCj4gPiA+ID4gPj4gUE9SVCBTWVNfUnN0ID0gc3lzX2J1c19yZXNldAo+ID4g
PiA+ID4+IEVORAo+ID4gPiA+ID4+Cj4gPiA+ID4gPj4gQkVHSU4gcGxiX3Y0Ngo+ID4gPiA+ID4+
IFBBUkFNRVRFUiBJTlNUQU5DRSA9IHBwYzQwNV8wX2RwbGIxCj4gPiA+ID4gPj4gUEFSQU1FVEVS
IEhXX1ZFUiA9IDEuMDIuYQo+ID4gPiA+ID4+IFBPUlQgUExCX0NsayA9IHN5c19jbGtfcwo+ID4g
PiA+ID4+IFBPUlQgU1lTX1JzdCA9IHN5c19idXNfcmVzZXQKPiA+ID4gPiA+PiBFTkQKPiA+ID4g
PiA+Pgo+ID4gPiA+ID4+IEJFR0lOIGNsb2NrX2dlbmVyYXRvcgo+ID4gPiA+ID4+IFBBUkFNRVRF
UiBJTlNUQU5DRSA9IGNsb2NrX2dlbmVyYXRvcl8wCj4gPiA+ID4gPj4gUEFSQU1FVEVSIEhXX1ZF
UiA9IDIuMDAuYQo+ID4gPiA+ID4+IFBBUkFNRVRFUiBDX0VYVF9SRVNFVF9ISUdIID0gMQo+ID4g
PiA+ID4+IFBBUkFNRVRFUiBDX0NMS0lOX0ZSRVEgPSAxMDAwMDAwMDAKPiA+ID4gPiA+PiBQQVJB
TUVURVIgQ19DTEtPVVQwX0ZSRVEgPSAxMDAwMDAwMDAKPiA+ID4gPiA+PiBQQVJBTUVURVIgQ19D
TEtPVVQwX0JVRiA9IFRSVUUKPiA+ID4gPiA+PiBQQVJBTUVURVIgQ19DTEtPVVQwX1BIQVNFID0g
MAo+ID4gPiA+ID4+IFBBUkFNRVRFUiBDX0NMS09VVDBfR1JPVVAgPSBEQ00wCj4gPiA+ID4gPj4g
UEFSQU1FVEVSIENfQ0xLT1VUMV9GUkVRID0gMTAwMDAwMDAwCj4gPiA+ID4gPj4gUEFSQU1FVEVS
IENfQ0xLT1VUMV9CVUYgPSBUUlVFCj4gPiA+ID4gPj4gUEFSQU1FVEVSIENfQ0xLT1VUMV9QSEFT
RSA9IDkwCj4gPiA+ID4gPj4gUEFSQU1FVEVSIENfQ0xLT1VUMV9HUk9VUCA9IERDTTAKPiA+ID4g
PiA+PiBQQVJBTUVURVIgQ19DTEtPVVQyX0ZSRVEgPSAzMDAwMDAwMDAKPiA+ID4gPiA+PiBQQVJB
TUVURVIgQ19DTEtPVVQyX0JVRiA9IFRSVUUKPiA+ID4gPiA+PiBQQVJBTUVURVIgQ19DTEtPVVQy
X1BIQVNFID0gMAo+ID4gPiA+ID4+IFBBUkFNRVRFUiBDX0NMS09VVDJfR1JPVVAgPSBEQ00wCj4g
PiA+ID4gPj4gUEFSQU1FVEVSIENfQ0xLT1VUM19GUkVRID0gMjAwMDAwMDAwCj4gPiA+ID4gPj4g
UEFSQU1FVEVSIENfQ0xLT1VUM19CVUYgPSBUUlVFCj4gPiA+ID4gPj4gUEFSQU1FVEVSIENfQ0xL
T1VUM19QSEFTRSA9IDAKPiA+ID4gPiA+PiBQQVJBTUVURVIgQ19DTEtPVVQzX0dST1VQID0gTk9O
RQo+ID4gPiA+ID4+IFBBUkFNRVRFUiBDX0NMS09VVDRfRlJFUSA9IDEyNTAwMDAwMAo+ID4gPiA+
ID4+IFBBUkFNRVRFUiBDX0NMS09VVDRfQlVGID0gVFJVRQo+ID4gPiA+ID4+IFBBUkFNRVRFUiBD
X0NMS09VVDRfUEhBU0UgPSAwCj4gPiA+ID4gPj4gUEFSQU1FVEVSIENfQ0xLT1VUNF9HUk9VUCA9
IE5PTkUKPiA+ID4gPiA+PiBQT1JUIENMS09VVDAgPSBzeXNfY2xrX3MKPiA+ID4gPiA+PiBQT1JU
IENMS09VVDEgPSBERFJfU0RSQU1fbXBtY19jbGtfOTBfcwo+ID4gPiA+ID4+IFBPUlQgQ0xLT1VU
MiA9IHByb2NfY2xrX3MKPiA+ID4gPiA+PiBQT1JUIENMS09VVDMgPSBjbGtfMjAwbWh6X3MKPiA+
ID4gPiA+PiBQT1JUIENMS09VVDQgPSB0ZW1hY19jbGtfcwo+ID4gPiA+ID4+IFBPUlQgQ0xLSU4g
PSBkY21fY2xrX3MKPiA+ID4gPiA+PiBQT1JUIExPQ0tFRCA9IERjbV9hbGxfbG9ja2VkCj4gPiA+
ID4gPj4gUE9SVCBSU1QgPSBuZXRfZ25kCj4gPiA+ID4gPj4gRU5ECj4gPiA+ID4gPj4KPiA+ID4g
PiA+PiBCRUdJTiBwcm9jX3N5c19yZXNldAo+ID4gPiA+ID4+IFBBUkFNRVRFUiBJTlNUQU5DRSA9
IHByb2Nfc3lzX3Jlc2V0XzAKPiA+ID4gPiA+PiBQQVJBTUVURVIgSFdfVkVSID0gMi4wMC5hCj4g
PiA+ID4gPj4gUEFSQU1FVEVSIENfRVhUX1JFU0VUX0hJR0ggPSAwCj4gPiA+ID4gPj4gQlVTX0lO
VEVSRkFDRSBSRVNFVFBQQzAgPSBwcGNfcmVzZXRfYnVzCj4gPiA+ID4gPj4gUE9SVCBTbG93ZXN0
X3N5bmNfY2xrID0gc3lzX2Nsa19zCj4gPiA+ID4gPj4gUE9SVCBEY21fbG9ja2VkID0gRGNtX2Fs
bF9sb2NrZWQKPiA+ID4gPiA+PiBQT1JUIEV4dF9SZXNldF9JbiA9IHN5c19yc3Rfcwo+ID4gPiA+
ID4+IFBPUlQgQnVzX1N0cnVjdF9SZXNldCA9IHN5c19idXNfcmVzZXQKPiA+ID4gPiA+PiBQT1JU
IFBlcmlwaGVyYWxfUmVzZXQgPSBzeXNfcGVyaXBoX3Jlc2V0Cj4gPiA+ID4gPj4gRU5ECj4gPiA+
ID4gPj4KPiA+ID4gPiA+PiBCRUdJTiB4cHNfaW50Ywo+ID4gPiA+ID4+IFBBUkFNRVRFUiBJTlNU
QU5DRSA9IHhwc19pbnRjXzAKPiA+ID4gPiA+PiBQQVJBTUVURVIgSFdfVkVSID0gMS4wMC5hCj4g
PiA+ID4gPj4gUEFSQU1FVEVSIENfQkFTRUFERFIgPSAweDgxODAwMDAwCj4gPiA+ID4gPj4gUEFS
QU1FVEVSIENfSElHSEFERFIgPSAweDgxODBmZmZmCj4gPiA+ID4gPj4gQlVTX0lOVEVSRkFDRSBT
UExCID0gcGxiCj4gPiA+ID4gPj4gUE9SVCBJcnEgPSBFSUNDNDA1RVhUSU5QVVRJUlEKPiA+ID4g
PiA+PiBQT1JUIEludHIgPSBSUzIzMl9VYXJ0X0lQMklOVENfSXJwdCAmIExFRHNfNEJpdF9JUDJJ
TlRDX0lycHQgJgo+ID4gPiA+IElJQ19FRVBST01fSUlDMklOVENfSXJwdCAmIFN5c0FDRV9Db21w
YWN0Rmxhc2hfU3lzQUNFX0lSUSAmCj4gPiA+ID4gVHJpTW9kZV9NQUNfR01JSV9UZW1hY0ludGMw
X0lycHQgJiBERFJfU0RSQU1fU0RNQTJfUnhfSW50T3V0ICYKPiA+ID4gPiBERFJfU0RSQU1fU0RN
QTJfVHhfSW50T3V0Cj4gPiA+ID4gPj4gRU5ECj4gPiA+ID4gPj4KPiA+ID4gPiA+Pgo+ID4gPiA+
ID4+Cj4gPiA+ID4gPj4gI2FkZHJlc3MtY2VsbHMgPSA8MT47Cj4gPiA+ID4gPj4gI3NpemUtY2Vs
bHMgPSA8MT47Cj4gPiA+ID4gPj4gY29tcGF0aWJsZSA9ICJ4bG54LHZpcnRleCI7Cj4gPiA+ID4g
Pj4gbW9kZWwgPSAidGVzdGluZyI7Cj4gPiA+ID4gPj4gRERSX1NEUkFNOiBtZW1vcnlAMCB7Cj4g
PiA+ID4gPj4gZGV2aWNlX3R5cGUgPSAibWVtb3J5IjsKPiA+ID4gPiA+PiByZWcgPSA8IDAgODAw
MDAwMCA+Owo+ID4gPiA+ID4+IH0gOwo+ID4gPiA+ID4+IGNob3NlbiB7Cj4gPiA+ID4gPj4gYm9v
dGFyZ3MgPSAiY29uc29sZT10dHlTMCw5NjAwIGlwPW9uCj4gPiA+ID4gbmZzcm9vdD0xNzIuMTYu
NDAuNzY6L3YycGNsaWVudHMvamhsMjYsdGNwIjsKPiA+ID4gPiA+PiBsaW51eCxzdGRvdXQtcGF0
aCA9ICIvcGxiQDAvc2VyaWFsQDgzZTAwMDAwIjsKPiA+ID4gPiA+PiB9IDsKPiA+ID4gPiA+PiBj
cHVzIHsKPiA+ID4gPiA+PiAjYWRkcmVzcy1jZWxscyA9IDwxPjsKPiA+ID4gPiA+PiAjY3B1cyA9
IDwxPjsKPiA+ID4gPiA+PiAjc2l6ZS1jZWxscyA9IDwwPjsKPiA+ID4gPiA+PiBwcGM0MDVfMDog
Y3B1QDAgewo+ID4gPiA+ID4+IGNsb2NrLWZyZXF1ZW5jeSA9IDwxMWUxYTMwMD47Cj4gPiA+ID4g
Pj4gY29tcGF0aWJsZSA9ICJQb3dlclBDLDQwNSIsICJpYm0scHBjNDA1IjsKPiA+ID4gPiA+PiBk
LWNhY2hlLWxpbmUtc2l6ZSA9IDwyMD47Cj4gPiA+ID4gPj4gZC1jYWNoZS1zaXplID0gPDQwMDA+
Owo+ID4gPiA+ID4+IGRldmljZV90eXBlID0gImNwdSI7Cj4gPiA+ID4gPj4gaS1jYWNoZS1saW5l
LXNpemUgPSA8MjA+Owo+ID4gPiA+ID4+IGktY2FjaGUtc2l6ZSA9IDw0MDAwPjsKPiA+ID4gPiA+
PiBtb2RlbCA9ICJQb3dlclBDLDQwNSI7Cj4gPiA+ID4gPj4gcmVnID0gPDA+Owo+ID4gPiA+ID4+
IHRpbWViYXNlLWZyZXF1ZW5jeSA9IDwxMWUxYTMwMD47Cj4gPiA+ID4gPj4geGxueCxhcHUtY29u
dHJvbCA9IDxkZTAwPjsKPiA+ID4gPiA+PiB4bG54LGFwdS11ZGktMSA9IDxhMTg5ODM+Owo+ID4g
PiA+ID4+IHhsbngsYXB1LXVkaS0yID0gPGEzODk4Mz47Cj4gPiA+ID4gPj4geGxueCxhcHUtdWRp
LTMgPSA8YTU4OWMzPjsKPiA+ID4gPiA+PiB4bG54LGFwdS11ZGktNCA9IDxhNzg5YzM+Owo+ID4g
PiA+ID4+IHhsbngsYXB1LXVkaS01ID0gPGE5OGMwMz47Cj4gPiA+ID4gPj4geGxueCxhcHUtdWRp
LTYgPSA8YWI4YzAzPjsKPiA+ID4gPiA+PiB4bG54LGFwdS11ZGktNyA9IDxhZDhjNDM+Owo+ID4g
PiA+ID4+IHhsbngsYXB1LXVkaS04ID0gPGFmOGM0Mz47Cj4gPiA+ID4gPj4geGxueCxkZXRlcm1p
bmlzdGljLW11bHQgPSA8MD47Cj4gPiA+ID4gPj4geGxueCxkaXNhYmxlLW9wZXJhbmQtZm9yd2Fy
ZGluZyA9IDwxPjsKPiA+ID4gPiA+PiB4bG54LGZhc3Rlc3QtcGxiLWNsb2NrID0gIkRQTEIwIjsK
PiA+ID4gPiA+PiB4bG54LGdlbmVyYXRlLXBsYi10aW1lc3BlY3MgPSA8MT47Cj4gPiA+ID4gPj4g
eGxueCxtbXUtZW5hYmxlID0gPDE+Owo+ID4gPiA+ID4+IHhsbngscHZyLWhpZ2ggPSA8MD47Cj4g
PiA+ID4gPj4geGxueCxwdnItbG93ID0gPDA+Owo+ID4gPiA+ID4+IH0gOwo+ID4gPiA+ID4+IH0g
Owo+ID4gPiA+ID4+IHBsYjogcGxiQDAgewo+ID4gPiA+ID4+ICNhZGRyZXNzLWNlbGxzID0gPDE+
Owo+ID4gPiA+ID4+ICNzaXplLWNlbGxzID0gPDE+Owo+ID4gPiA+ID4+IGNvbXBhdGlibGUgPSAi
eGxueCxwbGItdjQ2LTEuMDIuYSI7Cj4gPiA+ID4gPj4gcmFuZ2VzIDsKPiA+ID4gPiA+PiBJSUNf
RUVQUk9NOiBpMmNAODE2MDAwMDAgewo+ID4gPiA+ID4+IGNvbXBhdGlibGUgPSAieGxueCx4cHMt
aWljLTIuMDAuYSI7Cj4gPiA+ID4gPj4gaW50ZXJydXB0LXBhcmVudCA9IDwmeHBzX2ludGNfMD47
Cj4gPiA+ID4gPj4gaW50ZXJydXB0cyA9IDwgNCAyID47Cj4gPiA+ID4gPj4gcmVnID0gPCA4MTYw
MDAwMCAxMDAwMCA+Owo+ID4gPiA+ID4+IHhsbngsY2xrLWZyZXEgPSA8NWY1ZTEwMD47Cj4gPiA+
ID4gPj4geGxueCxmYW1pbHkgPSAidmlydGV4NCI7Cj4gPiA+ID4gPj4geGxueCxncG8td2lkdGgg
PSA8MT47Cj4gPiA+ID4gPj4geGxueCxpaWMtZnJlcSA9IDwxODZhMD47Cj4gPiA+ID4gPj4geGxu
eCxzY2wtaW5lcnRpYWwtZGVsYXkgPSA8MD47Cj4gPiA+ID4gPj4geGxueCxzZGEtaW5lcnRpYWwt
ZGVsYXkgPSA8MD47Cj4gPiA+ID4gPj4geGxueCx0ZW4tYml0LWFkciA9IDwwPjsKPiA+ID4gPiA+
PiB9IDsKPiA+ID4gPiA+PiBMRURzXzRCaXQ6IGdwaW9AODE0MDAwMDAgewo+ID4gPiA+ID4+IGNv
bXBhdGlibGUgPSAieGxueCx4cHMtZ3Bpby0xLjAwLmEiOwo+ID4gPiA+ID4+IGludGVycnVwdC1w
YXJlbnQgPSA8Jnhwc19pbnRjXzA+Owo+ID4gPiA+ID4+IGludGVycnVwdHMgPSA8IDUgMiA+Owo+
ID4gPiA+ID4+IHJlZyA9IDwgODE0MDAwMDAgMTAwMDAgPjsKPiA+ID4gPiA+PiB4bG54LGFsbC1p
bnB1dHMgPSA8MD47Cj4gPiA+ID4gPj4geGxueCxhbGwtaW5wdXRzLTIgPSA8MD47Cj4gPiA+ID4g
Pj4geGxueCxkb3V0LWRlZmF1bHQgPSA8MD47Cj4gPiA+ID4gPj4geGxueCxkb3V0LWRlZmF1bHQt
MiA9IDwwPjsKPiA+ID4gPiA+PiB4bG54LGZhbWlseSA9ICJ2aXJ0ZXg0IjsKPiA+ID4gPiA+PiB4
bG54LGdwaW8td2lkdGggPSA8ND47Cj4gPiA+ID4gPj4geGxueCxpbnRlcnJ1cHQtcHJlc2VudCA9
IDwxPjsKPiA+ID4gPiA+PiB4bG54LGlzLWJpZGlyID0gPDE+Owo+ID4gPiA+ID4+IHhsbngsaXMt
YmlkaXItMiA9IDwxPjsKPiA+ID4gPiA+PiB4bG54LGlzLWR1YWwgPSA8MD47Cj4gPiA+ID4gPj4g
eGxueCx0cmktZGVmYXVsdCA9IDxmZmZmZmZmZj47Cj4gPiA+ID4gPj4geGxueCx0cmktZGVmYXVs
dC0yID0gPGZmZmZmZmZmPjsKPiA+ID4gPiA+PiB9IDsKPiA+ID4gPiA+PiBSUzIzMl9VYXJ0OiBz
ZXJpYWxAODNlMDAwMDAgewo+ID4gPiA+ID4+IGNvbXBhdGlibGUgPSAieGxueCx4cHMtdWFydDE2
NTUwLTIuMDAuYSI7Cj4gPiA+ID4gPj4gLy8gY29tcGF0aWJsZSA9ICJuczE2NTUwIjsKPiA+ID4g
PiA+PiBkZXZpY2VfdHlwZSA9ICJzZXJpYWwiOwo+ID4gPiA+ID4+IGludGVycnVwdC1wYXJlbnQg
PSA8Jnhwc19pbnRjXzA+Owo+ID4gPiA+ID4+IGludGVycnVwdHMgPSA8IDYgMiA+Owo+ID4gPiA+
ID4+IHJlZyA9IDwgODNlMDAwMDAgMTAwMDAgPjsKPiA+ID4gPiA+PiBjdXJyZW50LXNwZWVkID0g
PGQjOTYwMD47Cj4gPiA+ID4gPj4gY2xvY2stZnJlcXVlbmN5ID0gPGQjMTAwMDAwMDAwPjsgLyog
YWRkZWQKPiA+ID4gPiBieSBqaGwgKi8KPiA+ID4gPiA+PiByZWctc2hpZnQgPSA8Mj47Cj4gPiA+
ID4gPj4geGxueCxmYW1pbHkgPSAidmlydGV4NCI7Cj4gPiA+ID4gPj4geGxueCxoYXMtZXh0ZXJu
YWwtcmNsayA9IDwwPjsKPiA+ID4gPiA+PiB4bG54LGhhcy1leHRlcm5hbC14aW4gPSA8MD47Cj4g
PiA+ID4gPj4geGxueCxpcy1hLTE2NTUwID0gPDE+Owo+ID4gPiA+ID4+IH0gOwo+ID4gPiA+ID4+
IFN5c0FDRV9Db21wYWN0Rmxhc2g6IHN5c2FjZUA4MzYwMDAwMCB7Cj4gPiA+ID4gPj4gY29tcGF0
aWJsZSA9ICJ4bG54LHhwcy1zeXNhY2UtMS4wMC5hIjsKPiA+ID4gPiA+PiBpbnRlcnJ1cHQtcGFy
ZW50ID0gPCZ4cHNfaW50Y18wPjsKPiA+ID4gPiA+PiBpbnRlcnJ1cHRzID0gPCAzIDIgPjsKPiA+
ID4gPiA+PiByZWcgPSA8IDgzNjAwMDAwIDEwMDAwID47Cj4gPiA+ID4gPj4geGxueCxmYW1pbHkg
PSAidmlydGV4NCI7Cj4gPiA+ID4gPj4geGxueCxtZW0td2lkdGggPSA8MTA+Owo+ID4gPiA+ID4+
IH0gOwo+ID4gPiA+ID4+IFRyaU1vZGVfTUFDX0dNSUk6IHhwcy1sbC10ZW1hY0A4MWMwMDAwMCB7
Cj4gPiA+ID4gPj4gI2FkZHJlc3MtY2VsbHMgPSA8MT47Cj4gPiA+ID4gPj4gI3NpemUtY2VsbHMg
PSA8MT47Cj4gPiA+ID4gPj4gY29tcGF0aWJsZSA9ICJ4bG54LGNvbXBvdW5kIjsKPiA+ID4gPiA+
PiBldGhlcm5ldEA4MWMwMDAwMCB7Cj4gPiA+ID4gPj4gY29tcGF0aWJsZSA9ICJ4bG54LHhwcy1s
bC10ZW1hYy0KPiA+ID4gPiAxLjAxLmEiOwo+ID4gPiA+ID4+IGRldmljZV90eXBlID0gIm5ldHdv
cmsiOwo+ID4gPiA+ID4+IGludGVycnVwdC1wYXJlbnQgPQo+ID4gPiA+IDwmeHBzX2ludGNfMD47
Cj4gPiA+ID4gPj4gaW50ZXJydXB0cyA9IDwgMiAyID47Cj4gPiA+ID4gPj4gbGxpbmstY29ubmVj
dGVkID0gPCZQSU0yPjsKPiA+ID4gPiA+PiBsb2NhbC1tYWMtYWRkcmVzcyA9IFsgMDIgMDAgMDAK
PiA+ID4gPiAwMCAwMCAwMSBdOwo+ID4gPiA+ID4+IHJlZyA9IDwgODFjMDAwMDAgNDAgPjsKPiA+
ID4gPiA+PiB4bG54LGJ1czJjb3JlLWNsay1yYXRpbyA9IDwxPjsKPiA+ID4gPiA+PiB4bG54LHBo
eS10eXBlID0gPDE+Owo+ID4gPiA+ID4+IHhsbngscGh5YWRkciA9IDwxPjsKPiA+ID4gPiA+PiB4
bG54LHJ4Y3N1bSA9IDwwPjsKPiA+ID4gPiA+PiB4bG54LHJ4ZmlmbyA9IDwxMDAwPjsKPiA+ID4g
PiA+PiB4bG54LHRlbWFjLXR5cGUgPSA8MT47Cj4gPiA+ID4gPj4geGxueCx0eGNzdW0gPSA8MD47
Cj4gPiA+ID4gPj4geGxueCx0eGZpZm8gPSA8MTAwMD47Cj4gPiA+ID4gPj4gfSA7Cj4gPiA+ID4g
Pj4gfSA7Cj4gPiA+ID4gPj4gbXBtY0AwIHsKPiA+ID4gPiA+PiAjYWRkcmVzcy1jZWxscyA9IDwx
PjsKPiA+ID4gPiA+PiAjc2l6ZS1jZWxscyA9IDwxPjsKPiA+ID4gPiA+PiBjb21wYXRpYmxlID0g
InhsbngsbXBtYy00LjAwLmEiOwo+ID4gPiA+ID4+IFBJTTI6IHNkbWFAODQ2MDAxMDAgewo+ID4g
PiA+ID4+IGNvbXBhdGlibGUgPSAieGxueCxsbC1kbWEtCj4gPiA+ID4gMS4wMC5hIjsKPiA+ID4g
PiA+PiBpbnRlcnJ1cHQtcGFyZW50ID0KPiA+ID4gPiA8Jnhwc19pbnRjXzA+Owo+ID4gPiA+ID4+
IGludGVycnVwdHMgPSA8IDEgMiAwIDIgPjsKPiA+ID4gPiA+PiByZWcgPSA8IDg0NjAwMTAwIDgw
ID47Cj4gPiA+ID4gPj4gfSA7Cj4gPiA+ID4gPj4gfSA7Cj4gPiA+ID4gPj4geHBzX2JyYW1faWZf
Y250bHJfMTogeHBzLWJyYW0taWYtY250bHJAZmZmZmUwMDAgewo+ID4gPiA+ID4+IGNvbXBhdGli
bGUgPSAieGxueCx4cHMtYnJhbS1pZi1jbnRsci0KPiA+ID4gPiAxLjAwLmEiOwo+ID4gPiA+ID4+
IHJlZyA9IDwgZmZmZmUwMDAgMjAwMCA+Owo+ID4gPiA+ID4+IHhsbngsZmFtaWx5ID0gInZpcnRl
eDQiOwo+ID4gPiA+ID4+IH0gOwo+ID4gPiA+ID4+IHhwc19pbnRjXzA6IGludGVycnVwdC1jb250
cm9sbGVyQDgxODAwMDAwIHsKPiA+ID4gPiA+PiAjaW50ZXJydXB0LWNlbGxzID0gPDI+Owo+ID4g
PiA+ID4+IGNvbXBhdGlibGUgPSAieGxueCx4cHMtaW50Yy0xLjAwLmEiOwo+ID4gPiA+ID4+IGlu
dGVycnVwdC1jb250cm9sbGVyIDsKPiA+ID4gPiA+PiByZWcgPSA8IDgxODAwMDAwIDEwMDAwID47
Cj4gPiA+ID4gPj4geGxueCxudW0taW50ci1pbnB1dHMgPSA8Nz47Cj4gPiA+ID4gPj4gfSA7Cj4g
PiA+ID4gPj4gfSA7Cj4gPiA+ID4gPj4gcHBjNDA1XzBfZHBsYjE6IHBsYkAxIHsKPiA+ID4gPiA+
PiAjYWRkcmVzcy1jZWxscyA9IDwxPjsKPiA+ID4gPiA+PiAjc2l6ZS1jZWxscyA9IDwxPjsKPiA+
ID4gPiA+PiBjb21wYXRpYmxlID0gInhsbngscGxiLXY0Ni0xLjAyLmEiOwo+ID4gPiA+ID4+IHJh
bmdlcyA7Cj4gPiA+ID4gPj4gfSA7Cj4gPiA+ID4gPj4gfSA7Cj4gPiA+ID4gPj4KPiA+ID4gPiA+
Pgo+ID4gPiA+ID4+Cj4gPiA+ID4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPiA+ID4g
PiA+PiBGcm9tOiBNYWdudXMgSGpvcnRoIFttYWlsdG86bWhAb21uaXN5cy5zZV0KPiA+ID4gPiA+
PiBTZW50OiBTYXR1cmRheSwgTWFyY2ggMjksIDIwMDggNjo1NCBBTQo+ID4gPiA+ID4+IFRvOiBn
aXQKPiA+ID4gPiA+PiBDYzogbGludXhwcGMtZW1iZWRkZWRAb3psYWJzLm9yZwo+ID4gPiA+ID4+
IFN1YmplY3Q6IFhpbGlueCBMTFRFTUFDIGRyaXZlciBpc3N1ZXMKPiA+ID4gPiA+Pgo+ID4gPiA+
ID4+IEhpLAo+ID4gPiA+ID4+Cj4gPiA+ID4gPj4gSSdtIGhhdmluZyBzb21lIG5ldHdvcmtpbmcg
dHJvdWJsZXMgd2l0aCB0aGUgWGlsaW54IExMVEVNQUMgZHJpdmVyCj4gZnJvbQo+ID4gPiB0aGUK
PiA+ID4gPiA+PiBYaWxpbnggTGludXggZ2l0IHRyZWUgKHBvd2VycGMgYXJjaCkgb24gYW4gTUw0
MDMgYm9hcmQuIEVESzkuMlNQMiwKPiA+ID4gPiA+PiB4cHNfbGxfdGVtYWMgdjEuMDAuYgo+ID4g
PiA+ID4+Cj4gPiA+ID4gPj4gVGhlIHdlaXJkIHRoaW5nIGlzLCB0aGF0IGl0IHNvcnQgb2YgaGFs
ZiB3b3Jrcy4gSXQgc3VjY2Vzc2Z1bGx5Cj4gbWFrZXMgYQo+ID4gPiBESENQCj4gPiA+ID4gPj4g
cmVxdWVzdCBhbmQgZ2V0cyBpdHMgSVAgYWRkcmVzcy4gSSB0cmllZCBzZXR0aW5nIHVwIGEgdGZ0
cGQgc2VydmVyLAo+IGFuZAo+ID4gPiBJIGNhbgo+ID4gPiA+ID4+IHNlZSBVRFAgcmVxdWVzdHMg
Y29taW5nIGluIGJ1dCB0aGUgcmVzcG9uc2UgZG9lc24ndCBzZWVtIHRvIGNvbWUKPiBvdXQuIEkK
PiA+ID4gYWxzbwo+ID4gPiA+ID4+IHRyaWVkIHJ1bm5pbmcgYSBUQ1Agc2VydmVyIG9uIHRoZSBi
b2FyZCwgYW5kIGl0IGNhbiBzZWUgYW5kIGFjY2VwdAo+ID4gPiBpbmNvbWluZwo+ID4gPiA+ID4+
IGNvbm5lY3Rpb25zIGJ1dCBhZnRlciB0aGF0IG5vIGRhdGEgc2VlbXMgdG8gZ2V0IHRocm91Z2gu
IEkgY2FuIHBpbmcKPiBvdXQKPiA+ID4gYW5kCj4gPiA+ID4gPj4gZ2V0IGFyb3VuZCA0MCUgcGFj
a2V0IGxvc3MuCj4gPiA+ID4gPj4KPiA+ID4gPiA+PiBMb29raW5nIGF0IC9wcm9jL2ludGVycnVw
dHMsIEkgY2FuIHNlZSBib3RoIFR4RG1hIGludGVycnVwdHMgYW5kCj4gUnhEbWEKPiA+ID4gPiA+
PiBpbnRlcnJ1cHRzLiBObyBldGgwIGludGVycnVwdHMgYnV0IHRoYXQgc2VlbXMgdG8gYmUgT0sg
anVkZ2luZyBieQo+IHRoZQo+ID4gPiBkcml2ZXIKPiA+ID4gPiA+PiBzb3VyY2UgY29tbWVudHMu
IElmY29uZmlnIHNob3dzIG5vIGNvbGxpc3Rpb25zLCBubyBkcm9wcGVkIHBhY2tldHMsCj4gbm8K
PiA+ID4gPiBlcnJvcnMsCj4gPiA+ID4gPj4gc28gdGhlIHN5c3RlbSBzZWVtcyB0byB0aGluayB0
aGF0IGV2ZXJ5dGhpbmcgaXMgT0suCj4gPiA+ID4gPj4KPiA+ID4gPiA+PiBDbHVlcyBhbnlvbmU/
IEknbSBzdGFydGluZyB0byBydW4gb3V0IG9mIGlkZWFzLi4uCj4gPiA+ID4gPj4KPiA+ID4gPiA+
PiBCZXN0IHJlZ2FyZHMsCj4gPiA+ID4gPj4gTWFnbnVzCj4gPiA+ID4gPj4KPiA+ID4gPiA+Pgo+
ID4gPiA+ID4+IC0tCj4gPiA+ID4gPj4KPiA+ID4gPiA+PiBNYWdudXMgSGpvcnRoLCBNLlNjLgo+
ID4gPiA+ID4+IE9tbmlzeXMgSW5zdHJ1bWVudHMgQUIKPiA+ID4gPiA+PiBHcnV2Z2F0YW4gOAo+
ID4gPiA+ID4+IFNFLTQyMSAzMCBWw6RzdHJhIEZyw7ZsdW5kYSwgU1dFREVOCj4gPiA+ID4gPj4g
UGhvbmU6ICs0NiAzMSA3MzQgMzQgMDkKPiA+ID4gPiA+PiBGYXg6ICs0NiAzMSA3MzQgMzQgMjkK
PiA+ID4gPiA+PiBodHRwOi8vd3d3Lm9tbmlzeXMuc2UKPiA+ID4gPiA+Pgo+ID4gPiA+ID4KPiA+
ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4g
PiA+ID4gPiBMaW51eHBwYy1lbWJlZGRlZCBtYWlsaW5nIGxpc3QKPiA+ID4gPiA+IExpbnV4cHBj
LWVtYmVkZGVkQG96bGFicy5vcmcKPiA+ID4gPiA+IGh0dHBzOi8vb3psYWJzLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL2xpbnV4cHBjLWVtYmVkZGVkCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fCj4gPiA+IExpbnV4cHBjLWVtYmVkZGVkIG1haWxpbmcg
bGlzdAo+ID4gPiBMaW51eHBwYy1lbWJlZGRlZEBvemxhYnMub3JnCj4gPiA+IGh0dHBzOi8vb3ps
YWJzLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4cHBjLWVtYmVkZGVkCj4gPiA+Cj4gPiA+Cj4g
PiA+IC0tCj4gPiA+IEpvaGFubiBCYXVkeQo+ID4gPiBqb2hhYWhuQGdtYWlsLmNvbQo+ID4gPiBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+ID4gPiDnlKggV2luZG93cyBMaXZlIFNw
YWNlcyDlsZXnpLrkuKrmgKfoh6rmiJHvvIzkuI7lpb3lj4vliIbkuqvnlJ/mtLvvvIEg5LqG6Kej
5pu05aSa5L+h5oGv77yBCj4gPgo+ID4KPiA+Cj4gPiAtLQo+ID4gSm9oYW5uIEJhdWR5Cj4gPiBq
b2hhYWhuQGdtYWlsLmNvbQo+Cj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+
IOeUqCBXaW5kb3dzIExpdmUgU3BhY2VzIOWxleekuuS4quaAp+iHquaIke+8jOS4juWlveWPi+WI
huS6q+eUn+a0u++8gSDkuobop6Pmm7TlpJrkv6Hmga/vvIEKCgoKLS0gCkpvaGFubiBCYXVkeQpq
b2hhYWhuQGdtYWlsLmNvbQo=
^ permalink raw reply
* Re: [PATCH] Add idle wait support for 44x platforms
From: Josh Boyer @ 2008-04-04 11:47 UTC (permalink / raw)
To: jyoung5; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <1207289558.6971.15.camel@thinkpadL>
On Fri, 04 Apr 2008 01:12:38 -0500
Jerone Young <jyoung5@us.ibm.com> wrote:
> >
> > > +static int current_mode = 0;
> >
> > Leave this as: static int current_mode;, so it'll end up in the bss
>
> The problem here is that this defines the default case. Is there really
> a benefit having this in bss ?
It's still defined to 0 if it's in the BSS, as that is all initialized
to 0.
josh
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox