Re: Rapidio interface in recent kernels
--- On Thu, 6/26/08, Kumar Gala <[EMAIL PROTECTED]> wrote: > From: Kumar Gala <[EMAIL PROTECTED]> > Subject: Re: Rapidio interface in recent kernels > To: [EMAIL PROTECTED] > Cc: linuxppc-embedded@ozlabs.org > Date: Thursday, June 26, 2008, 6:35 AM > On Jun 25, 2008, at 11:33 PM, Alex Dubov wrote: > > > Greetings. > > > > I was trying to make use of rapidio on recent (2.6.25) > kernel (I > > have a 8548 > > cpu). However, it seems that changes to the powerpc > arch had broken > > it. > > > > Therefore, the question: is there an anticipated fix > or I'm on my > > own here? > > Is there a compile error? if so please post it. > > - k I'm using 2.6.25.8, but I think it's the same for all 2.6.25 kernels. I set: ARCH=powerpc, CROSS_COMPILE=powerpc-linux-gnuspe- The cpu is Freescale 8548, so "Processor Type" is Freescale 85xx First, there's no Kconfig entry for rapidio, as it seems stuck in the ppc subtree, with bad guarding condition (around line 1097 in arch/ppc/Kconfig), so I just copied it into arch/powerpc/Kconfig (without the conditional for now). And now for the build errors: Stage 1: arch/powerpc/kernel/rio.c:17:21: error: asm/rio.h: No such file or directory Stage 2 (after fixing stage 1): arch/powerpc/sysdev/fsl_rio.c: In function ârio_open_outb_mboxâ: arch/powerpc/sysdev/fsl_rio.c:455: error: âMPC85xx_IRQ_RIO_TXâ undeclared (first use in this function) arch/powerpc/sysdev/fsl_rio.c:455: error: (Each undeclared identifier is reported only once arch/powerpc/sysdev/fsl_rio.c:455: error: for each function it appears in.) arch/powerpc/sysdev/fsl_rio.c: In function ârio_close_outb_mboxâ: arch/powerpc/sysdev/fsl_rio.c:510: error: âMPC85xx_IRQ_RIO_TXâ undeclared (first use in this function) arch/powerpc/sysdev/fsl_rio.c: In function ârio_open_inb_mboxâ: arch/powerpc/sysdev/fsl_rio.c:600: error: âMPC85xx_IRQ_RIO_RXâ undeclared (first use in this function) arch/powerpc/sysdev/fsl_rio.c: In function ârio_close_inb_mboxâ: arch/powerpc/sysdev/fsl_rio.c:647: error: âMPC85xx_IRQ_RIO_RXâ undeclared (first use in this function) arch/powerpc/sysdev/fsl_rio.c: In function âmpc85xx_rio_doorbell_initâ: arch/powerpc/sysdev/fsl_rio.c:838: error: âMPC85xx_IRQ_RIO_BELLâ undeclared (first use in this function) arch/powerpc/sysdev/fsl_rio.c: In function âmpc85xx_rio_setupâ: arch/powerpc/sysdev/fsl_rio.c:916: error: âCCSRBARâ undeclared (first use in this function) And the worst thing is - those macros are defined using old style ppc register defines and I don't have a nearest idea how to fix it on a new style kernel (for one - CCSRBAR is replaced with some runtime thingie). ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
National Semi DP83865 Phy on custom hardware with PPC 8540 CPU
Greetings. I am a hardware engineer and I designed a board based on a Power PC MPC8540 CPU. The hardware was patterned after another board with a Marvel driver. I had some difficulty locating the Marvel Chips, so I used a National Semiconductor DP83865 Phy instead, available at Digikey. We looked at this and felt it would not be too difficult to adapt the current Kernel code to this phy. In practice, now that we have hardware built, it is proving to be a bit more difficult to bring up. It is very interesting that u-boot contains code for this Phy, and we are able to get to the u-boot command line, setup and Ethernet address, ping and even do a tftpboot kernel transfer. Unfortunately, in the Kernel, we do not have the same success. This seems to indicate that the hardware is working, at least to some degree. We did some modifications on the Marvel driver in order to 'attempt' to adapt it to the National Phy. To be honest, we are not that familiar with this aspect of Kernel development, so we could really use some pointers/tips/assistance. There are some file geared toward the DP83865, but they are "PCI" drivers. Our Phy is directly connected to the PPC. I do not know if it make sense to start with the natsemi.c file (which is geared toward PCI), or to make our changes to the Marvel phy. I would appreciate any help in resolving this issue. Regards, Ed Henderson ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Migrating from 2.6.11 to 2.6.23 breaks pci-e with LSI 1068 SAS chip
Kumar, We are using it onboard, not as add-on card. But I am sure there must be PCI-E to SAS PCI cards based on LSI SAS controllers. I just googled http://cgi.ebay.com/LSI-LSISAS3080X-R-8-Port-3Gb-s-SAS-PCI-X-Host-Bus-Ad apt_W0QQitemZ220243588314QQihZ012QQcategoryZ90715QQcmdZViewItem?refid=st ore - Siva -Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2008 6:37 AM To: Siva Prasad Cc: linuxppc-embedded@ozlabs.org Subject: Re: Migrating from 2.6.11 to 2.6.23 breaks pci-e with LSI 1068 SAS chip Is the LSI chipset something you guys have on an add-on card (something we can put into a reference board) or is hard wired into your boards? If its an add on card a pointer to one would be appreciated. - k On Jun 25, 2008, at 5:20 PM, Siva Prasad wrote: > I am also having problems with PCI-E device LSI 1064E on 2.6.24-rc6 > kernel. This is running on 8641D processor. > > I can see the device, access the config space, but seems access from > device to memory is not working. Same device (same exact hardware) > works > fine for 2.6.15 kernel. > > - Siva > > > -Original Message- > > Date: Wed, 25 Jun 2008 10:30:35 -0500 > From: Kumar Gala <[EMAIL PROTECTED]> > Subject: Re: Migrating from 2.6.11 to 2.6.23 breaks pci-e with LSI > 1068 SASchip > To: Vince Asbridge <[EMAIL PROTECTED]> > Cc: linuxppc-embedded@ozlabs.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; > delsp=yes > > > On Jun 24, 2008, at 10:51 AM, Vince Asbridge wrote: > >> All, >> >> I'm new to this mailing list, but have not had any luck finding >> information on this issue. >> >> Please be kind if I break the forum rules on my first post. >> >> We recently tried to upgrade our Freescale CDS 8548 look-alike >> module (code name ATCA1000) from the 2.6.11 based BSP to the 2.6.23 >> based BSP. >> >> The upgrade went fairly smoothly, until we tried using SOME pci-e >> devices (some work fine, some don't show up to lspci). >> >> LSI pci-e controllers no longer show up at all! >> >> We see the ixgbe (intel 10G), SiliconImage SATA controller but do >> not see LSI devices (Specifically 1068 SAS, FC949-E fibrechannel). >> >> We're guessing it's a resource issue behind the bridge, because the >> LSI devices try to allocate 1 - 3M behind the bridge, but we can't >> find the bug, or where we would debug such an issue. >> >> The devices seem to "train" correctly, because we have an LED on the >> pci-e switch (PLX 8 port pci-e switch), and it's ON indicating pci-e >> link between the bridge and the 1068 device). >> >> We're totally at a loss as to why this always worked on the 2.6.11 >> kernel but doesn?t work on 2.6.23. >> >> Using lspci, the LSI adapters do not show up in the list at all, as >> though they are not plugged into the system. >> >> Is there something that needs to be done with respect to PCI-E >> devices that is new in the 2.6.23 based BSP that did not need to be >> done in the 2.6.11 based kit? For example, are pci resources >> allocated by a different piece of code, that may have some issue >> allocating resources for the LSI adapters? >> >> >> > Can you tree 2.6.25? There are some fixes in that kernel related to > PCIe support: > > [POWERPC] FSL: Rework PCI/PCIe support for 85xx/86xx > > However, its odd that lspci doesn't even show the device. Are you > using u-boot? if so what version? and does u-boot see the LSI? > > - k > > > ___ > 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
GPIO on 8360 from dts par_io?
Hi, I'm on 2.6.24 and need to get some GPIOs up and running on my 8360. I think one way I can do it is to modify my dts to add to a pio to my par_io node, find it with of_find_node_by_name and install it with par_io_of_config. 1) Is this the best way to do the job? booting-without-of doesn't have much advice for me.. 2) Now that I have the GPIOs up, what can I use the get and set them from the kernel? I understand GPIO management is coming/here in later kernels but I need to stick to 2.6.24 for the time being. Thanks ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Migrating from 2.6.11 to 2.6.23 breaks pci-e with LSI 1068 SAS chip
Is the LSI chipset something you guys have on an add-on card (something we can put into a reference board) or is hard wired into your boards? If its an add on card a pointer to one would be appreciated. - k On Jun 25, 2008, at 5:20 PM, Siva Prasad wrote: I am also having problems with PCI-E device LSI 1064E on 2.6.24-rc6 kernel. This is running on 8641D processor. I can see the device, access the config space, but seems access from device to memory is not working. Same device (same exact hardware) works fine for 2.6.15 kernel. - Siva -Original Message- Date: Wed, 25 Jun 2008 10:30:35 -0500 From: Kumar Gala <[EMAIL PROTECTED]> Subject: Re: Migrating from 2.6.11 to 2.6.23 breaks pci-e with LSI 1068 SASchip To: Vince Asbridge <[EMAIL PROTECTED]> Cc: linuxppc-embedded@ozlabs.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes On Jun 24, 2008, at 10:51 AM, Vince Asbridge wrote: All, I'm new to this mailing list, but have not had any luck finding information on this issue. Please be kind if I break the forum rules on my first post. We recently tried to upgrade our Freescale CDS 8548 look-alike module (code name ATCA1000) from the 2.6.11 based BSP to the 2.6.23 based BSP. The upgrade went fairly smoothly, until we tried using SOME pci-e devices (some work fine, some don't show up to lspci). LSI pci-e controllers no longer show up at all! We see the ixgbe (intel 10G), SiliconImage SATA controller but do not see LSI devices (Specifically 1068 SAS, FC949-E fibrechannel). We're guessing it's a resource issue behind the bridge, because the LSI devices try to allocate 1 - 3M behind the bridge, but we can't find the bug, or where we would debug such an issue. The devices seem to "train" correctly, because we have an LED on the pci-e switch (PLX 8 port pci-e switch), and it's ON indicating pci-e link between the bridge and the 1068 device). We're totally at a loss as to why this always worked on the 2.6.11 kernel but doesn?t work on 2.6.23. Using lspci, the LSI adapters do not show up in the list at all, as though they are not plugged into the system. Is there something that needs to be done with respect to PCI-E devices that is new in the 2.6.23 based BSP that did not need to be done in the 2.6.11 based kit? For example, are pci resources allocated by a different piece of code, that may have some issue allocating resources for the LSI adapters? Can you tree 2.6.25? There are some fixes in that kernel related to PCIe support: [POWERPC] FSL: Rework PCI/PCIe support for 85xx/86xx However, its odd that lspci doesn't even show the device. Are you using u-boot? if so what version? and does u-boot see the LSI? - k ___ 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
Re: Rapidio interface in recent kernels
On Jun 25, 2008, at 11:33 PM, Alex Dubov wrote: Greetings. I was trying to make use of rapidio on recent (2.6.25) kernel (I have a 8548 cpu). However, it seems that changes to the powerpc arch had broken it. Therefore, the question: is there an anticipated fix or I'm on my own here? Is there a compile error? if so please post it. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Linux on Virtex board with ARCH=powerpc
Hi Peter,
I think you'll get a baseline quicker this way and then you can go on
other less known paths after that.
In my experience, this message happens when there is no compact flash in
the slot of the board.
I have the system ace device as /dev/xsa2 in my notes, but I have only
used it much. Sorry it's not one of my primary test cases at this point
in time.
Thanks,
John
-Original Message-
From: Peter Mendham [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 26, 2008 7:24 AM
To: John Linn
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Linux on Virtex board with ARCH=powerpc
Hi John,
OK, I've given in and I'm using the xilinx git code now :) It now shows
some signs of life, thanks, but the sysace driver is not happy. My root
fs is on cf and I'm not using initrd. The driver loads then gets stuck,
repeatedly saying:
xsysace 8003.sysace: kicking stalled fsm; state=2 task=0 iter=1 dc=0
I notice from the driver source that state 2 is the driver attempting to
acquire the mpu lock. I have tried the standard xilinx sysace selftest
code which just acquires and frees the lock (which is fine) so the
hardware should be OK (I hope). I have the sysace hooked up to an irq
(the only one), I have no idea whether the dts is correct but it seems
to compare favourably with the ml405 one; mine says (the important
bits):
intc: [EMAIL PROTECTED] {
#interrupt-cells = <2>;
compatible = "xlnx,xps-intc-1.00.a";
interrupt-controller ;
reg = < 8001 1 >;
xlnx,num-intr-inputs = <1>;
} ;
sysace: [EMAIL PROTECTED] {
compatible = "xlnx,xps-sysace-1.00.a";
interrupt-parent = <&intc>;
interrupts = < 0 2 >;
reg = < 8003 1 >;
xlnx,family = "virtex4";
xlnx,mem-width = <10>;
} ;
Do you have any ideas?
Thanks,
-- Peter
John Linn wrote:
> Hi Peter,
>
> To some extent I think you're trying to re-invent the wheel here, but
I
> understand why.
>
> Ideally, you would be able to pull from the mainline kernel to build
> this, but Xilinx hasn't got our code into the mainline. We are
working
> on it more proactively now.
>
> So, in the meantime, it would be easier for you to pull from the
Xilinx
> git tree as we have solved the problems you are solving I believe.
>
> Git://git.xilinx.com/linux-2.6-xlnx or http://git.xilinx.com/...
>
> We supply the device tree files and kernel configurations for the
ML405
> and ML507 boards to help get started.
>
> Thanks and sorry for the inconvenience,
> John
>
> -Original Message-
> From: Peter Mendham [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 25, 2008 10:18 AM
> To: John Linn
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Linux on Virtex board with ARCH=powerpc
>
> OK, this is all new to me, so please bear with me if I've made a major
> mistake. I ran the kernel until it didn't give me anymore output and
> then told xmd to "stop", mrd from any location gave me exactly the
same
> 32-bit word of garbage. I then reset the processor and mrd would give
> me what looked like reasonable values. I found the __log_buf symbol
in
> the System.map file (0xc024a108) and tried mrd on what I assume is the
> corresponding physical address of 0x0024a108. I get the following:
>
> <6>Using Xilinx Virtex machine description
> <5>Linux version 2.6.26-rc6 ([EMAIL PROTECTED]) (gcc version 4.2.4) #9
PREEMPT
> Wed Jun 25 16:27:33 BST 2008
> <7>Entering add_active_range(0, 0, 131072) 0 entries of 256 used
> <7>Top of RAM: 0x2000, Total RAM: 0x2000
> <7>Memory hole size: 0MB
> <4>Zone PFN ranges:
> <4> DMA 0 -> 131072
> <4> Normal 131072 -> 131072
> <4>Movable zone start PFN for each node
> <4>early_node_map[1] active PFN ranges
> <4>0:0 -> 131072
> <7>On node 0 totalpages: 131072
> <7> DMA zone: 1024 pages used for memmap
> <7> DMA zone: 0 pages reserved
> <7> DMA zone: 130048 pages, LIFO batch:31
> <7> Normal zone: 0 pages used for memmap
> <7> Movable zone: 0 pages used for memmap
> <4>Built 1 zonelists in Zone order, mobility grouping on. Total
pages:
> 130048
> <5>Kernel command line: console=ttyUL0 root=/dev/xsa2 rw
> <6>Xilinx intc at 0xFDFFF000C025CFFC mapped to 0x025d
> <4>PID hash table entries: 2048 (order: 11, 8192 bytes)
>
> xmd tells me that the processor stopped at 0xc000fe50, and subsequent
> "con" and "stop" sequences do no move this on (it reports the same
each
> time). Below is a choice excerpt of my System.map:
>
> c000fdc4 t src_error
> c000fddc t dst_error
> c000fdf4 T __div64_32
> c000fe94 T cacheable_memzero
> c000ff38 T memset
>
> So I guess that means it's in __div64_32?
>
> Any ideas?
>
> Thanks in advance,
> -- Peter
>
> John Linn wrote:
>
>> Sounds like the bootstrap loader has loaded the kernel and passed off
>> execution to it, but there's no console working on the kernel.
>>
>> You can confirm that since you h
Re: Linux on Virtex board with ARCH=powerpc
Hi John,
OK, I've given in and I'm using the xilinx git code now :) It now shows
some signs of life, thanks, but the sysace driver is not happy. My root
fs is on cf and I'm not using initrd. The driver loads then gets stuck,
repeatedly saying:
xsysace 8003.sysace: kicking stalled fsm; state=2 task=0 iter=1 dc=0
I notice from the driver source that state 2 is the driver attempting to
acquire the mpu lock. I have tried the standard xilinx sysace selftest
code which just acquires and frees the lock (which is fine) so the
hardware should be OK (I hope). I have the sysace hooked up to an irq
(the only one), I have no idea whether the dts is correct but it seems
to compare favourably with the ml405 one; mine says (the important bits):
intc: [EMAIL PROTECTED] {
#interrupt-cells = <2>;
compatible = "xlnx,xps-intc-1.00.a";
interrupt-controller ;
reg = < 8001 1 >;
xlnx,num-intr-inputs = <1>;
} ;
sysace: [EMAIL PROTECTED] {
compatible = "xlnx,xps-sysace-1.00.a";
interrupt-parent = <&intc>;
interrupts = < 0 2 >;
reg = < 8003 1 >;
xlnx,family = "virtex4";
xlnx,mem-width = <10>;
} ;
Do you have any ideas?
Thanks,
-- Peter
John Linn wrote:
Hi Peter,
To some extent I think you're trying to re-invent the wheel here, but I
understand why.
Ideally, you would be able to pull from the mainline kernel to build
this, but Xilinx hasn't got our code into the mainline. We are working
on it more proactively now.
So, in the meantime, it would be easier for you to pull from the Xilinx
git tree as we have solved the problems you are solving I believe.
Git://git.xilinx.com/linux-2.6-xlnx or http://git.xilinx.com/...
We supply the device tree files and kernel configurations for the ML405
and ML507 boards to help get started.
Thanks and sorry for the inconvenience,
John
-Original Message-
From: Peter Mendham [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 25, 2008 10:18 AM
To: John Linn
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Linux on Virtex board with ARCH=powerpc
OK, this is all new to me, so please bear with me if I've made a major
mistake. I ran the kernel until it didn't give me anymore output and
then told xmd to "stop", mrd from any location gave me exactly the same
32-bit word of garbage. I then reset the processor and mrd would give
me what looked like reasonable values. I found the __log_buf symbol in
the System.map file (0xc024a108) and tried mrd on what I assume is the
corresponding physical address of 0x0024a108. I get the following:
<6>Using Xilinx Virtex machine description
<5>Linux version 2.6.26-rc6 ([EMAIL PROTECTED]) (gcc version 4.2.4) #9 PREEMPT
Wed Jun 25 16:27:33 BST 2008
<7>Entering add_active_range(0, 0, 131072) 0 entries of 256 used
<7>Top of RAM: 0x2000, Total RAM: 0x2000
<7>Memory hole size: 0MB
<4>Zone PFN ranges:
<4> DMA 0 -> 131072
<4> Normal 131072 -> 131072
<4>Movable zone start PFN for each node
<4>early_node_map[1] active PFN ranges
<4>0:0 -> 131072
<7>On node 0 totalpages: 131072
<7> DMA zone: 1024 pages used for memmap
<7> DMA zone: 0 pages reserved
<7> DMA zone: 130048 pages, LIFO batch:31
<7> Normal zone: 0 pages used for memmap
<7> Movable zone: 0 pages used for memmap
<4>Built 1 zonelists in Zone order, mobility grouping on. Total pages:
130048
<5>Kernel command line: console=ttyUL0 root=/dev/xsa2 rw
<6>Xilinx intc at 0xFDFFF000C025CFFC mapped to 0x025d
<4>PID hash table entries: 2048 (order: 11, 8192 bytes)
xmd tells me that the processor stopped at 0xc000fe50, and subsequent
"con" and "stop" sequences do no move this on (it reports the same each
time). Below is a choice excerpt of my System.map:
c000fdc4 t src_error
c000fddc t dst_error
c000fdf4 T __div64_32
c000fe94 T cacheable_memzero
c000ff38 T memset
So I guess that means it's in __div64_32?
Any ideas?
Thanks in advance,
-- Peter
John Linn wrote:
Sounds like the bootstrap loader has loaded the kernel and passed off
execution to it, but there's no console working on the kernel.
You can confirm that since you have a probe as you can dump the
__log_buf by getting the address of it using objdump on the elf image.
It's a pain to convert to readable form, but can help to see that
things
are indeed running. Stop the processor, then do the memory read
command,
mrd, in xmd.
For the console to work with UART Lite, CONFIG_OF must be on in the
kernel configuration, I would check that.
The file, arch/powerpc/boot/virtex.c, has the startup code for the
virtex specific processing. It checks to make sure there is
compatible
hardware based on the device tree. If your device tree doesn't match
that hardware you could have a problem. I have not found the powerup
of
the kernel to be very informative if the device tree
