* 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
* Re: Please pull linux-2.6-mpc52xx.git
From: Bartlomiej Sieka @ 2008-04-04 11:13 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <47F22C9A.4050501@semihalf.com>
Bartlomiej Sieka wrote:
> Hi Grant,
>
> Grant Likely wrote:
>> On Tue, Mar 25, 2008 at 11:38 AM, Bartlomiej Sieka <tur@semihalf.com>
>> wrote:
>>> Grant Likely wrote:
>>> > The one part that I have a really strong opinion on is that there
>>> > should be a full featured mpc5200 defconfig for build testing.
>>> Beyond
>>> > that (and if ojn can also be appeased) I can probably be
>>> convinced. :-)
>>>
>>> Hi Grant,
>>>
>>> How to deal with a situation where I need a particular PHY driver from
>>> libphy compiled in the kernel for one of the MPC5200 boards? Adding it
>>> to mpc5200_defconfig doesn't seem like a right thing to do.
>>
>> Why not? mpc5200_defconfig is all about compile and runtime testing
>> on many platforms to make sure drivers play well together. I have no
>> problem adding more drivers to the mpc5200 defconfig. (In fact, I
>> encourage it).
>>
>>> How to
>>> convince you (and appease ojn) to accept a patch that adds a
>>> board-specific defconfig that only slightly differs from
>>> mpc5200_defconfig? :)
>>
>> 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:
>
> arch/powerpc/configs/tqm5200_opt_defconfig
> arch/powerpc/configs/motionpro_opt_defconfig
>
> Or, to signify what is the base defconfig:
>
> arch/powerpc/configs/mpc5200_tqm5200_defconfig
> arch/powerpc/configs/mpc5200_motionpro_defconfig
>
> or even:
>
> arch/powerpc/configs/mpc5200_opt_tqm5200_defconfig
> arch/powerpc/configs/mpc5200_opt_motionpro_defconfig
>
> Would patch adding an optimized _defconfig along these lines be accepted?
Grant,
Any thoughts on the above?
Regards,
Bartlomiej
^ permalink raw reply
* RE: Xilinx LLTEMAC driver issues
From: MingLiu @ 2008-04-04 10:11 UTC (permalink / raw)
To: Johann Baudy; +Cc: John Linn, git, linuxppc-embedded
In-Reply-To: <7e0dd21a0804040253o938b00bnfe2bf89f39950782@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 30378 bytes --]
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
_________________________________________________________________
多个邮箱同步管理，live mail客户端万人抢用中
http://get.live.cn/product/mail.html
[-- Attachment #2: Type: text/html, Size: 44869 bytes --]
^ permalink raw reply
* Re: Xilinx LLTEMAC driver issues
From: Johann Baudy @ 2008-04-04 9:53 UTC (permalink / raw)
To: MingLiu; +Cc: John Linn, git, linuxppc-embedded
In-Reply-To: <BAY138-W323AC0BF7098709A16725DB2F60@phx.gbl>
SGkgTWluZywKCkkndmUgYWxyZWFkeSB1c2VkIG5ldHBlcmYgKHdpdGhvdXQgTkZTKSBzdWNjZXNz
ZnVsbHkuCkFyZSB5b3UgdXNpbmcgMS4wMC5iIGFuZCA5LjIsIGlmIHllcyBsb29rIGF0ICBBUiAj
Mjk3MDguCgpCZXN0IHJlZ2FyZHMsCkpvaGFubgoKT24gRnJpLCBBcHIgNCwgMjAwOCBhdCA5OjM2
IEFNLCBNaW5nTGl1IDxlZW1pbmdsaXVAaG90bWFpbC5jb20+IHdyb3RlOgo+Cj4gIERlYXIgSm9o
YW5uLAo+ICBQcmV2aW91c2x5IEkgc2FpZCB0aGlzIHBhdGNoIGhlbHBzIGZvciB0aGUgY2hlY2tz
dW0gZXJyb3IgcHJvYmxlbS4gQnV0IG5vdwo+IEkgZm91bmQgc29tZSBuZXcgaXNzdWVzLiBZZXMu
IGF0IGxlYXN0IHdpdGggdGhpcyBwYXRjaCwgc29tZXRoaW5nIGlzIGJldHRlcgo+IGFuZCBhdCBs
ZWFzdCB3ZSBjYW4gdXNlIHRoZSBoYXJkd2FyZSBjaGVja3N1bSBvZmZsb2FkaW5nIHRvIGRvIHNv
bWV0aGluZywKPiBmb3IgZXhhbXBsZSBJIGNhbiBtb3VudCB0aGUgTkZTIHJvb3QgZmlsZSBzeXN0
ZW0uIEhvd2V2ZXIgd2hlbiBJIHRyeSB0bwo+IG1lYXN1cmUgdGhlIGV0aGVybmV0IGJhbmR3aWR0
aCB3aXRoIG5ldHBlcmYsIHNvbWV0aGluZyBnb2VzIHdyb25nIGFuZCB0aGUKPiBORlMgbW91bnQg
d2lsbCBiZSBicm9rZW4uIEkgZ3Vlc3MgdGhpcyBpcyBiZWNhdXNlIG9mIHRoZSBsYXJnZSBidWxr
IGRhdGEKPiB0cmFuc2ZlciBhbmQgbWF5YmUgdGh1cyBpdCB0cmlnZ2VycyB0aGUgY2hlY2tzdW0g
cHJvYmxlbSB0byBoYXBwZW4uCj4KPiAgRG8geW91IGhhdmUgdGhlIHNhbWUgc2l0dWF0aW9uPyBP
ciBzb21lb25lIGVsc2UgaGFzIHRoZSBzYW1lIHByb2JsZW0/IEkKPiB3aWxsIGFwcHJlY2lhdGUg
aWYgeW91IGNhbiBzaGFyZSB5b3VyIGV4cGVyaWVuY2UuIFRoYW5rcyBhIGxvdC4KPgo+ICBCUgo+
ICBNaW5nCj4KPgo+Cj4gIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gIERhdGU6
IFdlZCwgMiBBcHIgMjAwOCAwNzoyMDo0MyArMDAwMAo+IEZyb206IGpvaGFhaG5AZ21haWwuY29t
Cj4gVG86IG1oQG9tbmlzeXMuc2UKPgo+IFN1YmplY3Q6IFJlOiBYaWxpbnggTExURU1BQyBkcml2
ZXIgaXNzdWVzCj4gQ0M6IGxpbnV4cHBjLWVtYmVkZGVkQG96bGFicy5vcmc7IEpvaG4uTGlubkB4
aWxpbnguY29tOyBnaXRAeGlsaW54LmNvbQo+Cj4KPgo+IEkndmUgc29sdmVkIHRoaXMgY2hlY2tz
dW0gb2ZmbG9hZGluZyBpc3N1ZSB3aXRoIHRoaXMgYmVsb3cgcGF0Y2guCj4gSXQgbWF5IGhlbHAs
IGlmIHlvdSBuZWVkIHBlcmZvcm1hbmNlLiBJdCBjZXJ0YWlubHkgbmVlZHMgcmV2aWV3IGJ1dCBp
dCB3b3Jrcwo+IG9uIG15IHNpZGUuCj4KPiAtLS0geGlsaW54Z2l0L2RyaXZlcnMvbmV0L3hpbGlu
eAo+IF9sbHRlbWFjL3hsbHRlbWFjX21haW4uYy5vcmlnICAgIDIwMDgtMDMtMjEgMDk6MTE6NDMu
MDAwMDAwMDAwICswMTAwCj4gKysrIHhpbGlueGdpdC9kcml2ZXJzL25ldC94aWxpbnhfbGx0ZW1h
Yy94bGx0ZW1hY19tYWluLmMgICAgMjAwOC0wMy0yMQo+IDA5OjI0OjIzLjAwMDAwMDAwMCArMDEw
MAo+IEBAIC0xMzMsNyArMTMzLDcgQEAKPiAgICAgICAgICAoWExsRG1hX21CZFJlYWQoKEJkUHRy
KSwgWExMRE1BX0JEX1NUU0NUUkxfVVNSMF9PRkZTRVQpKSAmCj4gMHhGRkZGRkZGRSApCj4KPiAg
I2RlZmluZSBCZENzdW1TZXR1cChCZFB0ciwgU3RhcnQsIEluc2VydCkgXAo+IC0gICAgWExsRG1h
X21CZFdyaXRlKChCZFB0ciksIFhMTERNQV9CRF9VU1IxX09GRlNFVCwgKFN0YXJ0KSA8PCAxNiB8
Cj4gKEluc2VydCkpCj4gKyAgICBYTGxEbWFfbUJkV3JpdGUoKEJkUHRyKSwgWExMRE1BX0JEX1VT
UjFfT0ZGU0VULCAoKFN0YXJ0KSA8PCAxNikgfAo+IChJbnNlcnQpKQo+Cj4gIC8qIFVzZWQgZm9y
IGRlYnVnZ2luZyAqLwo+ICAjZGVmaW5lIEJkQ3N1bUluc2VydChCZFB0cikgXAo+IEBAIC0xNTQw
LDcgKzE1NDEsNyBAQCBzdGF0aWMgaW50IHhlbmV0X0RtYVNlbmRfaW50ZXJuYWwoc3RydWN0Cj4g
ICAgICAvKgo+ICAgICAgICogaWYgdHggY2hlY2tzdW0gb2ZmbG9hZGluZyBpcyBlbmFibGVkLCB3
aGVuIHRoZSBldGhlcm5ldCBzdGFjawo+ICAgICAgICogd2FudHMgdXMgdG8gcGVyZm9ybSB0aGUg
Y2hlY2tzdW0gaW4gaGFyZHdhcmUsCj4gLSAgICAgKiBza2ItPmlwX3N1bW1lZCBpcyBDSEVDS1NV
TV9DT01QTEVURS4gT3RoZXJ3aXNlIHNrYi0+aXBfc3VtbWVkIGlzCj4gKyAgICAgKiBza2ItPmlw
X3N1bW1lZCBpcyBDSEVDS1NVTV9QQVJUSUFMLiBPdGhlcndpc2Ugc2tiLT5pcF9zdW1tZWQgaXMK
PiAgICAgICAqIENIRUNLU1VNX05PTkUsIG1lYW5pbmcgdGhlIGNoZWNrc3VtIGlzIGFscmVhZHkg
ZG9uZSwgb3IKPiAgICAgICAqIENIRUNLU1VNX1VOTkVDRVNTQVJZLCBtZWFuaW5nIGNoZWNrc3Vt
bWluZyBpcyB0dXJuZWQgb2ZmIChlLmcuCj4gICAgICAgKiBsb29wYmFjayBpbnRlcmZhY2UpCj4g
QEAgLTE1NjUsOSArMTU2NiwxMSBAQCBzdGF0aWMgaW50IHhlbmV0X0RtYVNlbmRfaW50ZXJuYWwo
c3RydWN0Cj4gICAgICAgKiBza2JfdHJhbnNwb3J0X2hlYWRlcihza2IpIHBvaW50cyB0byB0aGUg
YmVnaW5uaW5nIG9mIHRoZSBpcCBoZWFkZXIKPiAgICAgICAqCj4gICAgICAgKi8KPiAtICAgIGlm
IChza2ItPmlwX3N1bW1lZCA9PSBDSEVDS1NVTV9DT01QTEVURSkgewo+ICsgICAgaWYgKHNrYi0+
aXBfc3VtbWVkID09IENIRUNLU1VNX1BBUlRJQUwpIHsKPiArCj4gKyAgICAgICAgdW5zaWduZWQg
aW50IGNzdW1fc3RhcnRfb2ZmID0gc2tiX3RyYW5zcG9ydF9vZmZzZXQoc2tiKTsKPiArICAgICAg
ICB1bnNpZ25lZCBpbnQgY3N1bV9pbmRleF9vZmYgPSBjc3VtX3N0YXJ0X29mZiArIHNrYi0+Y3N1
bV9vZmZzZXQ7Cj4KPiAtICAgICAgICB1bnNpZ25lZCBjaGFyICpyYXcgPSBza2JfdHJhbnNwb3J0
X2hlYWRlcihza2IpOwo+ICAjaWYgMAo+ICAgICAgICAgIHsKPiAgICAgICAgICAgICAgdW5zaWdu
ZWQgaW50IGNzdW0gPSBfeGVuZXRfdHhfY3N1bShza2IpOwo+IEBAIC0xNTc4LDkgKzE1ODEsOCBA
QCBzdGF0aWMgaW50IHhlbmV0X0RtYVNlbmRfaW50ZXJuYWwoc3RydWN0Cj4gICAgICAgICAgfQo+
ICAjZWxzZQo+ICAgICAgICAgIEJkQ3N1bUVuYWJsZShiZF9wdHIpOwo+IC0gICAgICAgIEJkQ3N1
bVNldHVwKGJkX3B0ciwgcmF3IC0gc2tiLT5kYXRhLAo+IC0gICAgICAgICAgICAgICAgKHJhdyAt
IHNrYi0+ZGF0YSkgKyBza2ItPmNzdW0pOwo+IC0KPiArICAgICAgICBCZENzdW1TZXR1cChiZF9w
dHIsIGNzdW1fc3RhcnRfb2ZmLAo+ICsgICAgICAgICAgICAgICAgY3N1bV9pbmRleF9vZmYpOwo+
ICAjZW5kaWYKPiAgICAgICAgICBscC0+dHhfaHdfY3N1bXMrKzsKPiAgICAgIH0KPiBAQCAtMzI3
Nyw3ICszMjc5LDcgQEAgc3RhdGljIGludCBfX2RldmluaXQgeHRlbmV0X29mX3Byb2JlKHN0cgo+
ICAgICAgc3RydWN0IHJlc291cmNlICpyX2lycSA9ICZyX2lycV9zdHJ1Y3Q7ICAgIC8qIEludGVy
cnVwdCByZXNvdXJjZXMgKi8KPiAgICAgIHN0cnVjdCByZXNvdXJjZSAqcl9tZW0gPSAmcl9tZW1f
c3RydWN0OyAgICAvKiBJTyBtZW0gcmVzb3VyY2VzICovCj4gICAgICBzdHJ1Y3QgeGxsdGVtYWNf
cGxhdGZvcm1fZGF0YSAqcGRhdGEgPSAmcGRhdGFfc3RydWN0Owo+IC0gICAgICAgIHZvaWQgKm1h
Y19hZGRyZXNzOwo+ICsgICAgICAgIGNvbnN0IHZvaWQgKm1hY19hZGRyZXNzOwo+ICAgICAgaW50
IHJjID0gMDsKPiAgICAgIGNvbnN0IHBoYW5kbGUgKmxsaW5rX2Nvbm5lY3RlZF9oYW5kbGU7Cj4g
ICAgICBzdHJ1Y3QgZGV2aWNlX25vZGUgKmxsaW5rX2Nvbm5lY3RlZF9ub2RlOwo+Cj4KPiBPbiBN
b24sIE1hciAzMSwgMjAwOCBhdCAxMToxMCBBTSwgTWFnbnVzIEhqb3J0aCA8bWhAb21uaXN5cy5z
ZT4gd3JvdGU6Cj4KPiBEZWFjdGl2YXRpbmcgY2hlY2tzdW0gb2ZmbG9hZGluZyBoZWxwZWQgYSBs
b3QhIEkgc3RpbGwgaGF2ZSBzb21lIHBhY2tldCBsb3NzCj4gYW5kIG5vdCB0aGUgYmVzdCBwZXJm
b3JtYW5jZSAoVEZUUCB0cmFuc2ZlciBhYm91dCAxMDAga2J5dGUvcykgYnV0IGF0IGxlYXN0Cj4g
aXQgd29ya3MuCj4KPiBUaGFua3MhCj4KPiAvL01hZ251cwo+Cj4KPgo+Cj4gPiAtLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLQo+ID4gRnJvbTogcnphMSBbbWFpbHRvOnJ6YTFAc28tbG9naWMubmV0
XQo+ID4gU2VudDogZGVuIDMxIG1hcnMgMjAwOCAxMToxNAo+ID4gVG86IE1hZ251cyBIam9ydGgK
PiA+IENjOiBKb2huIExpbm47IGdpdDsgbGludXhwcGMtZW1iZWRkZWRAb3psYWJzLm9yZwo+ID4g
U3ViamVjdDogUmU6IFhpbGlueCBMTFRFTUFDIGRyaXZlciBpc3N1ZXMKPiA+Cj4gPiBIaSBNYWdu
dXMsCj4gPgo+ID4gMS4KPiA+IEkgYW0gdXNpbmcgbmVhcmx5IHRoZSBzYW1lIHZlcnNpb25zIHRo
ZW4geW91IGFuZCBnb3QgdGhlIHNhbWUgcHJvYmxlbXMKPiA+IHRvbyA7LSkuCj4gPiBJIHRoaW5r
IHRoZXJlIGFyZSBzb21lIHByb2JsZW1zIHdpdGggdGhlIGNoZWNrc3VtIG9mZmxvYWRpbmcuCj4g
PiBUcnkgdG8gc25pZmYgdGhlIHNvbWUgcGFja2FnZXMgKGUuZy4gd2lyZXNoYXJrKS4uLgo+ID4g
Rm9yIG1lIElDTVAgKHBpbmcpIHdvcmtlZCBidXQgdWRwIGFuZCB0Y3Agbm90IChiZWNhdXNlIG9m
ZiBhIHdyb25nCj4gPiBjaGVja3N1bSBpbiB0aGUgdHJhbnNwb3J0IGxheWVyKS4KPiA+IEEgcXVp
Y2sgc29sdXRpb24gaXMgdG8ganVzdCBkZWFjdGl2YXRlIGNoZWNrc3VtIG9mZmxvYWRpbmcuCj4g
Pgo+ID4gMi4KPiA+IEkgcmVtZW1iZXIgc29tZSBwcm9ibGVtcyB3aXRoIFZpcnRleC00IHByZXNh
bXBsZXMgdG9vLgo+ID4gVGhlcmUgd2hlcmUgcHJvYmxlbXMgd2l0aCB0aGUgaGFyZC10ZW1hYyB3
cmFwcGVyLiBZb3UgaGFkIHRvIHVzZSAxLjAwLmEKPiA+IGFuZCBub3QgYiB2ZXJzaW9uLgo+ID4g
QnV0IEkgZG9uJ3QgaGF2ZSB0aGVzZSBwcm9ibGVtcyB3aXRoIHRoZSBFREsgOS4yc3AyL0lTRTku
MnNwMyBhbnltb3JlLgo+ID4KPiA+IGFsbCB0aGUgYmVzdCwKPiA+IFJvYmVydAo+ID4KPiA+IE1h
Z251cyBIam9ydGggd3JvdGU6Cj4gPiA+IEhpIEpvaG4sCj4gPiA+Cj4gPiA+IFRoYW5rcyBmb3Ig
dGhlIHZlcnkgZmFzdCByZXBseSEgUmlnaHQgbm93IEknbSBub3QgYXQgd29yayBzbyBJIGRvbid0
Cj4gPiA+IGhhdmUgdGhlIGJvYXJkIG9yIEVESyBoZXJlIHRvIHRlc3QgYW55dGhpbmcuCj4gPiA+
Cj4gPiA+IEknbSB1c2luZyBjaGVja3N1bSBvZmZsb2FkLCBidXQgSSBkb24ndCBrbm93IGlmIERS
RSBpcyBlbmFibGVkIG9yIG5vdC4gSQo+ID4gPiBjYW4ndCByZWNhbGwgc2VlaW5nIGFueSBzZXR0
aW5nIHRvIGVuYWJsZS9kaXNhYmxlIERSRS4uCj4gPiA+Cj4gPiA+IEEgZmV3IHRoaW5ncyB0aGF0
IGNyb3NzZWQgbXkgbWluZDoKPiA+ID4KPiA+ID4gTGFzdCB5ZWFyIEkgZGlkIGEgZGVzaWduIHdp
dGggRURLIDguMiwgYmFjayB0aGVuIHRoZXJlIHdhcyBhbiBpc3N1ZSB3aXRoCj4gPiA+IHRoZSBN
TDQwMyBib2FyZHMgaGF2aW5nIGFuIG9sZCByZXZpc2lvbiBvZiB0aGUgRlBHQSB3aGljaCB3YXNu
J3QKPiA+ID4gY29tcGF0aWJsZSB3aXRoIHNvbWUgdmVyc2lvbnMgb2YgdGhlIElQIGNvcmUuIFRo
ZXJlIGFyZSBubyBzdWNoIHZlcnNpb24KPiA+ID4gaXNzdWVzIHdpdGggdGhlIHhwc19sbF90ZW1h
Yz8KPiA+ID4KPiA+ID4gSSBkb24ndCB0aGluayB0aGF0IEkgaGFkIHBoeS1hZGRyIHNldCBpbiB0
aGUgRFRTIGZpbGUuIFdpbGwgdGVzdCB0aGF0IG9uCj4gPiA+IE1vbmRheS4KPiA+ID4KPiA+ID4g
QmVzdCByZWdhcmRzLAo+ID4gPiBNYWdudXMKPiA+ID4KPiA+ID4KPiA+ID4gT24gU2F0LCAyMDA4
LTAzLTI5IGF0IDA3OjU4IC0wNjAwLCBKb2huIExpbm4gd3JvdGU6Cj4gPiA+Cj4gPiA+PiBIaSBN
YWdudXMsCj4gPiA+Pgo+ID4gPj4gU29ycnkgdG8gaGVhciB5b3UncmUgaGF2aW5nIHByb2JsZW1z
IHdpdGggaXQuCj4gPiA+Pgo+ID4gPj4gSSBhbSBkb2luZyB0ZXN0aW5nIG9uIGFuIE1MNDA1IHdo
aWNoIGlzIHRoZSBzYW1lIGJvYXJkIGJ1dCB3aXRoIGEKPiBiaWdnZXIKPiA+IEZQR0EsIGJ1dCB3
aXRoIHBwYyBhcmNoIGFuZCBJIGRvbid0IHNlZSB0aGlzIGlzc3VlLiBJIGhhdmUgZG9uZSBsaW1p
dGVkCj4gdGVzdGluZwo+ID4gd2l0aCBwb3dlcnBjIGFyY2ggYW5kIHRoZSBMTCBURU1BQywgYnV0
IEkgZGlkbid0IHNlZSB0aGlzIGlzc3VlIHRoZXJlCj4gZWl0aGVyLgo+ID4gUG93ZXJwYyBhcmNo
IGlzIGRlZmluaXRlbHkgbGVzcyBtYXR1cmUgaW4gbXkgZXhwZXJpZW5jZSB0aGFuIHRoZSBwcGMg
YXJjaC4KPiBJJ2xsCj4gPiBkbyBhIHF1aWNrIHRlc3Qgd2l0aCBteSBwb3dlcnBjIGFyY2ggYW5k
IG1ha2Ugc3VyZSBhZ2FpbiBJJ20gbm90IHNlZWluZwo+IGl0Lgo+ID4gPj4KPiA+ID4+IE15IGtl
cm5lbCBpcyBmcm9tIHRoZSBYaWxpbnggR2l0IHRyZWUsIGJ1dCB0aGVyZSBoYXZlIGJlZW4gYSBu
dW1iZXIgb2YKPiA+IGNoYW5nZXMgd2UgaGF2ZSBwdXNoZWQgb3V0IHNvIEkgZG9uJ3Qga25vdyBo
b3cgbG9uZyBhZ28geW91IHB1bGxlZCBmcm9tCj4gdGhlIEdpdAo+ID4gdHJlZS4KPiA+ID4+Cj4g
PiA+PiBNeSBFREsgcHJvamVjdCBpcyAxMC4xIHNvIGl0J3MgYSBsaXR0bGUgbmV3ZXIuIEkgYW0g
dXNpbmcgTEwgVEVNQUMKPiAxLjAxYSBzbwo+ID4gaXQncyBhIGxpdHRsZSBuZXdlci4gIEkgcmV2
aWV3ZWQgdGhlIGNoYW5nZSBsb2cgZm9yIHRoZSBMTCBURU1BQyBhbmQgZG9uJ3QKPiBzZWUKPiA+
IGFueSBiaWcgcHJvYmxlbXMgdGhhdCB3ZXJlIGZpeGVkIGluIHRoZSBuZXdlciB2ZXJzaW9ucywg
bW9yZSBuZXcgZmVhdHVyZXMuCj4gSSdsbAo+ID4gY2hlY2sgd2l0aCBzb21lIG90aGVycyBoZXJl
IHRvIHNlZSBpZiBJIG1pc3NlZCBzb21ldGhpbmcgdGhlcmUuCj4gPiA+Pgo+ID4gPj4gSSBhbSB1
c2luZyBETUEgYWxzbywgYnV0IG5vIERSRSBvciBjaGVja3N1bSBvZmZsb2FkLiAgWW91IGRpZG4n
dCBzYXkKPiBhbnl0aGluZwo+ID4gYWJvdXQgdGhvc2UuIEknbSBnb2luZyB0byBpbnNlcnQgbXkg
bWhzIGZpbGUgdGhhdCBkZXNjcmliZXMgbXkgc3lzdGVtIHRvCj4gbGV0IHlvdQo+ID4gY29tcGFy
ZSB5b3VyIHN5c3RlbSBjb25maWd1cmF0aW9uLiBJdCdzIG5vdCBjbGVhciB0byBtZSB5ZXQgaWYg
eW91IGhhdmUgYQo+IGgvdyBvcgo+ID4gcy93IHByb2JsZW0uCj4gPiA+Pgo+ID4gPj4gSSdsbCBh
bHNvIGluc2VydCBzb21lIG9mIG15IGRldmljZSB0cmVlIHdpdGggdGhlIExMIFRFTUFDIHNvIHlv
dSBjYW4KPiBjb21wYXJlCj4gPiAoaWdub3JlIDE2NTUwIHN0dWZmIGFzIHdlIGFyZSBzdGlsbCB3
b3JraW5nIG9uIHRoYXQpLgo+ID4gPj4KPiA+ID4+IFNpbmNlIHlvdSBjYW4ndCBwaW5nIHJlbGlh
Ymx5IEkgd291bGQgcHJvYmFibHkgZm9jdXMgb24gdGhhdCBzaW5jZSBpdCdzCj4gPiBzaW1wbGVy
IHRoYW4gdGhlIG90aGVyIGlzc3VlcyB5b3UncmUgc2VlaW5nLgo+ID4gPj4KPiA+ID4+IFRoYW5r
cywKPiA+ID4+IEpvaG4KPiA+ID4+Cj4gPiA+Pgo+ID4gPj4KPiA+ID4+ICMKPiA+Cj4gIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjCj4gPiA+PiAjIENyZWF0ZWQgYnkgQmFzZSBTeXN0ZW0gQnVpbGRlciBX
aXphcmQgZm9yIFhpbGlueCBFREsgMTAuMS4xIEJ1aWxkCj4gPiBFREtfS19TUDEuMQo+ID4gPj4g
IyBUaHUgRmViIDE0IDE0OjExOjEyIDIwMDgKPiA+ID4+ICMgVGFyZ2V0IEJvYXJkOiAgWGlsaW54
IFZpcnRleCA0IE1MNDA1IEV2YWx1YXRpb24gUGxhdGZvcm0gUmV2IDEKPiA+ID4+ICMgRmFtaWx5
OiAgICB2aXJ0ZXg0Cj4gPiA+PiAjIERldmljZTogICAgeGM0dmZ4MjAKPiA+ID4+ICMgUGFja2Fn
ZTogICBmZjY3Mgo+ID4gPj4gIyBTcGVlZCBHcmFkZTogIC0xMAo+ID4gPj4gIyBQcm9jZXNzb3I6
IHBwYzQwNV8wCj4gPiA+PiAjIFByb2Nlc3NvciBjbG9jayBmcmVxdWVuY3k6IDMwMC4wMCBNSHoK
PiA+ID4+ICMgQnVzIGNsb2NrIGZyZXF1ZW5jeTogMTAwLjAwIE1Iego+ID4gPj4gIyBPbiBDaGlw
IE1lbW9yeSA6ICAgOCBLQgo+ID4gPj4gIyBUb3RhbCBPZmYgQ2hpcCBNZW1vcnkgOiAxMjggTUIK
PiA+ID4+ICMgLSBERFJfU0RSQU0gPSAxMjggTUIKPiA+ID4+ICMKPiA+Cj4gIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjCj4gPiA+PiAgUEFSQU1FVEVSIFZFUlNJT04gPSAyLjEuMAo+ID4gPj4KPiA+ID4+
Cj4gPiA+PiAgUE9SVCBmcGdhXzBfUlMyMzJfVWFydF9zaW5fcGluID0gZnBnYV8wX1JTMjMyX1Vh
cnRfc2luLCBESVIgPSBJCj4gPiA+PiAgUE9SVCBmcGdhXzBfUlMyMzJfVWFydF9zb3V0X3BpbiA9
IGZwZ2FfMF9SUzIzMl9VYXJ0X3NvdXQsIERJUiA9IE8KPiA+ID4+ICBQT1JUIGZwZ2FfMF9MRURz
XzRCaXRfR1BJT19JT19waW4gPSBmcGdhXzBfTEVEc180Qml0X0dQSU9fSU8sIERJUiA9Cj4gSU8s
IFZFQwo+ID4gPSBbMDozXQo+ID4gPj4gIFBPUlQgZnBnYV8wX0lJQ19FRVBST01fU2NsX3BpbiA9
IGZwZ2FfMF9JSUNfRUVQUk9NX1NjbCwgRElSID0gSU8KPiA+ID4+ICBQT1JUIGZwZ2FfMF9JSUNf
RUVQUk9NX1NkYV9waW4gPSBmcGdhXzBfSUlDX0VFUFJPTV9TZGEsIERJUiA9IElPCj4gPiA+PiAg
UE9SVCBmcGdhXzBfU3lzQUNFX0NvbXBhY3RGbGFzaF9TeXNBQ0VfQ0xLX3BpbiA9Cj4gPiBmcGdh
XzBfU3lzQUNFX0NvbXBhY3RGbGFzaF9TeXNBQ0VfQ0xLLCBESVIgPSBJCj4gPiA+PiAgUE9SVCBm
cGdhXzBfU3lzQUNFX0NvbXBhY3RGbGFzaF9TeXNBQ0VfTVBBX3BpbiA9Cj4gPiBmcGdhXzBfU3lz
QUNFX0NvbXBhY3RGbGFzaF9TeXNBQ0VfTVBBLCBESVIgPSBPLCBWRUMgPSBbNjoxXQo+ID4gPj4g
IFBPUlQgZnBnYV8wX1N5c0FDRV9Db21wYWN0Rmxhc2hfU3lzQUNFX01QRF9waW4gPQo+ID4gZnBn
YV8wX1N5c0FDRV9Db21wYWN0Rmxhc2hfU3lzQUNFX01QRCwgRElSID0gSU8sIFZFQyA9IFsxNTow
XQo+ID4gPj4gIFBPUlQgZnBnYV8wX1N5c0FDRV9Db21wYWN0Rmxhc2hfU3lzQUNFX0NFTl9waW4g
PQo+ID4gZnBnYV8wX1N5c0FDRV9Db21wYWN0Rmxhc2hfU3lzQUNFX0NFTiwgRElSID0gTwo+ID4g
Pj4gIFBPUlQgZnBnYV8wX1N5c0FDRV9Db21wYWN0Rmxhc2hfU3lzQUNFX09FTl9waW4gPQo+ID4g
ZnBnYV8wX1N5c0FDRV9Db21wYWN0Rmxhc2hfU3lzQUNFX09FTiwgRElSID0gTwo+ID4gPj4gIFBP
UlQgZnBnYV8wX1N5c0FDRV9Db21wYWN0Rmxhc2hfU3lzQUNFX1dFTl9waW4gPQo+ID4gZnBnYV8w
X1N5c0FDRV9Db21wYWN0Rmxhc2hfU3lzQUNFX1dFTiwgRElSID0gTwo+ID4gPj4gIFBPUlQgZnBn
YV8wX1N5c0FDRV9Db21wYWN0Rmxhc2hfU3lzQUNFX01QSVJRX3BpbiA9Cj4gPiBmcGdhXzBfU3lz
QUNFX0NvbXBhY3RGbGFzaF9TeXNBQ0VfTVBJUlEsIERJUiA9IEkKPiA+ID4+ICBQT1JUIGZwZ2Ff
MF9ERFJfU0RSQU1fRERSX0Nsa19waW4gPSBmcGdhXzBfRERSX1NEUkFNX0REUl9DbGssIERJUiA9
IE8KPiA+ID4+ICBQT1JUIGZwZ2FfMF9ERFJfU0RSQU1fRERSX0Nsa19uX3BpbiA9IGZwZ2FfMF9E
RFJfU0RSQU1fRERSX0Nsa19uLCBESVIKPiA9IE8KPiA+ID4+ICBQT1JUIGZwZ2FfMF9ERFJfU0RS
QU1fRERSX0FkZHJfcGluID0gZnBnYV8wX0REUl9TRFJBTV9ERFJfQWRkciwgRElSID0KPiBPLCBW
RUMKPiA+ID0gWzEyOjBdCj4gPiA+PiAgUE9SVCBmcGdhXzBfRERSX1NEUkFNX0REUl9CYW5rQWRk
cl9waW4gPQo+IGZwZ2FfMF9ERFJfU0RSQU1fRERSX0JhbmtBZGRyLCBESVIKPiA+ID0gTywgVkVD
ID0gWzE6MF0KPiA+ID4+ICBQT1JUIGZwZ2FfMF9ERFJfU0RSQU1fRERSX0NBU19uX3BpbiA9IGZw
Z2FfMF9ERFJfU0RSQU1fRERSX0NBU19uLCBESVIKPiA9IE8KPiA+ID4+ICBQT1JUIGZwZ2FfMF9E
RFJfU0RSQU1fRERSX0NFX3BpbiA9IGZwZ2FfMF9ERFJfU0RSQU1fRERSX0NFLCBESVIgPSBPCj4g
PiA+PiAgUE9SVCBmcGdhXzBfRERSX1NEUkFNX0REUl9DU19uX3BpbiA9IGZwZ2FfMF9ERFJfU0RS
QU1fRERSX0NTX24sIERJUiA9Cj4gTwo+ID4gPj4gIFBPUlQgZnBnYV8wX0REUl9TRFJBTV9ERFJf
UkFTX25fcGluID0gZnBnYV8wX0REUl9TRFJBTV9ERFJfUkFTX24sIERJUgo+ID0gTwo+ID4gPj4g
IFBPUlQgZnBnYV8wX0REUl9TRFJBTV9ERFJfV0Vfbl9waW4gPSBmcGdhXzBfRERSX1NEUkFNX0RE
Ul9XRV9uLCBESVIgPQo+IE8KPiA+ID4+ICBQT1JUIGZwZ2FfMF9ERFJfU0RSQU1fRERSX0RNX3Bp
biA9IGZwZ2FfMF9ERFJfU0RSQU1fRERSX0RNLCBESVIgPSBPLAo+IFZFQyA9Cj4gPiBbMzowXQo+
ID4gPj4gIFBPUlQgZnBnYV8wX0REUl9TRFJBTV9ERFJfRFFTID0gZnBnYV8wX0REUl9TRFJBTV9E
RFJfRFFTLCBESVIgPSBJTywKPiBWRUMgPQo+ID4gWzM6MF0KPiA+ID4+ICBQT1JUIGZwZ2FfMF9E
RFJfU0RSQU1fRERSX0RRID0gZnBnYV8wX0REUl9TRFJBTV9ERFJfRFEsIERJUiA9IElPLCBWRUMK
PiA9Cj4gPiBbMzE6MF0KPiA+ID4+ICBQT1JUIGZwZ2FfMF9UcmlNb2RlX01BQ19HTUlJX0dNSUlf
VFhEXzBfcGluID0KPiA+IGZwZ2FfMF9UcmlNb2RlX01BQ19HTUlJX0dNSUlfVFhEXzAsIERJUiA9
IE8sIFZFQyA9IFs3OjBdCj4gPiA+PiAgUE9SVCBmcGdhXzBfVHJpTW9kZV9NQUNfR01JSV9HTUlJ
X1RYX0VOXzBfcGluID0KPiA+IGZwZ2FfMF9UcmlNb2RlX01BQ19HTUlJX0dNSUlfVFhfRU5fMCwg
RElSID0gTwo+ID4gPj4gIFBPUlQgZnBnYV8wX1RyaU1vZGVfTUFDX0dNSUlfR01JSV9UWF9FUl8w
X3BpbiA9Cj4gPiBmcGdhXzBfVHJpTW9kZV9NQUNfR01JSV9HTUlJX1RYX0VSXzAsIERJUiA9IE8K
PiA+ID4+ICBQT1JUIGZwZ2FfMF9UcmlNb2RlX01BQ19HTUlJX0dNSUlfVFhfQ0xLXzBfcGluID0K
PiA+IGZwZ2FfMF9UcmlNb2RlX01BQ19HTUlJX0dNSUlfVFhfQ0xLXzAsIERJUiA9IE8KPiA+ID4+
ICBQT1JUIGZwZ2FfMF9UcmlNb2RlX01BQ19HTUlJX0dNSUlfUlhEXzBfcGluID0KPiA+IGZwZ2Ff
MF9UcmlNb2RlX01BQ19HTUlJX0dNSUlfUlhEXzAsIERJUiA9IEksIFZFQyA9IFs3OjBdCj4gPiA+
PiAgUE9SVCBmcGdhXzBfVHJpTW9kZV9NQUNfR01JSV9HTUlJX1JYX0RWXzBfcGluID0KPiA+IGZw
Z2FfMF9UcmlNb2RlX01BQ19HTUlJX0dNSUlfUlhfRFZfMCwgRElSID0gSQo+ID4gPj4gIFBPUlQg
ZnBnYV8wX1RyaU1vZGVfTUFDX0dNSUlfR01JSV9SWF9FUl8wX3BpbiA9Cj4gPiBmcGdhXzBfVHJp
TW9kZV9NQUNfR01JSV9HTUlJX1JYX0VSXzAsIERJUiA9IEkKPiA+ID4+ICBQT1JUIGZwZ2FfMF9U
cmlNb2RlX01BQ19HTUlJX0dNSUlfUlhfQ0xLXzBfcGluID0KPiA+IGZwZ2FfMF9UcmlNb2RlX01B
Q19HTUlJX0dNSUlfUlhfQ0xLXzAsIERJUiA9IEkKPiA+ID4+ICBQT1JUIGZwZ2FfMF9UcmlNb2Rl
X01BQ19HTUlJX01JSV9UWF9DTEtfMF9waW4gPQo+ID4gZnBnYV8wX1RyaU1vZGVfTUFDX0dNSUlf
TUlJX1RYX0NMS18wLCBESVIgPSBJCj4gPiA+PiAgUE9SVCBmcGdhXzBfVHJpTW9kZV9NQUNfR01J
SV9NRElPXzBfcGluID0KPiBmcGdhXzBfVHJpTW9kZV9NQUNfR01JSV9NRElPXzAsCj4gPiBESVIg
PSBJTwo+ID4gPj4gIFBPUlQgZnBnYV8wX1RyaU1vZGVfTUFDX0dNSUlfTURDXzBfcGluID0KPiBm
cGdhXzBfVHJpTW9kZV9NQUNfR01JSV9NRENfMCwgRElSCj4gPiA9IE8KPiA+ID4+ICBQT1JUIGZw
Z2FfMF9UcmlNb2RlX01BQ19HTUlJX1RlbWFjUGh5X1JTVF9uX3BpbiA9Cj4gPiBmcGdhXzBfVHJp
TW9kZV9NQUNfR01JSV9UZW1hY1BoeV9SU1RfbiwgRElSID0gTwo+ID4gPj4gIFBPUlQgc3lzX2Ns
a19waW4gPSBkY21fY2xrX3MsIERJUiA9IEksIFNJR0lTID0gQ0xLLCBDTEtfRlJFUSA9Cj4gMTAw
MDAwMDAwCj4gPiA+PiAgUE9SVCBzeXNfcnN0X3BpbiA9IHN5c19yc3RfcywgRElSID0gSSwgUlNU
X1BPTEFSSVRZID0gMCwgU0lHSVMgPSBSU1QKPiA+ID4+Cj4gPiA+Pgo+ID4gPj4gQkVHSU4gcHBj
NDA1X3ZpcnRleDQKPiA+ID4+ICBQQVJBTUVURVIgSU5TVEFOQ0UgPSBwcGM0MDVfMAo+ID4gPj4g
IFBBUkFNRVRFUiBIV19WRVIgPSAyLjAxLmEKPiA+ID4+ICBQQVJBTUVURVIgQ19GQVNURVNUX1BM
Ql9DTE9DSyA9IERQTEIxCj4gPiA+PiAgUEFSQU1FVEVSIENfSURDUl9CQVNFQUREUiA9IDBiMDEw
MDAwMDAwMAo+ID4gPj4gIFBBUkFNRVRFUiBDX0lEQ1JfSElHSEFERFIgPSAwYjAxMTExMTExMTEK
PiA+ID4+ICBCVVNfSU5URVJGQUNFIEpUQUdQUEMgPSBqdGFncHBjXzBfMAo+ID4gPj4gIEJVU19J
TlRFUkZBQ0UgSVBMQjAgPSBwbGIKPiA+ID4+ICBCVVNfSU5URVJGQUNFIERQTEIwID0gcGxiCj4g
PiA+PiAgQlVTX0lOVEVSRkFDRSBJUExCMSA9IHBwYzQwNV8wX2lwbGIxCj4gPiA+PiAgQlVTX0lO
VEVSRkFDRSBEUExCMSA9IHBwYzQwNV8wX2RwbGIxCj4gPiA+PiAgQlVTX0lOVEVSRkFDRSBSRVNF
VFBQQyA9IHBwY19yZXNldF9idXMKPiA+ID4+ICBQT1JUIENQTUM0MDVDTE9DSyA9IHByb2NfY2xr
X3MKPiA+ID4+ICBQT1JUIEVJQ0M0MDVFWFRJTlBVVElSUSA9IEVJQ0M0MDVFWFRJTlBVVElSUQo+
ID4gPj4gRU5ECj4gPiA+Pgo+ID4gPj4gQkVHSU4ganRhZ3BwY19jbnRscgo+ID4gPj4gIFBBUkFN
RVRFUiBJTlNUQU5DRSA9IGp0YWdwcGNfMAo+ID4gPj4gIFBBUkFNRVRFUiBIV19WRVIgPSAyLjAx
LmEKPiA+ID4+ICBCVVNfSU5URVJGQUNFIEpUQUdQUEMwID0ganRhZ3BwY18wXzAKPiA+ID4+IEVO
RAo+ID4gPj4KPiA+ID4+IEJFR0lOIHBsYl92NDYKPiA+ID4+ICBQQVJBTUVURVIgSU5TVEFOQ0Ug
PSBwbGIKPiA+ID4+ICBQQVJBTUVURVIgQ19EQ1JfSU5URkNFID0gMAo+ID4gPj4gIFBBUkFNRVRF
UiBDX05VTV9DTEtfUExCMk9QQl9SRUFSQiA9IDEwMAo+ID4gPj4gIFBBUkFNRVRFUiBIV19WRVIg
PSAxLjAyLmEKPiA+ID4+ICBQT1JUIFBMQl9DbGsgPSBzeXNfY2xrX3MKPiA+ID4+ICBQT1JUIFNZ
U19Sc3QgPSBzeXNfYnVzX3Jlc2V0Cj4gPiA+PiBFTkQKPiA+ID4+Cj4gPiA+PiBCRUdJTiB4cHNf
YnJhbV9pZl9jbnRscgo+ID4gPj4gIFBBUkFNRVRFUiBJTlNUQU5DRSA9IHhwc19icmFtX2lmX2Nu
dGxyXzEKPiA+ID4+ICBQQVJBTUVURVIgSFdfVkVSID0gMS4wMC5hCj4gPiA+PiAgUEFSQU1FVEVS
IENfU1BMQl9OQVRJVkVfRFdJRFRIID0gNjQKPiA+ID4+ICBQQVJBTUVURVIgQ19CQVNFQUREUiA9
IDB4ZmZmZmUwMDAKPiA+ID4+ICBQQVJBTUVURVIgQ19ISUdIQUREUiA9IDB4ZmZmZmZmZmYKPiA+
ID4+ICBCVVNfSU5URVJGQUNFIFNQTEIgPSBwbGIKPiA+ID4+ICBCVVNfSU5URVJGQUNFIFBPUlRB
ID0geHBzX2JyYW1faWZfY250bHJfMV9wb3J0Cj4gPiA+PiBFTkQKPiA+ID4+Cj4gPiA+PiBCRUdJ
TiBicmFtX2Jsb2NrCj4gPiA+PiAgUEFSQU1FVEVSIElOU1RBTkNFID0gcGxiX2JyYW1faWZfY250
bHJfMV9icmFtCj4gPiA+PiAgUEFSQU1FVEVSIEhXX1ZFUiA9IDEuMDAuYQo+ID4gPj4gIEJVU19J
TlRFUkZBQ0UgUE9SVEEgPSB4cHNfYnJhbV9pZl9jbnRscl8xX3BvcnQKPiA+ID4+IEVORAo+ID4g
Pj4KPiA+ID4+IEJFR0lOIHhwc191YXJ0MTY1NTAKPiA+ID4+ICBQQVJBTUVURVIgSU5TVEFOQ0Ug
PSBSUzIzMl9VYXJ0Cj4gPiA+PiAgUEFSQU1FVEVSIEhXX1ZFUiA9IDIuMDAuYQo+ID4gPj4gIFBB
UkFNRVRFUiBDX0lTX0FfMTY1NTAgPSAxCj4gPiA+PiAgUEFSQU1FVEVSIENfQkFTRUFERFIgPSAw
eDgzZTAwMDAwCj4gPiA+PiAgUEFSQU1FVEVSIENfSElHSEFERFIgPSAweDgzZTBmZmZmCj4gPiA+
PiAgQlVTX0lOVEVSRkFDRSBTUExCID0gcGxiCj4gPiA+PiAgUE9SVCBzaW4gPSBmcGdhXzBfUlMy
MzJfVWFydF9zaW4KPiA+ID4+ICBQT1JUIHNvdXQgPSBmcGdhXzBfUlMyMzJfVWFydF9zb3V0Cj4g
PiA+PiAgUE9SVCBJUDJJTlRDX0lycHQgPSBSUzIzMl9VYXJ0X0lQMklOVENfSXJwdAo+ID4gPj4g
RU5ECj4gPiA+Pgo+ID4gPj4gQkVHSU4geHBzX2dwaW8KPiA+ID4+ICBQQVJBTUVURVIgSU5TVEFO
Q0UgPSBMRURzXzRCaXQKPiA+ID4+ICBQQVJBTUVURVIgSFdfVkVSID0gMS4wMC5hCj4gPiA+PiAg
UEFSQU1FVEVSIENfSU5URVJSVVBUX1BSRVNFTlQgPSAxCj4gPiA+PiAgUEFSQU1FVEVSIENfR1BJ
T19XSURUSCA9IDQKPiA+ID4+ICBQQVJBTUVURVIgQ19JU19EVUFMID0gMAo+ID4gPj4gIFBBUkFN
RVRFUiBDX0lTX0JJRElSID0gMQo+ID4gPj4gIFBBUkFNRVRFUiBDX0FMTF9JTlBVVFMgPSAwCj4g
PiA+PiAgUEFSQU1FVEVSIENfQkFTRUFERFIgPSAweDgxNDAwMDAwCj4gPiA+PiAgUEFSQU1FVEVS
IENfSElHSEFERFIgPSAweDgxNDBmZmZmCj4gPiA+PiAgQlVTX0lOVEVSRkFDRSBTUExCID0gcGxi
Cj4gPiA+PiAgUE9SVCBHUElPX0lPID0gZnBnYV8wX0xFRHNfNEJpdF9HUElPX0lPCj4gPiA+PiAg
UE9SVCBJUDJJTlRDX0lycHQgPSBMRURzXzRCaXRfSVAySU5UQ19JcnB0Cj4gPiA+PiBFTkQKPiA+
ID4+Cj4gPiA+PiBCRUdJTiB4cHNfaWljCj4gPiA+PiAgUEFSQU1FVEVSIElOU1RBTkNFID0gSUlD
X0VFUFJPTQo+ID4gPj4gIFBBUkFNRVRFUiBIV19WRVIgPSAyLjAwLmEKPiA+ID4+ICBQQVJBTUVU
RVIgQ19DTEtfRlJFUSA9IDEwMDAwMDAwMAo+ID4gPj4gIFBBUkFNRVRFUiBDX0lJQ19GUkVRID0g
MTAwMDAwCj4gPiA+PiAgUEFSQU1FVEVSIENfVEVOX0JJVF9BRFIgPSAwCj4gPiA+PiAgUEFSQU1F
VEVSIENfQkFTRUFERFIgPSAweDgxNjAwMDAwCj4gPiA+PiAgUEFSQU1FVEVSIENfSElHSEFERFIg
PSAweDgxNjBmZmZmCj4gPiA+PiAgQlVTX0lOVEVSRkFDRSBTUExCID0gcGxiCj4gPiA+PiAgUE9S
VCBTY2wgPSBmcGdhXzBfSUlDX0VFUFJPTV9TY2wKPiA+ID4+ICBQT1JUIFNkYSA9IGZwZ2FfMF9J
SUNfRUVQUk9NX1NkYQo+ID4gPj4gIFBPUlQgSUlDMklOVENfSXJwdCA9IElJQ19FRVBST01fSUlD
MklOVENfSXJwdAo+ID4gPj4gRU5ECj4gPiA+Pgo+ID4gPj4gQkVHSU4geHBzX3N5c2FjZQo+ID4g
Pj4gIFBBUkFNRVRFUiBJTlNUQU5DRSA9IFN5c0FDRV9Db21wYWN0Rmxhc2gKPiA+ID4+ICBQQVJB
TUVURVIgSFdfVkVSID0gMS4wMC5hCj4gPiA+PiAgUEFSQU1FVEVSIENfTUVNX1dJRFRIID0gMTYK
PiA+ID4+ICBQQVJBTUVURVIgQ19CQVNFQUREUiA9IDB4ODM2MDAwMDAKPiA+ID4+ICBQQVJBTUVU
RVIgQ19ISUdIQUREUiA9IDB4ODM2MGZmZmYKPiA+ID4+ICBCVVNfSU5URVJGQUNFIFNQTEIgPSBw
bGIKPiA+ID4+ICBQT1JUIFN5c0FDRV9DTEsgPSBmcGdhXzBfU3lzQUNFX0NvbXBhY3RGbGFzaF9T
eXNBQ0VfQ0xLCj4gPiA+PiAgUE9SVCBTeXNBQ0VfTVBBID0gZnBnYV8wX1N5c0FDRV9Db21wYWN0
Rmxhc2hfU3lzQUNFX01QQV9zcGxpdAo+ID4gPj4gIFBPUlQgU3lzQUNFX01QRCA9IGZwZ2FfMF9T
eXNBQ0VfQ29tcGFjdEZsYXNoX1N5c0FDRV9NUEQKPiA+ID4+ICBQT1JUIFN5c0FDRV9DRU4gPSBm
cGdhXzBfU3lzQUNFX0NvbXBhY3RGbGFzaF9TeXNBQ0VfQ0VOCj4gPiA+PiAgUE9SVCBTeXNBQ0Vf
T0VOID0gZnBnYV8wX1N5c0FDRV9Db21wYWN0Rmxhc2hfU3lzQUNFX09FTgo+ID4gPj4gIFBPUlQg
U3lzQUNFX1dFTiA9IGZwZ2FfMF9TeXNBQ0VfQ29tcGFjdEZsYXNoX1N5c0FDRV9XRU4KPiA+ID4+
ICBQT1JUIFN5c0FDRV9NUElSUSA9IGZwZ2FfMF9TeXNBQ0VfQ29tcGFjdEZsYXNoX1N5c0FDRV9N
UElSUQo+ID4gPj4gIFBPUlQgU3lzQUNFX0lSUSA9IFN5c0FDRV9Db21wYWN0Rmxhc2hfU3lzQUNF
X0lSUQo+ID4gPj4gRU5ECj4gPiA+Pgo+ID4gPj4gQkVHSU4gbXBtYwo+ID4gPj4gIFBBUkFNRVRF
UiBJTlNUQU5DRSA9IEREUl9TRFJBTQo+ID4gPj4gIFBBUkFNRVRFUiBIV19WRVIgPSA0LjAwLmEK
PiA+ID4+ICBQQVJBTUVURVIgQ19OVU1fUE9SVFMgPSAzCj4gPiA+PiAgUEFSQU1FVEVSIENfTUVN
X1BBUlROTyA9IEhZQjI1RDUxMjE2MEJFLTUKPiA+ID4+ICBQQVJBTUVURVIgQ19NRU1fREFUQV9X
SURUSCA9IDMyCj4gPiA+PiAgUEFSQU1FVEVSIENfTUVNX0RRU19XSURUSCA9IDQKPiA+ID4+ICBQ
QVJBTUVURVIgQ19NRU1fRE1fV0lEVEggPSA0Cj4gPiA+PiAgUEFSQU1FVEVSIENfTUVNX1RZUEUg
PSBERFIKPiA+ID4+ICBQQVJBTUVURVIgQ19OVU1fSURFTEFZQ1RSTCA9IDIKPiA+ID4+ICBQQVJB
TUVURVIgQ19JREVMQVlDVFJMX0xPQyA9IElERUxBWUNUUkxfWDBZMy1JREVMQVlDVFJMX1gwWTIK
PiA+ID4+ICBQQVJBTUVURVIgQ19QSU0wX0JBU0VUWVBFID0gMgo+ID4gPj4gIFBBUkFNRVRFUiBD
X1BJTTFfQkFTRVRZUEUgPSAyCj4gPiA+PiAgUEFSQU1FVEVSIENfUElNMl9CQVNFVFlQRSA9IDMK
PiA+ID4+ICBQQVJBTUVURVIgQ19NUE1DX0NMSzBfUEVSSU9EX1BTID0gMTAwMDAKPiA+ID4+ICBQ
QVJBTUVURVIgQ19TRE1BMl9QSTJMTF9DTEtfUkFUSU8gPSAxCj4gPiA+PiAgUEFSQU1FVEVSIENf
TVBNQ19CQVNFQUREUiA9IDB4MDAwMDAwMDAKPiA+ID4+ICBQQVJBTUVURVIgQ19NUE1DX0hJR0hB
RERSID0gMHgwN2ZmZmZmZgo+ID4gPj4gIFBBUkFNRVRFUiBDX1NETUFfQ1RSTF9CQVNFQUREUiA9
IDB4ODQ2MDAwMDAKPiA+ID4+ICBQQVJBTUVURVIgQ19TRE1BX0NUUkxfSElHSEFERFIgPSAweDg0
NjBmZmZmCj4gPiA+PiAgQlVTX0lOVEVSRkFDRSBTUExCMCA9IHBwYzQwNV8wX2lwbGIxCj4gPiA+
PiAgQlVTX0lOVEVSRkFDRSBTUExCMSA9IHBwYzQwNV8wX2RwbGIxCj4gPiA+PiAgQlVTX0lOVEVS
RkFDRSBTRE1BX0xMMiA9IFRyaU1vZGVfTUFDX0dNSUlfTExJTkswCj4gPiA+PiAgQlVTX0lOVEVS
RkFDRSBTRE1BX0NUUkwyID0gcGxiCj4gPiA+PiAgUE9SVCBERFJfQWRkciA9IGZwZ2FfMF9ERFJf
U0RSQU1fRERSX0FkZHIKPiA+ID4+ICBQT1JUIEREUl9CYW5rQWRkciA9IGZwZ2FfMF9ERFJfU0RS
QU1fRERSX0JhbmtBZGRyCj4gPiA+PiAgUE9SVCBERFJfQ0FTX24gPSBmcGdhXzBfRERSX1NEUkFN
X0REUl9DQVNfbgo+ID4gPj4gIFBPUlQgRERSX0NFID0gZnBnYV8wX0REUl9TRFJBTV9ERFJfQ0UK
PiA+ID4+ICBQT1JUIEREUl9DU19uID0gZnBnYV8wX0REUl9TRFJBTV9ERFJfQ1Nfbgo+ID4gPj4g
IFBPUlQgRERSX1JBU19uID0gZnBnYV8wX0REUl9TRFJBTV9ERFJfUkFTX24KPiA+ID4+ICBQT1JU
IEREUl9XRV9uID0gZnBnYV8wX0REUl9TRFJBTV9ERFJfV0Vfbgo+ID4gPj4gIFBPUlQgRERSX0RN
ID0gZnBnYV8wX0REUl9TRFJBTV9ERFJfRE0KPiA+ID4+ICBQT1JUIEREUl9EUVMgPSBmcGdhXzBf
RERSX1NEUkFNX0REUl9EUVMKPiA+ID4+ICBQT1JUIEREUl9EUSA9IGZwZ2FfMF9ERFJfU0RSQU1f
RERSX0RRCj4gPiA+PiAgUE9SVCBERFJfQ2xrID0gZnBnYV8wX0REUl9TRFJBTV9ERFJfQ2xrCj4g
PiA+PiAgUE9SVCBERFJfQ2xrX24gPSBmcGdhXzBfRERSX1NEUkFNX0REUl9DbGtfbgo+ID4gPj4g
IFBPUlQgTVBNQ19DbGswID0gc3lzX2Nsa19zCj4gPiA+PiAgUE9SVCBNUE1DX0NsazkwID0gRERS
X1NEUkFNX21wbWNfY2xrXzkwX3MKPiA+ID4+ICBQT1JUIFNETUEyX0NsayA9IHN5c19jbGtfcwo+
ID4gPj4gIFBPUlQgTVBNQ19DbGtfMjAwTUh6ID0gY2xrXzIwMG1oel9zCj4gPiA+PiAgUE9SVCBN
UE1DX1JzdCA9IHN5c19wZXJpcGhfcmVzZXQKPiA+ID4+ICBQT1JUIFNETUEyX1J4X0ludE91dCA9
IEREUl9TRFJBTV9TRE1BMl9SeF9JbnRPdXQKPiA+ID4+ICBQT1JUIFNETUEyX1R4X0ludE91dCA9
IEREUl9TRFJBTV9TRE1BMl9UeF9JbnRPdXQKPiA+ID4+IEVORAo+ID4gPj4KPiA+ID4+IEJFR0lO
IHhwc19sbF90ZW1hYwo+ID4gPj4gIFBBUkFNRVRFUiBJTlNUQU5DRSA9IFRyaU1vZGVfTUFDX0dN
SUkKPiA+ID4+ICBQQVJBTUVURVIgSFdfVkVSID0gMS4wMS5hCj4gPiA+PiAgUEFSQU1FVEVSIENf
U1BMQl9DTEtfUEVSSU9EX1BTID0gMTAwMDAKPiA+ID4+ICBQQVJBTUVURVIgQ19QSFlfVFlQRSA9
IDEKPiA+ID4+ICBQQVJBTUVURVIgQ19OVU1fSURFTEFZQ1RSTCA9IDQKPiA+ID4+ICBQQVJBTUVU
RVIgQ19JREVMQVlDVFJMX0xPQyA9IElERUxBWUNUUkxfWDFZMS1JREVMQVlDVFJMX1gxWTMtCj4g
PiBJREVMQVlDVFJMX1gyWTItSURFTEFZQ1RSTF9YMlkzCj4gPiA+PiAgUEFSQU1FVEVSIENfVEVN
QUNfVFlQRSA9IDEKPiA+ID4+ICBQQVJBTUVURVIgQ19CVVMyQ09SRV9DTEtfUkFUSU8gPSAxCj4g
PiA+PiAgUEFSQU1FVEVSIENfQkFTRUFERFIgPSAweDgxYzAwMDAwCj4gPiA+PiAgUEFSQU1FVEVS
IENfSElHSEFERFIgPSAweDgxYzBmZmZmCj4gPiA+PiAgQlVTX0lOVEVSRkFDRSBTUExCID0gcGxi
Cj4gPiA+PiAgQlVTX0lOVEVSRkFDRSBMTElOSzAgPSBUcmlNb2RlX01BQ19HTUlJX0xMSU5LMAo+
ID4gPj4gIFBPUlQgR01JSV9UWERfMCA9IGZwZ2FfMF9UcmlNb2RlX01BQ19HTUlJX0dNSUlfVFhE
XzAKPiA+ID4+ICBQT1JUIEdNSUlfVFhfRU5fMCA9IGZwZ2FfMF9UcmlNb2RlX01BQ19HTUlJX0dN
SUlfVFhfRU5fMAo+ID4gPj4gIFBPUlQgR01JSV9UWF9FUl8wID0gZnBnYV8wX1RyaU1vZGVfTUFD
X0dNSUlfR01JSV9UWF9FUl8wCj4gPiA+PiAgUE9SVCBHTUlJX1RYX0NMS18wID0gZnBnYV8wX1Ry
aU1vZGVfTUFDX0dNSUlfR01JSV9UWF9DTEtfMAo+ID4gPj4gIFBPUlQgR01JSV9SWERfMCA9IGZw
Z2FfMF9UcmlNb2RlX01BQ19HTUlJX0dNSUlfUlhEXzAKPiA+ID4+ICBQT1JUIEdNSUlfUlhfRFZf
MCA9IGZwZ2FfMF9UcmlNb2RlX01BQ19HTUlJX0dNSUlfUlhfRFZfMAo+ID4gPj4gIFBPUlQgR01J
SV9SWF9FUl8wID0gZnBnYV8wX1RyaU1vZGVfTUFDX0dNSUlfR01JSV9SWF9FUl8wCj4gPiA+PiAg
UE9SVCBHTUlJX1JYX0NMS18wID0gZnBnYV8wX1RyaU1vZGVfTUFDX0dNSUlfR01JSV9SWF9DTEtf
MAo+ID4gPj4gIFBPUlQgTUlJX1RYX0NMS18wID0gZnBnYV8wX1RyaU1vZGVfTUFDX0dNSUlfTUlJ
X1RYX0NMS18wCj4gPiA+PiAgUE9SVCBNRElPXzAgPSBmcGdhXzBfVHJpTW9kZV9NQUNfR01JSV9N
RElPXzAKPiA+ID4+ICBQT1JUIE1EQ18wID0gZnBnYV8wX1RyaU1vZGVfTUFDX0dNSUlfTURDXzAK
PiA+ID4+ICBQT1JUIFRlbWFjUGh5X1JTVF9uID0gZnBnYV8wX1RyaU1vZGVfTUFDX0dNSUlfVGVt
YWNQaHlfUlNUX24KPiA+ID4+ICBQT1JUIEdUWF9DTEtfMCA9IHRlbWFjX2Nsa19zCj4gPiA+PiAg
UE9SVCBSRUZDTEsgPSBjbGtfMjAwbWh6X3MKPiA+ID4+ICBQT1JUIExsaW5rVGVtYWMwX0NMSyA9
IHN5c19jbGtfcwo+ID4gPj4gIFBPUlQgVGVtYWNJbnRjMF9JcnB0ID0gVHJpTW9kZV9NQUNfR01J
SV9UZW1hY0ludGMwX0lycHQKPiA+ID4+IEVORAo+ID4gPj4KPiA+ID4+IEJFR0lOIHV0aWxfYnVz
X3NwbGl0Cj4gPiA+PiAgUEFSQU1FVEVSIElOU1RBTkNFID0gU3lzQUNFX0NvbXBhY3RGbGFzaF91
dGlsX2J1c19zcGxpdF8wCj4gPiA+PiAgUEFSQU1FVEVSIEhXX1ZFUiA9IDEuMDAuYQo+ID4gPj4g
IFBBUkFNRVRFUiBDX1NJWkVfSU4gPSA3Cj4gPiA+PiAgUEFSQU1FVEVSIENfTEVGVF9QT1MgPSAw
Cj4gPiA+PiAgUEFSQU1FVEVSIENfU1BMSVQgPSA2Cj4gPiA+PiAgUE9SVCBTaWcgPSBmcGdhXzBf
U3lzQUNFX0NvbXBhY3RGbGFzaF9TeXNBQ0VfTVBBX3NwbGl0Cj4gPiA+PiAgUE9SVCBPdXQxID0g
ZnBnYV8wX1N5c0FDRV9Db21wYWN0Rmxhc2hfU3lzQUNFX01QQQo+ID4gPj4gRU5ECj4gPiA+Pgo+
ID4gPj4gQkVHSU4gcGxiX3Y0Ngo+ID4gPj4gIFBBUkFNRVRFUiBJTlNUQU5DRSA9IHBwYzQwNV8w
X2lwbGIxCj4gPiA+PiAgUEFSQU1FVEVSIEhXX1ZFUiA9IDEuMDIuYQo+ID4gPj4gIFBPUlQgUExC
X0NsayA9IHN5c19jbGtfcwo+ID4gPj4gIFBPUlQgU1lTX1JzdCA9IHN5c19idXNfcmVzZXQKPiA+
ID4+IEVORAo+ID4gPj4KPiA+ID4+IEJFR0lOIHBsYl92NDYKPiA+ID4+ICBQQVJBTUVURVIgSU5T
VEFOQ0UgPSBwcGM0MDVfMF9kcGxiMQo+ID4gPj4gIFBBUkFNRVRFUiBIV19WRVIgPSAxLjAyLmEK
PiA+ID4+ICBQT1JUIFBMQl9DbGsgPSBzeXNfY2xrX3MKPiA+ID4+ICBQT1JUIFNZU19Sc3QgPSBz
eXNfYnVzX3Jlc2V0Cj4gPiA+PiBFTkQKPiA+ID4+Cj4gPiA+PiBCRUdJTiBjbG9ja19nZW5lcmF0
b3IKPiA+ID4+ICBQQVJBTUVURVIgSU5TVEFOQ0UgPSBjbG9ja19nZW5lcmF0b3JfMAo+ID4gPj4g
IFBBUkFNRVRFUiBIV19WRVIgPSAyLjAwLmEKPiA+ID4+ICBQQVJBTUVURVIgQ19FWFRfUkVTRVRf
SElHSCA9IDEKPiA+ID4+ICBQQVJBTUVURVIgQ19DTEtJTl9GUkVRID0gMTAwMDAwMDAwCj4gPiA+
PiAgUEFSQU1FVEVSIENfQ0xLT1VUMF9GUkVRID0gMTAwMDAwMDAwCj4gPiA+PiAgUEFSQU1FVEVS
IENfQ0xLT1VUMF9CVUYgPSBUUlVFCj4gPiA+PiAgUEFSQU1FVEVSIENfQ0xLT1VUMF9QSEFTRSA9
IDAKPiA+ID4+ICBQQVJBTUVURVIgQ19DTEtPVVQwX0dST1VQID0gRENNMAo+ID4gPj4gIFBBUkFN
RVRFUiBDX0NMS09VVDFfRlJFUSA9IDEwMDAwMDAwMAo+ID4gPj4gIFBBUkFNRVRFUiBDX0NMS09V
VDFfQlVGID0gVFJVRQo+ID4gPj4gIFBBUkFNRVRFUiBDX0NMS09VVDFfUEhBU0UgPSA5MAo+ID4g
Pj4gIFBBUkFNRVRFUiBDX0NMS09VVDFfR1JPVVAgPSBEQ00wCj4gPiA+PiAgUEFSQU1FVEVSIENf
Q0xLT1VUMl9GUkVRID0gMzAwMDAwMDAwCj4gPiA+PiAgUEFSQU1FVEVSIENfQ0xLT1VUMl9CVUYg
PSBUUlVFCj4gPiA+PiAgUEFSQU1FVEVSIENfQ0xLT1VUMl9QSEFTRSA9IDAKPiA+ID4+ICBQQVJB
TUVURVIgQ19DTEtPVVQyX0dST1VQID0gRENNMAo+ID4gPj4gIFBBUkFNRVRFUiBDX0NMS09VVDNf
RlJFUSA9IDIwMDAwMDAwMAo+ID4gPj4gIFBBUkFNRVRFUiBDX0NMS09VVDNfQlVGID0gVFJVRQo+
ID4gPj4gIFBBUkFNRVRFUiBDX0NMS09VVDNfUEhBU0UgPSAwCj4gPiA+PiAgUEFSQU1FVEVSIENf
Q0xLT1VUM19HUk9VUCA9IE5PTkUKPiA+ID4+ICBQQVJBTUVURVIgQ19DTEtPVVQ0X0ZSRVEgPSAx
MjUwMDAwMDAKPiA+ID4+ICBQQVJBTUVURVIgQ19DTEtPVVQ0X0JVRiA9IFRSVUUKPiA+ID4+ICBQ
QVJBTUVURVIgQ19DTEtPVVQ0X1BIQVNFID0gMAo+ID4gPj4gIFBBUkFNRVRFUiBDX0NMS09VVDRf
R1JPVVAgPSBOT05FCj4gPiA+PiAgUE9SVCBDTEtPVVQwID0gc3lzX2Nsa19zCj4gPiA+PiAgUE9S
VCBDTEtPVVQxID0gRERSX1NEUkFNX21wbWNfY2xrXzkwX3MKPiA+ID4+ICBQT1JUIENMS09VVDIg
PSBwcm9jX2Nsa19zCj4gPiA+PiAgUE9SVCBDTEtPVVQzID0gY2xrXzIwMG1oel9zCj4gPiA+PiAg
UE9SVCBDTEtPVVQ0ID0gdGVtYWNfY2xrX3MKPiA+ID4+ICBQT1JUIENMS0lOID0gZGNtX2Nsa19z
Cj4gPiA+PiAgUE9SVCBMT0NLRUQgPSBEY21fYWxsX2xvY2tlZAo+ID4gPj4gIFBPUlQgUlNUID0g
bmV0X2duZAo+ID4gPj4gRU5ECj4gPiA+Pgo+ID4gPj4gQkVHSU4gcHJvY19zeXNfcmVzZXQKPiA+
ID4+ICBQQVJBTUVURVIgSU5TVEFOQ0UgPSBwcm9jX3N5c19yZXNldF8wCj4gPiA+PiAgUEFSQU1F
VEVSIEhXX1ZFUiA9IDIuMDAuYQo+ID4gPj4gIFBBUkFNRVRFUiBDX0VYVF9SRVNFVF9ISUdIID0g
MAo+ID4gPj4gIEJVU19JTlRFUkZBQ0UgUkVTRVRQUEMwID0gcHBjX3Jlc2V0X2J1cwo+ID4gPj4g
IFBPUlQgU2xvd2VzdF9zeW5jX2NsayA9IHN5c19jbGtfcwo+ID4gPj4gIFBPUlQgRGNtX2xvY2tl
ZCA9IERjbV9hbGxfbG9ja2VkCj4gPiA+PiAgUE9SVCBFeHRfUmVzZXRfSW4gPSBzeXNfcnN0X3MK
PiA+ID4+ICBQT1JUIEJ1c19TdHJ1Y3RfUmVzZXQgPSBzeXNfYnVzX3Jlc2V0Cj4gPiA+PiAgUE9S
VCBQZXJpcGhlcmFsX1Jlc2V0ID0gc3lzX3BlcmlwaF9yZXNldAo+ID4gPj4gRU5ECj4gPiA+Pgo+
ID4gPj4gQkVHSU4geHBzX2ludGMKPiA+ID4+ICBQQVJBTUVURVIgSU5TVEFOQ0UgPSB4cHNfaW50
Y18wCj4gPiA+PiAgUEFSQU1FVEVSIEhXX1ZFUiA9IDEuMDAuYQo+ID4gPj4gIFBBUkFNRVRFUiBD
X0JBU0VBRERSID0gMHg4MTgwMDAwMAo+ID4gPj4gIFBBUkFNRVRFUiBDX0hJR0hBRERSID0gMHg4
MTgwZmZmZgo+ID4gPj4gIEJVU19JTlRFUkZBQ0UgU1BMQiA9IHBsYgo+ID4gPj4gIFBPUlQgSXJx
ID0gRUlDQzQwNUVYVElOUFVUSVJRCj4gPiA+PiAgUE9SVCBJbnRyID0gUlMyMzJfVWFydF9JUDJJ
TlRDX0lycHQgJiBMRURzXzRCaXRfSVAySU5UQ19JcnB0ICYKPiA+IElJQ19FRVBST01fSUlDMklO
VENfSXJwdCAmIFN5c0FDRV9Db21wYWN0Rmxhc2hfU3lzQUNFX0lSUSAmCj4gPiBUcmlNb2RlX01B
Q19HTUlJX1RlbWFjSW50YzBfSXJwdCAmIEREUl9TRFJBTV9TRE1BMl9SeF9JbnRPdXQgJgo+ID4g
RERSX1NEUkFNX1NETUEyX1R4X0ludE91dAo+ID4gPj4gRU5ECj4gPiA+Pgo+ID4gPj4KPiA+ID4+
Cj4gPiA+PiAgICAjYWRkcmVzcy1jZWxscyA9IDwxPjsKPiA+ID4+ICAgICNzaXplLWNlbGxzID0g
PDE+Owo+ID4gPj4gICAgY29tcGF0aWJsZSA9ICJ4bG54LHZpcnRleCI7Cj4gPiA+PiAgICBtb2Rl
bCA9ICJ0ZXN0aW5nIjsKPiA+ID4+ICAgIEREUl9TRFJBTTogbWVtb3J5QDAgewo+ID4gPj4gICAg
ICAgICAgICBkZXZpY2VfdHlwZSA9ICJtZW1vcnkiOwo+ID4gPj4gICAgICAgICAgICByZWcgPSA8
IDAgODAwMDAwMCA+Owo+ID4gPj4gICAgfSA7Cj4gPiA+PiAgICBjaG9zZW4gewo+ID4gPj4gICAg
ICAgICAgICBib290YXJncyA9ICJjb25zb2xlPXR0eVMwLDk2MDAgaXA9b24KPiA+IG5mc3Jvb3Q9
MTcyLjE2LjQwLjc2Oi92MnBjbGllbnRzL2pobDI2LHRjcCI7Cj4gPiA+PiAgICAgICAgICAgIGxp
bnV4LHN0ZG91dC1wYXRoID0gIi9wbGJAMC9zZXJpYWxAODNlMDAwMDAiOwo+ID4gPj4gICAgfSA7
Cj4gPiA+PiAgICBjcHVzIHsKPiA+ID4+ICAgICAgICAgICAgI2FkZHJlc3MtY2VsbHMgPSA8MT47
Cj4gPiA+PiAgICAgICAgICAgICNjcHVzID0gPDE+Owo+ID4gPj4gICAgICAgICAgICAjc2l6ZS1j
ZWxscyA9IDwwPjsKPiA+ID4+ICAgICAgICAgICAgcHBjNDA1XzA6IGNwdUAwIHsKPiA+ID4+ICAg
ICAgICAgICAgICAgICAgICBjbG9jay1mcmVxdWVuY3kgPSA8MTFlMWEzMDA+Owo+ID4gPj4gICAg
ICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiUG93ZXJQQyw0MDUiLCAiaWJtLHBwYzQwNSI7
Cj4gPiA+PiAgICAgICAgICAgICAgICAgICAgZC1jYWNoZS1saW5lLXNpemUgPSA8MjA+Owo+ID4g
Pj4gICAgICAgICAgICAgICAgICAgIGQtY2FjaGUtc2l6ZSA9IDw0MDAwPjsKPiA+ID4+ICAgICAg
ICAgICAgICAgICAgICBkZXZpY2VfdHlwZSA9ICJjcHUiOwo+ID4gPj4gICAgICAgICAgICAgICAg
ICAgIGktY2FjaGUtbGluZS1zaXplID0gPDIwPjsKPiA+ID4+ICAgICAgICAgICAgICAgICAgICBp
LWNhY2hlLXNpemUgPSA8NDAwMD47Cj4gPiA+PiAgICAgICAgICAgICAgICAgICAgbW9kZWwgPSAi
UG93ZXJQQyw0MDUiOwo+ID4gPj4gICAgICAgICAgICAgICAgICAgIHJlZyA9IDwwPjsKPiA+ID4+
ICAgICAgICAgICAgICAgICAgICB0aW1lYmFzZS1mcmVxdWVuY3kgPSA8MTFlMWEzMDA+Owo+ID4g
Pj4gICAgICAgICAgICAgICAgICAgIHhsbngsYXB1LWNvbnRyb2wgPSA8ZGUwMD47Cj4gPiA+PiAg
ICAgICAgICAgICAgICAgICAgeGxueCxhcHUtdWRpLTEgPSA8YTE4OTgzPjsKPiA+ID4+ICAgICAg
ICAgICAgICAgICAgICB4bG54LGFwdS11ZGktMiA9IDxhMzg5ODM+Owo+ID4gPj4gICAgICAgICAg
ICAgICAgICAgIHhsbngsYXB1LXVkaS0zID0gPGE1ODljMz47Cj4gPiA+PiAgICAgICAgICAgICAg
ICAgICAgeGxueCxhcHUtdWRpLTQgPSA8YTc4OWMzPjsKPiA+ID4+ICAgICAgICAgICAgICAgICAg
ICB4bG54LGFwdS11ZGktNSA9IDxhOThjMDM+Owo+ID4gPj4gICAgICAgICAgICAgICAgICAgIHhs
bngsYXB1LXVkaS02ID0gPGFiOGMwMz47Cj4gPiA+PiAgICAgICAgICAgICAgICAgICAgeGxueCxh
cHUtdWRpLTcgPSA8YWQ4YzQzPjsKPiA+ID4+ICAgICAgICAgICAgICAgICAgICB4bG54LGFwdS11
ZGktOCA9IDxhZjhjNDM+Owo+ID4gPj4gICAgICAgICAgICAgICAgICAgIHhsbngsZGV0ZXJtaW5p
c3RpYy1tdWx0ID0gPDA+Owo+ID4gPj4gICAgICAgICAgICAgICAgICAgIHhsbngsZGlzYWJsZS1v
cGVyYW5kLWZvcndhcmRpbmcgPSA8MT47Cj4gPiA+PiAgICAgICAgICAgICAgICAgICAgeGxueCxm
YXN0ZXN0LXBsYi1jbG9jayA9ICJEUExCMCI7Cj4gPiA+PiAgICAgICAgICAgICAgICAgICAgeGxu
eCxnZW5lcmF0ZS1wbGItdGltZXNwZWNzID0gPDE+Owo+ID4gPj4gICAgICAgICAgICAgICAgICAg
IHhsbngsbW11LWVuYWJsZSA9IDwxPjsKPiA+ID4+ICAgICAgICAgICAgICAgICAgICB4bG54LHB2
ci1oaWdoID0gPDA+Owo+ID4gPj4gICAgICAgICAgICAgICAgICAgIHhsbngscHZyLWxvdyA9IDww
PjsKPiA+ID4+ICAgICAgICAgICAgfSA7Cj4gPiA+PiAgICB9IDsKPiA+ID4+ICAgIHBsYjogcGxi
QDAgewo+ID4gPj4gICAgICAgICAgICAjYWRkcmVzcy1jZWxscyA9IDwxPjsKPiA+ID4+ICAgICAg
ICAgICAgI3NpemUtY2VsbHMgPSA8MT47Cj4gPiA+PiAgICAgICAgICAgIGNvbXBhdGlibGUgPSAi
eGxueCxwbGItdjQ2LTEuMDIuYSI7Cj4gPiA+PiAgICAgICAgICAgIHJhbmdlcyA7Cj4gPiA+PiAg
ICAgICAgICAgIElJQ19FRVBST006IGkyY0A4MTYwMDAwMCB7Cj4gPiA+PiAgICAgICAgICAgICAg
ICAgICAgY29tcGF0aWJsZSA9ICJ4bG54LHhwcy1paWMtMi4wMC5hIjsKPiA+ID4+ICAgICAgICAg
ICAgICAgICAgICBpbnRlcnJ1cHQtcGFyZW50ID0gPCZ4cHNfaW50Y18wPjsKPiA+ID4+ICAgICAg
ICAgICAgICAgICAgICBpbnRlcnJ1cHRzID0gPCA0IDIgPjsKPiA+ID4+ICAgICAgICAgICAgICAg
ICAgICByZWcgPSA8IDgxNjAwMDAwIDEwMDAwID47Cj4gPiA+PiAgICAgICAgICAgICAgICAgICAg
eGxueCxjbGstZnJlcSA9IDw1ZjVlMTAwPjsKPiA+ID4+ICAgICAgICAgICAgICAgICAgICB4bG54
LGZhbWlseSA9ICJ2aXJ0ZXg0IjsKPiA+ID4+ICAgICAgICAgICAgICAgICAgICB4bG54LGdwby13
aWR0aCA9IDwxPjsKPiA+ID4+ICAgICAgICAgICAgICAgICAgICB4bG54LGlpYy1mcmVxID0gPDE4
NmEwPjsKPiA+ID4+ICAgICAgICAgICAgICAgICAgICB4bG54LHNjbC1pbmVydGlhbC1kZWxheSA9
IDwwPjsKPiA+ID4+ICAgICAgICAgICAgICAgICAgICB4bG54LHNkYS1pbmVydGlhbC1kZWxheSA9
IDwwPjsKPiA+ID4+ICAgICAgICAgICAgICAgICAgICB4bG54LHRlbi1iaXQtYWRyID0gPDA+Owo+
ID4gPj4gICAgICAgICAgICB9IDsKPiA+ID4+ICAgICAgICAgICAgTEVEc180Qml0OiBncGlvQDgx
NDAwMDAwIHsKPiA+ID4+ICAgICAgICAgICAgICAgICAgICBjb21wYXRpYmxlID0gInhsbngseHBz
LWdwaW8tMS4wMC5hIjsKPiA+ID4+ICAgICAgICAgICAgICAgICAgICBpbnRlcnJ1cHQtcGFyZW50
ID0gPCZ4cHNfaW50Y18wPjsKPiA+ID4+ICAgICAgICAgICAgICAgICAgICBpbnRlcnJ1cHRzID0g
PCA1IDIgPjsKPiA+ID4+ICAgICAgICAgICAgICAgICAgICByZWcgPSA8IDgxNDAwMDAwIDEwMDAw
ID47Cj4gPiA+PiAgICAgICAgICAgICAgICAgICAgeGxueCxhbGwtaW5wdXRzID0gPDA+Owo+ID4g
Pj4gICAgICAgICAgICAgICAgICAgIHhsbngsYWxsLWlucHV0cy0yID0gPDA+Owo+ID4gPj4gICAg
ICAgICAgICAgICAgICAgIHhsbngsZG91dC1kZWZhdWx0ID0gPDA+Owo+ID4gPj4gICAgICAgICAg
ICAgICAgICAgIHhsbngsZG91dC1kZWZhdWx0LTIgPSA8MD47Cj4gPiA+PiAgICAgICAgICAgICAg
ICAgICAgeGxueCxmYW1pbHkgPSAidmlydGV4NCI7Cj4gPiA+PiAgICAgICAgICAgICAgICAgICAg
eGxueCxncGlvLXdpZHRoID0gPDQ+Owo+ID4gPj4gICAgICAgICAgICAgICAgICAgIHhsbngsaW50
ZXJydXB0LXByZXNlbnQgPSA8MT47Cj4gPiA+PiAgICAgICAgICAgICAgICAgICAgeGxueCxpcy1i
aWRpciA9IDwxPjsKPiA+ID4+ICAgICAgICAgICAgICAgICAgICB4bG54LGlzLWJpZGlyLTIgPSA8
MT47Cj4gPiA+PiAgICAgICAgICAgICAgICAgICAgeGxueCxpcy1kdWFsID0gPDA+Owo+ID4gPj4g
ICAgICAgICAgICAgICAgICAgIHhsbngsdHJpLWRlZmF1bHQgPSA8ZmZmZmZmZmY+Owo+ID4gPj4g
ICAgICAgICAgICAgICAgICAgIHhsbngsdHJpLWRlZmF1bHQtMiA9IDxmZmZmZmZmZj47Cj4gPiA+
PiAgICAgICAgICAgIH0gOwo+ID4gPj4gICAgICAgICAgICBSUzIzMl9VYXJ0OiBzZXJpYWxAODNl
MDAwMDAgewo+ID4gPj4gICAgICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAieGxueCx4cHMt
dWFydDE2NTUwLTIuMDAuYSI7Cj4gPiA+PiAvLyAgICAgICAgICAgICAgICAgY29tcGF0aWJsZSA9
ICJuczE2NTUwIjsKPiA+ID4+ICAgICAgICAgICAgICAgICAgICBkZXZpY2VfdHlwZSA9ICJzZXJp
YWwiOwo+ID4gPj4gICAgICAgICAgICAgICAgICAgIGludGVycnVwdC1wYXJlbnQgPSA8Jnhwc19p
bnRjXzA+Owo+ID4gPj4gICAgICAgICAgICAgICAgICAgIGludGVycnVwdHMgPSA8IDYgMiA+Owo+
ID4gPj4gICAgICAgICAgICAgICAgICAgIHJlZyA9IDwgODNlMDAwMDAgMTAwMDAgPjsKPiA+ID4+
ICAgICAgICAgICAgICAgICAgICBjdXJyZW50LXNwZWVkID0gPGQjOTYwMD47Cj4gPiA+PiAgICAg
ICAgICAgICAgICAgICAgY2xvY2stZnJlcXVlbmN5ID0gPGQjMTAwMDAwMDAwPjsgIC8qIGFkZGVk
Cj4gPiBieSBqaGwgKi8KPiA+ID4+ICAgICAgICAgICAgICAgICAgICByZWctc2hpZnQgPSA8Mj47
Cj4gPiA+PiAgICAgICAgICAgICAgICAgICAgeGxueCxmYW1pbHkgPSAidmlydGV4NCI7Cj4gPiA+
PiAgICAgICAgICAgICAgICAgICAgeGxueCxoYXMtZXh0ZXJuYWwtcmNsayA9IDwwPjsKPiA+ID4+
ICAgICAgICAgICAgICAgICAgICB4bG54LGhhcy1leHRlcm5hbC14aW4gPSA8MD47Cj4gPiA+PiAg
ICAgICAgICAgICAgICAgICAgeGxueCxpcy1hLTE2NTUwID0gPDE+Owo+ID4gPj4gICAgICAgICAg
ICB9IDsKPiA+ID4+ICAgICAgICAgICAgU3lzQUNFX0NvbXBhY3RGbGFzaDogc3lzYWNlQDgzNjAw
MDAwIHsKPiA+ID4+ICAgICAgICAgICAgICAgICAgICBjb21wYXRpYmxlID0gInhsbngseHBzLXN5
c2FjZS0xLjAwLmEiOwo+ID4gPj4gICAgICAgICAgICAgICAgICAgIGludGVycnVwdC1wYXJlbnQg
PSA8Jnhwc19pbnRjXzA+Owo+ID4gPj4gICAgICAgICAgICAgICAgICAgIGludGVycnVwdHMgPSA8
IDMgMiA+Owo+ID4gPj4gICAgICAgICAgICAgICAgICAgIHJlZyA9IDwgODM2MDAwMDAgMTAwMDAg
PjsKPiA+ID4+ICAgICAgICAgICAgICAgICAgICB4bG54LGZhbWlseSA9ICJ2aXJ0ZXg0IjsKPiA+
ID4+ICAgICAgICAgICAgICAgICAgICB4bG54LG1lbS13aWR0aCA9IDwxMD47Cj4gPiA+PiAgICAg
ICAgICAgIH0gOwo+ID4gPj4gICAgICAgICAgICBUcmlNb2RlX01BQ19HTUlJOiB4cHMtbGwtdGVt
YWNAODFjMDAwMDAgewo+ID4gPj4gICAgICAgICAgICAgICAgICAgICNhZGRyZXNzLWNlbGxzID0g
PDE+Owo+ID4gPj4gICAgICAgICAgICAgICAgICAgICNzaXplLWNlbGxzID0gPDE+Owo+ID4gPj4g
ICAgICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAieGxueCxjb21wb3VuZCI7Cj4gPiA+PiAg
ICAgICAgICAgICAgICAgICAgZXRoZXJuZXRAODFjMDAwMDAgewo+ID4gPj4gICAgICAgICAgICAg
ICAgICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJ4bG54LHhwcy1sbC10ZW1hYy0KPiA+IDEuMDEu
YSI7Cj4gPiA+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBkZXZpY2VfdHlwZSA9ICJuZXR3
b3JrIjsKPiA+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludGVycnVwdC1wYXJlbnQg
PQo+ID4gPCZ4cHNfaW50Y18wPjsKPiA+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlu
dGVycnVwdHMgPSA8IDIgMiA+Owo+ID4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgbGxp
bmstY29ubmVjdGVkID0gPCZQSU0yPjsKPiA+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg
IGxvY2FsLW1hYy1hZGRyZXNzID0gWyAwMiAwMCAwMAo+ID4gMDAgMDAgMDEgXTsKPiA+ID4+ICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHJlZyA9IDwgODFjMDAwMDAgNDAgPjsKPiA+ID4+ICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHhsbngsYnVzMmNvcmUtY2xrLXJhdGlvID0gPDE+Owo+
ID4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgeGxueCxwaHktdHlwZSA9IDwxPjsKPiA+
ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHhsbngscGh5YWRkciA9IDwxPjsKPiA+ID4+
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHhsbngscnhjc3VtID0gPDA+Owo+ID4gPj4gICAg
ICAgICAgICAgICAgICAgICAgICAgICAgeGxueCxyeGZpZm8gPSA8MTAwMD47Cj4gPiA+PiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB4bG54LHRlbWFjLXR5cGUgPSA8MT47Cj4gPiA+PiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB4bG54LHR4Y3N1bSA9IDwwPjsKPiA+ID4+ICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHhsbngsdHhmaWZvID0gPDEwMDA+Owo+ID4gPj4gICAgICAgICAg
ICAgICAgICAgIH0gOwo+ID4gPj4gICAgICAgICAgICB9IDsKPiA+ID4+ICAgICAgICAgICAgbXBt
Y0AwIHsKPiA+ID4+ICAgICAgICAgICAgICAgICAgICAjYWRkcmVzcy1jZWxscyA9IDwxPjsKPiA+
ID4+ICAgICAgICAgICAgICAgICAgICAjc2l6ZS1jZWxscyA9IDwxPjsKPiA+ID4+ICAgICAgICAg
ICAgICAgICAgICBjb21wYXRpYmxlID0gInhsbngsbXBtYy00LjAwLmEiOwo+ID4gPj4gICAgICAg
ICAgICAgICAgICAgIFBJTTI6IHNkbWFAODQ2MDAxMDAgewo+ID4gPj4gICAgICAgICAgICAgICAg
ICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJ4bG54LGxsLWRtYS0KPiA+IDEuMDAuYSI7Cj4gPiA+
PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnRlcnJ1cHQtcGFyZW50ID0KPiA+IDwmeHBz
X2ludGNfMD47Cj4gPiA+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnRlcnJ1cHRzID0g
PCAxIDIgMCAyID47Cj4gPiA+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICByZWcgPSA8IDg0
NjAwMTAwIDgwID47Cj4gPiA+PiAgICAgICAgICAgICAgICAgICAgfSA7Cj4gPiA+PiAgICAgICAg
ICAgIH0gOwo+ID4gPj4gICAgICAgICAgICB4cHNfYnJhbV9pZl9jbnRscl8xOiB4cHMtYnJhbS1p
Zi1jbnRsckBmZmZmZTAwMCB7Cj4gPiA+PiAgICAgICAgICAgICAgICAgICAgY29tcGF0aWJsZSA9
ICJ4bG54LHhwcy1icmFtLWlmLWNudGxyLQo+ID4gMS4wMC5hIjsKPiA+ID4+ICAgICAgICAgICAg
ICAgICAgICByZWcgPSA8IGZmZmZlMDAwIDIwMDAgPjsKPiA+ID4+ICAgICAgICAgICAgICAgICAg
ICB4bG54LGZhbWlseSA9ICJ2aXJ0ZXg0IjsKPiA+ID4+ICAgICAgICAgICAgfSA7Cj4gPiA+PiAg
ICAgICAgICAgIHhwc19pbnRjXzA6IGludGVycnVwdC1jb250cm9sbGVyQDgxODAwMDAwIHsKPiA+
ID4+ICAgICAgICAgICAgICAgICAgICAjaW50ZXJydXB0LWNlbGxzID0gPDI+Owo+ID4gPj4gICAg
ICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAieGxueCx4cHMtaW50Yy0xLjAwLmEiOwo+ID4g
Pj4gICAgICAgICAgICAgICAgICAgIGludGVycnVwdC1jb250cm9sbGVyIDsKPiA+ID4+ICAgICAg
ICAgICAgICAgICAgICByZWcgPSA8IDgxODAwMDAwIDEwMDAwID47Cj4gPiA+PiAgICAgICAgICAg
ICAgICAgICAgeGxueCxudW0taW50ci1pbnB1dHMgPSA8Nz47Cj4gPiA+PiAgICAgICAgICAgIH0g
Owo+ID4gPj4gICAgfSA7Cj4gPiA+PiAgICBwcGM0MDVfMF9kcGxiMTogcGxiQDEgewo+ID4gPj4g
ICAgICAgICAgICAjYWRkcmVzcy1jZWxscyA9IDwxPjsKPiA+ID4+ICAgICAgICAgICAgI3NpemUt
Y2VsbHMgPSA8MT47Cj4gPiA+PiAgICAgICAgICAgIGNvbXBhdGlibGUgPSAieGxueCxwbGItdjQ2
LTEuMDIuYSI7Cj4gPiA+PiAgICAgICAgICAgIHJhbmdlcyA7Cj4gPiA+PiAgICB9IDsKPiA+ID4+
IH0gIDsKPiA+ID4+Cj4gPiA+Pgo+ID4gPj4KPiA+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tCj4gPiA+PiBGcm9tOiBNYWdudXMgSGpvcnRoIFttYWlsdG86bWhAb21uaXN5cy5zZV0KPiA+
ID4+IFNlbnQ6IFNhdHVyZGF5LCBNYXJjaCAyOSwgMjAwOCA2OjU0IEFNCj4gPiA+PiBUbzogZ2l0
Cj4gPiA+PiBDYzogbGludXhwcGMtZW1iZWRkZWRAb3psYWJzLm9yZwo+ID4gPj4gU3ViamVjdDog
WGlsaW54IExMVEVNQUMgZHJpdmVyIGlzc3Vlcwo+ID4gPj4KPiA+ID4+IEhpLAo+ID4gPj4KPiA+
ID4+IEknbSBoYXZpbmcgc29tZSBuZXR3b3JraW5nIHRyb3VibGVzIHdpdGggdGhlIFhpbGlueCBM
TFRFTUFDIGRyaXZlciBmcm9tCj4gdGhlCj4gPiA+PiBYaWxpbnggTGludXggZ2l0IHRyZWUgKHBv
d2VycGMgYXJjaCkgb24gYW4gTUw0MDMgYm9hcmQuIEVESzkuMlNQMiwKPiA+ID4+IHhwc19sbF90
ZW1hYyB2MS4wMC5iCj4gPiA+Pgo+ID4gPj4gVGhlIHdlaXJkIHRoaW5nIGlzLCB0aGF0IGl0IHNv
cnQgb2YgaGFsZiB3b3Jrcy4gSXQgc3VjY2Vzc2Z1bGx5IG1ha2VzIGEKPiBESENQCj4gPiA+PiBy
ZXF1ZXN0IGFuZCBnZXRzIGl0cyBJUCBhZGRyZXNzLiBJIHRyaWVkIHNldHRpbmcgdXAgYSB0ZnRw
ZCBzZXJ2ZXIsIGFuZAo+IEkgY2FuCj4gPiA+PiBzZWUgVURQIHJlcXVlc3RzIGNvbWluZyBpbiBi
dXQgdGhlIHJlc3BvbnNlIGRvZXNuJ3Qgc2VlbSB0byBjb21lIG91dC4gSQo+IGFsc28KPiA+ID4+
IHRyaWVkIHJ1bm5pbmcgYSBUQ1Agc2VydmVyIG9uIHRoZSBib2FyZCwgYW5kIGl0IGNhbiBzZWUg
YW5kIGFjY2VwdAo+IGluY29taW5nCj4gPiA+PiBjb25uZWN0aW9ucyBidXQgYWZ0ZXIgdGhhdCBu
byBkYXRhIHNlZW1zIHRvIGdldCB0aHJvdWdoLiBJIGNhbiBwaW5nIG91dAo+IGFuZAo+ID4gPj4g
Z2V0IGFyb3VuZCA0MCUgcGFja2V0IGxvc3MuCj4gPiA+Pgo+ID4gPj4gTG9va2luZyBhdCAvcHJv
Yy9pbnRlcnJ1cHRzLCBJIGNhbiBzZWUgYm90aCBUeERtYSBpbnRlcnJ1cHRzIGFuZCBSeERtYQo+
ID4gPj4gaW50ZXJydXB0cy4gTm8gZXRoMCBpbnRlcnJ1cHRzIGJ1dCB0aGF0IHNlZW1zIHRvIGJl
IE9LIGp1ZGdpbmcgYnkgdGhlCj4gZHJpdmVyCj4gPiA+PiBzb3VyY2UgY29tbWVudHMuIElmY29u
ZmlnIHNob3dzIG5vIGNvbGxpc3Rpb25zLCBubyBkcm9wcGVkIHBhY2tldHMsIG5vCj4gPiBlcnJv
cnMsCj4gPiA+PiBzbyB0aGUgc3lzdGVtIHNlZW1zIHRvIHRoaW5rIHRoYXQgZXZlcnl0aGluZyBp
cyBPSy4KPiA+ID4+Cj4gPiA+PiBDbHVlcyBhbnlvbmU/IEknbSBzdGFydGluZyB0byBydW4gb3V0
IG9mIGlkZWFzLi4uCj4gPiA+Pgo+ID4gPj4gQmVzdCByZWdhcmRzLAo+ID4gPj4gTWFnbnVzCj4g
PiA+Pgo+ID4gPj4KPiA+ID4+IC0tCj4gPiA+Pgo+ID4gPj4gTWFnbnVzIEhqb3J0aCwgTS5TYy4K
PiA+ID4+IE9tbmlzeXMgSW5zdHJ1bWVudHMgQUIKPiA+ID4+IEdydXZnYXRhbiA4Cj4gPiA+PiBT
RS00MjEgMzAgIFbDpHN0cmEgRnLDtmx1bmRhLCBTV0VERU4KPiA+ID4+IFBob25lOiArNDYgMzEg
NzM0IDM0IDA5Cj4gPiA+PiBGYXg6ICs0NiAzMSA3MzQgMzQgMjkKPiA+ID4+IGh0dHA6Ly93d3cu
b21uaXN5cy5zZQo+ID4gPj4KPiA+ID4KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KPiA+ID4gTGludXhwcGMtZW1iZWRkZWQgbWFpbGluZyBsaXN0
Cj4gPiA+IExpbnV4cHBjLWVtYmVkZGVkQG96bGFicy5vcmcKPiA+ID4gaHR0cHM6Ly9vemxhYnMu
b3JnL21haWxtYW4vbGlzdGluZm8vbGludXhwcGMtZW1iZWRkZWQKPiBfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IExpbnV4cHBjLWVtYmVkZGVkIG1haWxp
bmcgbGlzdAo+IExpbnV4cHBjLWVtYmVkZGVkQG96bGFicy5vcmcKPiBodHRwczovL296bGFicy5v
cmcvbWFpbG1hbi9saXN0aW5mby9saW51eHBwYy1lbWJlZGRlZAo+Cj4KPiAtLQo+IEpvaGFubiBC
YXVkeQo+IGpvaGFhaG5AZ21haWwuY29tCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KPiDnlKggV2luZG93cyBMaXZlIFNwYWNlcyDlsZXnpLrkuKrmgKfoh6rmiJHvvIzkuI7lpb3l
j4vliIbkuqvnlJ/mtLvvvIEg5LqG6Kej5pu05aSa5L+h5oGv77yBCgoKCi0tIApKb2hhbm4gQmF1
ZHkKam9oYWFobkBnbWFpbC5jb20K
^ permalink raw reply
* Re: [BUG] 2.6.25-rc8-mm1 kernel panic while bootup on powerpc
From: Andy Whitcroft @ 2008-04-04 9:24 UTC (permalink / raw)
To: Andrew Morton
Cc: linuxppc-dev, Balbir Singh, Badari Pulavarty, linux-kernel,
Kamalesh Babulal
In-Reply-To: <20080401233909.23220623.akpm@linux-foundation.org>
On Tue, Apr 01, 2008 at 11:39:09PM -0700, Andrew Morton wrote:
> On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>
> > Hi Andrew,
> >
> > The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
> >
> > [ 0.000000] ------------[ cut here ]------------
> > [ 0.000000] kernel BUG at arch/powerpc/mm/init_64.c:240!
> > [ 0.000000] Oops: Exception in kernel mode, sig: 5 [#1]
> > [ 0.000000] SMP NR_CPUS=32 NUMA PowerMac
> > [ 0.000000] Modules linked in:
> > [ 0.000000] NIP: c0000000003d1dcc LR: c0000000003d1dc4 CTR: c00000000002b6ac
> > [ 0.000000] REGS: c00000000049b960 TRAP: 0700 Not tainted (2.6.25-rc8-mm1-autokern1)
> > [ 0.000000] MSR: 9000000000021032 <ME,IR,DR> CR: 44000088 XER: 20000000
> > [ 0.000000] TASK = c0000000003f9c90[0] 'swapper' THREAD: c000000000498000 CPU: 0
> > [ 0.000000] GPR00: c0000000003d1dc4 c00000000049bbe0 c0000000004989d0 0000000000000001
> > [ 0.000000] GPR04: d59aca40f0000000 000000000b000000 0000000000000010 0000000000000000
> > [ 0.000000] GPR08: 0000000000000004 0000000000000001 c00000027e520800 c0000000004bf0f0
> > [ 0.000000] GPR12: c0000000004bf020 c0000000003fa900 0000000000000000 0000000000000000
> > [ 0.000000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > [ 0.000000] GPR20: 0000000000000000 0000000000000000 0000000000000000 4000000001400000
> > [ 0.000000] GPR24: 00000000017d64b0 c0000000003d6250 0000000000000000 c000000000504000
> > [ 0.000000] GPR28: 0000000000000000 cf000000001f8000 0000000001000000 cf00000000000000
> > [ 0.000000] NIP [c0000000003d1dcc] .vmemmap_populate+0xb8/0xf4
> > [ 0.000000] LR [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4
> > [ 0.000000] Call Trace:
> > [ 0.000000] [c00000000049bbe0] [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4 (unreliable)
> > [ 0.000000] [c00000000049bc70] [c0000000003d2ee8] .sparse_mem_map_populate+0x38/0x60
> > [ 0.000000] [c00000000049bd00] [c0000000003c242c] .sparse_early_mem_map_alloc+0x54/0x94
> > [ 0.000000] [c00000000049bd90] [c0000000003c250c] .sparse_init+0xa0/0x20c
> > [ 0.000000] [c00000000049be50] [c0000000003ab7d0] .setup_arch+0x1ac/0x218
> > [ 0.000000] [c00000000049bee0] [c0000000003a36ac] .start_kernel+0xe0/0x3fc
> > [ 0.000000] [c00000000049bf90] [c000000000008594] .start_here_common+0x54/0xc0
> > [ 0.000000] Instruction dump:
> > [ 0.000000] 7fe3fb78 7ca02a14 4082000c 3860fff4 4800003c e92289c8 e96289c0 e9090002
> > [ 0.000000] e8eb0002 4bc575cd 60000000 78630fe0 <0b030000> 7ffff214 7fbfe840 7fe3fb78
> > [ 0.000000] ---[ end trace 31fd0ba7d8756001 ]---
> > [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
> >
>
> int __meminit vmemmap_populate(struct page *start_page,
> unsigned long nr_pages, int node)
> {
> unsigned long mode_rw;
> unsigned long start = (unsigned long)start_page;
> unsigned long end = (unsigned long)(start_page + nr_pages);
> unsigned long page_size = 1 << mmu_psize_defs[mmu_linear_psize].shift;
>
> mode_rw = _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
>
> /* Align to the page size of the linear mapping. */
> start = _ALIGN_DOWN(start, page_size);
>
> for (; start < end; start += page_size) {
> int mapped;
> void *p;
>
> if (vmemmap_populated(start, page_size))
> continue;
>
> p = vmemmap_alloc_block(page_size, node);
> if (!p)
> return -ENOMEM;
>
> pr_debug("vmemmap %08lx allocated at %p, physical %08lx.\n",
> start, p, __pa(p));
>
> mapped = htab_bolt_mapping(start, start + page_size,
> __pa(p), mode_rw, mmu_linear_psize,
> mmu_kernel_ssize);
> =====> BUG_ON(mapped < 0);
> }
>
> return 0;
> }
>
> Beats me. pseries? Badari has been diddling with the bolted memory code
> in git-powerpc...
It does look like this is resolved with the patch below, if my testing
is to be believed (results out on TKO):
[PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
From: Yinghai Lu <yhlu.kernel@gmail.com>
Andrew, I believe you just sucked that up into -mm.
-apw
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH] RTAS - adapt procfs interface
From: Christoph Hellwig @ 2008-04-04 9:15 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Nathan Lynch, cbe-oss-dev, Christoph Hellwig
In-Reply-To: <200804040739.30139.arnd@arndb.de>
On Fri, Apr 04, 2008 at 07:39:29AM +0200, Arnd Bergmann wrote:
> Well we still have the regression against 2.6.23 and I'd like to
> get that fixed in 2.6.25 if it's not already release by the time
> we get there.
>
> Would you prefer using Nathan's proper patch for 2.6.25, or do
> that for 2.6.26 instead, perhaps using Jens' patch as a quick
> fix, as Nathan suggested?
Nathan's patch is not correct either because each file needs it's own
open count. But something similar would be correct.
^ permalink raw reply
* Carol Dann is out of the office.
From: Sheau-Jiuan Dann @ 2008-04-04 8:00 UTC (permalink / raw)
To: linuxppc-dev
I will be out of the office starting 04/04/2008 and will not return
until 04/07/2008.
Should you need any assistance on RS6000/AIX/TSM , please contact :
Mr. Obaid Farghani at 201-413-8028 (ofarghani@us.mufg.jp), Mr. Paul
Giglio at 201-413-8280 (pgiglio@us.mufg.jp) or Mr. Gary Fatone at
201-413-8955 (gfatone@us.mufg.jp )
I will respond to your message when I return.
Regards,
Carol
-----------------------------------------
This electronic mail message, and any of the accompanying
documents, may contain confidential or privileged information. Any
unauthorized disclosure or distribution of such information is
strictly prohibited. If you are not the intended recipient of this
message, please notify the sender immediately and destroy the
message. Messages sent through electronic media may be subject to
delays or unauthorized alterations. Neither The Bank of
Tokyo-Mitsubishi UFJ, Ltd. nor any of its affiliates is responsible
for any such delay or alteration. This message may contain a
commercial advertisement or promotion of a commercial product or
service. If you do not wish to receive messages of this kind from
the sender in the future, please reply to this message and type
"REMOVE MY EMAIL ADDRESS" in the subject field, or write to the
sender at 1251 Avenue of the Americas, New York, NY 10020-1104.
^ permalink raw reply
* Re: [PATCH 2/11] cell: generalize io-workarounds code
From: Benjamin Herrenschmidt @ 2008-04-04 7:50 UTC (permalink / raw)
To: Ishizaki Kou; +Cc: linuxppc-dev, paulus
In-Reply-To: <20080404.154232.-1300528451.kouish@swc.toshiba.co.jp>
On Fri, 2008-04-04 at 15:42 +0900, Ishizaki Kou wrote:
>
> As you pointed, spider I/O functions in Cell blades need 2 step
> indirections by our patch. Shall I make another one for Cell blades
> whose spider I/O functions need one step indirection?
> (But you will need 2 step indirections when you use PCI-ex.)
I think the blades will need the same stuff as celleb since it's
possible to use the PCI-Express on them too.
Maybe an option is to do a if () / else statement rather than a function
pointer in there, it would at least be cheaper in term of CPU cycle
don't you think ? Anyway, do as you prefer.
Cheers,
Ben.
^ permalink raw reply
* [PATCH] [v2] Add idle wait support for 44x platforms
From: Jerone Young @ 2008-04-04 7:06 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kvm-ppc-devel
# 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;
+
+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);
+ /* return to initial state */
+ mtmsr(msr_save);
+}
+
+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 < sizeof(modes)/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: [PATCH 2/11] cell: generalize io-workarounds code
From: Ishizaki Kou @ 2008-04-04 6:42 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, paulus
In-Reply-To: <1207134052.10388.251.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Wed, 2008-04-02 at 19:52 +0900, Ishizaki Kou wrote:
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > > > As you said, if read/write/in/out functions take device parameter,
> > > > taking I/O function pointers into the dev_archdata structure should be
> > > > the best solution. But they don't take device parameter, and they must
> > > > search I/O function pointers with address parameter. I think it's
> > > > better they search pointers from bus bridges, because access mothod
> > > > for a device on its parent bus bridge, not device itself.
> > >
> > > What I meant is that if the pointers are in dev_archdata, we can
> > > populate with a different set of pointers for PCI vs. PCI-E.
> >
> > I'm afraid I misunderstood your opinion.
> >
> > My concern is how to find a device by address when I/O function
> > pointers are in dev_archdata.
> >
> > You must select the appropriate device with an address, because all
> > I/O functions, read/write/in/out don't have device parameter. If the
> > address is in MMIO space, you can set 'token' to the address to select
> > the device. But in IO space, you can't set 'token' to the I/O port
> > address. Thefore you must scan all devices to select the device.
> >
> > Do you have any better solution?
>
> No, you are right. The EEH code has a way to go back to the device but
> it has significant overhead. Let's stick to your current approach.
Thank you very much.
As you pointed, spider I/O functions in Cell blades need 2 step
indirections by our patch. Shall I make another one for Cell blades
whose spider I/O functions need one step indirection?
(But you will need 2 step indirections when you use PCI-ex.)
Best regards,
Kou Ishizaki
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH] Cell OProfile: SPU mutex lock fix
From: Arnd Bergmann @ 2008-04-04 6:38 UTC (permalink / raw)
To: cbe-oss-dev; +Cc: linuxppc-dev, cel, linux-kernel, Carl Love
In-Reply-To: <1207155775.7132.414.camel@carll-linux-desktop>
On Wednesday 02 April 2008, Carl Love wrote:
> On Wed, 2008-04-02 at 07:21 +0200, Arnd Bergmann wrote:
> > On Tuesday 25 March 2008, Carl Love wrote:
> > > This patch fixes a bug in the code that records the SPU data and
> > > context switches. The buffer_mutex lock must be held when the
> > > kernel is adding data to the buffer between the kernel and the
> > > OProfile daemon. The lock is not being held in the current code
> > > base. This patch fixes the bug using work queues. The data to
> > > be passed to the daemon is caputured by the interrupt handler.
> > > The workqueue function is invoked to grab the buffer_mutex lock
> > > and add the data to the buffer.
> >
> > So what was the exact bug you're fixing with this? There was no
> > buffer_mutex before, so why do you need it now? Can't this be a
> > spinlock so you can get it from interrupt context instead of
> > using a workqueue?
>
> The generic OProfile code defines a mutex lock, called buffer_mutex, to
> protect the kernel/daemon data buffer from being writen by the kernal
> and simultaneously read by the Daemon. When adding a PPU sample the
> oprofile routine oprofile_add_ext_sample(pc, regs, i, is_kernel) is
> called from the interrupt context to request the sample be stored. The
> generic oprofile code takes care of passing the data to a non interrupt
> context where the mutex lock is held and the necessary sequence of data
> is written into the kernel/daemon data buffer. However, OProfile does
> not have any built in functions for handling the SPU. Hence, we have to
> implement the code to capture the data in the interrupt context, pass it
> to a non interrupt context and put it into the buffer. This was not
> done correctly in the original implementation. Specifically, the mutex
> lock was not being held.
Ok, I see.
However, I'm pretty sure that the switch notification does not get
called from an atomic context, so you don't need a workqueue for
bringing that into a process context. Doing the context switch
notification directly from the scheduler sounds much better regarding
the impact on the measurement.
> > Never put extern statements in the implementation, they describe the
> > interface between two parts of the code and should be inside of a
> > common header.
> >
> > Why do you want to have your own workqueue instead of using the
> > global one?
>
> It is important that the data get context switch data get recorded as
> quickly as possible to avoid dropping data unnecessarily. The PC
> counter data for each SPU is ignored until the context switch record is
> put into the kernel/daemon buffer. The API documentation says that
> using a private workqueue has better performance then using the global
> workqueue. There is a comment in the code about this, perhaps it is not
> clear enough.
This sounds like an unrelated bug in the implementation. The PC
data should *not* be ignored in any case. As long as the records
get stored in the right order, everything should be fine here.
> > This looks like you want to use a delayed_work rather than building your
> > own out of hrtimer and work. Is there any point why you want to use
> > an hrtimer?
>
> The current implementation uses the hrtimer to schedule when to read the
> trace buffer the next time. This patch does not change how the
> scheduling of the buffer reads is done. Yes, you could change the
> implementation to use workqueues instead. If you feel that it is better
> to use the workqueue then we could make that change. Not sure that
> making that change in this bug fix patch is appropriate. I would need
> to create a second patch for that change.
I would guess that the change from hrtimer to delayed_workqueue is
smaller than the current patch changing from hrtimer to hrtimer plus
workqueue, so I would prefer to have only one changeset.
Since the timer only causes statistical data collection anyway, delaying
it a bit should not have any negative effect on the accuracy of the
measurement, unlike delaying the context switch notification.
> > > -static DEFINE_SPINLOCK(buffer_lock);
> > > +extern struct mutex buffer_mutex;
> > > +extern struct workqueue_struct *oprofile_spu_wq;
> > > +extern int calls_to_record_switch;
> > > +
> >
> > Again, public interfaces need to go to a header file, and should
> > have a name that identifies the interface. "buffer_mutex" is
> > certainly not a suitable name for a kernel-wide global variable!
>
> As stated earlier, the generic OProfile code defines the variable
> "buffer_mutex". Changing the name in the generic OProfile code is
> beyond the scope of this patch.
Ok, didn't see that the name was already part of the main oprofile
driver. However, this makes it even worse: you are accessing data
structures that are clearly not meant to be shared with architecture
code. The fact that it was not declared in a global header file should
have told you that.
I think you should instead add a function to drivers/oprofile/buffer_sync.c
that takes care of moving the data to the common buffer under the right
mutex_lock.
> >
> > > static DEFINE_SPINLOCK(cache_lock);
> > > static int num_spu_nodes;
> > > +
> > > int spu_prof_num_nodes;
> > > int last_guard_val[MAX_NUMNODES * 8];
> > > +int cnt_swtch_processed_flag[MAX_NUMNODES * 8];
> > > +
> > > +struct spus_profiling_code_data_s {
> > > + int num_spu_nodes;
> > > + struct work_struct spu_prof_code_wq;
> > > +} spus_profiling_code_data;
> > > +
> > > +struct spu_context_switch_data_s {
> > > + struct spu *spu;
> > > + unsigned long spu_cookie;
> > > + unsigned long app_dcookie;
> > > + unsigned int offset;
> > > + unsigned long objectId;
> > > + int valid_entry;
> > > +} spu_context_switch_data;
> >
> > I don't understand what these variables are really doing, but
> > having e.g. just one spu_context_switch_data for all the SPUs
> > doesn't seem to make much sense. What happens when two SPUs do
> > a context switch at the same time?
>
> This is the data same data that was being put into the event buffer
> directly from the interrupt context. We need to store the data that is
> only available in the interrupt context so the same data can be put into
> the buffer by the work queue function in the non interrupt context.
> This is the declaration of the data needed per SPU. Below in the
> spu_cntx_sw_data structure, we declare an array of entries so we can
> store the switch data on a per SPU basis as you alluded to.
The spu_context_switch_data and spus_profiling_code_data variables
are also unused, or just write-only. They look like they were left
over after a conversion from a typedef.
> The calls_to_record_switch variable is not used, my mistake for not
> getting it out of the patch. The record_spu_stat_flag is used. It is
> set in the spu_sync_start when SPU profiling is started. The first time
> the work function is called to record SPU context switches it sees the
> flag is set and writes the initial record to the daemon/kernel buffer
> stating that this is an SPU profile run not a PPU profile run. The
> daemon needs to know this as it effects how the postprocessing is done.
> The initial record is only written once.
>
> The spus_context_sw_data structure has the array per SPU for all of the
> interrupt context data that was recorded and needs to be written to the
> kernel/daemon buffer.
An ideal driver should not have *any* global variables at all, but store
all data in the (reference counted) objects it is dealing with, or
just on the stack while it's processing the data.
Storing the context switch information in a global breaks down as soon
as there are multiple context switches taking place for a single
SPU without the workqueue running in between, which is a very likely
scenario if you have high-priority tasks on the SPU.
> > > /* Container for caching information about an active SPU task. */
> > > struct cached_info {
> > > @@ -44,6 +73,8 @@ struct cached_info {
> > > struct kref cache_ref;
> > > };
> > >
> > > +struct workqueue_struct *oprofile_spu_wq;
> > > +
> > > static struct cached_info *spu_info[MAX_NUMNODES * 8];
> >
> > While you're cleaning this up, I guess the cached_info should
> > be moved into a pointer from struct spu as well, instead of
> > having this global variable here.
>
> This would be a functional change and it belongs in a functional change
> patch not in a bug fix patch.
The patch is already far bigger than a simple bug fix, but you're right
in that this part should be separate. Upon reading through the code
again, I noticed that the cached_info is thrown away on each context
switch and rebuilt, which I guess makes it impossible to really profile
the context switch code. In the initial design phase for spu oprofile, we
decided that the information should be cached in the spu_context, which
would not only be much cleaner but also avoid the performance problem.
Do you have any idea why this idea was dropped? Is it still work in
progress to get that functionality right?
> > I would guess that you need one work struct per SPU instead of a global
> > one, if you want to pass the SPU pointer as an argument.
>
> We only need one work struct because we have an array that contains the
> data for each SPU that has done a context switch.
right, but as I explained, the global array is the real problem that should
be fixed.
Arnd <><
^ permalink raw reply
* Re: [kvm-ppc-devel] [PATCH] Add idle wait support for 44x platforms
From: Jerone Young @ 2008-04-04 6:15 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: kvm-ppc-devel, linuxppc-dev, Stuart Yoder
In-Reply-To: <200804031813.59297.hollisb@us.ibm.com>
On Thu, 2008-04-03 at 18:13 -0500, Hollis Blanchard wrote:
> On Thursday 03 April 2008 17:43:02 Jerone Young wrote:
> > # HG changeset patch
> > # User Jerone Young <jyoung5@us.ibm.com>
> > # Date 1207262487 18000
> > # Node ID 7226bef216680748a50327900572c2fbc3e762b0
> > # Parent a5b2aebbc6ebd2439c655f1c047ed7e3c1991ec1
> > 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>
>
> Very nice.
>
> > +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);
> > + /* return to initial state */
> > + mtmsr(msr_save);
> > +}
> > +
> > +int __init ppc44x_idle_init(void)
> > +{
> > + if(of_find_node_by_path("/hypervisor") != NULL) {
> > + /* if we find /hypervisor node is in device tree,
> > + set idle mode to wait */
> > + current_mode = 1; /* wait mode */
> > + }
> > +
> > + ppc_md.power_save = modes[current_mode].entry;
> > + return 0;
> > +}
>
> By the way, watch that space in "if(". Also, you need to call of_node_put()
Got it.
>
> The one thing I don't like is the hardcoded assumption that 1 means "wait".
> Instead, you could do something like this (not even compile-tested):
>
> 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;
> of_node_put(node);
> }
>
> ppc_md.power_save = func;
> return 0;
> }
>
Will change.
> Stuart, we're getting into ePAPR territory. Do you think we need to worry
> about a hypervisor not handling mtmsr(MSR_WE)? In that case, we'd need to be
> more specific than just testing for "/hypervisor". IMHO every hypervisor
> should implement it... but maybe /hypervisor/idle = "wait" would be more
> explicit and therefore better?
This is the problem with just looking for the /hypervisor node. I'll
submit another with all the comments from everyone. But I have a feeling
this is going to lead to a longer discussion.
>
^ permalink raw reply
* Re: [PATCH] Add idle wait support for 44x platforms
From: Jerone Young @ 2008-04-04 6:12 UTC (permalink / raw)
To: Tony Breeds; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <20080403230356.GJ20457@bakeyournoodle.com>
On Fri, 2008-04-04 at 10:03 +1100, Tony Breeds wrote:
> On Thu, Apr 03, 2008 at 05:43:02PM -0500, Jerone Young wrote:
>
> Hi Jerone,
> A few minor nits.
> > 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>
>
> Can you include a diffstat in here?
I think there is a way. I can see if I can do it. Though I may have to
do it out side of my normal hg tools.
>
> > +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 ?
>
> > +int __init ppc44x_idle_init(void)
> > +{
> > + if(of_find_node_by_path("/hypervisor") != NULL) {
> ^ space
> > + /* if we find /hypervisor node is in device tree,
> > + set idle mode to wait */
> > + current_mode = 1; /* wait mode */
> > + }
>
> You don't really need the braces {} here.
>
> > +static int __init idle_param(char *p)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < sizeof(modes)/sizeof(struct sleep_mode); i++) {
>
> ARRAY_SIZE(modes)
I'll do this.
>
> Yours Tony
>
> linux.conf.au http://www.marchsouth.org/
> Jan 19 - 24 2009 The Australian Linux Technical Conference!
>
^ permalink raw reply
* Re: [PATCH] Add idle wait support for 44x platforms
From: Jerone Young @ 2008-04-04 5:59 UTC (permalink / raw)
To: Josh Boyer; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <20080403210027.05339204@zod.rchland.ibm.com>
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 a5b2aebbc6ebd2439c655f1c047ed7e3c1991ec1
>
> As a complete and unrelated side note to the actual patch, wtf is this
> hg stuff? I 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.
>
> > 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.
>
> This huge single line needs fixing in the next version of the patch.
>
> >
> > 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.
>
> In addition to the comments Tony and Hollis made, I have a few of my
> own.
>
> > Signed-off-by: Jerone Young <jyoung5@us.ibm.com>
> >
> > diff --git a/arch/powerpc/platforms/44x/44x.h b/arch/powerpc/platforms/44x/44x.h
> > --- a/arch/powerpc/platforms/44x/44x.h
> > +++ b/arch/powerpc/platforms/44x/44x.h
> > @@ -5,4 +5,6 @@ extern void as1_writeb(u8 data, volatile
> > extern void as1_writeb(u8 data, volatile u8 __iomem *addr);
> > extern void ppc44x_reset_system(char *cmd);
> >
> > +extern int ppc44x_idle_init(void);
> > +
> > #endif /* __POWERPC_PLATFORMS_44X_44X_H */
>
> The changes to this file aren't needed. See below.
>
> > 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,5 @@ obj-$(CONFIG_44x) := misc_44x.o
> > obj-$(CONFIG_44x) := misc_44x.o
> > +obj-$(CONFIG_44x) += idle.o
>
> Just add this target to the already existing obj-(CONFIG_44x)
>
> > obj-$(CONFIG_EBONY) += ebony.o
> > obj-$(CONFIG_TAISHAN) += taishan.o
> > obj-$(CONFIG_BAMBOO) += bamboo.o
> > diff --git a/arch/powerpc/platforms/44x/bamboo.c b/arch/powerpc/platforms/44x/bamboo.c
> > --- a/arch/powerpc/platforms/44x/bamboo.c
> > +++ b/arch/powerpc/platforms/44x/bamboo.c
> > @@ -61,3 +61,5 @@ define_machine(bamboo) {
> > .restart = ppc44x_reset_system,
> > .calibrate_decr = generic_calibrate_decr,
> > };
> > +
> > +machine_late_initcall(bamboo, ppc44x_idle_init);
>
> Ugh. Don't add an init call to every 4xx board like this. It's not
> needed. See below.
>
> > 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
>
> If you're ever going to extend bare metal support for this to 40x, then
> this is the wrong place for it. It should reside in
> arch/powerpc/sysdev/ppc4xx_soc.c in that case.
So I did this at first after your suggestions but then I changed it
because:
- it depended on CONFIG_4xx_SOC .. which I could not figure out who
actually enabled this
- wanted to make a patch that could also go into earlier kernels
>
> > +
> > +#include <linux/of.h>
> > +#include <asm/machdep.h>
> > +
> > +static void ppc44x_idle(void);
>
> This isn't needed. Move the structures below the function.
This can be done
>
> > +struct sleep_mode {
> > + char *name;
> > + void (*entry)(void);
> > +};
> > +
> > +static struct sleep_mode modes[] = {
> > + { .name = "spin", .entry = NULL },
> > + { .name = "wait", .entry = &ppc44x_idle },
> > +};
>
> <snip>
>
> > +int __init ppc44x_idle_init(void)
> > +{
> > + if(of_find_node_by_path("/hypervisor") != NULL) {
> > + /* if we find /hypervisor node is in device tree,
> > + set idle mode to wait */
> > + current_mode = 1; /* wait mode */
> > + }
> > +
> > + ppc_md.power_save = modes[current_mode].entry;
> > + return 0;
>
> I liked Hollis' method of assignment here.
>
> > +}
>
> Add an arch_initcall(ppc44x_idle_init); here and dispense with
> changing every board .c file in the 44x directory.
ah didn't know about arch_initcall
>
> josh
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH] RTAS - adapt procfs interface
From: Arnd Bergmann @ 2008-04-04 5:39 UTC (permalink / raw)
To: cbe-oss-dev; +Cc: Nathan Lynch, Christoph Hellwig, linuxppc-dev
In-Reply-To: <20080404001242.GA19506@lst.de>
On Friday 04 April 2008, Christoph Hellwig wrote:
> On Tue, Apr 01, 2008 at 03:12:20PM +0200, Jens Osterkamp wrote:
> >=20
> > Hi,
> >=20
> > rtas_flash was broken since 2.6.24-rc5. This patch fixes it.
> > I think this is a good bugfix candidate for 2.6.25.
>=20
> NACK. =A0driver should not poke into the internal count member. =A0Just
> provide your own inclusion with a new counter or set/test_bit.
Well we still have the regression against 2.6.23 and I'd like to
get that fixed in 2.6.25 if it's not already release by the time
we get there.
Would you prefer using Nathan's proper patch for 2.6.25, or do
that for 2.6.26 instead, perhaps using Jens' patch as a quick
fix, as Nathan suggested?
Arnd <><
^ permalink raw reply
* Re: [PATCH] PowerPC: MPIC ack interrupts at mpic_teardown_this_cpu()
From: Olof Johansson @ 2008-04-04 5:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1207259436.10388.337.camel@pasglop>
On Fri, Apr 04, 2008 at 08:50:36AM +1100, Benjamin Herrenschmidt wrote:
>
> On Thu, 2008-04-03 at 23:09 +0400, Valentine Barshak 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...
-Olof
^ permalink raw reply
* Re: [PATCH] Add idle wait support for 44x platforms
From: Josh Boyer @ 2008-04-04 2:00 UTC (permalink / raw)
To: Jerone Young; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <7226bef216680748a503.1207262582@thinkpadL>
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 a5b2aebbc6ebd2439c655f1c047ed7e3c1991ec1
As a complete and unrelated side note to the actual patch, wtf is this
hg stuff? I can't really tell what tree you're even basing this off of.
> 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.
This huge single line needs fixing in the next version of the patch.
>
> 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.
In addition to the comments Tony and Hollis made, I have a few of my
own.
> Signed-off-by: Jerone Young <jyoung5@us.ibm.com>
>
> diff --git a/arch/powerpc/platforms/44x/44x.h b/arch/powerpc/platforms/44x/44x.h
> --- a/arch/powerpc/platforms/44x/44x.h
> +++ b/arch/powerpc/platforms/44x/44x.h
> @@ -5,4 +5,6 @@ extern void as1_writeb(u8 data, volatile
> extern void as1_writeb(u8 data, volatile u8 __iomem *addr);
> extern void ppc44x_reset_system(char *cmd);
>
> +extern int ppc44x_idle_init(void);
> +
> #endif /* __POWERPC_PLATFORMS_44X_44X_H */
The changes to this file aren't needed. See below.
> 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,5 @@ obj-$(CONFIG_44x) := misc_44x.o
> obj-$(CONFIG_44x) := misc_44x.o
> +obj-$(CONFIG_44x) += idle.o
Just add this target to the already existing obj-(CONFIG_44x)
> obj-$(CONFIG_EBONY) += ebony.o
> obj-$(CONFIG_TAISHAN) += taishan.o
> obj-$(CONFIG_BAMBOO) += bamboo.o
> diff --git a/arch/powerpc/platforms/44x/bamboo.c b/arch/powerpc/platforms/44x/bamboo.c
> --- a/arch/powerpc/platforms/44x/bamboo.c
> +++ b/arch/powerpc/platforms/44x/bamboo.c
> @@ -61,3 +61,5 @@ define_machine(bamboo) {
> .restart = ppc44x_reset_system,
> .calibrate_decr = generic_calibrate_decr,
> };
> +
> +machine_late_initcall(bamboo, ppc44x_idle_init);
Ugh. Don't add an init call to every 4xx board like this. It's not
needed. See below.
> 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
If you're ever going to extend bare metal support for this to 40x, then
this is the wrong place for it. It should reside in
arch/powerpc/sysdev/ppc4xx_soc.c in that case.
> +
> +#include <linux/of.h>
> +#include <asm/machdep.h>
> +
> +static void ppc44x_idle(void);
This isn't needed. Move the structures below the function.
> +struct sleep_mode {
> + char *name;
> + void (*entry)(void);
> +};
> +
> +static struct sleep_mode modes[] = {
> + { .name = "spin", .entry = NULL },
> + { .name = "wait", .entry = &ppc44x_idle },
> +};
<snip>
> +int __init ppc44x_idle_init(void)
> +{
> + if(of_find_node_by_path("/hypervisor") != NULL) {
> + /* if we find /hypervisor node is in device tree,
> + set idle mode to wait */
> + current_mode = 1; /* wait mode */
> + }
> +
> + ppc_md.power_save = modes[current_mode].entry;
> + return 0;
I liked Hollis' method of assignment here.
> +}
Add an arch_initcall(ppc44x_idle_init); here and dispense with
changing every board .c file in the 44x directory.
josh
^ permalink raw reply
* Re: [PATCH] Add idle wait support for 44x platforms
From: Josh Boyer @ 2008-04-04 1:59 UTC (permalink / raw)
To: Tony Breeds; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <20080403230356.GJ20457@bakeyournoodle.com>
On Fri, 4 Apr 2008 10:03:56 +1100
tony@bakeyournoodle.com (Tony Breeds) wrote:
> > +int __init ppc44x_idle_init(void)
> > +{
> > + if(of_find_node_by_path("/hypervisor") != NULL) {
> ^ space
> > + /* if we find /hypervisor node is in device tree,
> > + set idle mode to wait */
> > + current_mode = 1; /* wait mode */
> > + }
>
> You don't really need the braces {} here.
They are technically not required, but I like them there none the
less because of the multi-line comment. I find it to be better style
personally.
josh
^ permalink raw reply
* has anyone written gfxdriver for graphic controller mb86296??
From: 刘小双 @ 2008-04-04 1:55 UTC (permalink / raw)
To: directfb-dev, linuxppc
[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]
hi,all
has anyone written gfxdriver for graphic controller mb86296?? I have a
problem when I'm writing the gfxdriver that refered to gfxdriver for
sm501. I want to enable the gfxdriver drawing line and filling rectangle and
so on .After finishing the gfxdriver, I run a test program to see if the
gfxdriver could draw a line in the center of the screen and fill a black
rectangle as background, I find there is nothing in display screen where
there should be a line in the center of the screen. here is some part of my
gfxdriver code about line and rectangle:
//draw line with with given coordinate point and color
void de_line(int x1,int y1,int x2,int y2,int c)
{
MB86290WriteFifo(4, (GDC_TYPE_SETCOLORREGISTER << 24) |
(GDC_CMD_BODY_FORE_COLOR << 16), c,
(GDC_TYPE_SETMODEREGISTER << 24) | (GDC_CMD_MDR1 <<
16), (2 << 7));
long cmd2 = (GDC_TYPE_DRAWLINE2I << 24) | 1;
MB86290WriteFifo(6, GDC_TYPE_DRAWLINE2I << 24, x1 << 16, y1 << 16,
cmd2, x2 << 16, y2 << 16);
}
// fill rectangle with given coordinate point and color
void de_fillrect(int x1,int y1,int x2,int y2,int c)
{
int DeltaX;
int DeltaY;
// Determine delta X
if (x2 < x1) {
DeltaX = x1 - x2 + 1;
x1 = x2;
}
else {
DeltaX = x2 - x1 + 1;
}
// Determine delta Y
if (y2 <y1) {
DeltaY = y1 - y2 + 1;
y1 = y2;
}
else {
DeltaY = y2 - y1 + 1;
}
MB86290WriteFifo(2,(GDC_TYPE_SETCOLORREGISTER << 24) |
(GDC_CMD_BODY_FORE_COLOR << 16),c);
MB86290WriteFifo(3,(GDC_TYPE_DRAWRECTP << 24) | (GDC_CMD_BLT_FILL <<
16),(y1 << 16)|x1,(DeltaY<<16)|DeltaX);
}
Thanks,
Xiaoshuang Liu
[-- Attachment #2: Type: text/html, Size: 2433 bytes --]
^ permalink raw reply
* Re: [kvm-ppc-devel] [PATCH] Add idle wait support for 44x platforms
From: Scott Wood @ 2008-04-04 0:17 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: kvm-ppc-devel, linuxppc-dev, Stuart Yoder
In-Reply-To: <200804031813.59297.hollisb@us.ibm.com>
On Thu, Apr 03, 2008 at 06:13:59PM -0500, Hollis Blanchard wrote:
> Stuart, we're getting into ePAPR territory. Do you think we need to worry
> about a hypervisor not handling mtmsr(MSR_WE)? In that case, we'd need to be
> more specific than just testing for "/hypervisor". IMHO every hypervisor
> should implement it... but maybe /hypervisor/idle = "wait" would be more
> explicit and therefore better?
We can't trap on MSR[WE] updates on hypervisor-enabled chips; the write
is silently ignored.
-Scott
^ permalink raw reply
* Re: [PATCH] RTAS - adapt procfs interface
From: Christoph Hellwig @ 2008-04-04 0:12 UTC (permalink / raw)
To: Jens Osterkamp; +Cc: maxim, linuxppc-dev, Paul Mackerras, cbe-oss-dev
In-Reply-To: <200804011512.20834.jens@de.ibm.com>
On Tue, Apr 01, 2008 at 03:12:20PM +0200, Jens Osterkamp wrote:
>
> Hi,
>
> rtas_flash was broken since 2.6.24-rc5. This patch fixes it.
> I think this is a good bugfix candidate for 2.6.25.
NACK. driver should not poke into the internal count member. Just
provide your own inclusion with a new counter or set/test_bit.
^ permalink raw reply
* Re: [kvm-ppc-devel] [PATCH] Add idle wait support for 44x platforms
From: Hollis Blanchard @ 2008-04-03 23:13 UTC (permalink / raw)
To: Jerone Young; +Cc: kvm-ppc-devel, linuxppc-dev, Stuart Yoder
In-Reply-To: <7226bef216680748a503.1207262582@thinkpadL>
On Thursday 03 April 2008 17:43:02 Jerone Young wrote:
> # HG changeset patch
> # User Jerone Young <jyoung5@us.ibm.com>
> # Date 1207262487 18000
> # Node ID 7226bef216680748a50327900572c2fbc3e762b0
> # Parent a5b2aebbc6ebd2439c655f1c047ed7e3c1991ec1
> 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>
Very nice.
> +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);
> + /* return to initial state */
> + mtmsr(msr_save);
> +}
> +
> +int __init ppc44x_idle_init(void)
> +{
> + if(of_find_node_by_path("/hypervisor") != NULL) {
> + /* if we find /hypervisor node is in device tree,
> + set idle mode to wait */
> + current_mode = 1; /* wait mode */
> + }
> +
> + ppc_md.power_save = modes[current_mode].entry;
> + return 0;
> +}
By the way, watch that space in "if(". Also, you need to call of_node_put().
The one thing I don't like is the hardcoded assumption that 1 means "wait".
Instead, you could do something like this (not even compile-tested):
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;
of_node_put(node);
}
ppc_md.power_save = func;
return 0;
}
Stuart, we're getting into ePAPR territory. Do you think we need to worry
about a hypervisor not handling mtmsr(MSR_WE)? In that case, we'd need to be
more specific than just testing for "/hypervisor". IMHO every hypervisor
should implement it... but maybe /hypervisor/idle = "wait" would be more
explicit and therefore better?
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH] Add idle wait support for 44x platforms
From: Tony Breeds @ 2008-04-03 23:03 UTC (permalink / raw)
To: Jerone Young; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <7226bef216680748a503.1207262582@thinkpadL>
On Thu, Apr 03, 2008 at 05:43:02PM -0500, Jerone Young wrote:
Hi Jerone,
A few minor nits.
> 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>
Can you include a diffstat in here?
> +static int current_mode = 0;
Leave this as: static int current_mode;, so it'll end up in the bss
> +int __init ppc44x_idle_init(void)
> +{
> + if(of_find_node_by_path("/hypervisor") != NULL) {
^ space
> + /* if we find /hypervisor node is in device tree,
> + set idle mode to wait */
> + current_mode = 1; /* wait mode */
> + }
You don't really need the braces {} here.
> +static int __init idle_param(char *p)
> +{
> + int i;
> +
> + for (i = 0; i < sizeof(modes)/sizeof(struct sleep_mode); i++) {
ARRAY_SIZE(modes)
Yours Tony
linux.conf.au http://www.marchsouth.org/
Jan 19 - 24 2009 The Australian Linux Technical Conference!
^ permalink raw reply
* [PATCH] Add idle wait support for 44x platforms
From: Jerone Young @ 2008-04-03 22:43 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kvm-ppc-devel
# HG changeset patch
# User Jerone Young <jyoung5@us.ibm.com>
# Date 1207262487 18000
# Node ID 7226bef216680748a50327900572c2fbc3e762b0
# Parent a5b2aebbc6ebd2439c655f1c047ed7e3c1991ec1
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/44x.h b/arch/powerpc/platforms/44x/44x.h
--- a/arch/powerpc/platforms/44x/44x.h
+++ b/arch/powerpc/platforms/44x/44x.h
@@ -5,4 +5,6 @@ extern void as1_writeb(u8 data, volatile
extern void as1_writeb(u8 data, volatile u8 __iomem *addr);
extern void ppc44x_reset_system(char *cmd);
+extern int ppc44x_idle_init(void);
+
#endif /* __POWERPC_PLATFORMS_44X_44X_H */
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,5 @@ obj-$(CONFIG_44x) := misc_44x.o
obj-$(CONFIG_44x) := misc_44x.o
+obj-$(CONFIG_44x) += idle.o
obj-$(CONFIG_EBONY) += ebony.o
obj-$(CONFIG_TAISHAN) += taishan.o
obj-$(CONFIG_BAMBOO) += bamboo.o
diff --git a/arch/powerpc/platforms/44x/bamboo.c b/arch/powerpc/platforms/44x/bamboo.c
--- a/arch/powerpc/platforms/44x/bamboo.c
+++ b/arch/powerpc/platforms/44x/bamboo.c
@@ -61,3 +61,5 @@ define_machine(bamboo) {
.restart = ppc44x_reset_system,
.calibrate_decr = generic_calibrate_decr,
};
+
+machine_late_initcall(bamboo, ppc44x_idle_init);
diff --git a/arch/powerpc/platforms/44x/canyonlands.c b/arch/powerpc/platforms/44x/canyonlands.c
--- a/arch/powerpc/platforms/44x/canyonlands.c
+++ b/arch/powerpc/platforms/44x/canyonlands.c
@@ -62,3 +62,5 @@ define_machine(canyonlands) {
.restart = ppc44x_reset_system,
.calibrate_decr = generic_calibrate_decr,
};
+
+machine_late_initcall(canyonlands, ppc44x_idle_init);
diff --git a/arch/powerpc/platforms/44x/ebony.c b/arch/powerpc/platforms/44x/ebony.c
--- a/arch/powerpc/platforms/44x/ebony.c
+++ b/arch/powerpc/platforms/44x/ebony.c
@@ -69,3 +69,5 @@ define_machine(ebony) {
.restart = ppc44x_reset_system,
.calibrate_decr = generic_calibrate_decr,
};
+
+machine_late_initcall(ebony, ppc44x_idle_init);
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,75 @@
+/*
+ * Copyright 2008 IBM Corp.
+ *
+ * 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 <asm/machdep.h>
+
+static void ppc44x_idle(void);
+
+struct sleep_mode {
+ char *name;
+ void (*entry)(void);
+};
+
+static struct sleep_mode modes[] = {
+ { .name = "spin", .entry = NULL },
+ { .name = "wait", .entry = &ppc44x_idle },
+};
+
+static int current_mode = 0;
+
+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);
+ /* return to initial state */
+ mtmsr(msr_save);
+}
+
+int __init ppc44x_idle_init(void)
+{
+ if(of_find_node_by_path("/hypervisor") != NULL) {
+ /* if we find /hypervisor node is in device tree,
+ set idle mode to wait */
+ current_mode = 1; /* wait mode */
+ }
+
+ ppc_md.power_save = modes[current_mode].entry;
+ return 0;
+}
+
+static int __init idle_param(char *p)
+{
+ int i;
+
+ for (i = 0; i < sizeof(modes)/sizeof(struct sleep_mode); i++) {
+ if (!strcmp(modes[i].name, p)) {
+ current_mode = i;
+ break;
+ }
+ }
+
+ return 0;
+}
+
+early_param("idle", idle_param);
diff --git a/arch/powerpc/platforms/44x/katmai.c b/arch/powerpc/platforms/44x/katmai.c
--- a/arch/powerpc/platforms/44x/katmai.c
+++ b/arch/powerpc/platforms/44x/katmai.c
@@ -61,3 +61,5 @@ define_machine(katmai) {
.restart = ppc44x_reset_system,
.calibrate_decr = generic_calibrate_decr,
};
+
+machine_late_initcall(katmai, ppc44x_idle_init);
diff --git a/arch/powerpc/platforms/44x/rainier.c b/arch/powerpc/platforms/44x/rainier.c
--- a/arch/powerpc/platforms/44x/rainier.c
+++ b/arch/powerpc/platforms/44x/rainier.c
@@ -60,3 +60,5 @@ define_machine(rainier) {
.restart = ppc44x_reset_system,
.calibrate_decr = generic_calibrate_decr,
};
+
+machine_late_initcall(rainier, ppc44x_idle_init);
diff --git a/arch/powerpc/platforms/44x/sequoia.c b/arch/powerpc/platforms/44x/sequoia.c
--- a/arch/powerpc/platforms/44x/sequoia.c
+++ b/arch/powerpc/platforms/44x/sequoia.c
@@ -61,3 +61,5 @@ define_machine(sequoia) {
.restart = ppc44x_reset_system,
.calibrate_decr = generic_calibrate_decr,
};
+
+machine_late_initcall(sequoia, ppc44x_idle_init);
diff --git a/arch/powerpc/platforms/44x/taishan.c b/arch/powerpc/platforms/44x/taishan.c
--- a/arch/powerpc/platforms/44x/taishan.c
+++ b/arch/powerpc/platforms/44x/taishan.c
@@ -71,3 +71,5 @@ define_machine(taishan) {
.restart = ppc44x_reset_system,
.calibrate_decr = generic_calibrate_decr,
};
+
+machine_late_initcall(taishan, ppc44x_idle_init);
^ permalink raw reply
* RE: [PATCH 2/3] [POWERPC][V3] Xilinx: of_serial support for Xilinxuart 16550.
From: Stephen Neuendorffer @ 2008-04-03 22:36 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev; +Cc: John Linn
In-Reply-To: <200804030616.09825.arnd@arndb.de>
The device tree generator now reflects this.
Steve
> -----Original Message-----
> From: =
linuxppc-dev-bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.org =
[mailto:linuxppc-dev-
> bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.org] On Behalf Of =
Arnd Bergmann
> Sent: Wednesday, April 02, 2008 9:16 PM
> To: linuxppc-dev@ozlabs.org
> Cc: John Linn
> Subject: Re: [PATCH 2/3] [POWERPC][V3] Xilinx: of_serial support for =
Xilinxuart 16550.
>=20
> On Thursday 03 April 2008, Grant Likely wrote:
> > >
> > > =A0Since it is not really compatible with ns16550, shouldn't you =
at least specify
> > > =A0a different "compatible" property? That way, the driver won't =
do incorrect
> > > =A0accesses when you try to use an old driver with a device tree =
that specifies
> > > =A0one of these.
> >
> > Heh; we've gone back and forth on this issue. =A0The problem is that =
we
> > have a common case of ns16550 like devices that require a little bit
> > of register address tweaking that spans a whole range of vendors (so
> > adding a compatible match with each of those vendor's prefixes is
> > probably non-scalable). =A0So, if "ns16550" is not a good idea, then
> > what should be used? =A0"sparse16550" has been suggested more than =
once.
>=20
> After another IRC discussion between Grant, Segher and myself, we =
concluded
> that we don't need to invent a new "compatible" value, as only new =
device
> trees with old kernels will have a problem with this, and they don't =
work
> in the first place.
>=20
> The devices will still have their specific "compatible" value, e.g.
> "xlnx,plb-uart16550-1.00.c", followed by "ns16550", and possibly
> "ns16450" and "i8250", although the last two do not have an effect
> on Linux.
>=20
> Josh, can you please forward all three patches in their latest =
version?
>=20
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ 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