* Re: Linuxppc-embedded Digest, Vol 44, Issue 17
From: William Feng @ 2008-04-04 12:15 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <mailman.403.1207310047.11702.linuxppc-embedded@ozlabs.org>
Hi Janhan,
Yes, it is confiemed. Thanks for your advise!
Regards
William Feng
Landscape Co, LTD.
--------------------------------------------------
From: <linuxppc-embedded-request@ozlabs.org>
Sent: Friday, April 04, 2008 7:54 PM
To: <linuxppc-embedded@ozlabs.org>
Subject: Linuxppc-embedded Digest, Vol 44, Issue 17
> Send Linuxppc-embedded mailing list submissions to
> linuxppc-embedded@ozlabs.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> or, via email, send a message with subject or body 'help' to
> linuxppc-embedded-request@ozlabs.org
>
> You can reach the person managing the list at
> linuxppc-embedded-owner@ozlabs.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Linuxppc-embedded digest..."
>
>
> Today's Topics:
>
> 1. Re: Xilinx LLTEMAC driver issues (Johann Baudy)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 4 Apr 2008 11:54:01 +0000
> From: "Johann Baudy" <johaahn@gmail.com>
> Subject: Re: Xilinx LLTEMAC driver issues
> To: MingLiu <eemingliu@hotmail.com>
> Cc: John Linn <john.linn@xilinx.com>, git <git@xilinx.com>,
> linuxppc-embedded@ozlabs.org
> Message-ID:
> <7e0dd21a0804040454i6ef73980mce1a14f7e8d3c281@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Dear Ming,
>
> I've made this test on EDK 9.2 + ll_temac 1.00.b + lltemac hw patch
> (ftp://ftp.xilinx.com/pub/applications/misc/tx_ll_if_edk10_1.zip
> (still up))+ ll_temac driver patch.
> I'm currently working on a 10.1 rebase. (ongoing...)
>
> Best regards,
> Johann
>
>
> On Fri, Apr 4, 2008 at 10:11 AM, MingLiu <eemingliu@hotmail.com> wrote:
>>
>> Dear Johann,
>> Thanks for the prompt reply.
>>
>> Actually I am using EDK 10.1 evaluation version. According to Xilinx's
>> answer, they said the problem will be fixed in 10.1 already.
>> Unfortunately I
>> still met it in my design.
>>
>> Do you happen to still have the file tx_ii_if.zip? I cannot download it
>> from Xilinx any more. Thank you so much if you can give me a copy.
>>
>> BR
>> Ming
>>
>>
>> > Date: Fri, 4 Apr 2008 09:53:07 +0000
>> > From: johaahn@gmail.com
>> > To: eemingliu@hotmail.com
>>
>> > Subject: Re: Xilinx LLTEMAC driver issues
>> > CC: mh@omnisys.se; linuxppc-embedded@ozlabs.org; john.linn@xilinx.com;
>> git@xilinx.com
>>
>>
>> >
>> > Hi Ming,
>> >
>> > I've already used netperf (without NFS) successfully.
>> > Are you using 1.00.b and 9.2, if yes look at AR #29708.
>> >
>> > Best regards,
>> > Johann
>> >
>> > On Fri, Apr 4, 2008 at 9:36 AM, MingLiu <eemingliu@hotmail.com> wrote:
>> > >
>> > > Dear Johann,
>> > > Previously I said this patch helps for the checksum error problem.
>> > > But
>> now
>> > > I found some new issues. Yes. at least with this patch, something is
>> better
>> > > and at least we can use the hardware checksum offloading to do
>> something,
>> > > for example I can mount the NFS root file system. However when I try
>> > > to
>> > > measure the ethernet bandwidth with netperf, something goes wrong and
>> the
>> > > NFS mount will be broken. I guess this is because of the large bulk
>> > > data
>> > > transfer and maybe thus it triggers the checksum problem to happen.
>> > >
>> > > Do you have the same situation? Or someone else has the same problem?
>> > > I
>> > > will appreciate if you can share your experience. Thanks a lot.
>> > >
>> > > BR
>> > > Ming
>> > >
>> > >
>> > >
>> > > ________________________________
>> > > Date: Wed, 2 Apr 2008 07:20:43 +0000
>> > > From: johaahn@gmail.com
>> > > To: mh@omnisys.se
>> > >
>> > > Subject: Re: Xilinx LLTEMAC driver issues
>> > > CC: linuxppc-embedded@ozlabs.org; John.Linn@xilinx.com;
>> > > git@xilinx.com
>> > >
>> > >
>> > >
>> > > I've solved this checksum offloading issue with this below patch.
>> > > It may help, if you need performance. It certainly needs review but
>> > > it
>> works
>> > > on my side.
>> > >
>> > > --- xilinxgit/drivers/net/xilinx
>> > > _lltemac/xlltemac_main.c.orig 2008-03-21 09:11:43.000000000 +0100
>> > > +++ xilinxgit/drivers/net/xilinx_lltemac/xlltemac_main.c 2008-03-21
>> > > 09:24:23.000000000 +0100
>> > > @@ -133,7 +133,7 @@
>> > > (XLlDma_mBdRead((BdPtr), XLLDMA_BD_STSCTRL_USR0_OFFSET)) &
>> > > 0xFFFFFFFE )
>> > >
>> > > #define BdCsumSetup(BdPtr, Start, Insert) \
>> > > - XLlDma_mBdWrite((BdPtr), XLLDMA_BD_USR1_OFFSET, (Start) << 16 |
>> > > (Insert))
>> > > + XLlDma_mBdWrite((BdPtr), XLLDMA_BD_USR1_OFFSET, ((Start) << 16) |
>> > > (Insert))
>> > >
>> > > /* Used for debugging */
>> > > #define BdCsumInsert(BdPtr) \
>> > > @@ -1540,7 +1541,7 @@ static int xenet_DmaSend_internal(struct
>> > > /*
>> > > * if tx checksum offloading is enabled, when the ethernet stack
>> > > * wants us to perform the checksum in hardware,
>> > > - * skb->ip_summed is CHECKSUM_COMPLETE. Otherwise skb->ip_summed is
>> > > + * skb->ip_summed is CHECKSUM_PARTIAL. Otherwise skb->ip_summed is
>> > > * CHECKSUM_NONE, meaning the checksum is already done, or
>> > > * CHECKSUM_UNNECESSARY, meaning checksumming is turned off (e.g.
>> > > * loopback interface)
>> > > @@ -1565,9 +1566,11 @@ static int xenet_DmaSend_internal(struct
>> > > * skb_transport_header(skb) points to the beginning of the ip header
>> > > *
>> > > */
>> > > - if (skb->ip_summed == CHECKSUM_COMPLETE) {
>> > > + if (skb->ip_summed == CHECKSUM_PARTIAL) {
>> > > +
>> > > + unsigned int csum_start_off = skb_transport_offset(skb);
>> > > + unsigned int csum_index_off = csum_start_off + skb->csum_offset;
>> > >
>> > > - unsigned char *raw = skb_transport_header(skb);
>> > > #if 0
>> > > {
>> > > unsigned int csum = _xenet_tx_csum(skb);
>> > > @@ -1578,9 +1581,8 @@ static int xenet_DmaSend_internal(struct
>> > > }
>> > > #else
>> > > BdCsumEnable(bd_ptr);
>> > > - BdCsumSetup(bd_ptr, raw - skb->data,
>> > > - (raw - skb->data) + skb->csum);
>> > > -
>> > > + BdCsumSetup(bd_ptr, csum_start_off,
>> > > + csum_index_off);
>> > > #endif
>> > > lp->tx_hw_csums++;
>> > > }
>> > > @@ -3277,7 +3279,7 @@ static int __devinit xtenet_of_probe(str
>> > > struct resource *r_irq = &r_irq_struct; /* Interrupt resources */
>> > > struct resource *r_mem = &r_mem_struct; /* IO mem resources */
>> > > struct xlltemac_platform_data *pdata = &pdata_struct;
>> > > - void *mac_address;
>> > > + const void *mac_address;
>> > > int rc = 0;
>> > > const phandle *llink_connected_handle;
>> > > struct device_node *llink_connected_node;
>> > >
>> > >
>> > > On Mon, Mar 31, 2008 at 11:10 AM, Magnus Hjorth <mh@omnisys.se>
>> > > wrote:
>> > >
>> > > Deactivating checksum offloading helped a lot! I still have some
>> > > packet
>> loss
>> > > and not the best performance (TFTP transfer about 100 kbyte/s) but at
>> least
>> > > it works.
>> > >
>> > > Thanks!
>> > >
>> > > //Magnus
>> > >
>> > >
>> > >
>> > >
>> > > > -----Original Message-----
>> > > > From: rza1 [mailto:rza1@so-logic.net]
>> > > > Sent: den 31 mars 2008 11:14
>> > > > To: Magnus Hjorth
>> > > > Cc: John Linn; git; linuxppc-embedded@ozlabs.org
>> > > > Subject: Re: Xilinx LLTEMAC driver issues
>> > > >
>> > > > Hi Magnus,
>> > > >
>> > > > 1.
>> > > > I am using nearly the same versions then you and got the same
>> > > > problems
>> > > > too ;-).
>> > > > I think there are some problems with the checksum offloading.
>> > > > Try to sniff the some packages (e.g. wireshark)...
>> > > > For me ICMP (ping) worked but udp and tcp not (because off a wrong
>> > > > checksum in the transport layer).
>> > > > A quick solution is to just deactivate checksum offloading.
>> > > >
>> > > > 2.
>> > > > I remember some problems with Virtex-4 presamples too.
>> > > > There where problems with the hard-temac wrapper. You had to use
>> 1.00.a
>> > > > and not b version.
>> > > > But I don't have these problems with the EDK 9.2sp2/ISE9.2sp3
>> > > > anymore.
>> > > >
>> > > > all the best,
>> > > > Robert
>> > > >
>> > > > Magnus Hjorth wrote:
>> > > > > Hi John,
>> > > > >
>> > > > > Thanks for the very fast reply! Right now I'm not at work so I
>> > > > > don't
>> > > > > have the board or EDK here to test anything.
>> > > > >
>> > > > > I'm using checksum offload, but I don't know if DRE is enabled or
>> not. I
>> > > > > can't recall seeing any setting to enable/disable DRE..
>> > > > >
>> > > > > A few things that crossed my mind:
>> > > > >
>> > > > > Last year I did a design with EDK 8.2, back then there was an
>> > > > > issue
>> with
>> > > > > the ML403 boards having an old revision of the FPGA which wasn't
>> > > > > compatible with some versions of the IP core. There are no such
>> version
>> > > > > issues with the xps_ll_temac?
>> > > > >
>> > > > > I don't think that I had phy-addr set in the DTS file. Will test
>> that on
>> > > > > Monday.
>> > > > >
>> > > > > Best regards,
>> > > > > Magnus
>> > > > >
>> > > > >
>> > > > > On Sat, 2008-03-29 at 07:58 -0600, John Linn wrote:
>> > > > >
>> > > > >> Hi Magnus,
>> > > > >>
>> > > > >> Sorry to hear you're having problems with it.
>> > > > >>
>> > > > >> I am doing testing on an ML405 which is the same board but with
>> > > > >> a
>> > > bigger
>> > > > FPGA, but with ppc arch and I don't see this issue. I have done
>> limited
>> > > testing
>> > > > with powerpc arch and the LL TEMAC, but I didn't see this issue
>> > > > there
>> > > either.
>> > > > Powerpc arch is definitely less mature in my experience than the
>> > > > ppc
>> arch.
>> > > I'll
>> > > > do a quick test with my powerpc arch and make sure again I'm not
>> seeing
>> > > it.
>> > > > >>
>> > > > >> My kernel is from the Xilinx Git tree, but there have been a
>> > > > >> number
>> of
>> > > > changes we have pushed out so I don't know how long ago you pulled
>> from
>> > > the Git
>> > > > tree.
>> > > > >>
>> > > > >> My EDK project is 10.1 so it's a little newer. I am using LL
>> > > > >> TEMAC
>> > > 1.01a so
>> > > > it's a little newer. I reviewed the change log for the LL TEMAC and
>> don't
>> > > see
>> > > > any big problems that were fixed in the newer versions, more new
>> features.
>> > > I'll
>> > > > check with some others here to see if I missed something there.
>> > > > >>
>> > > > >> I am using DMA also, but no DRE or checksum offload. You didn't
>> > > > >> say
>> > > anything
>> > > > about those. I'm going to insert my mhs file that describes my
>> > > > system
>> to
>> > > let you
>> > > > compare your system configuration. It's not clear to me yet if you
>> have a
>> > > h/w or
>> > > > s/w problem.
>> > > > >>
>> > > > >> I'll also insert some of my device tree with the LL TEMAC so you
>> can
>> > > compare
>> > > > (ignore 16550 stuff as we are still working on that).
>> > > > >>
>> > > > >> Since you can't ping reliably I would probably focus on that
>> > > > >> since
>> it's
>> > > > simpler than the other issues you're seeing.
>> > > > >>
>> > > > >> Thanks,
>> > > > >> John
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >> #
>> > > >
>> > >
>> ##############################################################################
>> > > > >> # Created by Base System Builder Wizard for Xilinx EDK 10.1.1
>> > > > >> Build
>> > > > EDK_K_SP1.1
>> > > > >> # Thu Feb 14 14:11:12 2008
>> > > > >> # Target Board: Xilinx Virtex 4 ML405 Evaluation Platform Rev 1
>> > > > >> # Family: virtex4
>> > > > >> # Device: xc4vfx20
>> > > > >> # Package: ff672
>> > > > >> # Speed Grade: -10
>> > > > >> # Processor: ppc405_0
>> > > > >> # Processor clock frequency: 300.00 MHz
>> > > > >> # Bus clock frequency: 100.00 MHz
>> > > > >> # On Chip Memory : 8 KB
>> > > > >> # Total Off Chip Memory : 128 MB
>> > > > >> # - DDR_SDRAM = 128 MB
>> > > > >> #
>> > > >
>> > >
>> ##############################################################################
>> > > > >> PARAMETER VERSION = 2.1.0
>> > > > >>
>> > > > >>
>> > > > >> PORT fpga_0_RS232_Uart_sin_pin = fpga_0_RS232_Uart_sin, DIR = I
>> > > > >> PORT fpga_0_RS232_Uart_sout_pin = fpga_0_RS232_Uart_sout, DIR =
>> > > > >> O
>> > > > >> PORT fpga_0_LEDs_4Bit_GPIO_IO_pin = fpga_0_LEDs_4Bit_GPIO_IO,
>> > > > >> DIR =
>> > > IO, VEC
>> > > > = [0:3]
>> > > > >> PORT fpga_0_IIC_EEPROM_Scl_pin = fpga_0_IIC_EEPROM_Scl, DIR = IO
>> > > > >> PORT fpga_0_IIC_EEPROM_Sda_pin = fpga_0_IIC_EEPROM_Sda, DIR = IO
>> > > > >> PORT fpga_0_SysACE_CompactFlash_SysACE_CLK_pin =
>> > > > fpga_0_SysACE_CompactFlash_SysACE_CLK, DIR = I
>> > > > >> PORT fpga_0_SysACE_CompactFlash_SysACE_MPA_pin =
>> > > > fpga_0_SysACE_CompactFlash_SysACE_MPA, DIR = O, VEC = [6:1]
>> > > > >> PORT fpga_0_SysACE_CompactFlash_SysACE_MPD_pin =
>> > > > fpga_0_SysACE_CompactFlash_SysACE_MPD, DIR = IO, VEC = [15:0]
>> > > > >> PORT fpga_0_SysACE_CompactFlash_SysACE_CEN_pin =
>> > > > fpga_0_SysACE_CompactFlash_SysACE_CEN, DIR = O
>> > > > >> PORT fpga_0_SysACE_CompactFlash_SysACE_OEN_pin =
>> > > > fpga_0_SysACE_CompactFlash_SysACE_OEN, DIR = O
>> > > > >> PORT fpga_0_SysACE_CompactFlash_SysACE_WEN_pin =
>> > > > fpga_0_SysACE_CompactFlash_SysACE_WEN, DIR = O
>> > > > >> PORT fpga_0_SysACE_CompactFlash_SysACE_MPIRQ_pin =
>> > > > fpga_0_SysACE_CompactFlash_SysACE_MPIRQ, DIR = I
>> > > > >> PORT fpga_0_DDR_SDRAM_DDR_Clk_pin = fpga_0_DDR_SDRAM_DDR_Clk,
>> > > > >> DIR =
>> O
>> > > > >> PORT fpga_0_DDR_SDRAM_DDR_Clk_n_pin =
>> > > > >> fpga_0_DDR_SDRAM_DDR_Clk_n,
>> DIR
>> > > = O
>> > > > >> PORT fpga_0_DDR_SDRAM_DDR_Addr_pin = fpga_0_DDR_SDRAM_DDR_Addr,
>> > > > >> DIR
>> =
>> > > O, VEC
>> > > > = [12:0]
>> > > > >> PORT fpga_0_DDR_SDRAM_DDR_BankAddr_pin =
>> > > fpga_0_DDR_SDRAM_DDR_BankAddr, DIR
>> > > > = O, VEC = [1:0]
>> > > > >> PORT fpga_0_DDR_SDRAM_DDR_CAS_n_pin =
>> > > > >> fpga_0_DDR_SDRAM_DDR_CAS_n,
>> DIR
>> > > = O
>> > > > >> PORT fpga_0_DDR_SDRAM_DDR_CE_pin = fpga_0_DDR_SDRAM_DDR_CE, DIR
>> > > > >> = O
>> > > > >> PORT fpga_0_DDR_SDRAM_DDR_CS_n_pin = fpga_0_DDR_SDRAM_DDR_CS_n,
>> > > > >> DIR
>> =
>> > > O
>> > > > >> PORT fpga_0_DDR_SDRAM_DDR_RAS_n_pin =
>> > > > >> fpga_0_DDR_SDRAM_DDR_RAS_n,
>> DIR
>> > > = O
>> > > > >> PORT fpga_0_DDR_SDRAM_DDR_WE_n_pin = fpga_0_DDR_SDRAM_DDR_WE_n,
>> > > > >> DIR
>> =
>> > > O
>> > > > >> PORT fpga_0_DDR_SDRAM_DDR_DM_pin = fpga_0_DDR_SDRAM_DDR_DM, DIR
>> > > > >> =
>> O,
>> > > VEC =
>> > > > [3:0]
>> > > > >> PORT fpga_0_DDR_SDRAM_DDR_DQS = fpga_0_DDR_SDRAM_DDR_DQS, DIR =
>> > > > >> IO,
>> > > VEC =
>> > > > [3:0]
>> > > > >> PORT fpga_0_DDR_SDRAM_DDR_DQ = fpga_0_DDR_SDRAM_DDR_DQ, DIR =
>> > > > >> IO,
>> VEC
>> > > =
>> > > > [31:0]
>> > > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_TXD_0_pin =
>> > > > fpga_0_TriMode_MAC_GMII_GMII_TXD_0, DIR = O, VEC = [7:0]
>> > > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_TX_EN_0_pin =
>> > > > fpga_0_TriMode_MAC_GMII_GMII_TX_EN_0, DIR = O
>> > > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_TX_ER_0_pin =
>> > > > fpga_0_TriMode_MAC_GMII_GMII_TX_ER_0, DIR = O
>> > > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_TX_CLK_0_pin =
>> > > > fpga_0_TriMode_MAC_GMII_GMII_TX_CLK_0, DIR = O
>> > > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_RXD_0_pin =
>> > > > fpga_0_TriMode_MAC_GMII_GMII_RXD_0, DIR = I, VEC = [7:0]
>> > > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_RX_DV_0_pin =
>> > > > fpga_0_TriMode_MAC_GMII_GMII_RX_DV_0, DIR = I
>> > > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_RX_ER_0_pin =
>> > > > fpga_0_TriMode_MAC_GMII_GMII_RX_ER_0, DIR = I
>> > > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_RX_CLK_0_pin =
>> > > > fpga_0_TriMode_MAC_GMII_GMII_RX_CLK_0, DIR = I
>> > > > >> PORT fpga_0_TriMode_MAC_GMII_MII_TX_CLK_0_pin =
>> > > > fpga_0_TriMode_MAC_GMII_MII_TX_CLK_0, DIR = I
>> > > > >> PORT fpga_0_TriMode_MAC_GMII_MDIO_0_pin =
>> > > fpga_0_TriMode_MAC_GMII_MDIO_0,
>> > > > DIR = IO
>> > > > >> PORT fpga_0_TriMode_MAC_GMII_MDC_0_pin =
>> > > fpga_0_TriMode_MAC_GMII_MDC_0, DIR
>> > > > = O
>> > > > >> PORT fpga_0_TriMode_MAC_GMII_TemacPhy_RST_n_pin =
>> > > > fpga_0_TriMode_MAC_GMII_TemacPhy_RST_n, DIR = O
>> > > > >> PORT sys_clk_pin = dcm_clk_s, DIR = I, SIGIS = CLK, CLK_FREQ =
>> > > 100000000
>> > > > >> PORT sys_rst_pin = sys_rst_s, DIR = I, RST_POLARITY = 0, SIGIS =
>> RST
>> > > > >>
>> > > > >>
>> > > > >> BEGIN ppc405_virtex4
>> > > > >> PARAMETER INSTANCE = ppc405_0
>> > > > >> PARAMETER HW_VER = 2.01.a
>> > > > >> PARAMETER C_FASTEST_PLB_CLOCK = DPLB1
>> > > > >> PARAMETER C_IDCR_BASEADDR = 0b0100000000
>> > > > >> PARAMETER C_IDCR_HIGHADDR = 0b0111111111
>> > > > >> BUS_INTERFACE JTAGPPC = jtagppc_0_0
>> > > > >> BUS_INTERFACE IPLB0 = plb
>> > > > >> BUS_INTERFACE DPLB0 = plb
>> > > > >> BUS_INTERFACE IPLB1 = ppc405_0_iplb1
>> > > > >> BUS_INTERFACE DPLB1 = ppc405_0_dplb1
>> > > > >> BUS_INTERFACE RESETPPC = ppc_reset_bus
>> > > > >> PORT CPMC405CLOCK = proc_clk_s
>> > > > >> PORT EICC405EXTINPUTIRQ = EICC405EXTINPUTIRQ
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN jtagppc_cntlr
>> > > > >> PARAMETER INSTANCE = jtagppc_0
>> > > > >> PARAMETER HW_VER = 2.01.a
>> > > > >> BUS_INTERFACE JTAGPPC0 = jtagppc_0_0
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN plb_v46
>> > > > >> PARAMETER INSTANCE = plb
>> > > > >> PARAMETER C_DCR_INTFCE = 0
>> > > > >> PARAMETER C_NUM_CLK_PLB2OPB_REARB = 100
>> > > > >> PARAMETER HW_VER = 1.02.a
>> > > > >> PORT PLB_Clk = sys_clk_s
>> > > > >> PORT SYS_Rst = sys_bus_reset
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN xps_bram_if_cntlr
>> > > > >> PARAMETER INSTANCE = xps_bram_if_cntlr_1
>> > > > >> PARAMETER HW_VER = 1.00.a
>> > > > >> PARAMETER C_SPLB_NATIVE_DWIDTH = 64
>> > > > >> PARAMETER C_BASEADDR = 0xffffe000
>> > > > >> PARAMETER C_HIGHADDR = 0xffffffff
>> > > > >> BUS_INTERFACE SPLB = plb
>> > > > >> BUS_INTERFACE PORTA = xps_bram_if_cntlr_1_port
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN bram_block
>> > > > >> PARAMETER INSTANCE = plb_bram_if_cntlr_1_bram
>> > > > >> PARAMETER HW_VER = 1.00.a
>> > > > >> BUS_INTERFACE PORTA = xps_bram_if_cntlr_1_port
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN xps_uart16550
>> > > > >> PARAMETER INSTANCE = RS232_Uart
>> > > > >> PARAMETER HW_VER = 2.00.a
>> > > > >> PARAMETER C_IS_A_16550 = 1
>> > > > >> PARAMETER C_BASEADDR = 0x83e00000
>> > > > >> PARAMETER C_HIGHADDR = 0x83e0ffff
>> > > > >> BUS_INTERFACE SPLB = plb
>> > > > >> PORT sin = fpga_0_RS232_Uart_sin
>> > > > >> PORT sout = fpga_0_RS232_Uart_sout
>> > > > >> PORT IP2INTC_Irpt = RS232_Uart_IP2INTC_Irpt
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN xps_gpio
>> > > > >> PARAMETER INSTANCE = LEDs_4Bit
>> > > > >> PARAMETER HW_VER = 1.00.a
>> > > > >> PARAMETER C_INTERRUPT_PRESENT = 1
>> > > > >> PARAMETER C_GPIO_WIDTH = 4
>> > > > >> PARAMETER C_IS_DUAL = 0
>> > > > >> PARAMETER C_IS_BIDIR = 1
>> > > > >> PARAMETER C_ALL_INPUTS = 0
>> > > > >> PARAMETER C_BASEADDR = 0x81400000
>> > > > >> PARAMETER C_HIGHADDR = 0x8140ffff
>> > > > >> BUS_INTERFACE SPLB = plb
>> > > > >> PORT GPIO_IO = fpga_0_LEDs_4Bit_GPIO_IO
>> > > > >> PORT IP2INTC_Irpt = LEDs_4Bit_IP2INTC_Irpt
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN xps_iic
>> > > > >> PARAMETER INSTANCE = IIC_EEPROM
>> > > > >> PARAMETER HW_VER = 2.00.a
>> > > > >> PARAMETER C_CLK_FREQ = 100000000
>> > > > >> PARAMETER C_IIC_FREQ = 100000
>> > > > >> PARAMETER C_TEN_BIT_ADR = 0
>> > > > >> PARAMETER C_BASEADDR = 0x81600000
>> > > > >> PARAMETER C_HIGHADDR = 0x8160ffff
>> > > > >> BUS_INTERFACE SPLB = plb
>> > > > >> PORT Scl = fpga_0_IIC_EEPROM_Scl
>> > > > >> PORT Sda = fpga_0_IIC_EEPROM_Sda
>> > > > >> PORT IIC2INTC_Irpt = IIC_EEPROM_IIC2INTC_Irpt
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN xps_sysace
>> > > > >> PARAMETER INSTANCE = SysACE_CompactFlash
>> > > > >> PARAMETER HW_VER = 1.00.a
>> > > > >> PARAMETER C_MEM_WIDTH = 16
>> > > > >> PARAMETER C_BASEADDR = 0x83600000
>> > > > >> PARAMETER C_HIGHADDR = 0x8360ffff
>> > > > >> BUS_INTERFACE SPLB = plb
>> > > > >> PORT SysACE_CLK = fpga_0_SysACE_CompactFlash_SysACE_CLK
>> > > > >> PORT SysACE_MPA = fpga_0_SysACE_CompactFlash_SysACE_MPA_split
>> > > > >> PORT SysACE_MPD = fpga_0_SysACE_CompactFlash_SysACE_MPD
>> > > > >> PORT SysACE_CEN = fpga_0_SysACE_CompactFlash_SysACE_CEN
>> > > > >> PORT SysACE_OEN = fpga_0_SysACE_CompactFlash_SysACE_OEN
>> > > > >> PORT SysACE_WEN = fpga_0_SysACE_CompactFlash_SysACE_WEN
>> > > > >> PORT SysACE_MPIRQ = fpga_0_SysACE_CompactFlash_SysACE_MPIRQ
>> > > > >> PORT SysACE_IRQ = SysACE_CompactFlash_SysACE_IRQ
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN mpmc
>> > > > >> PARAMETER INSTANCE = DDR_SDRAM
>> > > > >> PARAMETER HW_VER = 4.00.a
>> > > > >> PARAMETER C_NUM_PORTS = 3
>> > > > >> PARAMETER C_MEM_PARTNO = HYB25D512160BE-5
>> > > > >> PARAMETER C_MEM_DATA_WIDTH = 32
>> > > > >> PARAMETER C_MEM_DQS_WIDTH = 4
>> > > > >> PARAMETER C_MEM_DM_WIDTH = 4
>> > > > >> PARAMETER C_MEM_TYPE = DDR
>> > > > >> PARAMETER C_NUM_IDELAYCTRL = 2
>> > > > >> PARAMETER C_IDELAYCTRL_LOC = IDELAYCTRL_X0Y3-IDELAYCTRL_X0Y2
>> > > > >> PARAMETER C_PIM0_BASETYPE = 2
>> > > > >> PARAMETER C_PIM1_BASETYPE = 2
>> > > > >> PARAMETER C_PIM2_BASETYPE = 3
>> > > > >> PARAMETER C_MPMC_CLK0_PERIOD_PS = 10000
>> > > > >> PARAMETER C_SDMA2_PI2LL_CLK_RATIO = 1
>> > > > >> PARAMETER C_MPMC_BASEADDR = 0x00000000
>> > > > >> PARAMETER C_MPMC_HIGHADDR = 0x07ffffff
>> > > > >> PARAMETER C_SDMA_CTRL_BASEADDR = 0x84600000
>> > > > >> PARAMETER C_SDMA_CTRL_HIGHADDR = 0x8460ffff
>> > > > >> BUS_INTERFACE SPLB0 = ppc405_0_iplb1
>> > > > >> BUS_INTERFACE SPLB1 = ppc405_0_dplb1
>> > > > >> BUS_INTERFACE SDMA_LL2 = TriMode_MAC_GMII_LLINK0
>> > > > >> BUS_INTERFACE SDMA_CTRL2 = plb
>> > > > >> PORT DDR_Addr = fpga_0_DDR_SDRAM_DDR_Addr
>> > > > >> PORT DDR_BankAddr = fpga_0_DDR_SDRAM_DDR_BankAddr
>> > > > >> PORT DDR_CAS_n = fpga_0_DDR_SDRAM_DDR_CAS_n
>> > > > >> PORT DDR_CE = fpga_0_DDR_SDRAM_DDR_CE
>> > > > >> PORT DDR_CS_n = fpga_0_DDR_SDRAM_DDR_CS_n
>> > > > >> PORT DDR_RAS_n = fpga_0_DDR_SDRAM_DDR_RAS_n
>> > > > >> PORT DDR_WE_n = fpga_0_DDR_SDRAM_DDR_WE_n
>> > > > >> PORT DDR_DM = fpga_0_DDR_SDRAM_DDR_DM
>> > > > >> PORT DDR_DQS = fpga_0_DDR_SDRAM_DDR_DQS
>> > > > >> PORT DDR_DQ = fpga_0_DDR_SDRAM_DDR_DQ
>> > > > >> PORT DDR_Clk = fpga_0_DDR_SDRAM_DDR_Clk
>> > > > >> PORT DDR_Clk_n = fpga_0_DDR_SDRAM_DDR_Clk_n
>> > > > >> PORT MPMC_Clk0 = sys_clk_s
>> > > > >> PORT MPMC_Clk90 = DDR_SDRAM_mpmc_clk_90_s
>> > > > >> PORT SDMA2_Clk = sys_clk_s
>> > > > >> PORT MPMC_Clk_200MHz = clk_200mhz_s
>> > > > >> PORT MPMC_Rst = sys_periph_reset
>> > > > >> PORT SDMA2_Rx_IntOut = DDR_SDRAM_SDMA2_Rx_IntOut
>> > > > >> PORT SDMA2_Tx_IntOut = DDR_SDRAM_SDMA2_Tx_IntOut
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN xps_ll_temac
>> > > > >> PARAMETER INSTANCE = TriMode_MAC_GMII
>> > > > >> PARAMETER HW_VER = 1.01.a
>> > > > >> PARAMETER C_SPLB_CLK_PERIOD_PS = 10000
>> > > > >> PARAMETER C_PHY_TYPE = 1
>> > > > >> PARAMETER C_NUM_IDELAYCTRL = 4
>> > > > >> PARAMETER C_IDELAYCTRL_LOC = IDELAYCTRL_X1Y1-IDELAYCTRL_X1Y3-
>> > > > IDELAYCTRL_X2Y2-IDELAYCTRL_X2Y3
>> > > > >> PARAMETER C_TEMAC_TYPE = 1
>> > > > >> PARAMETER C_BUS2CORE_CLK_RATIO = 1
>> > > > >> PARAMETER C_BASEADDR = 0x81c00000
>> > > > >> PARAMETER C_HIGHADDR = 0x81c0ffff
>> > > > >> BUS_INTERFACE SPLB = plb
>> > > > >> BUS_INTERFACE LLINK0 = TriMode_MAC_GMII_LLINK0
>> > > > >> PORT GMII_TXD_0 = fpga_0_TriMode_MAC_GMII_GMII_TXD_0
>> > > > >> PORT GMII_TX_EN_0 = fpga_0_TriMode_MAC_GMII_GMII_TX_EN_0
>> > > > >> PORT GMII_TX_ER_0 = fpga_0_TriMode_MAC_GMII_GMII_TX_ER_0
>> > > > >> PORT GMII_TX_CLK_0 = fpga_0_TriMode_MAC_GMII_GMII_TX_CLK_0
>> > > > >> PORT GMII_RXD_0 = fpga_0_TriMode_MAC_GMII_GMII_RXD_0
>> > > > >> PORT GMII_RX_DV_0 = fpga_0_TriMode_MAC_GMII_GMII_RX_DV_0
>> > > > >> PORT GMII_RX_ER_0 = fpga_0_TriMode_MAC_GMII_GMII_RX_ER_0
>> > > > >> PORT GMII_RX_CLK_0 = fpga_0_TriMode_MAC_GMII_GMII_RX_CLK_0
>> > > > >> PORT MII_TX_CLK_0 = fpga_0_TriMode_MAC_GMII_MII_TX_CLK_0
>> > > > >> PORT MDIO_0 = fpga_0_TriMode_MAC_GMII_MDIO_0
>> > > > >> PORT MDC_0 = fpga_0_TriMode_MAC_GMII_MDC_0
>> > > > >> PORT TemacPhy_RST_n = fpga_0_TriMode_MAC_GMII_TemacPhy_RST_n
>> > > > >> PORT GTX_CLK_0 = temac_clk_s
>> > > > >> PORT REFCLK = clk_200mhz_s
>> > > > >> PORT LlinkTemac0_CLK = sys_clk_s
>> > > > >> PORT TemacIntc0_Irpt = TriMode_MAC_GMII_TemacIntc0_Irpt
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN util_bus_split
>> > > > >> PARAMETER INSTANCE = SysACE_CompactFlash_util_bus_split_0
>> > > > >> PARAMETER HW_VER = 1.00.a
>> > > > >> PARAMETER C_SIZE_IN = 7
>> > > > >> PARAMETER C_LEFT_POS = 0
>> > > > >> PARAMETER C_SPLIT = 6
>> > > > >> PORT Sig = fpga_0_SysACE_CompactFlash_SysACE_MPA_split
>> > > > >> PORT Out1 = fpga_0_SysACE_CompactFlash_SysACE_MPA
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN plb_v46
>> > > > >> PARAMETER INSTANCE = ppc405_0_iplb1
>> > > > >> PARAMETER HW_VER = 1.02.a
>> > > > >> PORT PLB_Clk = sys_clk_s
>> > > > >> PORT SYS_Rst = sys_bus_reset
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN plb_v46
>> > > > >> PARAMETER INSTANCE = ppc405_0_dplb1
>> > > > >> PARAMETER HW_VER = 1.02.a
>> > > > >> PORT PLB_Clk = sys_clk_s
>> > > > >> PORT SYS_Rst = sys_bus_reset
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN clock_generator
>> > > > >> PARAMETER INSTANCE = clock_generator_0
>> > > > >> PARAMETER HW_VER = 2.00.a
>> > > > >> PARAMETER C_EXT_RESET_HIGH = 1
>> > > > >> PARAMETER C_CLKIN_FREQ = 100000000
>> > > > >> PARAMETER C_CLKOUT0_FREQ = 100000000
>> > > > >> PARAMETER C_CLKOUT0_BUF = TRUE
>> > > > >> PARAMETER C_CLKOUT0_PHASE = 0
>> > > > >> PARAMETER C_CLKOUT0_GROUP = DCM0
>> > > > >> PARAMETER C_CLKOUT1_FREQ = 100000000
>> > > > >> PARAMETER C_CLKOUT1_BUF = TRUE
>> > > > >> PARAMETER C_CLKOUT1_PHASE = 90
>> > > > >> PARAMETER C_CLKOUT1_GROUP = DCM0
>> > > > >> PARAMETER C_CLKOUT2_FREQ = 300000000
>> > > > >> PARAMETER C_CLKOUT2_BUF = TRUE
>> > > > >> PARAMETER C_CLKOUT2_PHASE = 0
>> > > > >> PARAMETER C_CLKOUT2_GROUP = DCM0
>> > > > >> PARAMETER C_CLKOUT3_FREQ = 200000000
>> > > > >> PARAMETER C_CLKOUT3_BUF = TRUE
>> > > > >> PARAMETER C_CLKOUT3_PHASE = 0
>> > > > >> PARAMETER C_CLKOUT3_GROUP = NONE
>> > > > >> PARAMETER C_CLKOUT4_FREQ = 125000000
>> > > > >> PARAMETER C_CLKOUT4_BUF = TRUE
>> > > > >> PARAMETER C_CLKOUT4_PHASE = 0
>> > > > >> PARAMETER C_CLKOUT4_GROUP = NONE
>> > > > >> PORT CLKOUT0 = sys_clk_s
>> > > > >> PORT CLKOUT1 = DDR_SDRAM_mpmc_clk_90_s
>> > > > >> PORT CLKOUT2 = proc_clk_s
>> > > > >> PORT CLKOUT3 = clk_200mhz_s
>> > > > >> PORT CLKOUT4 = temac_clk_s
>> > > > >> PORT CLKIN = dcm_clk_s
>> > > > >> PORT LOCKED = Dcm_all_locked
>> > > > >> PORT RST = net_gnd
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN proc_sys_reset
>> > > > >> PARAMETER INSTANCE = proc_sys_reset_0
>> > > > >> PARAMETER HW_VER = 2.00.a
>> > > > >> PARAMETER C_EXT_RESET_HIGH = 0
>> > > > >> BUS_INTERFACE RESETPPC0 = ppc_reset_bus
>> > > > >> PORT Slowest_sync_clk = sys_clk_s
>> > > > >> PORT Dcm_locked = Dcm_all_locked
>> > > > >> PORT Ext_Reset_In = sys_rst_s
>> > > > >> PORT Bus_Struct_Reset = sys_bus_reset
>> > > > >> PORT Peripheral_Reset = sys_periph_reset
>> > > > >> END
>> > > > >>
>> > > > >> BEGIN xps_intc
>> > > > >> PARAMETER INSTANCE = xps_intc_0
>> > > > >> PARAMETER HW_VER = 1.00.a
>> > > > >> PARAMETER C_BASEADDR = 0x81800000
>> > > > >> PARAMETER C_HIGHADDR = 0x8180ffff
>> > > > >> BUS_INTERFACE SPLB = plb
>> > > > >> PORT Irq = EICC405EXTINPUTIRQ
>> > > > >> PORT Intr = RS232_Uart_IP2INTC_Irpt & LEDs_4Bit_IP2INTC_Irpt &
>> > > > IIC_EEPROM_IIC2INTC_Irpt & SysACE_CompactFlash_SysACE_IRQ &
>> > > > TriMode_MAC_GMII_TemacIntc0_Irpt & DDR_SDRAM_SDMA2_Rx_IntOut &
>> > > > DDR_SDRAM_SDMA2_Tx_IntOut
>> > > > >> END
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >> #address-cells = <1>;
>> > > > >> #size-cells = <1>;
>> > > > >> compatible = "xlnx,virtex";
>> > > > >> model = "testing";
>> > > > >> DDR_SDRAM: memory@0 {
>> > > > >> device_type = "memory";
>> > > > >> reg = < 0 8000000 >;
>> > > > >> } ;
>> > > > >> chosen {
>> > > > >> bootargs = "console=ttyS0,9600 ip=on
>> > > > nfsroot=172.16.40.76:/v2pclients/jhl26,tcp";
>> > > > >> linux,stdout-path = "/plb@0/serial@83e00000";
>> > > > >> } ;
>> > > > >> cpus {
>> > > > >> #address-cells = <1>;
>> > > > >> #cpus = <1>;
>> > > > >> #size-cells = <0>;
>> > > > >> ppc405_0: cpu@0 {
>> > > > >> clock-frequency = <11e1a300>;
>> > > > >> compatible = "PowerPC,405", "ibm,ppc405";
>> > > > >> d-cache-line-size = <20>;
>> > > > >> d-cache-size = <4000>;
>> > > > >> device_type = "cpu";
>> > > > >> i-cache-line-size = <20>;
>> > > > >> i-cache-size = <4000>;
>> > > > >> model = "PowerPC,405";
>> > > > >> reg = <0>;
>> > > > >> timebase-frequency = <11e1a300>;
>> > > > >> xlnx,apu-control = <de00>;
>> > > > >> xlnx,apu-udi-1 = <a18983>;
>> > > > >> xlnx,apu-udi-2 = <a38983>;
>> > > > >> xlnx,apu-udi-3 = <a589c3>;
>> > > > >> xlnx,apu-udi-4 = <a789c3>;
>> > > > >> xlnx,apu-udi-5 = <a98c03>;
>> > > > >> xlnx,apu-udi-6 = <ab8c03>;
>> > > > >> xlnx,apu-udi-7 = <ad8c43>;
>> > > > >> xlnx,apu-udi-8 = <af8c43>;
>> > > > >> xlnx,deterministic-mult = <0>;
>> > > > >> xlnx,disable-operand-forwarding = <1>;
>> > > > >> xlnx,fastest-plb-clock = "DPLB0";
>> > > > >> xlnx,generate-plb-timespecs = <1>;
>> > > > >> xlnx,mmu-enable = <1>;
>> > > > >> xlnx,pvr-high = <0>;
>> > > > >> xlnx,pvr-low = <0>;
>> > > > >> } ;
>> > > > >> } ;
>> > > > >> plb: plb@0 {
>> > > > >> #address-cells = <1>;
>> > > > >> #size-cells = <1>;
>> > > > >> compatible = "xlnx,plb-v46-1.02.a";
>> > > > >> ranges ;
>> > > > >> IIC_EEPROM: i2c@81600000 {
>> > > > >> compatible = "xlnx,xps-iic-2.00.a";
>> > > > >> interrupt-parent = <&xps_intc_0>;
>> > > > >> interrupts = < 4 2 >;
>> > > > >> reg = < 81600000 10000 >;
>> > > > >> xlnx,clk-freq = <5f5e100>;
>> > > > >> xlnx,family = "virtex4";
>> > > > >> xlnx,gpo-width = <1>;
>> > > > >> xlnx,iic-freq = <186a0>;
>> > > > >> xlnx,scl-inertial-delay = <0>;
>> > > > >> xlnx,sda-inertial-delay = <0>;
>> > > > >> xlnx,ten-bit-adr = <0>;
>> > > > >> } ;
>> > > > >> LEDs_4Bit: gpio@81400000 {
>> > > > >> compatible = "xlnx,xps-gpio-1.00.a";
>> > > > >> interrupt-parent = <&xps_intc_0>;
>> > > > >> interrupts = < 5 2 >;
>> > > > >> reg = < 81400000 10000 >;
>> > > > >> xlnx,all-inputs = <0>;
>> > > > >> xlnx,all-inputs-2 = <0>;
>> > > > >> xlnx,dout-default = <0>;
>> > > > >> xlnx,dout-default-2 = <0>;
>> > > > >> xlnx,family = "virtex4";
>> > > > >> xlnx,gpio-width = <4>;
>> > > > >> xlnx,interrupt-present = <1>;
>> > > > >> xlnx,is-bidir = <1>;
>> > > > >> xlnx,is-bidir-2 = <1>;
>> > > > >> xlnx,is-dual = <0>;
>> > > > >> xlnx,tri-default = <ffffffff>;
>> > > > >> xlnx,tri-default-2 = <ffffffff>;
>> > > > >> } ;
>> > > > >> RS232_Uart: serial@83e00000 {
>> > > > >> compatible = "xlnx,xps-uart16550-2.00.a";
>> > > > >> // compatible = "ns16550";
>> > > > >> device_type = "serial";
>> > > > >> interrupt-parent = <&xps_intc_0>;
>> > > > >> interrupts = < 6 2 >;
>> > > > >> reg = < 83e00000 10000 >;
>> > > > >> current-speed = <d#9600>;
>> > > > >> clock-frequency = <d#100000000>; /* added
>> > > > by jhl */
>> > > > >> reg-shift = <2>;
>> > > > >> xlnx,family = "virtex4";
>> > > > >> xlnx,has-external-rclk = <0>;
>> > > > >> xlnx,has-external-xin = <0>;
>> > > > >> xlnx,is-a-16550 = <1>;
>> > > > >> } ;
>> > > > >> SysACE_CompactFlash: sysace@83600000 {
>> > > > >> compatible = "xlnx,xps-sysace-1.00.a";
>> > > > >> interrupt-parent = <&xps_intc_0>;
>> > > > >> interrupts = < 3 2 >;
>> > > > >> reg = < 83600000 10000 >;
>> > > > >> xlnx,family = "virtex4";
>> > > > >> xlnx,mem-width = <10>;
>> > > > >> } ;
>> > > > >> TriMode_MAC_GMII: xps-ll-temac@81c00000 {
>> > > > >> #address-cells = <1>;
>> > > > >> #size-cells = <1>;
>> > > > >> compatible = "xlnx,compound";
>> > > > >> ethernet@81c00000 {
>> > > > >> compatible = "xlnx,xps-ll-temac-
>> > > > 1.01.a";
>> > > > >> device_type = "network";
>> > > > >> interrupt-parent =
>> > > > <&xps_intc_0>;
>> > > > >> interrupts = < 2 2 >;
>> > > > >> llink-connected = <&PIM2>;
>> > > > >> local-mac-address = [ 02 00 00
>> > > > 00 00 01 ];
>> > > > >> reg = < 81c00000 40 >;
>> > > > >> xlnx,bus2core-clk-ratio = <1>;
>> > > > >> xlnx,phy-type = <1>;
>> > > > >> xlnx,phyaddr = <1>;
>> > > > >> xlnx,rxcsum = <0>;
>> > > > >> xlnx,rxfifo = <1000>;
>> > > > >> xlnx,temac-type = <1>;
>> > > > >> xlnx,txcsum = <0>;
>> > > > >> xlnx,txfifo = <1000>;
>> > > > >> } ;
>> > > > >> } ;
>> > > > >> mpmc@0 {
>> > > > >> #address-cells = <1>;
>> > > > >> #size-cells = <1>;
>> > > > >> compatible = "xlnx,mpmc-4.00.a";
>> > > > >> PIM2: sdma@84600100 {
>> > > > >> compatible = "xlnx,ll-dma-
>> > > > 1.00.a";
>> > > > >> interrupt-parent =
>> > > > <&xps_intc_0>;
>> > > > >> interrupts = < 1 2 0 2 >;
>> > > > >> reg = < 84600100 80 >;
>> > > > >> } ;
>> > > > >> } ;
>> > > > >> xps_bram_if_cntlr_1: xps-bram-if-cntlr@ffffe000 {
>> > > > >> compatible = "xlnx,xps-bram-if-cntlr-
>> > > > 1.00.a";
>> > > > >> reg = < ffffe000 2000 >;
>> > > > >> xlnx,family = "virtex4";
>> > > > >> } ;
>> > > > >> xps_intc_0: interrupt-controller@81800000 {
>> > > > >> #interrupt-cells = <2>;
>> > > > >> compatible = "xlnx,xps-intc-1.00.a";
>> > > > >> interrupt-controller ;
>> > > > >> reg = < 81800000 10000 >;
>> > > > >> xlnx,num-intr-inputs = <7>;
>> > > > >> } ;
>> > > > >> } ;
>> > > > >> ppc405_0_dplb1: plb@1 {
>> > > > >> #address-cells = <1>;
>> > > > >> #size-cells = <1>;
>> > > > >> compatible = "xlnx,plb-v46-1.02.a";
>> > > > >> ranges ;
>> > > > >> } ;
>> > > > >> } ;
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >> -----Original Message-----
>> > > > >> From: Magnus Hjorth [mailto:mh@omnisys.se]
>> > > > >> Sent: Saturday, March 29, 2008 6:54 AM
>> > > > >> To: git
>> > > > >> Cc: linuxppc-embedded@ozlabs.org
>> > > > >> Subject: Xilinx LLTEMAC driver issues
>> > > > >>
>> > > > >> Hi,
>> > > > >>
>> > > > >> I'm having some networking troubles with the Xilinx LLTEMAC
>> > > > >> driver
>> from
>> > > the
>> > > > >> Xilinx Linux git tree (powerpc arch) on an ML403 board.
>> > > > >> EDK9.2SP2,
>> > > > >> xps_ll_temac v1.00.b
>> > > > >>
>> > > > >> The weird thing is, that it sort of half works. It successfully
>> makes a
>> > > DHCP
>> > > > >> request and gets its IP address. I tried setting up a tftpd
>> > > > >> server,
>> and
>> > > I can
>> > > > >> see UDP requests coming in but the response doesn't seem to come
>> out. I
>> > > also
>> > > > >> tried running a TCP server on the board, and it can see and
>> > > > >> accept
>> > > incoming
>> > > > >> connections but after that no data seems to get through. I can
>> > > > >> ping
>> out
>> > > and
>> > > > >> get around 40% packet loss.
>> > > > >>
>> > > > >> Looking at /proc/interrupts, I can see both TxDma interrupts and
>> RxDma
>> > > > >> interrupts. No eth0 interrupts but that seems to be OK judging
>> > > > >> by
>> the
>> > > driver
>> > > > >> source comments. Ifconfig shows no collistions, no dropped
>> > > > >> packets,
>> no
>> > > > errors,
>> > > > >> so the system seems to think that everything is OK.
>> > > > >>
>> > > > >> Clues anyone? I'm starting to run out of ideas...
>> > > > >>
>> > > > >> Best regards,
>> > > > >> Magnus
>> > > > >>
>> > > > >>
>> > > > >> --
>> > > > >>
>> > > > >> Magnus Hjorth, M.Sc.
>> > > > >> Omnisys Instruments AB
>> > > > >> Gruvgatan 8
>> > > > >> SE-421 30 V?stra Fr?lunda, SWEDEN
>> > > > >> Phone: +46 31 734 34 09
>> > > > >> Fax: +46 31 734 34 29
>> > > > >> http://www.omnisys.se
>> > > > >>
>> > > > >
>> > > > > _______________________________________________
>> > > > > Linuxppc-embedded mailing list
>> > > > > Linuxppc-embedded@ozlabs.org
>> > > > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>> > > _______________________________________________
>> > > Linuxppc-embedded mailing list
>> > > Linuxppc-embedded@ozlabs.org
>> > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>> > >
>> > >
>> > > --
>> > > Johann Baudy
>> > > johaahn@gmail.com
>> > > ________________________________
>> > > ? Windows Live Spaces ??????????????? ???????
>> >
>> >
>> >
>> > --
>> > Johann Baudy
>> > johaahn@gmail.com
>>
>>
>> ________________________________
>> ? Windows Live Spaces ??????????????? ???????
>
>
>
> --
> Johann Baudy
> johaahn@gmail.com
>
> ------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> End of Linuxppc-embedded Digest, Vol 44, Issue 17
> *************************************************
>
^ permalink raw reply
* Re: [kvm-ppc-devel] [PATCH] [v2] Add idle wait support for 44x platforms
From: Jimi Xenidis @ 2008-04-04 12:36 UTC (permalink / raw)
To: Jerone Young; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <afed3e5de82ab6c0ac8d.1207292794@thinkpadL>
On Apr 4, 2008, at 3:06 AM, Jerone Young wrote:
> # HG changeset patch
> # User Jerone Young <jyoung5@us.ibm.com>
> # Date 1207292108 18000
> # Node ID afed3e5de82ab6c0ac8d6ceeb0292b6c41ece1ed
> # Parent a5b2aebbc6ebd2439c655f1c047ed7e3c1991ec1
> [v2] Add idle wait support for 44x platforms
>
> This patch adds the ability for the CPU to go into wait state while
> in cpu_idle loop. This helps virtulization solutions know when the
> guest Linux kernel is in an idle state. There are two ways to do it.
>
> 1) Command line
> idle=spin <-- CPU will spin (this is the default)
> idle=wait <-- set CPU into wait state when idle
>
> 2) The device tree will be checked for the "/hypervisor" node
> If this node is seen it will use "wait" for idle, so that
> the hypervisor can know when guest Linux kernel it is in
> an idle state.
>
> This patch, unlike the last, isolates the code to 44x platforms.
>
> Signed-off-by: Jerone Young <jyoung5@us.ibm.com>
>
> diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/
> platforms/44x/Makefile
> --- a/arch/powerpc/platforms/44x/Makefile
> +++ b/arch/powerpc/platforms/44x/Makefile
> @@ -1,4 +1,4 @@ obj-$(CONFIG_44x) := misc_44x.o
> -obj-$(CONFIG_44x) := misc_44x.o
> +obj-$(CONFIG_44x) := misc_44x.o idle.o
> obj-$(CONFIG_EBONY) += ebony.o
> obj-$(CONFIG_TAISHAN) += taishan.o
> obj-$(CONFIG_BAMBOO) += bamboo.o
> diff --git a/arch/powerpc/platforms/44x/idle.c b/arch/powerpc/
> platforms/44x/idle.c
> new file mode 100644
> --- /dev/null
> +++ b/arch/powerpc/platforms/44x/idle.c
> @@ -0,0 +1,84 @@
> +/*
> + * Copyright 2008 IBM Corp.
> + *
> + * Derived from pasemi/idle.c
> + * by Olof Johansson <olof@lixom.net>
> + *
> + * Added by: Jerone Young <jyoung5@us.ibm.com>
> + *
> + * This program is free software; you can redistribute it and/or
> modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
> 02111-1307 USA
> + *
> + */
> +
> +#include <linux/of.h>
> +#include <linux/kernel.h>
> +#include <asm/machdep.h>
> +
> +static int current_mode = 0;
Doesn't matter if the 0 is functionally redundant or pleasing to your
eye, it is the "Linux way" to leave out the " = 0", so just do it
please.
> +
> +struct sleep_mode {
> + char *name;
> + void (*entry)(void);
> +};
> +
> +static void ppc44x_idle(void)
Perhaps "ppc44x_wait" is more appropriate?
> +{
> + unsigned long msr_save;
> +
> + msr_save = mfmsr();
> + /* set wait state MSR */
> + mtmsr(msr_save|MSR_WE|MSR_EE|MSR_CE);
Did we decide to drop MSR_DE?
> + /* return to initial state */
> + mtmsr(msr_save);
It may be my paranoia but I'm pretty sure you need the isync() after
_both_ mtmsr()s
Certainly can't hurt.
> +}
> +
> +static struct sleep_mode modes[] = {
> + { .name = "spin", .entry = NULL },
> + { .name = "wait", .entry = &ppc44x_idle },
> +};
> +
> +int __init ppc44x_idle_init(void)
> +{
> + void *func = modes[current_mode].entry;
> + struct device_node *node;
> +
> + node = of_find_node_by_path("/hypervisor");
> + if (node) {
> + /* if we find /hypervisor node is in device tree,
> + set idle mode to wait */
> + func = &ppc44x_idle; /* wait */
> + of_node_put(node);
> + }
> +
> + ppc_md.power_save = func;
> + return 0;
> +}
> +
> +arch_initcall(ppc44x_idle_init);
IIRC, this would over-ride the idle_param() below, is that the
intended behavior?
> +
> +static int __init idle_param(char *p)
> +{
> + int i;
> +
> + for (i = 0; i < sizeof(modes)/ARRAY_SIZE(modes); i++) {
It is supposed to be:
for (i = 0; i < ARRAY_SIZE(modes); i++) {
What you have will actually eval to 0 and would have never checked
anything :)
> + if (!strcmp(modes[i].name, p)) {
> + current_mode = i;
> + break;
> + }
> + }
> +
> + return 0;
> +}
> +
> +early_param("idle", idle_param);
>
> ----------------------------------------------------------------------
> ---
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/
> marketplace
> _______________________________________________
> kvm-ppc-devel mailing list
> kvm-ppc-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel
^ permalink raw reply
* [PATCH] ehea: Fix DLPAR memory add support
From: Thomas Klein @ 2008-04-04 13:04 UTC (permalink / raw)
To: Jeff Garzik
Cc: Jan-Bernd Themann, netdev, Hannes Hering, linux-kernel, linux-ppc,
Christoph Raisch, Stefan Roscher
This patch fixes two weaknesses in send/receive packet handling which may
lead to kernel panics during DLPAR memory add operations.
Signed-off-by: Thomas Klein <tklein@de.ibm.com>
---
diff -Nurp -X dontdiff linux-2.6.25-rc8/drivers/net/ehea/ehea.h patched_kernel/drivers/net/ehea/ehea.h
--- linux-2.6.25-rc8/drivers/net/ehea/ehea.h 2008-04-01 21:44:26.000000000 +0200
+++ patched_kernel/drivers/net/ehea/ehea.h 2008-04-03 15:36:36.000000000 +0200
@@ -40,7 +40,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0089"
+#define DRV_VERSION "EHEA_0090"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
@@ -371,6 +371,7 @@ struct ehea_port_res {
struct ehea_q_skb_arr rq2_skba;
struct ehea_q_skb_arr rq3_skba;
struct ehea_q_skb_arr sq_skba;
+ int sq_skba_size;
spinlock_t netif_queue;
int queue_stopped;
int swqe_refill_th;
diff -Nurp -X dontdiff linux-2.6.25-rc8/drivers/net/ehea/ehea_main.c patched_kernel/drivers/net/ehea/ehea_main.c
--- linux-2.6.25-rc8/drivers/net/ehea/ehea_main.c 2008-04-01 21:44:26.000000000 +0200
+++ patched_kernel/drivers/net/ehea/ehea_main.c 2008-04-03 15:36:36.000000000 +0200
@@ -349,7 +349,8 @@ static void ehea_refill_rq1(struct ehea_
pr->rq1_skba.os_skbs = 0;
if (unlikely(test_bit(__EHEA_STOP_XFER, &ehea_driver_flags))) {
- pr->rq1_skba.index = index;
+ if (nr_of_wqes > 0)
+ pr->rq1_skba.index = index;
pr->rq1_skba.os_skbs = fill_wqes;
return;
}
@@ -1464,7 +1465,9 @@ static int ehea_init_port_res(struct ehe
init_attr->act_nr_rwqes_rq2,
init_attr->act_nr_rwqes_rq3);
- ret = ehea_init_q_skba(&pr->sq_skba, init_attr->act_nr_send_wqes + 1);
+ pr->sq_skba_size = init_attr->act_nr_send_wqes + 1;
+
+ ret = ehea_init_q_skba(&pr->sq_skba, pr->sq_skba_size);
ret |= ehea_init_q_skba(&pr->rq1_skba, init_attr->act_nr_rwqes_rq1 + 1);
ret |= ehea_init_q_skba(&pr->rq2_skba, init_attr->act_nr_rwqes_rq2 + 1);
ret |= ehea_init_q_skba(&pr->rq3_skba, init_attr->act_nr_rwqes_rq3 + 1);
@@ -2621,6 +2624,22 @@ void ehea_purge_sq(struct ehea_qp *orig_
}
}
+void ehea_flush_sq(struct ehea_port *port)
+{
+ int i;
+
+ for (i = 0; i < port->num_def_qps + port->num_add_tx_qps; i++) {
+ struct ehea_port_res *pr = &port->port_res[i];
+ int swqe_max = pr->sq_skba_size - 2 - pr->swqe_ll_count;
+ int k = 0;
+ while (atomic_read(&pr->swqe_avail) < swqe_max) {
+ msleep(5);
+ if (++k == 20)
+ break;
+ }
+ }
+}
+
int ehea_stop_qps(struct net_device *dev)
{
struct ehea_port *port = netdev_priv(dev);
@@ -2845,6 +2864,7 @@ static void ehea_rereg_mrs(struct work_s
if (dev->flags & IFF_UP) {
down(&port->port_lock);
netif_stop_queue(dev);
+ ehea_flush_sq(port);
ret = ehea_stop_qps(dev);
if (ret) {
up(&port->port_lock);
^ permalink raw reply
* Oops MPC8343 @ 2.6.25-rc7
From: Andre Schwarz @ 2008-04-04 13:06 UTC (permalink / raw)
To: linux-ppc list
All,
I'm having trouble booting a MPC8343 into a recent 2.6.25-rc7 kernel.
Kernel config has been reduced to a minimum : no PCI, no netwoking, i2c,
spi ...
dts has been reduced to the CPU, soc and ipic nodes.
U-Boot fills out dtb correctly - as far as I can see.
Kernel crashes on various "of_" functions regarding to call trace.
There's also strange messages :
WARNING: Estimating decrementer frequency (not found)
WARNING: Estimating processor frequency (not found)
They're coming from "generic_calibrate_decr()" in kernel/time.c.
Looks like there something basically wrong with my dtb
location/processing, since the "timebase-frequency" is present and valid :
cpus {
#address-cells = <0x00000001>;
#size-cells = <0x00000000>;
PowerPC,8343@0 {
device_type = "cpu";
reg = <0x00000000>;
d-cache-line-size = <0x00000020>;
i-cache-line-size = <0x00000020>;
d-cache-size = <0x00008000>;
i-cache-size = <0x00008000>;
timebase-frequency = <0x03f940aa>;
bus-frequency = <0x0fe502a8>;
clock-frequency = <0x17d783fc>;
};
};
Any hints ?
regards,
Andre Schwarz
Matrix Vision
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
^ permalink raw reply
* [PATCH/RFC] via-pmu: remove mdelays from suspend/resume code
From: Johannes Berg @ 2008-04-03 15:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
I don't see a reason for either of those mdelay()s, is there any? Works
fine for me without them...
johannes
---
drivers/macintosh/via-pmu.c | 20 +++-----------------
1 file changed, 3 insertions(+), 17 deletions(-)
--- everything.orig/drivers/macintosh/via-pmu.c 2008-04-03 17:27:29.000000000 +0200
+++ everything/drivers/macintosh/via-pmu.c 2008-04-03 17:28:23.000000000 +0200
@@ -2165,8 +2165,6 @@ static void pmac_suspend_disable_irqs(vo
static int powerbook_sleep(suspend_state_t state)
{
- int error = 0;
-
/* Wait for completion of async requests */
while (!batt_req.complete)
pmu_poll();
@@ -2183,25 +2181,15 @@ static int powerbook_sleep(suspend_state
switch (pmu_kind) {
case PMU_OHARE_BASED:
- error = powerbook_sleep_3400();
- break;
+ return powerbook_sleep_3400();
case PMU_HEATHROW_BASED:
case PMU_PADDINGTON_BASED:
- error = powerbook_sleep_grackle();
- break;
+ return powerbook_sleep_grackle();
case PMU_KEYLARGO_BASED:
- error = powerbook_sleep_Core99();
- break;
+ return powerbook_sleep_Core99();
default:
return -ENOSYS;
}
-
- if (error)
- return error;
-
- mdelay(100);
-
- return 0;
}
static void pmac_suspend_enable_irqs(void)
@@ -2210,8 +2198,6 @@ static void pmac_suspend_enable_irqs(voi
adb_int_pending = 1;
via_pmu_interrupt(0, NULL);
- mdelay(10);
-
/* Call platform functions marked "on wake" */
pmac_pfunc_base_resume();
pmac_pfunc_i2c_resume();
^ permalink raw reply
* Re: [kvm-ppc-devel] [PATCH] Add idle wait support for 44x platforms
From: Hollis Blanchard @ 2008-04-04 14:33 UTC (permalink / raw)
To: jyoung5; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <1207288799.6971.11.camel@thinkpadL>
On Friday 04 April 2008 00:59:59 Jerone Young wrote:
> On Thu, 2008-04-03 at 21:00 -0500, Josh Boyer wrote:
> > On Thu, 03 Apr 2008 17:43:02 -0500
> >
> > Jerone Young <jyoung5@us.ibm.com> wrote:
> > > # HG changeset patch
> > > # User Jerone Young <jyoung5@us.ibm.com>
> > > # Date 1207262487 18000
> > > # Node ID 7226bef216680748a50327900572c2fbc3e762b0
> > > # Parent =A0a5b2aebbc6ebd2439c655f1c047ed7e3c1991ec1
> >
> > As a complete and unrelated side note to the actual patch, wtf is this
> > hg stuff? =A0I can't really tell what tree you're even basing this off =
of.
>
> hehe...I primary use hg as it's just much easier to deal with. Yes I do
> go through the conversion. But it is worth it. The patches I send are in
> git format.
By the way, you can use "hg email --plain" to avoid confusing the=20
unenlightened. ;) The Mercurial changeset data won't be useful here=20
anyways...
In reply to an earlier unrelated comment, there is also "hg email --diffsta=
t".
=2D-=20
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: cpu_clock confusion (was: printk time confusion?)
From: Ingo Molnar @ 2008-04-04 14:46 UTC (permalink / raw)
To: Johannes Berg
Cc: linuxppc-dev list, Arnd Bergmann, Linux Kernel list,
Benjamin Herrenschmidt
In-Reply-To: <1207240450.3797.22.camel@johannes.berg>
* Johannes Berg <johannes@sipsolutions.net> wrote:
> Hi,
>
> > > Not sure whether the lockdep patches or something else is causing this
> > > as I haven't checked w/o the patches yet, but I seem to be having some
> > > confusion of printk timestamps:
> >
> > Tried reverting the patches ?
>
> That didn't help, so it's not the lockdep patches causing it. I'm still
> seeing printk timestamps like this:
>
> [ 2.764009 (3/3)]
> [ 4.272241 (2/2)]
> [ 4.272322 (2/2)]
> [ 4.272375 (2/2)]
> [ 2.948002 (3/3)]
>
> As you can see, I added printk_cpu and smp_processor_id() to the
> printk timestamp output and thus it is obvious that the different
> times come from different CPUs.
the fixes are queued for v2.6.26. You can pick them up from
sched-devel/latest as well:
http://people.redhat.com/mingo/sched-devel.git/README
Ingo
^ permalink raw reply
* Re: Help required on MPC82XX USB Host controller Development using m82xx-hcd.
From: Amarendra_Reddy @ 2008-04-04 14:47 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200803270956.12203.laurentp@cse-semaphore.com>
Hi Laurent,
Thanks for your reply.
Most of the modules of the new product(based on Kernrel 2.6.10) are
completed, except for the USB module. Hence we have to work with the kernre=
l
2.6.10 even for USB module.
We integrated cmp2usb project into Kernel 2.6.10, and with some
modifications and compiled the kernel successfully.
When pendrive is inserted into the USB port we are facing the below
mentioned problems.
(sorry for a lengthy posting)
We would be thankful if you / anyone could suggest us with some solution or
idea or an alternative approach.
Given below is the Console Output=20
CASE 1: When pendrive is inserted "Directly to USB port of the 8272ADS
board".
CASE 2: When pendrive is inserted on an "External hub which is conntected t=
o
USB port of 8272ADS board".
Output from console:
CASE 1: Pendrive Directly connected to uSB port of the 8272ADS board
USB Universal Host Controller Interface driver v2.2
Registering platform device 'mpc82xx-hcd.3'. Parent at platform
=3D> driver mpc82xx-hcd, 2005
mpc82xx-hcd mpc82xx-hcd.3: PQ2 intergrated USB controller v0.1
mpc82xx-hcd mpc82xx-hcd.3: new USB bus registered, assigned bus number 1
usb usb1: Product: PQ2 intergrated USB controller v0.1
usb usb1: Manufacturer: Linux 2.6.10_mvl401-8272ads mpc82xx-hcd
usb usb1: SerialNumber: mpc82xx-hcd.3
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
PQ2USB: debug file creation
........after SANDISK pendrive inserted.........
usb 1-1: new full speed USB device using mpc82xx-hcd and address 2
usb 1-1: Product: U3 Cruzer Micro
usb 1-1: Manufacturer: SanDisk Corporation
Oops: Exception in kernel mode, sig: 4 [#1]
........after unknown/generic manufacturer's pendrive inserted.......
usb 1-1: new full speed USB device using mpc82xx-hcd and address 2
usb 1-1: device descriptor read/64, error -110
usb 1-1: device descriptor read/64, error -110
usb 1-1: new full speed USB device using mpc82xx-hcd and address 3
usb 1-1: device descriptor read/64, error -110
usb 1-1: device descriptor read/64, error -110
usb 1-1: new full speed USB device using mpc82xx-hcd and address 4
usb 1-1: device not accepting address 4, error -110
usb 1-1: new full speed USB device using mpc82xx-hcd and address 5
usb 1-1: device not accepting address 5, error -110
CASE 2: Pendrive is inserted on an "External hub which is conntected to USB
port of 8272ADS board".
USB Universal Host Controller Interface driver v2.2
sl811: driver sl811-hcd, 19 May 2005
Registering platform device 'mpc82xx-hcd.3'. Parent at platform
=3D> driver mpc82xx-hcd, 2005
mpc82xx-hcd mpc82xx-hcd.3: PQ2 intergrated USB controller v0.1
mpc82xx-hcd mpc82xx-hcd.3: new USB bus registered, assigned bus number 1
usb usb1: Product: PQ2 intergrated USB controller v0.1
usb usb1: Manufacturer: Linux 2.6.10_mvl401-8272ads mpc82xx-hcd
usb usb1: SerialNumber: mpc82xx-hcd.3
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
PQ2USB: debug file creation
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
.......after SANDISK pendrive inserted........
usb 1-1.3: new full speed USB device using mpc82xx-hcd and address 3
usb 1-1.3: Product: U3 Cruzer Micro
usb 1-1.3: Manufacturer: SanDisk Corporation
usb 1-1.3: can't set config #1, error -110
hub 1-1:1.0: cannot disable port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: Cannot enable port 3. Maybe the USB cable is bad?
hub 1-1:1.0: cannot disable port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: Cannot enable port 3. Maybe the USB cable is bad?
hub 1-1:1.0: cannot disable port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: cannot reset port 3 (err =3D -110)
hub 1-1:1.0: Cannot enable port 3. Maybe the USB cable is bad?
hub 1-1:1.0: cannot disable port 3 (err =3D -110)
hub 1-1:1.0: cannot disable port 3 (err =3D -110)
hub 1-1:1.0: hub_port_status failed (err =3D -110)
........after unknown manufacturer's pendrive inserted...........
usb 1-1.1: new full speed USB device using mpc82xx-hcd and address 7
usb 1-1.1: Product: Mass Storage Device
usb 1-1.1: Manufacturer: Generic
usb 1-1.1: SerialNumber: 6EOG5LAF
scsi0 : SCSI emulation for USB Mass Storage devices
floating point used in kernel (task=3Dc0306050, pc=3Dc022a5f8)
Oops: Exception in kernel mode, sig: 4 [#1]
Thanks & Regards
Amarendra Reddy
--------------------------------------------------------
Laurent Pinchart-4 wrote:
>=20
> Hi Amarendra,
>=20
> On Wednesday 26 March 2008 17:11, Amarendra_Reddy wrote:
>>=20
>> Hi all,
>>=20
>> We are working on implementation of the USB host controller driver for
>> the
>> MPC8272ADS (eval board).=20
>>=20
>> The USB Host controller on MPC8272 chip is neither UHCI nor OHCI
>> compliant.=20
>>=20
>> We downloaded the project cpm2usb and the patches created by Mr.Mike
>> Rapoport from http://cpm2usb.sourceforge.net
>>=20
>> We integrated the 'm82xx-hcd' into the 2.6.10 source with few changes to
>> usb
>> data structures (usb_hcd,usb_device,usb_host_endpoint) and to struct
>> hc_driver. Also updated the function ''tx_err' present in m82xx-hcd.c.
>=20
> The cpm2usb project isn't maintained. If possible you should upgrade to a
> more=20
> recent kernel and switch to the powerpc architecture where a new USB
> driver=20
> called fhci is available.
>=20
> The MPC872ADS is supported in recent kernels so switching shouldn't be to=
o=20
> difficult.
>=20
> Best regards,
>=20
> --=20
> Laurent Pinchart
> CSE Semaphore Belgium
>=20
> Chauss=C3=A9e de Bruxelles, 732A
> B-1410 Waterloo
> Belgium
>=20
> T +32 (2) 387 42 59
> F +32 (2) 387 42 75
>=20
> =20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
--=20
View this message in context: http://www.nabble.com/Help-on-MPC82XX-USB-Hos=
t-controller-Development-using-m82xx-hcd.-tp16304553p16491756.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [kvm-ppc-devel] [PATCH] [v2] Add idle wait support for 44x platforms
From: Jerone Young @ 2008-04-04 15:42 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <835D8B13-CF90-4013-A172-8243BF93DE52@pobox.com>
On Fri, 2008-04-04 at 08:36 -0400, Jimi Xenidis wrote:
> On Apr 4, 2008, at 3:06 AM, Jerone Young wrote:
>
> > # HG changeset patch
> > # User Jerone Young <jyoung5@us.ibm.com>
> > # Date 1207292108 18000
> > # Node ID afed3e5de82ab6c0ac8d6ceeb0292b6c41ece1ed
> > # Parent a5b2aebbc6ebd2439c655f1c047ed7e3c1991ec1
> > [v2] Add idle wait support for 44x platforms
> >
> > This patch adds the ability for the CPU to go into wait state while
> > in cpu_idle loop. This helps virtulization solutions know when the
> > guest Linux kernel is in an idle state. There are two ways to do it.
> >
> > 1) Command line
> > idle=spin <-- CPU will spin (this is the default)
> > idle=wait <-- set CPU into wait state when idle
> >
> > 2) The device tree will be checked for the "/hypervisor" node
> > If this node is seen it will use "wait" for idle, so that
> > the hypervisor can know when guest Linux kernel it is in
> > an idle state.
> >
> > This patch, unlike the last, isolates the code to 44x platforms.
> >
> > Signed-off-by: Jerone Young <jyoung5@us.ibm.com>
> >
> > diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/
> > platforms/44x/Makefile
> > --- a/arch/powerpc/platforms/44x/Makefile
> > +++ b/arch/powerpc/platforms/44x/Makefile
> > @@ -1,4 +1,4 @@ obj-$(CONFIG_44x) := misc_44x.o
> > -obj-$(CONFIG_44x) := misc_44x.o
> > +obj-$(CONFIG_44x) := misc_44x.o idle.o
> > obj-$(CONFIG_EBONY) += ebony.o
> > obj-$(CONFIG_TAISHAN) += taishan.o
> > obj-$(CONFIG_BAMBOO) += bamboo.o
> > diff --git a/arch/powerpc/platforms/44x/idle.c b/arch/powerpc/
> > platforms/44x/idle.c
> > new file mode 100644
> > --- /dev/null
> > +++ b/arch/powerpc/platforms/44x/idle.c
> > @@ -0,0 +1,84 @@
> > +/*
> > + * Copyright 2008 IBM Corp.
> > + *
> > + * Derived from pasemi/idle.c
> > + * by Olof Johansson <olof@lixom.net>
> > + *
> > + * Added by: Jerone Young <jyoung5@us.ibm.com>
> > + *
> > + * This program is free software; you can redistribute it and/or
> > modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > + * along with this program; if not, write to the Free Software
> > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
> > 02111-1307 USA
> > + *
> > + */
> > +
> > +#include <linux/of.h>
> > +#include <linux/kernel.h>
> > +#include <asm/machdep.h>
> > +
> > +static int current_mode = 0;
>
> Doesn't matter if the 0 is functionally redundant or pleasing to your
> eye, it is the "Linux way" to leave out the " = 0", so just do it
> please.
>
Ok this can be removed.
> > +
> > +struct sleep_mode {
> > + char *name;
> > + void (*entry)(void);
> > +};
> > +
> > +static void ppc44x_idle(void)
> Perhaps "ppc44x_wait" is more appropriate?
> > +{
> > + unsigned long msr_save;
> > +
> > + msr_save = mfmsr();
> > + /* set wait state MSR */
> > + mtmsr(msr_save|MSR_WE|MSR_EE|MSR_CE);
>
> Did we decide to drop MSR_DE?
Hollis argued it down on an earlier email on kvm-ppc-devel. Though I did
have it in one of the earlier patches.
>
> > + /* return to initial state */
> > + mtmsr(msr_save);
>
> It may be my paranoia but I'm pretty sure you need the isync() after
> _both_ mtmsr()s
> Certainly can't hurt.
I could add this back. Though everyone had already agreed on it without
it. So figured it was safer to go witout it. But I can add it back.
>
> > +}
> > +
> > +static struct sleep_mode modes[] = {
> > + { .name = "spin", .entry = NULL },
> > + { .name = "wait", .entry = &ppc44x_idle },
> > +};
> > +
> > +int __init ppc44x_idle_init(void)
> > +{
> > + void *func = modes[current_mode].entry;
> > + struct device_node *node;
> > +
> > + node = of_find_node_by_path("/hypervisor");
> > + if (node) {
> > + /* if we find /hypervisor node is in device tree,
> > + set idle mode to wait */
> > + func = &ppc44x_idle; /* wait */
> > + of_node_put(node);
> > + }
> > +
> > + ppc_md.power_save = func;
> > + return 0;
> > +}
> > +
> > +arch_initcall(ppc44x_idle_init);
>
> IIRC, this would over-ride the idle_param() below, is that the
> intended behavior?
Yes. At the moment if it detects a hypervisor in the kernel tree it
overrides what the command line says.
>
> > +
> > +static int __init idle_param(char *p)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < sizeof(modes)/ARRAY_SIZE(modes); i++) {
>
> It is supposed to be:
> for (i = 0; i < ARRAY_SIZE(modes); i++) {
> What you have will actually eval to 0 and would have never checked
> anything :)
Ouch. My bad. Wasn't thinking when I added that.
>
> > + if (!strcmp(modes[i].name, p)) {
> > + current_mode = i;
> > + break;
> > + }
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +early_param("idle", idle_param);
> >
> > ----------------------------------------------------------------------
> > ---
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/
> > marketplace
> > _______________________________________________
> > kvm-ppc-devel mailing list
> > kvm-ppc-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel
>
^ permalink raw reply
* [PATCH] [v3] Add idle wait support for 44x platforms
From: Jerone Young @ 2008-04-04 15:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kvm-ppc-devel
2 files changed, 87 insertions(+), 1 deletion(-)
arch/powerpc/platforms/44x/Makefile | 2
arch/powerpc/platforms/44x/idle.c | 86 +++++++++++++++++++++++++++++++++++
This patch adds the ability for the CPU to go into wait state while in cpu_idle loop. This helps virtulization solutions know when the guest Linux kernel is in an idle state. There are two ways to do it.
1) Command line
idle=spin <-- CPU will spin (this is the default)
idle=wait <-- set CPU into wait state when idle
2) The device tree will be checked for the "/hypervisor" node
If this node is seen it will use "wait" for idle, so that
the hypervisor can know when guest Linux kernel it is in
an idle state.
This patch, unlike the last, isolates the code to 44x platforms.
Signed-off-by: Jerone Young <jyoung5@us.ibm.com>
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -1,4 +1,4 @@ obj-$(CONFIG_44x) := misc_44x.o
-obj-$(CONFIG_44x) := misc_44x.o
+obj-$(CONFIG_44x) := misc_44x.o idle.o
obj-$(CONFIG_EBONY) += ebony.o
obj-$(CONFIG_TAISHAN) += taishan.o
obj-$(CONFIG_BAMBOO) += bamboo.o
diff --git a/arch/powerpc/platforms/44x/idle.c b/arch/powerpc/platforms/44x/idle.c
new file mode 100644
--- /dev/null
+++ b/arch/powerpc/platforms/44x/idle.c
@@ -0,0 +1,86 @@
+/*
+ * Copyright 2008 IBM Corp.
+ *
+ * Based on arch/powerpc/platforms/pasemi/idle.c:
+ * Copyright (C) 2006-2007 PA Semi, Inc
+ *
+ * Added by: Jerone Young <jyoung5@us.ibm.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include <linux/of.h>
+#include <linux/kernel.h>
+#include <asm/machdep.h>
+
+static int current_mode;
+
+struct sleep_mode {
+ char *name;
+ void (*entry)(void);
+};
+
+static void ppc44x_idle(void)
+{
+ unsigned long msr_save;
+
+ msr_save = mfmsr();
+ /* set wait state MSR */
+ mtmsr(msr_save|MSR_WE|MSR_EE|MSR_CE);
+ isync();
+ /* return to initial state */
+ mtmsr(msr_save);
+ isync();
+}
+
+static struct sleep_mode modes[] = {
+ { .name = "spin", .entry = NULL },
+ { .name = "wait", .entry = &ppc44x_idle },
+};
+
+int __init ppc44x_idle_init(void)
+{
+ void *func = modes[current_mode].entry;
+ struct device_node *node;
+
+ node = of_find_node_by_path("/hypervisor");
+ if (node) {
+ /* if we find /hypervisor node is in device tree,
+ set idle mode to wait */
+ func = &ppc44x_idle; /* wait */
+ of_node_put(node);
+ }
+
+ ppc_md.power_save = func;
+ return 0;
+}
+
+arch_initcall(ppc44x_idle_init);
+
+static int __init idle_param(char *p)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(modes); i++) {
+ if (!strcmp(modes[i].name, p)) {
+ current_mode = i;
+ break;
+ }
+ }
+
+ return 0;
+}
+
+early_param("idle", idle_param);
^ permalink raw reply
* Re: [kvm-ppc-devel] [PATCH] [v2] Add idle wait support for 44x platforms
From: Hollis Blanchard @ 2008-04-04 15:56 UTC (permalink / raw)
To: jyoung5; +Cc: kvm-ppc-devel, linuxppc-dev, Jimi Xenidis
In-Reply-To: <1207323761.6634.6.camel@thinkpadL>
On Friday 04 April 2008 10:42:41 Jerone Young wrote:
> > > +{
> > > +=A0=A0=A0unsigned long msr_save;
> > > +
> > > +=A0=A0=A0msr_save =3D mfmsr();
> > > +=A0=A0=A0/* set wait state MSR */
> > > +=A0=A0=A0mtmsr(msr_save|MSR_WE|MSR_EE|MSR_CE);
> >
> > Did we decide to drop MSR_DE?
>
> Hollis argued it down on an earlier email on kvm-ppc-devel. Though I did
> have it in one of the earlier patches.
I didn't comment either way. However, looking at the 440 user manual now, i=
t=20
seems clear that DE should be set to allow JTAG debugger events.
=2D-=20
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Grant Likely @ 2008-04-04 16:11 UTC (permalink / raw)
To: Bartlomiej Sieka; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <47F60D5D.5090402@semihalf.com>
On Fri, Apr 4, 2008 at 5:13 AM, Bartlomiej Sieka <tur@semihalf.com> wrote:
>
> Bartlomiej Sieka wrote:
>
> > Hi Grant,
> >
> > Grant Likely wrote:
> > > I'm thinking 'optimized' defconfigs should go into a subdirectory.
> >
> > This requires a change to the top-level Makefile and shepherding this
> > change upstream. Could we perhaps try to avoid this by having optimized
> > defconfigs in the form of, for example:
I don't think changes are required to put them in a subdir:
$ mkdir arch/powerpc/configs/optimized
$ cp arch/powerpc/configs/mpc5200_defconfig
arch/powerpc/configs/optimized/lite5200_defconfig
$ make optimized/lite5200_defconfig
This works for me.
>
> Grant,
>
> Any thoughts on the above?
Sorry I didn't reply earlier
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Grant Likely @ 2008-04-04 16:14 UTC (permalink / raw)
To: Bartlomiej Sieka; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <fa686aa40804040911o63e2e3efg2d9a74fff082fb16@mail.gmail.com>
On Fri, Apr 4, 2008 at 10:11 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > > I'm thinking 'optimized' defconfigs should go into a subdirectory.
> > >
> > > This requires a change to the top-level Makefile and shepherding this
> > > change upstream. Could we perhaps try to avoid this by having optimized
> > > defconfigs in the form of, for example:
>
> I don't think changes are required to put them in a subdir:
>
> $ mkdir arch/powerpc/configs/optimized
> $ cp arch/powerpc/configs/mpc5200_defconfig
> arch/powerpc/configs/optimized/lite5200_defconfig
> $ make optimized/lite5200_defconfig
>
> This works for me.
However, I'm not sure what the naming scheme should be for subdirectories.
board vendor?
host processor?
just one big directory for board specific defconfigs?
Olof, Kumar, Josh; any thoughts?
Not that it matters much; files are easy to move around later.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] [v4] Add idle wait support for 44x platforms
From: Jerone Young @ 2008-04-04 16:28 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kvm-ppc-devel
2 files changed, 87 insertions(+), 1 deletion(-)
arch/powerpc/platforms/44x/Makefile | 2
arch/powerpc/platforms/44x/idle.c | 86 +++++++++++++++++++++++++++++++++++
- adds MSR_DE to MSRs to enable while in wait state
This patch adds the ability for the CPU to go into wait state while in cpu_idle loop. This helps virtulization solutions know when the guest Linux kernel is in an idle state. There are two ways to do it.
1) Command line
idle=spin <-- CPU will spin (this is the default)
idle=wait <-- set CPU into wait state when idle
2) The device tree will be checked for the "/hypervisor" node
If this node is seen it will use "wait" for idle, so that
the hypervisor can know when guest Linux kernel it is in
an idle state.
This patch, unlike the last, isolates the code to 44x platforms.
Signed-off-by: Jerone Young <jyoung5@us.ibm.com>
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -1,4 +1,4 @@ obj-$(CONFIG_44x) := misc_44x.o
-obj-$(CONFIG_44x) := misc_44x.o
+obj-$(CONFIG_44x) := misc_44x.o idle.o
obj-$(CONFIG_EBONY) += ebony.o
obj-$(CONFIG_TAISHAN) += taishan.o
obj-$(CONFIG_BAMBOO) += bamboo.o
diff --git a/arch/powerpc/platforms/44x/idle.c b/arch/powerpc/platforms/44x/idle.c
new file mode 100644
--- /dev/null
+++ b/arch/powerpc/platforms/44x/idle.c
@@ -0,0 +1,86 @@
+/*
+ * Copyright 2008 IBM Corp.
+ *
+ * Based on arch/powerpc/platforms/pasemi/idle.c:
+ * Copyright (C) 2006-2007 PA Semi, Inc
+ *
+ * Added by: Jerone Young <jyoung5@us.ibm.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include <linux/of.h>
+#include <linux/kernel.h>
+#include <asm/machdep.h>
+
+static int current_mode;
+
+struct sleep_mode {
+ char *name;
+ void (*entry)(void);
+};
+
+static void ppc44x_idle(void)
+{
+ unsigned long msr_save;
+
+ msr_save = mfmsr();
+ /* set wait state MSR */
+ mtmsr(msr_save|MSR_WE|MSR_EE|MSR_CE|MSR_DE);
+ isync();
+ /* return to initial state */
+ mtmsr(msr_save);
+ isync();
+}
+
+static struct sleep_mode modes[] = {
+ { .name = "spin", .entry = NULL },
+ { .name = "wait", .entry = &ppc44x_idle },
+};
+
+int __init ppc44x_idle_init(void)
+{
+ void *func = modes[current_mode].entry;
+ struct device_node *node;
+
+ node = of_find_node_by_path("/hypervisor");
+ if (node) {
+ /* if we find /hypervisor node is in device tree,
+ set idle mode to wait */
+ func = &ppc44x_idle; /* wait */
+ of_node_put(node);
+ }
+
+ ppc_md.power_save = func;
+ return 0;
+}
+
+arch_initcall(ppc44x_idle_init);
+
+static int __init idle_param(char *p)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(modes); i++) {
+ if (!strcmp(modes[i].name, p)) {
+ current_mode = i;
+ break;
+ }
+ }
+
+ return 0;
+}
+
+early_param("idle", idle_param);
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Olof Johansson @ 2008-04-04 16:38 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40804040914s3f682e37r16b4cb299e2fc97e@mail.gmail.com>
On Fri, Apr 04, 2008 at 10:14:34AM -0600, Grant Likely wrote:
> On Fri, Apr 4, 2008 at 10:11 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > > > I'm thinking 'optimized' defconfigs should go into a subdirectory.
> > > >
> > > > This requires a change to the top-level Makefile and shepherding this
> > > > change upstream. Could we perhaps try to avoid this by having optimized
> > > > defconfigs in the form of, for example:
> >
> > I don't think changes are required to put them in a subdir:
> >
> > $ mkdir arch/powerpc/configs/optimized
> > $ cp arch/powerpc/configs/mpc5200_defconfig
> > arch/powerpc/configs/optimized/lite5200_defconfig
> > $ make optimized/lite5200_defconfig
> >
> > This works for me.
>
> However, I'm not sure what the naming scheme should be for subdirectories.
>
> board vendor?
> host processor?
> just one big directory for board specific defconfigs?
>
> Olof, Kumar, Josh; any thoughts?
>
> Not that it matters much; files are easy to move around later.
I really like the idea. It would probably make sense to organize it in
the same way as the platforms are done today, i.e. per processor/platform
family. And then have shared/merged configs in the main config directory.
-Olof
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Josh Boyer @ 2008-04-04 17:15 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20080404163858.GA25717@lixom.net>
On Fri, 2008-04-04 at 11:38 -0500, Olof Johansson wrote:
> On Fri, Apr 04, 2008 at 10:14:34AM -0600, Grant Likely wrote:
> > On Fri, Apr 4, 2008 at 10:11 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > > > > I'm thinking 'optimized' defconfigs should go into a subdirectory.
> > > > >
> > > > > This requires a change to the top-level Makefile and shepherding this
> > > > > change upstream. Could we perhaps try to avoid this by having optimized
> > > > > defconfigs in the form of, for example:
> > >
> > > I don't think changes are required to put them in a subdir:
> > >
> > > $ mkdir arch/powerpc/configs/optimized
> > > $ cp arch/powerpc/configs/mpc5200_defconfig
> > > arch/powerpc/configs/optimized/lite5200_defconfig
> > > $ make optimized/lite5200_defconfig
> > >
> > > This works for me.
> >
> > However, I'm not sure what the naming scheme should be for subdirectories.
> >
> > board vendor?
> > host processor?
> > just one big directory for board specific defconfigs?
> >
> > Olof, Kumar, Josh; any thoughts?
> >
> > Not that it matters much; files are easy to move around later.
>
> I really like the idea. It would probably make sense to organize it in
> the same way as the platforms are done today, i.e. per processor/platform
> family. And then have shared/merged configs in the main config directory.
Yes. I was thinking the same already for 4xx. Essentially:
configs/ppc44x_defconfig
configs/ppc40x_defconfig
configs/44x/<board>_defconfig
configs/40x/<board>_defconfig
josh
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Grant Likely @ 2008-04-04 17:25 UTC (permalink / raw)
To: Josh Boyer; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <1207329303.6518.16.camel@weaponx>
On Fri, Apr 4, 2008 at 11:15 AM, Josh Boyer > > I really like the
idea. It would probably make sense to organize it in
> > the same way as the platforms are done today, i.e. per processor/platform
> > family. And then have shared/merged configs in the main config directory.
>
> Yes. I was thinking the same already for 4xx. Essentially:
>
> configs/ppc44x_defconfig
> configs/ppc40x_defconfig
> configs/44x/<board>_defconfig
> configs/40x/<board>_defconfig
Sounds logical. I'm cool with this.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] PowerPC: MPIC ack interrupts at mpic_teardown_this_cpu()
From: Segher Boessenkool @ 2008-04-04 17:38 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20080404052955.GC11799@lixom.net>
>>> We really need to ack interrupts at mpic_teardown, since
>>> not all platforms reset mpic at kernel start-up. For example,
>>> kexec'ed kernel hangs on P.A. Semi if mpic_eoi() isn't called.
>>>
>>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>>> ---
>>
>> Would be interesting to find out why it hangs tho... it shouldn't .
>
> I haven't reproduced the problem and looked at hardware state yet, but
> I
> would expect it to be because the openpic won't send another interrupt
> until the previous is EOI'd, and the IPI is never EOI'd as far as I
> can tell.
>
> The XICS code does it explicitly already. I'm surprised it doesn't
> break
> on the 970-based platforms actually...
platforms/maple/setup.c and platforms/powermac/pic.c use
MPIC_WANTS_RESET.
Is there a reason why we don't do that on every MPIC? If there is such
a reason, the default should be to reset, only pseries and chrp and cell
and now pasemi do not use it. It's the only sane way to get an MPIC
into
a sane known state starting from <whatever> state.
Segher
^ permalink raw reply
* Re: [PATCH] PowerPC: MPIC ack interrupts at mpic_teardown_this_cpu()
From: Olof Johansson @ 2008-04-04 18:03 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <9d19fecb0ef172995b7ce3a317ee3c0d@kernel.crashing.org>
On Fri, Apr 04, 2008 at 07:38:27PM +0200, Segher Boessenkool wrote:
>>>> We really need to ack interrupts at mpic_teardown, since
>>>> not all platforms reset mpic at kernel start-up. For example,
>>>> kexec'ed kernel hangs on P.A. Semi if mpic_eoi() isn't called.
>>>>
>>>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>>>> ---
>>>
>>> Would be interesting to find out why it hangs tho... it shouldn't .
>>
>> I haven't reproduced the problem and looked at hardware state yet, but
>> I
>> would expect it to be because the openpic won't send another interrupt
>> until the previous is EOI'd, and the IPI is never EOI'd as far as I
>> can tell.
>>
>> The XICS code does it explicitly already. I'm surprised it doesn't
>> break
>> on the 970-based platforms actually...
>
> platforms/maple/setup.c and platforms/powermac/pic.c use
> MPIC_WANTS_RESET.
> Is there a reason why we don't do that on every MPIC? If there is such
> a reason, the default should be to reset, only pseries and chrp and cell
> and now pasemi do not use it. It's the only sane way to get an MPIC
> into
> a sane known state starting from <whatever> state.
I used to have the reset there on pasemi but due to some other issues I
ended up taking it out.
It's not like doing a final EOI is a big deal, I really don't see why
there's hassle about this patch.
-Olof
^ permalink raw reply
* [PATCH] [POWERPC] pasemi: Minor cleanups of iommu code
From: Olof Johansson @ 2008-04-04 18:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: pasemi-linux
Clean up the pwrficient iommu code a bit. It was using u32 *-based offsets
for registers, which can be confusing when comparing to the manual.
Generated binaries from the code is unchanged from before.
---
This will be pushed to for-2.6.26 of pasemi.git, so no signed-off here.
diff --git a/arch/powerpc/platforms/pasemi/iommu.c b/arch/powerpc/platforms/pasemi/iommu.c
index 5803f11..86967bd 100644
--- a/arch/powerpc/platforms/pasemi/iommu.c
+++ b/arch/powerpc/platforms/pasemi/iommu.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2005-2007, PA Semi, Inc
+ * Copyright (C) 2005-2008, PA Semi, Inc
*
* Maintained by: Olof Johansson <olof@lixom.net>
*
@@ -27,7 +27,6 @@
#include <asm/abs_addr.h>
#include <asm/firmware.h>
-
#define IOBMAP_PAGE_SHIFT 12
#define IOBMAP_PAGE_SIZE (1 << IOBMAP_PAGE_SHIFT)
#define IOBMAP_PAGE_MASK (IOBMAP_PAGE_SIZE - 1)
@@ -35,13 +34,13 @@
#define IOB_BASE 0xe0000000
#define IOB_SIZE 0x3000
/* Configuration registers */
-#define IOBCAP_REG 0x10
-#define IOBCOM_REG 0x40
+#define IOBCAP_REG 0x40
+#define IOBCOM_REG 0x100
/* Enable IOB address translation */
#define IOBCOM_ATEN 0x00000100
/* Address decode configuration register */
-#define IOB_AD_REG 0x53
+#define IOB_AD_REG 0x14c
/* IOBCOM_AD_REG fields */
#define IOB_AD_VGPRT 0x00000e00
#define IOB_AD_VGAEN 0x00000100
@@ -56,13 +55,13 @@
#define IOB_AD_TRNG_2G 0x00000001
#define IOB_AD_TRNG_128G 0x00000003
-#define IOB_TABLEBASE_REG 0x55
+#define IOB_TABLEBASE_REG 0x154
/* Base of the 64 4-byte L1 registers */
-#define IOB_XLT_L1_REGBASE 0xac0
+#define IOB_XLT_L1_REGBASE 0x2b00
/* Register to invalidate TLB entries */
-#define IOB_AT_INVAL_TLB_REG 0xb40
+#define IOB_AT_INVAL_TLB_REG 0x2d00
/* The top two bits of the level 1 entry contains valid and type flags */
#define IOBMAP_L1E_V 0x40000000
@@ -76,7 +75,7 @@
#define IOBMAP_L2E_V 0x80000000
#define IOBMAP_L2E_V_CACHED 0xc0000000
-static u32 __iomem *iob;
+static void __iomem *iob;
static u32 iob_l1_emptyval;
static u32 iob_l2_emptyval;
static u32 *iob_l2_base;
@@ -219,7 +218,7 @@ int __init iob_init(struct device_node *dn)
for (i = 0; i < 64; i++) {
/* Each L1 covers 32MB, i.e. 8K entries = 32K of ram */
regword = IOBMAP_L1E_V | (__pa(iob_l2_base + i*0x2000) >> 12);
- out_le32(iob+IOB_XLT_L1_REGBASE+i, regword);
+ out_le32(iob+IOB_XLT_L1_REGBASE+i*4, regword);
}
/* set 2GB translation window, based at 0 */
^ permalink raw reply related
* [PATCH] PowerPC 44x: use machine_device_initcall() instead of device_initcall() for warp_nand
From: Valentine Barshak @ 2008-04-04 18:24 UTC (permalink / raw)
To: linuxppc-dev
With a multiplatform kernel, once built we always have warp_setup_nand_flash() called
and NDFC probed, no matter what machine we actually run on. This potentially can cause
problems (such as kernel crash), since NDFC is probed at a warp-predefined address.
Using machine_device_initcall() NAND devices are registered if we run on a warp only.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/platforms/44x/warp-nand.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
--- linux-2.6.orig/arch/powerpc/platforms/44x/warp-nand.c 2008-03-06 14:39:46.000000000 +0300
+++ linux-2.6.bld/arch/powerpc/platforms/44x/warp-nand.c 2008-04-04 22:03:36.000000000 +0400
@@ -11,6 +11,7 @@
#include <linux/mtd/partitions.h>
#include <linux/mtd/nand.h>
#include <linux/mtd/ndfc.h>
+#include <asm/machdep.h>
#ifdef CONFIG_MTD_NAND_NDFC
@@ -100,6 +101,6 @@ static int warp_setup_nand_flash(void)
return 0;
}
-device_initcall(warp_setup_nand_flash);
+machine_device_initcall(warp, warp_setup_nand_flash);
#endif
^ permalink raw reply
* Re: [kvm-ppc-devel] [PATCH] [v2] Add idle wait support for 44x platforms
From: Segher Boessenkool @ 2008-04-04 18:47 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <835D8B13-CF90-4013-A172-8243BF93DE52@pobox.com>
>> + msr_save = mfmsr();
>> + /* set wait state MSR */
>> + mtmsr(msr_save|MSR_WE|MSR_EE|MSR_CE);
>
> Did we decide to drop MSR_DE?
>
>> + /* return to initial state */
>> + mtmsr(msr_save);
>
> It may be my paranoia but I'm pretty sure you need the isync() after
> _both_ mtmsr()s
> Certainly can't hurt.
It hurts because it spreads the paranoia. Cargo cult.
Please add a comment that explains _why_ you need a context
synchronising
instruction here. The POWER ISA 2.05 says that the requirements for
changing the WE bit are implementation dependent, both before and after
the mtmsr, so the safe thing to do would be to use the "big hammer"
isync
both before and after each of these mtmsrs. A sync before entering wait
state might be needed as well, dunno. Either way, comment please :-)
Segher
^ permalink raw reply
* Re: [PATCH] PowerPC 44x: use machine_device_initcall() instead of device_initcall() for warp_nand
From: Grant Likely @ 2008-04-04 18:49 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20080404182437.GA18185@ru.mvista.com>
On Fri, Apr 4, 2008 at 12:24 PM, Valentine Barshak
<vbarshak@ru.mvista.com> wrote:
> With a multiplatform kernel, once built we always have warp_setup_nand_flash() called
> and NDFC probed, no matter what machine we actually run on. This potentially can cause
> problems (such as kernel crash), since NDFC is probed at a warp-predefined address.
> Using machine_device_initcall() NAND devices are registered if we run on a warp only.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> arch/powerpc/platforms/44x/warp-nand.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletion(-)
>
> --- linux-2.6.orig/arch/powerpc/platforms/44x/warp-nand.c 2008-03-06 14:39:46.000000000 +0300
> +++ linux-2.6.bld/arch/powerpc/platforms/44x/warp-nand.c 2008-04-04 22:03:36.000000000 +0400
> @@ -11,6 +11,7 @@
> #include <linux/mtd/partitions.h>
> #include <linux/mtd/nand.h>
> #include <linux/mtd/ndfc.h>
> +#include <asm/machdep.h>
>
> #ifdef CONFIG_MTD_NAND_NDFC
>
> @@ -100,6 +101,6 @@ static int warp_setup_nand_flash(void)
>
> return 0;
> }
> -device_initcall(warp_setup_nand_flash);
> +machine_device_initcall(warp, warp_setup_nand_flash);
>
> #endif
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] PowerPC: MPIC ack interrupts at mpic_teardown_this_cpu()
From: Segher Boessenkool @ 2008-04-04 18:55 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20080404180333.GB26693@lixom.net>
>> platforms/maple/setup.c and platforms/powermac/pic.c use
>> MPIC_WANTS_RESET.
>> Is there a reason why we don't do that on every MPIC? If there is
>> such
>> a reason, the default should be to reset, only pseries and chrp and
>> cell
>> and now pasemi do not use it. It's the only sane way to get an MPIC
>> into
>> a sane known state starting from <whatever> state.
>
> I used to have the reset there on pasemi but due to some other issues I
> ended up taking it out.
>
> It's not like doing a final EOI is a big deal, I really don't see why
> there's hassle about this patch.
The patch is fine, don't get me wrong. I'm just saying MPIC_WANTS_RESET
should be the default since pretty much everything wants it. The few
platforms that don't can document why; with the current code, we cannot
see if you just forgot it or not.
Segher
^ permalink raw reply
* Re: [PATCH/RFC] via-pmu: remove mdelays from suspend/resume code
From: Johannes Berg @ 2008-04-04 19:21 UTC (permalink / raw)
To: Brad Boyer; +Cc: linuxppc-dev list
In-Reply-To: <20080404172006.GA13980@cynthia.pants.nu>
[-- Attachment #1: Type: text/plain, Size: 824 bytes --]
On Fri, 2008-04-04 at 10:20 -0700, Brad Boyer wrote:
> On Thu, Apr 03, 2008 at 05:44:44PM +0200, Johannes Berg wrote:
> > I don't see a reason for either of those mdelay()s, is there any? Works
> > fine for me without them...
>
> Which hardware revisions did you test? I suspect the mdelay calls were
> added to work around timing issues in one of the older PMU chips. Some
> of them are very timing sensitive, and sleep in particular is basically
> a pile of steps that got hacked until they worked on older systems.
Mine's a 5,6 powerbook with PMU firmware 0x0c. The mdelay(100) seems
fairly large though for a point where we're out of pmu code already, and
the other one doesn't really seem too pmu related anyway. In any case,
just wanted to float that, don't see a particular need for it.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ 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