Re: Linux on ML403 serial console problem
fidential and > intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its > affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily > reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of > this message without the prior written consent of the author of this > e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender > immediately. Before opening any mail and > attachments please check them for viruses and defect. > > --- > > > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded John Bonesio Commercial Linux Solutions [EMAIL PROTECTED] (408) 879-5569 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: APU FPU in Virtex ppc405
My understanding is that with the fpu on the ppc405 (not ppc440), the processor clock rate had to be reduced for the fpu to work. This ended up negating much of the performance benefits of using the fpu. I don't know the specifics offhand, but Xilinx answer records can be searched. Hopefully I'm wrong, and there can still be a benefit to using the ppc405 fpu. - John On Thu, 2008-05-22 at 19:06 -0400, David H. Lynch Jr. wrote: >Were the issues associated with getting the Xilinx Floating point APU > working with Linux completely resolved ? > Is there a git tree or patch collection with the appropriate patches > etc ? > > > ________ John Bonesio Commercial Linux Solutions [EMAIL PROTECTED] (408) 879-5569 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: XLlTemac soft lockup BUG
Hi Kevin, When the system locks up, does it get stuck in the FifoRecvHandler() routine? How many bytes are returned from XLlFifo_RxGetLen(&lp->Fifo) in that routine? You can try calling XLlFifo_Reset(&lp->Fifo); to see if that clears the fifo. Though, I suspect that this wont fix the root cause of the problem you're seeing. - John On Wed, 2008-04-23 at 11:09 -0700, khollan wrote: > Hi, > > I have done some more digging and it seems like whenever the system works > the command XLlFifo_IsRxEmpty(&lp->Fifo)) returns a 1 meaning that the > RxFifo is empty. I stuck this test in the xenet_open function right before > the fifo interupt gets enabled. > > When ever this test comes back as 0 the ifconfig will get into the soft > lockup I described above. > > Is there a function that empties out the fifo, I tried XLlFifo_RxReset but > that doesn't seem to work. > > Thanks > > Kevin ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: XLlTemac soft lockup BUG
Hi Kevin,
Does xlltemac_main.c have
#define MARVELL_88E_PHY
in it? If not, try setting that.
It's odd that sometimes it works. Does your system meet timing?
We've found that when the PHY is being poked, it can take a while before the
PHY settles down and starts working. If the code tries to start using the PHY
too soon, then the PHY never seems to get to a good state. So, you might
experiement with different values in the udelay() call in
_XLlTemac_SetOperatingSpeed().
If you really think there's something wrong in the fifo code, you can enable
debug (#define DEBUG) in the following files:
drivers/xilinx_common/xdebug.h
drivers/xilinx_common/xstreamer.h
Perhaps that will shed some light on the problem.
- John
On Wednesday 16 April 2008 15:08, khollan wrote:
>
> Hugo Villeneuve-3 wrote:
> >
> > Hi,
> > we had a similar error message, which was caused by us selecting the wrong
> > PHY type in the kernel configuration menu (latest linux-2.6-xlnx-git
> > tree). In fact, we had to modify the lltemac driver to support our PHY
> > (BCM5466). Once we did that, the error message went away.
> >
> > Hugo V.
> >
> I tried out all 3 configurations and it didn't seem to help. We are using
> the Marvell Phy on our prototype. The weird thing is it seems to work
> perfectly every once in awhile, but not very often. I seem to have tracked
> the problem to the FifoRecvHandler tasklet function in xlltemac_main.c it
> gets stuck in this while loop:
> while (XLlFifo_RxOccupancy(&lp->Fifo) != 0) {
> the XLlFifo_RxOccupancy always reads the same value.
> Any ideas?
>
> Thanks
> Kevin
> --
> View this message in context:
> http://www.nabble.com/XLlTemac--soft-lockup-BUG-tp16711066p16734685.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
Hi Shan, It's not clear what you're trying to do. If you have only one application using the FPU, and you're setting up the APU and FPU from that user application, I'm not sure if you need the FPU unavailable handler. If you're going to have multiple applications use the FPU, then you should use the FPU unavailable handler. In this case, you'll need to look in head_44x.S to see how the FPU unavailable handler is set up, and do something similar in head_4xx.S If you're going to do all FPU from one user application, you just need to make sure the kernel doesn't ever clear the FP Available bit in the MSR. Is this making sense? model #1: One user app owns/uses FPU: Use Yoshio's suggesting on getting access to the MSR to setup the fpu from the user application. Don't use FPU unavailable handler, Don't use load_up_fpu(). Check kernel code to make sure it doesn't clear FPU available bit on a context switch. model #2: Kernel owns FPU, user apps use FPU: Set up the MSR for fpu access in kernel startup code. Set up FPU unavailable handler in kernel. Use load_up_fpu(). Make sure the kernel clears the FPU available bit in the MSR on context switches. Hope this helps, - John On Tuesday 15 April 2008 11:47, Shanyuan Gao wrote: > No, actually I am using head_4xx.S and I cannot find FPU_UNAVAILABLE > in there. Do I need to set it? > > And I commented out the _GLOBAL(giveup_fpu) in head_4xx.S because it > has conflicts with fpu.S > > > > Shan > > > On Apr 15, 2008, at 2:37 PM, Stephen Neuendorffer wrote: > > > 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]�
Re: Problems of using APU/FPU under linux
Hi Shan, Someone here reminded me that the ppc405 is not BookE. One of your problems maybe in getting the kernel to set up an FPU unavilable handler. - John On Monday 14 April 2008 13:46, Shanyuan Gao wrote: > 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 > > orir10, 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 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 does
Re: Problems of using APU/FPU under linux
Hi Shan, It's not clear exactly what you are experiencing. What do you see in your user application, "Illegal instruction" ? In arch/powerpc/kernel/head_booke.h, there's #define FP_UNAVAILABLE_EXCEPTION. This defines the FPU unavailable exception. Is the code getting there? You should see the call to load_up_fpu in there, which is defined in arch/powerpc/kernel/fpu.S What exception is being generated? It looks like you're getting SIGTRAP in your application which is the debug exception, which doesn't seem related to how the kernel sets up the fpu. I believe the 2 bits you mentioned just have to do with with how the fpu behaves. The kernel code doesn't use those for the fpu context switching. It uses the Floating-Point Available bit in the MSR. Definitely check the errata and other information about the FPU you are using. As Steve mentioned, you should use the Xilinx gcc tools with the Xilinx FPU. - John On Monday 14 April 2008 13:46, Shanyuan Gao wrote: > 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 > > orir10, 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 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 > >
Re: Problems of using APU/FPU under linux
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 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: Xilinx LLTEMAC driver issues
The change with the extra parenthesis (in the patch starting with line 133)
seems unecessary. I looked at the XLlDma_mBdWrite macro and it appeared to have
the correct use of parethesis in the implementation.
So, assuming there's nothing subtle that I missed, it's not needed. However, it
does no harm either.
The rest of the patch seems fine.
- John
On Wednesday 02 April 2008 00:20, Johann Baudy wrote:
> I've solved this checksum offloading issue with this below patch.
> It may help, if you need performance. It certainly needs review but it works
> on my side.
>
> --- xilinxgit/drivers/net/xilinx_lltemac/xlltemac_main.c.orig2008-03-21
> 09:11:43.0 +0100
> +++ xilinxgit/drivers/net/xilinx_lltemac/xlltemac_main.c2008-03-21
> 09:24:23.0 +0100
> @@ -133,7 +133,7 @@
> (XLlDma_mBdRead((BdPtr), XLLDMA_BD_STSCTRL_USR0_OFFSET)) &
> 0xFFFE )
>
> #define BdCsumSetup(BdPtr, Start, Insert) \
> -XLlDma_mBdWrite((BdPtr), XLLDMA_BD_USR1_OFFSET, (Start) << 16 |
> (Insert))
> +XLlDma_mBdWrite((BdPtr), XLLDMA_BD_USR1_OFFSET, ((Start) << 16) |
> (Insert))
>
> /* Used for debugging */
> #define BdCsumInsert(BdPtr) \
> @@ -1540,7 +1541,7 @@ static int xenet_DmaSend_internal(struct
> /*
> * if tx checksum offloading is enabled, when the ethernet stack
> * wants us to perform the checksum in hardware,
> - * skb->ip_summed is CHECKSUM_COMPLETE. Otherwise skb->ip_summed is
> + * skb->ip_summed is CHECKSUM_PARTIAL. Otherwise skb->ip_summed is
> * CHECKSUM_NONE, meaning the checksum is already done, or
> * CHECKSUM_UNNECESSARY, meaning checksumming is turned off (e.g.
> * loopback interface)
> @@ -1565,9 +1566,11 @@ static int xenet_DmaSend_internal(struct
> * skb_transport_header(skb) points to the beginning of the ip header
> *
> */
> -if (skb->ip_summed == CHECKSUM_COMPLETE) {
> +if (skb->ip_summed == CHECKSUM_PARTIAL) {
> +
> +unsigned int csum_start_off = skb_transport_offset(skb);
> +unsigned int csum_index_off = csum_start_off + skb->csum_offset;
>
> -unsigned char *raw = skb_transport_header(skb);
> #if 0
> {
> unsigned int csum = _xenet_tx_csum(skb);
> @@ -1578,9 +1581,8 @@ static int xenet_DmaSend_internal(struct
> }
> #else
> BdCsumEnable(bd_ptr);
> -BdCsumSetup(bd_ptr, raw - skb->data,
> -(raw - skb->data) + skb->csum);
> -
> +BdCsumSetup(bd_ptr, csum_start_off,
> +csum_index_off);
> #endif
> lp->tx_hw_csums++;
> }
> @@ -3277,7 +3279,7 @@ static int __devinit xtenet_of_probe(str
> struct resource *r_irq = &r_irq_struct;/* Interrupt resources */
> struct resource *r_mem = &r_mem_struct;/* IO mem resources */
> struct xlltemac_platform_data *pdata = &pdata_struct;
> -void *mac_address;
> +const void *mac_address;
> int rc = 0;
> const phandle *llink_connected_handle;
> struct device_node *llink_connected_node;
>
>
> On Mon, Mar 31, 2008 at 11:10 AM, Magnus Hjorth <[EMAIL PROTECTED]> wrote:
>
> > Deactivating checksum offloading helped a lot! I still have some packet
> > loss and not the best performance (TFTP transfer about 100 kbyte/s) but at
> > least it works.
> >
> > Thanks!
> >
> > //Magnus
> >
> > > -Original Message-
> > > From: rza1 [mailto:[EMAIL PROTECTED]
> > > Sent: den 31 mars 2008 11:14
> > > To: Magnus Hjorth
> > > Cc: John Linn; git; linuxppc-embedded@ozlabs.org
> > > Subject: Re: Xilinx LLTEMAC driver issues
> > >
> > > Hi Magnus,
> > >
> > > 1.
> > > I am using nearly the same versions then you and got the same problems
> > > too ;-).
> > > I think there are some problems with the checksum offloading.
> > > Try to sniff the some packages (e.g. wireshark)...
> > > For me ICMP (ping) worked but udp and tcp not (because off a wrong
> > > checksum in the transport layer).
> > > A quick solution is to just deactivate checksum offloading.
> > >
> > > 2.
> > > I remember some problems with Virtex-4 presamples too.
> > > There where problems with the hard-temac wrapper. You had to use 1.00.a
> > > and not b version.
> > > But I don't have these problems with the EDK 9.2sp2/ISE9.2sp3 anymore.
> > >
> > > all the best,
> > > Robert
> > >
> > > Magnus Hjorth wrote:
> > > > Hi John,
> > > >
> > > > Thanks for the very fast reply! Right now I'm not at work so I don't
> > > > have the board or EDK here to test anything.
> > > >
> > > > I'm using checksum offload, but I don't know if DRE is enabled or not.
> > I
> > > > can't recall seeing any setting to enable/disable DRE..
> > > >
> > > > A few things that crossed my mind:
> > > >
> > > > Last year I did a design with EDK 8.2, back then there was an issue
> > with
> > > > the ML403 boards having an old revision of the FPGA which wasn't
> > > > compatible with some versions of the IP core. There are no such
> > version
> > > > issues with the xps_ll_temac
Re: FW: CRS - #454833 is assigned to Amit Kasat for review by eliasd
Hi all, Sorry for the spam. This was not intended for this list. Please ignore. - John On Wednesday 28 November 2007 12:11, Simon George wrote: > Hi John > > Id you mean to send that to the linuxppc alias? > > Looks a rather internal email! > > Regards > > > > --- > > Simon George > Embedded Specialist (Northern Europe) > > XILINX (UK) - Benchmark House, 203 Brooklands Road, WEYBRIDGE, Surrey > KT13 0RH (UK) > Office: +44 (0)870 7350 557 Mobile: +44 (0)7901 551704 > FAX: +44 (0)707 5023179 > > > --- > > -Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of John Bonesio > Sent: 28 November 2007 19:49 > To: linuxppc-embedded@ozlabs.org > Subject: Re: FW: CRS - #454833 is assigned to Amit Kasat for review by > eliasd > > Hi Rick, > > I just checked more closely. The linux 2.6 mld uses the following > directories: > $XILINX_EDK/sw/ThirdParty/bsp/$MLD_version > $XILINX_EDK/sw/XilinxProcessorIPLib/drivers > /bsp/$MLD_version > > If 'edk_user_repository', is an actual directory name, then it is not > used in the Linux MLD. > > - John > > > On Wednesday 28 November 2007 10:15, Rick Moleres wrote: > > > > John, > > > > So, the Linux MLD does use the edk_repository to search for drivers > > etc...? > > > > Thanks, > > Rick > > > > -Original Message- > > From: John Bonesio [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, November 28, 2007 10:54 AM > > To: Rick Moleres > > Cc: embedded_ip_sw > > Subject: Re: FW: CRS - #454833 is assigned to Amit Kasat for review by > > eliasd > > > > Hi Rick, > > > > It's possible we may need to change some (all?) of our mld's, but the > > change should be small (on the order of 1-5 lines). > > > > - John > > > > On Wednesday 28 November 2007 08:20, Rick Moleres wrote: > > > All, > > > > > > > > > > > > Does this impact any of our MLDs? > > > > > > > > > > > > Thanks, > > > > > > Rick > > > > > > > > > > > > > > > > > > From: Chang Sun > > > Sent: Tuesday, November 27, 2007 6:13 PM > > > To: Amit Kasat; Randy Robinson; Rick Moleres > > > Subject: RE: CRS - #454833 is assigned to Amit Kasat for review by > > > eliasd > > > > > > > > > > > > Hi Amit, > > > > > > > > > > > > I included Rick for this comment/suggestion, since Rick's team has > > been > > > doing most of the RTOS MLD integration work (Linux and VxWorks). > Rick > > > should be able to suggest the level of impact by this change. > > > > > > We also have some partners, e.g. Mentor Graphics supporting the MLD > > > integration directly, so I hope this change has no major impact on > > them, > > > assuming we provide them well documented instructions. > > > > > > > > > > > > Thanks, > > > > > > Chang > > > > > > > > > > > > From: Amit Kasat > > > Sent: Tuesday, November 27, 2007 2:30 PM > > > To: Randy Robinson; Chang Sun > > > Subject: FW: CRS - #454833 is assigned to Amit Kasat for review by > > > eliasd > > > > > > > > > > > > Hi Randy, Chang: > > > > > > > > > > > > I would like to deprecate this mechanism of automatically reading > > > edk_user_repository if this directory exists at the same level at > EDK > > > installation. I believe some of our Board and MLD partners use this > > > mechanism. Going forward, we would like them to use the setting in > XPS > > > Gui's > > > > > > > > > > > > Edit -> Preferences -> Application Preferences -> Global Peripheral > > > Repository > > > > > > > > > > > > This is a much better, documented and GUI-supported way of > specifiying > > > peripheral repository path that's picked up automatically for all >
Re: FW: CRS - #454833 is assigned to Amit Kasat for review by eliasd
Hi Rick, I just checked more closely. The linux 2.6 mld uses the following directories: $XILINX_EDK/sw/ThirdParty/bsp/$MLD_version $XILINX_EDK/sw/XilinxProcessorIPLib/drivers /bsp/$MLD_version If 'edk_user_repository', is an actual directory name, then it is not used in the Linux MLD. - John On Wednesday 28 November 2007 10:15, Rick Moleres wrote: > > John, > > So, the Linux MLD does use the edk_repository to search for drivers > etc...? > > Thanks, > Rick > > -Original Message- > From: John Bonesio [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 28, 2007 10:54 AM > To: Rick Moleres > Cc: embedded_ip_sw > Subject: Re: FW: CRS - #454833 is assigned to Amit Kasat for review by > eliasd > > Hi Rick, > > It's possible we may need to change some (all?) of our mld's, but the > change should be small (on the order of 1-5 lines). > > - John > > On Wednesday 28 November 2007 08:20, Rick Moleres wrote: > > All, > > > > > > > > Does this impact any of our MLDs? > > > > > > > > Thanks, > > > > Rick > > > > > > > > > > > > From: Chang Sun > > Sent: Tuesday, November 27, 2007 6:13 PM > > To: Amit Kasat; Randy Robinson; Rick Moleres > > Subject: RE: CRS - #454833 is assigned to Amit Kasat for review by > > eliasd > > > > > > > > Hi Amit, > > > > > > > > I included Rick for this comment/suggestion, since Rick's team has > been > > doing most of the RTOS MLD integration work (Linux and VxWorks). Rick > > should be able to suggest the level of impact by this change. > > > > We also have some partners, e.g. Mentor Graphics supporting the MLD > > integration directly, so I hope this change has no major impact on > them, > > assuming we provide them well documented instructions. > > > > > > > > Thanks, > > > > Chang > > > > > > > > From: Amit Kasat > > Sent: Tuesday, November 27, 2007 2:30 PM > > To: Randy Robinson; Chang Sun > > Subject: FW: CRS - #454833 is assigned to Amit Kasat for review by > > eliasd > > > > > > > > Hi Randy, Chang: > > > > > > > > I would like to deprecate this mechanism of automatically reading > > edk_user_repository if this directory exists at the same level at EDK > > installation. I believe some of our Board and MLD partners use this > > mechanism. Going forward, we would like them to use the setting in XPS > > Gui's > > > > > > > > Edit -> Preferences -> Application Preferences -> Global Peripheral > > Repository > > > > > > > > This is a much better, documented and GUI-supported way of specifiying > > peripheral repository path that's picked up automatically for all > > projects. > > > > > > > > We will need to tell the partners to start using the new mechanism. > This > > mechanism gives them the flexibility to use any directory to install > > their XBD/MLDs and point to it using this setting. > > > > > > > > The edk_cr_review_team did not have any concerns about it. I just > wanted > > to make sure you guys are ok with it too. > > > > > > > > Thanks, > > > > Amit > > > > > > > > > -Original Message- > > > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > > > Sent: Tuesday, November 27, 2007 2:19 PM > > > > > To: Amit Kasat > > > > > Subject: CRS - #454833 is assigned to Amit Kasat for review by > eliasd > > > > > > > > > > http://governator:9089/itg/html/kintanaHome.html > > > > > > > > > > > > > > > CR #:454833 > > > > > CR Link: > > > > > > > > http://governator:9089/itg//web/knta/crt/RequestDetail.jsp?REQUEST_ID=45 > > 48 > > > > > 33 > > > > > Created By: Amit Kasat > > > > > Creation Date: 20-NOV-07 > > > > > Description: Deprecate and then remove support of > > built in > > > > > reposiotry - $XILINX_EDK/../edk_user_repository > > > > > Status: New > > > > > Application: EDK_General > > > > > Ass
RE: Looking For XILINX TEMAC Driver For linux 2.4 or 2.6
Title: Looking For XILINX TEMAC Driver For linux 2.4 or 2.6 Hi, I could just send out one of these drivers and hope that it helps, but I thought it might be better to find out some more specifics on what is needed first. This way we can avoid lots thrashing and missed attempts at getting something to work. What TEMAC core are you using? What version? Is there a preference of linux kernels, 2.4 or 2.6? If you prefer 2.6, do you already have the other kernel changes to support Virtex 4 (assuming that's the fpga you're using)? Let me know what you're trying to accomplish so I can give you better specific help. - John From: [EMAIL PROTECTED] on behalf of Sharon FeldmanSent: Wed 10/18/2006 8:01 AMTo: linuxppc-embedded@ozlabs.orgSubject: Looking For XILINX TEMAC Driver For linux 2.4 or 2.6 I Need XILINX ll_temac Or PLB_Temac Drivers For Linux 2.4 Or 2.6 I Understand There Is A Driver For MV That Can Be Used. Best Regards/ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: booting 2.6 kernel on ML403
Hi Pradeep, If you are using the MontaVista/Xilinx driver for sysace for linux 2.6, the CONFIG_CMDLINE item in .config should have root=/dev/xsysace2 rw in it. From the text below it’s not clear what driver you are using. If you are using a different driver, you may be able to search for #define MAJOR_NAME in the source code of the sysace driver. I believe that will indicate which device name you should use in the CONFIG_CMDLINE. As you probably already know, the ‘2’ in ‘/dev/xsysace2’ refers to the partition number it should use – partition 2 in this case. For Problem 2: Do you see any error leds light up on the board? It’s possible that the drivers you are using for one or both of those cores is not meant for the version of the cores you are using. The core most likely to be suspect is the TEMAC soft core, as that has changed recently. Even though you are using the hard TEMAC core, there is a soft wrapper around it to connect it up to the bus and what not. This soft wrapper has changed from version 2 to version 3 not too long ago. While the TEMAC driver that MontaVista has (and I believe posted to this mailing list) is for version 2 of the soft TEMAC core. Hope this helps, - John From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pradeep Sampath Sent: Wednesday, October 04, 2006 10:35 AM To: Ming Liu; [EMAIL PROTECTED] Cc: linuxppc-embedded@ozlabs.org Subject: Re: booting 2.6 kernel on ML403 Hello Ameet/Ming, First of all really appreciate your inputs on this... Problem 1 : I was using the factory shipped compact flash as is which comes with a DOS FAT16 partition and a linux 83 partition with ext3 filesystem. I tried it on 2 factory shipped CFs and its the same behavior - . When i plug-in the CF card reader to the linux box it always reads it as "sda" and in the linux2.6.17.1/Documentation/devices.txt - sda is the device file for SCSI disk devices. Wonerding how you guys configured the root option as "/dev/xsa". Now i re-formatted my CF, created a ext2 filesystem using busybox-1.1.0 like the BYU instructions. Created 2 partitions on CF card 1. FAT16 partition & 2. linux partition and then created 1. dos file system using mkdosfs and 2. linux ext2 filesystem using mke2fs. But the problem still persists and i get "Please append a correct "root=" boot option :" :( Problem 2: After i included the TEMAC driver and sysace drivers, the kernel just hangs. I thought i'll fix problem 1 before i get to problem 2... With your help i am getting the confidence that i can make this all work! thanks once again. -Pradeep Ming Liu <[EMAIL PROTECTED]> wrote: Hello Ameet, I am using that driver very well now. There is only one problem. It seems that the driver for TEMAC only support Gigabit Enet, not 10/100/1000M adapted. But because I want to use the Gigabit enet, I don't care that. So it's OK, at lease for 1Gbit/s. So I don't think Pradeep's problem is caused by Temac. I still suspect that he didn't pass a right parameter to "root=", just like what I posted before. Regards Ming >From: Ameet Patil <[EMAIL PROTECTED]>>To: Ming Liu <[EMAIL PROTECTED]>>CC: [EMAIL PROTECTED], linuxppc-embedded@ozlabs.org >Subject: Re: booting 2.6 kernel on ML403 >Date: Wed, 04 Oct 2006 09:35:07 +0100 > >Ming Liu wrote: > > Hi, > > > >> [ 3.093694] TCP bic registered > >> [ 3.129458] NET: Registered protocol family 8 > >> [ 3.181412] NET: Registered protocol family 20 > >> [ 3.236744] VFS: Cannot open root device "xsa2" or unknown-block(0,0) > >> [ 3.313092] Please append a correct "root=" boot option > > > > It looks that some errors still exist in the parameters you passed to > > "root=". Please double check it, or post it in the maillist for deep > > analysis. > > Regards > > Ming > > > > _ > > ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£ http://www.hotmail.com > > > > > > ___ > > Linuxppc-embedded mailing list > > Linuxppc-embedded@ozlabs.org > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded >Hi Ming, >IIRC, you are or were using the TEMAC driver along with my System Ace >driver, isn't it? Does my driver patch ***-after-TEMAC.patch work for >you? I ask this because Pradeep is having some problems using it (see >Problem 2 in his email). Could you please update on this? > >Thanks, >-Ameet _ ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.msn.com/cn ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxpp
RE: booting 2.6 kernel on ML403
A quick amendment to my previous email: The device name you should use in the CONFIG_CMDLINE “root=…” can be found in the routine call to register_blkdev() in the driver source code. The first parameter to register_blkdev() is the major number of the device. The second parameter is the name of the device, as in /dev/xsda2, or /dev/xsysace2. This second parameter will contain just the ‘xsda’ or ‘xsysace’ in it, and it may be a preprocessor constant defined earlier in the file, such as #define MAJOR_NAME “xsda”, but it might not be a constant either. It depends on the code. Hopefully this clears things up a bit. - John From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pradeep Sampath Sent: Wednesday, October 04, 2006 10:35 AM To: Ming Liu; [EMAIL PROTECTED] Cc: linuxppc-embedded@ozlabs.org Subject: Re: booting 2.6 kernel on ML403 Hello Ameet/Ming, First of all really appreciate your inputs on this... Problem 1 : I was using the factory shipped compact flash as is which comes with a DOS FAT16 partition and a linux 83 partition with ext3 filesystem. I tried it on 2 factory shipped CFs and its the same behavior - . When i plug-in the CF card reader to the linux box it always reads it as "sda" and in the linux2.6.17.1/Documentation/devices.txt - sda is the device file for SCSI disk devices. Wonerding how you guys configured the root option as "/dev/xsa". Now i re-formatted my CF, created a ext2 filesystem using busybox-1.1.0 like the BYU instructions. Created 2 partitions on CF card 1. FAT16 partition & 2. linux partition and then created 1. dos file system using mkdosfs and 2. linux ext2 filesystem using mke2fs. But the problem still persists and i get "Please append a correct "root=" boot option :" :( Problem 2: After i included the TEMAC driver and sysace drivers, the kernel just hangs. I thought i'll fix problem 1 before i get to problem 2... With your help i am getting the confidence that i can make this all work! thanks once again. -Pradeep Ming Liu <[EMAIL PROTECTED]> wrote: Hello Ameet, I am using that driver very well now. There is only one problem. It seems that the driver for TEMAC only support Gigabit Enet, not 10/100/1000M adapted. But because I want to use the Gigabit enet, I don't care that. So it's OK, at lease for 1Gbit/s. So I don't think Pradeep's problem is caused by Temac. I still suspect that he didn't pass a right parameter to "root=", just like what I posted before. Regards Ming >From: Ameet Patil <[EMAIL PROTECTED]>>To: Ming Liu <[EMAIL PROTECTED]>>CC: [EMAIL PROTECTED], linuxppc-embedded@ozlabs.org >Subject: Re: booting 2.6 kernel on ML403 >Date: Wed, 04 Oct 2006 09:35:07 +0100 > >Ming Liu wrote: > > Hi, > > > >> [ 3.093694] TCP bic registered > >> [ 3.129458] NET: Registered protocol family 8 > >> [ 3.181412] NET: Registered protocol family 20 > >> [ 3.236744] VFS: Cannot open root device "xsa2" or unknown-block(0,0) > >> [ 3.313092] Please append a correct "root=" boot option > > > > It looks that some errors still exist in the parameters you passed to > > "root=". Please double check it, or post it in the maillist for deep > > analysis. > > Regards > > Ming > > > > _ > > ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£ http://www.hotmail.com > > > > > > ___ > > Linuxppc-embedded mailing list > > Linuxppc-embedded@ozlabs.org > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded >Hi Ming, >IIRC, you are or were using the TEMAC driver along with my System Ace >driver, isn't it? Does my driver patch ***-after-TEMAC.patch work for >you? I ask this because Pradeep is having some problems using it (see >Problem 2 in his email). Could you please update on this? > >Thanks, >-Ameet _ ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.msn.com/cn ___ 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: Ethernet driver for Linux kernel 2.6 running on ML403
Hi Keith, I know that on the surface it seems like a simple thing. Some of our parts are big, yet some are small. We are always getting pressure to make our IP as small as possible. Though, this may be something we can revisit again, for now this information just isn't going to be available. Perhaps the problem can be solved in a different way. - John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Keith J Outwater Sent: Thursday, September 14, 2006 5:09 PM To: linuxppc-embedded@ozlabs.org Subject: RE: Ethernet driver for Linux kernel 2.6 running on ML403 "John Bonesio" <[EMAIL PROTECTED]> wrote on 09/14/2006 10:52:16 AM: > > I don't think that there are any "version" registers in the Xilinx > IP cores that a driver could check to determine compatibility. That > would be very cheap to implement in hardware and you could then > develop more universal drivers. > > [John] > We've examined doing this in the past, and gotten some push back due to > the use of bram or other resources. Conceptually, it's a great idea, I > just don't know if this is likely to happen any time soon. > John, I thinking in terms of something like a 32 bit register (i.e. like a processor's PVR register) that has a hard-coded magic number which a driver can read and decode to determine driver compatibility. That does not sound resource-intensive given the size FPGAs we are talking about. Probably don't even need 32 bits. Keith ___ 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: Ethernet driver for Linux kernel 2.6 running on ML403
More comments below... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Keith J Outwater Sent: Thursday, September 14, 2006 11:36 AM To: linuxppc-embedded@ozlabs.org Subject: RE: Ethernet driver for Linux kernel 2.6 running on ML403 > Hi, > > I just saw this thread. The next version of EDK 8.2.2 will have a temac > v3.00a driver for linux 2.6. Our plan is to begin our code freeze stage > tomorrow. If people really need the driver right away, and can't wait a > few weeks for the release, I could possibly provide a patch (or use some > other distribution method) for the driver. > > Here at Xilinx, we have been in talks about having our drivers more > readily available in the open source repositories. As far as I know, > everyone seems to think that this would be a good thing for us. Right > now the plan is to have a 3rd party check our drivers into the main > repository as we have limited resources here. (Basically we're up to our > eyeballs in work right now.) I know that MontaVista is you preferred Linux partner - if they do the released, then we have to wait for them. If individual designers can get the driver sources, you can bet it will make it's way into the mainline kernel. > > I do know that Xilinx would rather play a principle role in developing > and maintaining these open source drivers, rather than having a separate > group go off and implement a separate set. You may end up having to serve multiple customer bases then, to keep things from forking. The are lots of us who want to have lots of fine-grained control over our source trees and the way in which we do builds. [John] One thing that may help you, is that you can clear out the 'target_dir' setting in xps. That will let you generate the BSP and then simply copy over the files you need. > > << Same complaints apply for Xilinx drivers in the U-Boot bootloader. > It is proving very difficult to get Xilinx code into U-Boot which means > BSPs that use the code are hard to get submitted as well.>> > > I've only touched on U-Boot a little bit. Have any thoughts on how to > make this easier? My perspective on this is that of a hardware designer who also develops code. I understand that is a good thing from the Xilinx point of view to make it as easy as possible for designers to develop designs using EDK with automatic BSP generation. It's great for doing stand alone (no OS) designs or to get "instant gratification" as in "gee, I just booted Linux!" (a la Xilinx XAPP765). When you do that, though, invariably you end up having to make decisions that constrain how the design flow works for the user and then it's hard for the user to deviate from that flow. For example, the idea of having a user auto-generate source code for a BSP that overwrites the bootloader or kernel source tree. The problem is that it's hard to "take the training wheels off" if I want or need to have a stable source base of if I want to use the mainline kernel or the mainline bootloader (U-Boot). What if the source code bases for the kernel or bootloader get re-arranged? What I'd really like to have is "out of the box" kernel support for all the primary peripheral devices like communications and interface stuff and U-Boot support for those devices as well. I don't want to have to generate BSPs and overwrite the source trees. [John] See my comment above. The whole licensing thing is another issue. As I stated to someone else at Xilinx: These are just drivers, not the crown jewels. GPL it all and make it easier for designers to incorporate the code into open source projects. Dual license if you have customers who have to have things locked up. [John] I believe this is our intention going forward. For U-Boot, I'm getting push-back from the maintainer on the size and "verbosity" of the code. Sounds like this might be an issue for the kernel as well. > > << The Xilinx approach of overwriting the source tree just feels wrong, > and > no one seems to want to do it that way.>> > > I am in the group that has control over how this is done. What would you > propose be done different? Keep in mind that we are trying to support a > process where someone builds a hardware design and the later changes it > with new peripherals or perhaps makes minor tweaks. We want to make the > updating of the Linux kernel to reflect these hardware changes easy for > people. A noble goal, and clearly the right thing to do from a user-success point of view, but do the hardware peripherals (i.e. the IP cores) change that much? See my comment below: Can you create a system that allows software drivers to verify that they (the drivers) are compatible with a particular IP version? For the novice user, the "full auto" system probably works fine, but for (some, at least) experienced users, it tends to be an additional layer or complexity (or opacity) that would be nice to get rid of. > > Having the ability to make rapid hardware changes, I t
RE: Ethernet driver for Linux kernel 2.6 running on ML403
Hi,
I just saw this thread. The next version of EDK 8.2.2 will have a temac
v3.00a driver for linux 2.6. Our plan is to begin our code freeze stage
tomorrow. If people really need the driver right away, and can't wait a
few weeks for the release, I could possibly provide a patch (or use some
other distribution method) for the driver.
Here at Xilinx, we have been in talks about having our drivers more
readily available in the open source repositories. As far as I know,
everyone seems to think that this would be a good thing for us. Right
now the plan is to have a 3rd party check our drivers into the main
repository as we have limited resources here. (Basically we're up to our
eyeballs in work right now.)
I do know that Xilinx would rather play a principle role in developing
and maintaining these open source drivers, rather than having a separate
group go off and implement a separate set.
<< Same complaints apply for Xilinx drivers in the U-Boot bootloader.
It is proving very difficult to get Xilinx code into U-Boot which means
BSPs that use the code are hard to get submitted as well.>>
I've only touched on U-Boot a little bit. Have any thoughts on how to
make this easier?
<< The Xilinx approach of overwriting the source tree just feels wrong,
and
no one seems to want to do it that way.>>
I am in the group that has control over how this is done. What would you
propose be done different? Keep in mind that we are trying to support a
process where someone builds a hardware design and the later changes it
with new peripherals or perhaps makes minor tweaks. We want to make the
updating of the Linux kernel to reflect these hardware changes easy for
people.
Having the ability to make rapid hardware changes, I think, is a bit
different from what most folks are used to.
Cheers,
- John
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Keith J Outwater
Sent: Thursday, September 14, 2006 9:48 AM
To: linuxppc-embedded@ozlabs.org
Subject: Re: Ethernet driver for Linux kernel 2.6 running on ML403
Grant,
You bring up excellent points, and I am having to deal with these
issues in my 2.4.x kernel and U-Boot ports to VirtexII Pro FPGAs
as well.
> On 9/14/06, Michael Galassi <[EMAIL PROTECTED]> wrote:
> > It is also worth noting that as released in MVL pro 4.0.1 it only
> > supports hard_temac 1.00.a and plb_temac 2.00.a, both of which are
> > tagged as deprecated in the current version (8.2.01i) of Xilinx's
> > EDK. The current version of {plb,hard}_temac (3.00.a) goes to great
> > lengths to break compatibility with older versions. This will
> > presumably be fixed next month when it is rumored that wonderful new
> > things will come from Xilinx. In the mean-time it is possible,
though
> > neither simple, nor fun, to create Virtex4 designs with the older
IP.
I think the general case is that Xilinx IP will be constantly evolving,
and
Xilinx driver code, when released under the GPL, will appear
sporadically.
Maybe it's best to resign ourselves to the fact that this situation
probably won't change, and then try to deal with it in a way that does
not depend so heavily on Xilinx drivers.
>
> So what direction do we (as the community) want to go for supporting
> Xilinx IP in the Linux kernel?
I don't know about anyone else, but running Linux on Virtex FPGAs is
something I simply have to be able to do. With or without Xilinx
drivers, I think the kernel needs to support Xilinx hardware.
>
> IIRC, Xilinx intends to get drivers submitted into mainline. (Based
> on their cross-platform driver support code). It is unknown which and
> how many drivers for different IP versions will be submitted.
That's part of the problem: we seem to get support for some
IP cores, but not all. Xilinx takes a piecemeal approach
to releasing drivers under the GPL.
>
> However, the xilinx driver code is verbose and does not match well
> with the rest of the Linux code base. (due to the cross platform
> support) Plus, the Xilinx tool work flow is geared towards the EDK
> tool overwriting the driver code in the kernel tree with code for the
> generated design. In which case, does it even make sense to accept
> Xilinx drivers into the Linux tree when they are just going to get
> overwritten by the toolchain anyway? Unfortunately, regenerating
> drivers has it's own problems considering that the license on the
> generated code is not GPL compatible at the moment.
Same complaints apply for Xilinx drivers in the U-Boot bootloader.
It is proving very difficult to get Xilinx code into U-Boot which means
BSPs that use the code are hard to get submitted as well.
The Xilinx approach of overwriting the source tree just feels wrong, and
no one seems to want to do it that way.
>
> If we reject the Xilinx driver code, then we either have to do without
> Xilinx support in mainline, or we need to write new drivers that
> address the above issues (support multiple IP versions, etc). The
> Xilinx su
xilinx ml403 with 2.6 Kernel
Hi, Support for linux 2.6 from the EDK tools does not yet work. Xilinx has contracted MontaVista to create an LSP for the ML40x development boards for MVL Pro 4.0 (which uses the 2.6.10 kernel). The LSP is anticipated to be available sometime before the end of this month. The use of xparameters_ml403.h does not provide the complete solution for building linux 2.6 on the ml403 board. - John -Original Message- From: linuxppc-embedded-bounces+jbonesio=xilinx.com at ozlabs.org [mailto:[EMAIL PROTECTED] On Behalf Of "Karl Pr?fer" Sent: Thursday, June 15, 2006 6:08 AM To: linuxppc-embedded at ozlabs.org Subject: Re: xilinx ml403 with 2.6 Kernel Hello again! I had a little mistake in my first mail. I have copied the whole BSP... Now i have tried to copy only the xparameters_ml403.h in arch/ppc/platforms/4xx/xparameters/ but get the same error!! I would be more then happy when somebody could help me. nice greetings Robert Original-Nachricht Datum: Thu, 15 Jun 2006 12:20:55 +0200 Von: "Karl Pr?fer" An: linuxppc-embedded at ozlabs.org Betreff: xilinx ml403 with 2.6 Kernel > Hallo! > > I am not perfect in english, so please forgice me my mistakes... > > I am trying to get the 2.6 kernel running on my ml403 board... > > 1. I downloaded paulus tree: > cg-clone git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git > myprojectdir > > > 2. I copied my Xilinx BSP in the kernel dir > cp -ra /* / > > > 3. I configured the Makefile to use my crosscompiler and the ppc Arch. > I have built a crosstoolchain for a 2.4.26 kernel in past (with crosstool > 0.42). > I know that this toolchain works with a 2.4 kernel... > > Can i use this toolchain to compile the 2.6 kernel?? > Why do i need a kernel(some headers) to build the croostoolchain?? > > > 4. Then I configured the kernel: > # > # Automatically generated make config: don't edit > # Linux kernel version: 2.6.17-rc5 > # Wed Jun 14 10:02:22 2006 > # > CONFIG_MMU=y > CONFIG_GENERIC_HARDIRQS=y > CONFIG_RWSEM_XCHGADD_ALGORITHM=y > CONFIG_GENERIC_HWEIGHT=y > CONFIG_GENERIC_CALIBRATE_DELAY=y > CONFIG_PPC=y > CONFIG_PPC32=y > CONFIG_GENERIC_NVRAM=y > CONFIG_GENERIC_FIND_NEXT_BIT=y > CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y > CONFIG_ARCH_MAY_HAVE_PC_FDC=y > > # > # Code maturity level options > # > CONFIG_EXPERIMENTAL=y > CONFIG_BROKEN_ON_SMP=y > CONFIG_INIT_ENV_ARG_LIMIT=32 > > # > # General setup > # > CONFIG_LOCALVERSION="" > # CONFIG_LOCALVERSION_AUTO is not set > # CONFIG_SWAP is not set > CONFIG_SYSVIPC=y > CONFIG_POSIX_MQUEUE=y > # CONFIG_BSD_PROCESS_ACCT is not set > CONFIG_SYSCTL=y > # CONFIG_AUDIT is not set > # CONFIG_IKCONFIG is not set > # CONFIG_RELAY is not set > CONFIG_INITRAMFS_SOURCE="" > # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set > # CONFIG_EMBEDDED is not set > CONFIG_KALLSYMS=y > # CONFIG_KALLSYMS_ALL is not set > # CONFIG_KALLSYMS_EXTRA_PASS is not set > CONFIG_HOTPLUG=y > CONFIG_PRINTK=y > CONFIG_BUG=y > CONFIG_ELF_CORE=y > CONFIG_BASE_FULL=y > CONFIG_FUTEX=y > CONFIG_EPOLL=y > CONFIG_SHMEM=y > CONFIG_SLAB=y > # CONFIG_TINY_SHMEM is not set > CONFIG_BASE_SMALL=0 > # CONFIG_SLOB is not set > > # > # Loadable module support > # > CONFIG_MODULES=y > CONFIG_MODULE_UNLOAD=y > # CONFIG_MODULE_FORCE_UNLOAD is not set > CONFIG_MODVERSIONS=y > # CONFIG_MODULE_SRCVERSION_ALL is not set > CONFIG_KMOD=y > > # > # Block layer > # > # CONFIG_LBD is not set > # CONFIG_BLK_DEV_IO_TRACE is not set > # CONFIG_LSF is not set > > # > # IO Schedulers > # > CONFIG_IOSCHED_NOOP=y > CONFIG_IOSCHED_AS=y > CONFIG_IOSCHED_DEADLINE=y > CONFIG_IOSCHED_CFQ=y > CONFIG_DEFAULT_AS=y > # CONFIG_DEFAULT_DEADLINE is not set > # CONFIG_DEFAULT_CFQ is not set > # CONFIG_DEFAULT_NOOP is not set > CONFIG_DEFAULT_IOSCHED="anticipatory" > > # > # Processor > # > # CONFIG_6xx is not set > CONFIG_40x=y > # CONFIG_44x is not set > # CONFIG_8xx is not set > # CONFIG_E200 is not set > # CONFIG_E500 is not set > # CONFIG_MATH_EMULATION is not set > # CONFIG_KEXEC is not set > # CONFIG_CPU_FREQ is not set > CONFIG_4xx=y > # CONFIG_WANT_EARLY_SERIAL is not set > > # > # IBM 4xx options > # > # CONFIG_BUBINGA is not set > # CONFIG_CPCI405 is not set > # CONFIG_EP405 is not set > # CONFIG_REDWOOD_5 is not set > # CONFIG_REDWOOD_6 is not set > # CONFIG_SYCAMORE is not set > # CONFIG_WALNUT is not set > # CONFIG_XILINX_ML300 is not set > CONFIG_XILINX_ML403=y > CONFIG_IBM405_ERR77=y > CONFIG_IBM405_ERR51=y > CONFIG_XILINX_VIRTEX_4_FX=y > CONFIG_XILINX_VIRTEX=y > CONFIG_EMBEDDEDBOOT=y > # CONFIG_PPC4xx_DMA is not set > CONFIG_PPC_GEN550=y > CONFIG_UART0_TTYS0=y > # CONFIG_UART0_TTYS1 is not set > CONFIG_NOT_COHERENT_CACHE=y > > # > # Platform options > # > # CONFIG_PC_KEYBOARD is not set > # CONFIG_HIGHMEM is not set > # CONFIG_HZ_100 is not set > CONFIG_HZ_250=y > # CONFIG_HZ_1000 is not set > CONFIG_HZ=250 > CONFIG_PREEMPT_NONE=y > # CONFIG_PREEMPT_VOLUNTARY is not set > # CONFIG_PREEMPT is not set > CONFIG_SELECT_MEMORY_MODEL=y > CONFIG_FLATMEM_
regarding xilinx system ace in linux-2.6
Hi, Xilinx has contracted MontaVista to create an LSP for the ML40x development boards for MVL Pro 4.0 (which uses the 2.6.10 kernel). This work is nearing completion. We (Xilinx) have also asked MontaVista to make those drivers available via open source, and MontaVista has agreed to this. The LSP is anticipated to be available sometime before the end of this month. I'm not sure when the drivers will be made available to open source. Hope this helps, - John -Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-embedded-bounces+jbonesio=xilinx.com at ozlabs.org] On Behalf Of Jeff Angielski Sent: Wednesday, June 14, 2006 8:15 AM To: rahul Cc: linuxppc-embedded at ozlabs.org Subject: Re: regarding xilinx system ace in linux-2.6 On Wed, 2006-06-14 at 10:03 +0530, rahul wrote: > Hi all > I would like to know if anyone in the group or otherwise using Xilinx's > System ACE MPU interface to read/write to Compact Flash card on their > hardware ? > I came to know the code is implemented in linux-2.4 but i want to have > it in linux-2.6 Last I heard was that Xilinx was working on the linux 2.6 implementation. You should contact your Xilinx representative to find out the current status of that effort and/or where you can get the source code. Jeff Angielski The PTR Group ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH 00/10] Updated ML300 & ML403 patches
Hello, I work in the Xilinx software group. I'm replying to this email thread because Grant suggested there be a GIT tree for Virtex specific changes. I am wondering if the open source community would prefer or see a benefit to Xilinx owning/hosting the source trees (CVS or GIT or whatever) for our drivers, and in particular the Linux adapter drivers. If we did this we would provide a web site with the information along with instructions on how to submit changes. We are exploring this idea and wanted to know what others thought of this. - John -Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-embedded-bounces at ozlabs.org] On Behalf Of Grant Likely Sent: Tuesday, January 17, 2006 8:41 AM To: peter.ryser Cc: Grant Likely; Andrei Konovalov; rick.moleres; linuxppc-embedded Subject: Re: [PATCH 00/10] Updated ML300 & ML403 patches Peter Ryser wrote: > >> Hmm, did you use the ml403 and ml300 def configs? What date did you >> pull Linus' tree? Kumar and Paul were talking today about some serial >> subsystem breakage on the linux-2.6 tree this weekend... I'll fast >> forward tonight and try it on my board. > > > Okay, please let me know how this works for you. > >> Try seeking to commit: 67daf5f11f06b9b15f8320de1d237ccc2e74fe43 >> That's what I generated the latest patches against. > > > Hmm, I only recently switched to using git. Is this number string some > kind of a tag that I can synchronize my local git tree to? If so, how? > Yea, the number is kind of like a raw tag without a name associated with it. The cg-seek command can be used to get you there. (But you also need to have cogito installed) >>> Anyway, there is another issue that I would like to bring up and it >>> has to do with xparameters.h. The xparameters.h file, or more >>> exactly, the xparameters_* file, is automatically generated by EDK >>> and is then used to configure the devices in the Linux kernel at >>> compile time. While I understand the desire to get away from a static >>> device definition to device enumeration at run-time, the current set >>> of patches is a step backwards for users from a useability point of >>> view. Users will now have to modify xparameters*.h by hand which is >>> an error-prone process. >> >> >> >> Actually, users should *never* modifiy generated files. The intent is >> that board specific fixups go directly into the top level >> xparameters.h so that newly generated files don't have to be touched. >> But yes, I understand what you mean. > > > An EDK user is free to choose arbitrary names for his peripherals. > Additionally, Base System Builder uses different names for various > boards (historically). With that it is impossible to make static > assignments in xparameters.h. If you go back to the 2.4 kernel and have > a look at xparameters_ml300.h you can see that the assignment of boards > specific parameters to Linux specific parameters is done in there and > that xparameters.h is basically used to chose the proper xparameters_* > file for a given board. okay > >>> Additionally, the original 'redefines' are now replaced with >>> redefines in xparameters.h but differently for every board. I suggest >>> we keep the 2.4 methodology until we can come up with a better >>> approach to enumerate devices at run-time. >> >> >> >> Andrei & I are already discussing this. I'm going to change the >> xparameters redefines to provide a default set of mappings that can be >> used if xparameters_*.h has the linux specific mappings. > > > Thanks. Why not just use the xparameters_ml300.h file created by the > system_linux.xmp in the EDK reference design for the ML403 and rename it > to xparameters_ml403.h for inclusion into the kernel tree? We could then > make a change in EDK, add a parameter that lets the user specify the > board he uses, and with that automatically create an xparameters_ml403.h > (or any other board for that matter). I don't understand what you mean. It sounds like your suggesting I do exactly opposite what you're arguing; hand modify one of the xparameters_*.h files. Are you saying that edk can't generate Linux redefines for the ml403 at the moment? I do *not* think I should replace the edk-generated xparameters_ml403.h with a hacked xparameters_ml300.h file. I'd rather use the generated _ml403 file and change the infrastructure when the Linux redefines are ready. > >> However, due to the fact that generated xparam files don't have the >> Linux redefines if the FPGA engineer doesn't select a linux bsp. > > > That's not a recommended flow. It's very easy to create an EDK design > with the proper settings and since it is very likely that things change > during the design process of the FPGA the small investment into making > the proper settings in the tool will save a lot of time in the end. I understand that it's not *recommended*; I'm just saying it's not always *reality* :p > >> I think it's important
