RE: Linux 2.6 boot failure on xup virtex II ppc405

[Stephen Neuendorffer]

Saadia,

I'm guessing that the kernel does not have the right clock information
in your device tree.  The quick fix is to fix the clock-frequency
attribute on the uart.  The kernel needs this in order to set the
register values in the uart correctly.

This information would be populated automatically, if you used a
somewhat recent version of EDK ( >= 10.1 ) and add a CLOCK_FREQUENCY
attribute on the external clock pin in the mhs file.

I'm actually somewhat surprised you see any output on the serial port at
all.

Steve

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of saadia
> Sent: Thursday, October 30, 2008 10:57 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Linux 2.6 boot failure on xup virtex II ppc405
> 
> 
> Hi,
> I have downloaded the latest linux kernel linux-2.6-xlnx.git from
> http://git.xilinx.com/ .
> Than I have downloaded the device tree generator  device-tree.git from
the
> same site.
> I launched edk 8.2.02, I designed a system with two powerpc cores:
> ppc_405_0, ppc_405_1, and opb bus , a plb bus, and the following
devices
> with their memory map:
> 
> BASE  HIGH   MODULE
> 0x0x0FFF  DDR_256MB_32MX64_rank1_row13_col10_cl2_5
> 0x40600x4060  RS232_Uart_1
> 0x40C00x40C0  Ethernet_MAC
> 0x41200x4120  opb_intc_0
> 0x41800x4180  SysACE_CompactFlash
> 
> I generated the bitsteam system.bit.
> After getting the device tree generator from
> git://git.xilinx.com/device-tree.git, I have copied the 'bsp'
directory and
> contents so that it can be used by edk XPS. Then I selected
'device-tree' in
> the pull down menu labeled 'OS' in the Software Platform Settings
dialog
> box.
> Then selected 'OS and Libraries' on the left, and entered the values
for
> 'console device' and  'bootargs' (respectively
> 'RS232_Uart_1' and 'console=ttyS0,9600 root=/dev/xsysace/disc0/part3
ip=on'
> ).
> Then I generated libraries and  BSP, in the edk_project directory and
not in
> the linux src directory.
> There were those warnings:
>

*
> **
> --- device tree generator version: v1.1 ---
> generating xilinx.dts
> Clock Port Summary:
> ppc405_0.CPMC405CLOCK connected to proc_clk_s:
> CLK_FREQ_HZ = WARNING: no frequency found!
> ppc405_0.PLBCLK connected to sys_clk_s:
> CLK_FREQ_HZ = WARNING: no frequency found!
> reset_block.Slowest_sync_clk connected to sys_clk_s:
> CLK_FREQ_HZ = WARNING: no frequency found!
> plb.PLB_Clk connected to sys_clk_s:
> CLK_FREQ_HZ = WARNING: no frequency found!
> opb.OPB_Clk connected to sys_clk_s:
> CLK_FREQ_HZ = WARNING: no frequency found!
> 
> plb2opb.PLB_Clk connected to sys_clk_s:
> CLK_FREQ_HZ = WARNING: no frequency found!
> plb2opb.OPB_Clk connected to sys_clk_s:
> CLK_FREQ_HZ = WARNING: no frequency found!
> RS232_Uart_1.OPB_Clk connected to sys_clk_s:
> CLK_FREQ_HZ = WARNING: no frequency found!
> Ethernet_MAC.OPB_Clk connected to sys_clk_s:
> CLK_FREQ_HZ = WARNING: no frequency found!
> SysACE_CompactFlash.OPB_Clk connected to sys_clk_s:
> CLK_FREQ_HZ = WARNING: no frequency found!
> DDR_256MB_32MX64_rank1_row13_col10_cl2_5.PLB_Clk connected to
sys_clk_s:
> CLK_FREQ_HZ = WARNING: no frequency found!
> plb_bram_if_cntlr_1.plb_clk connected to sys_clk_s:
> CLK_FREQ_HZ = WARNING: no frequency found!
> plb_bram_if_cntlr_1_bram.BRAM_Clk_A connected to
> plb_bram_if_cntlr_1_port_BRAM_Clk:
> CLK_FREQ_HZ = WARNING: no frequency found!
> opb_intc_0.OPB_Clk connected to sys_clk_s:
> CLK_FREQ_HZ = WARNING: no frequency found!
> dcm_0.CLKIN connected to dcm_clk_s:
> CLK_FREQ_HZ = WARNING: no frequency found!
> dcm_0.CLK0 connected to sys_clk_s:
> CLK_FREQ_HZ = WARNING: no frequency found!
> CLK_INPORT = CLKIN
> CLK_FACTOR = 1
> dcm_0.CLK90 connected to clk_90_s:
> CLK_FREQ_HZ = WARNING: no frequency found!
> CLK_INPORT = CLKIN
> CLK_FACTOR = 1
> dcm_0.CLKFX connected to proc_clk_s:
> CLK_FREQ_HZ = WARNING: no frequency found!
> CLK_INPORT = CLKIN
> CLK_FACTOR = C_CLKFX_MULTIPLY / C_CLKFX_DIVIDE
> dcm_1.CLKIN connected to ddr_feedback_s:
> CLK_FREQ_HZ = WARNING: no frequency found!
> dcm_1.CLK0 connected to dcm_1_FB:
> CLK_FREQ_HZ = WARNING: no frequency found!
> CLK_INPORT = CLKIN
> CLK_FACTOR = 1
> dcm_1.CLK90 connected to ddr_clk_90_s:
> CLK_FREQ_HZ = WARNING: no frequency found!
> CLK_INPORT = CLKIN
> CLK_FACTOR = 1
> Clock Frequency: 3
> IP connected to bus: plb
> -master DPLB plb ppc405_0
> -master IPLB plb ppc405_0
> -slave SPLB plb plb2opb
> -slave SPLB plb DDR_256MB_32MX64_rank1_row13_col10_cl2_5
> -slave SPLB plb plb_bram_if_cntlr_1
> IP connected to bus: opb
> -master MOPB opb plb2opb
> -slave SOPB opb RS232_Uart_1
> -slave SOPB opb Ethernet_MAC
> -slave SOPB opb SysACE_Com

RE: Linux driver for Xilinx ICAP

[Stephen Neuendorffer]

Ming,

That's correct, the current driver is not interrupt driven, but simply polled.  
Interrupts don't really add much except overhead, unless the core can DMA as 
well.
What architecture and core version are you running?
I believe there is a DEBUG define, which will generate some logging messages.  
It would be helpful if you can turn this on and then look at the resulting 
dmesg.

There are two things to be aware of:
1) xps-hwicap1.00.a is huge..  It's much smaller to use opb-hwicap + plb46-opb 
bridge.  I don't think an updated version has been released, however.
2) I've had problems getting the ICAP interface to properly SYNC, which may be 
the problem here  based on your response, we can debug further.

Steve

-Original Message-
From: MingLiu [mailto:[EMAIL PROTECTED]
Sent: Wed 10/8/2008 7:47 AM
To: John Linn; linuxppc-embedded@ozlabs.org
Cc: Stephen Neuendorffer
Subject: RE: Linux driver for Xilinx ICAP
 

Dear John,
Nice to hear from you. If possible, could you please show me your .mhs file 
concerning to the xps_hwicap core? Mine is listed as below:
 
BEGIN xps_hwicap PARAMETER INSTANCE = xps_hwicap_0 PARAMETER HW_VER = 1.00.a 
PARAMETER C_BASEADDR = 0x4020 PARAMETER C_HIGHADDR = 0x4020 
BUS_INTERFACE SPLB = plb PORT IP2INTC_Irpt = xps_hwicap_0_IP2INTC_IrptEND
 
The interrupt signal is connected to the interrupt controller. 
 
I suspect that the driver in Linux doesn't support interrupt mode for this 
core, since I didn't find interrupt handler registration function in the source 
code, like "request_irq", etc.. 
 
I will appreciate if you can have some comments to me. 
 
Br
Ming
 



Subject: RE: Linux driver for Xilinx ICAPDate: Wed, 8 Oct 2008 08:34:28 
-0600From: [EMAIL PROTECTED]: [EMAIL PROTECTED]; [EMAIL PROTECTED]: [EMAIL 
PROTECTED]






Hi Ming,
 
I'm copying our local expert on this core to see his thoughts as I don't 
actively use this core myself.
 
Thanks,
John
 





From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MingLiuSent: 
Wednesday, October 08, 2008 7:48 AMTo: [EMAIL PROTECTED]: Linux driver for 
Xilinx ICAP
 
Dear all,Has someone manage to use the driver for the Xilinx xps_hwicap core to 
reconfigure bitstreams? I have enabled the driver in Linux configuration 
(version 2.6.24 from Xilinx tree). However I failed to use it to reconfigure 
bitstreams. The operations are listed as follows: # cp partial.bit /dev/icap0# 
No error information is shown, however the partial bitstream is not 
successfully configured. I checked /proc/devices and the device "icap" has been 
successfully registered with the major of 259. But in /proc/interrupts, I 
didn't find any matching entry of the interrupt for icap core. I tried to 
reconfigure the PR module with JTAG, and my design works well.  Any hints for 
this problem? Is the problem on the interrupt? Thanks so much if someone can 
help me.  BRMing



Windows Live Writer,??,? !This email and any attachments 
are intended for the sole use of the named recipient(s) and contain(s) 
confidential information that may be proprietary, privileged or copyrighted 
under applicable law. If you are not the intended recipient, do not read, copy, 
or forward this email message or any attachments. Delete this email message and 
any attachments immediately. 
_
Windows Live Photo gallery ?,?,!
http://get.live.cn/product/photo.html



This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: Back port Virtex5 FPU to Virtex4?

[Stephen Neuendorffer]

Sorry, I missed your original question:

There's a very complex tradeoff with these cores, in terms of clock
speed of the processor, clock speed of the FPU, errata workarounds, etc.
Generally, In V4, DP floating point code ends up about the same speed
whether you use the DP core and accept the system limitations or just
use a well tuned DP floating point emulation library with the core
frequency as fast as possible: hence we usually recommend for most
purposes, people use the floating point emulation libraries in V4 for
double precision.   My understanding is that the IBM libraries are
significantly better than the gcc libraries in this respect...

Steve

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of Grant
Likely
> Sent: Wednesday, September 17, 2008 10:36 AM
> To: Shanyuan Gao
> Cc: linuxppc-embedded
> Subject: Re: Back port Virtex5 FPU to Virtex4?
> 
> On Tue, Aug 26, 2008 at 04:00:42PM -0400, Shanyuan Gao wrote:
> > I am working with ML410 and have FPU (single precision) working.
> > However, the FPU for V5 looks more attractive because it's double
> > precision.  So is it possible to back port the double precision FPU
to
> > V4?
> 
> As far as I understand there are limitations in the V4 APU interface
> that makes the full double precision FPU unfeasible.  The Xilinx folks
> can correct me if I'm wrong.
> 
> g.
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: PPC405EP errata CPU 213 (Incorrect data may be flushed from thedata cache)

[Stephen Neuendorffer]

arch/powerpc/boot/virtex405-head.S has:

#include "ppc_asm.h"

.text
.global _zimage_start
_zimage_start:

/* PPC errata 213: needed by Virtex-4 FX */
mfccr0  0
oris0,0,[EMAIL PROTECTED]
mtccr0  0

So, this happens first before anything else.
Without this, the boards that I've used crash pretty quickly, so it may be 
obvious that the status register is set properly.
As a result, you probably need to do it in the boot loader and not in the 
kernel proper.

Steve

-Original Message-
From: [EMAIL PROTECTED] on behalf of Darcy Watkins
Sent: Tue 8/26/2008 9:01 AM
To: linuxppc-embedded
Subject: PPC405EP errata CPU 213 (Incorrect data may be flushed from thedata 
cache)
 
Hello,

The IBM/AMCC errata document recommends setting reserved bits 1 & 3 in
CCR0 as a workaround to PPC405EP errata CPU 213 (Incorrect data may be
flushed from the data cache).  For a start, I just tried hacking in a
few lines of assembly code into...

  arch/powerpc/kernel/head_40x.S

---

Around line #839 ...

bl  early_init  /* We have to do this with MMU on */

/*
 * Decide what sort of machine this is and initialize the MMU.
 */
mr  r3,r31
mr  r4,r30
mr  r5,r29
mr  r6,r28
mr  r7,r27
bl  machine_init
bl  MMU_init
/* DLW hack!! - for PPC405EP errata CPU 213 */
mfspr   r4,SPRN_CCR0
orisr4,r4,0x5000
mtspr   SPRN_CCR0,r4
isync

/* Go back to running unmapped so we can load up new values
 * and change to using our exception vectors.
 * On the 4xx, all we have to do is invalidate the TLB to clear
 * the old 16M byte TLB mappings.
 */
lis r4,[EMAIL PROTECTED]
...

Since I am not a PowerPC assembler guru, does this appear right?

I think that eventually I'd want to create a cpu_setup_40x.S with the
fixup code as part of a setup_cpu_405ep function and then hook this into
cputable.c, but first I want to make sure that the errata workaround is
actually taking effect (and also not being undone by later startup
code).

-- 


Regards,

Darcy

--
Darcy L. Watkins - Senior Software Developer
Tranzeo Wireless Technologies, Inc.
19273 Fraser Way, Pitt Meadows, BC, Canada V3Y 2V4
T:604-460-6002 ext:410
http://www.tranzeo.com


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded




This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: [PATCH] Linux Device Driver for Xilinx LL TEMAC 10/100/1000 EthernetNIC

[Stephen Neuendorffer]

> +static struct platform_driver temac_device_driver = {
> + .probe  = temac_device_probe,
> + .remove = __devexit_p(temac_device_remove),
> + .suspend= NULL,
> + .resume = NULL,
> + .driver = {
> + .name   = DRV_NAME,
> + .owner  = THIS_MODULE,
> + },
> +};

I understand you're probably still using arch/ppc, but you'll need to
implement the of bindings as well.  This can be done relatively easily
in parallel with a platform_device binding. (and you can probably get
alot of the code out of the xilinx LLTEMAC driver.

> diff --git a/include/linux/xilinx_devices.h
b/include/linux/xilinx_devices.h
> index 41ad421..79ca491 100755
> --- a/include/linux/xilinx_devices.h
> +++ b/include/linux/xilinx_devices.h
> @@ -94,7 +94,7 @@ struct xtemac_platform_data {
>  #define XTEMAC_DMA_SGDMA 3   /* scatter gather DMA */
>  #endif
> 
> -#if defined(CONFIG_XILINX_LLTEMAC)
> +#if defined(CONFIG_XILINX_LLTEMAC) || defined(CONFIG_XPS_LLTEMAC)
>  /* LLTEMAC platform data */
>  struct xlltemac_platform_data {
>   u8 tx_csum;

You probably want to generate patches against mainline in the future...

Steve

This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: Linux on Virtex board with ARCH=powerpc

[Stephen Neuendorffer]

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of Peter
Mendham
> Sent: Tuesday, June 24, 2008 12:21 PM
> To: John Linn
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Linux on Virtex board with ARCH=powerpc
> 
> Hi John,
> 
> Thanks for your reply, that's really helpful.  I'm actually using the
> mainline kernel, rather than the one from the xilinx git tree, but
your
> information has really moved me on.  My first problem was that the
> Xilinx utility (from the git tree) for device tree dts generation
didn't
> insert a "linux,stdout-path" node under "chosen".  I spotted that the
> ml403 example had this, so after adding it I got early console
> messages.  Everything now grinds to a halt after I get the message
"flat
> tree at 0x40ad60" which is just before it calls the kernel, so I
assume
> it's that call that is killing it.  I have "console=ttyUL0" for my
> uartlite, so I should be getting messages, shouldn't I?  Do you know
> where the next execution point is?  Maybe I could find out where it's
> getting stuck.

It's time to look at __log_buf, most likely.
 
> I haven't managed to generate an ACE file, I'm just loading the kernel
> image from xmd ATM, genace won't play ball for me, it complains about
> -board user not being valid, it won't even run on the examples copied
> directly from the user manual.  Anyway, I think genace is a bit OT,
and
> I can manage with xmd for now.

This is fixed in EDK 10.1 SP2, I believe.

> 
> Thanks,
> -- Peter
> 
> John Linn wrote:
> > Hi Peter,
> >
> > I'm not up on what can be done with the simple image you refer to in
1.
> > I'm sure I should be, but there's a lot to learn.
> >
> > With regards to 2, the elf image, zImage (without the elf
extension), is
> > located in arch/powerpc/boot.
> >
> > You can make a SystemACE file from that elf image just as you did in
> > arch/ppc.  We have a default device tree file, ml405.dts, in the
> > arch/powerpc/boot/dts directory for our ml405 board. The kernel
> > configuration has a config, DEVICE_TREE, that specifies the name of
the
> > device tree file. I normally compile the device tree into the kernel
> > which is the default build, make ARCH=powerpc zImage. That image
does
> > not require a boot loader.
> >
> > I inserted the text below from a document that I have about building
the
> > arch/ppc and arch/powerpc kernels.
> >
> > Hope that helps,
> > John
> >
> >
> > Notation
> >
> > The phrase "" is used throughput the text and means
that
> > one or the other, "ppc" or "powerpc" is to be typed depending on the
> > architecture you are building.
> >
> > Commands that are used in a bash shell are preceded by ">".
> >
> > Getting Ready To Build the Kernel
> >
> > This assumes you installed the ELDK tools and assumes you'll be
using a
> > bash shell.
> >
> >
> >> bash
> >> export CROSS_COMPILE=ppc_4xx-
> >>
> >
> > Setting Up the Kernel Tree
> >
> > If you have previously built this kernel for another architecture,
ppc
> > or powerpc, then the tree needs to be setup correctly for the new
> > architecture.  Assuming you have not previously built it, this does
not
> > need to be done.
> >
> >
> >> make ARCH= mrproper
> >>
> >
> > Configuring the Kernel
> >
> > The kernel should be configured to run on the ML405 or ML507 board
from
> > Xilinx.
> >
> >
> >> make ARCH=  ml405_defconfig
> >>
> >
> > or
> >
> >
> >> make ARCH= ml507_defconfig
> >>
> >
> > Building the Kernel
> >
> > The following command will build the Linux kernel assuming you are
in
> > the root directory of the kernel.  The root directory of the kernel
from
> > the Xilinx Git tree is linux-2.6-xlnx. An elf file, zImage.elf, is
> > created in the arch/ppc/boot/images directory for ppc architecture.
An
> > elf file, zImage, is created in the the arch/powerpc/boot directory
for
> > the powerpc architecture.
> >
> >
> >> make ARCH= zImage
> >>
> >
> > Building the Kernel With Ramdisk
> >
> > A ram disk image, a file named *.gz, must be placed into the
> > arch/ppc/boot/images or arch/powerpc/boot directory, depending on
the
> > architecture, prior to building the kernel.
> >
> >
> >> make ARCH= zImage.initrd
> >>
> >
> > An elf file, zImage.initrd.elf, is created in arch/ppc/boot/images
> > directory for the ppc architecture. An elf file file, zImage.initrd,
is
> > created in arch/powerpc/boot directory for the powerpc architecture.
> >
> > Generating An Ace File
> >
> > The elf file generated for the kernel and the bit stream can be
combined
> > to create an ACE file for compact flash.  The following assumes a
bash
> > shell where XMD is accessible and a xilinx probe attached to the
board
> > for which you are generating an ace file.
> >
> >
> >> xmd -tcl genace.tcl -jprog -target ppc_hw -hw  -elf
 >>
> > file name> -board  -ace 
> >
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]
On
> > Behalf Of Peter Mendham
> > Sent: Tuesday, June 24, 2008 3:02 AM
> > To: li

RE: linux 2.6 hangs at __delay function on Viretx 4 board

[Stephen Neuendorffer]

In 10.1, it is actually free...

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of Howard,
Marc
> Sent: Wednesday, June 04, 2008 2:45 PM
> To: John Linn; Peter Korsgaard; swamydp
> Cc: linuxppc-embedded@ozlabs.org
> Subject: RE: linux 2.6 hangs at __delay function on Viretx 4 board
> 
> Every year at the Embedded Systems Conference I would complain to the
> Xilinix folks about the 16550 not being free.  This year I complained
&
> they told me that even though it is listed as a purchased core when
you
> go to "buy" it you get it for free.  This was just prior to the 10.x
> release.
> 
> Marc W Howard
> 
> > -Original Message-
> > From:
> > [EMAIL PROTECTED]
> g [mailto:linuxppc-embedded-bounces+marc.howard=kla->
> [EMAIL PROTECTED] On Behalf Of John Linn
> > Sent: Wednesday, June 04, 2008 2:23 PM
> > To: Peter Korsgaard; swamydp
> > Cc: linuxppc-embedded@ozlabs.org
> > Subject: RE: linux 2.6 hangs at __delay function on Viretx 4 board
> >
> > Hi Peter,
> >
> > Yes you need to enable UARTLITE as the console in the kernel
> > configuration.
> >
> > You have the command line syntax, ttyUL0, correct.
> >
> > They have now changed the UART 16550 to be a free core in the EDK,
not
> > sure which version of the EDK that happened.
> >
> > Thanks,
> > John
> >
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]
On
> > Behalf Of Peter Korsgaard
> > Sent: Wednesday, June 04, 2008 2:56 AM
> > To: swamydp
> > Cc: linuxppc-embedded@ozlabs.org
> > Subject: Re: linux 2.6 hangs at __delay function on Viretx 4 board
> >
> > > "swamydp" == swamydp  <[EMAIL PROTECTED]> writes:
> >
> >  swamydp> Hi John
> >
> >  swamydp> I am using UARTLITE as serial console. I do not have
license
> >  swamydp> for UART 16550.  I have enabled the drivers for uartlite
in
> >  swamydp> menuconfig while configuring the kernel. I have tested all
> >  swamydp> combinations for the kernel command line - tty0, ttyUL0,
> >  swamydp> ttyl0, ttyS0 but could not get uartlite to output kernel
> >  swamydp> printk messages.
> >
> > Correct syntax is console=ttyUL0
> >
> >  swamydp> Since I am using uartlite , the following settings are
> >  swamydp> turned off in menuconfig
> >
> >  swamydp> CONFIG_SERIAL_8250=n
> >  swamydp> CONFIG_SERIAL_8250_CONSOLE=n
> >
> > Do you have console on uartlite (CONFIG_SERIAL_UARTLITE_CONSOLE)
> > enabled?
> >
> > --
> > Bye, Peter Korsgaard
> > ___
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> >
> > This email and any attachments are intended for the sole use
> > of the named recipient(s) and contain(s) confidential
> > information that may be proprietary, privileged or
> > copyrighted under applicable law. If you are not the intended
> > recipient, do not read, copy, or forward this email message
> > or any attachments. Delete this email message and any
> > attachments immediately.
> >
> >
> > ___
> > 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


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: arch/powerpc, Xilinx, and mainline kernel support

[Stephen Neuendorffer]

We should run the fdt tests every night and generate a list of IP used
in tests.

> -Original Message-
> From: Koss, Mike (Mission Systems) [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 23, 2008 10:13 AM
> To: John Linn; Stephen Neuendorffer; Grant Likely
> Cc: linuxppc-embedded@ozlabs.org
> Subject: RE: arch/powerpc, Xilinx, and mainline kernel support
> 
> Yeah, I wasn't saying "hey! We need to support old/deprecated cores!".
> Rather I was stating that it would be nice to know which cores are
> supported currently: SystemACE, MPMC3/4, XPS_LL_TEMAC, SDMA, etc. Just
> so this sort of thing doesn't happen again to the next person who
tries
> it. If I get time this weekend, I may try and extract that information
> from the tcl and post a patch for the README.
> 
> -Original Message-
> From: John Linn [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 23, 2008 12:52 PM
> To: Koss, Mike (Mission Systems); Stephen Neuendorffer; Grant Likely
> Cc: linuxppc-embedded@ozlabs.org
> Subject: RE: arch/powerpc, Xilinx, and mainline kernel support
> 
> Hi Mike,
> 
> Thanks for the input, sounds right to me, we'll put it on the list of
> things to do.
> 
> In general we will be testing our work on the current version of the
> Xilinx tools and not maintaining them for all versions of the Xilinx
> tools, but we need a way to spell that out cleanly.
> 
> Thanks,
> John
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Koss, Mike (Mission Systems)
> Sent: Friday, May 23, 2008 9:09 AM
> To: Stephen Neuendorffer; Grant Likely
> Cc: linuxppc-embedded@ozlabs.org
> Subject: RE: arch/powerpc, Xilinx, and mainline kernel support
> 
> So yesterday, we got a chance to checkout Linus' main (2.26.26-rc3)
and
> it appears to not have all the necessary updates to build for the
> Generic Xilinx Virtex either.
> 
> For now, I've decided to work from the Xilinx git-tree.
> 
> We also gave the EDK bsp->dts generator a spin, and I have a comment
on
> it: documentation. It would be nice to have some kind of simple README
> that explains what it is and what it supports. The current README
talks
> about using the old python script. I fired up the bsp against my EDK
9.1
> MPMC(2) based system and it bombed out when it reached the MPMC2
> definition. So I dug through the tcl and found it that it was only
> supporting the MPMC3.
> 
> I'm still working on my EDK 9.2 MPMC3 system, so I can't check to see
if
> that works or not, yet.
> 
> -- Mike
> 
> -Original Message-
> From: Stephen Neuendorffer [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 16, 2008 6:34 PM
> To: Grant Likely; Koss, Mike (Mission Systems)
> Cc: linuxppc-embedded@ozlabs.org
> Subject: RE: arch/powerpc, Xilinx, and mainline kernel support
> 
> 
> 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> [mailto:linuxppc-embedded-
> > [EMAIL PROTECTED] On Behalf Of Grant
> Likely
> > Sent: Friday, May 16, 2008 3:27 PM
> > To: Koss, Mike (Mission Systems)
> > Cc: linuxppc-embedded@ozlabs.org
> > Subject: Re: arch/powerpc, Xilinx, and mainline kernel support
> >
> > On Fri, May 16, 2008 at 4:06 PM, Koss, Mike (Mission Systems)
> > <[EMAIL PROTECTED]> wrote:
> > > Is there any reason why the mainline 2.6.25.3 (and from what I
could
> see .4)
> > > is missing the files to build for the Xilinx Virtex platform?
> > >
> > > Or in other words, I tried to build from 2.6.25.3 for the Xilinx
> Virtex
> > > under arch/powerpc (because arch/ppc actually crashes when once
apps
> start
> > > to run) and it failed when trying to actually create the zImage. I
> hopped
> > > over to Xilinx's git server and noticed a bunch of missing entries
> in the
> > > boot/Makefile and source code to actually support the complete
image
> build
> > > for a Xilinx Virtex PPC405.
> > >
> > > When is the Xilinx Virtex support going to be mainline official? I
> need to
> > > be able to grab a stable kernel and work from there rather than
> using the
> > > latest -rc that Xilinx is hosting on their git server.
> >
> > Working on it.  Biggest problem is getting the device drivers in
> > shape.  However, other than Ethernet support, current arch/powerpc
> > (head of Linus' tree, not 2.6.25) should work for building virtex
> > kernels.
> 
> Mike,
> 
> What is your objection to using what is in the git tree, because it is
> based on 24-rc8 and not 25, or something more fundamental?
> 
> Steve
> 
> 
> This email 

RE: arch/powerpc, Xilinx, and mainline kernel support

[Stephen Neuendorffer]

Grant, could you post explicit instructions about how to build the
simpleImage?  I tried it too and couldn't get the makefile rules to
match my dts.

Mike, Supporting mpmc2 for memory access only is pretty straightforward,
but supporting the temac/sdma connections is more problematic,
particularly since we have no plans to update the plb_temac driver for
ARCH=powerpc.

Steve

> -Original Message-
> From: Koss, Mike (Mission Systems) [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 23, 2008 8:09 AM
> To: Stephen Neuendorffer; Grant Likely
> Cc: linuxppc-embedded@ozlabs.org
> Subject: RE: arch/powerpc, Xilinx, and mainline kernel support
> 
> So yesterday, we got a chance to checkout Linus' main (2.26.26-rc3)
and
> it appears to not have all the necessary updates to build for the
> Generic Xilinx Virtex either.
> 
> For now, I've decided to work from the Xilinx git-tree.
> 
> We also gave the EDK bsp->dts generator a spin, and I have a comment
on
> it: documentation. It would be nice to have some kind of simple README
> that explains what it is and what it supports. The current README
talks
> about using the old python script. I fired up the bsp against my EDK
9.1
> MPMC(2) based system and it bombed out when it reached the MPMC2
> definition. So I dug through the tcl and found it that it was only
> supporting the MPMC3.
> 
> I'm still working on my EDK 9.2 MPMC3 system, so I can't check to see
if
> that works or not, yet.
> 
> -- Mike
> 
> -Original Message-
> From: Stephen Neuendorffer [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 16, 2008 6:34 PM
> To: Grant Likely; Koss, Mike (Mission Systems)
> Cc: linuxppc-embedded@ozlabs.org
> Subject: RE: arch/powerpc, Xilinx, and mainline kernel support
> 
> 
> 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> [mailto:linuxppc-embedded-
> > [EMAIL PROTECTED] On Behalf Of Grant
> Likely
> > Sent: Friday, May 16, 2008 3:27 PM
> > To: Koss, Mike (Mission Systems)
> > Cc: linuxppc-embedded@ozlabs.org
> > Subject: Re: arch/powerpc, Xilinx, and mainline kernel support
> >
> > On Fri, May 16, 2008 at 4:06 PM, Koss, Mike (Mission Systems)
> > <[EMAIL PROTECTED]> wrote:
> > > Is there any reason why the mainline 2.6.25.3 (and from what I
could
> see .4)
> > > is missing the files to build for the Xilinx Virtex platform?
> > >
> > > Or in other words, I tried to build from 2.6.25.3 for the Xilinx
> Virtex
> > > under arch/powerpc (because arch/ppc actually crashes when once
apps
> start
> > > to run) and it failed when trying to actually create the zImage. I
> hopped
> > > over to Xilinx's git server and noticed a bunch of missing entries
> in the
> > > boot/Makefile and source code to actually support the complete
image
> build
> > > for a Xilinx Virtex PPC405.
> > >
> > > When is the Xilinx Virtex support going to be mainline official? I
> need to
> > > be able to grab a stable kernel and work from there rather than
> using the
> > > latest -rc that Xilinx is hosting on their git server.
> >
> > Working on it.  Biggest problem is getting the device drivers in
> > shape.  However, other than Ethernet support, current arch/powerpc
> > (head of Linus' tree, not 2.6.25) should work for building virtex
> > kernels.
> 
> Mike,
> 
> What is your objection to using what is in the git tree, because it is
> based on 24-rc8 and not 25, or something more fundamental?
> 
> Steve
> 
> 
> This email and any attachments are intended for the sole use of the
> named recipient(s) and contain(s) confidential information that may be
> proprietary, privileged or copyrighted under applicable law. If you
are
> not the intended recipient, do not read, copy, or forward this email
> message or any attachments. Delete this email message and any
> attachments immediately.
> 
> 


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: Instruction OCM

[Stephen Neuendorffer]

Ah yes, I forgot about that little detail with the OCM.

It would be slick if these mappings were generated based on memory nodes
in the device tree for ARCH=powerpc.

Steve

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of Temerkhanov
> Sent: Tuesday, May 20, 2008 4:11 AM
> To: mojtaba; linuxppc-embedded@ozlabs.org
> Subject: Re: Instruction OCM
> 
> On Tuesday 20 May 2008 13:19:26 mojtaba wrote:
> > Thank you for your email. But what is the solution to that? I have
seen
> > this in a thesis:
> >
> > "when using the OCM buses to connect memory, we can only use virtual
memory
> > as long as the virtual address is the same as the physical address,
which
> > is conceptually
> > the same as using a system without MMU. Therefore porting Linux to a
> > system based on an OCM memory system is not possible"
> >
> > http://ce.et.tudelft.nl/publicationfiles/1367_700_thesis.pdf
> >
> > Is that right? What do you suggest?
> >
> 
> 
> Getting OCM-based devices (and even memory) to work in Linux is
possible. All
> you need is to setup a mapping with virtual addresses equal to
physical (some
> info can be found here:
>
http://courses.ece.uiuc.edu/ece412/MP_Files/mp2/20060623-XUP-Linux-Tutor
ial-REVISION-FINAL.pdf)
> 
> Furthermore, if you really need to get the code running from OCM, I'd
suggest
> to setup such MMU mapping for OCM region very early - it can be done
in
> initial_mmu function at head_4xx.S. Look at line 936 (#if
> defined(CONFIG_SERIAL_TEXT_DEBUG) && defined(SERIAL_DEBUG_IO_BASE))
>  - that's very good point to start.
> 
> Regards, Sergey Temerkhanov
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: Instruction OCM

[Stephen Neuendorffer]

The traps are down there in low memory.  trap 700 is probably the one
that deals with MMU exceptions.  My guess is your OCM region is
overlapping with the DDR memory containing that code.

Steve

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of mojtaba
> Sent: Monday, May 19, 2008 8:17 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Instruction OCM
> 
> Dear all,
> 
> I cannot run Linux when I have an instruction OCM in my design but,
without instruction OCM
> everything is fine. I tried to do some debugging. It seems that the
Linux memory management unit has
> a problem with that.  After entering the MMU initialization phase, it
suddenly jumps to address
> 0x0700 it get stuck there. Is there anybody who have tried a
design with instruction OCM? Do I
> need to do special configuration for the Linux kernel?
> 
> Regards,
> 
> Mojtaba


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: Booting Linux from an ACE File

[Stephen Neuendorffer]

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of mojtaba
> Sent: Friday, May 16, 2008 4:58 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Booting Linux from an ACE File
> 
> Dear all,
> 
> Could you please explain what happens exactly when Linux is booting
from a
> compact flash?

The systemAce file is essentially a script of JTAG commands, some of
which target the FPGA with configuration data and some target the
PowerPC/microblaze with memory write commands.

> To my few knowledge, the Linux compressed image will be copied
somewhere in
> memory, will be uncompressed and the control will jump to the
beginning
> address of the Linux kernel.
> 
> Is there any boot loader that copies the Linux compressed image to the
> memory?

Essentially SystemAce does this for you and jumps to the Linux
bootwrapper code which begins decompressing the kernel.

> Where in memory does it put the Linux kernel? For example, if I have 2
DDRs
> in my hardware, in which of them it will be put the kernel?

The kernel is compiled at a particular address, typically targetting
whatever memory is low in the system.  I believe the default target
address is 0x4.  So whatever DDR memory lives at this address will
be targetted.

> Can I set the kernel location in memory manually?

If you change how the bootwrapper code and linker script work, yes.

> Might be an stupid question but: Is it possible for the kernel to be
half in
> BRAMS and half in DDR?

There have been some recent patches on the microblaze mailing lists that
attempt to put some of the latency-critical code (exception handlers and
the like) in BRAM.  Doing this is likely pretty architecture specific,
since you probably have a particular goal in mind.

Steve

This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: arch/powerpc, Xilinx, and mainline kernel support

[Stephen Neuendorffer]

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of Grant
Likely
> Sent: Friday, May 16, 2008 3:27 PM
> To: Koss, Mike (Mission Systems)
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: arch/powerpc, Xilinx, and mainline kernel support
> 
> On Fri, May 16, 2008 at 4:06 PM, Koss, Mike (Mission Systems)
> <[EMAIL PROTECTED]> wrote:
> > Is there any reason why the mainline 2.6.25.3 (and from what I could
see .4)
> > is missing the files to build for the Xilinx Virtex platform?
> >
> > Or in other words, I tried to build from 2.6.25.3 for the Xilinx
Virtex
> > under arch/powerpc (because arch/ppc actually crashes when once apps
start
> > to run) and it failed when trying to actually create the zImage. I
hopped
> > over to Xilinx's git server and noticed a bunch of missing entries
in the
> > boot/Makefile and source code to actually support the complete image
build
> > for a Xilinx Virtex PPC405.
> >
> > When is the Xilinx Virtex support going to be mainline official? I
need to
> > be able to grab a stable kernel and work from there rather than
using the
> > latest -rc that Xilinx is hosting on their git server.
> 
> Working on it.  Biggest problem is getting the device drivers in
> shape.  However, other than Ethernet support, current arch/powerpc
> (head of Linus' tree, not 2.6.25) should work for building virtex
> kernels.

Mike,

What is your objection to using what is in the git tree, because it is
based on 24-rc8 and not 25, or something more fundamental?

Steve


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: xilinx_hwicap driver problems

[Stephen Neuendorffer]

OK, that's progress.  The next thing I'd check is that you are *not*
using the JTAG configuration mode, as this disables the ICAP.  You can
also try turning on the DEBUG flags in the driver itself.  During open()
the driver attempts to read the IDCODE from the hwicap to get it back to
an initial state.

Steve

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of Will
Kritikos
> Sent: Wednesday, May 14, 2008 12:20 PM
> To: Stephen Neuendorffer
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: xilinx_hwicap driver problems
> 
> Steve,
> Yes, this fixed that problem.  the following is now printed when
> booting the kernel.
> 
> [5.866230] icap icap.0: Xilinx icap port driver
> [5.866401] icap icap.0: ioremap 4020 to c500 with size
1
> 
> The icap is at address 0x4020 on my system, so that seems correct.
> 
> However, when I copy partial bitstreams to the device, I get strange
> results.  Here is what I am seeing.
> 
>  # mknod /dev/icap c 259 0
> # cp opb_prr_0_lin_partial.bit /dev/icap
> cp: write error: Bad address
> # cp opb_prr_0_lin_partial.bit /dev/icap
> [   66.566107] icap icap.0: Failed to open file#
> # cp opb_prr_0_lin_partial.bit /dev/icap
> #
> 
> I know that this file exists in the current directory, and is a
> working partial bitstream.
> 
> Thanks for the help.
> Will
> 
> 
> On Wed, May 14, 2008 at 2:37 PM, Stephen Neuendorffer
> <[EMAIL PROTECTED]> wrote:
> >
> > I bet you're using ARCH ppc...
> >
> > It looks like in arch/ppc/syslib/virtex_devices.c:
> >
> > #define XPAR_HWICAP(num) { \
> >.name = "xilinx_icap", \
> >
> > Should probably be:
> >
> > #define XPAR_HWICAP(num) { \
> >.name = "icap", \
> >
> > now.
> >
> > Can you make this change locally and verify that it solves the
problem?
> >
> > Steve
> >
> >> -Original Message-
> >> From:
[EMAIL PROTECTED]
> > [mailto:linuxppc-embedded-
> >> [EMAIL PROTECTED] On Behalf Of Will
> > Kritikos
> >> Sent: Wednesday, May 14, 2008 9:03 AM
> >> To: linuxppc-embedded@ozlabs.org
> >> Subject: xilinx_hwicap driver problems
> >>
> >> I am having some trouble using the xilinx_hwicap driver in Linux.
> >> I am using version 2.6.24-rc8-xlnx of the Linux kernel from the
Xilinx
> >> GIT repository.
> >> The xilinx_hwicap driver is statically compiled in - not a loadable
> > module.
> >> I am using the opb_hwicap device on a V4FX60 FPGA, Linux running on
> > the PPC405.
> >>
> >> The driver successfully is initialized on boot - I added a printk
to
> >> the init function to verify this.   However, as far as I can tell,
the
> >> probe function is never called.  There is nothing in dmesg from the
> >> icap driver.
> >>
> >> After boot, the following files exist in /sys
> >>
> >> /sys/bus/platform/xilinx_icap.0
> >> /sys/bus/platform/drivers/icap/bind
> >> /sys/bus/platform/drivers/icap/uevent
> >> /sys/bus/platform/drivers/icap/unbind
> >> /sys/devices/platform/xilinx_icap.0
> >>
> >> I can make a device node /dev/icap, major number 259 minor number
0,
> >> and copy partial bitstreams to it, but again nothing happens, and
no
> >> output in dmesg.
> >>
> >> Any help is appreciated.  I am probably overlooking something
simple.
> >>
> >> Thanks,
> >> Will Kritikos
> >> ___
> >> Linuxppc-embedded mailing list
> >> Linuxppc-embedded@ozlabs.org
> >> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> >
> > This email and any attachments are intended for the sole use of the
named recipient(s) and
> contain(s) confidential information that may be proprietary,
privileged or copyrighted under
> applicable law. If you are not the intended recipient, do not read,
copy, or forward this email
> message or any attachments. Delete this email message and any
attachments immediately.
> >
> >
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: xilinx_hwicap driver problems

[Stephen Neuendorffer]

I bet you're using ARCH ppc...

It looks like in arch/ppc/syslib/virtex_devices.c:

#define XPAR_HWICAP(num) { \
.name = "xilinx_icap", \

Should probably be:

#define XPAR_HWICAP(num) { \
.name = "icap", \

now.

Can you make this change locally and verify that it solves the problem?

Steve

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of Will
Kritikos
> Sent: Wednesday, May 14, 2008 9:03 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: xilinx_hwicap driver problems
> 
> I am having some trouble using the xilinx_hwicap driver in Linux.
> I am using version 2.6.24-rc8-xlnx of the Linux kernel from the Xilinx
> GIT repository.
> The xilinx_hwicap driver is statically compiled in - not a loadable
module.
> I am using the opb_hwicap device on a V4FX60 FPGA, Linux running on
the PPC405.
> 
> The driver successfully is initialized on boot - I added a printk to
> the init function to verify this.   However, as far as I can tell, the
> probe function is never called.  There is nothing in dmesg from the
> icap driver.
> 
> After boot, the following files exist in /sys
> 
> /sys/bus/platform/xilinx_icap.0
> /sys/bus/platform/drivers/icap/bind
> /sys/bus/platform/drivers/icap/uevent
> /sys/bus/platform/drivers/icap/unbind
> /sys/devices/platform/xilinx_icap.0
> 
> I can make a device node /dev/icap, major number 259 minor number 0,
> and copy partial bitstreams to it, but again nothing happens, and no
> output in dmesg.
> 
> Any help is appreciated.  I am probably overlooking something simple.
> 
> Thanks,
> Will Kritikos
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: xilinx linux on a XUPV2P

[Stephen Neuendorffer]

Sounds like it's not finding the console.
If you're using the uartlite, you need to specify console=ttyUL0 on the
kernel command line.

Steve

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of Dr. Peter
Hartmann
> Sent: Thursday, May 08, 2008 6:56 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: xilinx linux on a XUPV2P
> 
> Hello everybody,
> 
> I am trying to get the latest Kernel (2.6.25-rc9) from git.xilinx.com
running on
> a XUPV2P board. I generated the hardware using JH Kelms step by step
list,
> skipping points 6-8 and replacing point 9 by a more modern version of
doing
> this. When I boot the system.ace from the CF card, the bootloader
talks to me
> over the RS232, but as soon as it tries to boot the kernel it hangs
up.
> I had 2.6.18-rc3 which I got from somebody else running this way. The
reason I
> intend to change is the UARTLITE driver, which seems to be included in
the
> latest kernel tree.
> I use Platform Studio 9.1.02i which I also used for the 2.6.18 Kernel.
> Has anybody yet got this to work out with 9.1.02i ??
> Would it be possible for somebody to give a dummy like me the steps
you took to
> get it working on your board? I'm really lost here. Thanks!
> 
> 
> Thanks in advance!

___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: Linux for ml410

[Stephen Neuendorffer]

I'm guessing you used the standard BSP generation process, which
overwrites files in the kernel.  Instead, you should generate the BSP
into a dummy directory and copy only the xparameters_*.h file over to
the kernel.  This is all that is needed in the git tree, since it
contains all of the required drivers.

Steve

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of mojtaba
> Sent: Tuesday, May 06, 2008 10:29 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Linux for ml410
> 
> Dear All,
> I am trying to compile Linux 2.6.25(which I got from git.xilinx) for
ML410
> board and I have a problem during compilation. This is the error
message:
> 
>  CC  arch/ppc/platforms/4xx/xilinx_generic_mlxxx.o
> arch/ppc/platforms/4xx/xilinx_generic_mlxxx.c: In function
> 'virtex_device_fixup':
> arch/ppc/platforms/4xx/xilinx_generic_mlxxx.c:31: error: dereferencing
> pointer to incomplete type
> make[1]: *** [arch/ppc/platforms/4xx/xilinx_generic_mlxxx.o] Error 1
> make: *** [arch/ppc/platforms/4xx] Error 2
> 
> it seems that xlltemac_platform_data structure is not recognized by
the
> compiler so it cannot dereference it. I do not know what this
structure is
> and where it has been defined. I really appreciate if you can help me.
> Best regards,
> Mojtaba
> 
> ___
> 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: Virtex4FX12LC hangs in calibrating delay loop

[Stephen Neuendorffer]

I think I've seen this happen when the boot code doesn't have the workarounds 
for the cache errata.  I'm not sure if that code ever made
it into grant's git server, but it's definitely is in the xilinx git tree at 
git.xilinx.com.

Steve

-Original Message-
From: [EMAIL PROTECTED] on behalf of wangyanlong
Sent: Tue 4/29/2008 1:53 AM
To: linuxppc-embedded@ozlabs.org
Subject: Re: Virtex4FX12LC hangs in calibrating delay loop
 

I meet the same problem as yours ,  have you fix your problem now ??? I am
keep trying 

Thomas Glanzmann wrote:
> 
> Hello,
> I used the HEAD secretlabs kernel and used ml403 defconfig. I still see
> no serial output from the _kernel_ on the serial console. But I do see
> output from the in kernel embedded boot loader "load_kernel". I typed in
> stop in xmd and got an instruction pointer which points to:
> 
> c00045a0 <__delay>:
> c00045a0:   2c 03 00 00 cmpwi   r3,0
> c00045a4:   7c 69 03 a6 mtctr   r3
> c00045a8:   4d 82 00 20 beqlr
> c00045ac:   42 00 00 00 bdnz-   c00045ac <__delay+0xc>  
> 
> c00045b0:   4e 80 00 20 blr
> 
> So I guess it is the calibrating delay loop and I am not sure. I can
> reproduce
> this. It is always in this function. Now I wonder is my board missing
> timer interrupts? What could be the reason for this. And of course one
> much more important question:
> 
> - Is the serial console initialized before or after the
>   calibrating delay loop?
> 
> Is there a way to get a backtrace out of this? If that is the case what
> do I have to do? Recompile the Kernel with frame pointers and attach
> gdb?
> 
> Thomas
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Virtex4FX12LC-hangs-in-calibrating-delay-loop-tp11235297p16955743.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

___
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: Problems of using APU/FPU under linux

[Stephen Neuendorffer]

> -Original Message-
> From: Shanyuan Gao [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 15, 2008 11:47 AM
> To: Stephen Neuendorffer; linuxppc-embedded@ozlabs.org
> Cc: John Bonesio; Yoshio Kashiwagi
> Subject: Re: Problems of using APU/FPU under linux
> 
> No, actually I am using head_4xx.S and I cannot find FPU_UNAVAILABLE
> in there. Do I need to set it?

Yes, I think this is why you are getting the unknown trap.  It appears
that 405's usually don't have FPU and so the code was never put there.

Steve


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: Problems of using APU/FPU under linux

[Stephen Neuendorffer]

Shanyuan,

Did you install the FPU_UNAVAILABLE trap in head_40x.S?


> -Original Message-
> From: Shanyuan Gao [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 15, 2008 11:34 AM
> To: Yoshio Kashiwagi; linuxppc-embedded@ozlabs.org
> Cc: Stephen Neuendorffer; John Bonesio
> Subject: Re: Problems of using APU/FPU under linux
> 
> Thank you, Yoshio!!
> 
> I just applied the change, seems it works! But it doesn't work
> correctly. I mean it won't give me traps any more, but the answer is
> not correctly. I just tried to multiply two float numbers. But it
> gives me 0.
> 
> The first time I change the reg.h was to enable apu enable, apu
> exception enable and fpu enable. It gives me answer 0.
> The second try I did was enabling apu enable and apu exception,
> because I notice that inside /arch/powerpc/kernel/fpu.S, it will
> enable FPU in load_up_fpu. So I guess I cannot enable FPU all the
> time. However, this time it gave me trap again, well, with a
> different MSR.
> 
> Now my guess is load_up_fpu is not working correctly. I am working on
> that.
> 
> 
> Shan
> 
> 
> 
> On Apr 15, 2008, at 2:20 PM, Yoshio Kashiwagi wrote:
> 
> > Hi,
> >
> > The following modification is required if you use APU in user space.
> >
> > in include/asm-powerpc/reg.h
> >
> > -#define MSR_USER   (MSR_KERNEL|MSR_PR|MSR_EE)
> > +#define MSR_USER   (MSR_KERNEL|MSR_PR|MSR_EE|MSR_VEC)
> >
> > Yoshio Kashiwagi - Nissin Systems
> >
> >> Thank you very much, Steve and John!
> >>
> >> My advisor and I discussed how Linux works with APU/FPU a few days
> >> ago.
> >  And he had the same thoughts with John. My naive guess was it would
> > automatically decode FP operations and mask the trap. Now it
> > answers my
> > second question. I will try it later.
> >>
> >> But for my first question, I searched all (almost all) the files,
> >> such
> > as head.S, entry.S, head_4xx.S, etc. And added following three lines
> > before mtmsr or MTMSRD �are used
> >>
> >> ori � � � �r10, r10, 1<<13 �/* enable fpu */
> >> oris � � �r10, r10, 1<<9 � �/* enable apu */
> >> oris � � �r10, r10, 1<<3 � �/* enable apu exception */
> >>
> >> However the MSR in trap prompts keeps the same (2d030) before and
> > after I added those lines.�
> >>
> >> [�� 31.819079] Bad trap at PC: 1458, MSR: 2d030,
> >> vector=800��� Not
> > tainted
> >> [�� 31.887027]�� Signal: 5
> >> [�� 31.887042]�� Code:�� 0
> >> [�� 31.887058]�� Addr:�� 0
> >> Trace/breakpoint trap
> >>
> >> I guess there must be some places, like some interrupts that changed
> > the MSR that I didn't know. �
> >>
> >> And for FP exceptions, it has two bits (two modes) in MSR. I think
> > they are for such exceptions like divided by zero. Do I need to set
> > them
> > also?
> >>
> >> In my previous build, I also added PPC_FPU under config 40x in arch/
> > ppc/Kconfig. It compiled arch/powerpc/kernel/fpu.S in, but didn't
> > help.
> > I will try CONFIG_PPC_FPU later.
> >>
> >>
> >> Shan
> >>
> >> On Apr 14, 2008, at 2:32 PM, John Bonesio wrote:
> >>
> >> Hi,
> >>
> >> The Linux kernel itself doesn't issue floating point instructions
> > other than to save and restore the fpu state when necessary.
> >>
> >> In Linux, the way it saves and restores the fpu state is to make use
> > of the trap. When the trap (fpu unavailable) occurs, it loads the fpu
> > state for the current task, sets up the MSR, and returns to re-try the
> > instruction.
> >>
> >> So, getting the trap is normal. If the FPU is not being set up
> > correctly, then there may be a problem with the restoring of the
> > state.
> >>
> >> When you guild the Linux kernel, you need to have CONFIG_PPC_FPU
> > enabled. Otherwise the kernel does not setup the fpu exception
> > handling.
> >>
> >> - John
> >>
> >>
> >> On Monday 14 April 2008 10:35, Stephen Neuendorffer wrote:
> >>
> >> I'm not sure exactly what's going on here.� Generally speaking,
> >> if you
> >> have the FPU instantiated in the design and enable the APU in the
> >> msr,
> >> then the processor should decode FP instructions and send them
> > directly
> >> to the APU with no trap.� I haven't done this myself, or I could
> >> probably give you some

RE: Problems of using APU/FPU under linux

[Stephen Neuendorffer]

I'm not sure exactly what's going on here.  Generally speaking, if you
have the FPU instantiated in the design and enable the APU in the msr,
then the processor should decode FP instructions and send them directly
to the APU with no trap.  I haven't done this myself, or I could
probably give you some better help...

One thing you should be aware of is that the there are gcc compiler
patches which are necessary to get the FPU working properly.  However, I
don't think the failure mode that these patches workaround would cause a
trap, so my guess is that there is still something else wrong.

Steve

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of Shanyuan
Gao
> Sent: Monday, April 14, 2008 9:18 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Problems of using APU/FPU under linux
> 
> Hi,
> 
> Recently I was trying to make APU/FPU working under Linux on Xilinx
> ML410. The standalone programs work perfectly. However under Linux,
> when I try to use a floating point operation, like *fmuls*, it will
> give me a *trap*.
> 
> By studying the user guide from Xilinx and dumping the object files,
> I know I need to change the corresponding bits (APU enable, FP
> enable, maybe APU Exception enable) in Machine State Register. I
> guess I need to enable the bits whenever before the kernel uses
> *mtmsr*. However, it doesn't work. I got the same trap with the same
> MSR, as I had no APU/FPU before. I also tried to add the FPU.S to ppc
> tree, but it doesn't work either.
> 
> The questions are
> 1. I guess there might be some place that changed MSR after all my
> changes. But I don't know where. And can I write a kernel module to
> change the MSR after booting in Linux? (well, it's hard for me though)
> 
> 2. Does it have any exception/interrupt mechanism to direct FP
> operation to APU/FPU? Or after enabling APU/FPU it will mask the
> exception/interrupt and decode FP operation by itself?
> 
> 
> Any ideas are appreciated. Thank you very much!
> 
> 
> Shan
> 
> ___
> 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: linux 2.6 and xps_ethernetlite

[Stephen Neuendorffer]

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of Matteo Vit
> Sent: Thursday, April 03, 2008 2:10 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: linux 2.6 and xps_ethernetlite
> 
> Hi,
> I'm planning to use the xps_ethernetlite with linux 2.6 kernel (xilinx
> git for example). Is there support for it ? Can I use the
> opb_ethernetlite driver ?

Yes, it works fine.

Steve


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: Virtex V5FX PPC 440 Support In Xilinx Git Tree

[Stephen Neuendorffer]

I've just pushed support for generating device trees for the ppc440 in
V5FXT up to git.xilinx.com.

The most obvious difference is that the PPC440 block contains not only
the PPC440 core, but also an interconnect block, subsuming part of the
'multi-ported' functionality of the MPMC.  In order to have a relatively
straightforward mapping between blocks in the EDK design and nodes in
the dts, I've represented this as shown below.  Note that unlike the
MPMC, the dma ports are controlled through DCR (which is part of the
point of the recent dcr patches).  I've done some preliminary testing
using some hacked together platform support code and we'll update this
based on the 405 code soon.

Steve

/ {
#address-cells = <1>;
#size-cells = <1>;
compatible = "xlnx,virtex";
dcr-parent = <&ppc440_virtex5_0>;
model = "testing";
chosen {
bootargs = "root=/dev/xsysace/disc0/part2";
} ;
cpus {
#address-cells = <1>;
#cpus = <1>;
#size-cells = <0>;
ppc440_virtex5_0: [EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <1>;
clock-frequency = <17d78400>;
compatible = "PowerPC,440", "ibm,ppc440";
d-cache-line-size = <20>;
d-cache-line-size = <20>;
d-cache-size = <8000>;
dcr-access-method = "native";
dcr-controller ;
device_type = "cpu";
i-cache-line-size = <20>;
i-cache-size = <8000>;
model = "PowerPC,440";
reg = <0>;
timebase-frequency = <17d78400>;
DMA0: [EMAIL PROTECTED] {
compatible = "xlnx,ll-dma-1.00.a";
dcr-reg = < 101 11 >;
interrupt-parent = <&opb_intc_0>;
interrupts = < 5 2 6 2 >;
} ;
DMA1: [EMAIL PROTECTED] {
compatible = "xlnx,ll-dma-1.00.a";
dcr-reg = < 101 11 >;
} ;
DMA2: [EMAIL PROTECTED] {
compatible = "xlnx,ll-dma-1.00.a";
dcr-reg = < 101 11 >;
} ;
DMA3: [EMAIL PROTECTED] {
compatible = "xlnx,ll-dma-1.00.a";
dcr-reg = < 101 11 >;
} ;
} ;
} ;
plb_v46_cfb_0: [EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <1>;
compatible = "xlnx,plb-v46-1.00.a";
ranges ;
iic_bus: [EMAIL PROTECTED] {
compatible = "xlnx,xps-iic-1.00.a";
interrupt-parent = <&opb_intc_0>;
interrupts = < 7 2 >;
reg = < d002 200 >;
xlnx,clk-freq = <5f5e100>;
xlnx,family = "virtex5";
xlnx,gpo-width = <1>;
xlnx,iic-freq = <186a0>;
xlnx,ten-bit-adr = <0>;
} ;
leds_8bit: [EMAIL PROTECTED] {
compatible = "xlnx,xps-gpio-1.00.a";
interrupt-parent = <&opb_intc_0>;
interrupts = < 1 2 >;
reg = < d0010200 200 >;
xlnx,all-inputs = <0>;
xlnx,all-inputs-2 = <0>;
xlnx,dout-default = <0>;
xlnx,dout-default-2 = <0>;
xlnx,family = "virtex5";
xlnx,gpio-width = <8>;
xlnx,interrupt-present = <1>;
xlnx,is-bidir = <1>;
xlnx,is-bidir-2 = <1>;
xlnx,is-dual = <0>;
xlnx,tri-default = ;
xlnx,tri-default-2 = ;
} ;
ll_temac_0: [EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <1>;
compatible = "xlnx,compound";
[EMAIL PROTECTED] {
compatible = "xlnx,xps-ll-temac-1.00.b";
device_type = "network";
interrupt-parent = <&opb_intc_0>;
interrupts = < 4 2 >;
llink-connected = <&DMA0>;
local-mac-address = [ 00 00 0

RE: Cannot open root device "xsysace/disco0/part3" or 00:00

[Stephen Neuendorffer]

Maybe just a typo?  I think it should be 'disc0' not 'disco0'

Steve

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of José Luis Añamuro Machicao
> Sent: Wednesday, March 26, 2008 12:39 PM
> To: Linuxppc-embedded@ozlabs.org
> Cc: [EMAIL PROTECTED]
> Subject: Cannot open root device "xsysace/disco0/part3" or 00:00
> 
> Hi
> I am installing the linux kernel 2.4.26 in the FPGA Virtex II Pro following 
> the instruction of
> http://www.cs.washington.edu/research/lis/empart/xup_ppc_linux.shtml
> 
> I compiled the linux kernel successfully, after that I build the root file 
> system using the BusyBox
> 1.1.0 infrastructure. I configured the busybox and the kernel with the cross 
> compiler, finally I
> execute the mkrootfs.sh script and obtain the all files of fyle system, these 
> files I copied to ext3
> partition of CompacFlash when I probe operatión by the hyperTerminal (38400 
> bps) appears a error that
> say:
> 
> Serial driver version 5.05c (2001-07-08) with no serial options enabled
> ttyS00 at 0xfdfff003 (irq = 30) is a 16550A
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> VFS: Cannot open root device "xsysace/disco0/part3" or 00:00
> Please append a correct "root=" boot option
> Kernel panic: VFS: Unable to mount root fs on 00:00
>  <0>Rebooting in 180 seconds.
> 
> 
> I configured the linux kernel with:
> 
> Code maturity level options --->
> 
> [*] Prompt for development and/or incomplete code/drivers
> 
> File systems --->
> 
> [*] /dev file system support (EXPERIMENTAL)
> 
>  [*] Automatically mount at boot
> 
> [*] Virtual memory file system support (former shm fs)
> 
> [*] /proc file system support
> 
> General Setup --->
> 
> [*] Networking support
> 
> [*] Sysctl support
> 
> [*] System V IPC
> 
> 
> 
> and edit the /etc/fstab
> 
> tmpfs /dev/shm tmpfs nodev,nosuid,noexec 0 0
> 
> proc /proc proc defaults 0 0
> 
> /dev/root / auto defaults,errors=remount-ro 0 0
> 
> 
> 
> -
> _____  __  José Luis Añamuro - PhD Student
> \/V  /\  |\_\ /\_\  Dept. Ingeniería Informática
> | | |  /  \  | |  \/  |   |Universidad Autónoma de Madrid
> | | | / /\\ | |   |   |   |Lab B-209   Tel. +34 615887260
> | | |/ __ \| | \  /|http://www.ii.uam.es/
> `-_-/_/\_\|_|\/|__|


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: XUPV2P board opb_emac cannot work with linux-2.6-xlnx

[Stephen Neuendorffer]

>From the data sheet:

"The OPB BUS clock frequency must be greater than or equal to 65 MHz for
100 Mbs Ethernet operation and greater than or equal to 6.5 Mhz for 10
Mbs Ethernet operation"

Steve

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of Qin Lin
> Sent: Tuesday, March 18, 2008 10:27 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: Re: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
> 
> 
> Hi,All
> 
> I found out what the problem was from.
> When i set the Bus clock frequency to 50MHz and Processor clock
Frequency
> 200MHz, opb_ethernet does not work with the driver.
> 
> And i check the driver,don't find the code base on the frequency .
Anyone
> knows the reason?
> 
> 
> 
> --
> View this message in context:
http://www.nabble.com/XUPV2P-board-opb_emac-cannot-work-with-linux-2.6-
> xlnx-tp16089631p16137363.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
> 
> ___
> 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: XUPV2P board opb_emac cannot work with linux-2.6-xlnx

[Stephen Neuendorffer]

Yes that should work...

Steve

-Original Message-
From: [EMAIL PROTECTED] on behalf of Qin Lin
Sent: Mon 3/17/2008 7:17 PM
To: linuxppc-embedded@ozlabs.org
Subject: RE: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
 

HI Steve:

when i design the system ,i chose opb_emac_1.04a ,No DMA, Use interrupt ?
Is it the correct setting for the current driver?

Thanks 



Stephen Neuendorffer wrote:
> 
> 
> It should...  (I use it regularly on the xup board)
> Did you remember to connect the interrupt line in your design?
> 
> Steve
> 
>> -Original Message-
>> From: [EMAIL PROTECTED]
> [mailto:linuxppc-embedded-
>> [EMAIL PROTECTED] On Behalf Of Qin Lin
>> Sent: Monday, March 17, 2008 12:36 AM
>> To: linuxppc-embedded@ozlabs.org
>> Subject: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
>> 
>> 
>> HI all,
>> 
>> Is anyone have the opb_emac (no DMA) work with the kernel
> linux-2.6-xlnx
>> from git.xilinx.com.
>> the message seams that it does work ,but the command ping return
> nothing!
>> 
>> Could you kindly suggest me what to do?
>> 
>> ps:
>> the kernel booting message
>> [0.258674] net_namespace: 64 bytes
>> [0.269780] NET: Registered protocol family 16
>> [0.290415] Registering device xilinx_emac:0
>> [0.381687] NET: Registered protocol family 2
>> [0.392324] IP route cache hash table entries: 2048 (order: 1, 8192
>> bytes)
>> [0.399556] TCP established hash table entries: 8192 (order: 4,
> 65536
>> bytes)
>> [0.403403] TCP bind hash table entries: 8192 (order: 3, 32768
> bytes)
>> [0.405409] TCP: Hash tables configured (established 8192 bind
> 8192)
>> [0.405489] TCP reno registered
>> [0.412758] sysctl table check failed: /kernel/l2cr .1.31 Missing
>> strategy
>> [0.413189] Call Trace:
>> [0.413244] [cf41feb0] [c0008178] show_stack+0x48/0x184
> (unreliable)
>> [0.413467] [cf41fed0] [c00303c8] set_fail+0x50/0x68
>> [0.413640] [cf41fef0] [c0030b54] sysctl_check_table+0x64c/0x698
>> [0.413724] [cf41ff20] [c0030b68] sysctl_check_table+0x660/0x698
>> [0.413802] [cf41ff50] [c001e810] register_sysctl_table+0x64/0xb4
>> [0.414141] [cf41ff70] [c01e4b1c]
> register_ppc_htab_sysctl+0x18/0x2c
>> [0.414311] [cf41ff80] [c01de1e4] kernel_init+0xc8/0x284
>> [0.414384] [cf41fff0] [c0004ab8] kernel_thread+0x44/0x60
>> 
>> [1.116395] xilinx_emac xilinx_emac.0: MAC address is now  2: 0: 0:
> 0: 0:
>> 0
>> [1.123790] XEmac: using fifo mode.
>> [1.128188] XEmac: Detected PHY at address 0, ManufID 0x0013, Rev.
>> 0x78e2.
>> [1.135715] eth0: Dropping NETIF_F_SG since no checksum feature.
>> [1.151038] eth0: Xilinx 10/100 EMAC at 0x40C0 mapped to
> 0xD002,
>> irq=2
>> [1.158713] eth0: XEmac id 1.4a, block id 128, type 1
>> [1.194661] TCP cubic registered
>> [1.198647] NET: Registered protocol family 1
>> [1.203728] NET: Registered protocol family 17
>> 
>> 
>> #ping 192.168.26.1 &
>> # ifconfig eth0
>> eth0  Link encap:Ethernet  HWaddr 02:00:00:00:00:00
>>   inet addr:192.168.26.127  Bcast:192.168.26.255
> Mask:255.255.255.0
>>   UP BROADCAST RUNNING  MTU:1500  Metric:1
>>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>>   TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
>>   collisions:0 txqueuelen:1000
>>   RX bytes:0 (0.0 B)  TX bytes:672 (672.0 B)
>>   Interrupt:2 Memory:40c0-40c0
>> 
>> Regards
>> 
>> Qin Lin
>> --
>> View this message in context:
> http://www.nabble.com/XUPV2P-board-opb_emac-cannot-work-with-linux-2.6-
>> xlnx-tp16089631p16089631.html
>> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>> 
>> ___
>> 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
> 
> 

-- 
View this message in context: 
http://www.nabble.com/XUPV2P-board-opb_emac-cannot-work-with-linux-2.6-xlnx-tp16089631p16112415.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

___
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: XUPV2P board opb_emac cannot work with linux-2.6-xlnx

[Stephen Neuendorffer]

It should...  (I use it regularly on the xup board)
Did you remember to connect the interrupt line in your design?

Steve

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of Qin Lin
> Sent: Monday, March 17, 2008 12:36 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
> 
> 
> HI all,
> 
> Is anyone have the opb_emac (no DMA) work with the kernel
linux-2.6-xlnx
> from git.xilinx.com.
> the message seams that it does work ,but the command ping return
nothing!
> 
> Could you kindly suggest me what to do?
> 
> ps:
> the kernel booting message
> [0.258674] net_namespace: 64 bytes
> [0.269780] NET: Registered protocol family 16
> [0.290415] Registering device xilinx_emac:0
> [0.381687] NET: Registered protocol family 2
> [0.392324] IP route cache hash table entries: 2048 (order: 1, 8192
> bytes)
> [0.399556] TCP established hash table entries: 8192 (order: 4,
65536
> bytes)
> [0.403403] TCP bind hash table entries: 8192 (order: 3, 32768
bytes)
> [0.405409] TCP: Hash tables configured (established 8192 bind
8192)
> [0.405489] TCP reno registered
> [0.412758] sysctl table check failed: /kernel/l2cr .1.31 Missing
> strategy
> [0.413189] Call Trace:
> [0.413244] [cf41feb0] [c0008178] show_stack+0x48/0x184
(unreliable)
> [0.413467] [cf41fed0] [c00303c8] set_fail+0x50/0x68
> [0.413640] [cf41fef0] [c0030b54] sysctl_check_table+0x64c/0x698
> [0.413724] [cf41ff20] [c0030b68] sysctl_check_table+0x660/0x698
> [0.413802] [cf41ff50] [c001e810] register_sysctl_table+0x64/0xb4
> [0.414141] [cf41ff70] [c01e4b1c]
register_ppc_htab_sysctl+0x18/0x2c
> [0.414311] [cf41ff80] [c01de1e4] kernel_init+0xc8/0x284
> [0.414384] [cf41fff0] [c0004ab8] kernel_thread+0x44/0x60
> 
> [1.116395] xilinx_emac xilinx_emac.0: MAC address is now  2: 0: 0:
0: 0:
> 0
> [1.123790] XEmac: using fifo mode.
> [1.128188] XEmac: Detected PHY at address 0, ManufID 0x0013, Rev.
> 0x78e2.
> [1.135715] eth0: Dropping NETIF_F_SG since no checksum feature.
> [1.151038] eth0: Xilinx 10/100 EMAC at 0x40C0 mapped to
0xD002,
> irq=2
> [1.158713] eth0: XEmac id 1.4a, block id 128, type 1
> [1.194661] TCP cubic registered
> [1.198647] NET: Registered protocol family 1
> [1.203728] NET: Registered protocol family 17
> 
> 
> #ping 192.168.26.1 &
> # ifconfig eth0
> eth0  Link encap:Ethernet  HWaddr 02:00:00:00:00:00
>   inet addr:192.168.26.127  Bcast:192.168.26.255
Mask:255.255.255.0
>   UP BROADCAST RUNNING  MTU:1500  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:0 (0.0 B)  TX bytes:672 (672.0 B)
>   Interrupt:2 Memory:40c0-40c0
> 
> Regards
> 
> Qin Lin
> --
> View this message in context:
http://www.nabble.com/XUPV2P-board-opb_emac-cannot-work-with-linux-2.6-
> xlnx-tp16089631p16089631.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
> 
> ___
> 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: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC

[Stephen Neuendorffer]

Sorry, but I'm not in a position to discuss product roadmaps.  The kinds
of technical questions are best handled by regular sales channels.

Steve

> -Original Message-
> From: Mohammad Sadegh Sadri [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 17, 2008 2:04 AM
> To: Stephen Neuendorffer; Koss, Mike (Mission Systems);
linuxppc-embedded@ozlabs.org
> Subject: RE: Compile time error, compiling Xilinx Linux 2.6 for XPS
LLTEMAC
> 
> Ok, thanks for guidance,
> 
> by the way it is interesting for me to hear about EDK 10.1 from u
steve,
> EDK 9.2 has been around just for a little time and you are going to
10.1?
> 
> What about future plan of xilinx about Virtex-5 FX? does this tool
consider that?
> the future plan is really important for our development team. let me
give a simple example, our dev
> team worked on the design of our system based on PLB and OPB buses for
some thing near 6 month, just
> then EDK 9.2.02 released and suddenly we forced to change all of the
designs and to define new
> activities specially focusing on MPMC. we did never consider MPMC
before, but the release of EDK 9.2
> changed every thing.
> 
> Now, that would be nice, if we can know your future plan a little,
that would help us to generate
> correct and real gant charts. and to assign human resources correctly.
this is also true for the
> project budget. We know that Virtex-5 devices are really capable of
doing better things than Virtex-
> 4, specially the PCI express option is great and very usable for us,
but we have not moved to virtex-
> 5 yet, because there is no FX series or at least we do not know your
plan about it. Our managers we
> seriously asking us if we have to move to Virtex-5 soon, we did not
have any reasonable answer for
> them because we do not have any info from u at all.
> 
> thanks
> 
> 
> 
> 
> 
>   Subject: RE: Compile time error, compiling Xilinx Linux 2.6 for
XPS LLTEMAC
>   Date: Sun, 16 Mar 2008 14:43:33 -0700
>   From: [EMAIL PROTECTED]
>   To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
linuxppc-embedded@ozlabs.org
> 
> 
> 
>   Ah, thanks mike...  you knocked the answer loose out of my
brain...
> 
>   In EDK 9.2., the ll_temac generates either SDMA or FIFO defines,
as necessary.
>   The platform data structure contains entries for both, with the
correct ones being ignored.  In
> order to get the code to compile, there are some defines in
xparameters.h which have:
> 
>   #ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR
>   #define XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR 0xdeadbeef
>   #endif
>   #ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_DMATX_INTR
>   #define XPAR_LLTEMAC_0_LLINK_CONNECTED_DMATX_INTR 0xdeadbeef
>   #endif
>   #ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_DMARX_INTR
>   #define XPAR_LLTEMAC_0_LLINK_CONNECTED_DMARX_INTR 0xdeadbeef
>   #endif
> 
>   after including xparameter_ml403.h
> 
>   I'm guessing maybe you overwrote the xparameters.h file and got
rid of these redefines?  You
> can define it to be whatever you want, since the value will be ignored
if you are using SDMA.
> 
>   In EDK 10.1, the BSP generator will always generate all the
defines (even ones which are not
> sensible in the current configuration), which avoids the above
annoyances.
> 
>   Steve
> 
>   -Original Message-
>   From:
[EMAIL PROTECTED] on behalf
of Koss, Mike
> (Mission Systems)
>   Sent: Sat 3/15/2008 9:12 PM
>   To: Mohammad Sadegh Sadri; linuxppc-embedded@ozlabs.org
>   Subject: RE: Compile time error, compiling Xilinx Linux 2.6 for
XPS LLTEMAC
> 
>   That interrupt is defined if you build a xps_ll_temac with the
>   xps_ll_fifo interface. Since you already stated that you're
using the
>   mpmc, I'm going to assume that you have it connected to a SDMA
>   controller on the mpmc. As such the driver should be looking for
that
>   definition, and not the FIFO interrupt. I don't have your
version of the
>   virtex_devices.c to have a reference as to how the platform
device is
>   being defined, so hopefully either Stephen N can chime in w/
more
>   information, or point me to the version of the virtex_devices.c
that
>   you're using and I can try to provide some more assistance.
> 
>   -- Mike
> 
>   
> 
>   From: Mohammad Sadegh Sadri [mailto:[EMAIL PROTECTED]
>   Sent: Saturday, March 15, 2008 4:31 AM
>   To: linuxppc-embedded@ozlabs.org
>   Subject: Compile time error, compiling Xilinx Linux 2.6 for XPS
LLTEMAC
> 
> 
>   All,
> 
>   that should be a small problem, and i

RE: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC

[Stephen Neuendorffer]

Ah, thanks mike...  you knocked the answer loose out of my brain...

In EDK 9.2., the ll_temac generates either SDMA or FIFO defines, as necessary.
The platform data structure contains entries for both, with the correct ones 
being ignored.  In order to get the code to compile, there are some defines in 
xparameters.h which have:

#ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR
#define XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR 0xdeadbeef
#endif
#ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_DMATX_INTR
#define XPAR_LLTEMAC_0_LLINK_CONNECTED_DMATX_INTR 0xdeadbeef
#endif
#ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_DMARX_INTR
#define XPAR_LLTEMAC_0_LLINK_CONNECTED_DMARX_INTR 0xdeadbeef
#endif

after including xparameter_ml403.h 

I'm guessing maybe you overwrote the xparameters.h file and got rid of these 
redefines?  You can define it to be whatever you want, since the value will be 
ignored if you are using SDMA.

In EDK 10.1, the BSP generator will always generate all the defines (even ones 
which are not sensible in the current configuration), which avoids the above 
annoyances.

Steve

-Original Message-
From: [EMAIL PROTECTED] on behalf of Koss, Mike (Mission Systems)
Sent: Sat 3/15/2008 9:12 PM
To: Mohammad Sadegh Sadri; linuxppc-embedded@ozlabs.org
Subject: RE: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC
 
That interrupt is defined if you build a xps_ll_temac with the
xps_ll_fifo interface. Since you already stated that you're using the
mpmc, I'm going to assume that you have it connected to a SDMA
controller on the mpmc. As such the driver should be looking for that
definition, and not the FIFO interrupt. I don't have your version of the
virtex_devices.c to have a reference as to how the platform device is
being defined, so hopefully either Stephen N can chime in w/ more
information, or point me to the version of the virtex_devices.c that
you're using and I can try to provide some more assistance.
 
-- Mike



From: Mohammad Sadegh Sadri [mailto:[EMAIL PROTECTED] 
Sent: Saturday, March 15, 2008 4:31 AM
To: linuxppc-embedded@ozlabs.org
Subject: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC


All,

that should be a small problem, and i think that its solution should be
simple,

I generate a base system using EDK 9.2.02 , the base system contains
XPS_LL_TEMAC , MPMC and other components,
I generate the software libraries and copy xparameters file into proper
kernel folder. I configure that kernel and add kernel support for
XPS_LL_TEMAC.

while doing make I encounter this error:

arch/ppc/syslib/virtex_devices.c:455: error:
'XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR' undeclared here (not in a
function)

I think that this definition should be available in xparameters_ml403.h
file but i see that there is no such definition. 
I added a dummy definition for myself there to complete kernel
compilation, don't know the correct value for it of course.

thanks





Access your files from anywhere with Windows Live SkyDrive! Sign up now
and get 5GB of space FREE!   

___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: [PATCH] Ported Xilinx GPIO driver to OpenFirmware.

[Stephen Neuendorffer]

Thanks Magnus...

Re: SPI I've been pondering some ideas along this line, but I haven't
done anything concrete. There are other cases where it makes sense to
have some information about the board-level design of the system (e.g.
ethernet PHYs.).

Steve

> -Original Message-
> From: Magnus Hjorth [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 13, 2008 1:34 AM
> To: Stephen Neuendorffer; git
> Cc: linuxppc-embedded@ozlabs.org; 'Grant Likely'
> Subject: RE: [PATCH] Ported Xilinx GPIO driver to OpenFirmware.
> 
> Hi,
> 
> Thanks for the feedback. I'll have a look into refining the patch in a
few weeks when I get some
> more time.
> 
> I have also been tinkering a little with the SPI driver, and that got
me thinking. Wouldn't it be
> great if SPI controllers and devices could be specified in the OF
device tree and registered on boot
> time? Even better if SPI worked as a true bus in EDK, with placeholder
IP-cores for each slave
> device, so such device entries could be autogenerated.
> 
> Cheers,
> Magnus
> 
> > -Original Message-
> > From: Stephen Neuendorffer [mailto:[EMAIL PROTECTED]
> > Sent: den 11 mars 2008 18:36
> > To: Magnus Hjorth; git
> > Cc: linuxppc-embedded@ozlabs.org; Grant Likely
> > Subject: RE: [PATCH] Ported Xilinx GPIO driver to OpenFirmware.
> >
> >
> > Thanks Magnus!
> >
> > Generally speaking this looks reasonable.  Some comments:
> >
> > >  struct xgpio_instance {
> > >   struct list_head link;
> > >   unsigned long base_phys;/* GPIO base address - physical
> > */
> > >   unsigned long remap_size;
> > > - u32 device_id;
> > > + u32 device_id;  /* Dev ID for platform devices, 0 for OF
> > devices */
> > > + void *of_id;/* of_dev pointer for OF devices, NULL
> > for plat devices */
> >
> > Why have separate ids?  I don't think the of_dev needs to be kept
around
> > here.  This driver seems seems awkwardly written to have a local
list of
> > all the devices, rather than simply attaching the xgpio_instance as
the
> > private data of the file.
> >
> > For instance, in drivers/char/xilinx_hwicap.c:
> >
> > static ssize_t
> > hwicap_read(struct file *file, char __user *buf, size_t count,
loff_t
> > *ppos)
> > {
> > struct hwicap_drvdata *drvdata = file->private_data;
> >
> > and the drvdata is set in open:
> >
> > static int hwicap_open(struct inode *inode, struct file *file)
> > {
> > struct hwicap_drvdata *drvdata;
> > int status;
> >
> > drvdata = container_of(inode->i_cdev, struct hwicap_drvdata,
> > cdev);
> > ...
> > file->private_data = drvdata;
> >
> > Which would work if xgpio_instance directly contains the struct
> > miscdevice.
> > I think this is a much cleaner pattern (although it took me a while
to
> > figure out the magic that makes it work... )
> >
> > > +static struct of_device_id xgpio_of_match[] = {
> > > + {.compatible = "xlnx,xps-gpio-1.00.a"},
> >
> > This should also probably contain the corresponding strings for the
> > following as well:
> >   opb_gpio_v1_00_a
> >   opb_gpio_v2_00_a
> >   opb_gpio_v3_01_a
> >   opb_gpio_v3_01_b
> > plb_gpio_v1_00_b
> >
> > This would seem to be a relatively easy driver to clean up (by
pulling
> > it all into one file and converting the other code to the kernel
style)
> > and submit to mainline, if you're interested?
> >
> > Steve


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: [PATCH] Ported Xilinx GPIO driver to OpenFirmware.

[Stephen Neuendorffer]

Thanks Magnus!

Generally speaking this looks reasonable.  Some comments:

>  struct xgpio_instance {
>   struct list_head link;
>   unsigned long base_phys;/* GPIO base address - physical
*/
>   unsigned long remap_size;
> - u32 device_id;
> + u32 device_id;  /* Dev ID for platform devices, 0 for OF
devices */
> + void *of_id;/* of_dev pointer for OF devices, NULL
for plat devices */

Why have separate ids?  I don't think the of_dev needs to be kept around
here.  This driver seems seems awkwardly written to have a local list of
all the devices, rather than simply attaching the xgpio_instance as the
private data of the file.

For instance, in drivers/char/xilinx_hwicap.c:

static ssize_t
hwicap_read(struct file *file, char __user *buf, size_t count, loff_t
*ppos)
{
struct hwicap_drvdata *drvdata = file->private_data;

and the drvdata is set in open:

static int hwicap_open(struct inode *inode, struct file *file)
{
struct hwicap_drvdata *drvdata;
int status;

drvdata = container_of(inode->i_cdev, struct hwicap_drvdata,
cdev);
...
file->private_data = drvdata;

Which would work if xgpio_instance directly contains the struct
miscdevice.
I think this is a much cleaner pattern (although it took me a while to
figure out the magic that makes it work... )

> +static struct of_device_id xgpio_of_match[] = {
> + {.compatible = "xlnx,xps-gpio-1.00.a"},

This should also probably contain the corresponding strings for the
following as well:
  opb_gpio_v1_00_a
  opb_gpio_v2_00_a
  opb_gpio_v3_01_a
  opb_gpio_v3_01_b
plb_gpio_v1_00_b

This would seem to be a relatively easy driver to clean up (by pulling
it all into one file and converting the other code to the kernel style)
and submit to mainline, if you're interested?

Steve


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: Xilinx EDK 9.2i and current Linux src tree(s)

[Stephen Neuendorffer]

You should copy the xparameters file into the Linux kernel tree.

Although the overall structure of the file is very different from EDK
7.1, and many names are different when using the xps* IP in EDK 9.2, the
names that are used by the kernel (in arch/ppc/syslib/virtex_devices.c)
should be defined correctly (as long as you use the linux-2.6 BSP).

Under no circumstances would I ever recommend editing that file by hand.
If you modify the design, you should regenerate the xparameters file and
copy it into your kernel.  Furthermoe, the file that is in the kernel is
for a standard reference design, and unless you are using this reference
design, you *must* copy the xparameters file for your design.  The
kernel from git.xilinx.com already has all the drivers, all you need is
the one file.

Steve

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of Phil
Hochstetler
> Sent: Monday, March 10, 2008 11:34 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Xilinx EDK 9.2i and current Linux src tree(s)
> 
> Thanks to responses from this group, I'm using Ubuntu and ELDK 4.1, I
have a working environment to
> build a linux kernel for a Xilinx ML403 board.  I pulled the kernel
source at
> git://git.xilinx.com/linux-2.6-xlnx.git
 xlnx.git;a=summary>  and while it will compile using "make ARCH=ppc
ml403_defconfig" and "make
> ARCH=ppc CROSS_COMPILE=ppc_4xx- bzImage", when I use the EDK 9.2i to
create a bitstream for the ML403
> board, the BSP based header files (xparam*) files are out of sync with
the kernel source.  The files
> in the linux-2.6-xlnx tree appear to have been build with EDK 7.1 and
I am using the current EDK
> release 9.2i.  The major diff seems to be that the new EDK release
moves all the periphials off the
> OPB bus and uses the XPS bus instead.  Any ideas on how best to
resolve this?  Is there a linux tree
> out there that is synced with the current EDK release?   Is it
sufficient to had edit in the hardware
> address in the existing OPB based file and ignore the differences
between OPB and XPS?   Is the
> difference in name only?  Should I just try to pick up the entire
linux tree from the EDK release and
> drop it on the linux kernel?  Has anyone else been down this path
already?  Thanks for any words of
> wisdom.
> 
> --phil


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: Xilinx git tree, LLTemac driver

[Stephen Neuendorffer]

Magnus,

The change that broke the lltemac driver was very recent, you should be able to 
check out a slightly earlier version to avoid the problem.

We've been following the migration pattern where drivers advertise platform 
devices *and* of devices.  In ARCH=ppc, only platform devices will ever get 
created and bound to the driver.  In ARCH=powerpc, only of devices will get 
created and bound.

Note that the ARCH=powerpc support is very new (and as evidenced by the bug you 
found, it hasn't been tested as much)...
If you have successes (or more failures), we'd appreciate hearing about them.

Steve

-Original Message-
From: Magnus Hjorth [mailto:[EMAIL PROTECTED]
Sent: Tue 3/4/2008 1:57 AM
To: linuxppc-embedded@ozlabs.org
Cc: git
Subject: Xilinx git tree, LLTemac driver
 
Hi,

I'm trying to compile the Linux kernel from the Xilinx git tree
(linux-2.6-xlnx) and am having some trouble with the LLTemac driver, having
to do with MAC address settings. 

There seems to be two routines getting the MAC address in different ways.
The xtenet_probe function tries to access an extern bd_t __res, the type
bd_t doesn't exist in the powerpc tree which causes the compilation to fail.
Then there is the xtenet_of_probe function which uses of_get_mac_address.

What confuses me is that both the regular and the OF driver is registered in
the xtenet_init function, I would have expected it to be either/or. 

Can I expect under the powerpc arch and supplying a .dts file, that the
xtenet_probe function will never be called? 

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

RE: Xilinx PowerPC

[Stephen Neuendorffer]

Michel,

I've had it on my todo list to get the u-boot stuff working for powerpc
too...  However, I remember a brief comment from John Williams that
you'd separated the BSP generation process more.  Details (or better
yet, code and patches) would be appreciated, here, since I'm a bit
swamped at the moment.

Steve

> -Original Message-
> From: Michal Simek [mailto:[EMAIL PROTECTED]
> Sent: Sunday, March 02, 2008 10:25 AM
> To: Stephen Neuendorffer
> Cc: David H. Lynch Jr.; Grant Likely; linuxppc-embedded
> Subject: Re: Xilinx PowerPC
> 
> Hi All,
> 
> > http://git.xilinx.com/gen-mhs-devtree.git contains two utilities for
> > generating device trees from EDK projects.  The older option is a
python
> > script, originally written by Grant.  The newer (and probably more
> > mature at this point) option is an EDK BSP generator for u-boot,
> > originally written by Michal Simek.  Preferably this gets passed
from a
> > uboot, although it's also possible to compile it into the kernel.
> > Currently, the uboot option is somewhat annoying because there's not
a
> > good surefire way for getting uboot up and running on an EDK design.
> > (Unfortunately, the EDK BSP generator is incomplete, and the uboot
> > support for virtex needs some work to get it integrated as well).
> 
> U-BOOT part will be removed from EDK generator. The new name will be
only
> fdt_v1.00.a. I have prepared separated version for FDT generation and
for U-BOOT
> generation.
> 
> Steve: You can remove U-BOOT part from generator. This part is useful
only for
> Microblaze cpu.
> 
> Regards,
> Michal Simek


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: Xilinx PowerPC

[Stephen Neuendorffer]

> -Original Message-
> From: David H. Lynch Jr. [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 22, 2008 1:51 PM
> To: Stephen Neuendorffer
> Cc: linuxppc-embedded
> Subject: Re: Xilinx PowerPC
> 
> Stephen Neuendorffer wrote:
> >
> >> -Original Message-
> >> From:
[EMAIL PROTECTED]
> >>
> > [mailto:linuxppc-embedded-
> >
> >> [EMAIL PROTECTED] On Behalf Of David H.
> >>
> > Lynch Jr.
> >
> >> Sent: Wednesday, February 20, 2008 10:59 PM
> >> To: Grant Likely; linuxppc-embedded
> >> Subject: Xilinx PowerPC
> >>
> >>
> >> So when you have Xilinx under powerpc working, do we pull it
from
> >>
> > your
> >
> >> git tree or the xilinx one ?
> >>
> >> Will there be an announcement ?
> >>
> >> How about a one paragraph getting started guide to moving a
xilinx
> >> ppc bsp to
> >> xilinx powerpc.
> >>
> >> Like  ?
> >>
> >> step 1).
> >>  Generate a dts - gen-mhs-devicetree ?
> >>  And pass it to through your boot loader to Linux ?
> >>
> >
> > http://git.xilinx.com/gen-mhs-devtree.git contains two utilities for
> > generating device trees from EDK projects.  The older option is a
python
> > script, originally written by Grant.  The newer (and probably more
> > mature at this point) option is an EDK BSP generator for u-boot,
> > originally written by Michal Simek.  Preferably this gets passed
from a
> > uboot, although it's also possible to compile it into the kernel.
> > Currently, the uboot option is somewhat annoying because there's not
a
> > good surefire way for getting uboot up and running on an EDK design.
> > (Unfortunately, the EDK BSP generator is incomplete, and the uboot
> > support for virtex needs some work to get it integrated as well).
> >
> Thanks, I found the python script. Please do not fixate on u-boot.
>  it is not an option for us. We have our own bootloader.
> it handles .elf files, fits in 16k or BRAM and just starts when
the
>  FPGA is loaded. We will have to added  device tree support to it.
> I had thought you were talking about appending the device tree to
> the bitfile.
>  That sounds like a really good option for us.
> 
> We also really don't have a great interest in the EDK BSP
generator.
> We have our own BSP's for our cards for both GHS and Linux.
> Except the rare instances - like right now while we are
> transitioning to the
> newer LL_TEMAC,  we use normal linux drivers, either from the
> existing kernel
> trees, or written inhouse.

The BSP generator is significantly different from the normal EDK Linux
BSP.  The key thing is that the device tree generated by the python
script is necessarily incomplete, since it does not have information
about default parameter values which appear in the core definitions.  I
would *highly recommend* using the uboot bsp to get a device tree.  You
can always ignore anything else that it does (or hack the code to your
hearts content to do what you want, such as incorporating it into your
own BSP).

> >> Step 2).
> >>  the code in arch/powerpc/ is the devicetree
equvalent
> >>
> > to
> >
> >>  arch/ppc/platforms/4xx/xilinx_ml410.c
> >>
> > http://git.xilinx.com/linux-2.6-xlnx.git contains a preliminary stab
at
> > the bootcode for Virtex.  I've been using this for a while with
> > ARCH=powerpc.  There isn't really much need for board specific
platform
> > code: This should (I think) be handled by the device tree.
> So I have a device tree for my card somehow. Presumably I need the
> binary form.
> My bootloader needs to pass a pointer to a copy in memory to
Linux.
> 
> How do I config the linux from your git tree ?
> Do I just config for a generic Xilinx card and the device tree
> handles the rest ?

Essentially.  There is a generic virtex configuration option.

> Next we have a hosted pseudo serial port. Devict Trees could cope
> with that.
> But We also have early serial support for both it and Uartlite,
> Also our Linux BSP and UartLite drivers will work without a PIC.
> And would even do ethernet (badly) with the earlier LL_TEMAC
without
> DMA and interrupts.
> So do I modify the device tree to choose a different uartlite
driver ?
> I had to put a fair amount of patches in to support early serial
with
> non-8250 serial ports. Do I have to patch your generic xilinx BSP
to
> deal w

RE: Xilinx PowerPC

[Stephen Neuendorffer]

> -Original Message-
> From: Alan Casey [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 22, 2008 10:58 AM
> To: Stephen Neuendorffer; Grant Likely
> Cc: linuxppc-embedded
> Subject: RE: Xilinx PowerPC
> 
> 
> >-- Original Message --
> >Subject: RE: Xilinx PowerPC
> >Date: Fri, 22 Feb 2008 10:11:19 -0800
> >From: "Stephen Neuendorffer" <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>,
> > "Grant Likely" <[EMAIL PROTECTED]>
> >Cc: linuxppc-embedded 
> >
> >
> >>
> >> Hi,
> >>
> >>   Just wondering - is it possible to use U-Boot on the Xilinx
XUPV2PRO
> >>   board or any similar tools (such as libfdt?) to copy a Linux
kernel
> >and
> >>
> >>   ramdisk filesystem from a SystemACE card to memory, uncompress
them
> >and
> >>
> >>   boot the Linux kernel etc?? If so is there any notes/docs about
how
> >to
> >> do
> >>   this or similar online anywhere?
> >>
> >>   Any info. appreciated,
> >>   Regards&Thanks,
> >>   Alan.
> >
> >In theory, yes...  All the infrastructure to do this exists, but I
don't
> >know of anyone who as actually tried it yet with ARCH=powerpc
kernels.
> >There
> >
> >Steve
> 
>  So i can try the latest official U-Boot releases with the ML300
configuration
> or is there a port or similar of U-Boot for the Xilinx XUPV2PRO
board??
> 
>   Regards&Thanks,
>   Alan.
> 
> 

That's probably your best starting point  There is a uboot
application note on the Xilinx website (XAPP 542), but it's a little
thin on porting information.

Steve


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: Xilinx PowerPC

[Stephen Neuendorffer]

> 
> Hi,
> 
>   Just wondering - is it possible to use U-Boot on the Xilinx XUPV2PRO
>   board or any similar tools (such as libfdt?) to copy a Linux kernel
and
> 
>   ramdisk filesystem from a SystemACE card to memory, uncompress them
and
> 
>   boot the Linux kernel etc?? If so is there any notes/docs about how
to
> do
>   this or similar online anywhere?
> 
>   Any info. appreciated,
>   Regards&Thanks,
>   Alan.

In theory, yes...  All the infrastructure to do this exists, but I don't
know of anyone who as actually tried it yet with ARCH=powerpc kernels.
There 

Steve


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: Xilinx PowerPC

[Stephen Neuendorffer]

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of David H.
Lynch Jr.
> Sent: Wednesday, February 20, 2008 10:59 PM
> To: Grant Likely; linuxppc-embedded
> Subject: Xilinx PowerPC
> 
> 
> So when you have Xilinx under powerpc working, do we pull it from
your
> git tree or the xilinx one ?
> 
> Will there be an announcement ?
> 
> How about a one paragraph getting started guide to moving a xilinx
> ppc bsp to
> xilinx powerpc.
> 
> Like  ?
> 
> step 1).
>  Generate a dts - gen-mhs-devicetree ?
>  And pass it to through your boot loader to Linux ?

http://git.xilinx.com/gen-mhs-devtree.git contains two utilities for
generating device trees from EDK projects.  The older option is a python
script, originally written by Grant.  The newer (and probably more
mature at this point) option is an EDK BSP generator for u-boot,
originally written by Michal Simek.  Preferably this gets passed from a
uboot, although it's also possible to compile it into the kernel.
Currently, the uboot option is somewhat annoying because there's not a
good surefire way for getting uboot up and running on an EDK design.
(Unfortunately, the EDK BSP generator is incomplete, and the uboot
support for virtex needs some work to get it integrated as well).

> Step 2).
>  the code in arch/powerpc/ is the devicetree equvalent
to
>  arch/ppc/platforms/4xx/xilinx_ml410.c
http://git.xilinx.com/linux-2.6-xlnx.git contains a preliminary stab at
the bootcode for Virtex.  I've been using this for a while with
ARCH=powerpc.  There isn't really much need for board specific platform
code: This should (I think) be handled by the device tree.  All of this
is still pretty preliminary at the moment however.  The big problem with
the boot code in the Xilinx tree is that you need to be able to allocate
memory in order to parse the device tree in order to figure out how much
memory you have.  I just haven't rewritten the code to use libfdt, which
can query the device tree without memory allocation yet.  Grant has a
slightly different scheme in his tree, but it works as well.  Generally
I've been more focused on avoiding u-boot, whereas Grant has been using
u-boot exclusively, I think.

> Step 3).
>  device drivers need to change initialization/setup from
>   to ???
All the xilinx drivers in mainline and most of the ones in the
git.xilinx.com tree export both platform device and of_device
interfaces.  You should be able to look at any of them to figure out a
good way of adding of_device support to a driver.  the ll_temac is by
far the most complex instance of this, which has to do some non-trivial
traversal of the device tree to discover the information it needs about
it's interface to memory.

So, the short answer is, you might be able to get it to work today, but
the code isn't in shape for mainline yet.

Steve


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: System Clock runaway on Xilinx platform

[Stephen Neuendorffer]

The processor is an integer factor faster than the bus, unless you're
doing something really unusual.  Are you sure that's not 300 and 150?

175/150 = 1.16, which might be the difference you're seeing?

Steve

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of khollan
> Sent: Wednesday, February 06, 2008 11:42 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: System Clock runaway on Xilinx platform
> 
> 
> Hi all,
> 
> Thanks for the help so far!
> I'm now running linux 2.6.21 on my custom virtex 4 board modeled after
the
> ml410.  The cpu clock is 300MHz and the PLB bus is 175MHz.
> 
> My question is which clock is the linux system clock that keeps track
of the
> date derived from?  I set my date with rdate -s time.mit.edu at boot
and
> then compare with the date command and rdate -p time.mit.edu and they
are
> off by 20 or so seconds even just after a few minutes, this trend
continues
> and it will be off by a day after a few hours.  I think I just don't
have
> something defined correctly but I can't figure out which.
> 
> Thanks
> 
> Kevin
> --
> View this message in context:
http://www.nabble.com/System-Clock-runaway-on-Xilinx-platform-
> tp15312437p15312437.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
> 
> ___
> 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: [Virtex 4 PPC] Which Linux?

[Stephen Neuendorffer]

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of IngoM
> Sent: Monday, February 04, 2008 5:55 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: [Virtex 4 PPC] Which Linux?
> 
> 
> Hello,
> 
> we develop a new laser-ranging-system and our hardware freaks have
choosen
> the Virtex 4 FX 12 on the "AVNET FX12 Mini-Module". The system had to
> deliver the raw data via UDP (12 Mbyte/sec) and on TCP the processed
data
> (about 6 Mbyte/sec). When you get the processed data via TCP then no
data
> send by UDP.
> 
> I'm confused by the following:
> 
> 1) Hard-TEMAC vs. Soft-TEMAC.
> Avnet provide a demo for the module which using Soft-TEMAC. If I get
it
> right this core has to be licenced. But when ther is a hard-TEMAC why
pay
> for it?

Generally speaking, if you have the hard temac, you should use it.  The
new EDK cores do this transparently. (see
http://www.xilinx.com/bvdocs/ipcenter/data_sheet/xps_ll_temac.pdf)  Note
that the emaclite license has recently been made free, although this
core doesn't support gigabit rates, which it looks like youll need.

Steve


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: [Virtex4] kernel2.6 or distribution

[Stephen Neuendorffer]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of Desroches L.
> Sent: Tuesday, February 05, 2008 7:49 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: [Virtex4] kernel2.6 or distribution
> 
> 
> Hi,
> 
> Sorry for my English, I am a French student. For my internship, I have to
> implement Linux on a Virtex4.
> 
> I know a few things about the Virtex4 because I am specialized in digital
> electronic (VHDL). I have to choose a solution for the Linux to implement.
> At this stage, I have some problems to determine the best solution probably
> because things are not clear for me whereas I have read a book about Linux
> embedded and seen a lot of websites.
> 
> I have seen several distributions (maybe my vocable is false) from
> MontaVista, LynuxWorks and others. I have seen also kernel2.6 for Virtex4
> (http://git.xilinx.com/cgi-bin/gitweb.cgi?p=linux-2.6-xlnx.git;a=summary). I
> would like to understand the difference between these two things.

The distributions contain kernel code that is heavily tested and stable, in 
addition to a toolchain, debuggers, rootfilesystem, etc.  git.xilinx.com is 
just the kernel code, without anything else.  git.xilinx.com also contains new 
code that is under development, rather than primarily stable code.

> If I have understood MontaVista for example offers a solution with a C
> library and drivers, isn't it ? So is it a better solution than kernel2.6 ?

'better' for what?
development of new code? yes, most distributions use older kernels.
building a sytem? Maybe... it depends on what features you need.
learning? Maybe... It depends on what you already know and what you want to 
learn.

> I prefer to start with the kernel given by xilinx, it is an internship so
> the aim is to learn the more I can but I have to convince my tutor that it
> is a better solution than MontaVista, BlueCat or µC/OSII. Do you have some
> arguments ?
> 
> Thanks for your help
> 
> Best Regards
> 
> ---
> 
> Desroches Ludovic
> ESIEE engineer : http://www.esiee.fr
> 
> 
> --
> View this message in context: 
> http://www.nabble.com/-Virtex4--kernel2.6-or-distribution-
> tp15291528p15291528.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
> 
> ___
> 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: Linux boot on a ppc 405

[Stephen Neuendorffer]

I've you've reset the processor, then the MMU has been reset too, in
which case your
log_buf will most likely be at 1e0cc4.  The 'trick' is that resetting
the processor
leaves the memory intact.

Steve

> -Original Message-
> From: Ricardo Ayres Severo [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 28, 2008 3:00 PM
> To: Stephen Neuendorffer
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Linux boot on a ppc 405
> 
> Steve,
> 
> I tried that, but the System.map is not the real memory address, it's
> processed by the mmu isn't it?
> 
> This is my System.map: c01e0cc4 b __log_buf
> when I try to look at the position 0xc01e0cc4 the debugger returns:
> Error: Cannot access memory at address 0xc01e0cc4
> 
> Am I doing something wrong?
> 
> Thanks,
> 
> On Jan 28, 2008 8:55 PM, Stephen Neuendorffer
> <[EMAIL PROTECTED]> wrote:
> >
> > You have to look at the System.map file, find the __log_buf symbol,
and
> > then look at the address manually.
> >
> > Steve
> >
> >
> > > -Original Message-
> > > From:
[EMAIL PROTECTED]
> > [mailto:linuxppc-embedded-
> > > [EMAIL PROTECTED] On Behalf Of Ricardo
> > Ayres Severo
> > > Sent: Monday, January 28, 2008 2:53 PM
> > > Cc: linuxppc-embedded@ozlabs.org
> > > Subject: Re: Linux boot on a ppc 405
> > >
> > > Grant,
> > >
> > > my output is the following:
> > >
> > > loaded at: 0040 004E919C
> > >
> > > board data at:  007C
> > >
> > > relocated to:  00404040 004040BC
> > >
> > > zimage at: 00404E2C 004E620A
> > >
> > > avail ram: 004EA000 8DA05119
> > >
> > >
> > > Linux/PPC load: console=ttyUL0,9600
> > >
> > > Uncompressing Linux...done.
> > >
> > > Now booting the kernel
> > >
> > >
> > >
> > > nothing shows up next.
> > > I tried to look at __log_buf but the debugger doesn't recognize
it.
> > > The debugger only knows the code of the part that boots the
kernel.
> > > I also tried setting ttyUL0 and ttyS0 for the linux console.
> > > Any ideas of how I can get the real position of __log_buf?
> > >
> > > Thanks,
> > >
> > > On Jan 27, 2008 7:15 PM, Grant Likely <[EMAIL PROTECTED]>
> > wrote:
> > > > On 1/27/08, Ricardo Severo <[EMAIL PROTECTED]> wrote:
> > > > > Hi all,
> > > > >
> > > > > I am working with a Xilinx Virtex II Pro  evaluation board,
wich
> > has two
> > > > > PowerPC 405 and I'm trying to boot a vanilla linux kernel
> > 2.6.23.14.
> > > > > Until now I've manged to make it uncompress the kernel, but it
> > doesn't boot.
> > > > > My question is how the initial execution (the one who
uncompresses
> > the
> > > > > kernel image) transfers the processor to the kernel itself.
I've
> > looked
> > > > > in the arch/ppc/boot/simple/relocate.S code and it jumps to
the
> > position
> > > > > 0x0 after uncompressing, is it right? The kernel is
uncompressed
> > at that
> > > > > position?
> > > >
> > > > Post your output log please.
> > > >
> > > > If your getting a message that the kernel is uncompressing, but
you
> > > > don't have any output beyond that then most likely your console
is
> > not
> > > > setup correctly.  If you've got a debugger, look at memory at
the
> > > > __log_buf location to see if there are any boot logs there.
> > > >
> > > > Cheers,
> > > > g.
> > > >
> > > >
> > > > --
> > > > Grant Likely, B.Sc., P.Eng.
> > > > Secret Lab Technologies Ltd.
> > > >
> > >
> > >
> > >
> > > --
> > > Ricardo Ayres Severo <[EMAIL PROTECTED]>
> >
> > > ___
> > > Linuxppc-embedded mailing list
> > > Linuxppc-embedded@ozlabs.org
> > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> >
> >
> 
> 
> 
> --
> Ricardo Ayres Severo <[EMAIL PROTECTED]>


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: Linux boot on a ppc 405

[Stephen Neuendorffer]

You have to look at the System.map file, find the __log_buf symbol, and
then look at the address manually.

Steve

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of Ricardo
Ayres Severo
> Sent: Monday, January 28, 2008 2:53 PM
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Linux boot on a ppc 405
> 
> Grant,
> 
> my output is the following:
> 
> loaded at: 0040 004E919C
> 
> board data at:  007C
> 
> relocated to:  00404040 004040BC
> 
> zimage at: 00404E2C 004E620A
> 
> avail ram: 004EA000 8DA05119
> 
> 
> Linux/PPC load: console=ttyUL0,9600
> 
> Uncompressing Linux...done.
> 
> Now booting the kernel
> 
> 
> 
> nothing shows up next.
> I tried to look at __log_buf but the debugger doesn't recognize it.
> The debugger only knows the code of the part that boots the kernel.
> I also tried setting ttyUL0 and ttyS0 for the linux console.
> Any ideas of how I can get the real position of __log_buf?
> 
> Thanks,
> 
> On Jan 27, 2008 7:15 PM, Grant Likely <[EMAIL PROTECTED]>
wrote:
> > On 1/27/08, Ricardo Severo <[EMAIL PROTECTED]> wrote:
> > > Hi all,
> > >
> > > I am working with a Xilinx Virtex II Pro  evaluation board, wich
has two
> > > PowerPC 405 and I'm trying to boot a vanilla linux kernel
2.6.23.14.
> > > Until now I've manged to make it uncompress the kernel, but it
doesn't boot.
> > > My question is how the initial execution (the one who uncompresses
the
> > > kernel image) transfers the processor to the kernel itself. I've
looked
> > > in the arch/ppc/boot/simple/relocate.S code and it jumps to the
position
> > > 0x0 after uncompressing, is it right? The kernel is uncompressed
at that
> > > position?
> >
> > Post your output log please.
> >
> > If your getting a message that the kernel is uncompressing, but you
> > don't have any output beyond that then most likely your console is
not
> > setup correctly.  If you've got a debugger, look at memory at the
> > __log_buf location to see if there are any boot logs there.
> >
> > Cheers,
> > g.
> >
> >
> > --
> > Grant Likely, B.Sc., P.Eng.
> > Secret Lab Technologies Ltd.
> >
> 
> 
> 
> --
> Ricardo Ayres Severo <[EMAIL PROTECTED]>
> ___
> 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: Xilinx XPS_LL_TEMAC vs PLB_TEMAC

[Stephen Neuendorffer]

The LL_TEMAC can be connected in two topologies.  One connects the
locallink directly to the SDMA port of the MPMC3.  The other topology
connects to a PLB46 bus using an XPS_LL_FIFO, which (most likely)
connects to the plb bus port of the mpmc.  The easiest way to decipher
the connection pattern is to use Base System Builder in EDK to generate
both topologies (which is determined by the 'use DMA' parameter when
selecting the LL_TEMAC device.  The Linux driver in git.xilinx.com
supports both topologies.

Steve

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of Mohammad
Sadegh Sadri
> Sent: Wednesday, January 23, 2008 7:13 AM
> To: Koss, Mike (Mission Systems); David Baird;
linuxppc-embedded@ozlabs.org
> Subject: RE: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
> 
> So, in this case, our base system, created with EDK 9.2 will not be
the same as previous systems, as
> shown in
> http://www.xilinx.com/esp/wired/optical/xlnx_net/mpmc.htm
> PLB and OPB usage is limited to a small area of design...
> 
> 
> 
> 
> 
>   Subject: RE: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
>   Date: Wed, 23 Jan 2008 07:43:14 -0600
>   From: [EMAIL PROTECTED]
>   To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
linuxppc-embedded@ozlabs.org
> 
> 
>   Actually, with the MPMC3 the XPS_LL_TEMAC still can directly
connect to the MPMC. You set one
> of the ports' type to SDMA and it instantiates what is similar to the
old CDMAC.
> 
> 
> 
>   From: Mohammad Sadegh Sadri [mailto:[EMAIL PROTECTED]
>   Sent: Wednesday, January 23, 2008 2:36 AM
>   To: Koss, Mike (Mission Systems); David Baird;
linuxppc-embedded@ozlabs.org
>   Subject: RE: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
> 
> 
>   Hi
> 
>   Well, As you know, we now need a PLB version, XPS_LL_TEMAC is
connected to PLB not MPMC2...yes
> I remember those days of Xilinx GSRD and MPMC2 however it seems that
the current architecture has
> slight changes.
> 
>   about the git repository of Xilinx, Although I do not believe on
it, I'll give it a
> try...thanks for info.
> 
>   well, what about Grant Likely... and his git tree?
> 
> 
> 
> 
> 
>   Subject: RE: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
>   Date: Mon, 21 Jan 2008 11:44:14 -0600
>   From: [EMAIL PROTECTED]
>   To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
linuxppc-embedded@ozlabs.org
> 
> 
>   In case anyone is interested, I'm currently working on
an almost-kernel-ready version
> that will be self-contained based on the LL-DMA version (the native
MPMC port, not the PLB). It's
> based upon the old adapter from MontaVista, that I originally ported
to 2.6 and the MPMC2.
> Unfortunately, it won't be ready for another few weeks since I'm
working on hardware images
> currently.
> 
>   -- Mike
> 
> 
> 
> 
>   From: Mohammad Sadegh Sadri
[mailto:[EMAIL PROTECTED]
>   Sent: Monday, January 21, 2008 3:54 AM
>   To: David Baird; linuxppc-embedded@ozlabs.org
>   Subject: RE: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
> 
> 
>   thanks for you reply david,
> 
>   As far as I know the Linux driver for Xilinx PLB TEMAC
was two parts : 1- adapter.c and
> 2- the rest of the driver files
> 
>   Only adapter.c was really a linux related file and the
rest of the files were Xilinx
> generic driver code for PLB TEMAC.
> 
>   correct?
> 
>   then now, I know EDK 9.2 generates the needed Linux
support package and needed related
> files, so if this is the case can we use these files as the needed
driver in our linux kernel?
> 
>   by the way, i did never hear about this git repository
before...can you describe us,
> where is it and how we can access it and which projects are now hosted
by it?
> 
> 
>   thanks
> 
> 
>   > Date: Mon, 21 Jan 2008 00:54:30 -0700
>   > From: [EMAIL PROTECTED]
>   > To: [EMAIL PROTECTED]
>   > Subject: Re: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
>   >
>   > On Jan 21, 2008 12:36 AM, Mohammad Sadegh Sadri
<[EMAIL PROTECTED]> wrote:
>   > > As you know Xilinx PLB TEMAC is a module which
connects Hard TEMAC in
>   > > Virtex-4 FX devices to PLB bus,
>   > > now, in the new release of EDK , EDK 9.2 Xilinx has
added a new interface
>   > > core , which is called XPS_LL_TEMAC and has a
different structure than
>   > > normal PLB TEMAC. spacially it has some additional
data transfer buses.
>   > >
>   > > Now the question is,... is there any linux driver
available for this new
>   > > core?
>   >
>   > Yes there is, but I had to use the git sources at:
>   >

RE: Generated xilinx linux 2.6 image sections

[Stephen Neuendorffer]

That would do it!
What's strange is that the testapps linked into the second bank by
default, which *happened* to work.

Steve

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of greenlean
> Sent: Tuesday, January 22, 2008 5:29 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: RE: Generated xilinx linux 2.6 image sections
> 
> 
> Now It's running the problem was the DDR controller I was including
the 512
> one but I'm working with a 256 DDR module ...
> 
> Thanks for the orientation, really usefull.
> 
> Bye.
> 
> 
> Stephen Neuendorffer wrote:
> >
> > The testapps are generated using a different linker script.
> >
> > Based on what you sent out, it looks like your EDK design has a
memory
> > at 0x1000, but this is
> > not reflected in the linux image you've generated.  This makes me
> > suspect that you haven't generated the BSP and copied the
appropriate
> > xparameters file over xparameters_xup.h (assuming you are using
> > CONFIG_XILINX_XUPV2P).
> >
> > Steve
> >
> >> -Original Message-
> >> From:
[EMAIL PROTECTED]
> > [mailto:linuxppc-embedded-
> >> [EMAIL PROTECTED] On Behalf Of
greenlean
> >> Sent: Monday, January 21, 2008 5:06 AM
> >> To: linuxppc-embedded@ozlabs.org
> >> Subject: Generated xilinx linux 2.6 image sections
> >>
> >>
> >> Hi all,
> >>
> >> I'm trying to boot the 2.6 xilinx kernel downloaded from their git
> > server in
> >> the XUPV2P board I'm really having troubles (I can't see anything
in
> > the
> >> minicom console terminal). I'm not seeing anything, neither the
> > ucompressing
> >> kernel string nor the prompt with the memory addresses that kernel
> > prompt at
> >> first time, so I have started to distrust of anything.
> >>
> >>
> >> 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
> >
> >
> 
> 
> 
> --
> View this message in context:
http://www.nabble.com/Generated-xilinx-linux-2.6--image-sections-
> tp14997109p15018508.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
> 
> ___
> 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: Generated xilinx linux 2.6 image sections

[Stephen Neuendorffer]

The testapps are generated using a different linker script.

Based on what you sent out, it looks like your EDK design has a memory
at 0x1000, but this is
not reflected in the linux image you've generated.  This makes me
suspect that you haven't generated the BSP and copied the appropriate
xparameters file over xparameters_xup.h (assuming you are using
CONFIG_XILINX_XUPV2P).

Steve

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of greenlean
> Sent: Monday, January 21, 2008 5:06 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Generated xilinx linux 2.6 image sections
> 
> 
> Hi all,
> 
> I'm trying to boot the 2.6 xilinx kernel downloaded from their git
server in
> the XUPV2P board I'm really having troubles (I can't see anything in
the
> minicom console terminal). I'm not seeing anything, neither the
ucompressing
> kernel string nor the prompt with the memory addresses that kernel
prompt at
> first time, so I have started to distrust of anything.
> 
> When I download the kernel using xmd, I see:
> 
> XMD% dow imagen_UART16550_ml300.elf
> section, .text: 0x0040-0x0040387b
> section, .data: 0x00404000-0x004e6fff
> section, .bss: 0x004e7000-0x004e919f
> Downloaded Program imagen_UART16550_ml300.elf
> Setting PC with Program Start Address 0x0040
> 
> and when I download some of the TestApp generated by EDK I see:
> 
> XMD% dow perif.elf
> section, .vectors: 0xfffe-0xfffe20c3
> section, .text: 0x1000-0x10003b7b
> section, .init: 0x10003b7c-0x10003b9f
> section, .fini: 0x10003ba0-0x10003bbf
> section, .boot0: 0xfffe20c4-0xfffe20d3
> section, .boot: 0xfffc-0x
> section, .rodata: 0x10003bc0-0x10004111
> section, .sdata2: 0x10004114-0x10004113
> section, .sbss2: 0x10004114-0x10004113
> section, .data: 0x10004114-0x10004243
> section, .got: 0x10004244-0x10004243
> section, .got1: 0x10004244-0x10004243
> section, .got2: 0x10004244-0x1000425f
> section, .ctors: 0x10004260-0x10004267
> section, .dtors: 0x10004268-0x1000426f
> section, .fixup: 0x10004270-0x1000426f
> section, .eh_frame: 0x10004270-0x10004277
> section, .jcr: 0x10004278-0x1000427b
> section, .gcc_except_table: 0x1000427c-0x100042
> section, .sdata: 0x1000427c-0x10004293
> section, .sbss: 0x10004294-0x100042a3
> section, .bss: 0x100042a4-0x10004473
> section, .stack: 0x10004474-0x1000647f
> section, .heap: 0x10006480-0x1000847f
> Downloaded Program perif.elf
> Setting PC with Program Start Address 0xfffc
> 
> Does anybody know why the kernel elf don't have a boot section like
the
> TestApp generated by EDK?
> 
> I suppossed this is because the image kernel is compressed, but
despite
> beeing compressed it should have a boot section or something similar
???
> It's right that the kernel start address is set to the 0x0040??
> 
> Or does the section .text  contains all the kernel code to uncompresse
the
> code of the kernel??
> 
> 
> 
> --
> View this message in context:
http://www.nabble.com/Generated-xilinx-linux-2.6--image-sections-
> tp14997109p14997109.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
> 
> ___
> 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: Xilinx XPS_LL_TEMAC vs PLB_TEMAC

[Stephen Neuendorffer]

Basically, git.xilinx.com has a tree with most of the xilinx-related
support already integrated and ported forward to a current kernel.  It
also includes ongoing work to unify microblaze and powerpc device
drivers through flat device trees.

See:
http://www.mail-archive.com/linuxppc-embedded@ozlabs.org/msg28690.html

To use the git.xilinx.com tree you should *not* generate the driver code
directly into the Linux tree.  Instead, you should generate the driver
code in a dummy directory and copy
arch/ppc/platforms/4xx/xparameters_ml*.h into the kernel tree.

The BSP generation process is designed older 2.6.10-era kernels and will
not work with recent kernels.  

Steve

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of Mohammad
Sadegh Sadri
> Sent: Monday, January 21, 2008 12:54 AM
> To: David Baird; linuxppc-embedded@ozlabs.org
> Subject: RE: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
> 
> thanks for you reply david,
> 
> As far as I know the Linux driver for Xilinx PLB TEMAC was two parts :
1- adapter.c and 2- the rest
> of the driver files
> 
> Only adapter.c was really a linux related file and the rest of the
files were Xilinx generic driver
> code for PLB TEMAC.
> 
> correct?
> 
> then now, I know EDK 9.2 generates the needed Linux support package
and needed related files, so if
> this is the case can we use these files as the needed driver in our
linux kernel?
> 
> by the way, i did never hear about this git repository before...can
you describe us, where is it and
> how we can access it and which projects are now hosted by it?
> 
> 
> thanks
> 
> 
> > Date: Mon, 21 Jan 2008 00:54:30 -0700
> > From: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> > Subject: Re: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
> >
> > On Jan 21, 2008 12:36 AM, Mohammad Sadegh Sadri
<[EMAIL PROTECTED]> wrote:
> > > As you know Xilinx PLB TEMAC is a module which connects Hard TEMAC
in
> > > Virtex-4 FX devices to PLB bus,
> > > now, in the new release of EDK , EDK 9.2 Xilinx has added a new
interface
> > > core , which is called XPS_LL_TEMAC and has a different structure
than
> > > normal PLB TEMAC. spacially it has some additional data transfer
buses.
> > >
> > > Now the question is,... is there any linux driver available for
this new
> > > core?
> >
> > Yes there is, but I had to use the git sources at:
> >
> > git.xilinx.com
> 
> 
> 


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: ml310 kernel2.6 booting problems

[Stephen Neuendorffer]

Ron,

It might be better to start with the kernel from git.xilinx.com, which
already has an ML41x option.  The current version of EDK will also
generate support for ML410 with the PCI driver, if you are still using a
2.6.10-era kernel.  

I've refrained putting the PCI stuff on git.xilinx.com, because any
non-trivial usage of it that I've tried has generated warnings.  On top
of that, the code has some interrupt values hardcoded in the ALI
southbridge code.  Since there is no way to have this code pushed into
mainline, I'm not terribly interested in encouraging any work on it,
either.  Perhaps since there is so much interest in this code, someone
would like to get it working in ARCH=powerpc?  I'm happy to provide some
handholding to get someone started.

Steve

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of Ron Sass
> Sent: Friday, January 18, 2008 4:11 PM
> To: Jean-Samuel Chenard
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: ml310 kernel2.6 booting problems
> 
> 
> Hello All,
> 
> I have a sidewise question related to this thread.  We have
> several ML-310 and ML-410 boards.  At some point, we may need
> PCI but right now it is not urgent so I am not ready to invest
> a lot of time yet either.  I imagine that 2.6 + PCI would be
> relatively similiar for both ML-310 and ML-410...
> 
> My question is this:  Would it make sense to have a Kernel
> configuration something like "VIRTEX_PCI" and a platforms
> "XILINX_ML4xx" / "XILINX_ML3xx" ... or create four platforms:
> 
>   XILINX_ML300
>   XILINX_ML310
>   XILINX_ML40x
>   XILINX_ML410
> 
> I ask now because we are working on some device drivers for
> the ML410 that may work on 40x and I wondering if I should
> introduce a new ML410 platform option...
> 
> Ron
> 
> > > Date: Thu, 17 Jan 2008 21:19:04 +0100
> > > From: Joachim Meyer
> > > Hmmm... I'm not really ready to invest that much time into the PCI
for ML=
> > -310.
> > >

-=
> > ---
> > >
http://ozlabs.org/pipermail/linuxppc-embedded/2007-December/029211.html
> > >
> > > How much work would it be (approximated), and do you think I can
success =
> > (I'm a novice, like you know)?
> > > Would you help me (Tell me where to start & what to do)?
> >
> > Hi Joachim,
> >
> > I was also interested in getting the PCI to run on the ML-310.  I
did
> > spend an evening trying to integrate a patch sent over by Stephen
> > Neuendorffer from Xilinx.  I managed to get everything to compile
> > (basically I fixed a few missing macros and had to search a bit to
> > ensure that the memory mapping was correctly ported).
Unfortunately,
> > when I tried the new kernel, I think that I must have messed
something
> > up with the interrupt mappings (I am a newbie to PCI) and I had to
> > remove some interrupt mapping from Stephen's patch.
> >
> > In any case, my ML-310 was booting the Linux kernel, but something
was
> > not right and I did not get anymore printouts from the UART Lite.
> > Since I don't have the JTAG cable, I was stuck at this point with
> > little means to debug the system.  One day I'll spoil myself with
one
> > of those platform JTAG USB cables...
> >
> > I used Z-modem to transfer files to/from my workstation to my CF
card
> > on the ML-310 and this was an acceptable compromise.
> >
> > I'd still be interested in having the PCI bus working on the ML-310,
> > but now that I got my BEE2 booting Linux 2.6, its not such a big
> > priority for me.  Let me know if you have some success in that
> > direction.
> >
> > Regards,
> >
> > Jean-Samuel
> > -- =
> >
> > Integrated Microsystems Laboratory
> > McGill University, Montr=E9al, QC, CANADA
> > Web Page: http://chaos.ece.mcgill.ca
> > ___
> > 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


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: Problem booting Linux 2.6 on Virtex-4

[Stephen Neuendorffer]

What kernel version are you targeting? Are you using arch/powerpc or arch/ppc?  
V4 has a data cache errata, which isn't currently in mainline arch/powerpc.

if((mfpvr() & 0xf000) == 0x20011000) {
/* PPC errata 213: only for Virtex-4 FX */
__asm__("mfccr0  0\n\t"
"oris0,0,[EMAIL PROTECTED]"
"mtccr0  0"
: : : "0");
}

Steve

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of David Baird
> Sent: Monday, January 14, 2008 12:12 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: Re: Problem booting Linux 2.6 on Virtex-4
> 
> On Jan 14, 2008 1:37 AM, Enno Lübbers <[EMAIL PROTECTED]> wrote:
> > Hello David,
> >
> > Am 14.01.2008 um 06:12 schrieb David Baird:
> >
> > > I'm having trouble with getting Linux to boot farther than early_init.
> > > [...]
> > > So, I experimented further and discovered that different memory
> > > regions seem to be aliased on to each other every 2*32*256 bytes.
> >
> >
> > This sounds either like a wrong programming of an BRx/ORx memory
> > controller register pair (which, AFAIK, the PPC405 does not have), or
> > like a messed up address map in EDK. My guess is that an optimized/
> > sloppy implementation of the address decoder for some peripheral in an
> > EDK system could produce something like you described; or there's a
> > block RAM that's attached to a controller in the wrong way; or the
> > bank/address parameters of the DDR controller don't match the physical
> > setup... there's a lot that can go wrong obviously on a configurable
> > SoC.
> 
> What has been confusing me is that I am unable to reproduce the
> problem in real mode.  I can only reproduce the problem in virtual
> mode.  This leads me to believe, perhaps mistakenly, that the hardware
> is implemented okay.  OTOH, neither can I see anything wrong with the
> software.
> 
> > Can you be more specific about your hardware platform? Is this a
> > reference design? What board are you using?
> 
> I am currently testing code on the ML403 evaluation board.  I used the
> Base System Builder in EDK to create the hardware design and DDR SDRAM
> is being used as the main RAM starting at address 0x and also
> with OCM BRAM mapped at the very end of the address space (so that
> 0xfffc can contain code to execute on startup).
> 
> I am now trying to experiment with the hardware and see if I can find
> a hardware reference design.  I will let you know what I figure out.
> 
> -David
> ___
> 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: Linux for ml310

[Stephen Neuendorffer]

If you are using the secretlab.ca or git.xilinx.com trees, then you
should *not* follow the normal BSP generation process.  You need to
generate the BSP in a dummy location and then copy only the
xparameters_*.h file over the appropriate one in
arch/ppc/platforms/4xx/xparameters and make menuconfig.

Steve

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of greenlean
> Sent: Monday, January 14, 2008 10:42 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Re: Linux for ml310
> 
> 
> Hi, I was reading this post and a question came to my mind.
> 
> When I try to compile, did I have to copy the EDK driver folder to my
Xilinx
> 2.6 kernel tree and run the cow.tcl script generated by EDK?? Or this
is
> unnecesay??
> 
> 
> 
> 
> Grant Likely-2 wrote:
> >
> > On 1/9/08, Joachim Meyer <[EMAIL PROTECTED]> wrote:
> >> Hi
> >>
> >> I switched "Xilinx uartlite serieal port support" and "Support for
> >> console on Xilinxuartlite serialport" on and "8250/16550 and
compatible
> >> serial support" off, in the kernel config.
> >> Then I removed the things I added in the xparameters.h and compiled
> >> successfully.
> >> But I have yet a few Questions:
> >>
> >> - What would you recommend to use? UART-Lite or a 16550 serial
port. Can
> >> I get a console running on the RS232 Port of the Board with both
> >> possibilities?
> >
> > if you don't need to change the baud rate at runtime then use the
> > uartlite.
> >
> > Console works on both.
> >
> >>
> >> - Can you recommend anything for my next steps to get an running
linux
> >> (rootfs usw.)? So far I oriented myself on the Klingauf page, but I
think
> >> it is perhaps not the best one because its too old and some things
will
> >> probably not work the way he did it anymore.
> >
> > Use either ELDK or buildroot.  Personally, I'd like to be using
> > OpenEmbedded, but I haven't been successful with that yet.
> >
> > Cheers,
> > g.
> >
> > --
> > Grant Likely, B.Sc., P.Eng.
> > Secret Lab Technologies Ltd.
> > ___
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> >
> 
> --
> View this message in context:
http://www.nabble.com/Linux-for-ml310-tp14675554p14808605.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
> 
> ___
> 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: In PowerPC's feature, are there any difference between ML410 and ML403?

[Stephen Neuendorffer]

There shouldn't be a significant different in the cores themselves, however, 
there are many ways to get the FPGA design slightly wrong where it won't boot, 
or to get the kernel xparameters file out of synch with the FPGA design.  This 
is most likely your problem.

Steve

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of diak sim
> Sent: Thursday, January 10, 2008 5:56 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: In PowerPC's feature,are there any difference between ML410 and 
> ML403?
> 
> Hello everyone,
> 
> I am using ML410 to port a Linux 2.6 kernel, but init_IRQ() doesn't pass.
> Porting Linux 2.6 to ML403 is successful? No such a problem?
> In PowerPC's feature, are there any difference between ML410 and ML403?
> 
> Thanks.
> 
> 
> 
> 
> 雅虎邮箱传递新年祝福，个性贺卡送亲朋！ 
> 

___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: i2c device for a linux 2.6 in XUPV2P

[Stephen Neuendorffer]

Yes, it should be possible, however I don't believe the Linux adapter
for the i2c driver has been updated for current 2.6 kernel versions.
It's not currently on git.xilinx.com, and apparently the i2c subsystem
has changed significantly since the adapter was written, so it's not a
straightforward update.

If all you want to do is some simple configuration, then bitbanging the
i2c is straightforward.  I'll send you a driver that I cooked up at one
point in a separate email.

Steve

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of Josep Maria
Batlle
> Sent: Monday, December 24, 2007 1:27 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: i2c device for a linux 2.6 in XUPV2P
> 
> Hi all,
> 
> I have booted up linux 2.6 on Xilinx XUPV2P (using the base of ml300
config file).
> Now I am trying to use the i2c in the user-space. First of all: is it
possible?
> 
> My first attempts have not worked. I have made this:
> 1) I enable "I2C Support" and "I2C device interface" in the kernel
recompilation.
> 2) I added the "i2c-0" device in /dev (# mknod i2c-0 c 89 0)
> 3) then I run a simple program to open the device (provided by the
"dev-interface" file of i2c kernel
> documentation) that returns this errno message: "No such device".
> 
> I have tried to use the device number 1, 2, 3, 4 but these have not
worked. I have tried to use the
> device "i2cn" but not worked. I have tried to use all the BSP's from
the EDK (7.1i) and then only the
> "xparameters_ml300.h" in the compilation. After all of this, now I am
modifying the RFS for "mdev"...
> Somebody can tell me what I am doing wrong if this use is possible?
> 
> I use the kernel tree "virtex-for-2.6.24" from SecretLab and Busybox
1.7.2.
> 
> Thanks.


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: MMU failure, Virtex4-FX60

[Stephen Neuendorffer]

Passed along

"Most likely bootloop is not enabled. The processor takes an invalid
instruction and registers a following machine check exception. The
machine check exception is taken when it is enabled in the MSR causing
Linux to crash."

Steve

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-
> [EMAIL PROTECTED] On Behalf Of Robert
Woodworth
> Sent: Tuesday, January 08, 2008 1:55 PM
> To: Grant Likely
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: MMU failure, Virtex4-FX60
> 
> After further investigation...
> There is a pending interrupt from the PLB waiting at bootup and it
gets
> hit by Linux when the MSR gets set and enables critical interrupts
(same
> time that it jumps into 0xC000).  The kernel code detects the
> interrupt as a PLB data bus error and goes into crash sequence die().
> 
> I think I have a problem with my reset hardware, such that the PLB is
> not getting reset correctly with the PPC.  With all interrupts
disabled
> and running a standalone C program, the PLB and memory work fine.
> Any Virtex experts out there have any hints?
> 
> 
> 
> RJW.
> 
> 
> 
> 
> On Mon, 2008-01-07 at 11:21 -0700, Grant Likely wrote:
> > On 1/7/08, Robert Woodworth <[EMAIL PROTECTED]> wrote:
> > > Hello!
> > >
> > > I'm building a new Virtex4-FX60 device.  I have built it with the
new
> > > MPMC3 and a 256MB SO-DIMM.  It works successfully with a
"mem-test" type
> > > embedded program.
> > >
> > > I cannot get it to boot a Linux kernel.  I have traced it down to
the
> > > MMU not getting mapped correctly.
> > >
> > > I can load the kernel via jtag, get the pre-boot messages on the
serial
> > > but then when it tries to jump to 0xc0002218 (start_here:
head_4xxx.S)
> > > it fails with a "Machine check exception; invalid instruction
address".
> > >
> > > Using the debugger and examining the memory once the mmu is
suppose to
> > > be configured, I see that it is not mapping 0xc000  to the
proper
> > > location.  I'm sure I've set something up wrong in my FPGA and I
need to
> > > re-synthesize.  But what?
> >
> > Hmmm, I haven't seen that failure mode before.  MMU handling on an
of
> > my virtex platforms has never been a problem.  Take a look at the
TLB
> > registers to see how they are configured to see if the mappings are
> > really getting written.
> >
> > What kernel version are you using?
> >
> > Cheers,
> > g.
> >
> 
> ___
> 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: Xilinx devicetrees

[Stephen Neuendorffer]

 

> -Original Message-
> From: Koss, Mike (Mission Systems) [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, December 13, 2007 5:49 AM
> To: Stephen Neuendorffer; David H. Lynch Jr.; Grant Likely; 
> linuxppc-embedded
> Subject: RE: Xilinx devicetrees
> 
> SN> Interesting idea..  I've been trying to figure out how to 
> architect this 
> SN> better, but it requires some information passing within 
> EDK that isnot 
> SN> today supported.  I don't see at all how to synchronize this with 
> SN> patches to the kernel, tho.  My approach is to describe 
> the hardware 
> SN> as completely and faithfully as we can (given the 
> information in EDK), 
> SN> and let the drivers do whatever with it that they want to.
> 
> You'll have to correct if I'm wrong here, but from what I've 
> been reading up about EDK and its built-in Tcl interface, one 
> can load their system.xmp with corresponding mhs and then use 
> Tcl to traverse the device information to create the same 
> information as found using the generated BSP. This would 
> allow for a Tcl system that could be setup such that a main 
> (unchanging, or slowly changing) Tcl script that would start 
> the EDK definition traversal and upon finding a new device it 
> would use a registered 'handler' Tcl function. These handlers 
> could be stored as seperate script/files and would be 
> registered at the start of the main script either via a 
> config file or by searching a directory and looking for tags 
> stored at the top of the Tcl files in comments. These driver 
> handlers would be passed the handle to the system definition 
> and then know how to gather the information they need to 
> create their entry in the device tree. This approach gets 
> around the issue of losing defaults found in the mhs file.

This seems like alot of work, for relatively little benefit.  :)
Instead, I think it is safer to just describe the IP as completely as we
can up front.  Everything else should be done by the Linux driver.  Now
today there is a problem, which is that there isn't a standard way of
having a device describe itself, in the format of a device tree.  This
is something that we'll likely have to add hooks for in the future.

> I originally looked at trying to perform the same thing using 
> just device drivers in EDK, but I think I found some pitfall. 
>  Oh, I think it was that I would have to choose the OS for 
> the processor and EDK wants to build the library, but there 
> isn't anything to compile for Linux (or I wasn't compiling 
> anything for the linux BSP) and that was adding extra time to 
> the download.bit generation and that is already a long build process.

I can't imagine that generating this file is the bottleneck in getting
to a bitstream (or at least, I really hope it isn't!) 

Steve

___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: Xilinx devicetrees

[Stephen Neuendorffer]

-Original Message-
From: Koss, Mike (Mission Systems) [mailto:[EMAIL PROTECTED]
Sent: Mon 11/26/2007 7:31 AM
To: Stephen Neuendorffer; David H. Lynch Jr.; Grant Likely; linuxppc-embedded
Subject: RE: Xilinx devicetrees
 
Time for my $.02, since I am heavily weighting my future designs on the
use of the device trees. :) (and b/c I don't check my work e-mail from
home ;P)




SN> As Grant says, the dynamic detection doesn't have to be done in the
boot loader, it could be done in the platform code.  You can largely
ignore 
SN> the device trees, or always boot with a core device tree and figure
it all out later (perhaps using version registers).  I anticipate that 
SN> the 'standard flow' will have standard platform code for any board
that uses a complete device tree.  If you have the need to do something 
SN> extraordinary, then you should feel free to hack away...  However,
It doesn't seem to me to be really necessary in your case, assuming that

SN> the device tree is packaged (somehow, TBD) along with the bitstream.
 
> I don't know if packaging the device tree with the bitstream is the best
> way to go. It's possible that it could lead to headaches for certain
> systems that have security restrictions. The same could be said for
> using it w/ the SystemACE to load it into RAM after the image. (which is
> what I'm currently doing for my 2 linux images in lieu of a true on-chip
> bootloader). I am already taking the security concerns into account for
> future revisions of the hardware wrt to using a SystemACE, and am
> planning on moving the device trees into NV storage like FLASH.

'with' not 'in'. either using SystemAce, or a flash image.

> One solution I've been thinking through (in lieu of direct support from
> EDK) is to use a tcl script with xps to traverse the hardware tree and
> generate the device tree. It seems like it should be relatively trivial
> to obtain the information. It's just going to be a pain to write all the
> handlers for each different linux driver: temac, interrupt controller,
> DMA controller, etc.
> In reality the best way to handle this would be to have EDK generate the
> device tree as part of the library/bsp build process. 
We have a python script to do this.  The main problem with just looking at the 
mhs file is that you lose all the defaults for each IP.  Hence, we've also 
written a BSP generator to do this.  both are at 
git://git.xilinx.com/gen-mhs-devtree.py
Once I can verify that they work in the mainline tree, I'll be sending out the 
patches that make this all work.

> Now, what I'd like
> to see with regards to this is the ability to change the handler for the
> generating a specific device information. An example could be the temac.
> If at some point in the future the temac needs new/more information to
> support its configuration/run-time then having to get a patch from
> Xilinx for a EDK is way too slow. The developers should be giving the
> opportunity to inject a new handler into the various parts of the device
> tree generation. That way when the kernel patch is submitted, an EDK
> device generator patch will be submitted at the same time to keep
> everything in sync.

Interesting idea..  I've been trying to figure out how to architect this 
better, but it requires some information passing within EDK that isnot today 
supported.  I don't see at all how to synchronize this with patches to the 
kernel, tho.  My approach is to describe the hardware as completely and 
faithfully as we can (given the information in EDK), and let the drivers do 
whatever with it that they want to.

Steve


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: Linux 2.6 from git.xilinx and XUPV2P

[Stephen Neuendorffer]

The xparameters file is specific to your hardware design.
You should change the name of the generated xparameters file to match
xparameters_xupv2p.h 

Unfortunately, it's sort of an historical artifact that it was done this
way...  In reality, all the different xparameters files should really
just be one, since only one can be active at a time.

The last error sounds like you haven't actually generated an elf file?
have you tried running objdump on it?

Steve

> -Original Message-
> From: 
> [EMAIL PROTECTED]
>  
> [mailto:[EMAIL PROTECTED]
> labs.org] On Behalf Of greenlean
> Sent: Wednesday, December 12, 2007 9:05 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Re: Linux 2.6 from git.xilinx and XUPV2P
> 
> 
> 
> 
> greenlean wrote:
> > 
> > Thanks both for the response, I've allready visited some of 
> the links. 
> > 
> > Yes, you was right it's easear than I think, my problem was 
> the .config
> > file. Now, I have generated it from ml300_defconfig and 
> after some changes
> > it compiles, but I've two question:
> > 
> >  * I've chosen as platform the XUPV2P in Machine Type, 
> instead of ML300,
> > so the xparameters file that I'm using is the 
> xparameters_xupv2p.h, but
> > the xparameters file generated by the EDK is 
> xparameters_ml300 despite I
> > told it to use XUPV2P, so I can't overwrite it... 
> > 
> > Should I use the xparameters_ml300 generated by EDK or the
> > xparameters_xupv2p included in the git kernel tree?.  I 
> can't compile with
> > the edk's xparameters_ml300 file because there's some 
> definition that the
> > compiler can't find, so I'm using the xparameters_xupv2p.
> > 
> >  * Second, if I compile using the xparameters_xupv2p, when 
> I do the dow
> > command to download the image to the board, the xmd shell tell me:
> >
> >XMD% dow zImage.elf
> >Failed to download ELF file
> > 
> >   ERROR(1053): UNABLE to Read Elf File. The Elf File 
> Maybe Corrupted
> >   : zImage.elf
> > Maybe this error is due to the above asumption??. I'll post 
> this second
> > one on xilinx-support maybe it's realted with my system.
> > 
> > 
> > 
> 
> -- 
> View this message in context: 
> http://www.nabble.com/Linux-2.6-from-git.xilinx-and-XUPV2P-tp1
> 4274035p14299307.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
> 
> ___
> 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: Linux 2.6 from git.xilinx and XUPV2P

[Stephen Neuendorffer]

Hi!

Unfortunately, at this point, git.xilinx.com is not 'beginner friendly'.
There is a rather complicated set of things that has to be coordinated
between EDK and the linux kernel.  Also, many EDK designs will simply
not work with the Linux drivers.  Today, it is primarily a place for us
to collaborate with the open source community on new development, hence
it also is perhaps less stable than a beginner really wants.

That said:
git.xilinx.com includes all the common EDK drivers.  The only thing you
should need to add is the xparameters file.  Today, this requires
generating the Board Support Package from a recent version of EDK, using
the linux_2_6 OS support and copied into
arch/ppc/platforms/4xx/xparameters/.  Then whenever you run make use
ARCH=ppc.

This appnote shows how to use the linux_2.6 BSP:
http://www.xilinx.com/support/documentation/application_notes/xapp969.pd
f

There are also several websites with more information about 'rolling
your own' Linux kernel and root file system (google some combination of
'xilinx' 'virtex' 'ml310' 'ml300' and 'linux'):

http://www.crhc.uiuc.edu/IMPACT/gsrc/hardwarelab/docs/kernel-HOWTO.html
http://www.klingauf.com/v2p/index.phtml
http://www.soe.ucsc.edu/~rios/ml310/ml310_linux.htm
http://www.cs.washington.edu/research/lis/empart/xup_ppc_linux.shtml
http://splish.ee.byu.edu/projects/LinuxFPGA/index.htm

Personally, EDK4.1 works fine for me.  It may be that you are
configuring lots of features in the kernel.  A good start would be the
ml300_defconfig.

Steve

> -Original Message-
> From: 
> [EMAIL PROTECTED]
>  
> [mailto:[EMAIL PROTECTED]
> labs.org] On Behalf Of greenlean
> Sent: Tuesday, December 11, 2007 5:32 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Linux 2.6 from git.xilinx and XUPV2P
> 
> 
> Hi all,
> 
>  I'm a beginner in Xilinx & Linux world and I'm getting a bit 
> loose. I'm
> trying to run linux kernel 2.6 that I downloaded from the 
> xilinx git server
> on the PPC405 of the Xilinx university program Virtex II Pro 
> (XUPV2P for the
> search engine)  board, and I'm using the compiler ELDK 4.1 
> (I' ve just read
> this compiler may cause some error so I'll change it, and try the 4.0
> version) and I'm getting a lot of compilation error  and warning. 
> 
> I think this is what I should use, Does anybody if I have to 
> patch this
> kernel or if it is still prepatched??
> 
> My compiler can find some definitions like TASK_SIZE or 
> CONFIG_KERNEL_START,
> now I'm solving it writting  the values manually , I google 
> for the error
> and make the definition where it's needed, but I don't think 
> this is a good
> idea ;). I think this definitions should be defined in the 
> .config file,
> because I found the values I wrote on a posted message in this list.
> 
> Maybe somebody could guide me a bit through this kernel 
> compilation, or send
> me .config file running. I don't know if a revision in the 
> project is a good
> way, to put things in situation for beginers. 
> 
> Thanks, any info would be interesting. 
> 
> 
> 
> -- 
> View this message in context: 
> http://www.nabble.com/Linux-2.6-from-git.xilinx-and-XUPV2P-tp1
> 4274035p14274035.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
> 
> ___
> 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: Xilinx ML310 Linux 2.6 PCI bridge

[Stephen Neuendorffer]

 
> That's where things get complicated...  In our lab, we get expensive
> hardware such as the BEE2 via CMC Microsystems (a Canadian granting
> agency).  However, getting funds locally to buy other equipment is a
> relatively long and administratively complex process...

Yeah, I understand how such things go... :)

> I find it strange that Xilinx would not invest in supporting Linux 2.6
> for an important feature such as a PCI bridge (not specifically for
> the ML-310, but in general) when this can bring many interesting
> benefits to an embedded platform.  Is this something that is "in
> progress" at Xilinx?  You seem to imply that most of the difficulty in
> getting the PCI core working is in meeting the timing requirements
> (not with the SW drivers), so I might be missing driver files when I
> generate the BSP code for Linux 2.6.

The PCI core needs a separate driver for generating the right
constraints.  In EDK 9.2 there is some linux 2.6 support for this, but
the code won't work with any of the new kernels.  I've pulled the
changes into my internal git tree, but for reasons that I haven't been
able to ascertain, there are hardcoded xparameter-based interrupt
defines in the super I/O bridge controller.

In any event, I'll send you the patches directly and you can try getting
it to work, although you'll likely need to carefully write the
xparameters by hand.  If you can get away without networking, I'd do
that, though.  :)

Steve 

___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: Xilinx ML310 Linux 2.6 PCI bridge

[Stephen Neuendorffer]

I would strongly recommend not spending a huge amount of time on the ml310.  
The University program board is dirt cheap for universities, very well 
supported under Linux, using either secretlab.ca or git.xilinx.com and you 
won't spend your time getting PCI to place and route correctly, followed by 
figuring out how to get Linux to talk to it nicely.

If your lab can afford a bee2, then you should be able to afford one (or better 
yet, several) xupv2p's to go with it.

http://www.xilinx.com/univ/xupv2p.html

Steve

-Original Message-
From: [EMAIL PROTECTED] on behalf of Grant Likely
Sent: Sun 12/9/2007 12:23 PM
To: Jean-Samuel Chenard
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Xilinx ML310 Linux 2.6 PCI bridge
 
On 12/9/07, Jean-Samuel Chenard <[EMAIL PROTECTED]> wrote:
> On Dec 9, 2007 1:18 AM, Grant Likely <[EMAIL PROTECTED]> wrote:
> > On 12/8/07, Jean-Samuel Chenard <[EMAIL PROTECTED]> wrote:
> > > Thanks to the valuable information provided by this discussion group and
> > > particularly by Grant Likely from Secret Lab Technologies, I was able to
> > > setup and run Linux 2.6 on my ML-310 development platform.
> >
> > Congratulations.  If you had to make any changes to get it to work
> > then please send me your patches.
>
> Thank you for the quick reply.

No problem.

>
> I will directly update Secret Lab's Wiki pages.  Those pages are the
> ones that got me going really quickly, so I will add a few of my
> observations directly on your pages so everyone can benefit.

Much appreciated; thank you!

> My real target is the control FPGA on a BEE2 box
> (http://bee2.eecs.berkeley.edu) and on that particular setup, the
> control FPGA is directly connected to an LXT971A Ethernet PHY, so I'll
> use the ethernet MAC from Xilinx.

Cool platform.  Yes, you should have much better luck with the EMAC
core.  The driver needs some work to be acceptable for mainline, but
it should be functional.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
___
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: current ARCH=powerpc for v2pro.

[Stephen Neuendorffer]

Hmm...  This code (from arch/ppc/boot/simple/embed_config.c) appears to
help:

static const unsigned long line_size = 32;
static const unsigned long congruence_classes = 256;
unsigned long addr;
unsigned long dccr;

/*
 * Invalidate the data cache if the data cache is turned off.
 * - The 405 core does not invalidate the data cache on power-up
 *   or reset but does turn off the data cache. We cannot assume
 *   that the cache contents are valid.
 * - If the data cache is turned on this must have been done by
 *   a bootloader and we assume that the cache contents are
 *   valid.
 */
__asm__("mfdccr %0": "=r" (dccr));
if (dccr == 0) {
for (addr = 0;
 addr < (congruence_classes * line_size);
 addr += line_size) {
__asm__("dccci 0,%0": :"b"(addr));
}
}

Although, I'm not sure why that should be virtex specific.

Steve 

> -Original Message-
> From: 
> [EMAIL PROTECTED]
>  
> [mailto:[EMAIL PROTECTED]
> labs.org] On Behalf Of Stephen Neuendorffer
> Sent: Monday, December 03, 2007 4:49 PM
> To: Grant Likely
> Cc: linuxppc-embedded
> Subject: RE: current ARCH=powerpc for v2pro.
> 
> I tried that, which essentially differed from what I was 
> trying in that
> interrupts were turned off.
> It fails in the same way as before.
> 
> I've booted ARCH=ppc from your tree on the exact same hardware design,
> and as near as I can tell, the code that runs in the kernel 
> proper up to
> the point where I see the machine check is almost identical.
> 
> The machine check (a trap into the Machine Check handler at 0x200)
> occurs at a nondeterministic point during the execution of 
> memset_io in
> early_init.
> 
> In the kernel I have, _bss_start is c02c8000, and these are the
> registers in the trap handler on two different runs of the kernel:
> 
> r3: c02c80cc r5: 00022874
> r3: c02c8248 r5: 000226f4
> 
> r3 is the current point being initialized, and r5 is the 
> count remaining
> in the .bss.
> 
> So, what would cause a machine check in the middle of a loop, in the
> middle of the almost the simplest code absolutely possible, and not on
> an obvious memory boundary?
> 
> Steve
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> > Behalf Of Grant Likely
> > Sent: Friday, November 30, 2007 10:40 PM
> > To: Stephen Neuendorffer
> > Cc: linuxppc-embedded
> > Subject: Re: current ARCH=powerpc for v2pro.
> > 
> > On 11/30/07, Stephen Neuendorffer 
> > <[EMAIL PROTECTED]> wrote:
> > >
> > > Grant,
> > >
> > > I'm trying to bring up your arch/powerpc work, using a compiled in
> > > device tree.  I added this:
> > >
> > 
> > >
> > > Which seems bizarre, because that code is very simple.  
> I'm guessing
> > > that something in the memory configuration is wierd (or maybe
> > > zImage.virtex is not the right way to do this?) but I'm a 
> > little lost
> > > where to look from here.  I also tried it with both 
> > paulus_master and
> > > your virtex-for-2.6.24 branch.
> > 
> > 
> > I've got a patch that adds 'raw' image support (originally 
> written by
> > Scott Wood) which somewhat works for booting (but not entirely; I
> > haven't had time to dig into it properly yet).  It's not suitable to
> > go into mainline yet.  I'll try to get the patch out to my tree this
> > evening... actually I've been trying to get my tree pushed out all
> > today, but other things keep coming up.  :-)
> > 
> > 
> > 
> > Okay, I pushed my current patch set out to the master branch of my
> > linux-2.6-virtex tree.  Give it a whirl.  It's not perfect, but it
> > should be usable for booting.
> > 
> > Cheers,
> > g.
> > 
> > -- 
> > Grant Likely, B.Sc., P.Eng.
> > Secret Lab Technologies Ltd.
> > [EMAIL PROTECTED]
> > (403) 399-0195
> > 
> > 
> 
> ___
> 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: current ARCH=powerpc for v2pro.

[Stephen Neuendorffer]

I tried that, which essentially differed from what I was trying in that
interrupts were turned off.
It fails in the same way as before.

I've booted ARCH=ppc from your tree on the exact same hardware design,
and as near as I can tell, the code that runs in the kernel proper up to
the point where I see the machine check is almost identical.

The machine check (a trap into the Machine Check handler at 0x200)
occurs at a nondeterministic point during the execution of memset_io in
early_init.

In the kernel I have, _bss_start is c02c8000, and these are the
registers in the trap handler on two different runs of the kernel:

r3: c02c80cc r5: 00022874
r3: c02c8248 r5: 000226f4

r3 is the current point being initialized, and r5 is the count remaining
in the .bss.

So, what would cause a machine check in the middle of a loop, in the
middle of the almost the simplest code absolutely possible, and not on
an obvious memory boundary?

Steve

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Grant Likely
> Sent: Friday, November 30, 2007 10:40 PM
> To: Stephen Neuendorffer
> Cc: linuxppc-embedded
> Subject: Re: current ARCH=powerpc for v2pro.
> 
> On 11/30/07, Stephen Neuendorffer 
> <[EMAIL PROTECTED]> wrote:
> >
> > Grant,
> >
> > I'm trying to bring up your arch/powerpc work, using a compiled in
> > device tree.  I added this:
> >
> 
> >
> > Which seems bizarre, because that code is very simple.  I'm guessing
> > that something in the memory configuration is wierd (or maybe
> > zImage.virtex is not the right way to do this?) but I'm a 
> little lost
> > where to look from here.  I also tried it with both 
> paulus_master and
> > your virtex-for-2.6.24 branch.
> 
> 
> I've got a patch that adds 'raw' image support (originally written by
> Scott Wood) which somewhat works for booting (but not entirely; I
> haven't had time to dig into it properly yet).  It's not suitable to
> go into mainline yet.  I'll try to get the patch out to my tree this
> evening... actually I've been trying to get my tree pushed out all
> today, but other things keep coming up.  :-)
> 
> 
> 
> Okay, I pushed my current patch set out to the master branch of my
> linux-2.6-virtex tree.  Give it a whirl.  It's not perfect, but it
> should be usable for booting.
> 
> Cheers,
> g.
> 
> -- 
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> [EMAIL PROTECTED]
> (403) 399-0195
> 
> 

___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

current ARCH=powerpc for v2pro.

[Stephen Neuendorffer]

Grant,

I'm trying to bring up your arch/powerpc work, using a compiled in
device tree.  I added this:

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 18e3271..48f745d 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -53,7 +53,7 @@ src-wlib := string.S crt0.S stdio.c main.c
flatdevtree.c flatd
cpm-serial.c stdlib.c mpc52xx-psc.c planetcore.c
uartlite.c \
fsl-soc.c mpc8xx.c pq2.c
 src-plat := of.c cuboot-52xx.c cuboot-83xx.c cuboot-85xx.c holly.c \
-   cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
+   virtex.c cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c
cuboot-8xx.c \
cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c
cuboot-bamboo.c 
fixed-head.S ep88xc.c cuboot-hpc2.c
@@ -159,6 +159,7 @@ image-$(CONFIG_EBONY)   +=
treeImage.ebo
 image-$(CONFIG_BAMBOO) += treeImage.bamboo
cuImage.bamboo
 image-$(CONFIG_SEQUOIA)+= cuImage.sequoia
 image-$(CONFIG_WALNUT) += treeImage.walnut
+image-$(CONFIG_XILINX_VIRTEX_GENERIC_BOARD)+=
zImage.virtex
 endif
 
 # For 32-bit powermacs, build the COFF and miboot images
diff --git a/arch/powerpc/boot/virtex.c b/arch/powerpc/boot/virtex.c
new file mode 100644
index 000..32cebc1
--- /dev/null
+++ b/arch/powerpc/boot/virtex.c
@@ -0,0 +1,20 @@
+
+
+#include "ops.h"
+#include "stdio.h"
+#include "dcr.h"
+#include "4xx.h"
+#include "io.h"
+
+BSS_STACK(4096);
+
+void platform_init(void)
+{
+   unsigned long end_of_ram = 0xfff;
+   unsigned long avail_ram = end_of_ram - (unsigned long) _end;
+
+   simple_alloc_init(_end, avail_ram, 32, 32);
+   ft_init(_dtb_start, _dtb_end - _dtb_start, 32);
+   serial_console_init();
+printf("booting virtex\n");
+}

and got as far as:

---
booting virtex

zImage starting: loaded at 0x0040 (sp: 0x00551f14)
Allocating 0x2d7324 bytes for kernel ...
gunzipping (0x <- 0x0040b000:0x00550d74)...done 0x2b35ec bytes

Linux/PowerPC load: root=/dev/xsysace/disc0/part2
Finalizing device tree... flat tree at 0x409870
---

Tracing through the code, it appears that there is a machine check in
memset_io in early_init():

unsigned long __init early_init(unsigned long dt_ptr)
{
unsigned long offset = reloc_offset();
struct cpu_spec *spec;

/* First zero the BSS -- use memset_io, some platforms don't
have
 * caches on yet */
memset_io((void __iomem *)PTRRELOC(&__bss_start), 0,
__bss_stop - __bss_start);

/*
 * Identify the CPU type and fix up code sections
 * that depend on which cpu we have.
 */
spec = identify_cpu(offset, mfspr(SPRN_PVR));

do_feature_fixups(spec->cpu_features,
  PTRRELOC(&__start___ftr_fixup),
  PTRRELOC(&__stop___ftr_fixup));

return KERNELBASE + offset;
}

Which seems bizarre, because that code is very simple.  I'm guessing
that something in the memory configuration is wierd (or maybe
zImage.virtex is not the right way to do this?) but I'm a little lost
where to look from here.  I also tried it with both paulus_master and
your virtex-for-2.6.24 branch.

Any ideas?

Steve

___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: Xilinx devicetrees

[Stephen Neuendorffer]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED]
>  
> [mailto:[EMAIL PROTECTED]
labs.org] On Behalf Of John Williams
> Sent: Tuesday, November 27, 2007 4:53 PM
> To: Stephen Neuendorffer
> Cc: Michal Simek; linuxppc-embedded
> Subject: Re: Xilinx devicetrees
> 
> Stephen Neuendorffer wrote:
> 
> >>From: John Williams [mailto:[EMAIL PROTECTED] 
> 
> >>MicroBlaze is a highly configurable CPU in terms of its 
> >>instruction set, 
> >>features and so on.  To make use of this, it is essential that each 
> >>kernel image be compiled to match the CPU configuration.  While a 
> >>generic kernel, making use of no features (MUL, DIV, Shift, 
> >>MSR ops etc) 
> >>would run on any CPU, performance would be abysmal.
> > 
> > I think the userspace is actually much more critical than 
> the kernel for
> > most of these things (with the exception of msrset/msrclr, and the
> > barrel shifter perhaps).  Unfortunately, even if you implement an
> > alternatives-style mechanism for the kernel, you're still hosed for
> > userspace.  
> 
> I haven't benchmarks each option on the kernel - you are right that 
> shift is a big one, but mul I think is also important, given 
> that every 
> array access generates an integer multiply,

Good point.

> 
> Once I a big enough system, it's just unfeasible to
> > recompile everything anyway.  I think this is where 
> autoconfig starts to
> > break down.
> 
> I'm not sure I agree, here, given that most people building 
> MicroBlaze 
> systems are doing so with uClinux-dist (or PetaLinux), you 
> can do a full 
> rebuilt, kernel libs apps, in a couple of minutes.  Much shorter than 
> sythnesis and P&R, that's for sure (and runtime is linear in size, 
> unlike P&R :)

Let's not bash the P&R guys too much...  You try working on a problem
that is known to be insolvable, and where no matter how many people you
make happier, you'll always get bashed by the guy whose design no longer
meets timing. :)

> > It's not nice, I agree.  I think the key principle should be that I
> > should be able to get a system working as quickly as possible, and I
> > might optimize things later.  One thing that device trees 
> will allow is
> > for *all* the drivers to get compiled in to the kernel, and 
> only as a
> > late stage operation does a designer need to start throwing 
> things away.
> > Using traps I can easily start with a 'kitchen sink' 
> design, and start
> > discarding processor features, relying on the traps.  When I get low
> > enough down on the performance curve, I can uas an autoconfig-type
> > mechanism to regain a little of what I lost by optimizing 
> away the trap
> > overhead. 
> 
> OK, but now we have a kernel dependent on *3* files - a DTS, a 
> Kconfig.auto, and (indirectly) the bitstream itself.

The kernel might be generated from them, but it is not *dependent* on
them.  The same kernel can run on other hardware, with other dts's.  If
there was a traps mechanism (or alternatives), then it could also run on
other designs with different processor features.

> Another thing I suggested to Michal recently, perhaps we need 
> kernel/lib/libof to store common OF / DT handling code.  Much better 
> than duplicating it accross microblaze and PPC, and maybe 
> other arch's 
> would also see the light..  That would also add a claim for 
> the DTC to 
> go in scripts/

There's some shared code in 2.6.24-rc in drivers/of.  Now that things
are settling down in terms of bugs, I'll probably transition to pushing
a 2.6.24-rc branch soon.  However, the few brief conversations I've had
suggest that what microblaze might need or want has very little
influence until it is visible in mainline.  Once that happens, I think
it will be easy to justify putting code like libfdt and some of the
kernel of/dt code in a common place.  

So, John: would you care to make a goal (for say 2.6.25 or 26) of
working with me to get the microblaze into mainline?  I think the
community exists to keep things maintained, but I'm guessing that it
would help to have an existing LKMLer or two take a look over the code.
Given the move towards device trees, getting someone from powerpc would
seem to be natural.  Anybody interested?

Steve

___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: Xilinx devicetrees

[Stephen Neuendorffer]

 
> -Original Message-
> From: John Williams [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, November 27, 2007 3:55 PM
> To: Stephen Neuendorffer
> Cc: David H. Lynch Jr.; linuxppc-embedded; Michal Simek
> Subject: Re: Xilinx devicetrees
> 
> 
> MicroBlaze is a highly configurable CPU in terms of its 
> instruction set, 
> features and so on.  To make use of this, it is essential that each 
> kernel image be compiled to match the CPU configuration.  While a 
> generic kernel, making use of no features (MUL, DIV, Shift, 
> MSR ops etc) 
> would run on any CPU, performance would be abysmal.

I think the userspace is actually much more critical than the kernel for
most of these things (with the exception of msrset/msrclr, and the
barrel shifter perhaps).  Unfortunately, even if you implement an
alternatives-style mechanism for the kernel, you're still hosed for
userspace.  Once I a big enough system, it's just unfeasible to
recompile everything anyway.  I think this is where autoconfig starts to
break down.

> In my view it's not acceptable to present these as options 
> for the user 
> to select at kernel config time. With N yes/no parameters, there is 1 
> correct configuration, and 2^N-1 incorrect ones.  The odds of 
> the user 
> falling upon a configuration that at worst fails to boot, or 
> at best is 
> not optimally matched to the hardware, are high.

Yes.  Autoconfig does handle this in a fairly nice way.

> This same issue also applies to C libraries and apps - they must be 
> compiled with prior knowledge of the CPU.  This is why our 
> microblaze-uclinux-gcc toolchain, with multilib'd uClibc, is 
> almost 400meg!
> 
> Wrapping every mul, div, shift etc in a function call is clearly not 
> feasible.  Things like the msrset/msrclr ops have a modest but 
> measurable impact on kernel code size and performance - it's just not 
> reasonable to add any level of indirection in there.
> 
> I have thought about dynamic (boot-time) code re-writing as one 
> possibility here, but it very quickly gets nasty.  All of the 
> "optimised" opcodes (MUL/DIV/Shift etc) are smaller than 
> their emulated 
> counterparts, so in principle we could re-write the text segment with 
> the optimised opcode, then NOP pad, but that's still inefficient.  As 
> soon as we start talking about dynamic code relocation, re-writing 
> relative offsets in loops, ... yuck..  We'd be putting half of mb-ld 
> into the arch early boot code (or bootloader...)
> 
> The opposite approach, to build with all instructions enabled and 
> install exception handlers to deal with the fixups, is also 
> pretty awful.

It's not nice, I agree.  I think the key principle should be that I
should be able to get a system working as quickly as possible, and I
might optimize things later.  One thing that device trees will allow is
for *all* the drivers to get compiled in to the kernel, and only as a
late stage operation does a designer need to start throwing things away.
Using traps I can easily start with a 'kitchen sink' design, and start
discarding processor features, relying on the traps.  When I get low
enough down on the performance curve, I can uas an autoconfig-type
mechanism to regain a little of what I lost by optimizing away the trap
overhead. 

Personally, I think the easiest way out of all this is to just have less
configurability.  For microblaze in general, this is too much of a
restriction, but microblaze used as a control processor running linux,
there are probably just a few design points that really make sense
(probably size optimized: no options except maybe msrset/msrclr, and the
kitchen sink).  If we go that far, we don't really need people to ever
run autoconfig, or kernels, or anything.  Especially considering there
is no easy way of selecting which of the 2^N design points I want
*anyway*. :)

> I find myself asking the question - for what use cases does 
> the current 
> static approach used in MicroBlaze (with the PetaLinux BSP / 
> Kconfig.auto) *not* work?
> 
> One compromise approach might be to have a script in 
> arch/microblaze/scripts, called by the arch Makefile, that 
> cracks open 
> the DT at build time and extracts appropriate cpu flags.

Hmm... interesting idea, although parsing the source is likely
difficult...  It's probably not worth it to go this far, I think.   As
you say, why doesn't autoconfig of today work fine for this.

> Finally, what is the LKML position on DT files going into the kernel 
> source tree?

Source .dts go in and get compiled to binary blobs at compile time.  The
'big' recent controversy is whether the source->binary compiler dtc
should be mirrored in the Linux tree or not.

Steve

___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: Xilinx devicetrees

[Stephen Neuendorffer]

 

> -Original Message-
> From: David H. Lynch Jr. [mailto:[EMAIL PROTECTED] 
> Sent: Monday, November 26, 2007 1:17 PM
> To: Koss, Mike (Mission Systems)
> Cc: Stephen Neuendorffer; Grant Likely; linuxppc-embedded
> Subject: Re: Xilinx devicetrees
> 
> Koss, Mike (Mission Systems) wrote:
> > Time for my $.02, since I am heavily weighting my future 
> designs on the
> > use of the device trees. :) (and b/c I don't check my work 
> e-mail from
> > home ;P)
> >
> > ____
> >
> > From: Stephen Neuendorffer [mailto:[EMAIL PROTECTED] 
> > Sent: Sunday, November 25, 2007 6:59 PM
> > To: David H. Lynch Jr.; Grant Likely; linuxppc-embedded
> > Subject: RE: Xilinx devicetrees
> >
> >
> 
> >
> > SN> I don't understand the 'burden on software developers'. 
>  The code to
> > do this will just be standard code.  
> I got 16K of RAM for my boot loader and that 16K has to 
> do alot more
> than just manage device trees.
> I think we have 2K left. In that I have to fit scripting, and
> ethernet, so where am I supposed to fit the standard code ?
> If the devicetree is say at the end of the bit file I can probably
> copy it to ram and pass a pointer to linux in maybe a couple 
> of hundred
> bytes.
> If I have to do much more it ain't happening.

Personally, It sounds like you're trying to do to much...  The only
thing that that code really needs to do is to find the 'real' boot code:
Maybe Uboot stored in flash? :)  I'm not naive enough to suggest that I
understand all the constraints of your system, but it is another
solution.

> > The worst that one can say is:
> > SN> 1) I need several KB additional non volatile storage.  Given the
> > size of the FPGA bitstream, this can't be a huge constraint.
> >   
>Several KB is NOT happening. The bitstream is in 
> flash. Flash is
> not a limited reasorce for  us.
>FPGA cells, and BRAM are precious as gold. The more we use the
> less our clients have.

Device tree should probably be stored in flash, in your case

> >
> > SN> Certainly..  But in a sense, these are all intermediate 
> files on the
> > path to the image on the board.
> Unless we are going to teach linux to read and interpret 
> .bit files
> while loading, then devicetrees are intermediate in an entirely
> different sense.
> The hardware works fine regardless of whether their is a 
> devicetree.
> But Linux may not boot.

I think this philosphy really minimized the value of software...  The
hardware doesn't work unless the software that comes with it *also*
works. :)

>  My objective is to get alot of software - linux, GHS, and
> standalone apps, to all load - from a single executables, accross
> multiple different bit images on several different (though 
> deliberately
> similar) products. My Linux kernel needs to work regardless 
> of the Pico
> card and regardless of the bit image, as done my GHS kernel, and 
> And I need to do that in a severly resource constrained environment.
> I would hope that should make sense of my harping about
> version/capabilities registers. If I have maybe 10 possible 
> peices of IP
> that may/maynot be present in a given FPGA and I am trying to
> dynamically configure - Linux/GHS/... to adapt to whatever it 
> encounters
> and work as long as it is a viable combination. At best 
> devicetrees are
> an extremly complex way of solving that - while version 
> registers are a
> trivial way.

It sounds like the real problem that you have is that even if you get
device trees working for Linux, you still have the same problem for GHS,
so from your perspective "device trees don't help"

Steve

___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: Xilinx devicetrees

[Stephen Neuendorffer]

I understand that you're trying to be somewhat of a devil's advocate here, but 
(as I mentioned in my other email), alot of these are issues we're attempting 
to tackle.
More comments below.

-Original Message-
From: [EMAIL PROTECTED] on behalf of David H. Lynch Jr.
Sent: Sun 11/25/2007 2:55 PM
To: Grant Likely; linuxppc-embedded
Subject: Re: Xilinx devicetrees
 
Grant Likely wrote:
>I am not expert on this, but at Pico we already store our boot
> monitor in the .bit files in BRAM.
> But that is not free.  It is one of the reasons we do not use
> u-boot. Our boot monitor must fit into 16K of BRAM.
> Must be able to perform selftests on critical hardware, support a
> flash file system, load bit files from flash to the FGA, load and
> exectute elf files, allow a small set of user commands, and handle
> hosted vs. standalone operation.
> And aparently extract the devicetree from a bit file and pass it to
> a linux kernel.

Once you can load a bitstream from flash, loading the device tree from flash
should be practically free.  In any event, why do you do this rather than just 
run out of the flash (or a ram copy of the flash?)

> In static or fairly static hardware, that's fine. Even in somewhat
> dynamic hardware with large quantities of startup resources - like a PC.
> But in highly dynamic hardware with fairly limited resources it
> starts to become an issue.

As Grant says, the dynamic detection doesn't have to be done in the boot 
loader, it could be done in the platform code.  You can largely ignore the 
device trees, or always boot with a core device tree and figure it all out 
later (perhaps using version registers).  I anticipate that the 'standard flow' 
will have standard platform code for any board that uses a complete device 
tree.  If you have the need to do something extraordinary, then you should feel 
free to hack away...  However, It doesn't seem to me to be really necessary in 
your case, assuming that the device tree is packaged (somehow, TBD) along with 
the bitstream.

>> No, unfortunately they don't deal with the problem you're facing
>> (which I'm facing also).  But it will be solved if we figure out a
>> sane way to bind the device tree up with the FPGA bitstream without
>> consuming FPGA resources.
>>   
>Note to Xilinx:
>
>   There MUST be some way of binding a device description to a bit file.
>
>neither building it into the FPGA fabric nor appending it to the end
> of the bit file are perfect solutions,
>The former is more powerfull and flexible but wastes precious
> resources. The later is more complex and puts more burdens on
>software developers, and may be completely unfeasible in some
> environments - not mine fortunately.

I don't understand the 'burden on software developers'.  The code to do this 
will just be standard code.  The worst that one can say is:
1) I need several KB additional non volatile storage.  Given the size of the 
FPGA bitstream, this can't be a huge constraint.
2) I can't use compile time optimization based on xparameters as easily.  
Anyone want to implement the alternatives mechanism on ppc and microblaze?
3) Some additional boot time.  However, again, this seems marginal.

>Regardless, something must be done. An odd collection of devicetree
> files co-mingled with a collection of bit files, is little better than
> xparameter files all over the place.

Certainly..  But in a sense, these are all intermediate files on the path to 
the image on the board.  That (and how it is interpreted by the platform code) 
should be generated in a consistent fashion by EDK.  See my other email for 
some of the possibilities.  Are there specific reasons why you think those 
proposals are inadequate?  Now is the time when we can take criticism, with the 
goal towards making a good end solution.

>And once again a plea to ALWAYS make version/capabilities registers
> atleast an optional part of every design.
>Embeddeding a device tree into a design might be fairly expensive. a
> pair of read only 32 bit registers is damn near free - basically the
> FPGA equivalent of atmost 64 diodes or resistors.

Actually, device trees actually seem to be cheaper (in the whole system sense) 
than such registers.  Unless there is something I don't understand?

Steve
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: SPI, I2C

[Stephen Neuendorffer]

The drivers for these do exist (see git.xilinx.com).  I suppose as a 'control' 
bus, they might actually be useful inside an FPGA, but why not just use dcr?  
Part of the value of i2c is minimizing wires (including power wires), but 
that's hardly a design constraint in an FPGA compared to conserving logic. 

I also got fed up with the i2c core at one point and wrote a bitbang version 
for the gpio.  It might be a bit slower, but it's dirt simple.  I can send it 
do you, if you're interested.

Steve

-Original Message-
From: [EMAIL PROTECTED] on behalf of David H. Lynch Jr.
Sent: Sun 11/25/2007 1:44 AM
To: linuxppc-embedded
Subject: SPI, I2C
 

I have been asked to do SPI and I2C drivers for Pico cards.
   
I am trying to grasp what the practical use of either could be in an
environment where neither SPI nor I2C are going to be able to
communicate outside the FPGA.

I am guessing that SPI and I2C implementations already exist for
Xilinx FPGA's - any chance that drivers might already exist ?

I would prefer not to charge a client to reinvent something that
exists, or that can not serve a useful purpose.

I am not trying to imply that SPI or I2C are not useful, just that
they are communications channels, and unless  they have outside I2C or
SPI hardware to talk to what purpose might they serve ?



-- 
Dave Lynch  DLA Systems
Software Development:Embedded Linux
717.627.3770   [EMAIL PROTECTED]  http://www.dlasys.net
fax: 1.253.369.9244Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too 
numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a 
touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

___
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: Xilinx devicetrees

[Stephen Neuendorffer]

-Original Message-
From: David H. Lynch Jr. [mailto:[EMAIL PROTECTED]
Sent: Sun 11/25/2007 1:37 AM
To: Stephen Neuendorffer
Cc: Grant Likely; linuxppc-embedded
Subject: Re: Xilinx devicetrees
 
Stephen Neuendorffer wrote:
>
> -Original Message-
> From: [EMAIL PROTECTED] on behalf of Grant Likely
> Sent: Sat 11/24/2007 9:12 AM
> To: David H. Lynch Jr.
> Cc: linuxppc-embedded
> Subject: Re: Xilinx devicetrees
>  
> Regardless, I think I saw a post of yours on the microblaze list
> about exporting a devicetree list with the firmware.
> that is probably a better solution that what exists now.

I agree.. that's why I'm working on it. :)  But just to clarify: I don't work 
directly on Xilinx products, but more in advanced development.

> I am curious - with the firmware is not the same as in the firmware.
> But since you brought up deciphering firmware - to me and to Pico,
> and I gather to alot of others, providing indentity information within
> the firmware is a really really important issue - one which xilinx seems
> to be unable to make up its mind about.
> There are frequent posts addressing issues like this driver only
> works with this version of some IP - but there is no way to query the IP
> to enough detail to determine whether the driver will work. It is one
> thing to make version registers an option. It is entirely different to
> just omit them entirely or change the IP without changing the version.
> Our clients beat us up for things like that. DevieTrees do nto solve
> that problem.

I know these issues are high priorities within the EDK development group.  One 
advantage of device trees is that this information can be included without 
using any additional FPGA resources.

> Anyway, my .02 would be to put the device tree into the firmware. In
> a perfect world - litterally in the firmware so that when the firmware
> loads the device tree data is already in the FPGA somewhere that it can
> be easily ready - oh and do that without consuming many FPGA resources.
> But in a more likely realworld scenario - append the information to
> the .bit file in some fashion so that if can easily be found and passed on.

I've experimented with putting this information into BRAM.  Typically 
compressed device trees should easily fit within a single BRAM.  However, I 
think in most scenarios this is actually overkill.  Storing the device tree 
with the bitstream is probably good enough, and likely cheaper since the 
bitstream is likely in bulk storage.  This might be configuration flash (which 
is accessible after booting), SystemAce (in which case, the systemace image 
could load the device tree into a known location in memory).  In other systems 
the bitstream and the device tree might be combined into an executable file 
along with processor code for configuring the FPGA.  This might be used with an 
external processor or a partially reconfigured system.

>Binding it to a kernel, is a non-starter for us.

I agree that this is not the best way of leveraging the power of device trees.  
The point is that by using a device tree, you haven't lost anything you can do 
currently.  In the future we might have one kernel which supports all versions 
of all our IP, along with all flavors of microblaze and powerpc...  You would 
only ever need to recompile this kernel as a final optimization, if at all.

> I am tasked with getting one binary for each
> OS to work with nearly every device(hardware) we make including
> addressing options that change with firmware AND the whim of the user.
> But life might not be to unpleasant - it might even actually be
> better, if our kernel loader just extracted the devicetree from the end
> of the currently executing firmware.

Device trees are a data driven way of doing exactly this.

Steve

___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: Xilinx devicetrees

[Stephen Neuendorffer]

-Original Message-
From: [EMAIL PROTECTED] on behalf of Grant Likely
Sent: Sat 11/24/2007 9:12 AM
To: David H. Lynch Jr.
Cc: linuxppc-embedded
Subject: Re: Xilinx devicetrees
 
On 11/24/07, David H. Lynch Jr. <[EMAIL PROTECTED]> wrote:

>> I am having some difficulty grasping the significant advantages to
>> this.
>> If the firmware for a given target is not fairly static - and I load
>> different firmware depending on what I am doing all the time, then I
>> know have to manage both a bit file for the firmware, and a devicetree
>> file describing it to the kernel.

The device tree file is meta-information about your bitfile.  Think of it as 
'part of the firmware'.  In the (hopefully short) future, it won't even have to 
be managed, it will just be one of the things that is generated by the EDK flow.

> That being said, using the device tree does not preclude using
> platform code to setup devices *where it makes sense to do so*.  Many
> things are one-off board specific things that are not well described
> with the device tree.  For example, we've been debating how to handle
> on board sound which use common codec chips, but have custom wireup.
> The codec chip can use a common driver, but the wireup is handled with
> an ALSA 'fabric' driver that is pretty much a one-off for the board.
> It probably makes more sense for the fabric driver to be instantiated
> by the platform code rather than trying to do a full device tree
> representation.

Actually, even this is still driven by the device tree, because the platform 
code binds to the toplevel 'compatible' property...  It's just 'different' from 
a standard device driver.  

>>
>> What am  missing about devicetrees that would make me more
>> interested in them ?

You won't have to write a bunch of code that deciphers which fpga firmware you 
are running on..  That information will be found with the firmware and can be 
dealt with in a generic way.  If you already HAVE that code, you can keep using 
it, but maintaining that kind of code is probably not where you want to spend 
your time.

Steve
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: Newbie on embedded linux on PPC: error: cannot find boot.o

[Stephen Neuendorffer]

 
You can also build a ppc405 toolchain using Crosstool, and it works
fine..
http://kegel.com/crosstool

Steve

> -Original Message-
> From: 
> [EMAIL PROTECTED]
>  
> [mailto:[EMAIL PROTECTED]
labs.org] On Behalf Of Wolfgang Reissnegger
> Sent: Tuesday, September 04, 2007 2:33 PM
> To: Thomas Gerlach
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Newbie on embedded linux on PPC: error: cannot 
> find boot.o
> 
> Hi Thomas,
> 
> Xilinx is building the tools in the EDK to work with VxWorks 
> and for Standalone systems. In order to compile a Linux 
> kernel you need to get a toolchain from one of the Third 
> Party vendors, such as MontaVista. They have the correct 
> linker scripts for building a kernel.
> 
> Cheers,
>Wolfgang
> 
> Thomas Gerlach wrote:
> > hi folks,
> > 
> > 
> > my name is thomas trying to make embedded linux run on a 
> powerpc, but
> > we've got special boards here, although we use a xilinx virtex4
> > fpga...
> > 
> > as you said in the nabble-thread (see subject), i set up edk9.1
> > software platform settings und ran libgen to get the xparameters*
> > files. i copied those bsp files into the kernel tree (i use your
> > kernel linux-2.6-virtex from git.secretlabs.ca/git). after
> > configuring the kernel settigs, i try
> > 
> > $ make ARCH=ppc CROSS_COMPILE=powerpc-eabi-
> > 
> > what i get is the following output:
> > 
> >>   CHK include/linux/version.h
> >>   CHK include/linux/utsrelease.h
> >>   CALLscripts/checksyscalls.sh
> >>   CHK include/linux/compile.h
> >>   LD  init/mounts.o
> >> powerpc-eabi-ld: cannot find boot.o
> >> make[1]: *** [init/mounts.o] Error 1
> >> make: *** [init] Error 2
> > 
> > so, i searched for boot.o (it exists) and even copied it 
> into several
> > dirs of the linux kernel tree (where i thought i would make sense),
> > but the problem still remains.
> > 
> > googling results in
> > 
> > 
> http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&g
etPagePath=17462&BV_SessionID=1197140711.1188909240>
&BV_EngineID=cccgaddllgmfkflcefeceihdffhdfkf.0
> > 
> > 
> > and this, too, doesn't take me further in solving the problem.
> > 
> > i hope you can help me.
> > 
> > many thanks in advance,
> > 
> > kind regards
> > thomas gerlach
> > 
> > 
> > 
> > ___
> > 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
> 
> 

___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: Kernel Debug on Virtex4-FX

[Stephen Neuendorffer]

It believe it should work fine:
You just need to set breakpoints in the kernel proper 
using virtual memory addresses.
I've never actually tried tracing through the enabling of the MMU,
however...

Steve

> -Original Message-
> From: 
> [EMAIL PROTECTED]
>  
> [mailto:[EMAIL PROTECTED]
labs.org] On Behalf Of Robert Woodworth
> Sent: Thursday, September 06, 2007 11:33 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Kernel Debug on Virtex4-FX
> 
> Is it possible to debug the kernel via Xilinx JTAG Platform USB cable?
> 
> If so, how?
> I can debug through the embedded-config.c and boot loader, 
> but once the
> kernel boots, (VM on) I cannot debug anymore.  
> 
> 
> Or do I have to use kgdb through serial? 
> 
> 
> 
> 
> Rob.
> 
> 
> 
> ___
> 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: Xilinx Virtex boot (And MPMC)

[Stephen Neuendorffer]

The MPMC would almost certainly be a better option here...

Steve

> -Original Message-
> From: 
> [EMAIL PROTECTED]
>  
> [mailto:[EMAIL PROTECTED]
labs.org] On Behalf Of Robert Woodworth
> Sent: Thursday, August 30, 2007 7:45 AM
> To: Grant Likely
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Xilinx Virtex boot
> 
> On Wed, 2007-08-29 at 18:29 -0600, Grant Likely wrote:
> > On 8/29/07, Robert Woodworth <[EMAIL PROTECTED]> wrote:
> > > I'm trying to port Linux to a new Virtex Platform.  The 
> kernel will not
> > > uncompress, I get the following on the console:
> > >
> > > loaded at: 0040 004FB19C
> > > board data at: 004F9120 004F919C
> > > relocated to:  00404054 004040D0
> > > zimage at: 00404E50 004F8409
> > > avail ram: 004FC000 0400
> > >
> > > Linux/PPC load: console=ttyUL root=/dev/xsa2
> > > Uncompressing Linux...
> > > zlib_inflateInit2 returned 00506530
> > > exit
> > >
> > > Any ideas what causes this error??
> > > Is something mis-configured on my EDK project?
> > >
> > 
> > Possibly, do you know that EDK has your ram is configured correctly
> > (ie. have you run a memory test application)?
> 
> Yes, I ran the sample memory test application that EDK builds
> automatically.  It ran fine.
> 
> The fact that the above prints on the console, tells me that the
> zImage.elf is getting loaded at the correct start location 
> and that its
> partly executing.
> 
> What is the return code that I'm seeing??  I have been unable 
> to figure
> that out from the source yet.
> 
> 
> > >
> > > I have 64MB DDR on the OPB *not* the PLB.
> > > Is that a problem??
> > 
> > It shouldn't be the problem, but why are you doing that?
> 
> We are building an image-processing application inside the FPGA.  The
> application is very memory intensive.  I have been told that the PPC
> always has priority on the PLB and that if I want to have my 
> FPGA module
> have priority on memory, that I should place the memory and my FPGA
> module on the OPB.  Yes, this can significantly slow down the PPC, but
> in my case the PPC is only used for UI and networking.
> 
> I will actually build in *two* OPBs one for the memory + my module and
> the second for the other peripherals. 
> 
> 
> Woody.
> 
> ___
> 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: [PATCH 1/3] Add generic configuration option to enable all xilinx drivers.

[Stephen Neuendorffer]

 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Grant Likely
> Sent: Tuesday, August 21, 2007 8:28 PM
> To: Wolfgang Reissnegger
> Cc: linuxppc-embedded@ozlabs.org; Stephen Neuendorffer
> Subject: Re: [PATCH 1/3] Add generic configuration option to 
> enable all xilinx drivers.
> 
> On 8/21/07, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
> > From: Stephen Neuendorffer <[EMAIL PROTECTED]>
> >
> > In the future, this will be used to provide similar configuration
> > for PowerPC and Microblaze.
> 
> I'm not convinced that this change is worth it since there is only one
> in-tree driver that uses it.  I'd maintain it separately in your tree
> until other drivers or the microblaze stuff is ready for merging.

I have at least one more driver that will use it, for the ICAP, and
joachim's AC97 driver should use it too.

In any event, my intention with all of this is to start small to figure
out how
to do it...  Plus I think it will be much easier to manage our tree if
basic
changes like this are merged long before arch/microblaze.

Steve 


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: Xilinx Virtex4 FX PPC

[Stephen Neuendorffer]

Note that you should pick one or the other and be consistent.

If you have MATH_EMULATION
in the kernel and use code compiled partly with and partly without
soft-fp,
then you get really strange errors, because (I believe) the soft-fp uses
a different mechanism for emulating the floating point register files
than
the kernel  (I suppose you'll also see the same thing in a system with
floating
point unit and a mixed-up compilation as well).

Steve

> -Original Message-
> From: 
> [EMAIL PROTECTED]
>  
> [mailto:[EMAIL PROTECTED]
labs.org] On Behalf Of Robert Woodworth
> Sent: Monday, August 20, 2007 10:27 AM
> To: Josh Boyer
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Xilinx Virtex4 FX PPC
> 
> On Mon, 2007-08-20 at 11:35 -0500, Josh Boyer wrote:
> > On Mon, 20 Aug 2007 10:00:54 -0600
> > Robert Woodworth <[EMAIL PROTECTED]> wrote:
> > 
> > > Problem 2:  Build my own rootfs.
> > > If I try to build my own programs (busybox and bash at 
> this point) with
> > > shared libc using the same glibc from my toolchain, I get 
> an "Illegal
> > > instruction" error.  Is my glibc not compatible with my 
> Xilinx PPC 405??
> > > 
> > > 
> > > If I try to build a rootfs with debian ppc packages I 
> have the same
> > > "Illegal instruction" error.
> > > 
> > > 
> > > 
> > > Question 1:
> > > Do I need a special glibc for the Xilinx PPC 405  
> > > Does a normal PPC glibc have more "advanced" instructions 
> compiled in
> > > that will not work on a Xilinx PPC 405??
> > 
> > Make sure you're building glibc with soft-fp, or make sure you have
> > CONFIG_MATH_EMULATION enabled in your kernel.  The PPC 405 
> doesn't have
> > an FPU.
> > 
> > josh
> 
> 
> CONFIG_MATH_EMULATION fixed it!!
> 
> 
> 
> What are the opinions out there? 
> Kernel fp or glibc soft-fp??
> 
> I don't have a need for floating point in my final application anyway.
> 
> ___
> 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: Device Tree tool [was RE: [PATCH] Consolidate XILINX_VIRTEXboardsupport]

[Stephen Neuendorffer]

I don't have an EDK script.  I'm currently using a hacked version of 
Grant's gen_mhs_devtree.py script, and then I modified the resulting
device
tree in an effort to get things working.  In the long term, I think
having
an EDK script will be necessary to ensure that all of the information is
in the device tree.

Michal: what do you need from me?

Steve

> -Original Message-
> From: Michal Simek [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, August 14, 2007 11:42 PM
> To: Stephen Neuendorffer
> Cc: Grant Likely; [EMAIL PROTECTED]; 
> linuxppc-embedded@ozlabs.org
> Subject: RE: Device Tree tool [was RE: [PATCH] Consolidate 
> XILINX_VIRTEXboardsupport]
> 
> Hi,
> 
> >I've managed to get the first step working: a microblaze system
> >advertising of_devices in 2.6 using a flat device tree.  
> 
> It's great news.
> 
> >Is there a concensus on how microblaze systems should get booted?
> >Currently,
> >I'm linking the device tree directly into the kernel itself, 
> loading the
> >whole
> >mess using SystemAce and the start address jumps directly into the
> >kernel, which
> >is quite a bit different than the way powerpc works.  It's certainly
> >simpler:
> >maybe too simple.  At the same time, replicating
> >the complexity of arch/powerpc with separate boot code may 
> or may not be
> >worth it...
> >Any thoughts?
> 
> Microblaze can be boot via U-BOOT. U-BOOT supports FDT for 
> some PowerPC boards.
> I would like to help with this part of bootloader code. 
> 
> Do you have any EDK script for generation FDT? 
> 
> Best regards,
> Michal Simek
> 
> 

___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: Device Tree tool [was RE: [PATCH] Consolidate XILINX_VIRTEXboardsupport]

[Stephen Neuendorffer]

> BTW: I'm currently hacking away to see if I can get a 
> microblaze system
> booting
> using a flat device tree...  I haven't decided if it's worth it to go
> that
> route in the end yet, but...
> 
> Steve

I've managed to get the first step working: a microblaze system
advertising of_devices in 2.6 using a flat device tree.  The next task
is to
reimplement probe() for a driver or two (probably the xilinx_emac driver
first).   My plan is to have the driver advertise both through
of_platform_bus, and
through the regular platform bus, and have a config option that either
advertises
the devices through of and links in the device tree, or using the
exising
platform_device mechanism.

Grant:  Does this make sense (in terms of dealing with drivers) with
your plans for
moving Virtex platforms to arch/powerpc?  I'd like to avoid duplicating
work on the
drivers, if possible.

Is there a concensus on how microblaze systems should get booted?
Currently,
I'm linking the device tree directly into the kernel itself, loading the
whole
mess using SystemAce and the start address jumps directly into the
kernel, which
is quite a bit different than the way powerpc works.  It's certainly
simpler:
maybe too simple.  At the same time, replicating
the complexity of arch/powerpc with separate boot code may or may not be
worth it...
Any thoughts?

Steve




___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: Device Tree tool [was RE: [PATCH] Consolidate XILINX_VIRTEX boardsupport]

[Stephen Neuendorffer]

The main thing that Grant's script lacks is the ability to pull in
default
parameters that aren't listed in the MPD for a core, but not in the MHS
file...
I think the only way to easily solve that is to live within EDK's bsp
generation, unfortunately...

BTW: I'm currently hacking away to see if I can get a microblaze system
booting
using a flat device tree...  I haven't decided if it's worth it to go
that
route in the end yet, but...

Steve

> -Original Message-
> From: 
> [EMAIL PROTECTED]
>  
> [mailto:[EMAIL PROTECTED]
labs.org] On Behalf Of Grant Likely
> Sent: Friday, August 10, 2007 6:48 AM
> To: Koss, Mike (Mission Systems)
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Device Tree tool [was RE: [PATCH] Consolidate 
> XILINX_VIRTEX boardsupport]
> 
> On 8/10/07, Koss, Mike (Mission Systems) <[EMAIL PROTECTED]> wrote:
> >
> > <>
> > > > > diff --git a/arch/ppc/platforms/4xx/xparameters/xparameters.h
> > > > > b/arch/ppc/platforms/4xx/xparameters/xparameters.h
> > > > > index 01aa043..34d9844 100644
> > > > > --- a/arch/ppc/platforms/4xx/xparameters/xparameters.h
> > > > > +++ b/arch/ppc/platforms/4xx/xparameters/xparameters.h
> > > > > @@ -15,8 +15,12 @@
> > > > >
> > > > > #if defined(CONFIG_XILINX_ML300)
> > > > > #include "xparameters_ml300.h"
> > > > > +#elif defined(CONFIG_XILINX_XUPV2P)  #include
> > > > > +"xparameters_xupv2p.h"
> > > > > #elif defined(CONFIG_XILINX_ML403)
> > > > > #include "xparameters_ml403.h"
> > > > > +#elif defined(CONFIG_XILINX_ML41x)
> > > > > + #include "xparameters_ml41x.h"
> > > > > #else
> > > > > /* Add other board xparameter includes here before 
> the #else */
> > > > > #error No xparameters_*.h file included
> > > >
> > > > see comment above.
> >
> > > This whole xparams stuff is a special case; but it is 
> going away for
> > arch/powerpc.  xparameters.h is generated by the xilinx EDK 
> tool and it
> > is painful to work with in the Linux context.  For 
> arch/powerpc, I've
> > got a tool that generates a device tree from the FPGA 
> hardware design.
> >
> > What is the tool that you are using and are you willing to 
> share it at
> > this point? I'm currently working on some code to generate platform
> > files for our internal drivers and the ll_temac vs using the ugle
> > xparam's file. I'd like to not duplicate, or actually 
> assist, any effort
> > in this area.
> 
> It's on my git tree; http://git.secretlab.ca
> 
> I've also got some feedback from the Xilinx folks in the form of a
> patch, but I haven't integrated it yet.  Pretty experimental stuff,
> I'll probably end up rewriting it from scratch before it's done.
> 
> Cheers,
> g.
> 
> >
> > -- Mike Koss
> >
> >
> 
> 
> -- 
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> [EMAIL PROTECTED]
> (403) 399-0195
> ___
> 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: [PATCH 1/2] Xlinx ML403 AC97 Controller Reference device driver

[Stephen Neuendorffer]

 
I second grant here... this should eventually work on microblaze, too,
so putting it drivers/ and using XILINX_DRIVERS instead of XILINX_VIRTEX
(based on the patch Wolfgang recently posted) would probably be preferable.

> +
> +config SND_ML403_AC97CR
> +   tristate "Xilinx ML403 AC97 Controller Reference"
> +   depends on SND && XILINX_VIRTEX

Steve

___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: [PATCH] Consolidate XILINX_VIRTEX board support

[Stephen Neuendorffer]

> On Tuesday 07 August 2007, Wolfgang Reissnegger wrote:
> > 
> > Make support for Xilinx boards more generic, making it easier
> > to add new boards.  Add initial support for xupv2p and ml410 boards.
> 
> I really think we shouldn't add stuff to arch/ppc at this point,
> it has been deprecated for over two years now.

This is a good point...  In fact the other patch (although tiny) is
more important, since it affects drivers, which should work in
arch/powerpc.  Thanks for the feedback anyway!

On this topic: has anyone tried using the recent Walnut patches for
arch/powerpc?   I briefly took a look at starting to port the Virtex
support to arch/powerpc but I'm a bit lost as to where to start... :)

Steve

___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: [PATCH] Generic configuration selector for Xilinx devices

[Stephen Neuendorffer]

Please consider these a 'first experiment' in generating patches.. :)
Sorry the XILINX_DRIVERS patch took so long, but hopefully things should
be easier after getting the first patch out...

Feedback (especially WRT the structure of the patches and the process
of generating them) is greatly welcome...

Steve

> -Original Message-
> From: 
> [EMAIL PROTECTED]
>  
> [mailto:[EMAIL PROTECTED]
labs.org] On Behalf Of Wolfgang Reissnegger
> Sent: Monday, August 06, 2007 3:55 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: [PATCH] Generic configuration selector for Xilinx devices
> 
> This is intended to make visible all device driver options for
> both powerpc and microblaze systems.
> 
> Thanks,
>Wolfgang
> 

___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: a question for linux framebuffer driver

[Stephen Neuendorffer]

The kernel has to be informed of the device itself using 
platform_device_register.
I believe in the kernel you have you'll have to add code to do this, and 
/arch/ppc/platforms/4xx/virtex.c is a reasonable place. 

Steve

> -Original Message-
> From: 
> [EMAIL PROTECTED]
>  
> [mailto:[EMAIL PROTECTED]
> labs.org] On Behalf Of silicom
> Sent: Saturday, June 09, 2007 5:22 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: a question for linux framebuffer driver
> 
> Hello,
> Now I'm porting framebuffer driver for ml403 in linux 
> 2.6.171, but I find after registering the driver using 
> driver_register function in xilinxfb_int, the 
> xilinxfb_drv_probe function has not been called, so 
> framebuffer not registered yet, no devices founded(but I have 
> connected the monitor). I want to know when will 
> xilinxfb_drv_probe be called?
> 
>  
>  
>  
> 
> 
> 
> 
> 150 万 人 同 时 在 玩 的 网 游，你 不 试 试 吗 ？ 
>  
> 

___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: [PATCH] Simple driver for Xilinx SPI controler.

[Stephen Neuendorffer]

> > config XILINX_EDK
> > bool
> > depends on XILINX_VIRTEX || XILINX_MICROBLAZE
> > default y
> 
> I don't have any problem with adding XILINX_EDK (or 
> whatever), but think particular layout is back-assward.  
> Rather than XILINX_EDK depending on XILINX_VIRTEX/MICROBLAZE, 
> XILINX_VIRTEX/MICROBLAZE should 'select' XILINX_EDK and you 
> need to drop the 'default y' line.
> Otherwise the XILINX_EDK option shows up in non-edk config files.

Good point...
 
> Why still have XILINX_EDK?  I thought you meant replace 
> XILINX_EDK with XILINX_DRIVERS.

Yes, that's what I was suggesting.
But I think that Andrei still wants to use XILINX_EDK to pull in the
stuff in drivers/xilinx_common.

# The Xilinx OS common code 
obj-$(CONFIG_XILINX_EDK) += xbasic_types.o xpacket_fifo_l_v2_00_a.o \
xpacket_fifo_v2_00_a.o xversion.o \
xdma_channel.o xdma_channel_sg.o

Which you wouldn't want if you were able to build a kernel completely
from 'non-edk' drivers.

Steve


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: [PATCH] Simple driver for Xilinx SPI controler.

[Stephen Neuendorffer]

Yes, except that microblazes systems run in non-virtex FPGAs...

It may be that XILINX_EDK is not the right thing either, but it
seemed like the easiest way to have a superset of powerpc and microblaze
systems

What I'm trying to do is (in concert with Grant's recent configuration
changes)
having an easy way for a new board configuration to select the Kconfig
options for
all of the Xilinx drivers.  Namely:

config XILINX_ML300
bool "Xilinx-ML300"
select XILINX_VIRTEX_II_PRO
select EMBEDDEDBOOT
help
  This option enables support for the Xilinx ML300 evaluation
board.

config XILINX_VIRTEX_II_PRO
bool
select XILINX_VIRTEX

config XILINX_EDK
bool
depends on XILINX_VIRTEX || XILINX_MICROBLAZE
default y

config XILINX_GPIO
tristate "Xilinx OPB GPIO Support"
depends on XILINX_EDK
help
This option enables support for Xilinx GPIO.


It seems like I'm using XILINX_EDK to mean something different than you
are.
Perhaps it sould be instead:

config XILINX_DRIVERS
bool
depends on XILINX_VIRTEX || XILINX_MICROBLAZE
default y

config XILINX_GPIO_EDK
tristate "Xilinx EDK-based OPB GPIO Support"
depends on XILINX_DRIVERS
select XILINX_EDK
help
This option enables support for Xilinx GPIO using EDK OS
independent driver.

config XILINX_GPIO
tristate "Xilinx OPB GPIO Support"
depends on XILINX_DRIVERS
help
This option enables support for Xilinx GPIO.

Would this work for you?

Steve

> -Original Message-
> From: Andrei Konovalov [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, June 06, 2007 10:58 AM
> To: Stephen Neuendorffer
> Cc: [EMAIL PROTECTED]; 
> linuxppc-embedded@ozlabs.org; Wolfgang Reissnegger
> Subject: Re: [PATCH] Simple driver for Xilinx SPI controler.
> 
> Hi Steve,
> 
> Stephen Neuendorffer wrote:
> > In order to anticipate future Microblaze support with most of these 
> > drivers, we've been moving towards having all of the Kconfig 
> > dependencies on XILINX_EDK,
> 
> There is no XILINX_EDK in the ko tree.
> 
> > rather than XILINX_VIRTEX...
> 
> Using XILINX_VIRTEX seems to be a common thing:
> 
> >  Original Message 
> > Subject: [RFC] Xilinx SystemACE device driver
> > Date: Sat, 14 Apr 2007 19:23:14 -0600
> > From: Grant Likely <[EMAIL PROTECTED]>
> > To: linuxppc-embedded@ozlabs.org, Andrei Konovalov 
> <[EMAIL PROTECTED]>,  Peter Korsgaard 
> <[EMAIL PROTECTED]>,  Rick Moleres <[EMAIL PROTECTED]>, 
> Stefan Roese <[EMAIL PROTECTED]>
> > 
> > Add support for block device access to the Xilinx SystemACE Compact 
> > flash interface
> 
> > diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig index 
> > 17ee97f..08ad23c 100644
> > --- a/drivers/block/Kconfig
> > +++ b/drivers/block/Kconfig
> > @@ -453,6 +453,12 @@ config ATA_OVER_ETH
> > This driver provides Support for ATA over Ethernet block
> > devices like the Coraid EtherDrive (R) Storage Blade.
> >  
> > +config XILINX_SYSACE
> > +   tristate "Xilinx SystemACE support"
> > +   depends on XILINX_VIRTEX
> > +   help
> > + Include support for the Xilinx SystemACE CompactFlash 
> interface
> > +
> 
> BTW the SystemACE has been successfully tested with ppc440 
> based board. So XILINX_VIRTEX doesn't imply ppc405.
> 
> On the other side,
> UART Lite driver (in the ko tree) doesn't depend on both 
> XILINX_EDK and XILINX_VIRTEX
> 
> Couldn't Microblaze port use XILINX_VIRTEX too?
> IMHO XILINX_VIRTEX is more general name for something inside 
> the Virtex chip (ppc405 core, Microblaze softcore, IP blocks 
> from EDK or elsewhere).
> 
> I've recently added XILINX_EDK to linux-xilinx-26.git 
> repository at source.mvista.com, but to include the level 1 
> drivers (aka OS independent drivers) from EDK. Haven't 
> planned to use XILINX_EDK for drivers not using EDK code.
> Here is the relevant snippet from 
> arch/ppc/platforms/4xx/Kconfig (from linux-xilinx-26.git @ 
> source.mvista.com, ko doesn't have XILINX_EDK and the rest below):
> 
> ===8<=
> config XILINX_VIRTEX_II_PRO
>   bool
>   select XILINX_VIRTEX
> 
> config XILINX_VIRTEX_4_FX
>   bool
>   select XILINX_VIRTEX
> 
> config XILINX_VIRTEX
>   bool
> 
> # The options selected by EDK based drivers. Not visible from 
> [menu]config.
> config XILINX_EDK
>   bool
> config XILINX_IPIF_V123B
>   bool
> config XILINX_FIFO_V200A
>   bool
> config XILINX_DMA_V300A
>   bool
> ===8<=
> 
> If we do something like
>config XILINX_MICROBLAZE
>   bool
>   select XILINX_VIRTEX
> in arch/microblaze/Kconfig
> would it work?
> 
> 
> Thanks,
> Andrei
> 
> 
> 

___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: [PATCH] Simple driver for Xilinx SPI controler.

[Stephen Neuendorffer]

In order to anticipate future Microblaze support with most of these
drivers,
we've been moving towards having all of the Kconfig dependencies on
XILINX_EDK,
rather than XILINX_VIRTEX...

Steve Neuendorffer

> -Original Message-
> From: 
> [EMAIL PROTECTED]
>  
> [mailto:[EMAIL PROTECTED]
labs.org] On Behalf Of Andrei Konovalov
> Sent: Wednesday, June 06, 2007 7:06 AM
> To: [EMAIL PROTECTED]
> Cc: linuxppc-embedded@ozlabs.org
> Subject: [PATCH] Simple driver for Xilinx SPI controler.
> 
> +config SPI_XILINX
> + tristate "Xilinx SPI controller"
> + depends on SPI_MASTER && XILINX_VIRTEX && EXPERIMENTAL
> + select SPI_BITBANG
> + help
> +   This enables using the SPI controller IP from Xilinx 
> EDK in master
> +   mode. See the DS464, "OPB Serial Peripheral Interface 
> (SPI) (v1.00e)"
> +   Product Specification document for the hardware details.
>   #
>   # Add new SPI master controllers in alphabetical order 
> above this line
>   #
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile 
> index 5788d86..a2412bd 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -23,6 +23,7 @@ obj-$(CONFIG_SPI_MPC52xx_PSC)   
> += mpc52xx_psc_spi.o
>   obj-$(CONFIG_SPI_MPC83xx)   += spi_mpc83xx.o
>   obj-$(CONFIG_SPI_S3C24XX_GPIO)  += spi_s3c24xx_gpio.o
>   obj-$(CONFIG_SPI_S3C24XX)   += spi_s3c24xx.o
> +obj-$(CONFIG_SPI_XILINX) += xilinx_spi.o
>   #   ... add above this line ...
> 
>   # SPI protocol drivers (device/link on bus) diff --git 
> a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c new 
> file mode 100644 index 000..e5f149f
> --- /dev/null
> +++ b/drivers/spi/xilinx_spi.c
> @@ -0,0 +1,447 @@
> +/*
> + * xilinx_spi.c
> + *
> + * Xilinx SPI controler driver (master mode only)
> + *
> + * Author: MontaVista Software, Inc.
> + * [EMAIL PROTECTED]
> + *
> + * 2002-2007 (c) MontaVista Software, Inc.  This file is 
> licensed under 
> +the
> + * terms of the GNU General Public License version 2.  This 
> program is 
> +licensed
> + * "as is" without any warranty of any kind, whether express 
> or implied.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#define XILINX_SPI_NAME "xspi"
> +
> +/* Register definitions as per "OPB Serial Peripheral 
> Interface (SPI) 
> +(v1.00e)
> + * Product Specification", DS464
> + */
> +#define XSPI_CR_OFFSET   0x62/* 16-bit 
> Control Register */
> +
> +#define XSPI_CR_ENABLE   0x02
> +#define XSPI_CR_MASTER_MODE  0x04
> +#define XSPI_CR_CPOL 0x08
> +#define XSPI_CR_CPHA 0x10
> +#define XSPI_CR_MODE_MASK(XSPI_CR_CPHA | XSPI_CR_CPOL)
> +#define XSPI_CR_TXFIFO_RESET 0x20
> +#define XSPI_CR_RXFIFO_RESET 0x40
> +#define XSPI_CR_MANUAL_SSELECT   0x80
> +#define XSPI_CR_TRANS_INHIBIT0x100
> +
> +#define XSPI_SR_OFFSET   0x67/* 8-bit Status 
> Register */
> +
> +#define XSPI_SR_RX_EMPTY_MASK0x01/* Receive FIFO 
> is empty */
> +#define XSPI_SR_RX_FULL_MASK 0x02/* Receive FIFO is full */
> +#define XSPI_SR_TX_EMPTY_MASK0x04/* Transmit 
> FIFO is empty */
> +#define XSPI_SR_TX_FULL_MASK 0x08/* Transmit FIFO is full */
> +#define XSPI_SR_MODE_FAULT_MASK  0x10/* Mode fault error */
> +
> +#define XSPI_TXD_OFFSET  0x6b/* 8-bit Data 
> Transmit Register */
> +#define XSPI_RXD_OFFSET  0x6f/* 8-bit Data 
> Receive Register */
> +
> +#define XSPI_SSR_OFFSET  0x70/* 32-bit Slave 
> Select Register */
> +
> +/* Register definitions as per "OPB IPIF (v3.01c) Product 
> +Specification", DS414
> + * IPIF registers are 32 bit
> + */
> +#define XIPIF_V123B_DGIER_OFFSET 0x1c/* IPIF global 
> int enable reg */
> +#define XIPIF_V123B_GINTR_ENABLE 0x8000
> +
> +#define XIPIF_V123B_IISR_OFFSET  0x20/* IPIF 
> interrupt status reg */
> +#define XIPIF_V123B_IIER_OFFSET  0x28/* IPIF 
> interrupt enable reg */
> +
> +#define XSPI_INTR_MODE_FAULT 0x01/* Mode fault error */
> +#define XSPI_INTR_SLAVE_MODE_FAULT   0x02/* Selected as 
> slave while
> +* disabled */
> +#define XSPI_INTR_TX_EMPTY   0x04/* TxFIFO is empty */
> +#define XSPI_INTR_TX_UNDERRUN0x08/* 
> TxFIFO was underrun */
> +#define XSPI_INTR_RX_FULL0x10/* RxFIFO is full */
> +#define XSPI_INTR_RX_OVERRUN 0x20/* RxFIFO was overrun */
> +
> +#define XIPIF_V123B_RESETR_OFFSET0x40/* IPIF reset 
> register */
> +#define XIPIF_V123B_RESET_MASK   0x0a/* the 
> value to write */
> +
> +/* Simple macros to get the code more readable */
> +#define xspi_in16(addr)  in_be16((u16 __iomem *)(addr))
> +#define xspi_in32(addr)  in_be32((u32 __iomem *)(addr))
> +#define xspi_out16(addr, value)

RE: Audio Dirver for the 403/405?

[Stephen Neuendorffer]

There is an opb core developed for the Xilinx University Program board,
which
has a similar hardware interface to the ML403 (i.e. no PCI bridge)
The XUPV2P web page with the opb_ac97 core is here:
http://www.xilinx.com/univ/xupv2p.html 

I have a /dev/dsp driver (which I'll send to Bert directly) which limps
along in 2.6.
This core has a relatively small buffer and no master access to memory,
which
results in relatively poor performance, but it is a starting point.

Steve

> -Original Message-
> From: 
> [EMAIL PROTECTED]
>  
> [mailto:[EMAIL PROTECTED]
labs.org] On Behalf Of bert_maxel
> Sent: Thursday, May 31, 2007 12:10 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: Re: Audio Dirver for the 403/405?
> 
> 
> 
> 
> Grant Likely-2 wrote:
> > 
> > On 5/30/07, bert_maxel <[EMAIL PROTECTED]> wrote:
> >>
> >> Hi all,
> >>
> >> Has anybody got some working audio driver (linux) for the  
> ML403/405 ?
> >> I know it's an ac97 codec, but I can't find anything 
> related to the 
> >> xilinx boards?
> >> If nobody has worked on this yet, I'm in trouble. I don't 
> know where 
> >> to start, or from what ac97 driver should I base my 
> initial development?
> > 
> > IIRC, the old mvista 2.4 tree has an audio driver.
> > 
> > g.
> > 
> > --
> > Grant Likely, B.Sc., P.Eng.
> > Secret Lab Technologies Ltd.
> > [EMAIL PROTECTED]
> > (403) 399-0195
> > ___
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> > 
> > 
> 
> There are plenty of boards with an ac97 codec, but what's 
> missing is the glue for the ML403 board, there's no pci bus 
> in this case,  opb cores instead.
> I hope somebody can point me to a link of interest.
> 
> thanks
> --
> View this message in context: 
> http://www.nabble.com/Audio-Dirver-for-the-403-405--tf3843165.
html#a10900170
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
> 
> ___
> 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