From nbasker at india.tejasnetworks.com  Mon Jul 23 17:51:44 2007
From: nbasker at india.tejasnetworks.com (nbasker at india.tejasnetworks.com)
Date: Tue, Tue 01 Jul 2003 08:16:00 PM IST, Jul 2003 20:16:00 +0530
Subject: problems in SCC-UART in mpc860
Message-ID: <1057070760.3f019ea838280@pop-mail.india.tejasnetworks.com>


Hi:

I am trying to use a SCC configured in UART to communicate with a intel
pc via modem. The configuration is simple and shown below

target --- modem -------phoneline---- modem----i386pc

target configuration:
1. mpc860T custom board
2. scc2 configured in uart
3. linux-2-2-14 from montavista
4. patched 8xx_io/uart.c from 2.2.4 kernel from Denks
5. using mgetty/pppd to program modem and start pppd.

host configuration:
1. i368pc running 2.2.14-12 redhat kernel
2. using pppd/chat to dialup to target modem.

In this setup if use PCSO to enable RTS, CTS and CD along with
crtscts option in pppd nothing works. If I disable PCSO and use
nocrtscts option in pppd, LCP connection goes through but IPCP
exchange at target fails (it never sends ConfigAck packet towards host).

I am able to get the setup working using null modem cable enabling
RTS/CTS/CD via PCSO register as well as pppd options.

Since I am able to get SCC2/UART working with nullmodem, but not
with actual modem, should I suspect hardware signal connectivity as
a problem source?. I suspected the uart driver and went through
all the register settings described in Section 23.21 of 860T user
manual and everything seems to be fine.

Any hint or help on this issue will be greatly appreciated.

Thanks for your time,
Nicholas.

-------------------------------------------------
This mail sent through Tejasnetworks Webclient


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/




From nbasker at india.tejasnetworks.com  Mon Jul 23 17:51:44 2007
From: nbasker at india.tejasnetworks.com (nbasker at india.tejasnetworks.com)
Date: Wed, Wed 02 Jul 2003 06:47:20 PM IST, Jul 2003 18:47:20 +0530
Subject: problems in SCC-UART in mpc860
In-Reply-To: <200307012248.13130.pruhland@rochester.rr.com>
References: <1057070760.3f019ea838280@pop-mail.india.tejasnetworks.com> <200307012248.13130.pruhland@rochester.rr.com>
Message-ID: <1057151840.3f02db609eb1d@pop-mail.india.tejasnetworks.com>


Hi:

The PVR of my mpc860 says 0x00500000.  I tried to
rearrange the BRGs assigned to SMCs and SCCs that I am using from

SMC1 - BRG2 (console)
SCC1 - BRG1 (hdlc)
SCC2 - BRG4 (uart)

to

SMC1 - BRG1 (console)
SCC1 - BRG1 (hdlc)
SCC2 - BRG3 (uart)

This kind of got me further ahead. Now I am able to ping (inconsistently)
via the connection, still my CTS/RTS/CD are disabled. After working for
sometime, modem hangsup and I have to reconnect to get it working again.

I am not able to explain why it was not working in the previous configuration
and why it works (though not completely) with the change. Any hints would be
helpful. Thanks.

Nicholas.

Quoting Paul Ruhland <pruhland at rochester.rr.com>:

>
> You stated you have the SCC UART CD enabled so this may be your initial
> problem.
>
> With CD enabled, SCC UART will not receive unless CD is asserted.
> Typically,
> a modem will not assert CD until it is connected and gets an aswer tone.
> Therefore, you will not be able to communicate with the modem to configure
> it
> and tell it to dial.
>
> Try enabling RTS and CTS but not CD.  This may get you farther along.
>
>
> On Tuesday 01 July 2003 10:46 am, nbasker at india.tejasnetworks.com wrote:
> > Hi:
> >
> > I am trying to use a SCC configured in UART to communicate with a intel
> > pc via modem. The configuration is simple and shown below
> >
> > target --- modem -------phoneline---- modem----i386pc
> >
> > target configuration:
> > 1. mpc860T custom board
> > 2. scc2 configured in uart
> > 3. linux-2-2-14 from montavista
> > 4. patched 8xx_io/uart.c from 2.2.4 kernel from Denks
> > 5. using mgetty/pppd to program modem and start pppd.
> >
> > host configuration:
> > 1. i368pc running 2.2.14-12 redhat kernel
> > 2. using pppd/chat to dialup to target modem.
> >
> > In this setup if use PCSO to enable RTS, CTS and CD along with
> > crtscts option in pppd nothing works. If I disable PCSO and use
> > nocrtscts option in pppd, LCP connection goes through but IPCP
> > exchange at target fails (it never sends ConfigAck packet towards host).
> >
> > I am able to get the setup working using null modem cable enabling
> > RTS/CTS/CD via PCSO register as well as pppd options.
> >
> > Since I am able to get SCC2/UART working with nullmodem, but not
> > with actual modem, should I suspect hardware signal connectivity as
> > a problem source?. I suspected the uart driver and went through
> > all the register settings described in Section 23.21 of 860T user
> > manual and everything seems to be fine.
> >
> > Any hint or help on this issue will be greatly appreciated.
> >
> > Thanks for your time,
> > Nicholas.
> >
> > -------------------------------------------------
> > This mail sent through Tejasnetworks Webclient
> >
> >
>
>
>
>




-------------------------------------------------
This mail sent through Tejasnetworks Webclient


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/




From nbasker at india.tejasnetworks.com  Mon Jul 23 17:51:44 2007
From: nbasker at india.tejasnetworks.com (nbasker at india.tejasnetworks.com)
Date: Thu, Thu 03 Jul 2003 03:17:37 PM IST, Jul 2003 15:17:37 +0530
Subject: Fwd: Problems in booting kernel from bootloader.
Message-ID: <1057225657.3f03fbb9e09cf@pop-mail.india.tejasnetworks.com>


Hi,


 I am having an EP8260 board. And I got a zImage binary from TimeSys
linux(2.4.7). The board comes with a bootloader and diagnostics.

 The TimeSys linux gives me a binary called
zImage.initrd.bin-2.4.7-timesys-3.1.180-ep8260.


 I am trying to boot the kernel using the bootloader given by the
PlanetCore guys. The kernel was the one which I got from TimeSys. But this
kernel doesn't come up(It hangs).


Then I tried modifying a few lines of
assembly code(arch/ppc/boot/mbx/head_8260.S) to find the problem. The
board always goes for a reset when I run my code. I get the initial prints
regarding the



loaded at:     00800000 0080C27C
relocated to:  00400000 0040C27C
board data at: F0003000 F0003034
relocated to:  0040C148 0040C17C
zimage at:     0080C27C 008C6253
avail ram:     008C7000 04000000

And then the "Uncompress kernel"and "Now booting kernel" prints are seen
and then the board goes for a reset.


 The embed_config, decompress_kernel functions are run correctly. I could
come to this conclusion from the dump of the first few bytes of
memory. These were exactly identical to the "disassembled code of
vmlinux".

The head_8260.S is followed by the head.S code in arch/ppc/kernel. What I
found is that I am able to jump to the diagnostics of the PlanetCore just
before entering the "_start" of arch/ppc/kernel. But I am not able to jump
to the diagnostics just after entering the "_start" of the kernel head.S.



How do I debug this problem, I know that the first few bytes of SDRAM are
exactly what was expected. These values I dumped. Then what is the problem
in jumping to that location. With my binary, the board goes for a reset.

Please help.
Nicholas

-------------------------------------------------
This mail sent through Tejasnetworks Webclient


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/




From deepesh at india.tejasnetworks.com  Mon Jul 23 17:51:44 2007
From: deepesh at india.tejasnetworks.com (deepesh at india.tejasnetworks.com)
Date: Fri, Fri 04 Jul 2003 10:21:09 AM IST, Jul 2003 10:21:09 +0530
Subject: Problems in the kernel for EP8260 Board.
Message-ID: <1057294269.3f0507bd27111@pop-mail.india.tejasnetworks.com>


Hi,

  I am having an EP8260 Board. And the linux I am using is from TimeSys.
I made a gzipped ramdisk.image.gz. Following are the last few lines
before the board hung.

TCP: Hash tables configured (established 128 bind 210)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 4389k freed
EXT2-fs warning: checktime reached, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
Mounted devfs on /?v
Root-NFS: No NFS server available, giving up.
VFS: Unable to mount root fs via NFS, trying floppy.
modprobe: modprobe: Can't open dependencies file
/lib/modules/2.4.7-timesys-3.1.180/modules.dep
(N
)

Thank you,
Deepesh

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/




From anil at india.tejasnetworks.com  Mon Jul 23 17:51:44 2007
From: anil at india.tejasnetworks.com (Anil Giri)
Date: Thu, Thu 10 Jul 2003 06:14:00 PM IST, Jul 2003 18:14:00 +0530
Subject: _PAGE_WRITETHRU option in 8xx
Message-ID: <1057841040.3f0d5f9022327@pop-mail.india.tejasnetworks.com>


Hi,
  I am using linuxppx_2_4_20 from denx and i can;t find the _PAGE_WRITETHRU
option in include/asm-ppc/pgtable.h for 8xx. Is it replaced or ommitted?

Thanks
-Anil


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/




From joakim.tjernlund at transmode.se  Sun Jul  1 00:02:50 2007
From: joakim.tjernlund at transmode.se (Joakim Tjernlund)
Date: Sat, 30 Jun 2007 16:02:50 +0200
Subject: 83xx: requesting external interrupts
In-Reply-To: <1B23F0C1-3BDF-434B-BF90-E75BB4C3994B@freescale.com>
Message-ID: <004501c7bb1f$58c84a50$0e67a8c0@Jocke>

 

> -----Original Message-----
> From: Andy Fleming [mailto:afleming at freescale.com] 
> Sent: den 30 juni 2007 01:55
> To: Joakim Tjernlund
> Cc: bwarren at qstreams.com; linuxppc-embedded at ozlabs.org
> Subject: Re: 83xx: requesting external interrupts
> 
> 
> On Jun 29, 2007, at 06:34, Joakim Tjernlund wrote:
> > mdio at 2320 {
> > 			#address-cells = <1>;
> > 			#size-cells = <0>;
> > 			reg = <2320 18>;
> > 			device_type = "mdio";
> > 			compatible = "ucc_geth_phy";
> >
> > 			phy1: ethernet-phy at 0 {
> > 				interrupt-parent = <&ipic>;
> > 				interrupts = <12 2>; //EXT IRQ2
> > 				reg = <0>; // 0
> > 				device_type = "ethernet-phy";
> > 				interface = <3>; //ENET_100_MII
> > 			};
> >
> > Now the things is that the IRQ works with and without the
> >  /* All external IRQs + Generic timer IRQs must be initialized by  
> > BSP */
> >  const int bsp_irqs[] = {48, 17, 18, 19, 20, 21, 22, 23, 90, 78,  
> > 84, 72};
> >  for (i=0;i<sizeof(bsp_irqs)/sizeof(bsp_irqs[0]);i++)
> > 	virq = irq_create_mapping(NULL, bsp_irqs[i]);
> 
> 
> This isn't how to use the device tree.  That is, you *aren't* using  
> the device tree.  You want to read the node of every device you want  
> to set up, and create the mapping.  Look at irq_of_parse_and_map().   
> Look in include/asm-powerpc/prom.h, at of_irq_to_resource(), which  
> maps an irq in the device tree.

I use both!
I see that ipic.c does all the work for me, so I should just drop
the above code. It is strange though that the virq # changes if
I keep the code.

hmm, maybe if I sort the bsp_irqs[] list numerically it will be the same?
Am at home ATM so I can't verify.

 Jocke



From silicom at 163.com  Sun Jul  1 10:37:09 2007
From: silicom at 163.com (silicom)
Date: Sun, 1 Jul 2007 08:37:09 +0800 (CST)
Subject: difference between ppc and powerpc
Message-ID: <25584182.1710331183250229848.JavaMail.coremail@bj163app48.163.com>

Hi  Can anybody tell me the difference between arch->ppc and arch->powerpc?   thanks a lot   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070701/44ab5366/attachment.htm 

From jwboyer at jdub.homelinux.org  Sun Jul  1 11:05:32 2007
From: jwboyer at jdub.homelinux.org (Josh Boyer)
Date: Sat, 30 Jun 2007 20:05:32 -0500
Subject: difference between ppc and powerpc
In-Reply-To: <25584182.1710331183250229848.JavaMail.coremail@bj163app48.163.com>
References: <25584182.1710331183250229848.JavaMail.coremail@bj163app48.163.com>
Message-ID: <1183251933.10368.7.camel@vader.jdub.homelinux.org>

On Sun, 2007-07-01 at 08:37 +0800, silicom wrote:
> Hi
>   Can anybody tell me the difference between arch->ppc and
> arch->powerpc?

arch/ppc is the original tree for 32 bit PowerPC machines.  arch/powerpc
is the merged tree for both 32 and 64 bit PowerPC machines.  arch/ppc is
dying a slow death and really shouldn't be used for new submissions.

josh




From jwboyer at jdub.homelinux.org  Sun Jul  1 11:07:06 2007
From: jwboyer at jdub.homelinux.org (Josh Boyer)
Date: Sat, 30 Jun 2007 20:07:06 -0500
Subject: ARCH=ppc or ARCH=powerpc
In-Reply-To: <2DD9CF30-5127-4EC1-8D8E-BC6552A832AE@kernel.crashing.org>
References: <F795765B112E7344AF36AA911279641502D1A42C@xmb-sjc-212.amer.cisco.com>
	<2DD9CF30-5127-4EC1-8D8E-BC6552A832AE@kernel.crashing.org>
Message-ID: <1183252026.10368.8.camel@vader.jdub.homelinux.org>

On Wed, 2007-06-27 at 20:20 -0500, Kumar Gala wrote:
> On Jun 27, 2007, at 4:41 PM, Bizhan Gholikhamseh ((bgholikh)) wrote:
> 
> > Hi All,
> > Sorry for asking this question again, I am still not clear on some  
> > of the issues.
> > Background:
> > We have developed a custom board based on Freescale reference  
> > board: MPC8555_CDS with MPC8541E processor running Linux 2.6.11 and  
> > uboot 1.1.2 version.
> >
> > I would like to update the Linux kernel to the latest available  
> > kernel 2.6.21.
> > Here are my questions:
> > 1- Should I use ARCH=ppc or ARCH=powerpc to build the kernel?
> 
> Move to ARCH=powerpc.
> 
> > 2- I have seen similar filenames under arch/ppc and arch/powerpc,  
> > which one applies to MPC8541E?
> 
> There is support for MPC8541e in both arch/ppc & arch/powerpc.

Why?  Shouldn't the arch/ppc support be killed if it's in arch/powerpc?

josh



From silicom at 163.com  Sun Jul  1 12:03:41 2007
From: silicom at 163.com (silicom)
Date: Sun, 1 Jul 2007 10:03:41 +0800 (CST)
Subject: Can anyone send me a copy of ac97 driver with interrupt function
Message-ID: <1719162188.1761901183255421508.JavaMail.coremail@bj163app130.163.com>

 Hi    I'm writing an ac97 driver with interrupt mode,below is my code:staticirqreturn_t ac97_interrupt_handler(int irq,void *dev_id,struct pt_regs *regs){    disable_irq(7);    wake_up_interruptible(ac97_queue);    return IRQ_HANDLED;} static int xilinx_ac97_write(struct file *filp,char *buffer,size_t count,loff_t *ppos){    ......    if(XAC97_isInFIFOFull(baseAddress))        wait_event_interruptible(ac97_queue,...);    else        XAC97_mSetInFifoData(baseAddress,...);    ......}    Int the write function,when the play back fifo is not full,I send the PCM code to the fifo,else I make the write process sleep,and in the interrupt handler(when the fifo half empty,an interrupt occure),I wake up the write process,and go on write PCM code to the fifo.    But I find the play speed is rather faster than regular and can't hear the voice(I have set the pcm rate correctly),I don't know why,can anyone give some advice on writing interupt handler or send me a copy of ac97 driver with interrupt mode? thanks a lot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070701/6e2e48ef/attachment.htm 

From blackfin.kang at gmail.com  Mon Jul  2 00:24:16 2007
From: blackfin.kang at gmail.com (kang shuo)
Date: Sun, 1 Jul 2007 22:24:16 +0800
Subject: A question about man_page in linux-kernel
Message-ID: <a7f827420707010724g7ebd9920weab2fc5af9c98899@mail.gmail.com>

hi:
    I had read some ppc code in linux-2.6.20. There is a question
about map_page function. map_page seems to implement the map between
virtual address and physical address. But I can not understand how the
tlb entry operation is done in the code in map_page. The map_page is
as the following:

int
map_page(unsigned long va, phys_addr_t pa, int flags)
{
       pmd_t *pd;
       pte_t *pg;
       int err = -ENOMEM;

       /* Use upper 10 bits of VA to index the first level map */
       pd = pmd_offset(pgd_offset_k(va), va);
       /* Use middle 10 bits of VA to index the second-level map */
       pg = pte_alloc_kernel(pd, va);
       if (pg != 0) {
               err = 0;
               set_pte_at(&init_mm, va, pg, pfn_pte(pa >> PAGE_SHIFT,
__pgprot(flags)));
               if (mem_init_done)
                       flush_HPTE(0, va, pmd_val(*pd));
       }
       return err;
}

       Could anyone give me some hints about where and when tlb entry
is setup according to map_page function. That is very appreciate.

-- Thanks
-- Michael.Kang


From ylin at airvana.com  Mon Jul  2 12:49:34 2007
From: ylin at airvana.com (Ying Lin)
Date: Sun, 1 Jul 2007 22:49:34 -0400
Subject: Anyone using QE UART mode?  
Message-ID: <8F798BFDA851B943B3A1B2510E9287850350A905@airmail.wirelessworld.airvananet.com>

How to enable TTY devices using QUICC Engine UCC UART Mode?

Are Linux kernel patches enough to enable them?  Or, additional
programming required?

 

The kernel has QE patches, and I am able to use QE Ethernet.  Also, I
can choose the QE slow UART mode in kernel configurations.  But, can not
see TTY devices from QE.

 

Thanks,

Ying

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070701/da081856/attachment.htm 

From keng_629 at 126.com  Mon Jul  2 19:08:55 2007
From: keng_629 at 126.com (=?gbk?B?s8LL1e+s?=)
Date: Mon, 02 Jul 2007 17:08:55 +0800
Subject: No subject
Message-ID: <op.tutyc5hxn9m0t0@chensukeng>






From smdelusa at gmail.com  Mon Jul  2 19:50:50 2007
From: smdelusa at gmail.com (SHIERA LYN DELUSA)
Date: Mon, 2 Jul 2007 18:50:50 +0900
Subject: Linux Process Address Space
Message-ID: <1a866be30707020250p7145b143j71042c3b115d01c4@mail.gmail.com>

Hello,

Based on the following thread regarding Linux memory map:
http://ozlabs.org/pipermail/linuxppc-embedded/2000-May/001333.html

Obviously, I am still a newbie in Linux kernel and I find it hard to grasp
things especially Linux MM.  I quoted some lines from this thread (from
Dan's post), then some follow-up questions.  I do hope you could help me out
in these:

1.)  *"Virtual addresses from 0 to 0x7fffffff are for user context."*
     a.) If TASK_SIZE is defined as 0x80000000, does this necessarily mean
that 2G-2G split is used?


2.)  *"For this reason, and since it followed prior PowerPC platform
examples, I chose to map the embedded 8xx kernel to the 0xc0000000 virtual
address."*
     a.)  This 0xc0000000 virtual address must be defined as the value of
PAGE_OFFSET, right?
     b.)  Does this mean that the kernel's .text section is located in this
address?
     c.)  If user space is only up to 0x80000000, and the kernel starts at
0xc0000000, what could possibly be located in between?


3.)  *"Prior to this KVM initialization, we choose to map virtual to
physical addresses 1:1.  That is, the kernel virtual address exactly matches
the physical address on the bus.  These mappings are typically done in
arch/ppc/kernel/head.S, or arch/ppc/mm/init.c.  Only   absolutely necessary
mappings should be done at this time, for example board control registers or
a serial uart.  Normal device driver initialization should map resources
later when necessary." *
      a.)  Is there any chance that the mapping done here is relocated later
in the initialization process?


I would really appreciate your input on this.  Thank you very much!


Regards,
Shiera
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070702/f742be3e/attachment.htm 

From timur at freescale.com  Tue Jul  3 01:40:27 2007
From: timur at freescale.com (Timur Tabi)
Date: Mon, 02 Jul 2007 10:40:27 -0500
Subject: Anyone using QE UART mode?
In-Reply-To: <8F798BFDA851B943B3A1B2510E9287850350A905@airmail.wirelessworld.airvananet.com>
References: <8F798BFDA851B943B3A1B2510E9287850350A905@airmail.wirelessworld.airvananet.com>
Message-ID: <46891C6B.3090507@freescale.com>

Ying Lin wrote:
> How to enable TTY devices using QUICC Engine UCC UART Mode?
> 
> Are Linux kernel patches enough to enable them?  Or, additional 
> programming required?

I'm working on a device driver for QE UART mode, but it's not working yet.  The QE UART is 
like the CPM UART, but I'm having troubel getting it to work.

It is *not* trivial, or even easy, to enabled.  It's a full-blown UART driver that also 
deals with the complexity of the QE.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale


From ylin at airvana.com  Tue Jul  3 02:01:56 2007
From: ylin at airvana.com (Ying Lin)
Date: Mon, 2 Jul 2007 12:01:56 -0400
Subject: Anyone using QE UART mode?
In-Reply-To: <46891C6B.3090507@freescale.com>
Message-ID: <8F798BFDA851B943B3A1B2510E9287850350A908@airmail.wirelessworld.airvananet.com>

OK, the missing piece (UART driver) I am looking for is not available
yet.  I will seek alternative solutions (create a simple UART driver, or
just wait).
Thanks for the information. 
Ying 

-----Original Message-----
From: Timur Tabi [mailto:timur at freescale.com] 
Sent: Monday, July 02, 2007 11:40 AM
To: Ying Lin
Cc: linuxppc-embedded at ozlabs.org
Subject: Re: Anyone using QE UART mode?

Ying Lin wrote:
> How to enable TTY devices using QUICC Engine UCC UART Mode?
> 
> Are Linux kernel patches enough to enable them?  Or, additional 
> programming required?

I'm working on a device driver for QE UART mode, but it's not working
yet.  The QE UART is 
like the CPM UART, but I'm having troubel getting it to work.

It is *not* trivial, or even easy, to enabled.  It's a full-blown UART
driver that also 
deals with the complexity of the QE.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale


From nhickman at dtechlabs.com  Tue Jul  3 04:41:13 2007
From: nhickman at dtechlabs.com (Nicholas Hickman)
Date: Mon, 2 Jul 2007 14:41:13 -0400
Subject: mpc8270 & Intel 82551ER on 2.6.17.14
In-Reply-To: <f87351060706290112o407f75e5h9dffd9939ab80ef9@mail.gmail.com>
References: <8140AAF341CC904BA92C3D6A5A1909782A2FA3@ditech-1.ditechllc.com>
	<f87351060706290112o407f75e5h9dffd9939ab80ef9@mail.gmail.com>
Message-ID: <8140AAF341CC904BA92C3D6A5A1909782A300A@ditech-1.ditechllc.com>

Pradyumna,

With the help of some others I have finally figured it out.  I took a
step back and read the manual over and over along with debugging my
U-boot until it worked.  My issue there was with the SIUMCR. Since I now
had that working in U-boot I moved on to the kernel where I found that I
was redefining the SIUMCR here:

arch/ppc/syslib/m82xx_pci.c 
approx line 248
#elif defined CONFIG_PQ2FADS || MYBOARD
        /*
         * Setting required to enable IRQ1-IRQ7 (SIUMCR [DPPC]),
         * and local bus for PCI (SIUMCR [LBPC]).
         */
        immap->im_siu_conf.siu_82xx.sc_siumcr =

I was entering this routine since I was basing my config off of the
PQ2FADS board.  I removed my board definition from the elif and
everything seems to be working fine.

Good luck!


-Nick


-----Original Message-----
From: Pradyumna Sampath [mailto:pradyumna.sampath at gmail.com] 
Sent: Friday, June 29, 2007 4:12 AM
To: Nicholas Hickman
Cc: linuxppc-embedded at ozlabs.org
Subject: Re: mpc8270 & Intel 82551ER on 2.6.17.14

Hi Nicholas,

On 6/29/07, Nicholas Hickman <nhickman at dtechlabs.com> wrote:
>
>
> I am having trouble getting two 82551ER Ethernet controllers running 
> in Linux.  I am able to scan the PCI bus and see the devices and I was

> even able to program the EEPROM from U-boot.
>
> In the kernel I mapped the IRQ's through /arch/ppc/m82xx_pci.c.  I've 
> been using the e100 drive that comes with the 2.6.17.14 kernel and 
> have also tried the driver directly from Intel.  Both give the same 
> results.  The PCI scan shows the correct output for how the device
should be configured.
<snip..>

I have the same, exact same problem. But there are some of the
differences with the setup though. I have an MPC5200B and the other
difference is that I have a 2.6.21-rt3. However its the same ethernet
controller.

I am trying out a few things here, some of them being complete guesses.
But if I hit something, I will let this list know. Anyone else had
similar issues ? Request you to please holler.

regards
prady
--
htp://prady.livejournal.com


From khollan at daktronics.com  Tue Jul  3 06:58:42 2007
From: khollan at daktronics.com (khollan)
Date: Mon, 2 Jul 2007 13:58:42 -0700 (PDT)
Subject: Porting Linux to Xilinx ML410
In-Reply-To: <11328063.post@talk.nabble.com>
References: <11328063.post@talk.nabble.com>
Message-ID: <11401755.post@talk.nabble.com>


Im trying to mount the root file system off of compact flash and now I get
this happening during boot

xsysace xsa: kicking stalled fsm; state=2 task=0 iter=1 dc=0
xsysace xsa: kicking stalled fsm; state=2 task=0 iter=1 dc=0
xsysace xsa: kicking stalled fsm; state=2 task=0 iter=1 dc=0

any ideas what this is and how to fix it?  I tried applying a patch that
talked about this but my version of xsysace.c already had those changes.

Thanks

Kevin
-- 
View this message in context: http://www.nabble.com/Porting-Linux-to-Xilinx-ML410-tf3989483.html#a11401755
Sent from the linuxppc-embedded mailing list archive at Nabble.com.



From grant.likely at secretlab.ca  Tue Jul  3 08:51:59 2007
From: grant.likely at secretlab.ca (Grant Likely)
Date: Mon, 2 Jul 2007 16:51:59 -0600
Subject: Porting Linux to Xilinx ML410
In-Reply-To: <11401755.post@talk.nabble.com>
References: <11328063.post@talk.nabble.com> <11401755.post@talk.nabble.com>
Message-ID: <fa686aa40707021551y469e1b7fv3b8c329b904b3d6@mail.gmail.com>

On 7/2/07, khollan <khollan at daktronics.com> wrote:
>
> Im trying to mount the root file system off of compact flash and now I get
> this happening during boot
>
> xsysace xsa: kicking stalled fsm; state=2 task=0 iter=1 dc=0
> xsysace xsa: kicking stalled fsm; state=2 task=0 iter=1 dc=0
> xsysace xsa: kicking stalled fsm; state=2 task=0 iter=1 dc=0
>
> any ideas what this is and how to fix it?  I tried applying a patch that
> talked about this but my version of xsysace.c already had those changes.

It means the driver is not getting interrupts from the systemace
device, so it's reverting to (extremely slow) polling.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195


From bgholikh at cisco.com  Tue Jul  3 10:04:28 2007
From: bgholikh at cisco.com (Bizhan Gholikhamseh (bgholikh))
Date: Mon, 2 Jul 2007 17:04:28 -0700
Subject: help on dts compiler please.
Message-ID: <F795765B112E7344AF36AA911279641502D1A454@xmb-sjc-212.amer.cisco.com>

Hi 
I have downloaded the latest Linux code from the following git tree:
git:// git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
 
I have also installed dtc compiler version.
I am trying to create dtb file from mpc8541cds.dts.
I ran the following command and get error:
 
$ dtc -f -I dts -O dtb mpc8541cds.dts
DTC: dts->dtb  on file "mpc8541cds.dts"
syntax error at line 15
FATAL ERROR: Couldn't read input tree

 
Many thanks in advance,
Bizhan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070702/8ed41d60/attachment.htm 

From sprasad at bivio.net  Tue Jul  3 10:13:13 2007
From: sprasad at bivio.net (Siva Prasad)
Date: Mon, 2 Jul 2007 17:13:13 -0700
Subject: insmod - Bad address
Message-ID: <D83235F0F3C86D4D889D8B9A0DA8C6D7808797@corpexc01.corp.networkrobots.com>

Hi,

When I try to do insmod or modprobe, I get "Bad Address". I don't
exactly understand what this is, and how to take care of this.

Any ideas. Appreciate any help.

=============================
modprobe: FATAL: Error inserting binfmt_misc
(/lib/modules/2.6.15-9bvoem50npc3/kernel/fs/binfmt_misc.ko): Bad address

modprobe: FATAL: Error running install command for binfmt_misc
=============================

Thanks
Siva



From jwboyer at jdub.homelinux.org  Tue Jul  3 11:33:24 2007
From: jwboyer at jdub.homelinux.org (Josh Boyer)
Date: Mon, 02 Jul 2007 20:33:24 -0500
Subject: help on dts compiler please.
In-Reply-To: <F795765B112E7344AF36AA911279641502D1A454@xmb-sjc-212.amer.cisco.com>
References: <F795765B112E7344AF36AA911279641502D1A454@xmb-sjc-212.amer.cisco.com>
Message-ID: <1183426404.5643.0.camel@vader.jdub.homelinux.org>

On Mon, 2007-07-02 at 17:04 -0700, Bizhan Gholikhamseh (bgholikh) wrote:
> Hi 
> I have downloaded the latest Linux code from the following git tree:
> git:// git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
>  
> I have also installed dtc compiler version.
> I am trying to create dtb file from mpc8541cds.dts.
> I ran the following command and get error:
>  
> $ dtc -f -I dts -O dtb mpc8541cds.dts
> DTC: dts->dtb  on file "mpc8541cds.dts"
> syntax error at line 15
> FATAL ERROR: Couldn't read input tree

Where did you get your dtc version from?

josh




From bgholikh at cisco.com  Tue Jul  3 11:41:42 2007
From: bgholikh at cisco.com (Bizhan Gholikhamseh (bgholikh))
Date: Mon, 2 Jul 2007 18:41:42 -0700
Subject: help on dts compiler please.
In-Reply-To: <1183426404.5643.0.camel@vader.jdub.homelinux.org>
Message-ID: <F795765B112E7344AF36AA911279641502D1A458@xmb-sjc-212.amer.cisco.com>

 

> -----Original Message-----
> From: Josh Boyer [mailto:jwboyer at jdub.homelinux.org] 
> Sent: Monday, July 02, 2007 6:33 PM
> To: Bizhan Gholikhamseh (bgholikh)
> Cc: linuxppc-embedded at ozlabs.org
> Subject: Re: help on dts compiler please.
> 
> On Mon, 2007-07-02 at 17:04 -0700, Bizhan Gholikhamseh 
> (bgholikh) wrote:
> > Hi
> > I have downloaded the latest Linux code from the following git tree:
> > git:// git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
> >  
> > I have also installed dtc compiler version.
> > I am trying to create dtb file from mpc8541cds.dts.
> > I ran the following command and get error:
> >  
> > $ dtc -f -I dts -O dtb mpc8541cds.dts
> > DTC: dts->dtb  on file "mpc8541cds.dts"
> > syntax error at line 15
> > FATAL ERROR: Couldn't read input tree
> 
> Where did you get your dtc version from?

I got it from the git tree two days ago:git://
git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git

I have attached the file.
It appears it complains about "compatibility" property on all the dts
file.

Thanks,
Bizhan

> 
> josh
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mpc8541cds.dts
Type: application/octet-stream
Size: 5798 bytes
Desc: mpc8541cds.dts
Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070702/3b83c0d1/attachment.obj 

From bgholikh at cisco.com  Tue Jul  3 11:49:15 2007
From: bgholikh at cisco.com (Bizhan Gholikhamseh (bgholikh))
Date: Mon, 2 Jul 2007 18:49:15 -0700
Subject: help on dts compiler please.
In-Reply-To: <1183426404.5643.0.camel@vader.jdub.homelinux.org>
Message-ID: <F795765B112E7344AF36AA911279641502D1A45A@xmb-sjc-212.amer.cisco.com>

 
> > $ dtc -f -I dts -O dtb mpc8541cds.dts
> > DTC: dts->dtb  on file "mpc8541cds.dts"
> > syntax error at line 15
> > FATAL ERROR: Couldn't read input tree
> 
> Where did you get your dtc version from?
> 
Sorry I answered the question wrong. I downloaded the gzip tar file from
David Gibson web page.

> josh
> 


From silicom at 163.com  Tue Jul  3 12:22:43 2007
From: silicom at 163.com (silicom)
Date: Tue, 3 Jul 2007 10:22:43 +0800 (CST)
Subject: Can anyone help me about ac97 driver
Message-ID: <1329478984.2865871183429363889.JavaMail.coremail@bj163app129.163.com>

 Hi    I'm writing an ac97 driver with interrupt mode on xilinx ml403 and linux 2.6.17.1 platform but encounter a incredible problem,can anyone send me a copy of the driver code.  thanks sincerely.  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070703/1ca11945/attachment.htm 

From dale at farnsworth.org  Tue Jul  3 12:31:18 2007
From: dale at farnsworth.org (Dale Farnsworth)
Date: 2 Jul 2007 19:31:18 -0700
Subject: help on dts compiler please.
In-Reply-To: <F795765B112E7344AF36AA911279641502D1A45A@xmb-sjc-212.amer.cisco.com>
References: <1183426404.5643.0.camel@vader.jdub.homelinux.org>
Message-ID: <20070703023118.30095.qmail@farnsworth.org>

> > > $ dtc -f -I dts -O dtb mpc8541cds.dts
> > > DTC: dts->dtb  on file "mpc8541cds.dts"
> > > syntax error at line 15
> > > FATAL ERROR: Couldn't read input tree
> > 
> > Where did you get your dtc version from?
> > 
> Sorry I answered the question wrong. I downloaded the gzip tar file from
> David Gibson web page.

That same web page says that the latest version of the web page is
at git://www.jdl.com/software/dtc.git

Try the current version available there.

-Dale Farnsworth


From jwboyer at jdub.homelinux.org  Tue Jul  3 12:32:20 2007
From: jwboyer at jdub.homelinux.org (Josh Boyer)
Date: Mon, 02 Jul 2007 21:32:20 -0500
Subject: help on dts compiler please.
In-Reply-To: <F795765B112E7344AF36AA911279641502D1A45A@xmb-sjc-212.amer.cisco.com>
References: <F795765B112E7344AF36AA911279641502D1A45A@xmb-sjc-212.amer.cisco.com>
Message-ID: <1183429940.9030.1.camel@vader.jdub.homelinux.org>

On Mon, 2007-07-02 at 18:49 -0700, Bizhan Gholikhamseh (bgholikh) wrote:
> > > $ dtc -f -I dts -O dtb mpc8541cds.dts
> > > DTC: dts->dtb  on file "mpc8541cds.dts"
> > > syntax error at line 15
> > > FATAL ERROR: Couldn't read input tree
> > 
> > Where did you get your dtc version from?
> > 
> Sorry I answered the question wrong. I downloaded the gzip tar file from
> David Gibson web page.

That is a very out of date dtc.  Try using the one found here:

git://www.jdl.com/software/dtc.git

josh



From grant.likely at secretlab.ca  Tue Jul  3 13:36:53 2007
From: grant.likely at secretlab.ca (Grant Likely)
Date: Mon, 2 Jul 2007 21:36:53 -0600
Subject: Can anyone help me about ac97 driver
In-Reply-To: <1329478984.2865871183429363889.JavaMail.coremail@bj163app129.163.com>
References: <1329478984.2865871183429363889.JavaMail.coremail@bj163app129.163.com>
Message-ID: <fa686aa40707022036m1abdc1f7l33062e240be5304a@mail.gmail.com>

On 7/2/07, silicom <silicom at 163.com> wrote:
>
> Hi
>     I'm writing an ac97 driver with interrupt mode on xilinx ml403 and linux
> 2.6.17.1 platform but encounter a incredible problem,can anyone send me a
> copy of the driver code.

I think there is a driver in MontaVista's 2.4 tree, but I haven't used
it and don't know how well it works.

http://penguinppc.org/kernel/#historical

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195


From mls.JOFT at gmx.de  Tue Jul  3 16:21:55 2007
From: mls.JOFT at gmx.de (Joachim =?ISO-8859-1?Q?F=F6rster?=)
Date: Tue, 03 Jul 2007 08:21:55 +0200
Subject: Can anyone help me about ac97 driver
In-Reply-To: <1329478984.2865871183429363889.JavaMail.coremail@bj163app129.163.com>
References: <1329478984.2865871183429363889.JavaMail.coremail@bj163app129.163.com>
Message-ID: <1183443715.5645.19.camel@localhost>

Hi silicom,

On Tue, 2007-07-03 at 10:22 +0800, silicom wrote:
>     I'm writing an ac97 driver with interrupt mode on xilinx ml403 and
> linux 2.6.17.1 platform but encounter a incredible problem,can anyone
> send me a copy of the driver code.

I read your previous mails (about a problem with the interrupt handler).
Mainly in the last few days/week I wrote an (ALSA) driver for the
"Xilinx ML403 AC97 Controller Ref", too (ATM playback part only, no
record).
And I didn't encounter problems such as your problem. The only
difference I see, is, that I don't have an explicit "write process": INT
is thrown => INT handler: loop, copy data to the FIFO until full =>
return from INT handler.

I had serious problems with the "Register Access Finished" bit, which
stops working after (average) ~80 codec register accesses (bit remains
0).

My driver is "working" since yesterday evening ;-) ... so I feel a bit
uncertain about "releasing" it to the public right now. I'm willing to
post/contribute my driver, but that will have to wait some more days/a
week ;-) ...

BTW: Is your driver an ALSA driver, too? Or is it an OSS driver?

 Joachim


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070703/29262f70/attachment.pgp 

From domen.puncer at telargo.com  Tue Jul  3 18:27:38 2007
From: domen.puncer at telargo.com (Domen Puncer)
Date: Tue, 3 Jul 2007 10:27:38 +0200
Subject: [PATCH] pata_mpc52xx: suspend/resume support
Message-ID: <20070703082738.GM23294@moe.telargo.com>

Implement suspend and resume routines for mpc52xx ata driver.
Tested on Lite5200b with deep-sleep and low-power (not yet in-tree)
modes.


Signed-off-by: Domen Puncer <domen.puncer at telargo.com>

---
If anyone cares, I attached ATA_DEBUG messages at the end of patch.
Should it take almost 5 seconds?


 drivers/ata/pata_mpc52xx.c |   18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

Index: work-powerpc.git/drivers/ata/pata_mpc52xx.c
===================================================================
--- work-powerpc.git.orig/drivers/ata/pata_mpc52xx.c
+++ work-powerpc.git/drivers/ata/pata_mpc52xx.c
@@ -467,13 +467,27 @@ mpc52xx_ata_remove(struct of_device *op)
 static int
 mpc52xx_ata_suspend(struct of_device *op, pm_message_t state)
 {
-	return 0;	/* FIXME : What to do here ? */
+	struct ata_host *host = dev_get_drvdata(&op->dev);
+
+	return ata_host_suspend(host, state);
 }
 
 static int
 mpc52xx_ata_resume(struct of_device *op)
 {
-	return 0;	/* FIXME : What to do here ? */
+	struct ata_host *host = dev_get_drvdata(&op->dev);
+	struct mpc52xx_ata_priv *priv = host->private_data;
+	int rv;
+
+	rv = mpc52xx_ata_hw_init(priv);
+	if (rv) {
+		printk(KERN_ERR DRV_NAME ": Error during HW init\n");
+		return rv;
+	}
+
+	ata_host_resume(host);
+
+	return 0;
 }
 
 #endif


[ 1039.434045] Stopping tasks ... done.
[ 1039.438193] Suspending console(s)
[ 1039.441662] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 1039.441749] ata_scsi_dump_cdb: CDB (1:0,0,0) 35 00 00 00 00 00 00 00 00
[ 1039.441817] ata_exec_command: ata1: cmd 0xE7
[ 1039.442191] ata_hsm_move: ata1: protocol 1 task_state 3 (dev_stat 0x50)
[ 1039.442208] ata_hsm_move: ata1: dev 0 command complete, drv_stat 0x50
[ 1039.442310] sd 0:0:0:0: [sda] Stopping disk
[ 1039.442378] ata_scsi_dump_cdb: CDB (1:0,0,0) 1b 00 00 00 00 00 00 00 00
[ 1039.442442] ata_exec_command: ata1: cmd 0xE0
[ 1039.442738] ata_hsm_move: ata1: protocol 1 task_state 3 (dev_stat 0x50)
[ 1039.442754] ata_hsm_move: ata1: dev 0 command complete, drv_stat 0x50
[ 1039.442881] usb_endpoint usbdev1.1_ep81: PM: suspend 0->2, parent 1-0:1.0 already 2
[ 1039.442903] hub 1-0:1.0: PM: suspend 2->2, parent usb1 already 2
[ 1039.442919] usb_endpoint usbdev1.1_ep00: PM: suspend 0->2, parent usb1 already 2
[ 1039.444022] ata_port_schedule_eh: port EH scheduled
[ 1039.444056] ata_scsi_error: ENTER
[ 1039.444065] ata_port_flush_task: ENTER
[ 1039.444074] ata_port_flush_task: flush #1
[ 1039.444087] ata1: ata_port_flush_task: flush #2
[ 1039.444097] ata1: ata_port_flush_task: EXIT
[ 1039.444116] ata_eh_autopsy: ENTER
[ 1039.444133] ata_eh_autopsy: EXIT
[ 1039.444141] ata_eh_recover: ENTER
[ 1039.444151] ata_eh_revalidate_and_attach: ENTER
[ 1039.444162] ata_eh_recover: EXIT, rc=0
[ 1039.444179] __ata_port_freeze: ata1 port frozen
[ 1039.444198] ata_scsi_error: EXIT
[ 1039.447207] ata_port_schedule_eh: port EH scheduled
[ 1039.447270] eth0: Phy @ 0x0, type LXT971 (0x001378e2)
[ 1039.448257] usb_endpoint usbdev1.1_ep00: PM: resume from 0, parent usb1 still 2
[ 1039.448276] usb_endpoint usbdev1.1_ep81: PM: resume from 0, parent 1-0:1.0 still 2
[ 1039.448306] sd 0:0:0:0: [sda] Starting disk
[ 1039.448384] ata_scsi_error: ENTER
[ 1039.448398] ata_port_flush_task: ENTER
[ 1039.448407] ata_port_flush_task: flush #1
[ 1039.448420] ata1: ata_port_flush_task: flush #2
[ 1039.448430] ata1: ata_port_flush_task: EXIT
[ 1039.448451] ata_eh_autopsy: ENTER
[ 1039.448467] ata_eh_recover: ENTER
[ 1039.448481] __ata_port_freeze: ata1 port frozen
[ 1039.956600] ata_std_softreset: ENTER
[ 1039.956648] ata_std_softreset: about to softreset, devmask=3
[ 1039.956661] ata_bus_softreset: ata1: bus reset via SRST
[ 1040.107612] ata_dev_classify: found ATA device by sig
[ 1040.107643] ata_dev_classify: found ATA device by sig
[ 1040.107656] ata_std_softreset: EXIT, classes[0]=1 [1]=5
[ 1040.107667] ata_std_postreset: ENTER
[ 1040.107680] ata_std_postreset: EXIT
[ 1040.107708] ata_eh_thaw_port: ata1 port thawed
[ 1040.107717] ata_eh_revalidate_and_attach: ENTER
[ 1040.107732] ata1.00: ata_dev_read_id: ENTER
[ 1040.107833] ata_exec_command: ata1: cmd 0xEC
[ 1040.110597] ata_hsm_move: ata1: protocol 2 task_state 2 (dev_stat 0x58)
[ 1040.110616] ata_pio_sector: data read
[ 1040.110852] ata_hsm_move: ata1: protocol 2 task_state 3 (dev_stat 0x50)
[ 1040.110867] ata_hsm_move: ata1: dev 0 command complete, drv_stat 0x50
[ 1040.110920] ata_port_flush_task: ENTER
[ 1040.110929] ata_port_flush_task: flush #1
[ 1040.110941] ata1: ata_port_flush_task: flush #2
[ 1040.110952] ata1: ata_port_flush_task: EXIT
[ 1040.111032] ata_dev_set_xfermode: set features - xfer mode
[ 1040.111102] ata_exec_command: ata1: cmd 0xEF
[ 1040.111263] ata_hsm_move: ata1: protocol 1 task_state 3 (dev_stat 0x50)
[ 1040.111281] ata_hsm_move: ata1: dev 0 command complete, drv_stat 0x50
[ 1040.111329] ata_port_flush_task: ENTER
[ 1040.111339] ata_port_flush_task: flush #1
[ 1040.111351] ata1: ata_port_flush_task: flush #2
[ 1040.111361] ata1: ata_port_flush_task: EXIT
[ 1040.111373] ata_dev_set_xfermode: EXIT, err_mask=0
[ 1040.111385] ata1.00: ata_dev_read_id: ENTER
[ 1040.111474] ata_exec_command: ata1: cmd 0xEC
[ 1040.114596] ata_hsm_move: ata1: protocol 2 task_state 2 (dev_stat 0x58)
[ 1040.114615] ata_pio_sector: data read
[ 1040.114713] ata_hsm_move: ata1: protocol 2 task_state 3 (dev_stat 0x50)
[ 1040.114727] ata_hsm_move: ata1: dev 0 command complete, drv_stat 0x50
[ 1040.114775] ata_port_flush_task: ENTER
[ 1040.114784] ata_port_flush_task: flush #1
[ 1040.114796] ata1: ata_port_flush_task: flush #2
[ 1040.114806] ata1: ata_port_flush_task: EXIT
[ 1040.114861] ata_dev_set_mode: xfer_shift=0, xfer_mode=0xc
[ 1040.114873] ata1.00: configured for PIO4
[ 1040.114883] ata_eh_recover: EXIT, rc=0
[ 1040.114907] ata_scsi_error: EXIT
[ 1040.114957] ata_scsi_dump_cdb: CDB (1:0,0,0) 00 00 00 00 00 00 00 00 00
[ 1040.115051] ata_scsi_dump_cdb: CDB (1:0,0,0) 1b 00 00 00 01 00 00 00 00
[ 1040.115118] ata_exec_command: ata1: cmd 0x40
[ 1043.605018] ata_hsm_move: ata1: protocol 1 task_state 3 (dev_stat 0x50)
[ 1043.605039] ata_hsm_move: ata1: dev 0 command complete, drv_stat 0x50
[ 1043.605128] ata_scsi_dump_cdb: CDB (1:0,0,0) 25 00 00 00 00 00 00 00 00
[ 1043.990208] Restarting tasks ... done.
[ 1043.995913] sd 0:0:0:0: [sda] 8404830 512-byte hardware sectors (4303 MB)
[ 1044.004169] ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 3f 00 00 00 00 00 08
[ 1044.011083] sd 0:0:0:0: [sda] Write Protect is off
[ 1044.016047] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 1044.016134] ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 08 00 00 00 00 00 08
[ 1044.023085] ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 08 00 00 00 00 00 24
[ 1044.029978] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA



From LeoLi at freescale.com  Tue Jul  3 18:32:42 2007
From: LeoLi at freescale.com (Li Yang-r58472)
Date: Tue, 3 Jul 2007 16:32:42 +0800
Subject: Anyone using QE UART mode?
In-Reply-To: <8F798BFDA851B943B3A1B2510E9287850350A908@airmail.wirelessworld.airvananet.com>
Message-ID: <989B956029373F45A0B8AF0297081890D83844@zch01exm26.fsl.freescale.net>

> -----Original Message-----
> From: linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org
> [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org] On
Behalf
> Of Ying Lin
> Sent: Tuesday, July 03, 2007 12:02 AM
> To: Tabi Timur-B04825
> Cc: linuxppc-embedded at ozlabs.org
> Subject: RE: Anyone using QE UART mode?
> 
> OK, the missing piece (UART driver) I am looking for is not available
> yet.  I will seek alternative solutions (create a simple UART driver,
or
> just wait).

Which chip are you using?  There should be separate 16550 compatible
UART controller on MPC8360.  The driver is already there and working
pretty well.

- Leo


From b_kisku at yahoo.co.in  Tue Jul  3 21:23:25 2007
From: b_kisku at yahoo.co.in (Barisa kisku)
Date: Tue, 3 Jul 2007 12:23:25 +0100 (BST)
Subject: NFS mounting problem in mpc860 based board
Message-ID: <566752.34558.qm@web8506.mail.in.yahoo.com>

hi,

I have ported u-boot 1.1.6 in a custom board based on
mpc860.using "tftpboot" command Linux kernel uImage is
downloaded.And it was run with "bootm" command and
controls are transfered to linux properly.

While kernel is mounting root file system through nfs
it is not able to send the message properly.By
observing through "Ethereal" at server machine, no ARP
message is reaching.

Print coming in console of embedded system is:
portmap: "Unable to get port number for  nfsd of
server"

But i am able to mount the file system in the given
server from other machine in the LAN.

Again by looking at the status of the BDs it seems
that the ethernet driver is sending message properly
to the LAN.

If anybody has come across this type of problem,
please help me in debugging.

Thanks in advance.

Regards,
Barisa Kisku







		
__________________________________________________________
Yahoo! India Answers: Share what you know. Learn something new
http://in.answers.yahoo.com/


From ylin at airvana.com  Tue Jul  3 23:15:51 2007
From: ylin at airvana.com (Ying Lin)
Date: Tue, 3 Jul 2007 09:15:51 -0400
Subject: Anyone using QE UART mode?
In-Reply-To: <989B956029373F45A0B8AF0297081890D83844@zch01exm26.fsl.freescale.net>
Message-ID: <8F798BFDA851B943B3A1B2510E9287850350A90D@airmail.wirelessworld.airvananet.com>



> Which chip are you using?  There should be separate 16550 compatible
> UART controller on MPC8360.  The driver is already there and working
> pretty well.

We are using MPC8323E.  We have 2 working serial ports from the DUART
controller, but we need more than 2.

We have about 4 weeks to make them working, any suggestion where to
start?  We plan to start with CW QE Utility generated codes.

Thanks,
Ying


From timur at freescale.com  Wed Jul  4 00:59:13 2007
From: timur at freescale.com (Timur Tabi)
Date: Tue, 03 Jul 2007 09:59:13 -0500
Subject: Anyone using QE UART mode?
In-Reply-To: <8F798BFDA851B943B3A1B2510E9287850350A90D@airmail.wirelessworld.airvananet.com>
References: <8F798BFDA851B943B3A1B2510E9287850350A90D@airmail.wirelessworld.airvananet.com>
Message-ID: <468A6441.105@freescale.com>

Ying Lin wrote:
> 
>> Which chip are you using?  There should be separate 16550 compatible
>> UART controller on MPC8360.  The driver is already there and working
>> pretty well.
> 
> We are using MPC8323E.  We have 2 working serial ports from the DUART
> controller, but we need more than 2.
> 
> We have about 4 weeks to make them working, any suggestion where to
> start?  We plan to start with CW QE Utility generated codes.

Have you tried using a PCI UART card?

-- 
Timur Tabi
Linux Kernel Developer @ Freescale


From ylin at airvana.com  Wed Jul  4 01:11:43 2007
From: ylin at airvana.com (Ying Lin)
Date: Tue, 3 Jul 2007 11:11:43 -0400
Subject: Anyone using QE UART mode?
In-Reply-To: <468A6441.105@freescale.com>
Message-ID: <8F798BFDA851B943B3A1B2510E9287850350A90E@airmail.wirelessworld.airvananet.com>


> Have you tried using a PCI UART card?

No, the hardware is fixed to use UCC4/5.



From kari.davidsson at marel.is  Wed Jul  4 00:54:20 2007
From: kari.davidsson at marel.is (=?iso-8859-1?B?S+FyaSBEYXbt8HNzb24=?=)
Date: Tue, 3 Jul 2007 14:54:20 -0000
Subject: OF devices and non OF devices
Message-ID: <DD39B5C3F4963040ADC9768BE7E430CB020D3B9D@is-hdq-exchange.marel.net>

Hi,

I am attempting to get some non OF devices working for an mpc 5200 board, in particular 
PCF8563 RTC.

This device has an non OF device interface which I believe is correct. After all it should work
on non OF platforms.

I have managed to get the board to run the i2c initialization (and probe) for the fsl-mpc i2c driver by
converting the fsl-mpc i2c driver to OF driver (I found some patch here that I based this work on).

Since the PCF8563 driver is not OF driver only its initaliziation code is run but the .probe function
of the driver is never run. Basically (as far as I can understand) the .probe is never run because the
driver is not an OF driver.

I could convert the PCF8563 driver to OF driver and make it work for our puposes but I feel this is
1) Wrong
2) therefore wasted work.

What seems to elude me is some glue that glues together the OF part of the driver space to the non OF part
of the driver space.

Any hints or pointers on where to find this glue?

Regards,
kd

P.S. Kernel is post 2.6.20.

-- 
K?ri Dav??sson                   | kari.davidsson at marel.is
Hugb?na?arger?                   | www.marel.com
Tel: 563-8156 Fax: +354 563 8001
Iceland


From jcrigby at gmail.com  Wed Jul  4 02:31:00 2007
From: jcrigby at gmail.com (John Rigby)
Date: Tue, 3 Jul 2007 10:31:00 -0600
Subject: OF devices and non OF devices
In-Reply-To: <DD39B5C3F4963040ADC9768BE7E430CB020D3B9D@is-hdq-exchange.marel.net>
References: <DD39B5C3F4963040ADC9768BE7E430CB020D3B9D@is-hdq-exchange.marel.net>
Message-ID: <4b73d43f0707030931v42aefc72x2598546e48ae87e8@mail.gmail.com>

One place to find binding between OF devices and non OF devices is in
arch/powerpc/sysdev/fsl_soc.c
The typical pattern is:
    if of_find_compatible_node "of-device-name"
        platform_device_register_simple ""platform-device-name"
        platform_device_add_data ...


On 7/3/07, K?ri Dav??sson <kari.davidsson at marel.is> wrote:
>
> Hi,
>
> I am attempting to get some non OF devices working for an mpc 5200 board,
> in particular
> PCF8563 RTC.
>
> This device has an non OF device interface which I believe is correct.
> After all it should work
> on non OF platforms.
>
> I have managed to get the board to run the i2c initialization (and probe)
> for the fsl-mpc i2c driver by
> converting the fsl-mpc i2c driver to OF driver (I found some patch here
> that I based this work on).


fsl-i2c is one of the devices handled by fsl_soc.c so you shouldn't need to
change anything to
make it work in the latest kernel.  CONFIG_FSL_SOC was only added to
lite5200_defconfig recently so
that may explain why it's not on in your kernel.

Since the PCF8563 driver is not OF driver only its initaliziation code is
> run but the .probe function
> of the driver is never run. Basically (as far as I can understand) the
> .probe is never run because the
> driver is not an OF driver.
>
> I could convert the PCF8563 driver to OF driver and make it work for our
> puposes but I feel this is
> 1) Wrong
> 2) therefore wasted work.


Since the driver must run on non OF platforms then it should not be
converted.  You just need to add a platform_device_register somewhere.
I don't think fsl_soc.c is  the right place since it is not part of an
freescale SOC.
You could probably put it in a board specific startup routine.

What seems to elude me is some glue that glues together the OF part of the
> driver space to the non OF part
> of the driver space.
>
> Any hints or pointers on where to find this glue?
>
> Regards,
> kd
>
> P.S. Kernel is post 2.6.20.
>
> --
> K?ri Dav??sson                   | kari.davidsson at marel.is
> Hugb?na?arger?                   | www.marel.com
> Tel: 563-8156 Fax: +354 563 8001
> Iceland
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070703/25bc12f9/attachment.htm 

From li.chunlin at zte.com.cn  Wed Jul  4 14:24:13 2007
From: li.chunlin at zte.com.cn (li.chunlin at zte.com.cn)
Date: Wed, 4 Jul 2007 12:24:13 +0800
Subject: about FCC of MPC8270
In-Reply-To: <4b73d43f0707030931v42aefc72x2598546e48ae87e8@mail.gmail.com>
Message-ID: <OF067D5541.23C80493-ON4825730E.001766FC-4825730E.00183FCF@zte.com.cn>

hello, every one

   I have a board with mpc8270. And there are two ethernet interface by 
fcc1 and fcc2. Now in linux kernel 2.6.14 fcc1 is ok, but fcc2 is some 
wrong. I set loopback of fcc2 or rmii. that's ok. But i set loopback in 
phy, it is wrong. But fcc2 is ok in u-boot.

I take a look with oscillograph. i find that there is signal from fcc2 to 
phy and there is signal from phy to fcc2 in data pins. But fcc2 cannot 
receive data and fcc2 can send data.

who know the reason? Can you tell me? 

thanks.
lichunlin


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070704/3111e6a3/attachment.htm 

From mouli1982 at gmail.com  Wed Jul  4 06:09:38 2007
From: mouli1982 at gmail.com (mouli)
Date: Tue, 3 Jul 2007 16:09:38 -0400
Subject: request for linux preview kit for ML403
Message-ID: <82551e630707031309u4e873acw2235523ee7ea5df2@mail.gmail.com>

Dear all,
           I am working on Virtex-4 Fx12LC (ML 403 ) Fpga that has powerpc
hard core.
I would want to load Linux RTOS onto it and try and access the on chip
memory and Fpga logic from that.
May I know if any body has the preview kit for Linux for that version of the
VIrtex-4 FPGA.

I am not able to access the montavista linux preview kit from monta vista
website.

thanks and regards
---------------------------------------------------------------------
To save the world is the simplest thing in the world. All one has to do is
think.  Leonard Peikoff

vijay chandra mouli N.
ECE department,
NC state univeristy,
Raleigh,NC-27606.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070703/a36fd294/attachment.htm 

From matvejchikov at gmail.com  Wed Jul  4 15:42:26 2007
From: matvejchikov at gmail.com (Matvejchikov Ilya)
Date: Wed, 4 Jul 2007 09:42:26 +0400
Subject: about FCC of MPC8270
In-Reply-To: <OF067D5541.23C80493-ON4825730E.001766FC-4825730E.00183FCF@zte.com.cn>
References: <4b73d43f0707030931v42aefc72x2598546e48ae87e8@mail.gmail.com>
	<OF067D5541.23C80493-ON4825730E.001766FC-4825730E.00183FCF@zte.com.cn>
Message-ID: <8496f91a0707032242w40c0f398s87ab5a9249c0e902@mail.gmail.com>

Hi!

Do you use CPM_FCC_SPECIAL_BASE constant? (include/asm-ppc/cpm2.h)
In my case (8250, 8260) FCCs only works when it is set to 0x3000...


2007/7/4, li.chunlin at zte.com.cn <li.chunlin at zte.com.cn>:
>
> hello, every one
>
>    I have a board with mpc8270. And there are two ethernet interface by fcc1
> and fcc2. Now in linux kernel 2.6.14 fcc1 is ok, but fcc2 is some wrong. I
> set loopback of fcc2 or rmii. that's ok. But i set loopback in phy, it is
> wrong. But fcc2 is ok in u-boot.
>
> I take a look with oscillograph. i find that there is signal from fcc2 to
> phy and there is signal from phy to fcc2 in data pins. But fcc2 cannot
> receive data and fcc2 can send data.
>
> who know the reason? Can you tell me?
>
> thanks.
> lichunlin
>


From matvejchikov at gmail.com  Wed Jul  4 15:51:09 2007
From: matvejchikov at gmail.com (Matvejchikov Ilya)
Date: Wed, 4 Jul 2007 09:51:09 +0400
Subject: Too many spurious interrupts on mpc82xx with linux-2.4.35.5
Message-ID: <8496f91a0707032251m6fea386cu2405899d2945fd07@mail.gmail.com>

Hi all!

If you still have this problem, try this patch. It helps :)

Signed-off-by : Matvejchikov Ilya <matvejchikov at gmail.com>
---
diff -purN linux-2.4.34.5-vanilla/arch/ppc/kernel/cpm2_pic.c
linux-2.4.34.5/arch/ppc/kernel/cpm2_pic.c
--- linux-2.4.34.5-vanilla/arch/ppc/kernel/cpm2_pic.c	2007-06-06
23:20:53.000000000 +0400
+++ linux-2.4.34.5/arch/ppc/kernel/cpm2_pic.c	2007-06-28
12:17:42.000000000 +0400
@@ -79,6 +79,12 @@ static void cpm2_mask_and_ack(unsigned i
 	ppc_cached_irq_mask[word] &= ~(1 << (31 - bit));
 	simr[word] = ppc_cached_irq_mask[word];
 	sipnr[word] = 1 << (31 - bit);
+
+	/*
+	 * Work around large numbers of spurious IRQs on PowerPC 82xx
+	 * systems.
+	 */
+	mb();
 }

 static void cpm2_end_irq(unsigned int irq_nr)


From li.chunlin at zte.com.cn  Wed Jul  4 16:55:21 2007
From: li.chunlin at zte.com.cn (li.chunlin at zte.com.cn)
Date: Wed, 4 Jul 2007 14:55:21 +0800
Subject: about FCC of MPC8270
In-Reply-To: <8496f91a0707032242w40c0f398s87ab5a9249c0e902@mail.gmail.com>
Message-ID: <OF0D7C4044.9BAD3D4B-ON4825730E.0025DB9D-4825730E.002615DC@zte.com.cn>

I use it. And it is: #define CPM_FCC_SPECIAL_BASE       ((uint)0x0000b000)



Hi!

Do you use CPM_FCC_SPECIAL_BASE constant? (include/asm-ppc/cpm2.h)
In my case (8250, 8260) FCCs only works when it is set to 0x3000...


2007/7/4, li.chunlin at zte.com.cn <li.chunlin at zte.com.cn>:
>
> hello, every one
>
>    I have a board with mpc8270. And there are two ethernet interface by 
fcc1
> and fcc2. Now in linux kernel 2.6.14 fcc1 is ok, but fcc2 is some wrong. 
I
> set loopback of fcc2 or rmii. that's ok. But i set loopback in phy, it 
is
> wrong. But fcc2 is ok in u-boot.
>
> I take a look with oscillograph. i find that there is signal from fcc2 
to
> phy and there is signal from phy to fcc2 in data pins. But fcc2 cannot
> receive data and fcc2 can send data.
>
> who know the reason? Can you tell me?
>
> thanks.
> lichunlin
>




--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070704/84a413a2/attachment.htm 

From matvejchikov at gmail.com  Wed Jul  4 17:02:05 2007
From: matvejchikov at gmail.com (Matvejchikov Ilya)
Date: Wed, 4 Jul 2007 11:02:05 +0400
Subject: about FCC of MPC8270
In-Reply-To: <OF0D7C4044.9BAD3D4B-ON4825730E.0025DB9D-4825730E.002615DC@zte.com.cn>
References: <8496f91a0707032242w40c0f398s87ab5a9249c0e902@mail.gmail.com>
	<OF0D7C4044.9BAD3D4B-ON4825730E.0025DB9D-4825730E.002615DC@zte.com.cn>
Message-ID: <8496f91a0707040002w6e036024i7c22fdd01c0c21d8@mail.gmail.com>

Try 0x3000

2007/7/4, li.chunlin at zte.com.cn <li.chunlin at zte.com.cn>:
>
> I use it. And it is: #define CPM_FCC_SPECIAL_BASE        ((uint)0x0000b000)
>
>
>
>
> Hi!
>
>  Do you use CPM_FCC_SPECIAL_BASE constant? (include/asm-ppc/cpm2.h)
>  In my case (8250, 8260) FCCs only works when it is set to 0x3000...
>
>
>  2007/7/4, li.chunlin at zte.com.cn <li.chunlin at zte.com.cn>:
>  >
>  > hello, every one
>  >
>  >    I have a board with mpc8270. And there are two ethernet interface by
> fcc1
>  > and fcc2. Now in linux kernel 2.6.14 fcc1 is ok, but fcc2 is some wrong.
> I
>  > set loopback of fcc2 or rmii. that's ok. But i set loopback in phy, it is
>  > wrong. But fcc2 is ok in u-boot.
>  >
>  > I take a look with oscillograph. i find that there is signal from fcc2 to
>  > phy and there is signal from phy to fcc2 in data pins. But fcc2 cannot
>  > receive data and fcc2 can send data.
>  >
>  > who know the reason? Can you tell me?
>  >
>  > thanks.
>  > lichunlin
>  >


From li.chunlin at zte.com.cn  Wed Jul  4 17:50:33 2007
From: li.chunlin at zte.com.cn (li.chunlin at zte.com.cn)
Date: Wed, 4 Jul 2007 15:50:33 +0800
Subject: about FCC of MPC8270
In-Reply-To: <8496f91a0707040002w6e036024i7c22fdd01c0c21d8@mail.gmail.com>
Message-ID: <OF0F6D8F13.FC8F531D-ON4825730E.002B02E1-4825730E.002B23F6@zte.com.cn>

Not ok with 0x3000






"Matvejchikov Ilya" <matvejchikov at gmail.com>


 
        ????        "li.chunlin at zte.com.cn" <li.chunlin at zte.com.cn>
        ???  linuxppc-embedded at ozlabs.org
        ???  Re: about FCC of MPC8270


Try 0x3000

2007/7/4, li.chunlin at zte.com.cn <li.chunlin at zte.com.cn>:
>
> I use it. And it is: #define CPM_FCC_SPECIAL_BASE ((uint)0x0000b000)
>
>
>
>
> Hi!
>
>  Do you use CPM_FCC_SPECIAL_BASE constant? (include/asm-ppc/cpm2.h)
>  In my case (8250, 8260) FCCs only works when it is set to 0x3000...
>
>
>  2007/7/4, li.chunlin at zte.com.cn <li.chunlin at zte.com.cn>:
>  >
>  > hello, every one
>  >
>  >    I have a board with mpc8270. And there are two ethernet interface 
by
> fcc1
>  > and fcc2. Now in linux kernel 2.6.14 fcc1 is ok, but fcc2 is some 
wrong.
> I
>  > set loopback of fcc2 or rmii. that's ok. But i set loopback in phy, 
it is
>  > wrong. But fcc2 is ok in u-boot.
>  >
>  > I take a look with oscillograph. i find that there is signal from 
fcc2 to
>  > phy and there is signal from phy to fcc2 in data pins. But fcc2 
cannot
>  > receive data and fcc2 can send data.
>  >
>  > who know the reason? Can you tell me?
>  >
>  > thanks.
>  > lichunlin
>  >






--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070704/c7a206a2/attachment.htm 

From clifford at clifford.at  Wed Jul  4 19:05:54 2007
From: clifford at clifford.at (Clifford Wolf)
Date: Wed, 4 Jul 2007 11:05:54 +0200
Subject: Mem-2-Mem DMA - Generalized API
In-Reply-To: <20070625180110.GH20463@clifford.at>
References: <20070624193932.GA11797@clifford.at>
	<200706242221.57507.arnd@arndb.de>
	<467FA0EA.3000607@genesi-usa.com> <467FBABD.9040103@anagramm.de>
	<467FD1DF.4000602@genesi-usa.com>
	<20070625180110.GH20463@clifford.at>
Message-ID: <20070704090554.GA30693@clifford.at>

Hi,

On Mon, Jun 25, 2007 at 08:01:10PM +0200, Clifford Wolf wrote:
> I've put a 'draft header file' of an api as I would have expected it
> online: [...]

Ok, so here comes the first implementation:
(I also have other projects, so it took a while.. ;-)

	http://www.clifford.at/priv/dmatransfer-20070704.diff

This is just for the MPC8349 DMA now, registers are still hardcoded in the
driver instead of beeing taken from the platform files and support for
scatter-gather is still missing and the Kconfig integration isn't checking
if we are building for the mpc8349 (or even ppc) yet. But I think the
direction of the API is pretty clear.

The patch also contains a hackish demo client (dma_demo_client.ko) which is
performing some dma transfers in the 256th MB of physical memory. So it
should only be used on a machine with 256MB of memory bootet with mem=255M
(but changing that should be trivial). The demo client shows well how the
API works and how much overhead the API adds.

Any feedback this time?

yours,
 - clifford

-- 
#!/usr/bin/perl
$p="1"x1002;for$c(2..1000){if($p=~/^.{$c}0/){next;};printf"%3d\%s",
$c,++$x%14?" ":"\n";while($p=~s/^((.{$c})+)1/${1}0/){}}$_="lPSFZQ".
"SJNFTZBUZ<IUUQ:;;XXX.DMJGGPSE.BU;QSJNF;>\n";y:B-Zl;:a-x M/:;print;


From clemens.koller at anagramm.de  Wed Jul  4 20:11:28 2007
From: clemens.koller at anagramm.de (Clemens Koller)
Date: Wed, 04 Jul 2007 12:11:28 +0200
Subject: Mem-2-Mem DMA - Generalized API
In-Reply-To: <20070704090554.GA30693@clifford.at>
References: <20070624193932.GA11797@clifford.at>	<200706242221.57507.arnd@arndb.de>	<467FA0EA.3000607@genesi-usa.com>
	<467FBABD.9040103@anagramm.de>	<467FD1DF.4000602@genesi-usa.com>	<20070625180110.GH20463@clifford.at>
	<20070704090554.GA30693@clifford.at>
Message-ID: <468B7250.3070704@anagramm.de>

Clifford Wolf schrieb:
> On Mon, Jun 25, 2007 at 08:01:10PM +0200, Clifford Wolf wrote:
>> I've put a 'draft header file' of an api as I would have expected it
>> online: [...]
> 
> Ok, so here comes the first implementation:
> (I also have other projects, so it took a while.. ;-)
> 
> 	http://www.clifford.at/priv/dmatransfer-20070704.diff
> 
> This is just for the MPC8349 DMA now, registers are still hardcoded in the
> driver instead of beeing taken from the platform files and support for
> scatter-gather is still missing and the Kconfig integration isn't checking
> if we are building for the mpc8349 (or even ppc) yet. But I think the
> direction of the API is pretty clear.

That looks good. It should be useful on other PowerQUICC's DMA engines
and maybe even for the MPC5200 BestComm, too, with some changes.

> The patch also contains a hackish demo client (dma_demo_client.ko) which is
> performing some dma transfers in the 256th MB of physical memory. So it
> should only be used on a machine with 256MB of memory bootet with mem=255M
> (but changing that should be trivial). The demo client shows well how the
> API works and how much overhead the API adds.
> 
> Any feedback this time?

Sorry, I'm currently busy with some hardware design work.
But if you want to test some code, I can get you an SSH account on my
MPC8540 platform.

Best regards,
-- 
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Stra?e 45/1
Linhof Werksgel?nde
D-81379 M?nchen
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com


From kari.davidsson at marel.is  Wed Jul  4 22:00:31 2007
From: kari.davidsson at marel.is (=?iso-8859-1?B?S+FyaSBEYXbt8HNzb24=?=)
Date: Wed, 4 Jul 2007 12:00:31 -0000
Subject: OF devices and non OF devices
In-Reply-To: <4b73d43f0707030931v42aefc72x2598546e48ae87e8@mail.gmail.com>
Message-ID: <DD39B5C3F4963040ADC9768BE7E430CB020D3DE8@is-hdq-exchange.marel.net>

John, thank you for your answare.

Enabling CONFIG_FSL_SOC only enabled the execution of the init function (fsl_i2c_init())
of the fsl-i2c driver (i2c-mpc.c). The .probe function of the driver was never called
until I converted the driver to the OF model and added the .match_table to the driver structure.

Then I get the .probe function (fsl_i2c_probe()) called and the i2c bus set up.

Similar thing happens for the i2c device PCF8563 i.e., the init functin of the driver (pcf8563_init())
is called the driver is registered with the kernel, but the .probe (pcf8563_probe()) is never called.

The driver pcf8563 has _NO_ exported structures or functions so I basically have no handle on it
that I can utilize in board specific setup.

The way I suspect this is supposed to work is that from the board settup files I would do
rtc_dev = platform_device_register_simple("pcf8563", -1, NULL, 0);
which should later trigger the calling of the pcf8563_probe() function.

This is doing things in the same way as the fsl i2c code, i.e.
i2c_dev = platform_device_register_simple("i2c", i, r, 2);
which by the way does not work untill I have converted the fsl_i2c (i2c-mpc.c) driver to the OF structure.

So still the method of gluing together the OF drivers and non OF drivers eludes me.

rg
kd

P.S. I did check the 2.6.21-RC7-git3 and found that the i2c-mpc.c and the rtc-pcf85763.c are basically the same
as what I am working with in 2.6.20+ 
________________________________

From: John Rigby [mailto:jcrigby at gmail.com] 
Sent: 3. j?l? 2007 16:31
To: K?ri Dav??sson
Cc: linuxppc-embedded at ozlabs.org
Subject: Re: OF devices and non OF devices


One place to find binding between OF devices and non OF devices is in arch/powerpc/sysdev/fsl_soc.c
The typical pattern is:
    if of_find_compatible_node "of-device-name"
        platform_device_register_simple ""platform-device-name" 
        platform_device_add_data ...

  

On 7/3/07, K?ri Dav??sson <kari.davidsson at marel.is> wrote: 

	Hi,
	
	I am attempting to get some non OF devices working for an mpc 5200 board, in particular 
	PCF8563 RTC.
	
	This device has an non OF device interface which I believe is correct. After all it should work
	on non OF platforms.
	
	I have managed to get the board to run the i2c initialization (and probe) for the fsl-mpc i2c driver by 
	converting the fsl-mpc i2c driver to OF driver (I found some patch here that I based this work on).


fsl-i2c is one of the devices handled by fsl_soc.c so you shouldn't need to change anything to 
make it work in the latest kernel.  CONFIG_FSL_SOC was only added to lite5200_defconfig recently so 
that may explain why it's not on in your kernel.



	Since the PCF8563 driver is not OF driver only its initaliziation code is run but the .probe function
	of the driver is never run. Basically (as far as I can understand) the .probe is never run because the
	driver is not an OF driver. 
	
	I could convert the PCF8563 driver to OF driver and make it work for our puposes but I feel this is
	1) Wrong
	2) therefore wasted work.


Since the driver must run on non OF platforms then it should not be converted.  You just need to add a platform_device_register somewhere. 
I don't think fsl_soc.c is  the right place since it is not part of an freescale SOC.
You could probably put it in a board specific startup routine.



	What seems to elude me is some glue that glues together the OF part of the driver space to the non OF part
	of the driver space.
	
	Any hints or pointers on where to find this glue?
	
	Regards,
	kd
	
	P.S. Kernel is post 2.6.20.
	
	--
	K?ri Dav??sson                   | kari.davidsson at marel.is
	Hugb?na?arger?                   | www.marel.com
	Tel: 563-8156 Fax: +354 563 8001 
	Iceland
	_______________________________________________
	Linuxppc-embedded mailing list
	Linuxppc-embedded at ozlabs.org
	https://ozlabs.org/mailman/listinfo/linuxppc-embedded
	




From ma.harounansari at gdatech.co.in  Thu Jul  5 00:18:36 2007
From: ma.harounansari at gdatech.co.in (Ansari)
Date: Wed, 4 Jul 2007 19:48:36 +0530
Subject: MPC8540 DMA transfer
Message-ID: <000501c7be46$368236c0$9503a8c0@Ansari>

Hello Koller,

Is there any support for dma transter in linux 2.4.x kernel . Whether u have any source code for tht ?????. I think u have attached a dma driver code for 2.6.x kernel . But i need it for 2.4 kernel. ( Processor : MPC8540 / MPC8560 )

Regards
Ansari 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070704/0b7b3ce5/attachment.htm 

From kusti at iki.fi  Thu Jul  5 00:51:58 2007
From: kusti at iki.fi (Kimmo Surakka)
Date: Wed, 4 Jul 2007 17:51:58 +0300
Subject: TQM5200 problems (kernel 2.4)
Message-ID: <a44e83440707040751o4f2e195dte8c2edafd5f864c@mail.gmail.com>

Hello all,

I've been playing with a TQM5200 card and trying to make its I2C
communications even relatively reliable. To communicate with the card,
I use PPP over RS-232 (on port PSC0), baud rate 115200. All the files
are stored on the card's own 32 MB flash.

On my tests, I've met three problems: PPP connection unreliability,
I2C unreliability, and flash unreliability. I anybody has any ideas on
what could be causing these, I'd be happy to hear. Also, I've put
together two patches that help a bit, so if somebody else is
struggling with the same problems, feel free to test these patches.

Problem #1: PPP unreliability. If I just fetch the latest 2.4 kernel
from http://www.denx.de/cgi-bin/gitweb.cgi?p=linuxppc_2_4_devel.git;a=summary
and build it with a pretty minimal configuration file, PPP connection
is really unreliable. I've set the MTS to be 576 bytes, because on a
continuous transfer from TQM I get CRC error about once every ten
seconds. This triggers TCP CRC recalculation code from git commits
e3145f7943db03e3808e493555b28e7696e8f408
and 8bab0e983d5fc1ad53c34c0cc68a07d9339a7148. As a result, my dmesg
log gets filled with lines like:

tcp_recheck_csum: seq 0x1e9a515 retransmit, csum 0x4bb2 OK?
tcp_recheck_csum: seq 0x1e9ad75 retransmit, csum 0x32fe OK?
tcp_recheck_csum: seq 0x1e9ad75 retransmit, csum 0x32fe OK?
tcp_recheck_csum: seq 0x1e9ad75 retransmit, csum 0x32fe OK?
tcp_recheck_csum: seq 0x1e9af8d retransmit, csum 0xc296 OK?
tcp_recheck_csum: seq 0x1e9af8d retransmit, csum 0xc272 OK?

All PPP transmission also stalls. Data just won't arrive anymore.

I put together a patch that undoes the TCP/IP workaround patches. When
I apply the patch to the latest git commit, the errors seem to go
away. PPP connection now works even though there are the occational
CRC errors due to unreliable serial line. My conclusion:
the TCP/IP workaround is somehow broken. I'm not sure what bug it was
meant to work around, but while doing that it caused serious problems
with PPP communication.

Problem #2: I2C unreliability. My test setup has two slaves connected
on the TQM5200 I2C bus #1. On default setup this bus is disabled, so I
needed to edit file drivers/i2c/i2c-tqm5200.c and changethe value of
MPC5xxx_I2C1_ENABLE. After this change, the bus gets initialised.
However, it's not reliable. I send smbus_read_word and
smbus_write_word commands to the slaves every few milliseconds. Sooner
or later the bus gets stuck, apparently forever. I found an old I2c
patch for mpc5200 and modified it a bit. With the patch applied, the
kernel tries to detect bus lock-ups and reset the bus. This helps a
lot: now the lock-ups are only temporary. However, the dmesg log gets
polluted with lines like

Warning: kfree_skb on hard IRQ c008ecfc
Warning: kfree_skb on hard IRQ c008ecfc
Warning: kfree_skb on hard IRQ c008ecfc
Warning: kfree_skb on hard IRQ c008ecfc
Warning: kfree_skb on hard IRQ c008ecfc
Warning: kfree_skb on hard IRQ c008ecfc

(always the same IRQ). The seem to come from net/core/skbuff.c, and
caused by kfree_skb being called while in_irq().

Problem #3: flash unreliability. After some time (weeks or so) the
system's flash filesystem (JFFS2) starts to misbehave. On every boot I
see lines like

jffs2_scan_eraseblock(): Node at 0x000bce2c {0x1985, 0x0000,
0x00000000) has invalid CRC 0x6ca60000 (calculated 0xbe76ea63)
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000bce34:
0x6ca6 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000bce48:
0x0019 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000bce4c:
0x42c6 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000bce50:
0x42c6 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000bce54:
0x42c6 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000bce58:
0x0019 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000bce64:
0x0600 instead

After a number of boots the system finally fails to boot at all. The
errors go away by erasing the flash and recreating the filesystem, but
the come back again at some point. Actually, I'm not sure if this
error still exists on the latest kernel sources. Before this, I've
been using the sources from snapshot
ftp://ftp.denx.de/pub/linux/linuxppc_2_4_devel-2005-10-25-1440.tar.bz2,
but since the code starts to be pretty old, I switched to using the
git repository. I'll continue tests with the latest code and see if
the problem still exists.



-- 
Kimmo Surakka <kusti at iki.fi>
http://www.iki.fi/kusti
-------------- next part --------------
A non-text attachment was scrubbed...
Name: undo-tcpip-workaround.patch
Type: text/x-patch
Size: 8149 bytes
Desc: not available
Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070704/59dc206e/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: i2c-fix-test.patch
Type: text/x-patch
Size: 6392 bytes
Desc: not available
Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070704/59dc206e/attachment-0001.bin 

From mamsadegh at hotmail.com  Thu Jul  5 01:17:25 2007
From: mamsadegh at hotmail.com (Mohammad Sadegh Sadri)
Date: Wed, 4 Jul 2007 15:17:25 +0000
Subject: ML403 gigabit ethernet bandwidth - 2.6 kernel
Message-ID: <BAY115-W524929EDF5E3368B521F1B2030@phx.gbl>


Dear All,

Our tests show that CPU usage is always 100% during netperf test.
So the speed of CPU is important in the overall performance of the gigabit link.
If we can increase the CPU core clock frequency we may achieve better results using existing hardware/software configuration.

I know that the PPC core inside FX12 can run with clock frequencies up to 450MHz, However Base System Builder for ML403 allows just frequencies of up to 300MHz for PPC core. Does any body here know how I can make PPC core to run with 400MHz in ML403?

thanks




----------------------------------------
> From: eemingliu at hotmail.com
> To: mamsadegh at hotmail.com
> CC: akonovalov at ru.mvista.com; linuxppc-embedded at ozlabs.org
> Subject: RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
> Date: Tue, 26 Jun 2007 18:12:55 +0000
> 
> Dear Mohammad,
> 
> >ML403--->PC : 410Mbits/s
> >PC--->ML403 : 210Mbits/s
> 
> These results are interesting. In priciple, board to PC will be less than 
> PC to board. And also you board to PC speed is quite fast. I never had that 
> high before. :)
> 
> >We have described the characteristics of our base system in previous posts 
> here
> >
> >In additiona we have :
> >1- enabled the ppc caches
> 
> This will help the improvement quite a lot.
> 
> >2- we have set BD_IN_BRAM in adapter.c to 1. ( default is 0 )
> 
> Actually I didn't try to modify this before. My previous results are based 
> on bd_NOT_in_bram. :) From my understanding, enable this option will put 
> the buffer descriptor in BRAM rather than DDR. Perhaps I can also try it 
> and to see if there is any improvement on my system.
> 
> >TX_THRESHOLD is 16 and RX_THRESHOLD is 2.
> >
> >the virtex4 fx12 device on ML403 is now completely full, we do not have 
> any free block memories nor any logic slices. Maybe if we had more space we 
> could choose higher values for XTE_SEND_BD_CNT and XTE_RECV_BD_CNT i.e. 
> 384. Do you think this will improve performance?
> 
> Probably yes. But I never modified these numbers before. My default ones 
> are 512 respectively.
> 
> >There is also another interesting test,
> >We executed netperf on both of PC and ML403 simultanously , when we do not 
> put BDs in BRAM, the performance of ML403-->PC link drops from 390Mbits to 
> 45Mbits, but when using PLB BRAMs for BDs the performance decreases from 
> 410Mbits/s to just 130Mbita/s. It is important when the user wants to 
> transfer data in both directions simulatanously.
> 
> Definitely! The bottleneck is CPU processing capability. So if you send and 
> receive data at the same time, the results will be much worse. I think 
> another reason is TCP is guaranteed protocal. So there will be some 
> acknowledgements returning back when you send packets out. Thus your 
> bandwidth will be taken a little away. However compared with the 
> consumption of CPU, this perhaps will be trivial.
> 
> BR
> Ming
> 
> 
> 
> 
> >
> >
> >----------------------------------------
> > > From: eemingliu at hotmail.com
> > > To: mamsadegh at hotmail.com
> > > CC: akonovalov at ru.mvista.com; linuxppc-embedded at ozlabs.org
> > > Subject: RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
> > > Date: Mon, 25 Jun 2007 10:03:30 +0000
> > >
> > > Dear Mohammad,
> > >
> > > >The results are as follows:
> > > >PC-->ML403
> > > >TCP_SENDFILE : 38Mbps
> > > >
> > > >ML403--->PC
> > > >TCP_SENDFILE: 155Mbps
> > >
> > > This result is unreasonable. Because PC is more powerful than your 
> board,
> > > so PC->board should be faster than board->PC.
> > >
> > > >The transfer rate from ML403 to PC has improved by a factor of 2,
> > > >I see on the posts here in the mailing list that you have reached a 
> band
> > > width of 301Mbps.
> > >
> > > Yes, with all features which could improve performance enabled, we can 
> get
> > > around 300Mbps for TCP transfer. one more hint, did you enable caches 
> on
> > > your system? perhaps it will help. Anyway, double check your hardware
> > > design to make sure all features are enabled.That's all I can suggest.
> > >
> > > BR
> > > Ming
> > >
> > >
> > > >
> > > >
> > > >
> > > >
> > > >----------------------------------------
> > > > > From: eemingliu at hotmail.com
> > > > > To: mamsadegh at hotmail.com; akonovalov at ru.mvista.com;
> > > linuxppc-embedded at ozlabs.org; grant.likely at secretlab.ca
> > > > > Subject: RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
> > > > > Date: Sat, 23 Jun 2007 19:10:16 +0000
> > > > >
> > > > > Use the following command in Linux please:
> > > > >
> > > > > ifconfig eth0 mtu 8982
> > > > >
> > > > > As well you should do that on your PC in the measurement.
> > > > >
> > > > > Ming
> > > > >
> > > > >
> > > > > >From: Mohammad Sadegh Sadri
> > > > > >To: Ming Liu ,
> > > > > ,,
> > > > >
> > > > > >Subject: RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
> > > > > >Date: Sat, 23 Jun 2007 19:08:29 +0000
> > > > > >
> > > > > >
> > > > > >Dear Ming,
> > > > > >
> > > > > >Really thanks for reply,
> > > > > >
> > > > > >about thresholds and waitbound OK! I'll adjust them in adapter.c ,
> > > > > >
> > > > > >but what about enabling jumbo frames? should I do any thing 
> special to
> > > > > enable Jumbo fram support?
> > > > > >
> > > > > >we were thinking that it is enabled by default. Is it?
> > > > > >
> > > > > >thanks
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >----------------------------------------
> > > > > > > From: eemingliu at hotmail.com
> > > > > > > To: mamsadegh at hotmail.com; akonovalov at ru.mvista.com;
> > > > > linuxppc-embedded at ozlabs.org; grant.likely at secretlab.ca
> > > > > > > Subject: RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
> > > > > > > Date: Sat, 23 Jun 2007 18:48:19 +0000
> > > > > > >
> > > > > > > Dear Mohammad,
> > > > > > > There are some parameters which could be adjusted to improve 
> the
> > > > > > > performance. They are: TX and RX_Threshold TX and RX_waitbound. 
> In
> > > my
> > > > > > > system, we use TX_Threshold=16 and Rx_Threshold=8 and both
> > > waitbound=1.
> > > > > > >
> > > > > > > Also Jumbo frame of 8982 could be enable.
> > > > > > >
> > > > > > > Try those hints and share your improvement with us.
> > > > > > >
> > > > > > > BR
> > > > > > > Ming
> > > > > > >
> > > > > > > >From: Mohammad Sadegh Sadri
> > > > > > > >To: Andrei Konovalov , Linux PPC Linux
> > > > > > > PPC, Grant Likely
> > > > > > > >Subject: ML403 gigabit ethernet bandwidth - 2.6 kernel
> > > > > > > >Date: Sat, 23 Jun 2007 12:19:12 +0000
> > > > > > > >
> > > > > > > >
> > > > > > > >Dear all,
> > > > > > > >
> > > > > > > >Recently we did a set of tests on performance of virtex 4FX 
> hard
> > > TEMAC
> > > > > > > module using ML403
> > > > > > > >
> > > > > > > >we studied all of the posts here carefully: these are the 
> system
> > > > > > > characteristics;
> > > > > > > >
> > > > > > > >Board : ML403
> > > > > > > >EDK    : EDK9.1SP2
> > > > > > > >Hard TEMAC version and PLTEMAC version are both 3.0.a
> > > > > > > >PPC clock frequency :  300MHz
> > > > > > > >Kernel : 2.6.21-rc7 , downloaded from grant's git tree some 
> thing
> > > near
> > > > > one
> > > > > > > week ago
> > > > > > > >DMA type: 3 (sg dma)
> > > > > > > >DRE : enabled for TX and RX, (2)
> > > > > > > >CSUM offload is enabled for both of TX and RX
> > > > > > > >tx and rx fifo sizes : 131072 bits
> > > > > > > >
> > > > > > > >the board comes up over NFS root file system completely and
> > > without
> > > > > any
> > > > > > > problems.
> > > > > > > >
> > > > > > > >PC system used for these tests is : CPU P4 Dual Core, 3.4GHz ,
> > > > > 2Gigabytes
> > > > > > > memory, Dual gigabit ethernet port, running linux 2.6.21.3
> > > > > > > >We have tested the PC system band width and it can easily 
> reach
> > > > > 966mbits/s
> > > > > > > when connected to the same PC. ( using the same cross cable 
> used
> > > for
> > > > > ml403
> > > > > > > test)
> > > > > > > >
> > > > > > > >Netperf is compiled with TCP SEND FILE enabled, ( 
> -DHAVE_SENDFILE)
> > > > > > > >
> > > > > > > >(from board to PC)
> > > > > > > >netperf -t TCP_SENDFILE -H 10.10.10.250 -F /boot/zImage.elf -- 
> -m
> > > > > 16384 -s
> > > > > > > 87380 -S 87380
> > > > > > > >
> > > > > > > >the measured bandwidth for this test was just 40.66Mbits.
> > > > > > > >It is also true for netperf from PC to board.
> > > > > > > >
> > > > > > > >we do not have any more idea about what we should do to 
> improve
> > > the
> > > > > > > bandwidth.
> > > > > > > >any help or ideas is appreciated...
> > > > > > > >
> > > > > > > 
> >_________________________________________________________________
> > > > > > > >Connect to the next generation of MSN
> > > > > > >
> > > > >
> > > 
> Messenger?>http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline
> 
> > >
> > > > >
> > > > > > >
> > > > > > > >_______________________________________________
> > > > > > > >Linuxppc-embedded mailing list
> > > > > > > >Linuxppc-embedded at ozlabs.org
> > > > > > > >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> > > > > > >
> > > > > > > 
> _________________________________________________________________
> > > > > > > ???? MSN Explorer:   http://explorer.msn.com/lccn/
> > > > > > >
> > > > > >
> > > > > >_________________________________________________________________
> > > > > >News, entertainment and everything you care about at Live.com. Get 
> it
> > > now!
> > > > > >http://www.live.com/getstarted.aspx
> > > > >
> > > > > _________________________________________________________________
> > > > > ???? MSN Explorer:   http://explorer.msn.com/lccn/
> > > > >
> > > >
> > > >_________________________________________________________________
> > > >Discover the new Windows Vista
> > > >http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE
> > >
> > > _________________________________________________________________
> > > ???? MSN Explorer:   http://explorer.msn.com/lccn/
> > >
> >
> >_________________________________________________________________
> >News, entertainment and everything you care about at Live.com. Get it now!
> >http://www.live.com/getstarted.aspx
> 
> _________________________________________________________________
> ?????????????? MSN Messenger:  http://messenger.msn.com/cn  
> 

_________________________________________________________________
Connect to the next generation of MSN Messenger?
http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline

From andrea.rosetti at hse-systems.com  Tue Jul  3 18:31:52 2007
From: andrea.rosetti at hse-systems.com (Andrea Rosetti)
Date: Tue, 3 Jul 2007 10:31:52 +0200 (CEST)
Subject: A uart driver to control modem
Message-ID: <1247.85.43.48.190.1183451512.squirrel@www.hse-systems.com>


Hi everybody,

I'm a newbe on linux emb development.
In a mpc880 based board (kernel 2.6.19) I've to control a modem
using a scc with handshake signals on general I/O ports.
Reading code of cpm_uart driver, it seems don't manage
handshake signals whereas uart driver (<2.6.10) seems do this.
It's correct?
Could you suggest the right way to start?

Thank you,
Andrea

-- 
H.S.E. Systems
Smartcard & Loyalty Solutions
G. Di Vincenzo, 2
67100 - L'Aquila - Italy
Tel.  08621965154
Mobile 3406874961
Fax 0862319822


From domen.puncer at telargo.com  Thu Jul  5 16:54:29 2007
From: domen.puncer at telargo.com (Domen Puncer)
Date: Thu, 5 Jul 2007 08:54:29 +0200
Subject: TQM5200 problems (kernel 2.4)
In-Reply-To: <a44e83440707040751o4f2e195dte8c2edafd5f864c@mail.gmail.com>
References: <a44e83440707040751o4f2e195dte8c2edafd5f864c@mail.gmail.com>
Message-ID: <20070705065429.GC4186@moe.telargo.com>

On 04/07/07 17:51 +0300, Kimmo Surakka wrote:
> Hello all,
> 
Hi!

...
> Problem #2: I2C unreliability. My test setup has two slaves connected
> on the TQM5200 I2C bus #1. On default setup this bus is disabled, so I
> needed to edit file drivers/i2c/i2c-tqm5200.c and changethe value of
> MPC5xxx_I2C1_ENABLE. After this change, the bus gets initialised.
> However, it's not reliable. I send smbus_read_word and
> smbus_write_word commands to the slaves every few milliseconds. Sooner
> or later the bus gets stuck, apparently forever. I found an old I2c

This is probably a hardware bug as described in:
http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019038.html

> patch for mpc5200 and modified it a bit. With the patch applied, the
> kernel tries to detect bus lock-ups and reset the bus. This helps a
> lot: now the lock-ups are only temporary. However, the dmesg log gets
> polluted with lines like
> 
> Warning: kfree_skb on hard IRQ c008ecfc
> Warning: kfree_skb on hard IRQ c008ecfc
> Warning: kfree_skb on hard IRQ c008ecfc
> Warning: kfree_skb on hard IRQ c008ecfc
> Warning: kfree_skb on hard IRQ c008ecfc
> Warning: kfree_skb on hard IRQ c008ecfc
> 
> (always the same IRQ). The seem to come from net/core/skbuff.c, and
> caused by kfree_skb being called while in_irq().
> 

I'm not seeing these (2.6-git from kernel.org)


	Domen


From jcrigby at gmail.com  Thu Jul  5 23:28:58 2007
From: jcrigby at gmail.com (John Rigby)
Date: Thu, 5 Jul 2007 07:28:58 -0600
Subject: OF devices and non OF devices
In-Reply-To: <DD39B5C3F4963040ADC9768BE7E430CB020D3DE8@is-hdq-exchange.marel.net>
References: <4b73d43f0707030931v42aefc72x2598546e48ae87e8@mail.gmail.com>
	<DD39B5C3F4963040ADC9768BE7E430CB020D3DE8@is-hdq-exchange.marel.net>
Message-ID: <4b73d43f0707050628qd9db2afu3b63dd654be32646@mail.gmail.com>

kd,

Ok, obviously It doesn't work the way I thought.  Hopefully someone who does
understand this will comment.

John

On 7/4/07, K?ri Dav??sson <kari.davidsson at marel.is> wrote:
>
> John, thank you for your answare.
>
> Enabling CONFIG_FSL_SOC only enabled the execution of the init function
> (fsl_i2c_init())
> of the fsl-i2c driver (i2c-mpc.c). The .probe function of the driver was
> never called
> until I converted the driver to the OF model and added the .match_table to
> the driver structure.
>
> Then I get the .probe function (fsl_i2c_probe()) called and the i2c bus
> set up.
>
> Similar thing happens for the i2c device PCF8563 i.e., the init functin of
> the driver (pcf8563_init())
> is called the driver is registered with the kernel, but the .probe
> (pcf8563_probe()) is never called.
>
> The driver pcf8563 has _NO_ exported structures or functions so I
> basically have no handle on it
> that I can utilize in board specific setup.
>
> The way I suspect this is supposed to work is that from the board settup
> files I would do
> rtc_dev = platform_device_register_simple("pcf8563", -1, NULL, 0);
> which should later trigger the calling of the pcf8563_probe() function.
>
> This is doing things in the same way as the fsl i2c code, i.e.
> i2c_dev = platform_device_register_simple("i2c", i, r, 2);
> which by the way does not work untill I have converted the fsl_i2c (
> i2c-mpc.c) driver to the OF structure.
>
> So still the method of gluing together the OF drivers and non OF drivers
> eludes me.
>
> rg
> kd
>
> P.S. I did check the 2.6.21-RC7-git3 and found that the i2c-mpc.c and the
> rtc-pcf85763.c are basically the same
> as what I am working with in 2.6.20+
> ________________________________
>
> From: John Rigby [mailto:jcrigby at gmail.com]
> Sent: 3. j?l? 2007 16:31
> To: K?ri Dav??sson
> Cc: linuxppc-embedded at ozlabs.org
> Subject: Re: OF devices and non OF devices
>
>
> One place to find binding between OF devices and non OF devices is in
> arch/powerpc/sysdev/fsl_soc.c
> The typical pattern is:
>     if of_find_compatible_node "of-device-name"
>         platform_device_register_simple ""platform-device-name"
>         platform_device_add_data ...
>
>
>
> On 7/3/07, K?ri Dav??sson <kari.davidsson at marel.is> wrote:
>
>         Hi,
>
>         I am attempting to get some non OF devices working for an mpc 5200
> board, in particular
>         PCF8563 RTC.
>
>         This device has an non OF device interface which I believe is
> correct. After all it should work
>         on non OF platforms.
>
>         I have managed to get the board to run the i2c initialization (and
> probe) for the fsl-mpc i2c driver by
>         converting the fsl-mpc i2c driver to OF driver (I found some patch
> here that I based this work on).
>
>
> fsl-i2c is one of the devices handled by fsl_soc.c so you shouldn't need
> to change anything to
> make it work in the latest kernel.  CONFIG_FSL_SOC was only added to
> lite5200_defconfig recently so
> that may explain why it's not on in your kernel.
>
>
>
>         Since the PCF8563 driver is not OF driver only its initaliziation
> code is run but the .probe function
>         of the driver is never run. Basically (as far as I can understand)
> the .probe is never run because the
>         driver is not an OF driver.
>
>         I could convert the PCF8563 driver to OF driver and make it work
> for our puposes but I feel this is
>         1) Wrong
>         2) therefore wasted work.
>
>
> Since the driver must run on non OF platforms then it should not be
> converted.  You just need to add a platform_device_register somewhere.
> I don't think fsl_soc.c is  the right place since it is not part of an
> freescale SOC.
> You could probably put it in a board specific startup routine.
>
>
>
>         What seems to elude me is some glue that glues together the OF
> part of the driver space to the non OF part
>         of the driver space.
>
>         Any hints or pointers on where to find this glue?
>
>         Regards,
>         kd
>
>         P.S. Kernel is post 2.6.20.
>
>         --
>         K?ri Dav??sson                   | kari.davidsson at marel.is
>         Hugb?na?arger?                   | www.marel.com
>         Tel: 563-8156 Fax: +354 563 8001
>         Iceland
>         _______________________________________________
>         Linuxppc-embedded mailing list
>         Linuxppc-embedded at ozlabs.org
>         https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070705/69fb36db/attachment.htm 

From clemens.koller at anagramm.de  Thu Jul  5 23:58:30 2007
From: clemens.koller at anagramm.de (Clemens Koller)
Date: Thu, 05 Jul 2007 15:58:30 +0200
Subject: MPC8540 DMA transfer
In-Reply-To: <000501c7be46$368236c0$9503a8c0@Ansari>
References: <000501c7be46$368236c0$9503a8c0@Ansari>
Message-ID: <468CF906.4000202@anagramm.de>

Hello, Ansari!

Ansari schrieb:
> Hello Koller,
>  
> Is there any support for dma transter in linux 2.4.x kernel . Whether u 
> have any source code for tht ?????. I think u have attached a dma driver 
> code for 2.6.x kernel . But i need it for 2.4 kernel. ( Processor : 
> MPC8540 / MPC8560 )

There are no new features going into kernel 2.4.x. Development has stopped
long time ago. Have a look at the available code and backport it to 2.4 (YMMV).
But you propably want to move to the latest 2.6. The MPC8540 is supported
very well.
If you want to have new features implemented, use the latest 2.6.x tree from
Linus. Don't ride dead horses!

Regards,
-- 
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Stra?e 45/1
Linhof Werksgel?nde
D-81379 M?nchen
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com


From jcrigby at gmail.com  Fri Jul  6 03:20:42 2007
From: jcrigby at gmail.com (John Rigby)
Date: Thu, 5 Jul 2007 11:20:42 -0600
Subject: OF devices and non OF devices
In-Reply-To: <4b73d43f0707050628qd9db2afu3b63dd654be32646@mail.gmail.com>
References: <4b73d43f0707030931v42aefc72x2598546e48ae87e8@mail.gmail.com>
	<DD39B5C3F4963040ADC9768BE7E430CB020D3DE8@is-hdq-exchange.marel.net>
	<4b73d43f0707050628qd9db2afu3b63dd654be32646@mail.gmail.com>
Message-ID: <4b73d43f0707051020o67e671dft1d3b3816776d8eb7@mail.gmail.com>

There must be something else wrong with your configuration.
On my Lite5200B fsl_i2c_probe gets called with no changes to the driver.

The kernel version is 2.6.22-rc7

The relevant part of my device tree is:

        i2c at 3d00 {
            device_type = "i2c";
            compatible = "mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c";
            cell-index = <0>;
            reg = <3d00 40>;
            interrupts = <2 f 0>;
            interrupt-parent = <&mpc5200_pic>;
            fsl5200-clocking;
        };

        i2c at 3d40 {
            device_type = "i2c";
            compatible = "mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c";
            cell-index = <1>;
            reg = <3d40 40>;
            interrupts = <2 10 0>;
            interrupt-parent = <&mpc5200_pic>;
            fsl5200-clocking;
        };

I turned on DEBUG in drivers/base/dd.c and a call to pr_debug in the probe
routine
and here are the relevant log messages:

[   27.258245] platform: Matched Device fsl-i2c.0 with Driver fsl-i2c
[   27.258269] platform: Probing driver fsl-i2c with device fsl-i2c.0
[   27.258299] I2C: here in fsl_i2c_probe
[   27.258732] bound device 'fsl-i2c.0' to driver 'fsl-i2c'
[   27.258756] platform: Bound Device fsl-i2c.0 to Driver fsl-i2c
[   27.258776] platform: Matched Device fsl-i2c.1 with Driver fsl-i2c
[   27.258789] platform: Probing driver fsl-i2c with device fsl-i2c.1
[   27.258821] I2C: here in fsl_i2c_probe
[   27.259269] bound device 'fsl-i2c.1' to driver 'fsl-i2c'
[   27.259293] platform: Bound Device fsl-i2c.1 to Driver fsl-i2c

John

On 7/5/07, John Rigby <jcrigby at gmail.com> wrote:
>
> kd,
>
> Ok, obviously It doesn't work the way I thought.  Hopefully someone who
> does
> understand this will comment.
>
> John
>
> On 7/4/07, K?ri Dav??sson <kari.davidsson at marel.is> wrote:
> >
> > John, thank you for your answare.
> >
> > Enabling CONFIG_FSL_SOC only enabled the execution of the init function
> > (fsl_i2c_init())
> > of the fsl-i2c driver (i2c-mpc.c). The .probe function of the driver was
> > never called
> > until I converted the driver to the OF model and added the .match_table
> > to the driver structure.
> >
> > Then I get the .probe function (fsl_i2c_probe()) called and the i2c bus
> > set up.
> >
> > Similar thing happens for the i2c device PCF8563 i.e., the init functin
> > of the driver (pcf8563_init())
> > is called the driver is registered with the kernel, but the .probe
> > (pcf8563_probe()) is never called.
> >
> > The driver pcf8563 has _NO_ exported structures or functions so I
> > basically have no handle on it
> > that I can utilize in board specific setup.
> >
> > The way I suspect this is supposed to work is that from the board settup
> > files I would do
> > rtc_dev = platform_device_register_simple("pcf8563", -1, NULL, 0);
> > which should later trigger the calling of the pcf8563_probe() function.
> >
> > This is doing things in the same way as the fsl i2c code, i.e.
> > i2c_dev = platform_device_register_simple("i2c", i, r, 2);
> > which by the way does not work untill I have converted the fsl_i2c (
> > i2c-mpc.c) driver to the OF structure.
> >
> > So still the method of gluing together the OF drivers and non OF drivers
> > eludes me.
> >
> > rg
> > kd
> >
> > P.S. I did check the 2.6.21-RC7-git3 and found that the i2c-mpc.c and
> > the rtc-pcf85763.c are basically the same
> > as what I am working with in 2.6.20+
> > ________________________________
> >
> > From: John Rigby [mailto: jcrigby at gmail.com]
> > Sent: 3. j?l? 2007 16:31
> > To: K?ri Dav??sson
> > Cc: linuxppc-embedded at ozlabs.org
> > Subject: Re: OF devices and non OF devices
> >
> >
> > One place to find binding between OF devices and non OF devices is in
> > arch/powerpc/sysdev/fsl_soc.c
> > The typical pattern is:
> >     if of_find_compatible_node "of-device-name"
> >         platform_device_register_simple ""platform-device-name"
> >         platform_device_add_data ...
> >
> >
> >
> > On 7/3/07, K?ri Dav??sson <kari.davidsson at marel.is> wrote:
> >
> >         Hi,
> >
> >         I am attempting to get some non OF devices working for an mpc
> > 5200 board, in particular
> >         PCF8563 RTC.
> >
> >         This device has an non OF device interface which I believe is
> > correct. After all it should work
> >         on non OF platforms.
> >
> >         I have managed to get the board to run the i2c initialization
> > (and probe) for the fsl-mpc i2c driver by
> >         converting the fsl-mpc i2c driver to OF driver (I found some
> > patch here that I based this work on).
> >
> >
> > fsl-i2c is one of the devices handled by fsl_soc.c so you shouldn't need
> > to change anything to
> > make it work in the latest kernel.  CONFIG_FSL_SOC was only added to
> > lite5200_defconfig recently so
> > that may explain why it's not on in your kernel.
> >
> >
> >
> >         Since the PCF8563 driver is not OF driver only its
> > initaliziation code is run but the .probe function
> >         of the driver is never run. Basically (as far as I can
> > understand) the .probe is never run because the
> >         driver is not an OF driver.
> >
> >         I could convert the PCF8563 driver to OF driver and make it work
> > for our puposes but I feel this is
> >         1) Wrong
> >         2) therefore wasted work.
> >
> >
> > Since the driver must run on non OF platforms then it should not be
> > converted.  You just need to add a platform_device_register somewhere.
> > I don't think fsl_soc.c is  the right place since it is not part of an
> > freescale SOC.
> > You could probably put it in a board specific startup routine.
> >
> >
> >
> >         What seems to elude me is some glue that glues together the OF
> > part of the driver space to the non OF part
> >         of the driver space.
> >
> >         Any hints or pointers on where to find this glue?
> >
> >         Regards,
> >         kd
> >
> >         P.S. Kernel is post 2.6.20.
> >
> >         --
> >         K?ri Dav??sson                   | kari.davidsson at marel.is
> >         Hugb?na?arger?                   | www.marel.com
> >         Tel: 563-8156 Fax: +354 563 8001
> >         Iceland
> >         _______________________________________________
> >         Linuxppc-embedded mailing list
> >         Linuxppc-embedded at ozlabs.org
> >         https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> >
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded at ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070705/9f9bad63/attachment.htm 

From khollan at daktronics.com  Fri Jul  6 06:23:30 2007
From: khollan at daktronics.com (khollan)
Date: Thu, 5 Jul 2007 13:23:30 -0700 (PDT)
Subject: Porting Linux to Xilinx ML410
In-Reply-To: <fa686aa40707021551y469e1b7fv3b8c329b904b3d6@mail.gmail.com>
References: <11328063.post@talk.nabble.com> <11401755.post@talk.nabble.com>
	<fa686aa40707021551y469e1b7fv3b8c329b904b3d6@mail.gmail.com>
Message-ID: <11453962.post@talk.nabble.com>


Thanks I fixed the error, my system ace hardware wasn't working correctly.
Now I have a new problem during the init process.  It gives me this message

Starting pid 213 tty '': '/sbin/getty'
process '/sbin/getty 9600 ttyUL0 (pid 213) exited. Scheduling it for
restart.

And it tries to respawn it indefinetly.
If I pass the kernel command Init=/bin/sh I can get into the shell correctly
Any Ideas what this problem is?
Thanks for your help
Kevin
-- 
View this message in context: http://www.nabble.com/Porting-Linux-to-Xilinx-ML410-tf3989483.html#a11453962
Sent from the linuxppc-embedded mailing list archive at Nabble.com.



From wd at denx.de  Fri Jul  6 08:13:27 2007
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 06 Jul 2007 00:13:27 +0200
Subject: TQM5200 problems (kernel 2.4) 
In-Reply-To: Your message of "Wed, 04 Jul 2007 17:51:58 +0300."
	<a44e83440707040751o4f2e195dte8c2edafd5f864c@mail.gmail.com> 
Message-ID: <20070705221327.92FB5353A91@atlas.denx.de>

Dear Kimmo,

in message <a44e83440707040751o4f2e195dte8c2edafd5f864c at mail.gmail.com> you wrote:
>
> Problem #1: PPP unreliability. If I just fetch the latest 2.4 kernel
> from http://www.denx.de/cgi-bin/gitweb.cgi?p=linuxppc_2_4_devel.git;a=summary

Did you try the 2.6 kernel tree?  It  will  be  much  easier  to  get
people's attention when you use a current code base.

Alternatively, you may ask us for support. We know that old 2.4  tree
pretty well.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The explanation requiring the fewest assumptions is the  most  likely
to be correct.                                    -- William of Occam


From kusti at iki.fi  Fri Jul  6 16:21:27 2007
From: kusti at iki.fi (Kimmo Surakka)
Date: Fri, 6 Jul 2007 09:21:27 +0300
Subject: TQM5200 problems (kernel 2.4)
In-Reply-To: <20070705065429.GC4186@moe.telargo.com>
References: <a44e83440707040751o4f2e195dte8c2edafd5f864c@mail.gmail.com>
	<20070705065429.GC4186@moe.telargo.com>
Message-ID: <a44e83440707052321h14413336p9001daaa5a6a0181@mail.gmail.com>

> This is probably a hardware bug as described in:
> http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019038.html

Yes, that seems to be the case. The patch basically disables and again
enables the bus so that the missing clock pulse gets generated. I also
changes the code a bit so that an extra byte is not sent at the end of
transmissions.

The message http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019076.html
suggests to use a bit-banging driver instead of the buggy MPC5200 i2c
hardware. Maybe I'll look into that.

> > Warning: kfree_skb on hard IRQ c008ecfc
> > Warning: kfree_skb on hard IRQ c008ecfc
> > Warning: kfree_skb on hard IRQ c008ecfc
>
> I'm not seeing these (2.6-git from kernel.org)

Maybe it's indeed time to start using the 2.6 series, then. Thanks!

-- 
Kimmo Surakka <kusti at iki.fi>
http://www.iki.fi/kusti


From kusti at iki.fi  Fri Jul  6 16:25:45 2007
From: kusti at iki.fi (Kimmo Surakka)
Date: Fri, 6 Jul 2007 09:25:45 +0300
Subject: TQM5200 problems (kernel 2.4)
In-Reply-To: <20070705221327.92FB5353A91@atlas.denx.de>
References: <a44e83440707040751o4f2e195dte8c2edafd5f864c@mail.gmail.com>
	<20070705221327.92FB5353A91@atlas.denx.de>
Message-ID: <a44e83440707052325q7114362chb85e6999f1e09da6@mail.gmail.com>

Hello Wolfgang,

On 7/6/07, Wolfgang Denk <wd at denx.de> wrote:
> Did you try the 2.6 kernel tree?  It  will  be  much  easier  to  get
> people's attention when you use a current code base.

The 2.6 support for TQM5200 is still pretty new so I haven't had much
experience with it. Anyway, I think I'll look into it next. Thank you!

-- 
Kimmo Surakka <kusti at iki.fi>
http://www.iki.fi/kusti


From grant.likely at secretlab.ca  Sat Jul  7 06:02:28 2007
From: grant.likely at secretlab.ca (Grant Likely)
Date: Fri, 6 Jul 2007 14:02:28 -0600
Subject: mpc83xx USB support status
Message-ID: <fa686aa40707061302o6ed9ec7cq2b9cdba2553cee7a@mail.gmail.com>

Li,

What is the state of mpc83xx support in arch/powerpc?  I saw some of
the patches you posted to the ppc and usb-devel lists, but I want to
make sure I've got the whole set.  Also, can you tell me what the
state of those patches are (ie. which ones will be picked up for
2.6.23?)

I'm working on the mpc8349-mitx-gp board, and I can do the work to get
your changes working on that board.

Thanks,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195


From timur at freescale.com  Sat Jul  7 15:24:43 2007
From: timur at freescale.com (Timur Tabi)
Date: Sat, 07 Jul 2007 00:24:43 -0500
Subject: Mem-2-Mem DMA - Generalized API
In-Reply-To: <20070704090554.GA30693@clifford.at>
References: <20070624193932.GA11797@clifford.at>	<200706242221.57507.arnd@arndb.de>	<467FA0EA.3000607@genesi-usa.com>
	<467FBABD.9040103@anagramm.de>	<467FD1DF.4000602@genesi-usa.com>	<20070625180110.GH20463@clifford.at>
	<20070704090554.GA30693@clifford.at>
Message-ID: <468F239B.5070800@freescale.com>

Clifford Wolf wrote:
> Hi,
> 
> On Mon, Jun 25, 2007 at 08:01:10PM +0200, Clifford Wolf wrote:
>> I've put a 'draft header file' of an api as I would have expected it
>> online: [...]
> 
> Ok, so here comes the first implementation:
> (I also have other projects, so it took a while.. ;-)
> 
> 	http://www.clifford.at/priv/dmatransfer-20070704.diff

Why aren't you following the DMA API in include/linux/dmaengine.h?



From clifford at clifford.at  Sat Jul  7 18:41:14 2007
From: clifford at clifford.at (Clifford Wolf)
Date: Sat, 7 Jul 2007 10:41:14 +0200
Subject: Mem-2-Mem DMA - Generalized API
In-Reply-To: <468F239B.5070800@freescale.com>
References: <20070624193932.GA11797@clifford.at>
	<200706242221.57507.arnd@arndb.de>
	<467FA0EA.3000607@genesi-usa.com> <467FBABD.9040103@anagramm.de>
	<467FD1DF.4000602@genesi-usa.com>
	<20070625180110.GH20463@clifford.at>
	<20070704090554.GA30693@clifford.at>
	<468F239B.5070800@freescale.com>
Message-ID: <20070707084114.GD8448@clifford.at>

Hi,

On Sat, Jul 07, 2007 at 12:24:43AM -0500, Timur Tabi wrote:
> Clifford Wolf wrote:
>> Hi,
>> On Mon, Jun 25, 2007 at 08:01:10PM +0200, Clifford Wolf wrote:
>>> I've put a 'draft header file' of an api as I would have expected it
>>> online: [...]
>> Ok, so here comes the first implementation:
>> (I also have other projects, so it took a while.. ;-)
>> 	http://www.clifford.at/priv/dmatransfer-20070704.diff
>
> Why aren't you following the DMA API in include/linux/dmaengine.h?

because dmaengine statically assigns dma channels to drivers. it does trhat
becaus it is in fact not a generic api but only designed for speeding up
TCP using the Intel I/OAT engine. If more drivers would try to use it one
would need to decide at compile time which driver should be the one that
may use the dmaengine.

My dmatransfer api assigns the dma channels dynamically and there is no
limit how many drivers could use dmatransfer instead of ioremap and memcpy.

Also my framework has support for scatter/gather dma, fifo modes and all
that stuff (but the mpc8349dma driver doen't implement it yet).

'Extending' dmaengine in a way so it supports all this would result in
replacing every public api function of dmaengine and having a much more
complicated backend. The only current dmaengine user is the tcp/ip code
which is just a few (less than 10 if i remember correctly) lines of code.

Imo dmaengine should be replaced by an entirely different api instead of
hacking around its shortcommings. Thats why I propose the dmatransfer api.

yours,
 - clifford

-- 
for(var d,i=<>just</>,j=function(){d~=i~(defined(i=next[*],i)?" ":"
");},just,another,SPL,hacker;defined i||({debug d;return 0;});j());


From arnd at arndb.de  Sat Jul  7 23:08:03 2007
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 7 Jul 2007 15:08:03 +0200
Subject: Mem-2-Mem DMA - Generalized API
In-Reply-To: <20070704090554.GA30693@clifford.at>
References: <20070624193932.GA11797@clifford.at>
	<20070625180110.GH20463@clifford.at>
	<20070704090554.GA30693@clifford.at>
Message-ID: <200707071508.04143.arnd@arndb.de>

On Wednesday 04 July 2007, Clifford Wolf wrote:
> Ok, so here comes the first implementation:
> (I also have other projects, so it took a while.. ;-)
>
>         http://www.clifford.at/priv/dmatransfer-20070704.diff
>
> This is just for the MPC8349 DMA now, registers are still hardcoded in the
> driver instead of beeing taken from the platform files and support for
> scatter-gather is still missing and the Kconfig integration isn't checking
> if we are building for the mpc8349 (or even ppc) yet. But I think the
> direction of the API is pretty clear.

Is this a superset of what the dmaengine API can do? If not, I would
guess that things can get really confusing for the user.
Is it possible to wrap the existing dmaengine code inside of a
dmatransfer implementation?

You should probably have the authors of the dmaengine on Cc in
your next version of the driver, if you indend to replace their
code.

> +
> +/*** A dmatransfer is described using input and output chunks ***/
> +
> +// set one of this bits in fifo mode an none in linear mode

Please follow the common kernel commenting style, which allows

/* one-line comment */

/*
 * multi-line
 * comment
 */

/**
 * identifier - description in kerneldoc format
 * @name: struct member or function argument
 * @name2: another one
 *
 * long description here
 */

> +struct dmatransfer
> +{
> +	struct kref refcount;
> +
> +	// callbacks (may be called in interrupt context)
> +	dmatransfer_progress_callback_t progress_callback;
> +	dmatransfer_finish_callback_t finish_callback;
> +	dmatransfer_release_callback_t release_callback;
> +
> +	// private data from the requestor
> +	union {
> +		void *data_voidp;
> +		__u32 data_u32;
> +		__u64 data_u64;
> +	} data;

This could simply be an unsigned long, I guess. We tend to
use unsigned long for generic data, unless it always is a pointer.

> +	__u32 flags;
> +
> +	// how many input and output junks
> +	int n_input_chunks;
> +	int n_output_chunks;

unsigned?

> +	// these are used internally in dmatransfer_request_*
> +	enum {
> +		DMATRANSFER_ASYNC,
> +		DMATRANSFER_WAITING,
> +		DMATRANSFER_FINISHED
> +	} status;
> +	wait_queue_head_t wq;
> +
> +	// these are used internally in the backends
> +	struct dmatransfer_backend *backend;
> +	struct list_head backend_spool;
> +	void *backend_data_voidp;
> +
> +	// this array first contains all input and output chunk descriptions (in
> this order) +	struct dmatransfer_chunk chunks[];
> +};



> +
> +// This functions may return -EINVAL when the requested transfer can't be
> +// done in hardware and DMATRANSFER_DMAONLY is set and -EAGAIN if there
> are +// no free DMA channels and DMATRANSFER_NOSPOOL is set for the
> transfer. +extern int dmatransfer_request_async(struct dmatransfer
> *transfer); 

Put the description in front of the function definition in kerneldoc format

> +extern int dmatransfer_request_wait(struct dmatransfer *transfer); 
> +extern struct dmatransfer *dmatransfer_malloc(int chunks_n, int flags);

maybe better dmatransfer_alloc instead of dmatransfer_malloc?
To me, malloc sort of implies that it only does a pure allocation,
not also the initialization.

> +extern void dmatransfer_release(struct kref *kref);

There is a recent tendency to always leave out the 'extern' keyword
for function declarations.

> +/*** Backend drivers register themself using this struct ***/
> +
> +enum dmatransfer_quality {
> +	DMATRANSFER_QUALITY_NO = 0,
> +	DMATRANSFER_QUALITY_SOFT = 1,
> +	DMATRANSFER_QUALITY_SPOOL = 2,
> +	DMATRANSFER_QUALITY_GOOD = 3,
> +	DMATRANSFER_QUALITY_BEST = 4,
> +};
> +
> +struct dmatransfer_backend
> +{
> +	enum dmatransfer_quality (*check)(struct dmatransfer *transfer);
> +	void (*perform)(struct dmatransfer *transfer);
> +
> +	// performing transfers is 'reading' and unregistering is 'writing'
> +	struct rw_semaphore unreg_sem;
> +
> +	// internally used by the dmatransfer core
> +	struct list_head backend_list;
> +};
> +
> +extern void dmatransfer_finish(struct dmatransfer *transfer);
> +
> +extern void dmatransfer_register_backend(struct dmatransfer_backend
> *backend); +
> +// This function may sleep until all pending dma transfers for this
> backend +// have been finished.
> +extern void dmatransfer_unregister_backend(struct dmatransfer_backend
> *backend); +
> +#endif /* DMATRANSFER_H */
> +


> +#include <linux/dmatransfer.h>
> +#include <linux/module.h>
> +#include <linux/sched.h>
> +
> +static rwlock_t backend_list_lock = RW_LOCK_UNLOCKED;
> +static LIST_HEAD(backend_list);
> +
> +static int dmatransfer_request_worker(struct dmatransfer *transfer)
> +{
> +	enum dmatransfer_quality best_quality = DMATRANSFER_QUALITY_NO;
> +	struct dmatransfer_backend *best_backend = 0;
> +	int error_ret = -EINVAL;
> +	struct list_head *p;
> +
> +	// WARNING:
> +	// There is a non-critical race in this codepath: backend->check() may
> return +	// that the DMA request can be performed without spooling for two
> concurrently +	// running dmatransfer_request_worker() instances. If the
> backend has only one +	// free channel this will result in one request
> beeing executed without spooling +	// and the other one beeing spooled. So
> DMATRANSFER_NOSPOOL does not guarantee +	// that the request isn't spooled
> - just that we _try_ to avoid spooling. +

You appear to have a lot of overly long lines. Try to limit your code to less
than 80 characters per line.

> +struct dmatransfer *dmatransfer_malloc(int chunks_n, int flags)
> +{
> +	size_t transfer_size = sizeof(struct dmatransfer) + 2*sizeof(struct
> dmatransfer_chunk); +	struct dmatransfer *transfer = kmalloc(transfer_size,
> flags);
> +	memset(transfer, 0, transfer_size);

Use kzalloc instead kmalloc+memset.

> +void dmatransfer_register_backend(struct dmatransfer_backend *backend)
> +{
> +	unsigned long irqflags;
> +
> +	init_rwsem(&backend->unreg_sem);
> +
> +	write_lock_irqsave(&backend_list_lock, irqflags);
> +	INIT_LIST_HEAD(&backend->backend_list);
> +	list_add(&backend->backend_list, &backend_list);
> +	write_unlock_irqrestore(&backend_list_lock, irqflags);
> +}
> +
> +void dmatransfer_unregister_backend(struct dmatransfer_backend *backend)
> +{
> +	unsigned long irqflags;
> +	write_lock_irqsave(&backend_list_lock, irqflags);
> +	list_del(&backend->backend_list);
> +	write_unlock_irqrestore(&backend_list_lock, irqflags);
> +
> +	// make sure all pending requests have finished before returning
> +	down_write(&backend->unreg_sem);
> +	up_write(&backend->unreg_sem);
> +}

This usage of rw semaphores looks fishy. 

> +EXPORT_SYMBOL(dmatransfer_request_async);
> +EXPORT_SYMBOL(dmatransfer_request_wait);
> +
> +EXPORT_SYMBOL(dmatransfer_malloc);
> +EXPORT_SYMBOL(dmatransfer_release);
> +
> +EXPORT_SYMBOL(dmatransfer_finish);
> +
> +EXPORT_SYMBOL(dmatransfer_register_backend);
> +EXPORT_SYMBOL(dmatransfer_unregister_backend);

Please put the EXPORT_SYMBOL lines directly below the respective symbol definitions.
Also, make them EXPORT_SYMBOL_GPL() or explain why you don't. For new subsystems,
we normally don't use non-GPL exports any more.

> +#define CHANNEL_N 4
> +
> +static LIST_HEAD(spool);
> +static struct dmatransfer *spool_current_transfers[CHANNEL_N];
> +static spinlock_t spool_lock = SPIN_LOCK_UNLOCKED;

use DEFINE_SPINLOCK instead of assigning to SPIN_LOCK_UNLOCKED.

> +#define BIT(_name, _n) (1<<(_n))

I personally don't like such macros. Why don't you just define named
constants for the bits in there right position?

s/BIT(TE, 7)/DMASR_TE/

> +		iowrite32(transfer->chunks[0].bus_address,
> reg_map[i]+REG_OFFSET_DMASAR);
> +		iowrite32(transfer->chunks[1].bus_address,
> reg_map[i]+REG_OFFSET_DMADAR); +		iowrite32(transfer->chunks[1].bytecount, 
>  reg_map[i]+REG_OFFSET_DMABCR); +
> +		iowrite32(BIT(TE, 7) | BIT(EOSI, 1) | BIT(EOCDI, 0),
> reg_map[i]+REG_OFFSET_DMASR); +
> +		dmamr = 0;
> +		dmamr |= BIT(EOTIE, 7);
> +		dmamr |= BIT(CTM, 2);
> +		iowrite32(dmamr, reg_map[i]+REG_OFFSET_DMAMR);
> +
> +		dmamr |= BIT(CS, 0);
> +		iowrite32(dmamr, reg_map[i]+REG_OFFSET_DMAMR);
> +	}
> +}

iowrite32 is currently only well-defined for PCI devices, which I believe
this devide is not. Use out_be32 or out_le32 instead.

> +		if ((dmasr & (BIT(TE, 7) | BIT(EOCDI, 0))) != 0) {
> +			if ((dmasr & BIT(TE, 7)) != 0) {
> +				printk(KERN_ERR "MPC8349 DMA Transfer Error on DMA channel #%d.\n",
> i); +				BUG();
> +			} 

BUG() may be a little harsh here, especially since you are holding spinlocks.
It would be better to try to recover here, unless you expect actual data
corruption, in which case a full panic() might be more appropriate.

	Arnd <><


From clifford at clifford.at  Sat Jul  7 23:27:48 2007
From: clifford at clifford.at (Clifford Wolf)
Date: Sat, 7 Jul 2007 15:27:48 +0200
Subject: Mem-2-Mem DMA - Generalized API
In-Reply-To: <200707071508.04143.arnd@arndb.de>
References: <20070624193932.GA11797@clifford.at>
	<20070625180110.GH20463@clifford.at>
	<20070704090554.GA30693@clifford.at>
	<200707071508.04143.arnd@arndb.de>
Message-ID: <20070707132748.GB32740@clifford.at>

Hi,

Thanks for your feedback. I will incorporate to my code and release a new
version of Tuesday when I'm back in the office..

On Sat, Jul 07, 2007 at 03:08:03PM +0200, Arnd Bergmann wrote:
> > +void dmatransfer_unregister_backend(struct dmatransfer_backend *backend)
> > +{
> > +	unsigned long irqflags;
> > +	write_lock_irqsave(&backend_list_lock, irqflags);
> > +	list_del(&backend->backend_list);
> > +	write_unlock_irqrestore(&backend_list_lock, irqflags);
> > +
> > +	// make sure all pending requests have finished before returning
> > +	down_write(&backend->unreg_sem);
> > +	up_write(&backend->unreg_sem);
> > +}
> 
> This usage of rw semaphores looks fishy. 

yep. do you have a better idea how to implement this easily?

> > +		if ((dmasr & (BIT(TE, 7) | BIT(EOCDI, 0))) != 0) {
> > +			if ((dmasr & BIT(TE, 7)) != 0) {
> > +				printk(KERN_ERR "MPC8349 DMA Transfer Error on DMA channel #%d.\n",
> > i); +				BUG();
> > +			} 
> 
> BUG() may be a little harsh here, especially since you are holding spinlocks.
> It would be better to try to recover here, unless you expect actual data
> corruption, in which case a full panic() might be more appropriate.

in this way dmatransfer() is designed to be used like memcpy(): you don't
try and check for errors afterwards, you only start a dmatransfer if you
know it is ok and can't fail.

This codepath triggeres if 'the impossible' happens: a dma transfer
actually fails. Since there is no datapath to communicate this error back
to the caller it is almost sure that we have lost data. I will change that
to use panic() instead.

yours,
 - clifford

-- 
Some languages are designed to solve a problem. Others are designed to
prove a point.


From clifford at clifford.at  Sat Jul  7 23:34:14 2007
From: clifford at clifford.at (Clifford Wolf)
Date: Sat, 7 Jul 2007 15:34:14 +0200
Subject: Mem-2-Mem DMA - Generalized API
In-Reply-To: <200707071508.04143.arnd@arndb.de>
References: <20070624193932.GA11797@clifford.at>
	<20070625180110.GH20463@clifford.at>
	<20070704090554.GA30693@clifford.at>
	<200707071508.04143.arnd@arndb.de>
Message-ID: <20070707133414.GC32740@clifford.at>

Hi again,

On Sat, Jul 07, 2007 at 03:08:03PM +0200, Arnd Bergmann wrote:
> Is this a superset of what the dmaengine API can do? If not, I would
> guess that things can get really confusing for the user.

dmatransfer should replace the dmaengine API. dmaengine has only one client
(the tcp/ip network stack - just a few lines of code) and provides only one
driver (ioatdma).

I would have added a ioatdma driver to dmatransfer but unfortunately I
don't have the hardware..

> Is it possible to wrap the existing dmaengine code inside of a
> dmatransfer implementation?

sure - but that wouldn't make much sense. dmaengine gives away exclusive
use rights to dma channels. so if dmatransfer is using dmaengine, noone
else could use it.

> You should probably have the authors of the dmaengine on Cc in
> your next version of the driver, if you indend to replace their
> code.

I'll write them a personal mail to get things rolling as soon as the next
dmatransfer release with the cleanups you suggested and scatter/gather as
well as fifo support is out.

yours,
 - clifford

-- 
ocaml graphics.cma <( echo 'open Graphics;;open_graph " 640x480"let
complex_mul(a,b)(c,d)=(a*.c-.b*.d,a*.d+.b*.c)let complex_add(a,b)(c
,d)=(a+.c,b+.d);;let rec mandel c n=if n>0 then let z=mandel c(n-1)
in complex_add(complex_mul z z)c else (0.0,0.0);; for x=0 to 640 do
for y=0 to 480 do let c=((float_of_int(x-450))/.200.0,(float_of_int
(y-240))/.200.0) in let cabs2(a,b)=(a*.a)+.(b*.b)in if cabs2(mandel
c 50)<4.0 then plot x y done done;;read_line()' )


From arnd at arndb.de  Sat Jul  7 23:28:00 2007
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 7 Jul 2007 15:28:00 +0200
Subject: Mem-2-Mem DMA - Generalized API
In-Reply-To: <20070707132748.GB32740@clifford.at>
References: <20070624193932.GA11797@clifford.at>
	<200707071508.04143.arnd@arndb.de>
	<20070707132748.GB32740@clifford.at>
Message-ID: <200707071528.00449.arnd@arndb.de>

On Saturday 07 July 2007, Clifford Wolf wrote:
> > > +???// make sure all pending requests have finished before returning
> > > +???down_write(&backend->unreg_sem);
> > > +???up_write(&backend->unreg_sem);
> > > +}
> > 
> > This usage of rw semaphores looks fishy. 
> 
> yep. do you have a better idea how to implement this easily?
> 

I'd guess what you really want is reference counting. Every request
that gets assigned to a backend should get a kref on that backend
and give that up once it gets released itself.

I guess you can then have one more reference that you get in
dmatransfer_register_backend and release in dmatransfer_unregister_backend.
When you release the last reference, you call complete(),
and dmatransfer_unregister_backend() ends with a wait_for_completion().

	Arnd <><


From mark at mtfhpc.demon.co.uk  Sat Jul  7 02:21:21 2007
From: mark at mtfhpc.demon.co.uk (Mark Fortescue)
Date: Fri, 6 Jul 2007 17:21:21 +0100 (BST)
Subject: ARCH=ppc vs ARCH=powerpc
Message-ID: <Pine.LNX.4.61.0707061706140.4792@mtfhpc.demon.co.uk>

Hi,

I have noticed and read a few comments regarding the demise of ARCH=ppc.

Having two PowerPC arcitectures and only supprting one of them makes 
little sense. Is it not time to migrate (where required) the remaining 
code from arch/ppc to arch/powerpc and asm-ppc to asm-powerpc. There are 
not many files left that are unique to ARCH=ppc so it should not take too 
long.

For me, the requirement is to keep support for the cards indicated in 
arch/ppc/config/xxx_defconfig (as I have one that I might what to use with 
linux) in the same way as they are supported in ARCH=ppc.

I have just made some tweeks to get ARCH=ppc building for me but I still 
need to sort out what is required to get around *** Error: Headers not 
exportable for this architecture (ppc).

Regards
 	Mark Fortescue.



From sahil.satpute at gmail.com  Fri Jul  6 16:33:28 2007
From: sahil.satpute at gmail.com (linuxdev)
Date: Thu, 5 Jul 2007 23:33:28 -0700 (PDT)
Subject: Porting kernel to MPC 74X7
Message-ID: <11459454.post@talk.nabble.com>


HI guys!

I have to port  a linux kernel on Motorola MPC 74X7 based board.
Since am pretty new to this tech, I would be grateful if anyone could help
with directing to information source or guide me in selecting a proper
kernel and the respective BSP.

Thanks...
-- 
View this message in context: http://www.nabble.com/Porting-kernel-to-MPC-74X7-tf4033888.html#a11459454
Sent from the linuxppc-embedded mailing list archive at Nabble.com.



From arnd at arndb.de  Mon Jul  9 10:34:14 2007
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 9 Jul 2007 02:34:14 +0200
Subject: ARCH=ppc vs ARCH=powerpc
In-Reply-To: <Pine.LNX.4.61.0707061706140.4792@mtfhpc.demon.co.uk>
References: <Pine.LNX.4.61.0707061706140.4792@mtfhpc.demon.co.uk>
Message-ID: <200707090234.14851.arnd@arndb.de>

On Friday 06 July 2007, Mark Fortescue wrote:
> For me, the requirement is to keep support for the cards indicated in 
> arch/ppc/config/xxx_defconfig (as I have one that I might what to use with 
> linux) in the same way as they are supported in ARCH=ppc.

The one thing that is holding up the transition to arch/powerpc is lack
of people with access to the respective boards. If you have one board
that you care about, it would be good if you look into getting it moved
over. Tell us if you have problems doing so. It shouldn't be all that
hard any more, and if it is, maybe some documentation is missing.

> I have just made some tweeks to get ARCH=ppc building for me but I still 
> need to sort out what is required to get around *** Error: Headers not 
> exportable for this architecture (ppc).

You should simply install the headers with ARCH=powerc, even when the
kernel is built with ARCH=ppc. From the user space point of view, there
is only one set of headers.

	Arnd <><


From LeoLi at freescale.com  Mon Jul  9 13:01:00 2007
From: LeoLi at freescale.com (Li Yang-r58472)
Date: Mon, 9 Jul 2007 11:01:00 +0800
Subject: mpc83xx USB support status
In-Reply-To: <fa686aa40707061302o6ed9ec7cq2b9cdba2553cee7a@mail.gmail.com>
Message-ID: <989B956029373F45A0B8AF0297081890F05B32@zch01exm26.fsl.freescale.net>

> -----Original Message-----
> From: glikely at secretlab.ca [mailto:glikely at secretlab.ca] On Behalf Of
Grant
> Likely
> Sent: Saturday, July 07, 2007 4:02 AM
> To: Li Yang-r58472; Tabi Timur-B04825; Behan Webster; Linux PPC Linux
PPC
> Subject: mpc83xx USB support status
> 
> Li,
> 
> What is the state of mpc83xx support in arch/powerpc?  I saw some of
> the patches you posted to the ppc and usb-devel lists, but I want to
> make sure I've got the whole set.  Also, can you tell me what the
> state of those patches are (ie. which ones will be picked up for
> 2.6.23?)

The USB host/gadget should be working in arch/powerpc with all the
patches I submitted to ppc and usb-devel applied.  AFAIK, all the
patches posted to usb-devel will be picked up for 2.6.23.  I hope the
platform rework code will also be picked up; I see nothing preventing it
from being included.

> 
> I'm working on the mpc8349-mitx-gp board, and I can do the work to get
> your changes working on that board.

Good, the USB drivers are intended to be platform independent.  The soc
specific configuration will be done in the rework patch I submitted.
The only thing you need to take care of is board specific setup.  Feel
free to contact me if you have any problem.

- Leo


From jwboyer at jdub.homelinux.org  Mon Jul  9 13:37:30 2007
From: jwboyer at jdub.homelinux.org (Josh Boyer)
Date: Sun, 08 Jul 2007 22:37:30 -0500
Subject: ARCH=ppc vs ARCH=powerpc
In-Reply-To: <200707090234.14851.arnd@arndb.de>
References: <Pine.LNX.4.61.0707061706140.4792@mtfhpc.demon.co.uk>
	<200707090234.14851.arnd@arndb.de>
Message-ID: <1183952250.3308.0.camel@vader.jdub.homelinux.org>

On Mon, 2007-07-09 at 02:34 +0200, Arnd Bergmann wrote:
> On Friday 06 July 2007, Mark Fortescue wrote:
> > For me, the requirement is to keep support for the cards indicated in 
> > arch/ppc/config/xxx_defconfig (as I have one that I might what to use with 
> > linux) in the same way as they are supported in ARCH=ppc.
> 
> The one thing that is holding up the transition to arch/powerpc is lack
> of people with access to the respective boards. If you have one board
> that you care about, it would be good if you look into getting it moved
> over. Tell us if you have problems doing so. It shouldn't be all that
> hard any more, and if it is, maybe some documentation is missing.

It's not just lack of boards.  It's lack of understanding of the
requirements to get a board port into arch/powerpc.  Namely, the device
tree stuff.

josh



From jwboyer at jdub.homelinux.org  Mon Jul  9 13:38:28 2007
From: jwboyer at jdub.homelinux.org (Josh Boyer)
Date: Sun, 08 Jul 2007 22:38:28 -0500
Subject: ARCH=ppc vs ARCH=powerpc
In-Reply-To: <Pine.LNX.4.61.0707061706140.4792@mtfhpc.demon.co.uk>
References: <Pine.LNX.4.61.0707061706140.4792@mtfhpc.demon.co.uk>
Message-ID: <1183952308.3308.2.camel@vader.jdub.homelinux.org>

On Fri, 2007-07-06 at 17:21 +0100, Mark Fortescue wrote:
> Hi,
> 
> I have noticed and read a few comments regarding the demise of ARCH=ppc.
> 
> Having two PowerPC arcitectures and only supprting one of them makes 
> little sense. Is it not time to migrate (where required) the remaining 
> code from arch/ppc to arch/powerpc and asm-ppc to asm-powerpc. There are 
> not many files left that are unique to ARCH=ppc so it should not take too 
> long.

It was started in 2005.  It's taken too long already.

Bug fixes will still be taken until arch/ppc dies.  New platform/board
support, no.

josh



From jcrigby at gmail.com  Mon Jul  9 13:55:20 2007
From: jcrigby at gmail.com (John Rigby)
Date: Sun, 8 Jul 2007 21:55:20 -0600
Subject: [PATCH] Add USB support to mpc8349-mitx board port
In-Reply-To: <fa686aa40707071748g7f00f4c7jb761cceb7d72456d@mail.gmail.com>
References: <20070706222909.19943.39455.stgit@trillian.secretlab.ca>
	<200707070148.20526.arnd@arndb.de>
	<fa686aa40707062246j71a347acje8559b7b6be9d38b@mail.gmail.com>
	<4b73d43f0707071734yeedd7e6g53101d45fbec899e@mail.gmail.com>
	<fa686aa40707071748g7f00f4c7jb761cceb7d72456d@mail.gmail.com>
Message-ID: <4b73d43f0707082055y2b96fa53td55d6b381b6fb0ef@mail.gmail.com>

I see your point, I agree the two layers of glue is bad.  But this means
the double code is spread across many drivers instead of being in one
place (fsl_soc.c).

On 7/7/07, Grant Likely <grant.likely at secretlab.ca> wrote:
>
> On 7/7/07, John Rigby <jcrigby at gmail.com> wrote:
> > > This same comment probably goes for the other arch_initcall functions
> > > in fsl_soc.c which do exactly the same thing for other devices.
> >
> > This depends,  some devices in fsl_soc.c may exist on non-powerpc SoCs
> > that do not have OF.  The USB core in 8349 for example also is in the
> > arm based mx27 and mx31.  These devices should remain platform devices
> > and the glue in fls_soc.c will continure to be needed.
>
> I disagree; the current method is "glue for the glue".  There is no
> reason why the driver cannot have two bindings; one for
> platform_device and one for of_platform_device.  It's about the same
> amount of code, but uses less indirection for the device tree case.
>
> Cheers,
> g.
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely at secretlab.ca
> (403) 399-0195
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070708/01956efd/attachment.htm 

From domen.puncer at telargo.com  Mon Jul  9 17:19:55 2007
From: domen.puncer at telargo.com (Domen Puncer)
Date: Mon, 9 Jul 2007 09:19:55 +0200
Subject: [PATCH] i2c-mpc: work around missing-9th-clock-pulse bug
Message-ID: <20070709071955.GD4186@moe.telargo.com>

Work around a problem reported on:
http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019038.html
Without this patch I2C on mpc5200 becomes unusable after a while.
Tested on mpc5200 based boards by Matthias and me.


Signed-off-by: Domen Puncer <domen.puncer at telargo.com>

---
 drivers/i2c/busses/i2c-mpc.c |   19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

Index: work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
===================================================================
--- work-powerpc.git.orig/drivers/i2c/busses/i2c-mpc.c
+++ work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
@@ -74,6 +74,20 @@ static irqreturn_t mpc_i2c_isr(int irq, 
 	return IRQ_HANDLED;
 }
 
+static void mpc_i2c_fixup(struct mpc_i2c *i2c)
+{
+	writeccr(i2c, 0);
+	udelay(30);
+	writeccr(i2c, CCR_MEN);
+	udelay(30);
+	writeccr(i2c, CCR_MSTA | CCR_MTX);
+	udelay(30);
+	writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);
+	udelay(30);
+	writeccr(i2c, CCR_MEN);
+	udelay(30);
+}
+
 static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
 {
 	unsigned long orig_jiffies = jiffies;
@@ -153,6 +167,9 @@ static void mpc_i2c_start(struct mpc_i2c
 static void mpc_i2c_stop(struct mpc_i2c *i2c)
 {
 	writeccr(i2c, CCR_MEN);
+	mb();
+	writeccr(i2c, 0);
+	mb();
 }
 
 static int mpc_write(struct mpc_i2c *i2c, int target,
@@ -245,6 +262,8 @@ static int mpc_xfer(struct i2c_adapter *
 		}
 		if (time_after(jiffies, orig_jiffies + HZ)) {
 			pr_debug("I2C: timeout\n");
+			if (readb(i2c->base + MPC_I2C_SR) == (CSR_MCF | CSR_MBB | CSR_RXAK))
+				mpc_i2c_fixup(i2c);
 			return -EIO;
 		}
 		schedule();


From domen.puncer at telargo.com  Mon Jul  9 17:49:53 2007
From: domen.puncer at telargo.com (Domen Puncer)
Date: Mon, 9 Jul 2007 09:49:53 +0200
Subject: [PATCH] mpc5200: low power mode
Message-ID: <20070709074953.GE4186@moe.telargo.com>

Low-power mode implementation for Lite5200b.
Some I/O registers are also saved here.

A recent U-Boot that supports this (lite5200b_PM_config) is needed.


Signed-off-by: Domen Puncer <domen.puncer at telargo.com>

---
It would be nice to get this merged.

 arch/powerpc/platforms/52xx/Makefile         |    3 
 arch/powerpc/platforms/52xx/lite5200.c       |   14 
 arch/powerpc/platforms/52xx/lite5200_pm.c    |  213 +++++++++++++
 arch/powerpc/platforms/52xx/lite5200_sleep.S |  413 +++++++++++++++++++++++++++
 include/asm-powerpc/mpc52xx.h                |   10 
 5 files changed, 648 insertions(+), 5 deletions(-)

Index: work-powerpc.git/arch/powerpc/platforms/52xx/lite5200_pm.c
===================================================================
--- /dev/null
+++ work-powerpc.git/arch/powerpc/platforms/52xx/lite5200_pm.c
@@ -0,0 +1,213 @@
+#include <linux/init.h>
+#include <linux/pm.h>
+#include <asm/io.h>
+#include <asm/time.h>
+#include <asm/mpc52xx.h>
+#include "mpc52xx_pic.h"
+
+/* defined in lite5200_sleep.S and only used here */
+extern void lite5200_low_power(void __iomem *sram, void __iomem *mbar);
+
+static struct mpc52xx_cdm __iomem *cdm;
+static struct mpc52xx_intr __iomem *pic;
+static struct mpc52xx_sdma __iomem *bes;
+static struct mpc52xx_xlb __iomem *xlb;
+static struct mpc52xx_gpio __iomem *gps;
+static struct mpc52xx_gpio_wkup __iomem *gpw;
+static void __iomem *sram;
+static const int sram_size = 0x4000;	/* 16 kBytes */
+static void __iomem *mbar;
+
+static int lite5200_pm_valid(suspend_state_t state)
+{
+	switch (state) {
+	case PM_SUSPEND_STANDBY:
+	case PM_SUSPEND_MEM:
+		return 1;
+	default:
+		return 0;
+	}
+}
+
+static int lite5200_pm_prepare(suspend_state_t state)
+{
+	/* deep sleep? let mpc52xx code handle that */
+	if (state == PM_SUSPEND_STANDBY)
+		return mpc52xx_pm_prepare(state);
+
+	if (state != PM_SUSPEND_MEM)
+		return -EINVAL;
+
+	/* map registers */
+	mbar = mpc52xx_find_and_map("mpc5200");
+	if (!mbar) {
+		printk(KERN_ERR "%s:%i Error mapping registers\n", __func__, __LINE__);
+		return -ENOSYS;
+	}
+
+	cdm = mbar + 0x200;
+	pic = mbar + 0x500;
+	gps = mbar + 0xb00;
+	gpw = mbar + 0xc00;
+	bes = mbar + 0x1200;
+	xlb = mbar + 0x1f00;
+	sram = mbar + 0x8000;
+
+	return 0;
+}
+
+/* save and restore registers not bound to any real devices */
+static struct mpc52xx_cdm scdm;
+static struct mpc52xx_intr spic;
+static struct mpc52xx_sdma sbes;
+static struct mpc52xx_xlb sxlb;
+static struct mpc52xx_gpio sgps;
+static struct mpc52xx_gpio_wkup sgpw;
+
+static void lite5200_save_regs(void)
+{
+	_memcpy_fromio(&spic, pic, sizeof(*pic));
+	_memcpy_fromio(&sbes, bes, sizeof(*bes));
+	_memcpy_fromio(&scdm, cdm, sizeof(*cdm));
+	_memcpy_fromio(&sxlb, xlb, sizeof(*xlb));
+	_memcpy_fromio(&sgps, gps, sizeof(*gps));
+	_memcpy_fromio(&sgpw, gpw, sizeof(*gpw));
+
+	_memcpy_fromio(saved_sram, sram, sram_size);
+}
+
+static void lite5200_restore_regs(void)
+{
+	int i;
+	_memcpy_toio(sram, saved_sram, sram_size);
+
+
+	/*
+	 * GPIOs. Interrupt Master Enable has higher address then other
+	 * registers, so just memcpy is ok.
+	 */
+	_memcpy_toio(gpw, &sgpw, sizeof(*gpw));
+	_memcpy_toio(gps, &sgps, sizeof(*gps));
+
+
+	/* XLB Arbitrer */
+	out_be32(&xlb->snoop_window, sxlb.snoop_window);
+	out_be32(&xlb->master_priority, sxlb.master_priority);
+	out_be32(&xlb->master_pri_enable, sxlb.master_pri_enable);
+
+	/* enable */
+	out_be32(&xlb->int_enable, sxlb.int_enable);
+	out_be32(&xlb->config, sxlb.config);
+
+
+	/* CDM - Clock Distribution Module */
+	out_8(&cdm->ipb_clk_sel, scdm.ipb_clk_sel);
+	out_8(&cdm->pci_clk_sel, scdm.pci_clk_sel);
+
+	out_8(&cdm->ext_48mhz_en, scdm.ext_48mhz_en);
+	out_8(&cdm->fd_enable, scdm.fd_enable);
+	out_be16(&cdm->fd_counters, scdm.fd_counters);
+
+	out_be32(&cdm->clk_enables, scdm.clk_enables);
+
+	out_8(&cdm->osc_disable, scdm.osc_disable);
+
+	out_be16(&cdm->mclken_div_psc1, scdm.mclken_div_psc1);
+	out_be16(&cdm->mclken_div_psc2, scdm.mclken_div_psc2);
+	out_be16(&cdm->mclken_div_psc3, scdm.mclken_div_psc3);
+	out_be16(&cdm->mclken_div_psc6, scdm.mclken_div_psc6);
+
+
+	/* BESTCOMM */
+	out_be32(&bes->taskBar, sbes.taskBar);
+	out_be32(&bes->currentPointer, sbes.currentPointer);
+	out_be32(&bes->endPointer, sbes.endPointer);
+	out_be32(&bes->variablePointer, sbes.variablePointer);
+
+	out_8(&bes->IntVect1, sbes.IntVect1);
+	out_8(&bes->IntVect2, sbes.IntVect2);
+	out_be16(&bes->PtdCntrl, sbes.PtdCntrl);
+
+	for (i=0; i<32; i++)
+		out_8(&bes->ipr[i], sbes.ipr[i]);
+
+	out_be32(&bes->cReqSelect, sbes.cReqSelect);
+	out_be32(&bes->task_size0, sbes.task_size0);
+	out_be32(&bes->task_size1, sbes.task_size1);
+	out_be32(&bes->MDEDebug, sbes.MDEDebug);
+	out_be32(&bes->ADSDebug, sbes.ADSDebug);
+	out_be32(&bes->Value1, sbes.Value1);
+	out_be32(&bes->Value2, sbes.Value2);
+	out_be32(&bes->Control, sbes.Control);
+	out_be32(&bes->Status, sbes.Status);
+	out_be32(&bes->PTDDebug, sbes.PTDDebug);
+
+	/* restore tasks */
+	for (i=0; i<16; i++)
+		out_be16(&bes->tcr[i], sbes.tcr[i]);
+
+	/* enable interrupts */
+	out_be32(&bes->IntPend, sbes.IntPend);
+	out_be32(&bes->IntMask, sbes.IntMask);
+
+
+	/* PIC */
+	out_be32(&pic->per_pri1, spic.per_pri1);
+	out_be32(&pic->per_pri2, spic.per_pri2);
+	out_be32(&pic->per_pri3, spic.per_pri3);
+
+	out_be32(&pic->main_pri1, spic.main_pri1);
+	out_be32(&pic->main_pri2, spic.main_pri2);
+
+	out_be32(&pic->enc_status, spic.enc_status);
+
+	/* unmask and enable interrupts */
+	out_be32(&pic->per_mask, spic.per_mask);
+	out_be32(&pic->main_mask, spic.main_mask);
+	out_be32(&pic->ctrl, spic.ctrl);
+}
+
+static int lite5200_pm_enter(suspend_state_t state)
+{
+	/* deep sleep? let mpc52xx code handle that */
+	if (state == PM_SUSPEND_STANDBY) {
+		return mpc52xx_pm_enter(state);
+	}
+
+	lite5200_save_regs();
+
+	/* effectively save FP regs */
+	enable_kernel_fp();
+
+	lite5200_low_power(sram, mbar);
+
+	lite5200_restore_regs();
+
+	/* restart jiffies */
+	wakeup_decrementer();
+
+	iounmap(mbar);
+	return 0;
+}
+
+static int lite5200_pm_finish(suspend_state_t state)
+{
+	/* deep sleep? let mpc52xx code handle that */
+	if (state == PM_SUSPEND_STANDBY) {
+		return mpc52xx_pm_finish(state);
+	}
+	return 0;
+}
+
+static struct pm_ops lite5200_pm_ops = {
+	.valid		= lite5200_pm_valid,
+	.prepare	= lite5200_pm_prepare,
+	.enter		= lite5200_pm_enter,
+	.finish		= lite5200_pm_finish,
+};
+
+int __init lite5200_pm_init(void)
+{
+	pm_set_ops(&lite5200_pm_ops);
+	return 0;
+}
Index: work-powerpc.git/arch/powerpc/platforms/52xx/lite5200_sleep.S
===================================================================
--- /dev/null
+++ work-powerpc.git/arch/powerpc/platforms/52xx/lite5200_sleep.S
@@ -0,0 +1,413 @@
+#include <asm/reg.h>
+#include <asm/ppc_asm.h>
+#include <asm/processor.h>
+#include <asm/cache.h>
+
+
+#define SDRAM_CTRL	0x104
+#define SC_MODE_EN	(1<<31)
+#define SC_CKE		(1<<30)
+#define SC_REF_EN	(1<<28)
+#define SC_SOFT_PRE	(1<<1)
+
+#define GPIOW_GPIOE	0xc00
+#define GPIOW_DDR	0xc08
+#define GPIOW_DVO	0xc0c
+
+#define CDM_CE		0x214
+#define CDM_SDRAM	(1<<3)
+
+
+/* helpers... beware: r10 and r4 are overwritten */
+#define SAVE_SPRN(reg, addr)		\
+	mfspr	r10, SPRN_##reg;	\
+	stw	r10, ((addr)*4)(r4);
+
+#define LOAD_SPRN(reg, addr)		\
+	lwz	r10, ((addr)*4)(r4);	\
+	mtspr	SPRN_##reg, r10;	\
+	sync;				\
+	isync;
+
+
+	.data
+registers:
+	.space 0x5c*4
+	.text
+
+/* ---------------------------------------------------------------------- */
+/* low-power mode with help of M68HLC908QT1 */
+
+	.globl lite5200_low_power
+lite5200_low_power:
+
+	mr	r7, r3	/* save SRAM va */
+	mr	r8, r4	/* save MBAR va */
+
+	/* setup wakeup address for u-boot at physical location 0x0 */
+	lis	r3, CONFIG_KERNEL_START at h
+	lis	r4, lite5200_wakeup at h
+	ori	r4, r4, lite5200_wakeup at l
+	sub	r4, r4, r3
+	stw	r4, 0(r3)
+
+
+	/*
+	 * save stuff BDI overwrites
+	 * 0xf0 (0xe0->0x100 gets overwritten when BDI connected;
+	 *   even when CONFIG_BDI* is disabled and MMU XLAT commented; heisenbug?))
+	 * WARNING: self-refresh doesn't seem to work when BDI2000 is connected,
+	 *   possibly because BDI sets SDRAM registers before wakeup code does
+	 */
+	lis	r4, registers at h
+	ori	r4, r4, registers at l
+	lwz	r10, 0xf0(r3)
+	stw	r10, (0x1d*4)(r4)
+
+	/* save registers to r4 [destroys r10] */
+	SAVE_SPRN(LR, 0x1c)
+	bl	save_regs
+
+	/* flush caches [destroys r3, r4] */
+	bl	flush_data_cache
+
+
+	/* copy code to sram */
+	mr	r4, r7
+	li	r3, (sram_code_end - sram_code)/4
+	mtctr	r3
+	lis	r3, sram_code at h
+	ori	r3, r3, sram_code at l
+1:
+	lwz	r5, 0(r3)
+	stw	r5, 0(r4)
+	addi	r3, r3, 4
+	addi	r4, r4, 4
+	bdnz	1b
+
+	/* get tb_ticks_per_usec */
+	lis	r3, tb_ticks_per_usec at h
+	lwz	r11, tb_ticks_per_usec at l(r3)
+
+	/* disable I and D caches */
+	mfspr	r3, SPRN_HID0
+	ori	r3, r3, HID0_ICE | HID0_DCE
+	xori	r3, r3, HID0_ICE | HID0_DCE
+	sync; isync;
+	mtspr	SPRN_HID0, r3
+	sync; isync;
+
+	/* jump to sram */
+	mtlr	r7
+	blrl
+	/* doesn't return */
+
+
+sram_code:
+	/* self refresh */
+	lwz	r4, SDRAM_CTRL(r8)
+
+	/* send NOP (precharge) */
+	oris	r4, r4, SC_MODE_EN at h	/* mode_en */
+	stw	r4, SDRAM_CTRL(r8)
+	sync
+
+	ori	r4, r4, SC_SOFT_PRE	/* soft_pre */
+	stw	r4, SDRAM_CTRL(r8)
+	sync
+	xori	r4, r4, SC_SOFT_PRE
+
+	xoris	r4, r4, SC_MODE_EN at h	/* !mode_en */
+	stw	r4, SDRAM_CTRL(r8)
+	sync
+
+	/* delay (for NOP to finish) */
+	li	r12, 1
+	bl	udelay
+
+	/*
+	 * mode_en must not be set when enabling self-refresh
+	 * send AR with CKE low (self-refresh)
+	 */
+	oris	r4, r4, (SC_REF_EN | SC_CKE)@h
+	xoris	r4, r4, (SC_CKE)@h	/* ref_en !cke */
+	stw	r4, SDRAM_CTRL(r8)
+	sync
+
+	/* delay (after !CKE there should be two cycles) */
+	li	r12, 1
+	bl	udelay
+
+	/* disable clock */
+	lwz	r4, CDM_CE(r8)
+	ori	r4, r4, CDM_SDRAM
+	xori	r4, r4, CDM_SDRAM
+	stw	r4, CDM_CE(r8)
+	sync
+
+	/* delay a bit */
+	li	r12, 1
+	bl	udelay
+
+
+	/* turn off with QT chip */
+	li	r4, 0x02
+	stb	r4, GPIOW_GPIOE(r8)	/* enable gpio_wkup1 */
+	sync
+
+	stb	r4, GPIOW_DVO(r8)	/* "output" high */
+	sync
+	stb	r4, GPIOW_DDR(r8)	/* output */
+	sync
+	stb	r4, GPIOW_DVO(r8)	/* output high */
+	sync
+
+	/* 10uS delay */
+	li	r12, 10
+	bl	udelay
+
+	/* turn off */
+	li	r4, 0
+	stb	r4, GPIOW_DVO(r8)	/* output low */
+	sync
+
+	/* wait until we're offline */
+  1:
+	b	1b
+
+
+	/* local udelay in sram is needed */
+  udelay: /* r11 - tb_ticks_per_usec, r12 - usecs, overwrites r13 */
+	mullw	r12, r12, r11
+	mftb	r13	/* start */
+	addi	r12, r13, r12 /* end */
+    1:
+	mftb	r13	/* current */
+	cmp	cr0, r13, r12
+	blt	1b
+	blr
+
+sram_code_end:
+
+
+
+/* uboot jumps here on resume */
+lite5200_wakeup:
+	bl	restore_regs
+
+
+	/* HIDs, MSR */
+	LOAD_SPRN(HID1, 0x19)
+	LOAD_SPRN(HID2, 0x1a)
+
+
+	/* address translation is tricky (see turn_on_mmu) */
+	mfmsr	r10
+	ori	r10, r10, MSR_DR | MSR_IR
+
+
+	mtspr	SPRN_SRR1, r10
+	lis	r10, mmu_on at h
+	ori	r10, r10, mmu_on at l
+	mtspr	SPRN_SRR0, r10
+	sync
+	rfi
+mmu_on:
+	/* kernel offset (r4 is still set from restore_registers) */
+	addis	r4, r4, CONFIG_KERNEL_START at h
+
+
+	/* restore MSR */
+	lwz	r10, (4*0x1b)(r4)
+	mtmsr	r10
+	sync; isync;
+
+	/* invalidate caches */
+	mfspr	r10, SPRN_HID0
+	ori	r5, r10, HID0_ICFI | HID0_DCI
+	mtspr	SPRN_HID0, r5	/* invalidate caches */
+	sync; isync;
+	mtspr	SPRN_HID0, r10
+	sync; isync;
+
+	/* enable caches */
+	lwz	r10, (4*0x18)(r4)
+	mtspr	SPRN_HID0, r10	/* restore (enable caches, DPM) */
+	/* ^ this has to be after address translation set in MSR */
+	sync
+	isync
+
+
+	/* restore 0xf0 (BDI2000) */
+	lis	r3, CONFIG_KERNEL_START at h
+	lwz	r10, (0x1d*4)(r4)
+	stw	r10, 0xf0(r3)
+
+	LOAD_SPRN(LR, 0x1c)
+
+
+	blr
+
+
+/* ---------------------------------------------------------------------- */
+/* boring code: helpers */
+
+/* save registers */
+#define SAVE_BAT(n, addr)		\
+	SAVE_SPRN(DBAT##n##L, addr);	\
+	SAVE_SPRN(DBAT##n##U, addr+1);	\
+	SAVE_SPRN(IBAT##n##L, addr+2);	\
+	SAVE_SPRN(IBAT##n##U, addr+3);
+
+#define SAVE_SR(n, addr)		\
+	mfsr	r10, n;			\
+	stw	r10, ((addr)*4)(r4);
+
+#define SAVE_4SR(n, addr)	\
+	SAVE_SR(n, addr);	\
+	SAVE_SR(n+1, addr+1);	\
+	SAVE_SR(n+2, addr+2);	\
+	SAVE_SR(n+3, addr+3);
+
+save_regs:
+	stw	r0, 0(r4)
+	stw	r1, 0x4(r4)
+	stw	r2, 0x8(r4)
+	stmw	r11, 0xc(r4) /* 0xc -> 0x5f, (0x18*4-1) */
+
+	SAVE_SPRN(HID0, 0x18)
+	SAVE_SPRN(HID1, 0x19)
+	SAVE_SPRN(HID2, 0x1a)
+	mfmsr	r10
+	stw	r10, (4*0x1b)(r4)
+	/*SAVE_SPRN(LR, 0x1c) have to save it before the call */
+	/* 0x1d reserved by 0xf0 */
+	SAVE_SPRN(RPA,   0x1e)
+	SAVE_SPRN(SDR1,  0x1f)
+
+	/* save MMU regs */
+	SAVE_BAT(0, 0x20)
+	SAVE_BAT(1, 0x24)
+	SAVE_BAT(2, 0x28)
+	SAVE_BAT(3, 0x2c)
+	SAVE_BAT(4, 0x30)
+	SAVE_BAT(5, 0x34)
+	SAVE_BAT(6, 0x38)
+	SAVE_BAT(7, 0x3c)
+
+	SAVE_4SR(0, 0x40)
+	SAVE_4SR(4, 0x44)
+	SAVE_4SR(8, 0x48)
+	SAVE_4SR(12, 0x4c)
+
+	SAVE_SPRN(SPRG0, 0x50)
+	SAVE_SPRN(SPRG1, 0x51)
+	SAVE_SPRN(SPRG2, 0x52)
+	SAVE_SPRN(SPRG3, 0x53)
+	SAVE_SPRN(SPRG4, 0x54)
+	SAVE_SPRN(SPRG5, 0x55)
+	SAVE_SPRN(SPRG6, 0x56)
+	SAVE_SPRN(SPRG7, 0x57)
+
+	SAVE_SPRN(IABR,  0x58)
+	SAVE_SPRN(DABR,  0x59)
+	SAVE_SPRN(TBRL,  0x5a)
+	SAVE_SPRN(TBRU,  0x5b)
+
+	blr
+
+
+/* restore registers */
+#define LOAD_BAT(n, addr)		\
+	LOAD_SPRN(DBAT##n##L, addr);	\
+	LOAD_SPRN(DBAT##n##U, addr+1);	\
+	LOAD_SPRN(IBAT##n##L, addr+2);	\
+	LOAD_SPRN(IBAT##n##U, addr+3);
+
+#define LOAD_SR(n, addr)		\
+	lwz	r10, ((addr)*4)(r4);	\
+	mtsr	n, r10;
+
+#define LOAD_4SR(n, addr)	\
+	LOAD_SR(n, addr);	\
+	LOAD_SR(n+1, addr+1);	\
+	LOAD_SR(n+2, addr+2);	\
+	LOAD_SR(n+3, addr+3);
+
+restore_regs:
+	lis	r4, registers at h
+	ori	r4, r4, registers at l
+
+	/* MMU is not up yet */
+	subis	r4, r4, CONFIG_KERNEL_START at h
+
+	lwz	r0, 0(r4)
+	lwz	r1, 0x4(r4)
+	lwz	r2, 0x8(r4)
+	lmw	r11, 0xc(r4)
+
+	/*
+	 * these are a bit tricky
+	 *
+	 * 0x18 - HID0
+	 * 0x19 - HID1
+	 * 0x1a - HID2
+	 * 0x1b - MSR
+	 * 0x1c - LR
+	 * 0x1d - reserved by 0xf0 (BDI2000)
+	 */
+	LOAD_SPRN(RPA,   0x1e);
+	LOAD_SPRN(SDR1,  0x1f);
+
+	/* restore MMU regs */
+	LOAD_BAT(0, 0x20)
+	LOAD_BAT(1, 0x24)
+	LOAD_BAT(2, 0x28)
+	LOAD_BAT(3, 0x2c)
+	LOAD_BAT(4, 0x30)
+	LOAD_BAT(5, 0x34)
+	LOAD_BAT(6, 0x38)
+	LOAD_BAT(7, 0x3c)
+
+	LOAD_4SR(0, 0x40)
+	LOAD_4SR(4, 0x44)
+	LOAD_4SR(8, 0x48)
+	LOAD_4SR(12, 0x4c)
+
+	/* rest of regs */
+	LOAD_SPRN(SPRG0, 0x50);
+	LOAD_SPRN(SPRG1, 0x51);
+	LOAD_SPRN(SPRG2, 0x52);
+	LOAD_SPRN(SPRG3, 0x53);
+	LOAD_SPRN(SPRG4, 0x54);
+	LOAD_SPRN(SPRG5, 0x55);
+	LOAD_SPRN(SPRG6, 0x56);
+	LOAD_SPRN(SPRG7, 0x57);
+
+	LOAD_SPRN(IABR,  0x58);
+	LOAD_SPRN(DABR,  0x59);
+	LOAD_SPRN(TBWL,  0x5a);	/* these two have separate R/W regs */
+	LOAD_SPRN(TBWU,  0x5b);
+
+	blr
+
+
+
+/* cache flushing code. copied from arch/ppc/boot/util.S */
+#define NUM_CACHE_LINES (128*8)
+
+/*
+ * Flush data cache
+ * Do this by just reading lots of stuff into the cache.
+ */
+        .globl flush_data_cache
+flush_data_cache:
+	lis	r3,CONFIG_KERNEL_START at h
+	ori	r3,r3,CONFIG_KERNEL_START at l
+	li	r4,NUM_CACHE_LINES
+	mtctr	r4
+1:
+	lwz	r4,0(r3)
+	addi	r3,r3,L1_CACHE_BYTES	/* Next line, please */
+	bdnz	1b
+	blr
Index: work-powerpc.git/arch/powerpc/platforms/52xx/Makefile
===================================================================
--- work-powerpc.git.orig/arch/powerpc/platforms/52xx/Makefile
+++ work-powerpc.git/arch/powerpc/platforms/52xx/Makefile
@@ -10,3 +10,6 @@ obj-$(CONFIG_PPC_EFIKA)		+= efika.o
 obj-$(CONFIG_PPC_LITE5200)	+= lite5200.o
 
 obj-$(CONFIG_PM)		+= mpc52xx_sleep.o mpc52xx_pm.o
+ifeq ($(CONFIG_PPC_LITE5200),y)
+	obj-$(CONFIG_PM)	+= lite5200_sleep.o lite5200_pm.o
+endif
Index: work-powerpc.git/arch/powerpc/platforms/52xx/lite5200.c
===================================================================
--- work-powerpc.git.orig/arch/powerpc/platforms/52xx/lite5200.c
+++ work-powerpc.git/arch/powerpc/platforms/52xx/lite5200.c
@@ -86,7 +86,6 @@ error:
 }
 
 #ifdef CONFIG_PM
-static u32 descr_a;
 static void lite5200_suspend_prepare(void __iomem *mbar)
 {
 	u8 pin = 1;	/* GPIO_WKUP_1 (GPIO_PSC2_4) */
@@ -97,13 +96,18 @@ static void lite5200_suspend_prepare(voi
 	 * power down usb port
 	 * this needs to be called before of-ohci suspend code
 	 */
-	descr_a = in_be32(mbar + 0x1048);
-	out_be32(mbar + 0x1048, (descr_a & ~0x200) | 0x100);
+
+	/* set ports to "power switched" and "powered at the same time"
+	 * USB Rh descriptor A: NPS = 0, PSM = 0 */
+	out_be32(mbar + 0x1048, in_be32(mbar + 0x1048) & ~0x300);
+	/* USB Rh status: LPS = 1 - turn off power */
+	out_be32(mbar + 0x1050, 0x00000001);
 }
 
 static void lite5200_resume_finish(void __iomem *mbar)
 {
-	out_be32(mbar + 0x1048, descr_a);
+	/* USB Rh status: LPSC = 1 - turn on power */
+	out_be32(mbar + 0x1050, 0x00010000);
 }
 #endif
 
@@ -132,7 +136,7 @@ static void __init lite5200_setup_arch(v
 #ifdef CONFIG_PM
 	mpc52xx_suspend.board_suspend_prepare = lite5200_suspend_prepare;
 	mpc52xx_suspend.board_resume_finish = lite5200_resume_finish;
-	mpc52xx_pm_init();
+ 	lite5200_pm_init();
 #endif
 
 #ifdef CONFIG_PCI
Index: work-powerpc.git/include/asm-powerpc/mpc52xx.h
===================================================================
--- work-powerpc.git.orig/include/asm-powerpc/mpc52xx.h
+++ work-powerpc.git/include/asm-powerpc/mpc52xx.h
@@ -262,6 +262,16 @@ struct mpc52xx_suspend {
 extern struct mpc52xx_suspend mpc52xx_suspend;
 extern int __init mpc52xx_pm_init(void);
 extern int mpc52xx_set_wakeup_gpio(u8 pin, u8 level);
+
+#ifdef CONFIG_PPC_LITE5200
+extern int __init lite5200_pm_init(void);
+
+/* lite5200 calls mpc5200 suspend functions, so here they are */
+extern int mpc52xx_pm_prepare(suspend_state_t);
+extern int mpc52xx_pm_enter(suspend_state_t);
+extern int mpc52xx_pm_finish(suspend_state_t);
+extern char saved_sram[0x4000]; /* reuse buffer from mpc52xx suspend */
+#endif
 #endif /* CONFIG_PM */
 
 #endif /* __ASM_POWERPC_MPC52xx_H__ */


From domen.puncer at telargo.com  Mon Jul  9 17:52:03 2007
From: domen.puncer at telargo.com (Domen Puncer)
Date: Mon, 9 Jul 2007 09:52:03 +0200
Subject: [PATCH] mpc52xx: sparse fixes
In-Reply-To: <20070621074507.GL23294@moe.telargo.com>
References: <20070621074507.GL23294@moe.telargo.com>
Message-ID: <20070709075203.GF4186@moe.telargo.com>

sparse caught these static functions / __iomem annotations
under arch/powerpc/platform/52xx/


Signed-off-by: Domen Puncer <domen.puncer at telargo.com>

---
Reposting, adding tnt to Cc, and requesting inclusion.
The patch is pretty much harmless :-)


 arch/powerpc/platforms/52xx/efika.c      |    4 ++--
 arch/powerpc/platforms/52xx/lite5200.c   |    2 +-
 arch/powerpc/platforms/52xx/mpc52xx_pm.c |    8 ++++----
 3 files changed, 7 insertions(+), 7 deletions(-)

Index: work-powerpc.git/arch/powerpc/platforms/52xx/efika.c
===================================================================
--- work-powerpc.git.orig/arch/powerpc/platforms/52xx/efika.c
+++ work-powerpc.git/arch/powerpc/platforms/52xx/efika.c
@@ -83,7 +83,7 @@ static struct pci_ops rtas_pci_ops = {
 };
 
 
-void __init efika_pcisetup(void)
+static void __init efika_pcisetup(void)
 {
 	const int *bus_range;
 	int len;
@@ -145,7 +145,7 @@ void __init efika_pcisetup(void)
 }
 
 #else
-void __init efika_pcisetup(void)
+static void __init efika_pcisetup(void)
 {}
 #endif
 
Index: work-powerpc.git/arch/powerpc/platforms/52xx/lite5200.c
===================================================================
--- work-powerpc.git.orig/arch/powerpc/platforms/52xx/lite5200.c
+++ work-powerpc.git/arch/powerpc/platforms/52xx/lite5200.c
@@ -156,7 +156,7 @@ static void __init lite5200_setup_arch(v
 
 }
 
-void lite5200_show_cpuinfo(struct seq_file *m)
+static void lite5200_show_cpuinfo(struct seq_file *m)
 {
 	struct device_node* np = of_find_all_nodes(NULL);
 	const char *model = NULL;
Index: work-powerpc.git/arch/powerpc/platforms/52xx/mpc52xx_pm.c
===================================================================
--- work-powerpc.git.orig/arch/powerpc/platforms/52xx/mpc52xx_pm.c
+++ work-powerpc.git/arch/powerpc/platforms/52xx/mpc52xx_pm.c
@@ -9,8 +9,8 @@
 
 
 /* these are defined in mpc52xx_sleep.S, and only used here */
-extern void mpc52xx_deep_sleep(void *sram, void *sdram_regs,
-		struct mpc52xx_cdm *, struct mpc52xx_intr *);
+extern void mpc52xx_deep_sleep(void __iomem *sram, void __iomem *sdram_regs,
+		struct mpc52xx_cdm __iomem *, struct mpc52xx_intr __iomem*);
 extern void mpc52xx_ds_sram(void);
 extern const long mpc52xx_ds_sram_size;
 extern void mpc52xx_ds_cached(void);
@@ -21,7 +21,7 @@ static void __iomem *sdram;
 static struct mpc52xx_cdm __iomem *cdm;
 static struct mpc52xx_intr __iomem *intr;
 static struct mpc52xx_gpio_wkup __iomem *gpiow;
-static void *sram;
+static void __iomem *sram;
 static int sram_size;
 
 struct mpc52xx_suspend mpc52xx_suspend;
@@ -100,7 +100,7 @@ int mpc52xx_pm_enter(suspend_state_t sta
 	u32 clk_enables;
 	u32 msr, hid0;
 	u32 intr_main_mask;
-	void __iomem * irq_0x500 = (void *)CONFIG_KERNEL_START + 0x500;
+	void __iomem * irq_0x500 = (void __iomem *)CONFIG_KERNEL_START + 0x500;
 	unsigned long irq_0x500_stop = (unsigned long)irq_0x500 + mpc52xx_ds_cached_size;
 	char saved_0x500[mpc52xx_ds_cached_size];
 


From laurent.pinchart at technotrade.biz  Mon Jul  9 22:58:18 2007
From: laurent.pinchart at technotrade.biz (Laurent Pinchart)
Date: Mon, 9 Jul 2007 14:58:18 +0200
Subject: [PATCH] [PPC]: Add linux/pagemap.h to arch/ppc/mm/tlb.c
Message-ID: <200707091458.19445.laurent.pinchart@technotrade.biz>

When compiled without swap support, arch/mm/tlb.c complains about missing
function declarations. This patch fixes the warnings.

Signed-off-by: Laurent Pinchart <laurent.pinchart at technotrade.biz>
---
 arch/ppc/mm/tlb.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/ppc/mm/tlb.c b/arch/ppc/mm/tlb.c
index fa29740..4ff260b 100644
--- a/arch/ppc/mm/tlb.c
+++ b/arch/ppc/mm/tlb.c
@@ -27,6 +27,7 @@
 #include <linux/mm.h>
 #include <linux/init.h>
 #include <linux/highmem.h>
+#include <linux/pagemap.h>
 #include <asm/tlbflush.h>
 #include <asm/tlb.h>
 
-- 
1.5.0


From mark at mtfhpc.demon.co.uk  Tue Jul 10 00:33:05 2007
From: mark at mtfhpc.demon.co.uk (Mark Fortescue)
Date: Mon, 9 Jul 2007 15:33:05 +0100 (BST)
Subject: ARCH=ppc vs ARCH=powerpc
In-Reply-To: <200707090234.14851.arnd@arndb.de>
References: <Pine.LNX.4.61.0707061706140.4792@mtfhpc.demon.co.uk>
	<200707090234.14851.arnd@arndb.de>
Message-ID: <Pine.LNX.4.61.0707091528510.12823@mtfhpc.demon.co.uk>

Hi All,

I am currently trying to identify an anoying feature of linux on my 
sparc32 systems but I will do some work on the ppc -> powerpc migration 
as soon as I have exauhsted my current avenues of investiation on the 
sparc32 issue.

Regards
 	Mark Fortescue.

On Mon, 9 Jul 2007, Arnd Bergmann wrote:

> On Friday 06 July 2007, Mark Fortescue wrote:
>> For me, the requirement is to keep support for the cards indicated in
>> arch/ppc/config/xxx_defconfig (as I have one that I might what to use with
>> linux) in the same way as they are supported in ARCH=ppc.
>
> The one thing that is holding up the transition to arch/powerpc is lack
> of people with access to the respective boards. If you have one board
> that you care about, it would be good if you look into getting it moved
> over. Tell us if you have problems doing so. It shouldn't be all that
> hard any more, and if it is, maybe some documentation is missing.
>
>> I have just made some tweeks to get ARCH=ppc building for me but I still
>> need to sort out what is required to get around *** Error: Headers not
>> exportable for this architecture (ppc).
>
> You should simply install the headers with ARCH=powerc, even when the
> kernel is built with ARCH=ppc. From the user space point of view, there
> is only one set of headers.
>
> 	Arnd <><
>


From grant.likely at secretlab.ca  Tue Jul 10 01:53:07 2007
From: grant.likely at secretlab.ca (Grant Likely)
Date: Mon, 9 Jul 2007 09:53:07 -0600
Subject: [PATCH] i2c-mpc: work around missing-9th-clock-pulse bug
In-Reply-To: <20070709071955.GD4186@moe.telargo.com>
References: <20070709071955.GD4186@moe.telargo.com>
Message-ID: <fa686aa40707090853j6079b0c7rbcff7c449baa15e0@mail.gmail.com>

On 7/9/07, Domen Puncer <domen.puncer at telargo.com> wrote:
> Work around a problem reported on:
> http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019038.html
> Without this patch I2C on mpc5200 becomes unusable after a while.
> Tested on mpc5200 based boards by Matthias and me.
>
> Index: work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
> ===================================================================
> --- work-powerpc.git.orig/drivers/i2c/busses/i2c-mpc.c
> +++ work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
> @@ -153,6 +167,9 @@ static void mpc_i2c_start(struct mpc_i2c
>  static void mpc_i2c_stop(struct mpc_i2c *i2c)
>  {
>         writeccr(i2c, CCR_MEN);
> +       mb();
> +       writeccr(i2c, 0);
> +       mb();
>  }

Are the mb() calls necessary?  The writeccr path includes eieio; is
that not sufficient?

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195


From grant.likely at secretlab.ca  Tue Jul 10 01:58:04 2007
From: grant.likely at secretlab.ca (Grant Likely)
Date: Mon, 9 Jul 2007 09:58:04 -0600
Subject: [PATCH] mpc52xx: sparse fixes
In-Reply-To: <20070709075203.GF4186@moe.telargo.com>
References: <20070621074507.GL23294@moe.telargo.com>
	<20070709075203.GF4186@moe.telargo.com>
Message-ID: <fa686aa40707090858x6f6a5318i113e3e02e5f4af35@mail.gmail.com>

On 7/9/07, Domen Puncer <domen.puncer at telargo.com> wrote:
> sparse caught these static functions / __iomem annotations
> under arch/powerpc/platform/52xx/
>
>
> Signed-off-by: Domen Puncer <domen.puncer at telargo.com>
Signed-off-by: Grant Likely <grant.likely at secretlab.ca>

>
> ---
> Reposting, adding tnt to Cc, and requesting inclusion.
> The patch is pretty much harmless :-)
>
>
>  arch/powerpc/platforms/52xx/efika.c      |    4 ++--
>  arch/powerpc/platforms/52xx/lite5200.c   |    2 +-
>  arch/powerpc/platforms/52xx/mpc52xx_pm.c |    8 ++++----
>  3 files changed, 7 insertions(+), 7 deletions(-)
>
> Index: work-powerpc.git/arch/powerpc/platforms/52xx/efika.c
> ===================================================================
> --- work-powerpc.git.orig/arch/powerpc/platforms/52xx/efika.c
> +++ work-powerpc.git/arch/powerpc/platforms/52xx/efika.c
> @@ -83,7 +83,7 @@ static struct pci_ops rtas_pci_ops = {
>  };
>
>
> -void __init efika_pcisetup(void)
> +static void __init efika_pcisetup(void)
>  {
>         const int *bus_range;
>         int len;
> @@ -145,7 +145,7 @@ void __init efika_pcisetup(void)
>  }
>
>  #else
> -void __init efika_pcisetup(void)
> +static void __init efika_pcisetup(void)
>  {}
>  #endif
>
> Index: work-powerpc.git/arch/powerpc/platforms/52xx/lite5200.c
> ===================================================================
> --- work-powerpc.git.orig/arch/powerpc/platforms/52xx/lite5200.c
> +++ work-powerpc.git/arch/powerpc/platforms/52xx/lite5200.c
> @@ -156,7 +156,7 @@ static void __init lite5200_setup_arch(v
>
>  }
>
> -void lite5200_show_cpuinfo(struct seq_file *m)
> +static void lite5200_show_cpuinfo(struct seq_file *m)
>  {
>         struct device_node* np = of_find_all_nodes(NULL);
>         const char *model = NULL;
> Index: work-powerpc.git/arch/powerpc/platforms/52xx/mpc52xx_pm.c
> ===================================================================
> --- work-powerpc.git.orig/arch/powerpc/platforms/52xx/mpc52xx_pm.c
> +++ work-powerpc.git/arch/powerpc/platforms/52xx/mpc52xx_pm.c
> @@ -9,8 +9,8 @@
>
>
>  /* these are defined in mpc52xx_sleep.S, and only used here */
> -extern void mpc52xx_deep_sleep(void *sram, void *sdram_regs,
> -               struct mpc52xx_cdm *, struct mpc52xx_intr *);
> +extern void mpc52xx_deep_sleep(void __iomem *sram, void __iomem *sdram_regs,
> +               struct mpc52xx_cdm __iomem *, struct mpc52xx_intr __iomem*);
>  extern void mpc52xx_ds_sram(void);
>  extern const long mpc52xx_ds_sram_size;
>  extern void mpc52xx_ds_cached(void);
> @@ -21,7 +21,7 @@ static void __iomem *sdram;
>  static struct mpc52xx_cdm __iomem *cdm;
>  static struct mpc52xx_intr __iomem *intr;
>  static struct mpc52xx_gpio_wkup __iomem *gpiow;
> -static void *sram;
> +static void __iomem *sram;
>  static int sram_size;
>
>  struct mpc52xx_suspend mpc52xx_suspend;
> @@ -100,7 +100,7 @@ int mpc52xx_pm_enter(suspend_state_t sta
>         u32 clk_enables;
>         u32 msr, hid0;
>         u32 intr_main_mask;
> -       void __iomem * irq_0x500 = (void *)CONFIG_KERNEL_START + 0x500;
> +       void __iomem * irq_0x500 = (void __iomem *)CONFIG_KERNEL_START + 0x500;
>         unsigned long irq_0x500_stop = (unsigned long)irq_0x500 + mpc52xx_ds_cached_size;
>         char saved_0x500[mpc52xx_ds_cached_size];
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195


From grant.likely at secretlab.ca  Tue Jul 10 03:03:29 2007
From: grant.likely at secretlab.ca (Grant Likely)
Date: Mon, 9 Jul 2007 11:03:29 -0600
Subject: [PATCH] Add USB support to mpc8349-mitx board port
In-Reply-To: <4b73d43f0707082055y2b96fa53td55d6b381b6fb0ef@mail.gmail.com>
References: <20070706222909.19943.39455.stgit@trillian.secretlab.ca>
	<200707070148.20526.arnd@arndb.de>
	<fa686aa40707062246j71a347acje8559b7b6be9d38b@mail.gmail.com>
	<4b73d43f0707071734yeedd7e6g53101d45fbec899e@mail.gmail.com>
	<fa686aa40707071748g7f00f4c7jb761cceb7d72456d@mail.gmail.com>
	<4b73d43f0707082055y2b96fa53td55d6b381b6fb0ef@mail.gmail.com>
Message-ID: <fa686aa40707091003n45870ccdn8c9a3629cf19cf77@mail.gmail.com>

On 7/8/07, John Rigby <jcrigby at gmail.com> wrote:
> I see your point, I agree the two layers of glue is bad.  But this means
> the double code is spread across many drivers instead of being in one
> place (fsl_soc.c).

???  I don't understand what you mean.  Are you saying that it's
better to have all the OF bindings in one place (fsl_soc.c) instead of
with each individual driver?

Cheers,
g.


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195


From jcrigby at gmail.com  Tue Jul 10 09:35:58 2007
From: jcrigby at gmail.com (John Rigby)
Date: Mon, 9 Jul 2007 17:35:58 -0600
Subject: [PATCH] Add USB support to mpc8349-mitx board port
In-Reply-To: <fa686aa40707091003n45870ccdn8c9a3629cf19cf77@mail.gmail.com>
References: <20070706222909.19943.39455.stgit@trillian.secretlab.ca>
	<200707070148.20526.arnd@arndb.de>
	<fa686aa40707062246j71a347acje8559b7b6be9d38b@mail.gmail.com>
	<4b73d43f0707071734yeedd7e6g53101d45fbec899e@mail.gmail.com>
	<fa686aa40707071748g7f00f4c7jb761cceb7d72456d@mail.gmail.com>
	<4b73d43f0707082055y2b96fa53td55d6b381b6fb0ef@mail.gmail.com>
	<fa686aa40707091003n45870ccdn8c9a3629cf19cf77@mail.gmail.com>
Message-ID: <4b73d43f0707091635o3ff98713raae9bd914007d9f3@mail.gmail.com>

I'm just saying that an argument can be made that having all the OF to
non-OF
glue in one place is better than having dual bindings in every driver.

If you count ugliness in terms of file count the fsl_soc.c solution
gets a score of 1 and the dual binding solution gets an score of N.
Where N is the number of drivers.

John

On 7/9/07, Grant Likely <grant.likely at secretlab.ca> wrote:
>
> On 7/8/07, John Rigby <jcrigby at gmail.com> wrote:
> > I see your point, I agree the two layers of glue is bad.  But this means
> > the double code is spread across many drivers instead of being in one
> > place (fsl_soc.c).
>
> ???  I don't understand what you mean.  Are you saying that it's
> better to have all the OF bindings in one place (fsl_soc.c) instead of
> with each individual driver?
>
> Cheers,
> g.
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely at secretlab.ca
> (403) 399-0195
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070709/99c6cef6/attachment.htm 

From blackfin.kang at gmail.com  Tue Jul 10 12:11:28 2007
From: blackfin.kang at gmail.com (kang shuo)
Date: Tue, 10 Jul 2007 10:11:28 +0800
Subject: A question about _PAGE_PRESENT flag when ioremap is executed....
Message-ID: <a7f827420707091911x5c3b538fp5f0dd8a316d862ad@mail.gmail.com>

hi:
           I had read some confusing code about io address map in
MPC8560 that employs E500 core. My confusion is when io address map is
setup, if _PAGE_PRESENT flag of page is set? In implementation of
mpc8560 , that seems page flag that maps to io address region is
0x280, means only the following flag is set:
#define _PAGE_GUARDED   0x00080 /* H: G bit */
#define _PAGE_NO_CACHE  0x00200 /* H: I bit */

But  I think _PAGE_PRESENT shoulbe be set for BOOKE too...
/* Definitions for FSL Book-E Cores */
#define _PAGE_PRESENT   0x00001 /* S: PTE contains a translation */
           Any guys give me some idea about that? Thanks....


-- Michael.Kang


From domen.puncer at telargo.com  Tue Jul 10 16:17:36 2007
From: domen.puncer at telargo.com (Domen Puncer)
Date: Tue, 10 Jul 2007 08:17:36 +0200
Subject: [PATCH] i2c-mpc: work around missing-9th-clock-pulse bug
In-Reply-To: <fa686aa40707090853j6079b0c7rbcff7c449baa15e0@mail.gmail.com>
References: <20070709071955.GD4186@moe.telargo.com>
	<fa686aa40707090853j6079b0c7rbcff7c449baa15e0@mail.gmail.com>
Message-ID: <20070710061736.GG4186@moe.telargo.com>

On 09/07/07 09:53 -0600, Grant Likely wrote:
> On 7/9/07, Domen Puncer <domen.puncer at telargo.com> wrote:
> >Work around a problem reported on:
> >http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019038.html
> >Without this patch I2C on mpc5200 becomes unusable after a while.
> >Tested on mpc5200 based boards by Matthias and me.
> >
> >Index: work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
> >===================================================================
> >--- work-powerpc.git.orig/drivers/i2c/busses/i2c-mpc.c
> >+++ work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
> >@@ -153,6 +167,9 @@ static void mpc_i2c_start(struct mpc_i2c
> > static void mpc_i2c_stop(struct mpc_i2c *i2c)
> > {
> >        writeccr(i2c, CCR_MEN);
> >+       mb();
> >+       writeccr(i2c, 0);
> >+       mb();
> > }
> 
> Are the mb() calls necessary?  The writeccr path includes eieio; is
> that not sufficient?

Right, v2:


Work around a problem reported on:
http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019038.html
Without this patch I2C on mpc5200 becomes unusable after a while.
Tested on mpc5200 boards by Matthias and me.


Signed-off-by: Domen Puncer <domen.puncer at telargo.com>

---
 drivers/i2c/busses/i2c-mpc.c |   17 +++++++++++++++++
 1 file changed, 17 insertions(+)

Index: work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
===================================================================
--- work-powerpc.git.orig/drivers/i2c/busses/i2c-mpc.c
+++ work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
@@ -74,6 +74,20 @@ static irqreturn_t mpc_i2c_isr(int irq, 
 	return IRQ_HANDLED;
 }
 
+static void mpc_i2c_fixup(struct mpc_i2c *i2c)
+{
+	writeccr(i2c, 0);
+	udelay(30);
+	writeccr(i2c, CCR_MEN);
+	udelay(30);
+	writeccr(i2c, CCR_MSTA | CCR_MTX);
+	udelay(30);
+	writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);
+	udelay(30);
+	writeccr(i2c, CCR_MEN);
+	udelay(30);
+}
+
 static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
 {
 	unsigned long orig_jiffies = jiffies;
@@ -153,6 +167,7 @@ static void mpc_i2c_start(struct mpc_i2c
 static void mpc_i2c_stop(struct mpc_i2c *i2c)
 {
 	writeccr(i2c, CCR_MEN);
+	writeccr(i2c, 0);
 }
 
 static int mpc_write(struct mpc_i2c *i2c, int target,
@@ -245,6 +260,8 @@ static int mpc_xfer(struct i2c_adapter *
 		}
 		if (time_after(jiffies, orig_jiffies + HZ)) {
 			pr_debug("I2C: timeout\n");
+			if (readb(i2c->base + MPC_I2C_SR) == (CSR_MCF | CSR_MBB | CSR_RXAK))
+				mpc_i2c_fixup(i2c);
 			return -EIO;
 		}
 		schedule();


From grant.likely at secretlab.ca  Tue Jul 10 16:22:05 2007
From: grant.likely at secretlab.ca (Grant Likely)
Date: Tue, 10 Jul 2007 00:22:05 -0600
Subject: [PATCH] i2c-mpc: work around missing-9th-clock-pulse bug
In-Reply-To: <20070710061736.GG4186@moe.telargo.com>
References: <20070709071955.GD4186@moe.telargo.com>
	<fa686aa40707090853j6079b0c7rbcff7c449baa15e0@mail.gmail.com>
	<20070710061736.GG4186@moe.telargo.com>
Message-ID: <fa686aa40707092322v58bbdad0veb0ee2ec00f125b0@mail.gmail.com>

On 7/10/07, Domen Puncer <domen.puncer at telargo.com> wrote:
> On 09/07/07 09:53 -0600, Grant Likely wrote:
> > On 7/9/07, Domen Puncer <domen.puncer at telargo.com> wrote:
> > >Work around a problem reported on:
> > >http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019038.html
> > >Without this patch I2C on mpc5200 becomes unusable after a while.
> > >Tested on mpc5200 based boards by Matthias and me.
> > >
> > >Index: work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
> > >===================================================================
> > >--- work-powerpc.git.orig/drivers/i2c/busses/i2c-mpc.c
> > >+++ work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
> > >@@ -153,6 +167,9 @@ static void mpc_i2c_start(struct mpc_i2c
> > > static void mpc_i2c_stop(struct mpc_i2c *i2c)
> > > {
> > >        writeccr(i2c, CCR_MEN);
> > >+       mb();
> > >+       writeccr(i2c, 0);
> > >+       mb();
> > > }
> >
> > Are the mb() calls necessary?  The writeccr path includes eieio; is
> > that not sufficient?
>
> Right, v2:
>
>
> Work around a problem reported on:
> http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019038.html
> Without this patch I2C on mpc5200 becomes unusable after a while.
> Tested on mpc5200 boards by Matthias and me.
>
>
> Signed-off-by: Domen Puncer <domen.puncer at telargo.com>

Looks good to me,

Acked-by: Grant Likely <grant.likely at secretlab.ca>

>
> ---
>  drivers/i2c/busses/i2c-mpc.c |   17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
>
> Index: work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
> ===================================================================
> --- work-powerpc.git.orig/drivers/i2c/busses/i2c-mpc.c
> +++ work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
> @@ -74,6 +74,20 @@ static irqreturn_t mpc_i2c_isr(int irq,
>         return IRQ_HANDLED;
>  }
>
> +static void mpc_i2c_fixup(struct mpc_i2c *i2c)
> +{
> +       writeccr(i2c, 0);
> +       udelay(30);
> +       writeccr(i2c, CCR_MEN);
> +       udelay(30);
> +       writeccr(i2c, CCR_MSTA | CCR_MTX);
> +       udelay(30);
> +       writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);
> +       udelay(30);
> +       writeccr(i2c, CCR_MEN);
> +       udelay(30);
> +}
> +
>  static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
>  {
>         unsigned long orig_jiffies = jiffies;
> @@ -153,6 +167,7 @@ static void mpc_i2c_start(struct mpc_i2c
>  static void mpc_i2c_stop(struct mpc_i2c *i2c)
>  {
>         writeccr(i2c, CCR_MEN);
> +       writeccr(i2c, 0);
>  }
>
>  static int mpc_write(struct mpc_i2c *i2c, int target,
> @@ -245,6 +260,8 @@ static int mpc_xfer(struct i2c_adapter *
>                 }
>                 if (time_after(jiffies, orig_jiffies + HZ)) {
>                         pr_debug("I2C: timeout\n");
> +                       if (readb(i2c->base + MPC_I2C_SR) == (CSR_MCF | CSR_MBB | CSR_RXAK))
> +                               mpc_i2c_fixup(i2c);
>                         return -EIO;
>                 }
>                 schedule();
>


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195


From psyphi at gmail.com  Tue Jul 10 16:36:52 2007
From: psyphi at gmail.com (ThomasB)
Date: Tue, 10 Jul 2007 08:36:52 +0200
Subject: [kernel-2.6.19]Marvell GT-64260 and Ethernet
Message-ID: <13b81f0c0707092336r5c7f4996u6f9c73d95c63bdc6@mail.gmail.com>

Hi all,
I'm porting a Linux kernel 2.6.19 on a PowerPC 750 FX board.
My Linux runs completely except for Ethernet. I don't find any Ethernet
driver for my bridge. Do you know if there is an Ethernet driver for the
Marvell GT-64260 bridge for PowerPC processor. I found a GT-64260 ethernet
driver in the kernel 2.4.34 for MIPS processor, will it be possible to port
it in a 2.6 kernel?
Thanks for you help.


-- 
ThomasB
http://psyphi.zeblog.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070710/3c86d09d/attachment.htm 

From laurent.pinchart at technotrade.biz  Tue Jul 10 21:12:45 2007
From: laurent.pinchart at technotrade.biz (Laurent Pinchart)
Date: Tue, 10 Jul 2007 13:12:45 +0200
Subject: [PATCH] [POWERPC] Move generic MPC82xx functions out of ADS-specific
Message-ID: <200707101312.46052.laurent.pinchart@technotrade.biz>

The non board-specific mpc82xx_halt and mpc82xx_restart functions are defined
in arch/powerpc/platforms/82xx/mpc82xx_ads.c. This patch moves them to
mpc82xx.c to make them usable by other MPC82xx boards.

Signed-off-by: Laurent Pinchart <laurent.pinchart at technotrade.biz>
---
 arch/powerpc/platforms/82xx/mpc82xx.c     |   33 
+++++++++++++++--------------
 arch/powerpc/platforms/82xx/mpc82xx.h     |   24 +++++++++++++++++++++
 arch/powerpc/platforms/82xx/mpc82xx_ads.c |   31 ++++++++++++++-------------
 arch/powerpc/platforms/82xx/pq2ads.h      |    1 -
 4 files changed, 57 insertions(+), 32 deletions(-)
 create mode 100644 arch/powerpc/platforms/82xx/mpc82xx.h

diff --git a/arch/powerpc/platforms/82xx/mpc82xx.c 
b/arch/powerpc/platforms/82xx/mpc82xx.c
index cc9900d..d67c754 100644
--- a/arch/powerpc/platforms/82xx/mpc82xx.c
+++ b/arch/powerpc/platforms/82xx/mpc82xx.c
@@ -50,7 +50,7 @@
 #include <sysdev/fsl_soc.h>
 #include <sysdev/cpm2_pic.h>
 
-#include "pq2ads.h"
+#include "mpc82xx.h"
 
 static int __init get_freq(char *name, unsigned long *val)
 {
@@ -88,23 +88,24 @@ void __init m82xx_calibrate_decr(void)
 				"(not found)\n");
 }
 
-void mpc82xx_ads_show_cpuinfo(struct seq_file *m)
+#define RMR_CSRE 0x00000001
+void m82xx_restart(char *cmd)
 {
-	uint pvid, svid, phid1;
-	uint memsize = total_memory;
+	__volatile__ unsigned char dummy;
 
-	pvid = mfspr(SPRN_PVR);
-	svid = mfspr(SPRN_SVR);
+	local_irq_disable();
+	((cpm2_map_t *) cpm2_immr)->im_clkrst.car_rmr |= RMR_CSRE;
 
-	seq_printf(m, "Vendor\t\t: Freescale Semiconductor\n");
-	seq_printf(m, "Machine\t\t: %s\n", CPUINFO_MACHINE);
-	seq_printf(m, "PVR\t\t: 0x%x\n", pvid);
-	seq_printf(m, "SVR\t\t: 0x%x\n", svid);
-
-	/* Display cpu Pll setting */
-	phid1 = mfspr(SPRN_HID1);
-	seq_printf(m, "PLL setting\t: 0x%x\n", ((phid1 >> 24) & 0x3f));
+	/* Clear the ME,EE,IR & DR bits in MSR to cause checkstop */
+	mtmsr(mfmsr() & ~(MSR_ME | MSR_EE | MSR_IR | MSR_DR));
+	dummy = ((cpm2_map_t *) cpm2_immr)->im_clkrst.res[0];
+	printk("Restart failed\n");
+	while (1) ;
+}
 
-	/* Display the amount of memory */
-	seq_printf(m, "Memory\t\t: %d MB\n", memsize / (1024 * 1024));
+void m82xx_halt(void)
+{
+	local_irq_disable();
+	while (1) ;
 }
+
diff --git a/arch/powerpc/platforms/82xx/mpc82xx.h 
b/arch/powerpc/platforms/82xx/mpc82xx.h
new file mode 100644
index 0000000..427925b
--- /dev/null
+++ b/arch/powerpc/platforms/82xx/mpc82xx.h
@@ -0,0 +1,24 @@
+/*
+ * MPC82xx setup and early boot code plus other random bits.
+ *
+ * Author: Vitaly Bordug <vbordug at ru.mvista.com>
+ *
+ * Copyright (c) 2006 MontaVista Software, Inc.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#ifndef __MACH_MPC82XX_H__
+#define __MACH_MPC82XX_H__
+
+#include <linux/init.h>
+
+extern void __init m82xx_calibrate_decr(void);
+extern void m82xx_restart(char *cmd);
+extern void m82xx_halt(void);
+
+#endif
+
diff --git a/arch/powerpc/platforms/82xx/mpc82xx_ads.c 
b/arch/powerpc/platforms/82xx/mpc82xx_ads.c
index 47cb09f..1af9449 100644
--- a/arch/powerpc/platforms/82xx/mpc82xx_ads.c
+++ b/arch/powerpc/platforms/82xx/mpc82xx_ads.c
@@ -51,6 +51,7 @@
 #include <sysdev/fsl_soc.h>
 #include <../sysdev/cpm2_pic.h>
 
+#include "mpc82xx.h"
 #include "pq2ads.h"
 
 #ifdef CONFIG_PCI
@@ -611,25 +612,25 @@ static int __init mpc82xx_ads_probe(void)
 	return 1;
 }
 
-#define RMR_CSRE 0x00000001
-static void m82xx_restart(char *cmd)
+void mpc82xx_ads_show_cpuinfo(struct seq_file *m)
 {
-	__volatile__ unsigned char dummy;
+	uint pvid, svid, phid1;
+	uint memsize = total_memory;
 
-	local_irq_disable();
-	((cpm2_map_t *) cpm2_immr)->im_clkrst.car_rmr |= RMR_CSRE;
+	pvid = mfspr(SPRN_PVR);
+	svid = mfspr(SPRN_SVR);
 
-	/* Clear the ME,EE,IR & DR bits in MSR to cause checkstop */
-	mtmsr(mfmsr() & ~(MSR_ME | MSR_EE | MSR_IR | MSR_DR));
-	dummy = ((cpm2_map_t *) cpm2_immr)->im_clkrst.res[0];
-	printk("Restart failed\n");
-	while (1) ;
-}
+	seq_printf(m, "Vendor\t\t: Freescale Semiconductor\n");
+	seq_printf(m, "Machine\t\t: %s\n", CPUINFO_MACHINE);
+	seq_printf(m, "PVR\t\t: 0x%x\n", pvid);
+	seq_printf(m, "SVR\t\t: 0x%x\n", svid);
 
-static void m82xx_halt(void)
-{
-	local_irq_disable();
-	while (1) ;
+	/* Display cpu Pll setting */
+	phid1 = mfspr(SPRN_HID1);
+	seq_printf(m, "PLL setting\t: 0x%x\n", ((phid1 >> 24) & 0x3f));
+
+	/* Display the amount of memory */
+	seq_printf(m, "Memory\t\t: %d MB\n", memsize / (1024 * 1024));
 }
 
 define_machine(mpc82xx_ads)
diff --git a/arch/powerpc/platforms/82xx/pq2ads.h 
b/arch/powerpc/platforms/82xx/pq2ads.h
index 5b5cca6..5056fe5 100644
--- a/arch/powerpc/platforms/82xx/pq2ads.h
+++ b/arch/powerpc/platforms/82xx/pq2ads.h
@@ -60,7 +60,6 @@
 
 void m82xx_pci_init_irq(void);
 void mpc82xx_ads_show_cpuinfo(struct seq_file*);
-void m82xx_calibrate_decr(void);
 
 #endif /* __MACH_ADS8260_DEFS */
 #endif /* __KERNEL__ */
-- 
1.5.0


From matt at genesi-usa.com  Tue Jul 10 23:14:07 2007
From: matt at genesi-usa.com (Matt Sealey)
Date: Tue, 10 Jul 2007 14:14:07 +0100
Subject: [kernel-2.6.19]Marvell GT-64260 and Ethernet
In-Reply-To: <13b81f0c0707092336r5c7f4996u6f9c73d95c63bdc6@mail.gmail.com>
References: <13b81f0c0707092336r5c7f4996u6f9c73d95c63bdc6@mail.gmail.com>
Message-ID: <4693861F.2000403@genesi-usa.com>

Isn't the ethernet the same on the 64260, 64360, 64460?

There's definitely a driver for 6436x and above..

-- 
Matt Sealey <matt at genesi-usa.com>
Genesi, Manager, Developer Relations

ThomasB wrote:
> Hi all,
> I'm porting a Linux kernel 2.6.19 on a PowerPC 750 FX board.
> My Linux runs completely except for Ethernet. I don't find any Ethernet
> driver for my bridge. Do you know if there is an Ethernet driver for the
> Marvell GT-64260 bridge for PowerPC processor. I found a GT-64260
> ethernet driver in the kernel 2.4.34 for MIPS processor, will it be
> possible to port it in a 2.6 kernel?
> Thanks for you help.
> 
> 
> -- 
> ThomasB
> http://psyphi.zeblog.com/ <http://psyphi.zeblog.com/>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded


From dale at farnsworth.org  Tue Jul 10 23:22:07 2007
From: dale at farnsworth.org (Dale Farnsworth)
Date: 10 Jul 2007 06:22:07 -0700
Subject: [kernel-2.6.19]Marvell GT-64260 and Ethernet
In-Reply-To: <13b81f0c0707092336r5c7f4996u6f9c73d95c63bdc6@mail.gmail.com>
Message-ID: <20070710132207.12018.qmail@farnsworth.org>

> I'm porting a Linux kernel 2.6.19 on a PowerPC 750 FX board.
> My Linux runs completely except for Ethernet. I don't find any Ethernet
> driver for my bridge. Do you know if there is an Ethernet driver for the
> Marvell GT-64260 bridge for PowerPC processor. I found a GT-64260 ethernet
> driver in the kernel 2.4.34 for MIPS processor, will it be possible to port
> it in a 2.6 kernel?

I believe that Steve Hill <sjhill at realitydiluted.com> has patched
the mv643xx_eth driver to work with the 64260 and plans to submit
the patches.

-Dale


From psyphi at gmail.com  Tue Jul 10 23:41:25 2007
From: psyphi at gmail.com (ThomasB)
Date: Tue, 10 Jul 2007 15:41:25 +0200
Subject: [kernel-2.6.19]Marvell GT-64260 and Ethernet
In-Reply-To: <20070710132207.12018.qmail@farnsworth.org>
References: <13b81f0c0707092336r5c7f4996u6f9c73d95c63bdc6@mail.gmail.com>
	<20070710132207.12018.qmail@farnsworth.org>
Message-ID: <13b81f0c0707100641i56e08bd3n7c7911782a81628a@mail.gmail.com>

>Isn't the ethernet the same on the 64260, 64360, 64460?
>
> There's definitely a driver for 6436x and above..

I just try it, it doesn't work, I receive without end the message:
mv643xx PHY read timeout, port 0

> I believe that Steve Hill <sjhill at realitydiluted.com> has patched
> the mv643xx_eth driver to work with the 64260 and plans to submit
> the patches.
That's means the patch isn't yet ready?
I will try to contact him.

It's nevertheless odd, I read about a file named gt64260_eth.c during my
search on the internet.But I wasn't able to find it :(.

Thanks for you help

-- 
ThomasB
http://psyphi.zeblog.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070710/bb12205d/attachment.htm 

From dale at farnsworth.org  Tue Jul 10 23:50:05 2007
From: dale at farnsworth.org (Dale Farnsworth)
Date: Tue, 10 Jul 2007 06:50:05 -0700
Subject: [kernel-2.6.19]Marvell GT-64260 and Ethernet
In-Reply-To: <13b81f0c0707100641i56e08bd3n7c7911782a81628a@mail.gmail.com>
References: <13b81f0c0707092336r5c7f4996u6f9c73d95c63bdc6@mail.gmail.com>
	<20070710132207.12018.qmail@farnsworth.org>
	<13b81f0c0707100641i56e08bd3n7c7911782a81628a@mail.gmail.com>
Message-ID: <20070710135004.GA13589@xyzzy.farnsworth.org>

On Tue, Jul 10, 2007 at 03:41:25PM +0200, ThomasB wrote:
> It's nevertheless odd, I read about a file named gt64260_eth.c during my
> search on the internet.But I wasn't able to find it :(.

It was in the (now obsolete) linuxppc_2_4_devel kernel.  I can send
you a copy, but a merged mv64x60 driver will be much better.

-Dale


From khali at linux-fr.org  Tue Jul 10 22:40:30 2007
From: khali at linux-fr.org (Jean Delvare)
Date: Tue, 10 Jul 2007 14:40:30 +0200
Subject: [PATCH] i2c-mpc: work around missing-9th-clock-pulse bug
In-Reply-To: <fa686aa40707092322v58bbdad0veb0ee2ec00f125b0@mail.gmail.com>
References: <20070709071955.GD4186@moe.telargo.com>
	<fa686aa40707090853j6079b0c7rbcff7c449baa15e0@mail.gmail.com>
	<20070710061736.GG4186@moe.telargo.com>
	<fa686aa40707092322v58bbdad0veb0ee2ec00f125b0@mail.gmail.com>
Message-ID: <20070710144030.3786cbf3@hyperion.delvare>

Hi Grant, hi Domen,

On Tue, 10 Jul 2007 00:22:05 -0600, Grant Likely wrote:
> On 7/10/07, Domen Puncer <domen.puncer at telargo.com> wrote:
> > Work around a problem reported on:
> > http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019038.html
> > Without this patch I2C on mpc5200 becomes unusable after a while.
> > Tested on mpc5200 boards by Matthias and me.
> >
> >
> > Signed-off-by: Domen Puncer <domen.puncer at telargo.com>
> 
> Looks good to me,
> 
> Acked-by: Grant Likely <grant.likely at secretlab.ca>

OK, I will take this patch, but I'd like you to add a comment before
mpc_i2c_fixup() explaining what exactly the problem is and how it is
worked around. Otherwise it's a bit obscure what is going on.

I guess you want this patch in 2.6.23-rc1?

> > ---
> >  drivers/i2c/busses/i2c-mpc.c |   17 +++++++++++++++++
> >  1 file changed, 17 insertions(+)
> >
> > Index: work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
> > ===================================================================
> > --- work-powerpc.git.orig/drivers/i2c/busses/i2c-mpc.c
> > +++ work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
> > @@ -74,6 +74,20 @@ static irqreturn_t mpc_i2c_isr(int irq,
> >         return IRQ_HANDLED;
> >  }
> >
> > +static void mpc_i2c_fixup(struct mpc_i2c *i2c)
> > +{
> > +       writeccr(i2c, 0);
> > +       udelay(30);
> > +       writeccr(i2c, CCR_MEN);
> > +       udelay(30);
> > +       writeccr(i2c, CCR_MSTA | CCR_MTX);
> > +       udelay(30);
> > +       writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);
> > +       udelay(30);
> > +       writeccr(i2c, CCR_MEN);
> > +       udelay(30);
> > +}
> > +
> >  static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
> >  {
> >         unsigned long orig_jiffies = jiffies;
> > @@ -153,6 +167,7 @@ static void mpc_i2c_start(struct mpc_i2c
> >  static void mpc_i2c_stop(struct mpc_i2c *i2c)
> >  {
> >         writeccr(i2c, CCR_MEN);
> > +       writeccr(i2c, 0);
> >  }
> >
> >  static int mpc_write(struct mpc_i2c *i2c, int target,
> > @@ -245,6 +260,8 @@ static int mpc_xfer(struct i2c_adapter *
> >                 }
> >                 if (time_after(jiffies, orig_jiffies + HZ)) {
> >                         pr_debug("I2C: timeout\n");
> > +                       if (readb(i2c->base + MPC_I2C_SR) == (CSR_MCF | CSR_MBB | CSR_RXAK))
> > +                               mpc_i2c_fixup(i2c);
> >                         return -EIO;
> >                 }
> >                 schedule();
> >

-- 
Jean Delvare


From laurent.pinchart at technotrade.biz  Wed Jul 11 00:19:51 2007
From: laurent.pinchart at technotrade.biz (Laurent Pinchart)
Date: Tue, 10 Jul 2007 16:19:51 +0200
Subject: MPC82xx ADS SCC ports initialisation
Message-ID: <200707101619.52438.laurent.pinchart@technotrade.biz>

Hi everybody,

while checking the availability of MPC8260 support in ARCH=powerpc, I ran 
across a possible issue in SCC ports initialisation for the MPC82xx ADS 
boards.

init_scc1_uart_ioports and init_scc4_uart_ioports in 
arch/powerpc/platforms/mpc82xx/mpx82xx_ads.c use the following code to 
configure the SCC clocks:

clrbits32(&immap->im_cpmux.cmx_scr, (0x00000007 << (4 - data->clk_tx)));
clrbits32(&immap->im_cpmux.cmx_scr, (0x00000038 << (4 - data->clk_rx)));
setbits32(&immap->im_cpmux.cmx_scr, 
          ((data->clk_tx - 1) << (4 - data->clk_tx)));
setbits32(&immap->im_cpmux.cmx_scr,
          ((data->clk_rx - 1) << (4 - data->clk_rx)));

The shift right-hand operand doesn't seem to be correct. Could anyone confirm 
this ? If my assumption is right, could anyone tell me if the MPC82xx 
processors are actually supported by the powerpc architecture, or if the 
MPC82xx ADS code is just a non-functional work in progress.

I also noticed that U-Boot doesn't have flatten device tree support for the 
MPC82xx family. There seem to be still a lot of work to do to support the 
MPC82xx in the powerpc tree, and the effort is much bigger than just porting 
a board from ppc to powerpc.

Laurent Pinchart


From mgreer at mvista.com  Tue Jul 10 23:51:02 2007
From: mgreer at mvista.com (Mark A. Greer)
Date: Tue, 10 Jul 2007 06:51:02 -0700
Subject: [kernel-2.6.19]Marvell GT-64260 and Ethernet
In-Reply-To: <13b81f0c0707100641i56e08bd3n7c7911782a81628a@mail.gmail.com>
References: <13b81f0c0707092336r5c7f4996u6f9c73d95c63bdc6@mail.gmail.com>
	<20070710132207.12018.qmail@farnsworth.org>
	<13b81f0c0707100641i56e08bd3n7c7911782a81628a@mail.gmail.com>
Message-ID: <20070710135102.GA22993@mag.az.mvista.com>

On Tue, Jul 10, 2007 at 03:41:25PM +0200, ThomasB wrote:
> >Isn't the ethernet the same on the 64260, 64360, 64460?
> >
> >There's definitely a driver for 6436x and above..
> 
> I just try it, it doesn't work, I receive without end the message:
> mv643xx PHY read timeout, port 0
> 
> >I believe that Steve Hill <sjhill at realitydiluted.com> has patched
> >the mv643xx_eth driver to work with the 64260 and plans to submit
> >the patches.
> That's means the patch isn't yet ready?

It probably means you don't something set up for whatever PHY you're
using.

> I will try to contact him.

A good idea.

> It's nevertheless odd, I read about a file named gt64260_eth.c during my
> search on the internet.But I wasn't able to find it :(.

There was one for 2.4 that was in the ppc devel tree but it never went
mainline.  Hopefully, Steve can help you from here.

Mark


From miroslaw.dach at psi.ch  Wed Jul 11 01:52:20 2007
From: miroslaw.dach at psi.ch (Mirek23)
Date: Tue, 10 Jul 2007 08:52:20 -0700 (PDT)
Subject: xilinx gpio in kernel 2.6
In-Reply-To: <10285090.post@talk.nabble.com>
References: <10254948.post@talk.nabble.com> <10285090.post@talk.nabble.com>
Message-ID: <11523745.post@talk.nabble.com>


Hi All,

 After some time I have found the way how to deal with GPIO driver from the
user space:

First you have to mknod xgpio under /dev :
crw-rw-rw-    1 root     root      10, 185 Jun  1 13:59 /dev/xgpio

Example program below shows how to read from the GPIO channel.
To write to the channel change the call:
ioctl(fgpio,XGPIO_IN,&sGpioData); to ioctl(fgpio,XGPIO_OUT,&sGpioData);

#include <stdlib.h>
#include <stdio.h>
#include <sys/ioctl.h>
#include <fcntl.h>

#include <linux/xgpio_ioctl.h>


main(){


  int fgpio =0;
  struct xgpio_ioctl_data sGpioData;
    /* {
        __u32 device;
        __u32 mask;
        __u32 data;
        }*/

  sGpioData.device=0; /* N=0,1,2,3-> GPIO DEV NR   2*N   (Lower 32 bit part
)
                                                   2*N+1 (Upper 32 bit part
)*/
  sGpioData.mask=0xffffffff;
  sGpioData.data=0x55555555;

fgpio = open ("/dev/xgpio",O_RDWR);
 if( fgpio != -1){

   ioctl(fgpio,XGPIO_IN,&sGpioData);//pointer here to  xgpio_ioctl_data
   printf("Dip Swich readout 0x%X\n",sGpioData.data);
 }
 else
   printf("Can not open GPIO\n");

 close(fgpio);
}// end main












 



-- 
View this message in context: http://www.nabble.com/xilinx-gpio-in-kernel-2.6-tf3670122.html#a11523745
Sent from the linuxppc-embedded mailing list archive at Nabble.com.



From gmuruga at gdatech.com  Wed Jul 11 02:52:01 2007
From: gmuruga at gdatech.com (Muruga Ganapathy)
Date: Tue, 10 Jul 2007 09:52:01 -0700
Subject: [kernel-2.6.19]Marvell GT-64260 and Ethernet
Message-ID: <200707101652.l6AGq1613447@sierra.gdatech.com>

You need to check the phy address and the type of the PHY used.
If it is not there/or supported, you may want to include them.


> On Tue, Jul 10, 2007 at 03:41:25PM +0200, ThomasB wrote:
> > >Isn't the ethernet the same on the 64260, 64360, 64460?
> > >
> > >There's definitely a driver for 6436x and above..
> > 
> > I just try it, it doesn't work, I receive without end the message:
> > mv643xx PHY read timeout, port 0
> > 
> > >I believe that Steve Hill <sjhill at realitydiluted.com> has patched
> > >the mv643xx_eth driver to work with the 64260 and plans to submit
> > >the patches.
> > That's means the patch isn't yet ready?
> 
> It probably means you don't something set up for whatever PHY you're
> using.
> 
> > I will try to contact him.
> 
> A good idea.
> 
> > It's nevertheless odd, I read about a file named gt64260_eth.c 
during my
> > search on the internet.But I wasn't able to find it :(.
> 
> There was one for 2.4 that was in the ppc devel tree but it never went
> mainline.  Hopefully, Steve can help you from here.
> 
> Mark
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 

*************************************************************
GDA Technologies, Inc.		
1010 Rincon Circle 
San Jose CA, 95131
Phone	(408) 432-3090
Fax	(408) 432-3091

Accelerate Your Innovation	
**************************************************************


=====
This message contains information from GDA Technologies Inc and 
affiliates, and is intended for the sole use of the individual and 
entity to whom it is addressed. It may contain information, including 
any attachments, that is privileged, confidential and exempt from 
disclosure under applicable law. If you are not the intended addressee, 
nor authorized to receive for the intended addressee, you are hereby 
notified that you may not use, copy, disclose or distribute to anyone 
the message or any information contained in the message. If you have 
received this electronic transmission in error, please notify the 
sender immediately by a "reply to sender only" message and destroy all 
electronic and hard copies of the communication, including attachments.
====


From scottwood at freescale.com  Wed Jul 11 04:05:27 2007
From: scottwood at freescale.com (Scott Wood)
Date: Tue, 10 Jul 2007 13:05:27 -0500
Subject: [PATCH] [POWERPC] Move generic MPC82xx functions out of
	ADS-specific
In-Reply-To: <200707101312.46052.laurent.pinchart@technotrade.biz>
References: <200707101312.46052.laurent.pinchart@technotrade.biz>
Message-ID: <20070710180526.GA14935@ld0162-tx32.am.freescale.net>

On Tue, Jul 10, 2007 at 01:12:45PM +0200, Laurent Pinchart wrote:
> The non board-specific mpc82xx_halt and mpc82xx_restart functions are defined
> in arch/powerpc/platforms/82xx/mpc82xx_ads.c. This patch moves them to
> mpc82xx.c to make them usable by other MPC82xx boards.

Why are you also moving mpc82xx_ads_show_cpuinfo() to the board file? 
It's not really ADS-specific; it should just be renamed.

-Scott


From scottwood at freescale.com  Wed Jul 11 04:11:33 2007
From: scottwood at freescale.com (Scott Wood)
Date: Tue, 10 Jul 2007 13:11:33 -0500
Subject: MPC82xx ADS SCC ports initialisation
In-Reply-To: <200707101619.52438.laurent.pinchart@technotrade.biz>
References: <200707101619.52438.laurent.pinchart@technotrade.biz>
Message-ID: <20070710181133.GB14935@ld0162-tx32.am.freescale.net>

On Tue, Jul 10, 2007 at 04:19:51PM +0200, Laurent Pinchart wrote:
> clrbits32(&immap->im_cpmux.cmx_scr, (0x00000007 << (4 - data->clk_tx)));
> clrbits32(&immap->im_cpmux.cmx_scr, (0x00000038 << (4 - data->clk_rx)));
> setbits32(&immap->im_cpmux.cmx_scr, 
>           ((data->clk_tx - 1) << (4 - data->clk_tx)));
> setbits32(&immap->im_cpmux.cmx_scr,
>           ((data->clk_rx - 1) << (4 - data->clk_rx)));
> 
> The shift right-hand operand doesn't seem to be correct. Could anyone confirm 
> this ?

You are correct; it's broken.

> If my assumption is right, could anyone tell me if the MPC82xx 
> processors are actually supported by the powerpc architecture, or if the 
> MPC82xx ADS code is just a non-functional work in progress.

I have a bunch of 8xx/82xx changes pending; I hope to get them cleaned up
before the merge window ends.

> I also noticed that U-Boot doesn't have flatten device tree support for the 
> MPC82xx family.

No, but cuImage for 82xx is on its way.

-Scott


From Antonio.DiBacco at technolabs.it  Wed Jul 11 04:15:29 2007
From: Antonio.DiBacco at technolabs.it (DI BACCO ANTONIO - technolabs)
Date: Tue, 10 Jul 2007 20:15:29 +0200
Subject: Talking to PHYs on MPC880
Message-ID: <F1F6EC0C8B75034F9E3A79FC85122E8E977B81@aquib01a>

Hi,

I have an MPC880 with his FEC1 (eth0) connected via an MII-MII interface
to a switch.
The MPC880 controls (through its MDIO bus controller) the PHYs of the
switch. Each PHY has its own ethernet connector.

Because I don't want the FEC to bother about the status of the PHYs, I
chose to assign to the eth0 a "fixed at 100:1" virtual PHY. Nevertheless, I
would like to read registers of the real PHYs but issueing the ioctl
SIOCGMIIREG  I actually access the (virtual) fixed PHY. How could I
handle this problem?
I can apply an ugly patch to fs_enet but I would like to receive and
advice to do a beautiful job.

Any help is appreciated.


From jeff at garzik.org  Wed Jul 11 11:14:50 2007
From: jeff at garzik.org (Jeff Garzik)
Date: Tue, 10 Jul 2007 21:14:50 -0400
Subject: [PATCH] pata_mpc52xx: suspend/resume support
In-Reply-To: <20070703082738.GM23294@moe.telargo.com>
References: <20070703082738.GM23294@moe.telargo.com>
Message-ID: <46942F0A.1010707@garzik.org>

Domen Puncer wrote:
> Implement suspend and resume routines for mpc52xx ata driver.
> Tested on Lite5200b with deep-sleep and low-power (not yet in-tree)
> modes.
> 
> 
> Signed-off-by: Domen Puncer <domen.puncer at telargo.com>
> 
> ---
> If anyone cares, I attached ATA_DEBUG messages at the end of patch.
> Should it take almost 5 seconds?
> 
> 
>  drivers/ata/pata_mpc52xx.c |   18 ++++++++++++++++--
>  1 file changed, 16 insertions(+), 2 deletions(-)

applied




From domen.puncer at telargo.com  Wed Jul 11 15:49:23 2007
From: domen.puncer at telargo.com (Domen Puncer)
Date: Wed, 11 Jul 2007 07:49:23 +0200
Subject: [PATCH] i2c-mpc: work around missing-9th-clock-pulse bug
In-Reply-To: <20070710144030.3786cbf3@hyperion.delvare>
References: <20070709071955.GD4186@moe.telargo.com>
	<fa686aa40707090853j6079b0c7rbcff7c449baa15e0@mail.gmail.com>
	<20070710061736.GG4186@moe.telargo.com>
	<fa686aa40707092322v58bbdad0veb0ee2ec00f125b0@mail.gmail.com>
	<20070710144030.3786cbf3@hyperion.delvare>
Message-ID: <20070711054923.GA4375@moe.telargo.com>

On 10/07/07 14:40 +0200, Jean Delvare wrote:
> Hi Grant, hi Domen,
> 
> On Tue, 10 Jul 2007 00:22:05 -0600, Grant Likely wrote:
> > On 7/10/07, Domen Puncer <domen.puncer at telargo.com> wrote:
> > > Work around a problem reported on:
> > > http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019038.html
> > > Without this patch I2C on mpc5200 becomes unusable after a while.
> > > Tested on mpc5200 boards by Matthias and me.
> > >
> > >
> > > Signed-off-by: Domen Puncer <domen.puncer at telargo.com>
> > 
> > Looks good to me,
> > 
> > Acked-by: Grant Likely <grant.likely at secretlab.ca>
> 
> OK, I will take this patch, but I'd like you to add a comment before
> mpc_i2c_fixup() explaining what exactly the problem is and how it is
> worked around. Otherwise it's a bit obscure what is going on.

OK.

> 
> I guess you want this patch in 2.6.23-rc1?

Yes.

So... v3:
<----------- cut ------------->

Work around a problem reported on:
http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019038.html
Without this patch I2C on mpc5200 becomes unusable after a while.
Tested on mpc5200 boards by Matthias Fechner and me.


Signed-off-by: Domen Puncer <domen.puncer at telargo.com>

---
 drivers/i2c/busses/i2c-mpc.c |   21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

Index: work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
===================================================================
--- work-powerpc.git.orig/drivers/i2c/busses/i2c-mpc.c
+++ work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
@@ -74,6 +74,24 @@ static irqreturn_t mpc_i2c_isr(int irq, 
 	return IRQ_HANDLED;
 }
 
+/* Sometimes 9th clock pulse isn't generated, so slave doesn't release
+ * the bus.  Documented and suggested workaround on
+ * http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019038.html
+ */
+static void mpc_i2c_fixup(struct mpc_i2c *i2c)
+{
+	writeccr(i2c, 0);
+	udelay(30);
+	writeccr(i2c, CCR_MEN);
+	udelay(30);
+	writeccr(i2c, CCR_MSTA | CCR_MTX);
+	udelay(30);
+	writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);
+	udelay(30);
+	writeccr(i2c, CCR_MEN);
+	udelay(30);
+}
+
 static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
 {
 	unsigned long orig_jiffies = jiffies;
@@ -153,6 +171,7 @@ static void mpc_i2c_start(struct mpc_i2c
 static void mpc_i2c_stop(struct mpc_i2c *i2c)
 {
 	writeccr(i2c, CCR_MEN);
+	writeccr(i2c, 0);
 }
 
 static int mpc_write(struct mpc_i2c *i2c, int target,
@@ -245,6 +264,8 @@ static int mpc_xfer(struct i2c_adapter *
 		}
 		if (time_after(jiffies, orig_jiffies + HZ)) {
 			pr_debug("I2C: timeout\n");
+			if (readb(i2c->base + MPC_I2C_SR) == (CSR_MCF | CSR_MBB | CSR_RXAK))
+				mpc_i2c_fixup(i2c);
 			return -EIO;
 		}
 		schedule();


From grant.likely at secretlab.ca  Wed Jul 11 16:03:28 2007
From: grant.likely at secretlab.ca (Grant Likely)
Date: Wed, 11 Jul 2007 00:03:28 -0600
Subject: [PATCH] i2c-mpc: work around missing-9th-clock-pulse bug
In-Reply-To: <20070711054923.GA4375@moe.telargo.com>
References: <20070709071955.GD4186@moe.telargo.com>
	<fa686aa40707090853j6079b0c7rbcff7c449baa15e0@mail.gmail.com>
	<20070710061736.GG4186@moe.telargo.com>
	<fa686aa40707092322v58bbdad0veb0ee2ec00f125b0@mail.gmail.com>
	<20070710144030.3786cbf3@hyperion.delvare>
	<20070711054923.GA4375@moe.telargo.com>
Message-ID: <fa686aa40707102303k58bae578u7358b932c4721ec0@mail.gmail.com>

On 7/10/07, Domen Puncer <domen.puncer at telargo.com> wrote:
> On 10/07/07 14:40 +0200, Jean Delvare wrote:
> > Hi Grant, hi Domen,
> >
> > On Tue, 10 Jul 2007 00:22:05 -0600, Grant Likely wrote:
> > > On 7/10/07, Domen Puncer <domen.puncer at telargo.com> wrote:
> > > > Work around a problem reported on:
> > > > http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019038.html
> > > > Without this patch I2C on mpc5200 becomes unusable after a while.
> > > > Tested on mpc5200 boards by Matthias and me.
> > > >
> > > >
> > > > Signed-off-by: Domen Puncer <domen.puncer at telargo.com>
> > >
> > > Looks good to me,
> > >
> > > Acked-by: Grant Likely <grant.likely at secretlab.ca>
> >
> > OK, I will take this patch, but I'd like you to add a comment before
> > mpc_i2c_fixup() explaining what exactly the problem is and how it is
> > worked around. Otherwise it's a bit obscure what is going on.
>
> OK.
>
> >
> > I guess you want this patch in 2.6.23-rc1?
>
> Yes.
>
> So... v3:
> <----------- cut ------------->
>
> Work around a problem reported on:
> http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019038.html
> Without this patch I2C on mpc5200 becomes unusable after a while.
> Tested on mpc5200 boards by Matthias Fechner and me.
>
>
> Signed-off-by: Domen Puncer <domen.puncer at telargo.com>
>
> ---
>  drivers/i2c/busses/i2c-mpc.c |   21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
>
> Index: work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
> ===================================================================
> --- work-powerpc.git.orig/drivers/i2c/busses/i2c-mpc.c
> +++ work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
> @@ -74,6 +74,24 @@ static irqreturn_t mpc_i2c_isr(int irq,
>         return IRQ_HANDLED;
>  }
>
> +/* Sometimes 9th clock pulse isn't generated, so slave doesn't release
> + * the bus.  Documented and suggested workaround on
> + * http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019038.html
> + */

I don't think it's a great idea to use a link;  You should copy the
important parts into the .c file.  Archives may not be forever, and
links cannot be read when offline.  If the text is too long for the
middle of the C file; then put the documentation at the top right
after the header block.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195


From domen.puncer at telargo.com  Wed Jul 11 16:33:35 2007
From: domen.puncer at telargo.com (Domen Puncer)
Date: Wed, 11 Jul 2007 08:33:35 +0200
Subject: [PATCH] i2c-mpc: work around missing-9th-clock-pulse bug
In-Reply-To: <fa686aa40707102303k58bae578u7358b932c4721ec0@mail.gmail.com>
References: <20070709071955.GD4186@moe.telargo.com>
	<fa686aa40707090853j6079b0c7rbcff7c449baa15e0@mail.gmail.com>
	<20070710061736.GG4186@moe.telargo.com>
	<fa686aa40707092322v58bbdad0veb0ee2ec00f125b0@mail.gmail.com>
	<20070710144030.3786cbf3@hyperion.delvare>
	<20070711054923.GA4375@moe.telargo.com>
	<fa686aa40707102303k58bae578u7358b932c4721ec0@mail.gmail.com>
Message-ID: <20070711063335.GB4375@moe.telargo.com>

On 11/07/07 00:03 -0600, Grant Likely wrote:
> On 7/10/07, Domen Puncer <domen.puncer at telargo.com> wrote:
> >On 10/07/07 14:40 +0200, Jean Delvare wrote:
...
> >+/* Sometimes 9th clock pulse isn't generated, so slave doesn't release
> >+ * the bus.  Documented and suggested workaround on
> >+ * http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019038.html
> >+ */
> 
> I don't think it's a great idea to use a link;  You should copy the
> important parts into the .c file.  Archives may not be forever, and
> links cannot be read when offline.  If the text is too long for the
> middle of the C file; then put the documentation at the top right
> after the header block.

And v4:
<----------- cut ------------->

Work around a problem reported on:
http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019038.html
Without this patch I2C on mpc5200 becomes unusable after a while.
Tested on mpc5200 boards by Matthias Fechner and me.


Signed-off-by: Domen Puncer <domen.puncer at telargo.com>

---
 drivers/i2c/busses/i2c-mpc.c |   22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

Index: work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
===================================================================
--- work-powerpc.git.orig/drivers/i2c/busses/i2c-mpc.c
+++ work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
@@ -74,6 +74,25 @@ static irqreturn_t mpc_i2c_isr(int irq, 
 	return IRQ_HANDLED;
 }
 
+/* Sometimes 9th clock pulse isn't generated, and slave doesn't release
+ * the bus, because it wants to send ACK.
+ * Following sequence of enabling/disabling and sending start/stop generates
+ * the pulse, so it's all OK.
+ */
+static void mpc_i2c_fixup(struct mpc_i2c *i2c)
+{
+	writeccr(i2c, 0);
+	udelay(30);
+	writeccr(i2c, CCR_MEN);
+	udelay(30);
+	writeccr(i2c, CCR_MSTA | CCR_MTX);
+	udelay(30);
+	writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);
+	udelay(30);
+	writeccr(i2c, CCR_MEN);
+	udelay(30);
+}
+
 static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
 {
 	unsigned long orig_jiffies = jiffies;
@@ -153,6 +172,7 @@ static void mpc_i2c_start(struct mpc_i2c
 static void mpc_i2c_stop(struct mpc_i2c *i2c)
 {
 	writeccr(i2c, CCR_MEN);
+	writeccr(i2c, 0);
 }
 
 static int mpc_write(struct mpc_i2c *i2c, int target,
@@ -245,6 +265,8 @@ static int mpc_xfer(struct i2c_adapter *
 		}
 		if (time_after(jiffies, orig_jiffies + HZ)) {
 			pr_debug("I2C: timeout\n");
+			if (readb(i2c->base + MPC_I2C_SR) == (CSR_MCF | CSR_MBB | CSR_RXAK))
+				mpc_i2c_fixup(i2c);
 			return -EIO;
 		}
 		schedule();


From sahil.satpute at gmail.com  Wed Jul 11 16:58:03 2007
From: sahil.satpute at gmail.com (linuxdev)
Date: Tue, 10 Jul 2007 23:58:03 -0700 (PDT)
Subject: Porting kernel 2.6.11 to WindRiver board.
Message-ID: <11459454.post@talk.nabble.com>


HI guys!

I have to port a linux kernel to Motorola MPC 7447 based WindRiver SBC 7447
board.
I plan to use Kernel 2.6.11 and Uboot for the same. I wanted to know whether
these two can be used for the board. Also how do I get hold of a BSP for
this board and kernel? Are there any information resources for the same?

Thanks in advance...
LinuxDev.
-- 
View this message in context: http://www.nabble.com/Porting-kernel-2.6.11-to-WindRiver-board.-tf4033888.html#a11459454
Sent from the linuxppc-embedded mailing list archive at Nabble.com.



From laurent.pinchart at technotrade.biz  Wed Jul 11 17:11:18 2007
From: laurent.pinchart at technotrade.biz (Laurent Pinchart)
Date: Wed, 11 Jul 2007 09:11:18 +0200
Subject: MPC82xx ADS SCC ports initialisation
In-Reply-To: <20070710181133.GB14935@ld0162-tx32.am.freescale.net>
References: <200707101619.52438.laurent.pinchart@technotrade.biz>
	<20070710181133.GB14935@ld0162-tx32.am.freescale.net>
Message-ID: <200707110911.19477.laurent.pinchart@technotrade.biz>

On Tuesday 10 July 2007 20:11, Scott Wood wrote:
> On Tue, Jul 10, 2007 at 04:19:51PM +0200, Laurent Pinchart wrote:
> > clrbits32(&immap->im_cpmux.cmx_scr, (0x00000007 << (4 - data->clk_tx)));
> > clrbits32(&immap->im_cpmux.cmx_scr, (0x00000038 << (4 - data->clk_rx)));
> > setbits32(&immap->im_cpmux.cmx_scr,
> >           ((data->clk_tx - 1) << (4 - data->clk_tx)));
> > setbits32(&immap->im_cpmux.cmx_scr,
> >           ((data->clk_rx - 1) << (4 - data->clk_rx)));
> >
> > The shift right-hand operand doesn't seem to be correct. Could anyone
> > confirm this ?
>
> You are correct; it's broken.

That code should be replaced with calls to cpm2_clk_setup 
(arch/powerpc/sysdev/cpm2_common.c). cpm2_clk_setup currently supports FCC 
clock setup only, but I've got a patch to add SCC clock setup support. Should 
I send it ?

> > If my assumption is right, could anyone tell me if the MPC82xx
> > processors are actually supported by the powerpc architecture, or if the
> > MPC82xx ADS code is just a non-functional work in progress.
>
> I have a bunch of 8xx/82xx changes pending; I hope to get them cleaned up
> before the merge window ends.

That would be nice. I'll wait for your changes to continue my ppc -> powerpc 
port.

> > I also noticed that U-Boot doesn't have flatten device tree support for
> > the MPC82xx family.
>
> No, but cuImage for 82xx is on its way.

Ok, nice to know. Adding FDT support to U-Boot for the MPC82xx family will be 
on my todo-list once I get Linux working with cuImage.

Laurent Pinchart


From laurent.pinchart at technotrade.biz  Wed Jul 11 17:28:55 2007
From: laurent.pinchart at technotrade.biz (Laurent Pinchart)
Date: Wed, 11 Jul 2007 09:28:55 +0200
Subject: [PATCH] [POWERPC] Move generic MPC82xx functions out of
	ADS-specific
In-Reply-To: <20070710180526.GA14935@ld0162-tx32.am.freescale.net>
References: <200707101312.46052.laurent.pinchart@technotrade.biz>
	<20070710180526.GA14935@ld0162-tx32.am.freescale.net>
Message-ID: <200707110928.55339.laurent.pinchart@technotrade.biz>

On Tuesday 10 July 2007 20:05, Scott Wood wrote:
> On Tue, Jul 10, 2007 at 01:12:45PM +0200, Laurent Pinchart wrote:
> > The non board-specific mpc82xx_halt and mpc82xx_restart functions are
> > defined in arch/powerpc/platforms/82xx/mpc82xx_ads.c. This patch moves
> > them to mpc82xx.c to make them usable by other MPC82xx boards.
>
> Why are you also moving mpc82xx_ads_show_cpuinfo() to the board file?
> It's not really ADS-specific; it should just be renamed.

For the MPC82xx ADS boards, mpc82xx_ads_show_cpuinfo() prints

Vendor		: Freescale Semiconductor
Machine		: PQ2 ADS PowerPC

The vendor string is hardcoded to "Freescale Semiconductor", and the machine 
string is defined in pq2ads.h. What should show_cpuinfo() print ? Should the 
vendor be the board vendor or the CPU vendor ? What about the machine ?

Laurent Pinchart


From clifford at clifford.at  Wed Jul 11 19:35:34 2007
From: clifford at clifford.at (Clifford Wolf)
Date: Wed, 11 Jul 2007 11:35:34 +0200
Subject: Mem-2-Mem DMA - Generalized API
In-Reply-To: <200707071508.04143.arnd@arndb.de>
References: <20070624193932.GA11797@clifford.at>
	<20070625180110.GH20463@clifford.at>
	<20070704090554.GA30693@clifford.at>
	<200707071508.04143.arnd@arndb.de>
Message-ID: <20070711093534.GA6366@clifford.at>

Hi again,

The updated status of my DMA Transfer API can be found at:

	http://www.clifford.at/priv/dmatransfer-20070711.diff

I have incorporated your feedback and would appreciate if you could have
another look over the updated sourcecode. Changes include:

	- Many cosmetic / coding style related changes

	- Added MPC3494 Scatter/Gather DMA Support

	- Added a 'softdma' driver providing software emulation

	- Added DMATRANSFER_MAYFAIL flag, panic() if a DMA Transfer without
	  this flag set fails.

	- Added /proc/dmatransfer with statistic data

I also have two questions. In the my current source there is the following
hack:

--snip--
	wmb();
	dma_cache_wback_inv(sg_list, sizeof(struct chain_desc) * segment_n);

#if 1
	/* FIXME: dma_cache_wback_inv() should have done this already! */
	{
		void *p = sg_list;
		while (p < ((void*)sg_list) +
				sizeof(struct chain_desc) * segment_n) {
			__asm__ __volatile__ ("dcbf 0,%0" : : "r" (p));
			p += 4;
		}
		__asm__ __volatile__ ("sync");
	}
#endif
--snap--

In my understanding, dma_cache_wback_inv() should do exactly the same thing
as my loop with PowerPC inline assembly. However, if I change the '#if 1'
to '#if 0' in this source it stopps working.

What am I doing wrong? What function should I use instead of
dma_cache_wback_inv() in this place?

> BUG() may be a little harsh here, especially since you are holding spinlocks.
> It would be better to try to recover here, unless you expect actual data
> corruption, in which case a full panic() might be more appropriate.

So what exactly would be the correct usecase of BUG() over panic()?

My impressions was that BUG() would be the right choice for errors coming
from bad programming while panic() would be for errors coming from bad
hardware.

yours,
 - clifford

-- 
For extra security, this message has been encrypted with double-ROT13.


From blackfin.kang at gmail.com  Wed Jul 11 20:21:08 2007
From: blackfin.kang at gmail.com (kang shuo)
Date: Wed, 11 Jul 2007 18:21:08 +0800
Subject: ask two question about e500 implementation in
	arch/ppc/kernel/head_fsl_booke.S
Message-ID: <a7f827420707110321scea22beg9505286e00ba79b2@mail.gmail.com>

hi,galak:
              I have two question about e500 part of linux kernel. I
can not get reponse from maillist . So I sent the questions to you
directly.

1. in  arch/ppc/kernel/head_fsl_booke.S
 603         FIND_PTE
 604         andi.   r13, r11, _PAGE_PRESENT /* Is the page present? */
 605         beq     2f                      /* Bail if not present */

That seems _PAGE_PRESENT should be set before enter DataTLBError
exception handler(Or the following finish_tlb_load function will not
execute), but  in __ioremap function of e500 implementation,
_PAGE_PRESENT bit is not set for an io address map.Why?

2. still in   arch/ppc/kernel/head_fsl_booke.S
 791 #ifdef CONFIG_E200
 792         /* Round robin TLB1 entries assignment */
 793         mfspr   r12, SPRN_MAS0
 794
 795         /* Extract TLB1CFG(NENTRY) */
 796         mfspr   r11, SPRN_TLB1CFG
 797         andi.   r11, r11, 0xfff
 798
 799         /* Extract MAS0(NV) */
 800         andi.   r13, r12, 0xfff
 801         addi    r13, r13, 1
 802         cmpw    0, r13, r11
 803         addi    r12, r12, 1
 804
 805         /* check if we need to wrap */
 806         blt     7f
 807
 808         /* wrap back to first free tlbcam entry */
 809         lis     r13, tlbcam_index at ha
 810         lwz     r13, tlbcam_index at l(r13)
 811         rlwimi  r12, r13, 0, 20, 31
 812 7:
 813         mtspr   SPRN_MAS0,r12
 814 #endif /* CONFIG_E200 */
 815
 816         tlbwe

That seems original tlb entry will be overwritten in the above code
for e500? Why , I thought a free tlb entry should be select and fill
for e500. Just like CONFIG_E200.


-- Thanks
-- Michael.Kang


From clemens.koller at anagramm.de  Wed Jul 11 21:02:33 2007
From: clemens.koller at anagramm.de (Clemens Koller)
Date: Wed, 11 Jul 2007 13:02:33 +0200
Subject: Porting kernel 2.6.11 to WindRiver board.
In-Reply-To: <11459454.post@talk.nabble.com>
References: <11459454.post@talk.nabble.com>
Message-ID: <4694B8C9.8010209@anagramm.de>

linuxdev schrieb:
> I have to port a linux kernel to Motorola MPC 7447 based WindRiver SBC 7447
> board.

The MPC7447 is one of the G4+ PowerPC processor series.
You shouldn't run into much issues to get Linux running on it.

A good start can be to use the latest ELDK from http://www.denx.de.

I created a native PowerPC environment for embedded use based on the
latest CRUX linux distribution (http://cruxppc.sunsite.dk).
CRUX is also available for x86 (http://crux.nu) which is nice
to work completely platform independent.

> I plan to use Kernel 2.6.11 and Uboot for the same.

It doesn't make sense to use an older than the latest Kernel because
nobody wants to help you in case you run into problems.
Use the latest linux git tree. (or at least some 2.6.22)
And use the latest U-Boot git tree. (also from denx)

 > I wanted to know whether
> these two can be used for the board. Also how do I get hold of a BSP for
> this board and kernel? Are there any information resources for the same?

It's all available in the web. It depends on your hardware setup
how complicated your "porting" might be. I hope you good good documentation
for it.
If you have a Harddisk to boot from or some network interface, "porting"
it might be as simple as installing some x86 platform.

> Thanks in advance...
> LinuxDev.
Please use your real name.

Regards,
-- 
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Stra?e 45/1
Linhof Werksgel?nde
D-81379 M?nchen
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com


From vbordug at ru.mvista.com  Wed Jul 11 20:34:22 2007
From: vbordug at ru.mvista.com (Vitaly Bordug)
Date: Wed, 11 Jul 2007 14:34:22 +0400
Subject: MPC82xx ADS SCC ports initialisation
In-Reply-To: <200707110911.19477.laurent.pinchart@technotrade.biz>
References: <200707101619.52438.laurent.pinchart@technotrade.biz>
	<20070710181133.GB14935@ld0162-tx32.am.freescale.net>
	<200707110911.19477.laurent.pinchart@technotrade.biz>
Message-ID: <20070711143422.6b00620e@localhost.localdomain>

On Wed, 11 Jul 2007 09:11:18 +0200
Laurent Pinchart wrote:

> On Tuesday 10 July 2007 20:11, Scott Wood wrote:
> > On Tue, Jul 10, 2007 at 04:19:51PM +0200, Laurent Pinchart wrote:
> > > clrbits32(&immap->im_cpmux.cmx_scr, (0x00000007 << (4 -
> > > data->clk_tx))); clrbits32(&immap->im_cpmux.cmx_scr, (0x00000038
> > > << (4 - data->clk_rx))); setbits32(&immap->im_cpmux.cmx_scr,
> > >           ((data->clk_tx - 1) << (4 - data->clk_tx)));
> > > setbits32(&immap->im_cpmux.cmx_scr,
> > >           ((data->clk_rx - 1) << (4 - data->clk_rx)));
> > >
> > > The shift right-hand operand doesn't seem to be correct. Could
> > > anyone confirm this ?
> >
> > You are correct; it's broken.
> 
> That code should be replaced with calls to cpm2_clk_setup 
> (arch/powerpc/sysdev/cpm2_common.c). cpm2_clk_setup currently
> supports FCC clock setup only, but I've got a patch to add SCC clock
> setup support. Should I send it ?
> 
If you have functional approach, please feel free to send it...

> > > If my assumption is right, could anyone tell me if the MPC82xx
> > > processors are actually supported by the powerpc architecture, or
> > > if the MPC82xx ADS code is just a non-functional work in progress.
> >
once my last changes were committed, 82xx was supported and worked fine.
Pretty long time I had no access to the hardware, hence some minor things might require catch-up.



> > I have a bunch of 8xx/82xx changes pending; I hope to get them
> > cleaned up before the merge window ends.
> 
Since I'm the only person covering 8xx/82xx for a while, I definitely want to look at those changes...
> That would be nice. I'll wait for your changes to continue my ppc ->
> powerpc port.
> 
> > > I also noticed that U-Boot doesn't have flatten device tree
> > > support for the MPC82xx family.
> >

At the moment, I have a patch to add such a thing, but no ability to validate it still works. If you guys will assist a little,
I'll go ahead and submit it to the u-boot list.

> > No, but cuImage for 82xx is on its way.
> 
> Ok, nice to know. Adding FDT support to U-Boot for the MPC82xx family
> will be on my todo-list once I get Linux working with cuImage.
> 
> Laurent Pinchart
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070711/6a746ca1/attachment.pgp 

From khali at linux-fr.org  Wed Jul 11 21:40:37 2007
From: khali at linux-fr.org (Jean Delvare)
Date: Wed, 11 Jul 2007 13:40:37 +0200
Subject: [PATCH] i2c-mpc: work around missing-9th-clock-pulse bug
In-Reply-To: <20070711063335.GB4375@moe.telargo.com>
References: <20070709071955.GD4186@moe.telargo.com>
	<fa686aa40707090853j6079b0c7rbcff7c449baa15e0@mail.gmail.com>
	<20070710061736.GG4186@moe.telargo.com>
	<fa686aa40707092322v58bbdad0veb0ee2ec00f125b0@mail.gmail.com>
	<20070710144030.3786cbf3@hyperion.delvare>
	<20070711054923.GA4375@moe.telargo.com>
	<fa686aa40707102303k58bae578u7358b932c4721ec0@mail.gmail.com>
	<20070711063335.GB4375@moe.telargo.com>
Message-ID: <20070711134037.1fe0373e@hyperion.delvare>

Hi Domen,

On Wed, 11 Jul 2007 08:33:35 +0200, Domen Puncer wrote:
> On 11/07/07 00:03 -0600, Grant Likely wrote:
> > I don't think it's a great idea to use a link;  You should copy the
> > important parts into the .c file.  Archives may not be forever, and
> > links cannot be read when offline.  If the text is too long for the
> > middle of the C file; then put the documentation at the top right
> > after the header block.
> 
> And v4:
> <----------- cut ------------->
> 
> Work around a problem reported on:
> http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019038.html
> Without this patch I2C on mpc5200 becomes unusable after a while.
> Tested on mpc5200 boards by Matthias Fechner and me.
> 
> 
> Signed-off-by: Domen Puncer <domen.puncer at telargo.com>

Applied, thanks.

-- 
Jean Delvare


From laurent.pinchart at technotrade.biz  Wed Jul 11 23:13:59 2007
From: laurent.pinchart at technotrade.biz (Laurent Pinchart)
Date: Wed, 11 Jul 2007 15:13:59 +0200
Subject: MPC82xx ADS SCC ports initialisation
In-Reply-To: <20070711143422.6b00620e@localhost.localdomain>
References: <200707101619.52438.laurent.pinchart@technotrade.biz>
	<200707110911.19477.laurent.pinchart@technotrade.biz>
	<20070711143422.6b00620e@localhost.localdomain>
Message-ID: <200707111514.00910.laurent.pinchart@technotrade.biz>

Hi Vitaly,

On Wednesday 11 July 2007 12:34, Vitaly Bordug wrote:
> On Wed, 11 Jul 2007 09:11:18 +0200
>
> Laurent Pinchart wrote:
> > On Tuesday 10 July 2007 20:11, Scott Wood wrote:
> > > On Tue, Jul 10, 2007 at 04:19:51PM +0200, Laurent Pinchart wrote:
> > > > clrbits32(&immap->im_cpmux.cmx_scr, (0x00000007 << (4 -
> > > > data->clk_tx))); clrbits32(&immap->im_cpmux.cmx_scr, (0x00000038
> > > > << (4 - data->clk_rx))); setbits32(&immap->im_cpmux.cmx_scr,
> > > >           ((data->clk_tx - 1) << (4 - data->clk_tx)));
> > > > setbits32(&immap->im_cpmux.cmx_scr,
> > > >           ((data->clk_rx - 1) << (4 - data->clk_rx)));
> > > >
> > > > The shift right-hand operand doesn't seem to be correct. Could
> > > > anyone confirm this ?
> > >
> > > You are correct; it's broken.
> >
> > That code should be replaced with calls to cpm2_clk_setup
> > (arch/powerpc/sysdev/cpm2_common.c). cpm2_clk_setup currently
> > supports FCC clock setup only, but I've got a patch to add SCC clock
> > setup support. Should I send it ?
>
> If you have functional approach, please feel free to send it...

I haven't been able to test the patch, as I have no ADS hardware to test it 
on. My MPC82xx board is far from being ported to the powerpc architecture. 
I'll send the patch anyway. Could you evaluate it ?

> > > > If my assumption is right, could anyone tell me if the MPC82xx
> > > > processors are actually supported by the powerpc architecture, or
> > > > if the MPC82xx ADS code is just a non-functional work in progress.
>
> once my last changes were committed, 82xx was supported and worked fine.
> Pretty long time I had no access to the hardware, hence some minor things
> might require catch-up.

The above code might have been worked by sheer luck though.

> > > I have a bunch of 8xx/82xx changes pending; I hope to get them
> > > cleaned up before the merge window ends.
>
> Since I'm the only person covering 8xx/82xx for a while, I definitely want
> to look at those changes...
>
> > That would be nice. I'll wait for your changes to continue my ppc ->
> > powerpc port.
> >
> > > > I also noticed that U-Boot doesn't have flatten device tree
> > > > support for the MPC82xx family.
>
> At the moment, I have a patch to add such a thing, but no ability to
> validate it still works. If you guys will assist a little, I'll go ahead
> and submit it to the u-boot list.

I'm ready to help, but I'd like to port my board to the powerpc architecture 
first. FDT support in U-Boot is pretty useless with the ppc architecture.

> > > No, but cuImage for 82xx is on its way.
> >
> > Ok, nice to know. Adding FDT support to U-Boot for the MPC82xx family
> > will be on my todo-list once I get Linux working with cuImage.

Laurent Pinchart


From laurent.pinchart at technotrade.biz  Wed Jul 11 23:17:52 2007
From: laurent.pinchart at technotrade.biz (Laurent Pinchart)
Date: Wed, 11 Jul 2007 15:17:52 +0200
Subject: [PATCH 1/2] [POWERPC] Add SCC clock support to cpm2_clk_setup()
Message-ID: <200707111517.52663.laurent.pinchart@technotrade.biz>

cpm2_clk_setup() supports setting FCC clocks only, even though the
cpm_clk_target enumeration lists SCC clocks. This patch adds SCC clock
support.

Signed-off-by: Laurent Pinchart <laurent.pinchart at technotrade.biz>
---
 arch/powerpc/sysdev/cpm2_common.c |   38 ++++++++++++++++++++++++++++++++++--
 1 files changed, 35 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/sysdev/cpm2_common.c 
b/arch/powerpc/sysdev/cpm2_common.c
index 9244129..459fead 100644
--- a/arch/powerpc/sysdev/cpm2_common.c
+++ b/arch/powerpc/sysdev/cpm2_common.c
@@ -138,7 +138,39 @@ int cpm2_clk_setup(enum cpm_clk_target target, int clock, 
int mode)
 	cpmux_t *im_cpmux;
 	u32 *reg;
 	u32 mask = 7;
-	u8 clk_map [24][3] = {
+	u8 clk_map [][3] = {
+		{CPM_CLK_SCC1, CPM_BRG1, 0},
+		{CPM_CLK_SCC1, CPM_BRG2, 1},
+		{CPM_CLK_SCC1, CPM_BRG3, 2},
+		{CPM_CLK_SCC1, CPM_BRG4, 3},
+		{CPM_CLK_SCC1, CPM_CLK5, 4},
+		{CPM_CLK_SCC1, CPM_CLK6, 5},
+		{CPM_CLK_SCC1, CPM_CLK7, 6},
+		{CPM_CLK_SCC1, CPM_CLK8, 7},
+		{CPM_CLK_SCC2, CPM_BRG1, 0},
+		{CPM_CLK_SCC2, CPM_BRG2, 1},
+		{CPM_CLK_SCC2, CPM_BRG3, 2},
+		{CPM_CLK_SCC2, CPM_BRG4, 3},
+		{CPM_CLK_SCC2, CPM_CLK5, 4},
+		{CPM_CLK_SCC2, CPM_CLK6, 5},
+		{CPM_CLK_SCC2, CPM_CLK7, 6},
+		{CPM_CLK_SCC2, CPM_CLK8, 7},
+		{CPM_CLK_SCC3, CPM_BRG1, 0},
+		{CPM_CLK_SCC3, CPM_BRG2, 1},
+		{CPM_CLK_SCC3, CPM_BRG3, 2},
+		{CPM_CLK_SCC3, CPM_BRG4, 3},
+		{CPM_CLK_SCC3, CPM_CLK5, 4},
+		{CPM_CLK_SCC3, CPM_CLK6, 5},
+		{CPM_CLK_SCC3, CPM_CLK7, 6},
+		{CPM_CLK_SCC3, CPM_CLK8, 7},
+		{CPM_CLK_SCC4, CPM_BRG1, 0},
+		{CPM_CLK_SCC4, CPM_BRG2, 1},
+		{CPM_CLK_SCC4, CPM_BRG3, 2},
+		{CPM_CLK_SCC4, CPM_BRG4, 3},
+		{CPM_CLK_SCC4, CPM_CLK5, 4},
+		{CPM_CLK_SCC4, CPM_CLK6, 5},
+		{CPM_CLK_SCC4, CPM_CLK7, 6},
+		{CPM_CLK_SCC4, CPM_CLK8, 7},
 		{CPM_CLK_FCC1, CPM_BRG5, 0},
 		{CPM_CLK_FCC1, CPM_BRG6, 1},
 		{CPM_CLK_FCC1, CPM_BRG7, 2},
@@ -203,13 +235,13 @@ int cpm2_clk_setup(enum cpm_clk_target target, int 
clock, int mode)
 	if (mode == CPM_CLK_RX)
 		shift +=3;
 
-	for (i=0; i<24; i++) {
+	for (i=0; i<ARRAY_SIZE(clk_map); i++) {
 		if (clk_map[i][0] == target && clk_map[i][1] == clock) {
 			bits = clk_map[i][2];
 			break;
 		}
 	}
-	if (i == sizeof(clk_map)/3)
+	if (i == ARRAY_SIZE(clk_map))
 	    ret = -EINVAL;
 
 	bits <<= shift;
-- 
1.5.0


From laurent.pinchart at technotrade.biz  Wed Jul 11 23:18:48 2007
From: laurent.pinchart at technotrade.biz (Laurent Pinchart)
Date: Wed, 11 Jul 2007 15:18:48 +0200
Subject: [PATCH 2/2] [POWERPC] Use cpm2_clk_setup to configure SCC clocks for
	the MPC82xx ADS
Message-ID: <200707111518.48394.laurent.pinchart@technotrade.biz>


Signed-off-by: Laurent Pinchart <laurent.pinchart at technotrade.biz>
---
 arch/powerpc/platforms/82xx/mpc82xx_ads.c |   16 ++++------------
 1 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/platforms/82xx/mpc82xx_ads.c 
b/arch/powerpc/platforms/82xx/mpc82xx_ads.c
index 47cb09f..c8a29b9 100644
--- a/arch/powerpc/platforms/82xx/mpc82xx_ads.c
+++ b/arch/powerpc/platforms/82xx/mpc82xx_ads.c
@@ -234,12 +234,8 @@ static void init_scc1_uart_ioports(struct 
fs_uart_platform_info *data)
 	clrbits32(&immap->im_ioport.iop_pdird, 0x00000001);
 	setbits32(&immap->im_ioport.iop_pdird, 0x00000002);
 
-	clrbits32(&immap->im_cpmux.cmx_scr, (0x00000007 << (4 - data->clk_tx)));
-	clrbits32(&immap->im_cpmux.cmx_scr, (0x00000038 << (4 - data->clk_rx)));
-	setbits32(&immap->im_cpmux.cmx_scr,
-		  ((data->clk_tx - 1) << (4 - data->clk_tx)));
-	setbits32(&immap->im_cpmux.cmx_scr,
-		  ((data->clk_rx - 1) << (4 - data->clk_rx)));
+	cpm2_clk_setup(CPM_CLK_SCC1, data->clk_rx, CPM_CLK_RX);
+	cpm2_clk_setup(CPM_CLK_SCC1, data->clk_tx, CPM_CLK_TX);
 
 	iounmap(immap);
 }
@@ -253,12 +249,8 @@ static void init_scc4_uart_ioports(struct 
fs_uart_platform_info *data)
 	clrbits32(&immap->im_ioport.iop_pdird, 0x00000200);
 	setbits32(&immap->im_ioport.iop_pdird, 0x00000400);
 
-	clrbits32(&immap->im_cpmux.cmx_scr, (0x00000007 << (4 - data->clk_tx)));
-	clrbits32(&immap->im_cpmux.cmx_scr, (0x00000038 << (4 - data->clk_rx)));
-	setbits32(&immap->im_cpmux.cmx_scr,
-		  ((data->clk_tx - 1) << (4 - data->clk_tx)));
-	setbits32(&immap->im_cpmux.cmx_scr,
-		  ((data->clk_rx - 1) << (4 - data->clk_rx)));
+	cpm2_clk_setup(CPM_CLK_SCC4, data->clk_rx, CPM_CLK_RX);
+	cpm2_clk_setup(CPM_CLK_SCC4, data->clk_tx, CPM_CLK_TX);
 
 	iounmap(immap);
 }
-- 
1.5.0


From galak at kernel.crashing.org  Wed Jul 11 23:41:11 2007
From: galak at kernel.crashing.org (Kumar Gala)
Date: Wed, 11 Jul 2007 08:41:11 -0500
Subject: ask two question about e500 implementation in
	arch/ppc/kernel/head_fsl_booke.S
In-Reply-To: <a7f827420707110321scea22beg9505286e00ba79b2@mail.gmail.com>
References: <a7f827420707110321scea22beg9505286e00ba79b2@mail.gmail.com>
Message-ID: <48B57E32-92E8-4D95-B3A0-EC16A78D01F6@kernel.crashing.org>


On Jul 11, 2007, at 5:21 AM, kang shuo wrote:

> hi,galak:
>              I have two question about e500 part of linux kernel. I
> can not get reponse from maillist . So I sent the questions to you
> directly.
>
> 1. in  arch/ppc/kernel/head_fsl_booke.S
> 603         FIND_PTE
> 604         andi.   r13, r11, _PAGE_PRESENT /* Is the page present? */
> 605         beq     2f                      /* Bail if not present */
>
> That seems _PAGE_PRESENT should be set before enter DataTLBError
> exception handler(Or the following finish_tlb_load function will not
> execute), but  in __ioremap function of e500 implementation,
> _PAGE_PRESENT bit is not set for an io address map.Why?

_PAGE_PRESENT is sent when we use the page not when we map it.  So on  
the first fault we set _PAGE_PRESENT.

> 2. still in   arch/ppc/kernel/head_fsl_booke.S
> 791 #ifdef CONFIG_E200
> 792         /* Round robin TLB1 entries assignment */
> 793         mfspr   r12, SPRN_MAS0
> 794
> 795         /* Extract TLB1CFG(NENTRY) */
> 796         mfspr   r11, SPRN_TLB1CFG
> 797         andi.   r11, r11, 0xfff
> 798
> 799         /* Extract MAS0(NV) */
> 800         andi.   r13, r12, 0xfff
> 801         addi    r13, r13, 1
> 802         cmpw    0, r13, r11
> 803         addi    r12, r12, 1
> 804
> 805         /* check if we need to wrap */
> 806         blt     7f
> 807
> 808         /* wrap back to first free tlbcam entry */
> 809         lis     r13, tlbcam_index at ha
> 810         lwz     r13, tlbcam_index at l(r13)
> 811         rlwimi  r12, r13, 0, 20, 31
> 812 7:
> 813         mtspr   SPRN_MAS0,r12
> 814 #endif /* CONFIG_E200 */
> 815
> 816         tlbwe
>
> That seems original tlb entry will be overwritten in the above code
> for e500? Why , I thought a free tlb entry should be select and fill
> for e500. Just like CONFIG_E200.

Huh? The above code is for E200 only.  Maybe the issue you're missing  
is that on E500 the NV bit is updated by HW.

- k


From kkboyanov at gmail.com  Thu Jul 12 00:50:32 2007
From: kkboyanov at gmail.com (Konstantin Boyanov)
Date: Wed, 11 Jul 2007 16:50:32 +0200
Subject: Leaf drivers on Linux?
Message-ID: <929bf310707110750r32557735v848d84c626f0b5d9@mail.gmail.com>

Hi list,

I'm a little bit confused about an issue I hope you can shed some light on
it.

Right now I'm trying to write a driver for a vustom piece of hardware, which
resides on a VME bus. I'm using 2.6.15 kernel with an VME driver and can
access the device through normal ioctl()'s, read(), writes()'s. My
confiusion comes from the fact that from my driver I have to read some
registers when the custom device generates an interrupt, but since this
happens in kernel space, I'm not sure wheather I can use the normal IO
controls or not. Further confusion brings the fact that there is already a
working device for Solaris/SPARC for this device, and there the device
driver uses some kind of leaf driver. Is the concept of leaf and nexus
drivers, which is present in Solaris, also present in Linux? I tried to find
some information about differences in the two operating systems on that
level but only ended up in the "Writing device drivers" tutorials on
doc.sun.com.

If anybody can give me some clue about this leaf stuff I'll be thankful.

Best regards,
Konstantin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070711/8e6ed6a8/attachment.htm 

From scottwood at freescale.com  Thu Jul 12 01:21:28 2007
From: scottwood at freescale.com (Scott Wood)
Date: Wed, 11 Jul 2007 10:21:28 -0500
Subject: MPC82xx ADS SCC ports initialisation
In-Reply-To: <200707110911.19477.laurent.pinchart@technotrade.biz>
References: <200707101619.52438.laurent.pinchart@technotrade.biz>
	<20070710181133.GB14935@ld0162-tx32.am.freescale.net>
	<200707110911.19477.laurent.pinchart@technotrade.biz>
Message-ID: <4694F578.70901@freescale.com>

Laurent Pinchart wrote:
> That code should be replaced with calls to cpm2_clk_setup 
> (arch/powerpc/sysdev/cpm2_common.c). cpm2_clk_setup currently supports FCC 
> clock setup only, but I've got a patch to add SCC clock setup support. Should 
> I send it ?

It's already done in my working tree; I should have it picked apart into 
postable patches in the next few days.

-Scott


From scottwood at freescale.com  Thu Jul 12 01:25:33 2007
From: scottwood at freescale.com (Scott Wood)
Date: Wed, 11 Jul 2007 10:25:33 -0500
Subject: [PATCH] [POWERPC] Move generic MPC82xx functions out of
	ADS-specific
In-Reply-To: <200707110928.55339.laurent.pinchart@technotrade.biz>
References: <200707101312.46052.laurent.pinchart@technotrade.biz>
	<20070710180526.GA14935@ld0162-tx32.am.freescale.net>
	<200707110928.55339.laurent.pinchart@technotrade.biz>
Message-ID: <4694F66D.2010907@freescale.com>

Laurent Pinchart wrote:
> On Tuesday 10 July 2007 20:05, Scott Wood wrote:
>>Why are you also moving mpc82xx_ads_show_cpuinfo() to the board file?
>>It's not really ADS-specific; it should just be renamed.
> 
> 
> For the MPC82xx ADS boards, mpc82xx_ads_show_cpuinfo() prints
> 
> Vendor		: Freescale Semiconductor
> Machine		: PQ2 ADS PowerPC
> 
> The vendor string is hardcoded to "Freescale Semiconductor", and the machine 
> string is defined in pq2ads.h. What should show_cpuinfo() print ? Should the 
> vendor be the board vendor or the CPU vendor ? What about the machine ?

Ah, I missed that.  I'd just get rid of "Vendor" altogether, and include 
the vendor name in the machine name.

-Scott


From mederle_nicolas at yahoo.fr  Thu Jul 12 01:39:41 2007
From: mederle_nicolas at yahoo.fr (Nicolas Mederle)
Date: Wed, 11 Jul 2007 17:39:41 +0200
Subject: PageFault when I write in the Serial registers, MMU ?
Message-ID: <4694F9BD.4090406@yahoo.fr>

Hi,

    I am porting linux on a custom board equipped with a PPC750, and I 
will like to have some advices on the MMU. I used the powerpc arch, and 
I built my device tree.
    I will like to know in which files we can configure the 
authorizations access for the I/O registers. When I use the function 
md_ppc.progress, I have a data access fault. I modified the head. S 
files, for add the BAT config. But I think that it is not correct, and 
that it is possible to do it elsewhere (platform_init?). Moreover the 
kernel modify the MMU config, it removes the BATs, and configures the 
Registers Segments. So, must I remake the configuration? Or is it 
possible to indicate, at the beginning, which space is reserved for I/O?
    I studied several patch (sandpoint, PrPMC2800) but none configures 
really the MMU for I/O registers. In the same way, I read several books, 
but I am not able to have information that I seek, therefore I am really 
blocked. I warmly thank you for the assistance which you will be able to 
bring to me.

    Mapping :     0x0000 0000    ->  0x0FFF FFFF   :   RAM
                         0x2000 0000   ->   0x201F FFFF   :   ASIC ( 
UART, DMA, GPIO, PIC...)
                         0x8000 0000   ->   0x8FFF FFFF   :   PCI
                         0xF000 0000   ->   0xFFFF FFFF   :   Flash
    The kernel is load at 0x0, an the system is a Run In Memory. 
Currently, I don't use the flash.


Best regards,
Nicolas MEDERLE

-- 
Cordialement,

Nicolas MEDERLE. 



From laurent.pinchart at technotrade.biz  Thu Jul 12 01:53:39 2007
From: laurent.pinchart at technotrade.biz (Laurent Pinchart)
Date: Wed, 11 Jul 2007 17:53:39 +0200
Subject: PageFault when I write in the Serial registers, MMU ?
In-Reply-To: <4694F9BD.4090406@yahoo.fr>
References: <4694F9BD.4090406@yahoo.fr>
Message-ID: <200707111753.39640.laurent.pinchart@technotrade.biz>

Hi Nicolas,

On Wednesday 11 July 2007 17:39, Nicolas Mederle wrote:
> Hi,
>
>     I am porting linux on a custom board equipped with a PPC750, and I
> will like to have some advices on the MMU. I used the powerpc arch, and
> I built my device tree.
>     I will like to know in which files we can configure the
> authorizations access for the I/O registers. When I use the function
> md_ppc.progress, I have a data access fault. I modified the head. S
> files, for add the BAT config. But I think that it is not correct, and
> that it is possible to do it elsewhere (platform_init?). Moreover the
> kernel modify the MMU config, it removes the BATs, and configures the
> Registers Segments. So, must I remake the configuration? Or is it
> possible to indicate, at the beginning, which space is reserved for I/O?
>     I studied several patch (sandpoint, PrPMC2800) but none configures
> really the MMU for I/O registers. In the same way, I read several books,
> but I am not able to have information that I seek, therefore I am really
> blocked. I warmly thank you for the assistance which you will be able to
> bring to me.
>
>     Mapping :     0x0000 0000    ->  0x0FFF FFFF   :   RAM
>                          0x2000 0000   ->   0x201F FFFF   :   ASIC (
> UART, DMA, GPIO, PIC...)
>                          0x8000 0000   ->   0x8FFF FFFF   :   PCI
>                          0xF000 0000   ->   0xFFFF FFFF   :   Flash
>     The kernel is load at 0x0, an the system is a Run In Memory.
> Currently, I don't use the flash.

You should ioremap() the memory you want to access, and use the I/O access 
functions defined in asm/io.h. Don't forget to iounmap() once you're done.

Best regards,

Laurent Pinchart


From bhupi.saharan at gmail.com  Thu Jul 12 02:32:59 2007
From: bhupi.saharan at gmail.com (Bhupender Saharan)
Date: Wed, 11 Jul 2007 09:32:59 -0700
Subject: PageFault when I write in the Serial registers, MMU ?
In-Reply-To: <4694F9BD.4090406@yahoo.fr>
References: <4694F9BD.4090406@yahoo.fr>
Message-ID: <720399a30707110932n5a4ddb33u552f5b01921f34b5@mail.gmail.com>

Hi,

You could call *io_block_mapping* function from your setup.c file that will
add the entry into MMU.

regards
Bhupi





On 7/11/07, Nicolas Mederle <mederle_nicolas at yahoo.fr> wrote:
>
> Hi,
>
>    I am porting linux on a custom board equipped with a PPC750, and I
> will like to have some advices on the MMU. I used the powerpc arch, and
> I built my device tree.
>    I will like to know in which files we can configure the
> authorizations access for the I/O registers. When I use the function
> md_ppc.progress, I have a data access fault. I modified the head. S
> files, for add the BAT config. But I think that it is not correct, and
> that it is possible to do it elsewhere (platform_init?). Moreover the
> kernel modify the MMU config, it removes the BATs, and configures the
> Registers Segments. So, must I remake the configuration? Or is it
> possible to indicate, at the beginning, which space is reserved for I/O?
>    I studied several patch (sandpoint, PrPMC2800) but none configures
> really the MMU for I/O registers. In the same way, I read several books,
> but I am not able to have information that I seek, therefore I am really
> blocked. I warmly thank you for the assistance which you will be able to
> bring to me.
>
>    Mapping :     0x0000 0000    ->  0x0FFF FFFF   :   RAM
>                         0x2000 0000   ->   0x201F FFFF   :   ASIC (
> UART, DMA, GPIO, PIC...)
>                         0x8000 0000   ->   0x8FFF FFFF   :   PCI
>                         0xF000 0000   ->   0xFFFF FFFF   :   Flash
>    The kernel is load at 0x0, an the system is a Run In Memory.
> Currently, I don't use the flash.
>
>
> Best regards,
> Nicolas MEDERLE
>
> --
> Cordialement,
>
> Nicolas MEDERLE.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070711/d0bf725b/attachment.htm 

From jwboyer at linux.vnet.ibm.com  Thu Jul 12 03:51:00 2007
From: jwboyer at linux.vnet.ibm.com (Josh Boyer)
Date: Wed, 11 Jul 2007 12:51:00 -0500
Subject: PageFault when I write in the Serial registers, MMU ?
In-Reply-To: <720399a30707110932n5a4ddb33u552f5b01921f34b5@mail.gmail.com>
References: <4694F9BD.4090406@yahoo.fr>
	<720399a30707110932n5a4ddb33u552f5b01921f34b5@mail.gmail.com>
Message-ID: <1184176260.32199.77.camel@weaponx.rchland.ibm.com>

On Wed, 2007-07-11 at 09:32 -0700, Bhupender Saharan wrote:
> Hi,
>  
> You could call io_block_mapping function from your setup.c file that
> will add the entry into MMU.

io_block_mapping doesn't exist in the arch/powerpc tree.

josh




From khollan at daktronics.com  Thu Jul 12 05:15:31 2007
From: khollan at daktronics.com (khollan)
Date: Wed, 11 Jul 2007 12:15:31 -0700 (PDT)
Subject: ML410 PCI support
Message-ID: <11547023.post@talk.nabble.com>


I have two questions:
1) Has anyone wrote linux 2.6 PCI drviers for the xilinx development boards. 
I want to get the PCI slots working on my board.
2)How do I set the HwAddr for the TEMAC driver?  Im using Grants latest git
tree.  My board boots and the HwAddr is set to 00:00:00:00:00:00
Thanks for your help
Kevin
-- 
View this message in context: http://www.nabble.com/ML410-PCI-support-tf4064052.html#a11547023
Sent from the linuxppc-embedded mailing list archive at Nabble.com.



From grant.likely at secretlab.ca  Thu Jul 12 06:11:16 2007
From: grant.likely at secretlab.ca (Grant Likely)
Date: Wed, 11 Jul 2007 14:11:16 -0600
Subject: TEMAC MAC address
In-Reply-To: <3D99384DA1D6124CBE9EE993BAA0E5B70195FDFD@exbe-dak-01.daktronics.lan>
References: <3D99384DA1D6124CBE9EE993BAA0E5B70195FDFD@exbe-dak-01.daktronics.lan>
Message-ID: <fa686aa40707111311i42ed56bdiff24d2680b4a8297@mail.gmail.com>

On 7/11/07, Kevin Holland <KHollan at daktronics.com> wrote:
> Grant,
>  How do I set the MAC address?

Badly, with an ugly hack.  :-)

> When my ML410 board boots its Hardware
> address is set to 0.  I looked through the message boards and can't seem
> to find what Im looking for.  Thanks for your help.

I set the mac addr with some Virtex specific code in
arch/ppc/boot/simple/embed_config.c.

BTW, Please at least CC: the mailing list when asking questions.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195


From grant.likely at secretlab.ca  Thu Jul 12 06:38:52 2007
From: grant.likely at secretlab.ca (Grant Likely)
Date: Wed, 11 Jul 2007 14:38:52 -0600
Subject: [PATCH] Setup default eth addr in embed_config for Xilinx Virtex
	platforms
Message-ID: <20070711203852.1839.38604.stgit@trillian>

From: Grant Likely <grant.likely at secretlab.ca>

Signed-off-by: Grant Likely <grant.likely at secretlab.ca>
---

 arch/ppc/boot/simple/embed_config.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/ppc/boot/simple/embed_config.c b/arch/ppc/boot/simple/embed_config.c
index 46676d2..07f1bb5 100644
--- a/arch/ppc/boot/simple/embed_config.c
+++ b/arch/ppc/boot/simple/embed_config.c
@@ -752,7 +752,9 @@ embed_config(bd_t ** bdp)
 	static const unsigned long congruence_classes = 256;
 	unsigned long addr;
 	unsigned long dccr;
+	uint8_t* cp;
 	bd_t *bd;
+	int i;
 
 	/*
 	 * Invalidate the data cache if the data cache is turned off.
@@ -778,6 +780,12 @@ embed_config(bd_t ** bdp)
 	bd->bi_intfreq = XPAR_CORE_CLOCK_FREQ_HZ;
 	bd->bi_busfreq = XPAR_PLB_CLOCK_FREQ_HZ;
 	bd->bi_pci_busfreq = XPAR_PCI_0_CLOCK_FREQ_HZ;
+
+	/* Copy the default ethernet address */
+	cp = (u_char *)def_enet_addr;
+	for (i=0; i<6; i++)
+		bd->bi_enetaddr[i] = *cp++;
+
 	timebase_period_ns = 1000000000 / bd->bi_tbfreq;
 }
 #endif /* CONFIG_XILINX_VIRTEX */


From sureshtang at gmail.com  Thu Jul 12 20:07:08 2007
From: sureshtang at gmail.com (suresh suresh)
Date: Thu, 12 Jul 2007 15:37:08 +0530
Subject: How to access physical memory from user space for MPC8260 chip
Message-ID: <e5eb93010707120307h785bf195n7a649363e4e455f@mail.gmail.com>

Hi,

I have to map physical memory to user space or kernel space. I am writing
driver for MPC8260 chip and I want to know how to map any 32-bit address
space to user space and kernel space.

Please give me some ideas.

Thanks,
Suresh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070712/a028a4e9/attachment.htm 

From stephane.fillod at thomson.net  Thu Jul 12 22:07:52 2007
From: stephane.fillod at thomson.net (Fillod Stephane)
Date: Thu, 12 Jul 2007 14:07:52 +0200
Subject: How to access physical memory from user space for MPC8260 chip
Message-ID: <0B45E93C5FF65740AEAE690BF3848B7A4AB178@rennsmail04.eu.thmulti.com>

suresh suresh wrote:
>I have to map physical memory to user space or kernel space. I am
writing >driver for MPC8260 chip and I want to know how to map any
32-bit address >space to user space and kernel space.

Your question is a linuxppc-embedded FAQ. User-land access is documented

in Denx's FAQ[1], and accessible through shorter URL[2]. For more 
information, please follow this thread[3] (not ppc specific actually).

[1]
http://www.denx.de/twiki/bin/view/PPCEmbedded/DeviceDrivers#Section_Acce
ssingPeripheralsFromUserSpace
[2] http://tinyurl.com/6c7th
[3] http://article.gmane.org/gmane.linux.ports.ppc.embedded/5053

In kernel land, ioremap() is all you need.

Don't forget to use the 'eieio' asm instruction if you want explicit 
I/O ordering.

Best Regards,
-- 
Stephane, the userland ioremap bot


From mederle_nicolas at yahoo.fr  Fri Jul 13 00:30:12 2007
From: mederle_nicolas at yahoo.fr (Nicolas Mederle)
Date: Thu, 12 Jul 2007 16:30:12 +0200
Subject: The kernel source in RAM is covered by data
Message-ID: <46963AF4.7030209@yahoo.fr>

Hi,

    I have port Linux on a PowerPc board. I have the following problems, 
the kernel source is covered by data.
For example, after the kernel unzip by the loader, I have this mapping :
                   _start:
00000000: nop
00000004: nop
00000008: nop
                   __start:
0000000c: mr      r31,r3
00000010: mr      r30,r4
00000014: li      r24,0
00000018: bl      early_init
0000001c: bl      mmu_off
                   __after_mmu_off:
00000020: bl      clear_bats
00000024: bl      flush_tlbs
00000028: bl      initial_bats
0000002c: bl      setup_disp_bat
00000030: bl      reloc_offset

When the kernel launch the init process, I have an PageFault error. And 
the mapping is the following :
                   _start:
00000000: .long   0
00000004: .long   0xB0
00000008: .long   0x67DC28
                   __start:
0000000c: .long   0x3C5FD0
00000010: .long   0x1031C
00000014: .long   0x8001032
00000018: .long   0
0000001c:  .long   4
                   __after_mmu_off:
00000020: .long   1
00000024: .long   0x10590
00000028: .long   0x1032
0000002c: .long   0x1031C
00000030: .long   0x320000

Why the kernel space is modified? I have forgot a config in the kernel 
config? the advanced setup kernel config is the following :
    CONFIG_ADVANCED_OPTIONS=y
    CONFIG_HIGHMEM_START=0xfe000000
    CONFIG_LOWMEM_SIZE_BOOL=y
    CONFIG_LOWMEM_SIZE=0x30000000
    CONFIG_KERNEL_START_BOOL=y
    CONFIG_KERNEL_START=0x0
    # CONFIG_TASK_SIZE_BOOL is not set
    CONFIG_TASK_SIZE=0x80000000
    CONFIG_BOOT_LOAD_BOOL=y
    CONFIG_BOOT_LOAD=0x00400000

Thanks for your feedback,
Nicolas MEDERLE.

-- 
Cordialement,

Nicolas MEDERLE. 



From bwaite at irobot.com  Fri Jul 13 00:50:10 2007
From: bwaite at irobot.com (Brian Waite)
Date: Thu, 12 Jul 2007 10:50:10 -0400
Subject: [kernel-2.6.19]Marvell GT-64260 and Ethernet
In-Reply-To: <4693861F.2000403@genesi-usa.com>
References: <13b81f0c0707092336r5c7f4996u6f9c73d95c63bdc6@mail.gmail.com>
	<4693861F.2000403@genesi-usa.com>
Message-ID: <200707121050.10967.bwaite@irobot.com>

On Tuesday 10 July 2007, Matt Sealey wrote:
> Isn't the ethernet the same on the 64260, 64360, 64460?
>
> There's definitely a driver for 6436x and above..

There was some work done back in the early 2.6 timeframe to make a unified 
360/260 driver. I worked on in a while ago (2+ years) I think the reason you 
don't see it in the tree, is because we all stopped using the 260 and went to 
the 360 as fast as possible. 
gt64260_eth.c ill not jus work. A lot of work (Mark Greer etc) was done in 
refactoring most of the Marvell support from 2.4->2.6. You might get away 
with setting up the platfrom correctly for the 260. Check out the ppc/syslib 
directory. You might find some clues there,


Thanks
Brian


From laurentp at cse-semaphore.com  Fri Jul 13 01:07:31 2007
From: laurentp at cse-semaphore.com (Laurent Pinchart)
Date: Thu, 12 Jul 2007 17:07:31 +0200
Subject: [PATCH] [POWERPC] Move generic MPC82xx functions out of
	ADS-specific
In-Reply-To: <4694F66D.2010907@freescale.com>
References: <200707101312.46052.laurent.pinchart@technotrade.biz>
	<200707110928.55339.laurent.pinchart@technotrade.biz>
	<4694F66D.2010907@freescale.com>
Message-ID: <200707121707.31208.laurentp@cse-semaphore.com>

Hi Scott,

On Wednesday 11 July 2007 17:25, Scott Wood wrote:
> Laurent Pinchart wrote:
> > On Tuesday 10 July 2007 20:05, Scott Wood wrote:
> >>Why are you also moving mpc82xx_ads_show_cpuinfo() to the board file?
> >>It's not really ADS-specific; it should just be renamed.
> >
> > For the MPC82xx ADS boards, mpc82xx_ads_show_cpuinfo() prints
> >
> > Vendor              : Freescale Semiconductor
> > Machine             : PQ2 ADS PowerPC
> >
> > The vendor string is hardcoded to "Freescale Semiconductor", and the
> > machine string is defined in pq2ads.h. What should show_cpuinfo() print ?
> > Should the vendor be the board vendor or the CPU vendor ? What about the
> > machine ?
>
> Ah, I missed that.  I'd just get rid of "Vendor" altogether, and include
> the vendor name in the machine name.

Is there any standard/documentation regarding what show_cpuinfo should print ? 
Should it show CPU information only, or board information as well ? What 
about the memory size, clock settings, ... ? What are the meanings 
of "vendor" and "machine" ?

-- 
Laurent Pinchart
CSE Semaphore Belgium


From laurent.pinchart at cse-semaphore.com  Fri Jul 13 00:57:50 2007
From: laurent.pinchart at cse-semaphore.com (Laurent Pinchart)
Date: Thu, 12 Jul 2007 16:57:50 +0200
Subject: [PATCH] [POWERPC] Move generic MPC82xx functions out of
	ADS-specific
In-Reply-To: <4694F66D.2010907@freescale.com>
References: <200707101312.46052.laurent.pinchart@technotrade.biz>
	<200707110928.55339.laurent.pinchart@technotrade.biz>
	<4694F66D.2010907@freescale.com>
Message-ID: <200707121657.51214.laurent.pinchart@cse-semaphore.com>

Hi Scott,

On Wednesday 11 July 2007 17:25, Scott Wood wrote:
> Laurent Pinchart wrote:
> > On Tuesday 10 July 2007 20:05, Scott Wood wrote:
> >>Why are you also moving mpc82xx_ads_show_cpuinfo() to the board file?
> >>It's not really ADS-specific; it should just be renamed.
> >
> > For the MPC82xx ADS boards, mpc82xx_ads_show_cpuinfo() prints
> >
> > Vendor		: Freescale Semiconductor
> > Machine		: PQ2 ADS PowerPC
> >
> > The vendor string is hardcoded to "Freescale Semiconductor", and the
> > machine string is defined in pq2ads.h. What should show_cpuinfo() print ?
> > Should the vendor be the board vendor or the CPU vendor ? What about the
> > machine ?
>
> Ah, I missed that.  I'd just get rid of "Vendor" altogether, and include
> the vendor name in the machine name.

Is there any standard/documentation regarding what show_cpuinfo should print ? 
Should it show CPU information only, or board information as well ? What 
about the memory size, clock settings, ... ? What are the meanings 
of "vendor" and "machine" ?

-- 
Laurent Pinchart
CSE Semaphore Belgium


From laurent.pinchart at cse-semaphore.com  Fri Jul 13 01:04:45 2007
From: laurent.pinchart at cse-semaphore.com (Laurent Pinchart)
Date: Thu, 12 Jul 2007 17:04:45 +0200
Subject: [PATCH] [POWERPC] Move generic MPC82xx functions out of
	ADS-specific
In-Reply-To: <4694F66D.2010907@freescale.com>
References: <200707101312.46052.laurent.pinchart@technotrade.biz>
	<200707110928.55339.laurent.pinchart@technotrade.biz>
	<4694F66D.2010907@freescale.com>
Message-ID: <200707121704.45373.laurent.pinchart@cse-semaphore.com>

Hi Scott,

On Wednesday 11 July 2007 17:25, Scott Wood wrote:
> Laurent Pinchart wrote:
> > On Tuesday 10 July 2007 20:05, Scott Wood wrote:
> >>Why are you also moving mpc82xx_ads_show_cpuinfo() to the board file?
> >>It's not really ADS-specific; it should just be renamed.
> >
> > For the MPC82xx ADS boards, mpc82xx_ads_show_cpuinfo() prints
> >
> > Vendor		: Freescale Semiconductor
> > Machine		: PQ2 ADS PowerPC
> >
> > The vendor string is hardcoded to "Freescale Semiconductor", and the
> > machine string is defined in pq2ads.h. What should show_cpuinfo() print ?
> > Should the vendor be the board vendor or the CPU vendor ? What about the
> > machine ?
>
> Ah, I missed that.  I'd just get rid of "Vendor" altogether, and include
> the vendor name in the machine name.

Is there any standard/documentation regarding what show_cpuinfo should print ? 
Should it show CPU information only, or board information as well ? What 
about the memory size, clock settings, ... ? What are the meanings 
of "vendor" and "machine" ?

-- 
Laurent Pinchart
CSE Semaphore Belgium


From joseph.robertson at sanmina-sci.com  Fri Jul 13 04:03:03 2007
From: joseph.robertson at sanmina-sci.com (Robertson, Joseph M.)
Date: Thu, 12 Jul 2007 13:03:03 -0500
Subject: XSysAce driver cant mount DOS part
Message-ID: <939D37AEB47F1F49B88FAB6599B6023501A17205@hsv1dafpew02.das.gov.sanm.corp>

Hi all,

I've been workig with this for a while but have made no progress.
Today I got the latest XSysAce patch for kernel 2.6.17.1 and applied it to get clean code.  
I inherited the previous code from another developer.

My problem is that mounting the DOS partition always fails in a short time with a kernel oops.

ECAU-9999:# Oops: kernel access of bad area, sig: 11 [#1]                       
PREEMPT                                                                         
NIP: C00701C8 LR: C0070C18 CTR: 00000000                                        
REGS: c0391dd0 TRAP: 0300   Not tainted  (2.6.17.1)                             
MSR: 00021030 <ME,IR,DR>  CR: 22028082  XER: 0000000B                           
DAR: 00000000, DSISR: 00800000                                                  
TASK = c0373030[4] 'events/0' THREAD: c0390000                                  
GPR00: 00000080 C0391E80 C0373030 C02CAC00 C0E03000 C0E03154 00000000 C02CAC00  
GPR08: 00200200 00000000 00100100 00000000 00051A4B FFFFDE60 03BD4900 007FFF3B  
GPR16: 00400000 00000001 FFFFFFFF 03BCDC58 00000000 007FFF00 00000002 C0280000  
GPR24: C0363A10 0000000B 00000000 00000000 00000000 C02CAC00 C035ED20 C0E03000  
NIP [C00701C8] free_block+0x8c/0x138                                            
LR [C0070C18] drain_array+0xb8/0x124                                            
Call Trace:                                   

The setup:
My own build system.
Kernel 2.6.17.1 with lots of xilinx stuff, eth, i2c, xsysace.  Crosscompiled for PPC405.
Latest, clean XSysAce code.  mods:  major hardcoded to = 125.  Polled mode.
CF:  3 partitions,
1:  DOS FAT16
2:  Ext2  main
3:  Ext2  rescue

This build boots up fine, mounts a ext2 as root fine.  I can also mount the rescue partition with no problems.

Does anyone have any pointers of where I should look for problems?

My next step is to go and set it up for interrupt service and see if that changes anything.
 
Thanks,

Joe Robertson
Joseph.Robertson at sanmina-sci.com


CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited.  If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING.  Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), or any other person or entity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070712/ca55899b/attachment.htm 

From grant.likely at secretlab.ca  Fri Jul 13 04:16:12 2007
From: grant.likely at secretlab.ca (Grant Likely)
Date: Thu, 12 Jul 2007 12:16:12 -0600
Subject: XSysAce driver cant mount DOS part
In-Reply-To: <939D37AEB47F1F49B88FAB6599B6023501A17205@hsv1dafpew02.das.gov.sanm.corp>
References: <939D37AEB47F1F49B88FAB6599B6023501A17205@hsv1dafpew02.das.gov.sanm.corp>
Message-ID: <fa686aa40707121116l1d76078aq82926eb861720474@mail.gmail.com>

On 7/12/07, Robertson, Joseph M. <joseph.robertson at sanmina-sci.com> wrote:
>
>  I've been workig with this for a while but have made no progress.
>  Today I got the latest XSysAce patch for kernel 2.6.17.1 and applied it to
> get clean code.
>  I inherited the previous code from another developer.

Who's tree are you using?  Montavistas?  Mainline?

Which sysace driver are you using?  The old one from Xilinx or the new one?

>
>  My problem is that mounting the DOS partition always fails in a short time
> with a kernel oops.
>
>  ECAU-9999:# Oops: kernel access of bad area, sig: 11 [#1]
>
>  PREEMPT
---8<---snip--->8---
>  LR [C0070C18] drain_array+0xb8/0x124
>
>  Call Trace:

Did you trim off the call trace?  The call trace is pretty useful for
figuring out what happened.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195


From jeff at theptrgroup.com  Fri Jul 13 04:26:40 2007
From: jeff at theptrgroup.com (Jeff Angielski)
Date: Thu, 12 Jul 2007 14:26:40 -0400
Subject: XSysAce driver cant mount DOS part
In-Reply-To: <939D37AEB47F1F49B88FAB6599B6023501A17205@hsv1dafpew02.das.gov.sanm.corp>
References: <939D37AEB47F1F49B88FAB6599B6023501A17205@hsv1dafpew02.das.gov.sanm.corp>
Message-ID: <1184264800.22249.17.camel@jaalaptop>

On Thu, 2007-07-12 at 13:03 -0500, Robertson, Joseph M. wrote:
> Hi all,
> 
> I've been workig with this for a while but have made no progress.
> Today I got the latest XSysAce patch for kernel 2.6.17.1 and applied
> it to get clean code. 
> I inherited the previous code from another developer.
> 
> My problem is that mounting the DOS partition always fails in a short
> time with a kernel oops.

Can you access that partition on your Linux host using a CF adapter?

Can you access that partition from the uboot prompt?

How did you format that partition?  mkfs.msdos?


-- 
Jeff Angielski
The PTR Group
www.theptrgroup.com



From joseph.robertson at sanmina-sci.com  Fri Jul 13 04:53:20 2007
From: joseph.robertson at sanmina-sci.com (Robertson, Joseph M.)
Date: Thu, 12 Jul 2007 13:53:20 -0500
Subject: XSysAce driver cant mount DOS part
References: <939D37AEB47F1F49B88FAB6599B6023501A17205@hsv1dafpew02.das.gov.sanm.corp>
	<fa686aa40707121116l1d76078aq82926eb861720474@mail.gmail.com>
Message-ID: <939D37AEB47F1F49B88FAB6599B6023501A17206@hsv1dafpew02.das.gov.sanm.corp>

Hi!

Wow, quick replies.

RE: Tree.  
Its the mainline 2.6.17.1, with
denx ppc patches from 4.0.0?  IIRC.
I redid the patch set for the xsysace to get a known baseline.
Its a custom build system, which I developed over the years, ported to use a ppc405 crosscompiler I made from
CrossTool-0.42. Its very similar to uClinux, but with a simpler config system.
The compiler is gcc.3.4.1 with glibc 2.3.3 (yeah we use glibc).

The XsysAce patch is in the normal place, only change I made was to define the major number.
And I moved xbasic_types.c/h to another folder onthe path since xilinx_iic drivers uses it too, and I was getting redefine errors.
One thing I just thought of was I did not run the 'normal' config stuff, any deps in there?
I can go look at the kconfigs and see.

RE: Xilinx SysAce driver
The HW group used Xilinx env 8.2.02i, and the project shows Sysace_compactflash driver:  sysace_v1_01_a

The HW is a Virtex-4 with the embedded ppc405.  The Xsysace chip is supposed tobe using irq_intr = 2.

The system actually works fine using the Ext2 fs, but if we want to upgrade the fpga code, I need to be able to write to the dos part.

Thanks so much.


Joe Robertson
Joseph.Robertson at sanmina-sci.com





-----Original Message-----
From: glikely at secretlab.ca on behalf of Grant Likely
Sent: Thu 7/12/2007 1:16 PM
To: Robertson, Joseph M.
Cc: linuxppc-embedded at ozlabs.org
Subject: Re: XSysAce driver cant mount DOS part
 
On 7/12/07, Robertson, Joseph M. <joseph.robertson at sanmina-sci.com> wrote:
>
>  I've been workig with this for a while but have made no progress.
>  Today I got the latest XSysAce patch for kernel 2.6.17.1 and applied it to
> get clean code.
>  I inherited the previous code from another developer.

Who's tree are you using?  Montavistas?  Mainline?

Which sysace driver are you using?  The old one from Xilinx or the new one?

>
>  My problem is that mounting the DOS partition always fails in a short time
> with a kernel oops.
>
>  ECAU-9999:# Oops: kernel access of bad area, sig: 11 [#1]
>
>  PREEMPT
---8<---snip--->8---
>  LR [C0070C18] drain_array+0xb8/0x124
>
>  Call Trace:

Did you trim off the call trace?  The call trace is pretty useful for
figuring out what happened.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195




CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited.  If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING.  Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), or any other person or entity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070712/0e111a8a/attachment.htm 

From grant.likely at secretlab.ca  Fri Jul 13 05:06:26 2007
From: grant.likely at secretlab.ca (Grant Likely)
Date: Thu, 12 Jul 2007 13:06:26 -0600
Subject: XSysAce driver cant mount DOS part
In-Reply-To: <939D37AEB47F1F49B88FAB6599B6023501A17206@hsv1dafpew02.das.gov.sanm.corp>
References: <939D37AEB47F1F49B88FAB6599B6023501A17205@hsv1dafpew02.das.gov.sanm.corp>
	<fa686aa40707121116l1d76078aq82926eb861720474@mail.gmail.com>
	<939D37AEB47F1F49B88FAB6599B6023501A17206@hsv1dafpew02.das.gov.sanm.corp>
Message-ID: <fa686aa40707121206n7e75e770q742adb3659f35e79@mail.gmail.com>

On 7/12/07, Robertson, Joseph M. <joseph.robertson at sanmina-sci.com> wrote:
>  RE: Tree.
>  Its the mainline 2.6.17.1, with
>  denx ppc patches from 4.0.0?  IIRC.
>  I redid the patch set for the xsysace to get a known baseline.
>  Its a custom build system, which I developed over the years, ported to use
> a ppc405 crosscompiler I made from
>  CrossTool-0.42. Its very similar to uClinux, but with a simpler config
> system.
>  The compiler is gcc.3.4.1 with glibc 2.3.3 (yeah we use glibc).

Heh, so do I.  So do a lot of people.  glibc *is* for embedded
systems, regardless of what some may say.  :-)

>  The XsysAce patch is in the normal place, only change I made was to define
> the major number.
>  And I moved xbasic_types.c/h to another folder onthe path since xilinx_iic
> drivers uses it too, and I was getting redefine errors.
>  One thing I just thought of was I did not run the 'normal' config stuff,
> any deps in there?
>  I can go look at the kconfigs and see.
>
>  RE: Xilinx SysAce driver
>  The HW group used Xilinx env 8.2.02i, and the project shows
> Sysace_compactflash driver:  sysace_v1_01_a

Okay, so that's the old driver.  There is a new driver that has
considerably better performance which you might want to try; but it
doesn't support insertion/removal yet.  It is about to be pulled into
mainline, but you can get it here too:

http://article.gmane.org/gmane.linux.kernel/526293/match=xsysace+c

>
>  The HW is a Virtex-4 with the embedded ppc405.  The Xsysace chip is
> supposed tobe using irq_intr = 2.
>
>  The system actually works fine using the Ext2 fs, but if we want to upgrade
> the fpga code, I need to be able to write to the dos part.

2.6.17 is rather old.  You might be hitting an old bug.  Virtex
support in the newer kernels is significantly better.  Have you
considered upgrading?  I've got a bunch of patches in my git tree that
add the TEMAC and other drivers to a more recent kernel.  My internal
tree is based on 2.6.22; I'll try to update my external tree to match
in the next day or so:

http://git.secretlab.ca/cgi-bin/gitweb.cgi?h=virtex-dev;p=linux-2.6.git;a=shortlog

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195


From joseph.robertson at sanmina-sci.com  Fri Jul 13 05:10:34 2007
From: joseph.robertson at sanmina-sci.com (Robertson, Joseph M.)
Date: Thu, 12 Jul 2007 14:10:34 -0500
Subject: XSysAce driver cant mount DOS part
References: <939D37AEB47F1F49B88FAB6599B6023501A17205@hsv1dafpew02.das.gov.sanm.corp>
	<1184264800.22249.17.camel@jaalaptop>
Message-ID: <939D37AEB47F1F49B88FAB6599B6023501A17207@hsv1dafpew02.das.gov.sanm.corp>

See answers to queries below.

Thanks,
Joe Robertson
Joseph.Robertson at sanmina-sci.com




-----Original Message-----
From: Jeff Angielski [mailto:jeff at theptrgroup.com]
Sent: Thu 7/12/2007 1:26 PM
To: Robertson, Joseph M.
Cc: linuxppc-embedded at ozlabs.org
Subject: Re: XSysAce driver cant mount DOS part
 
On Thu, 2007-07-12 at 13:03 -0500, Robertson, Joseph M. wrote:
> Hi all,
> 
> I've been workig with this for a while but have made no progress.
> Today I got the latest XSysAce patch for kernel 2.6.17.1 and applied
> it to get clean code. 
> I inherited the previous code from another developer.
> 
> My problem is that mounting the DOS partition always fails in a short
> time with a kernel oops.

Can you access that partition on your Linux host using a CF adapter?

 Yes.

Can you access that partition from the uboot prompt?

 Dunno, I don't think I have uboot set to let me do that.
 precompiled setup, I'd have to work on it.
 
How did you format that partition?  mkfs.msdos?

  Yes, mkdosfs -F 16 /dev/sda1  (its a fat16, 32Mb partition)




-- 
Jeff Angielski
The PTR Group
www.theptrgroup.com





CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited.  If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING.  Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), or any other person or entity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070712/c7e1a5de/attachment.htm 

From joseph.robertson at sanmina-sci.com  Fri Jul 13 05:17:09 2007
From: joseph.robertson at sanmina-sci.com (Robertson, Joseph M.)
Date: Thu, 12 Jul 2007 14:17:09 -0500
Subject: XSysAce driver cant mount DOS part
References: <939D37AEB47F1F49B88FAB6599B6023501A17205@hsv1dafpew02.das.gov.sanm.corp><fa686aa40707121116l1d76078aq82926eb861720474@mail.gmail.com><939D37AEB47F1F49B88FAB6599B6023501A17206@hsv1dafpew02.das.gov.sanm.corp>
	<fa686aa40707121206n7e75e770q742adb3659f35e79@mail.gmail.com>
Message-ID: <939D37AEB47F1F49B88FAB6599B6023501A17208@hsv1dafpew02.das.gov.sanm.corp>

Hi,

I will try the new code you suggest.  We are not supporting CF changes at all (factory only).


RE: 2.6.17.1 being old. 
Well, old is relative.  Once this works, and its 99% there, we won't change it.
We'll probably be using this kernel for 3-5 years.
In fact, at this point we've got 2.5 years invested, and about 4 months of testing already, so changing now is bad.
That would mean I have to retest a whole bunch of stuff.

Thanks,
Joe Robertson
Joseph.Robertson at sanmina-sci.com



-----Original Message-----
From: glikely at secretlab.ca on behalf of Grant Likely
Sent: Thu 7/12/2007 2:06 PM
To: Robertson, Joseph M.
Cc: linuxppc-embedded at ozlabs.org
Subject: Re: XSysAce driver cant mount DOS part
 
On 7/12/07, Robertson, Joseph M. <joseph.robertson at sanmina-sci.com> wrote:
>  RE: Tree.
>  Its the mainline 2.6.17.1, with
>  denx ppc patches from 4.0.0?  IIRC.
>  I redid the patch set for the xsysace to get a known baseline.
>  Its a custom build system, which I developed over the years, ported to use
> a ppc405 crosscompiler I made from
>  CrossTool-0.42. Its very similar to uClinux, but with a simpler config
> system.
>  The compiler is gcc.3.4.1 with glibc 2.3.3 (yeah we use glibc).

Heh, so do I.  So do a lot of people.  glibc *is* for embedded
systems, regardless of what some may say.  :-)

>  The XsysAce patch is in the normal place, only change I made was to define
> the major number.
>  And I moved xbasic_types.c/h to another folder onthe path since xilinx_iic
> drivers uses it too, and I was getting redefine errors.
>  One thing I just thought of was I did not run the 'normal' config stuff,
> any deps in there?
>  I can go look at the kconfigs and see.
>
>  RE: Xilinx SysAce driver
>  The HW group used Xilinx env 8.2.02i, and the project shows
> Sysace_compactflash driver:  sysace_v1_01_a

Okay, so that's the old driver.  There is a new driver that has
considerably better performance which you might want to try; but it
doesn't support insertion/removal yet.  It is about to be pulled into
mainline, but you can get it here too:

http://article.gmane.org/gmane.linux.kernel/526293/match=xsysace+c

>
>  The HW is a Virtex-4 with the embedded ppc405.  The Xsysace chip is
> supposed tobe using irq_intr = 2.
>
>  The system actually works fine using the Ext2 fs, but if we want to upgrade
> the fpga code, I need to be able to write to the dos part.

2.6.17 is rather old.  You might be hitting an old bug.  Virtex
support in the newer kernels is significantly better.  Have you
considered upgrading?  I've got a bunch of patches in my git tree that
add the TEMAC and other drivers to a more recent kernel.  My internal
tree is based on 2.6.22; I'll try to update my external tree to match
in the next day or so:

http://git.secretlab.ca/cgi-bin/gitweb.cgi?h=virtex-dev;p=linux-2.6.git;a=shortlog

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195


CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited.  If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING.  Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), or any other person or entity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070712/38d1d4d7/attachment.htm 

From joseph.robertson at sanmina-sci.com  Fri Jul 13 05:49:39 2007
From: joseph.robertson at sanmina-sci.com (Robertson, Joseph M.)
Date: Thu, 12 Jul 2007 14:49:39 -0500
Subject: XSysAce driver cant mount DOS part
References: <939D37AEB47F1F49B88FAB6599B6023501A17205@hsv1dafpew02.das.gov.sanm.corp><fa686aa40707121116l1d76078aq82926eb861720474@mail.gmail.com><939D37AEB47F1F49B88FAB6599B6023501A17206@hsv1dafpew02.das.gov.sanm.corp>
	<fa686aa40707121206n7e75e770q742adb3659f35e79@mail.gmail.com>
Message-ID: <939D37AEB47F1F49B88FAB6599B6023501A17209@hsv1dafpew02.das.gov.sanm.corp>

Hi,

Ok this is surely enough to drive you nuts, but all I get is an error.
How the heck do you debug patch?  All I get is this.

root at tocnet_ws_9:/mnt/public2/ecau/src/linux/linux-2.6.17.1# patch -p1 -un  -i xsys.patch 
patch unexpectedly ends in middle of line
patch: **** Only garbage was found in the patch input.

I copied the text from the htmlpage and pasted to a file.
Its very weird to me, I've never seen that.  A line number would be nice.


Joe Robertson
x8259
Joseph.Robertson at sanmina-sci.com

CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited.  If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING.  Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), or any other person or entity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070712/671b78b1/attachment.htm 

From grant.likely at secretlab.ca  Fri Jul 13 08:51:04 2007
From: grant.likely at secretlab.ca (Grant Likely)
Date: Thu, 12 Jul 2007 16:51:04 -0600
Subject: XSysAce driver cant mount DOS part
In-Reply-To: <939D37AEB47F1F49B88FAB6599B6023501A17209@hsv1dafpew02.das.gov.sanm.corp>
References: <939D37AEB47F1F49B88FAB6599B6023501A17205@hsv1dafpew02.das.gov.sanm.corp>
	<fa686aa40707121116l1d76078aq82926eb861720474@mail.gmail.com>
	<939D37AEB47F1F49B88FAB6599B6023501A17206@hsv1dafpew02.das.gov.sanm.corp>
	<fa686aa40707121206n7e75e770q742adb3659f35e79@mail.gmail.com>
	<939D37AEB47F1F49B88FAB6599B6023501A17209@hsv1dafpew02.das.gov.sanm.corp>
Message-ID: <fa686aa40707121551i7b123818i94423c386f58a5bb@mail.gmail.com>

On 7/12/07, Robertson, Joseph M. <joseph.robertson at sanmina-sci.com> wrote:
> Hi,
>
>  Ok this is surely enough to drive you nuts, but all I get is an error.
>  How the heck do you debug patch?  All I get is this.
>
> root at tocnet_ws_9:/mnt/public2/ecau/src/linux/linux-2.6.17.1#
> patch -p1 -un  -i xsys.patch
>  patch unexpectedly ends in middle of line
>  patch: **** Only garbage was found in the patch input.

The Gmane web view mangles patches.  You can use an NNTP client to
talk to gmane to get them without mangling.

But to keep things simple, I'll just email you the patch.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195


From vikramkone at gmail.com  Fri Jul 13 08:57:32 2007
From: vikramkone at gmail.com (Vikram Kone)
Date: Thu, 12 Jul 2007 15:57:32 -0700
Subject: Help required for porting ISP1362 usb device driver
Message-ID: <003d01c7c4d8$07ea3cc0$66dd47ab@cisco.com>

Hi..
I'm a linux newbie and im working on porting the USB driver ISP1362 by
Philips on to my Freescale ppc board.
I dont know how to do this... so if any of you can tell me how to do this
step by step, i would be very grateful to you
 
Few details..
I'm running RHEL with kernel 2.4.21 on a PC (i386 machine)
Target Machine is MPC8548 CDS by Free scale (ppc architecture) running
kernel version 2.6.11
 
I do have a ppc tool chain, if that helps.....but i dont know how to use it 
 
Thanks
 
P.S. I downloaded the deive driver and host controller drivers from
sourceforge.net and both of them seem to work for 2.6.6 kernel for i386 arch
..
 
P.P.S : Wolfgang ??!1 Can you help me out... I went through the archives on
the list and seems thatu answered many Qs on this driver. But i didnt find
any post specifcally for my problem..so
 
??? 

  <http://www.cisco.com/global/EMEA/brand/signature/default/spacer.gif>


Vikram Kone
College Intern
EWTG GSBU

vkone at cisco.com
Phone :+1 408 853 8916
Mobile :+1 919 457 8792


Cisco Systems, Inc.
170 West Tasman Drive,
San Jose, CA 95134-1706
USA
www.cisco.com <http://www.cisco.com/> 

 	
  <http://www.cisco.com/global/EMEA/brand/signature/default/footerHead.gif>

This e-mail may contain confidential and privileged material for the sole
use of the intended recipient. Any review, use, distribution or disclosure
by others is strictly prohibited. If you are not the intended recipient (or
authorized to receive for the recipient), please contact the sender by reply
e-mail and delete all copies of this message.	

  <http://www.cisco.com/global/EMEA/brand/signature/default/footer.gif> 


 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070712/429bf109/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 51 bytes
Desc: not available
Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070712/429bf109/attachment.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 68 bytes
Desc: not available
Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070712/429bf109/attachment-0001.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 347 bytes
Desc: not available
Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070712/429bf109/attachment-0002.gif 

From vkone at cisco.com  Fri Jul 13 08:56:47 2007
From: vkone at cisco.com (Vikram Kone (vkone))
Date: Thu, 12 Jul 2007 15:56:47 -0700
Subject: Help required on porting ISP1362 driver to ppc 
Message-ID: <C99477645D09FA43ADF9A3B8874E7E7703DA68C9@xmb-sjc-21c.amer.cisco.com>

Hi..
I'm a linux newbie and im working on porting the USB driver ISP1362 by Philips on to my Freescale ppc board.
I dont know how to do this... so if any of you can tell me how to do this step by step, i would be very grateful to you
 
Few details..
I'm running RHEL with kernel 2.4.21 on a PC (i386 machine)
Target Machine is MPC8548 CDS by Free scale (ppc architecture) running kernel version 2.6.11
 
I do have a ppc tool chain, if that helps.....but i dont know how to use it 
 
Thanks
 
P.S. I downloaded the deive driver and host controller drivers from sourceforge.net and both of them seem to work for 2.6.6 kernel for i386 arch ..
 
P.P.S : Wolfgang ??!1 Can you help me out... I went through the archives on the list and seems thatu answered many Qs on this driver. But i didnt find any post specifcally for my problem..so
 
??? 
 	
Vikram Kone
College Intern
EWTG GSBU

vkone at cisco.com
Phone :+1 408 853 8916
Mobile :+1 919 457 8792


Cisco Systems, Inc.
170 West Tasman Drive,
San Jose, CA 95134-1706
USA
www.cisco.com <http://www.cisco.com/> 

 	
 	
This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message.	
 


 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070712/392db684/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 51 bytes
Desc: spacer.gif
Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070712/392db684/attachment.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 68 bytes
Desc: footerHead.gif
Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070712/392db684/attachment-0001.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 347 bytes
Desc: footer.gif
Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070712/392db684/attachment-0002.gif 

From arnd at arndb.de  Fri Jul 13 09:59:40 2007
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 13 Jul 2007 01:59:40 +0200
Subject: [PATCH] [POWERPC] Move generic MPC82xx functions out of
	ADS-specific
In-Reply-To: <200707121704.45373.laurent.pinchart@cse-semaphore.com>
References: <200707101312.46052.laurent.pinchart@technotrade.biz>
	<4694F66D.2010907@freescale.com>
	<200707121704.45373.laurent.pinchart@cse-semaphore.com>
Message-ID: <200707130159.40394.arnd@arndb.de>

On Thursday 12 July 2007, Laurent Pinchart wrote:
> > Ah, I missed that. ?I'd just get rid of "Vendor" altogether, and include
> > the vendor name in the machine name.
> 
> Is there any standard/documentation regarding what show_cpuinfo should print ? 
> Should it show CPU information only, or board information as well ? What 
> about the memory size, clock settings, ... ? What are the meanings 
> of "vendor" and "machine" ?

I guess the easiest would be to modify the common show_cpuinfo function
to fall back to just printing the model, if there is no specific function:

--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -175,6 +175,12 @@ static int show_cpuinfo(struct seq_file *m, void *v)
 			seq_printf(m, "platform\t: %s\n", ppc_md.name);
 		if (ppc_md.show_cpuinfo != NULL)
 			ppc_md.show_cpuinfo(m);
+		else {
+			struct device_node *root = of_find_node_by_path("/");
+			const char *model = of_get_property(root, "model", NULL);
+			seq_printf(m, "machine\t\t: %s\n", model);
+			of_node_put(root);
+		}
 
 		return 0;
 	}

With that in place, we can probably get rid of half the platform
specific show_cpuinfo functions.

	Arnd <><


From dhlii at dlasys.net  Fri Jul 13 13:57:19 2007
From: dhlii at dlasys.net (David H. Lynch Jr.)
Date: Thu, 12 Jul 2007 23:57:19 -0400
Subject: TEMAC MAC address
In-Reply-To: <fa686aa40707111311i42ed56bdiff24d2680b4a8297@mail.gmail.com>
References: <3D99384DA1D6124CBE9EE993BAA0E5B70195FDFD@exbe-dak-01.daktronics.lan>
	<fa686aa40707111311i42ed56bdiff24d2680b4a8297@mail.gmail.com>
Message-ID: <4696F81F.2040200@dlasys.net>

Grant Likely wrote:
> On 7/11/07, Kevin Holland <KHollan at daktronics.com> wrote:
>   
>> Grant,
>>  How do I set the MAC address?
>>     
>
> Badly, with an ugly hack.  :-)
>
>   
>> When my ML410 board boots its Hardware
>> address is set to 0.  I looked through the message boards and can't seem
>> to find what Im looking for.  Thanks for your help.
>>     
>
> I set the mac addr with some Virtex specific code in
> arch/ppc/boot/simple/embed_config.c.
>
> BTW, Please at least CC: the mailing list when asking questions.
>   

Pico cards pass the MAC address to linux via the board info struct -
doesn't uboot etc.
have a similar facility ?

Pico registered a block of MAC addresses, uses them as card serial
numbers and passes them via
board info.


-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii at dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 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



From dhlii at dlasys.net  Fri Jul 13 14:10:46 2007
From: dhlii at dlasys.net (David H. Lynch Jr.)
Date: Fri, 13 Jul 2007 00:10:46 -0400
Subject: TEMAC driver available
Message-ID: <4696FB46.3020103@dlasys.net>

    I have finally been inspired to complete my TEMAC driver to an alpha
state.
    It nearly required dynamite - I had a client application where the
Xilinx/MV TEMAC
    just did not work.

    Anyway, the sucker is done and I guess I will post it as soon as I
have leaned it up
    if there is any interest.

    A brief description:
          Might optionally (as in used to badly) support the LL_TEMAC.
          Supports the more common PLB TEMAC ONLY in FIFO configurations.
          Autonegotiates.
          Is a reasonable approximation to a normal Linux network driver.
             i.e. does not require xilinx_comon, or xilinx_edk or .....
           Aside from hooks into the Linux build system is entirely
contained
          in a single reasonably sized source.
          Is extremely loosely based on older xilinx code from their
Webserver
          sample application.

    For someone that desparately wants to see it immediately you can
download
    http://www.picocomputing.com/files/linux/linux-2.6-pico.tar.bz2
    but that is a complete 2.6.22-rc4 kernel.org linux source with the
complete
    Pico BSP
         
      

-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii at dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 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



From silicom at 163.com  Fri Jul 13 15:22:54 2007
From: silicom at 163.com (silicom)
Date: Fri, 13 Jul 2007 13:22:54 +0800 (CST)
Subject: can anyone help me to test my ac97 driver
Message-ID: <165516780.1952051184304174471.JavaMail.coremail@bj163app130.163.com>

 Hi
    I have a simple oss ac97 playback driver for xilinx ml403 and linux2.6.17 kernel,but when I test it with a *.wav file with sample rate 44.1k, there is much noisy, and I want to know whether there's problem with my ml403 board or ac97 driver,could anyone be kind to help me test it on your board or point out my problem?
 
thanks
below is my code "xilinx_ac97_adapter.c"
#include <linux/module.h>
#include <linux/version.h>
#include <linux/string.h>
#include <linux/ctype.h>
#include <linux/ioport.h>
#include <linux/sched.h>
#include <linux/delay.h>
#include <linux/sound.h>
#include <linux/slab.h>
#include <linux/soundcard.h>
#include <asm/io.h>
#include <asm/dma.h>
#include <linux/init.h>
#include <linux/poll.h>
#include <linux/spinlock.h>
#include <linux/smp_lock.h>
#include <linux/sound.h>
#include <linux/ac97_codec.h>
#include <linux/interrupt.h>
#include <linux/irq.h>
#include <linux/signal.h>
//#include <linux/wrapper.h>
#include <asm/uaccess.h>
#include <asm/hardirq.h>
#include "xparameters.h"
#include "xac97_l.h"
#include "xio.h"
#define XILINX_AC97
#define DRIVER_VERSION "1.00a"
#define AC97_BASEADDR XPAR_OPB_AC97_CONTROLLER_REF_0_BASEADDR
#define AC97_HIGHADDR XPAR_OPB_AC97_CONTROLLER_REF_0_HIGHADDR
/* AC97 codec initialisation. */
static struct ac97_codec *xilinx_ac97_codec = NULL;
static int dev_audio = -1;
#define BUFFER_SIZE 32768
#define XILINX_AC97_PLAYBACK_INTERRUPT 7
struct xilinx_ac97_state {
    struct semaphore    open_sem;     /* Device access */
    struct semaphore    sem;             /* File access */
    spinlock_t        lock;        /* State */
    spinlock_t        ac97_lock;
    struct ac97_codec    *ac97;
    char            *buffer;
    int            multichannel;
    int            dsp;         /* OSS handle */
    int                     trigger;    /* mmap I/O trigger */
    int            halfFull;
    //    struct forte_channel    play;
    //    struct forte_channel    rec;
};
static struct xilinx_ac97_state *state;
static int halfEmpty;
static DECLARE_WAIT_QUEUE_HEAD(ac97_queue);
static int emptyTime;
static u16 xilinx_ac97_get(struct ac97_codec *dev, u8 reg);
static void xilinx_ac97_set(struct ac97_codec *dev, u8 reg, u16 data);
static void xilinx_ac97_codec_wait(struct ac97_codec *dev);
static irqreturn_t xilinx_ac97_interrupt(int irq, void * dev_id, struct pt_regs *regs)
{
    disable_irq(XILINX_AC97_PLAYBACK_INTERRUPT);
    halfEmpty = 1;
    wake_up_interruptible(&ac97_queue);
    return IRQ_HANDLED;  
}
static u16 xilinx_ac97_get(struct ac97_codec *dev, u8 reg)
{
        return XAC97_ReadReg((u32)dev->private_data, reg);
}
static void xilinx_ac97_set(struct ac97_codec *dev, u8 reg, u16 data) {
        XAC97_WriteReg((u32)dev->private_data, reg, data);
}
static void xilinx_ac97_codec_wait(struct ac97_codec *dev) {
        XAC97_AwaitCodecReady((u32)dev->private_data);
}
/* OSS /dev/mixer file operation methods */
static int xilinx_ac97_open_mixdev(struct inode *inode, struct file *file)
{
    int minor = MINOR(inode->i_rdev);
    if (xilinx_ac97_codec && xilinx_ac97_codec->dev_mixer == minor) {
        file->private_data = xilinx_ac97_codec;
        return 0;
    }
    return -ENODEV;
}
static int xilinx_ac97_ioctl_mixdev(struct inode *inode,
                    struct file *file,
                    unsigned int cmd, unsigned long arg)
{
    struct ac97_codec *codec = (struct ac97_codec *) file->private_data;
    return codec->mixer_ioctl(codec, cmd, arg);
}
static /*const */ struct file_operations xilinx_ac97_mixer_fops = {
    owner:THIS_MODULE,
    llseek:no_llseek,
    ioctl:xilinx_ac97_ioctl_mixdev,
    open:xilinx_ac97_open_mixdev,
};
static int xilinx_ac97_open(struct inode *inode, struct file *file)
{
    u32 baseAddress;
    if (!state)
        BUG();
    if (!xilinx_ac97_codec)
        BUG();
  
    baseAddress = (u32)xilinx_ac97_codec->private_data;
    if (file->f_flags & O_NONBLOCK) {
        if (down_trylock (&state->open_sem)) {
            printk ("%s: returning -EAGAIN\n", __FUNCTION__);
            return -EAGAIN;
        }
    }
    else {
        if (down_interruptible (&state->open_sem)) {
            printk ("%s: returning -ERESTARTSYS\n", __FUNCTION__);
            return -ERESTARTSYS;
        }
    }
    file->private_data = state;
    printk ("%s: dsp opened by %d\n", __FUNCTION__, current->pid);
    state->buffer = (char *)kmalloc(BUFFER_SIZE, GFP_KERNEL);
    /** Reset AC97 **/                     //added by myself
    XAC97_WriteReg(baseAddress, AC97_Reset, 0);
    XAC97_Delay(1000);
  
    /** Wait for the ready signal **/
    XAC97_AwaitCodecReady(baseAddress);
    XAC97_WriteReg(baseAddress, AC97_PCM_DAC_Rate0, AC97_PCM_RATE_48000_HZ);
    XAC97_WriteReg(baseAddress, AC97_PCM_DAC_Rate1, AC97_PCM_RATE_48000_HZ);
    /** Clear FIFOs **/
    XAC97_ClearFifos(baseAddress);      
    XAC97_WriteReg(baseAddress, AC97_GeneralPurpose, 0x0000);
    XAC97_WriteReg(baseAddress, AC97_SerialConfig, 0x7000);
    /** Enable VRA Mode **/
    XAC97_WriteReg(baseAddress, AC97_ExtendedAudioStat, AC97_EXTENDED_AUDIO_CONTROL_VRA);
  
    if (file->f_mode & FMODE_WRITE) {
        printk(KERN_INFO "setting volume\n");
        /** Play Volume Settings **/
        XAC97_WriteReg(baseAddress, AC97_MasterVol, AC97_VOL_MAX);
        XAC97_WriteReg(baseAddress, AC97_AuxOutVol, AC97_VOL_MAX);
        XAC97_WriteReg(baseAddress, AC97_MasterVolMono, AC97_VOL_MAX);
        XAC97_WriteReg(baseAddress, AC97_PCBeepVol, AC97_VOL_MAX);
        XAC97_WriteReg(baseAddress, AC97_PCMOutVol, AC97_VOL_MAX);
         }
    //firstly disable interrupt
    disable_irq(XILINX_AC97_PLAYBACK_INTERRUPT);
    if(request_irq(XILINX_AC97_PLAYBACK_INTERRUPT,xilinx_ac97_interrupt,SA_INTERRUPT,"ac97",NULL))
    {
        printk(KERN_ALERT "cannot register interrupt handler\n");
    }  
    return 0;
}
static ssize_t
xilinx_ac97_write (struct file *file, const char *buffer, size_t bytes,
         loff_t *ppos)
{
    struct xilinx_ac97_state *state;
    unsigned int i = 0;// sz = 0;
    u32 baseAddress;
    char* sound_ptr;
    size_t words;
    ssize_t ret;
    int j;
     if (!access_ok (VERIFY_READ, buffer, bytes))
         return -EFAULT;
    state = (struct xilinx_ac97_state *) file->private_data;
    if (!state)
        BUG();
    if (!xilinx_ac97_codec)
        BUG();
    if (down_interruptible(&state->sem))
        return -ERESTARTSYS;
    baseAddress = (u32)xilinx_ac97_codec->private_data;
    size_t buffer_size =(size_t)BUFFER_SIZE;
    size_t tmp = bytes;
    bytes = min(tmp,buffer_size);
    if(XAC97_isInFIFOEmpty(baseAddress))
    emptyTime++;//there's some time when playback FIFO is empty,I don't know how to fix it
    if (copy_from_user(state->buffer, buffer, bytes)) {
        ret = -EFAULT;
        goto out;
    }
    words = bytes >> 1;
    sound_ptr = (char *)state->buffer;
    i = 0;
    while(i < words) {
        j = *sound_ptr;
        sound_ptr++;
        j |= (*sound_ptr)<<8;
        if(!XAC97_isInFIFOFull(baseAddress))
            XAC97_WriteFifo(baseAddress, j);
        else
        {
            halfEmpty = 0;
            enable_irq(XILINX_AC97_PLAYBACK_INTERRUPT);
            wait_event_interruptible(ac97_queue,halfEmpty != 0);
            XAC97_WriteFifo(baseAddress,j);
        }
        sound_ptr++;
        i++;
        j = 0;
    }
    ret = i << 1;
 out:
    up(&state->sem);
    return ret;
}
  
static ssize_t
xilinx_ac97_read (struct file *file, const char *buffer, size_t bytes,
         loff_t *ppos)
{
    struct xilinx_ac97_state *state;
    unsigned int i = 0;// sz = 0;
    u32 baseAddress;
    u32* sound_ptr;
    size_t words;
    if (ppos != &file->f_pos)
        return -ESPIPE;
    if (!access_ok (VERIFY_WRITE, buffer, bytes))
        return -EFAULT;
    state = (struct xilinx_ac97_state *) file->private_data;
    if (!state)
        BUG();
    if (!xilinx_ac97_codec)
        BUG();
    baseAddress = (u32)xilinx_ac97_codec->private_data;
    // Check if already opened for read?
    // Compute the number of words to transfer.
    words = bytes >> 2;
    sound_ptr = (u32*)buffer;
    i = 0;
    while(i < words && !XAC97_isOutFIFOEmpty(baseAddress)) {
        *sound_ptr = XAC97_mGetOutFifoData(baseAddress);
        sound_ptr++;
        i++;
    }
    // Return the number of bytes transferred.
    return i << 2;
}
         
static int
xilinx_ac97_release (struct inode *inode, struct file *file)
{
    u32 baseAddress;
    kfree(state->buffer);
    baseAddress = (u32)xilinx_ac97_codec->private_data;
    XAC97_ClearFifos(baseAddress);      
    XAC97_SoftReset(baseAddress);
    free_irq(XILINX_AC97_PLAYBACK_INTERRUPT,NULL);
    up (&state->open_sem);
    printk(KERN_ALERT "Empyt time is %d\n",emptyTime);
    emptyTime = 0;
    return 0;
}
static int
xilinx_ac97_ioctl (struct inode *inode, struct file *file, unsigned int cmd,
         unsigned long arg)
{
    int ival=0, rd, wr;//ret, count, rval=0;
    struct xilinx_ac97_state *state;
    u32 baseAddress = (u32)xilinx_ac97_codec->private_data;
    state = (struct xilinx_ac97_state *)file->private_data;  
  
    if (file->f_mode & FMODE_WRITE)
        wr = 1;
    else
        wr = 0;
    if (file->f_mode & FMODE_READ)
        rd = 1;
    else
        rd = 0;
    switch(cmd){
    default:break;
    }
    return -EINVAL;
}
  
static /*const */ struct file_operations xilinx_ac97_audio_fops = {
    owner:THIS_MODULE,
    llseek:no_llseek,
    read:xilinx_ac97_read,
    write:xilinx_ac97_write,
    //    poll:xilinx_ac97_poll,
    ioctl:xilinx_ac97_ioctl,
    //    mmap:xilinx_ac97_mmap,
    open:xilinx_ac97_open,
    release:xilinx_ac97_release,
};
MODULE_AUTHOR("Xilinx");
MODULE_DESCRIPTION("Xilinx AC97 driver");
MODULE_LICENSE("GPL");
static int __init xilinx_ac97_init_module(void)
{
    struct ac97_codec *codec;
        u32 baseAddress;
    printk(KERN_INFO "Xilinx AC97 Audio, version "
           DRIVER_VERSION ", " __TIME__ " " __DATE__ "\n");
        baseAddress = (u32)ioremap(AC97_BASEADDR,AC97_HIGHADDR-AC97_BASEADDR);
        printk(KERN_INFO "XAC97_HardReset\n");
    XAC97_HardReset(baseAddress);
        if ((codec = ac97_alloc_codec()) == NULL)
                return -ENOMEM;
        codec->private_data = (void *)baseAddress;
        codec->id = 0;
        codec->codec_read = xilinx_ac97_get;
        codec->codec_write = xilinx_ac97_set;
        codec->codec_wait = xilinx_ac97_codec_wait;
    if (!ac97_probe_codec(codec)) {
                printk(KERN_ERR "Failed to init Xilinx AC97");
                kfree(codec);
                return -ENODEV;    /* it didn't work */
        }
        XAC97_InitAudio((u32)codec->private_data,0);
    if ((codec->dev_mixer = register_sound_mixer(&xilinx_ac97_mixer_fops, -1)) < 0) {
        printk(KERN_ERR "xilinx_ac97_audio: couldn't register mixer!\n");
        kfree(codec);
        return -ENODEV;
    }
    if ((dev_audio = register_sound_dsp(&xilinx_ac97_audio_fops, -1)) < 0) {
        printk(KERN_ERR "xilinx_ac97_audio: couldn't register DSP device!\n");
        unregister_sound_mixer(xilinx_ac97_codec->dev_mixer);
        kfree(xilinx_ac97_codec);
        return -ENODEV;
    }
    xilinx_ac97_codec = codec;
    state = (struct xilinx_ac97_state *) kmalloc(sizeof(struct xilinx_ac97_state), GFP_KERNEL);
    init_MUTEX(&state->open_sem);
    init_MUTEX(&state->sem);
    return 0;
}
static void __exit xilinx_ac97_cleanup_module(void)
{
    unregister_sound_mixer(xilinx_ac97_codec->dev_mixer);
    ac97_release_codec(xilinx_ac97_codec);
    xilinx_ac97_codec = NULL;
    unregister_sound_dsp(dev_audio);
    dev_audio = -1;
}
module_init(xilinx_ac97_init_module);
module_exit(xilinx_ac97_cleanup_module);
/*
Local Variables:
c-basic-offset: 8
End:
*/
below is the test file "test_oss.c"
#include <fcntl.h>
#include <stdlib.h>
#include <linux/soundcard.h>
#include <sys/ioctl.h>
#define BUFFER_SIZE 1024
static int audio_fd;
void init_audio_device()
{
    int fmts;
      int init_channels;
      int speed;
      if ( (audio_fd = open("/dev/dsp", O_WRONLY)) == -1)
    {
            perror("open error\n");
            printf("soundcard open error");
            exit(1);
      }
    printf("successfully init soundcard\n\n");
}
int audio_close(void)
{
     if (audio_fd)
    {
        close(audio_fd);
             printf("the device has been closed!\n");
      }    
      return 0;
}
int audio_play(char *buf, int len)
{
    int temp;
    temp = write(audio_fd, buf, len);
    return temp;
}
int main()
{  
    init_audio_device();
    int fd = open("/root/********.wav",O_RDONLY);
    int len = 0;
    char buffer[BUFFER_SIZE];
    int i=0;
    char tempt;
    while(1)
    {
        len = read(fd,buffer,sizeof(buffer));
        if(len == 0)
        {
        printf("reach the end\n");
        break;
        }
        audio_play(buffer,len); 
    }
    audio_close();
    close(fd);
    return 0;
}
 
in the write process,firstly check whether playback FIFO is full,if not, then send PCM data to FIFO;else sleep until FIFO half-empty interrupt,in the interrupt handler,wake up write process,then go on send data to playback FIFO until full. 
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070713/ebdecf62/attachment.htm 

From grant.likely at secretlab.ca  Fri Jul 13 15:40:44 2007
From: grant.likely at secretlab.ca (Grant Likely)
Date: Thu, 12 Jul 2007 23:40:44 -0600
Subject: TEMAC driver available
In-Reply-To: <4696FB46.3020103@dlasys.net>
References: <4696FB46.3020103@dlasys.net>
Message-ID: <fa686aa40707122240k14611270h6b69aedf8e560680@mail.gmail.com>

On 7/12/07, David H. Lynch Jr. <dhlii at dlasys.net> wrote:
>     I have finally been inspired to complete my TEMAC driver to an alpha
> state.
>     It nearly required dynamite - I had a client application where the
> Xilinx/MV TEMAC
>     just did not work.
>
>     Anyway, the sucker is done and I guess I will post it as soon as I
> have leaned it up
>     if there is any interest.

Wonderful; good news.  I'd love to see it.  Please send a patch as
soon as you can.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195


From yiming at windriver.com  Fri Jul 13 17:17:18 2007
From: yiming at windriver.com (meerkat)
Date: Fri, 13 Jul 2007 00:17:18 -0700 (PDT)
Subject: boottime kernel relocation, what I missed?
Message-ID: <11574529.post@talk.nabble.com>


Good day all,

For the first time I begin working on PPC, and on low level, and right start
from boot sequence, one issue puzzled me.

After bootstrap code (zImage) uncompressed the kernel vmLinux to physical
memory (say from addr 0),
it jumps to the kernel entry point, _start, using physically address. 

 At this time, the MMU is not yet setup to map the kernel virtual address 
(which is statically linked against base address KERNELBASE) to the
physically address.

$ nm vmlinux |grep early_init
c038b8e0 T early_init


_start calls early_init before mmu is on to map the KERNEL_BASE to
physically address

The question is how "bl  early_init"  can branch to the early_init entry
point, properly, as early_init is still a virtual address?

Thanks

Jim
-- 
View this message in context: http://www.nabble.com/boottime-kernel-relocation%2C-what-I-missed--tf4072673.html#a11574529
Sent from the linuxppc-embedded mailing list archive at Nabble.com.



From urwithsudheer at gmail.com  Fri Jul 13 19:25:50 2007
From: urwithsudheer at gmail.com (urwithsudheer)
Date: Fri, 13 Jul 2007 14:55:50 +0530
Subject: XSysAce driver cant mount DOS part
In-Reply-To: <939D37AEB47F1F49B88FAB6599B6023501A17205@hsv1dafpew02.das.gov.sanm.corp>
References: <939D37AEB47F1F49B88FAB6599B6023501A17205@hsv1dafpew02.das.gov.sanm.corp>
Message-ID: <4697451E.3030409@gmail.com>

Hi

Robertson, Joseph M. wrote:
>
> Hi all,
>
> I've been workig with this for a while but have made no progress.
> Today I got the latest XSysAce patch for kernel 2.6.17.1 and applied 
> it to get clean code. 
> I inherited the previous code from another developer.
>
Can you send the link to xsysace driver source code from where you obtained.


Thanks
Sudheer


>
> My problem is that mounting the DOS partition always fails in a short 
> time with a kernel oops.
>
> ECAU-9999:# Oops: kernel access of bad area, sig: 11 
> [#1]                      
> PREEMPT                                                                        
> NIP: C00701C8 LR: C0070C18 CTR: 
> 00000000                                       
> REGS: c0391dd0 TRAP: 0300   Not tainted  
> (2.6.17.1)                            
> MSR: 00021030 <ME,IR,DR>  CR: 22028082  XER: 
> 0000000B                          
> DAR: 00000000, DSISR: 
> 00800000                                                 
> TASK = c0373030[4] 'events/0' THREAD: 
> c0390000                                 
> GPR00: 00000080 C0391E80 C0373030 C02CAC00 C0E03000 C0E03154 00000000 
> C02CAC00 
> GPR08: 00200200 00000000 00100100 00000000 00051A4B FFFFDE60 03BD4900 
> 007FFF3B 
> GPR16: 00400000 00000001 FFFFFFFF 03BCDC58 00000000 007FFF00 00000002 
> C0280000 
> GPR24: C0363A10 0000000B 00000000 00000000 00000000 C02CAC00 C035ED20 
> C0E03000 
> NIP [C00701C8] 
> free_block+0x8c/0x138                                           
> LR [C0070C18] 
> drain_array+0xb8/0x124                                           
> Call Trace:                                  
>
> The setup:
> My own build system.
> Kernel 2.6.17.1 with lots of xilinx stuff, eth, i2c, xsysace.  
> Crosscompiled for PPC405.
> Latest, clean XSysAce code.  mods:  major hardcoded to = 125.  Polled 
> mode.
> CF:  3 partitions,
> 1:  DOS FAT16
> 2:  Ext2  main
> 3:  Ext2  rescue
>
> This build boots up fine, mounts a ext2 as root fine.  I can also 
> mount the rescue partition with no problems.
>
> Does anyone have any pointers of where I should look for problems?
>
> My next step is to go and set it up for interrupt service and see if 
> that changes anything.
>
> Thanks,
>
> Joe Robertson
> Joseph.Robertson at sanmina-sci.com
>
>
> CONFIDENTIALITY
> This e-mail message and any attachments thereto, is intended only for 
> use by the addressee(s) named herein and may contain legally 
> privileged and/or confidential information. If you are not the 
> intended recipient of this e-mail message, you are hereby notified 
> that any dissemination, distribution or copying of this e-mail 
> message, and any attachments thereto, is strictly prohibited. If you 
> have received this e-mail message in error, please immediately notify 
> the sender and permanently delete the original and any copies of this 
> email and any prints thereof.
> ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL 
> IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the 
> Uniform Electronic Transactions Act or the applicability of any other 
> law of similar substance and effect, absent an express statement to 
> the contrary hereinabove, this e-mail message its contents, and any 
> attachments hereto are not intended to represent an offer or 
> acceptance to enter into a contract and are not otherwise intended to 
> bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), 
> or any other person or entity.
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070713/b59404ea/attachment.htm 

From joseph.robertson at sanmina-sci.com  Fri Jul 13 23:28:04 2007
From: joseph.robertson at sanmina-sci.com (Robertson, Joseph M.)
Date: Fri, 13 Jul 2007 08:28:04 -0500
Subject: XSysAce driver cant mount DOS part
References: <939D37AEB47F1F49B88FAB6599B6023501A17205@hsv1dafpew02.das.gov.sanm.corp>
	<4697451E.3030409@gmail.com>
Message-ID: <939D37AEB47F1F49B88FAB6599B6023501A1720A@hsv1dafpew02.das.gov.sanm.corp>

Hi, 

Yes, I got it from here.
http://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/patches/linuxppc-2.6.17.1-sysace-1.2.patch

The 'official' one, yes?

Thanks,

Joe Robertson
Joseph.Robertson at sanmina-sci.com



-----Original Message-----
From: urwithsudheer [mailto:urwithsudheer at gmail.com]
Sent: Fri 7/13/2007 4:25 AM
To: Robertson, Joseph M.
Cc: linuxppc-embedded at ozlabs.org
Subject: Re: XSysAce driver cant mount DOS part
 
Hi

Robertson, Joseph M. wrote:
>
> Hi all,
>
> I've been workig with this for a while but have made no progress.
> Today I got the latest XSysAce patch for kernel 2.6.17.1 and applied 
> it to get clean code. 
> I inherited the previous code from another developer.
>
Can you send the link to xsysace driver source code from where you obtained.


Thanks
Sudheer


>
> My problem is that mounting the DOS partition always fails in a short 
> time with a kernel oops.
>
> ECAU-9999:# Oops: kernel access of bad area, sig: 11 
> [#1]                      
> PREEMPT                                                                        
> NIP: C00701C8 LR: C0070C18 CTR: 
> 00000000                                       
> REGS: c0391dd0 TRAP: 0300   Not tainted  
> (2.6.17.1)                            
> MSR: 00021030 <ME,IR,DR>  CR: 22028082  XER: 
> 0000000B                          
> DAR: 00000000, DSISR: 
> 00800000                                                 
> TASK = c0373030[4] 'events/0' THREAD: 
> c0390000                                 
> GPR00: 00000080 C0391E80 C0373030 C02CAC00 C0E03000 C0E03154 00000000 
> C02CAC00 
> GPR08: 00200200 00000000 00100100 00000000 00051A4B FFFFDE60 03BD4900 
> 007FFF3B 
> GPR16: 00400000 00000001 FFFFFFFF 03BCDC58 00000000 007FFF00 00000002 
> C0280000 
> GPR24: C0363A10 0000000B 00000000 00000000 00000000 C02CAC00 C035ED20 
> C0E03000 
> NIP [C00701C8] 
> free_block+0x8c/0x138                                           
> LR [C0070C18] 
> drain_array+0xb8/0x124                                           
> Call Trace:                                  
>
> The setup:
> My own build system.
> Kernel 2.6.17.1 with lots of xilinx stuff, eth, i2c, xsysace.  
> Crosscompiled for PPC405.
> Latest, clean XSysAce code.  mods:  major hardcoded to = 125.  Polled 
> mode.
> CF:  3 partitions,
> 1:  DOS FAT16
> 2:  Ext2  main
> 3:  Ext2  rescue
>
> This build boots up fine, mounts a ext2 as root fine.  I can also 
> mount the rescue partition with no problems.
>
> Does anyone have any pointers of where I should look for problems?
>
> My next step is to go and set it up for interrupt service and see if 
> that changes anything.
>
> Thanks,
>
> Joe Robertson
> Joseph.Robertson at sanmina-sci.com
>
>
> CONFIDENTIALITY
> This e-mail message and any attachments thereto, is intended only for 
> use by the addressee(s) named herein and may contain legally 
> privileged and/or confidential information. If you are not the 
> intended recipient of this e-mail message, you are hereby notified 
> that any dissemination, distribution or copying of this e-mail 
> message, and any attachments thereto, is strictly prohibited. If you 
> have received this e-mail message in error, please immediately notify 
> the sender and permanently delete the original and any copies of this 
> email and any prints thereof.
> ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL 
> IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the 
> Uniform Electronic Transactions Act or the applicability of any other 
> law of similar substance and effect, absent an express statement to 
> the contrary hereinabove, this e-mail message its contents, and any 
> attachments hereto are not intended to represent an offer or 
> acceptance to enter into a contract and are not otherwise intended to 
> bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), 
> or any other person or entity.
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded



CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited.  If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING.  Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), or any other person or entity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070713/d006695e/attachment.htm 

From willy.jacobs at nl.thalesgroup.com  Fri Jul 13 21:21:40 2007
From: willy.jacobs at nl.thalesgroup.com (willy jacobs)
Date: Fri, 13 Jul 2007 13:21:40 +0200
Subject: Strange PCI mmap problem on MPC8555
Message-ID: <46976044.1030702@nl.thalesgroup.com>

Setup: ELDK 4.1, U-Boot 1.2.0 and Linux 2.6.20.2 (arch/ppc)

The PPC can communicate (memory mapped) with a FGPA through the PCI bus.
A user program should be able to access (read/write) the FPGA memory areas
directly via mmap() through a small Linux driver.

In the driver initialisation bar0 (1 KByte memory) the PCI physical 
address
is remapped to virtual address space via ioremap().
A memory dump (with expected values) in the kernel driver shows:
             0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
0xe1056000 17 31 04 00 02 00 00 00 07 20 07 03 00 00 00 00

The mmap call in driver looks like this:

static int
rvc_mmap (struct file *filp, struct vm_area_struct *vma)
{
...
	if (remap_pfn_range(vma,
			    vma->vm_start,
			    phys_bar0 >> PAGE_SHIFT,
			    vma->vm_end - vma->vm_start,
			    vma->vm_page_prot)) {
	    printk(KERN_CRIT "rvc_mmap: remap_page bar0 failed\n");
	    return -EAGAIN;
...
}

The user space test program does a mmap() to bar0 and the memory dump
(erroneous values) now shows:

            0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
0x30019000 17 31 04 00 17 31 04 00 07 20 07 03 07 20 07 03
                        ^^^^^^^^^^^             ^^^^^^^^^^^
So the first 32-bit word is now exactly the same as the second 32-bit 
word,
the 4th 32-bit word is the same as the 3rd 32-bit word, etc.
Also the same behaviour for bar1.
It looks like a 32-/64 bit problem, but the kernel I use is 32-bits.
Any idea what causes this strange behaviour?
-- 
willy
Unclassified


From grant.likely at secretlab.ca  Sat Jul 14 01:41:34 2007
From: grant.likely at secretlab.ca (Grant Likely)
Date: Fri, 13 Jul 2007 09:41:34 -0600
Subject: [PATCH] Xilinx SystemACE device driver
In-Reply-To: <939D37AEB47F1F49B88FAB6599B6023501A1720B@hsv1dafpew02.das.gov.sanm.corp>
References: <20070712225138.13213.38257.stgit@trillian>
	<939D37AEB47F1F49B88FAB6599B6023501A1720B@hsv1dafpew02.das.gov.sanm.corp>
Message-ID: <fa686aa40707130841w6a36146cufc85a62f78a53b0d@mail.gmail.com>

On 7/13/07, Robertson, Joseph M. <joseph.robertson at sanmina-sci.com> wrote:
>
>
>
> Hi,
>
>  I apologize if I am just being dense, but cannot get this patch to work.

BTW, please make sure you CC the mailing list when asking questions.
That way more people than just me can offer answers.

You will probably get conflicts when applying the patch which you need
to fixup, but the conflicts should be limited to Kconfig and Makefile.

>  I get the same problem.
>  What command do you use to apply the patch?  patch -p1 < filename
>  I put file in kernel root and change b/drivers/block/xsysace.c ->
> b/drivers/block/xilinx_sysace/xsysace.c  (the 'old'
> location?)

Yes, 'patch -p1 < file' is the correct command.  Make sure you start
at the top of the Linux kernel source tree.  Also make sure that you
are using the raw email that I sent you.  Do *NOT* try to copy and
paste from your mail client.  It will not work.  Outlook is
particularly bad for working with patches, so if you can change mail
clients, or start using a gmail account, your life will get easier.

>  I thought I had a too old version of patch, but its actually later than the
> gnu website(2.5.4), I have 2.5.9

The patch format is *very* stable.  This is certainly not your problem.
>
>  Can you post the complete file for xsysace v1.01a somewhere?
>  Or tell me, does the xsysace.c code completely replace the previous
> xsysace.c file?

The new driver is a 100% rewrite.  In fact, the old and new drivers
can coexist side-by-side.  The new driver is fully contained in a
single source file (xsysace.c).

>
>  Or perhaps point out what xsysace bug we need to fix?

I have no idea.  I cannot say without trying to reproduce the problem,
and 2.6.17 is far to old for me to want to twiddle with.

What xilinx devices are you using?  TEMAC, SystemACE I know.  Any others?

>
>  Thanks a lot.  I hope to be able to contribute one day.

:-)

>
>  Joe Robertson
>  x8259
>  Joseph.Robertson at sanmina-sci.com
>
>
>
>  -----Original Message-----
>  From: Grant Likely [mailto:grant.likely at secretlab.ca]
>  Sent: Thu 7/12/2007 5:51 PM
>  To: Robertson at secretlab.ca; Robertson, Joseph M.
>  Subject: [PATCH] Xilinx SystemACE device driver
>
>  From: Grant Likely <grant.likely at secretlab.ca>
>
>  Add support for block device access to the Xilinx SystemACE Compact
>  flash interface
>
>  Signed-off-by: Grant Likely <grant.likely at secretlab.ca>
>  ---
>
>   drivers/block/Kconfig   |    6
>   drivers/block/Makefile  |    1
>   drivers/block/xsysace.c | 1167
> +++++++++++++++++++++++++++++++++++++++++++++++
>   3 files changed, 1174 insertions(+), 0 deletions(-)
>
>  diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
>  index b4c8319..184b30d 100644
>  --- a/drivers/block/Kconfig
>  +++ b/drivers/block/Kconfig
>  @@ -453,6 +453,12 @@ config ATA_OVER_ETH
>
>   source "drivers/s390/block/Kconfig"
>
>  +config XILINX_SYSACE
>  +       tristate "Xilinx SystemACE support"
>  +       depends on 4xx
>  +       help
>  +         Include support for the Xilinx SystemACE CompactFlash interface
>  +
>   endmenu
>
>   endif
>  diff --git a/drivers/block/Makefile b/drivers/block/Makefile
>  index dd88e33..31ea323 100644
>  --- a/drivers/block/Makefile
>  +++ b/drivers/block/Makefile
>  @@ -28,4 +28,5 @@ obj-$(CONFIG_BLK_DEV_CRYPTOLOOP) +=
> cryptoloop.o
>   obj-$(CONFIG_VIODASD)          += viodasd.o
>   obj-$(CONFIG_BLK_DEV_SX8)      += sx8.o
>   obj-$(CONFIG_BLK_DEV_UB)       += ub.o
>  +obj-$(CONFIG_XILINX_SYSACE)    += xsysace.o
>
>  diff --git a/drivers/block/xsysace.c b/drivers/block/xsysace.c
>  new file mode 100644
>  index 0000000..f8602e6
>  --- /dev/null
>  +++ b/drivers/block/xsysace.c
>  @@ -0,0 +1,1167 @@
>  +/*
>  + * Xilinx SystemACE device driver
>  + *
>  + * Copyright 2007 Secret Lab Technologies Ltd.
>  + *
>  + * This program is free software; you can redistribute it and/or modify it
>  + * under the terms of the GNU General Public License version 2 as
> published
>  + * by the Free Software Foundation.
>  + */
>  +
>  +/*
>  + * The SystemACE chip is designed to configure FPGAs by loading an FPGA
>  + * bitstream from a file on a CF card and squirting it into FPGAs
> connected
>  + * to the SystemACE JTAG chain.  It also has the advantage of providing an
>  + * MPU interface which can be used to control the FPGA configuration
> process
>  + * and to use the attached CF card for general purpose storage.
>  + *
>  + * This driver is a block device driver for the SystemACE.
>  + *
>  + * Initialization:
>  + *    The driver registers itself as a platform_device driver at module
>  + *    load time.  The platform bus will take care of calling the
>  + *    ace_probe() method for all SystemACE instances in the system.  Any
>  + *    number of SystemACE instances are supported.  ace_probe() calls
>  + *    ace_setup() which initialized all data structures, reads the CF
>  + *    id structure and registers the device.
>  + *
>  + * Processing:
>  + *    Just about all of the heavy lifting in this driver is performed by
>  + *    a Finite State Machine (FSM).  The driver needs to wait on a number
>  + *    of events; some raised by interrupts, some which need to be polled
>  + *    for.  Describing all of the behaviour in a FSM seems to be the
>  + *    easiest way to keep the complexity low and make it easy to
>  + *    understand what the driver is doing.  If the block ops or the
>  + *    request function need to interact with the hardware, then they
>  + *    simply need to flag the request and kick of FSM processing.
>  + *
>  + *    The FSM itself is atomic-safe code which can be run from any
>  + *    context.  The general process flow is:
>  + *    1. obtain the ace->lock spinlock.
>  + *    2. loop on ace_fsm_dostate() until the ace->fsm_continue flag is
>  + *       cleared.
>  + *    3. release the lock.
>  + *
>  + *    Individual states do not sleep in any way.  If a condition needs to
>  + *    be waited for then the state much clear the fsm_continue flag and
>  + *    either schedule the FSM to be run again at a later time, or expect
>  + *    an interrupt to call the FSM when the desired condition is met.
>  + *
>  + *    In normal operation, the FSM is processed at interrupt context
>  + *    either when the driver's tasklet is scheduled, or when an irq is
>  + *    raised by the hardware.  The tasklet can be scheduled at any time.
>  + *    The request method in particular schedules the tasklet when a new
>  + *    request has been indicated by the block layer.  Once started, the
>  + *    FSM proceeds as far as it can processing the request until it
>  + *    needs on a hardware event.  At this point, it must yield execution.
>  + *
>  + *    A state has two options when yielding execution:
>  + *    1. ace_fsm_yield()
>  + *       - Call if need to poll for event.
>  + *       - clears the fsm_continue flag to exit the processing loop
>  + *       - reschedules the tasklet to run again as soon as possible
>  + *    2. ace_fsm_yieldirq()
>  + *       - Call if an irq is expected from the HW
>  + *       - clears the fsm_continue flag to exit the processing loop
>  + *       - does not reschedule the tasklet so the FSM will not be
> processed
>  + *         again until an irq is received.
>  + *    After calling a yield function, the state must return control back
>  + *    to the FSM main loop.
>  + *
>  + *    Additionally, the driver maintains a kernel timer which can process
>  + *    the FSM.  If the FSM gets stalled, typically due to a missed
>  + *    interrupt, then the kernel timer will expire and the driver can
>  + *    continue where it left off.
>  + *
>  + * To Do:
>  + *    - Add FPGA configuration control interface.
>  + *    - Request major number from lanana
>  + */
>  +
>  +#undef DEBUG
>  +
>  +#include <linux/module.h>
>  +#include <linux/ctype.h>
>  +#include <linux/init.h>
>  +#include <linux/interrupt.h>
>  +#include <linux/errno.h>
>  +#include <linux/kernel.h>
>  +#include <linux/delay.h>
>  +#include <linux/slab.h>
>  +#include <linux/blkdev.h>
>  +#include <linux/hdreg.h>
>  +#include <linux/platform_device.h>
>  +
>  +MODULE_AUTHOR("Grant Likely <grant.likely at secretlab.ca>");
>  +MODULE_DESCRIPTION("Xilinx SystemACE device driver");
>  +MODULE_LICENSE("GPL");
>  +
>  +/* SystemACE register definitions */
>  +#define ACE_BUSMODE (0x00)
>  +
>  +#define ACE_STATUS (0x04)
>  +#define ACE_STATUS_CFGLOCK      (0x00000001)
>  +#define ACE_STATUS_MPULOCK      (0x00000002)
>  +#define ACE_STATUS_CFGERROR     (0x00000004)   /* config controller error
> */
>  +#define ACE_STATUS_CFCERROR     (0x00000008)   /* CF controller error */
>  +#define ACE_STATUS_CFDETECT     (0x00000010)
>  +#define ACE_STATUS_DATABUFRDY   (0x00000020)
>  +#define ACE_STATUS_DATABUFMODE  (0x00000040)
>  +#define ACE_STATUS_CFGDONE      (0x00000080)
>  +#define ACE_STATUS_RDYFORCFCMD  (0x00000100)
>  +#define ACE_STATUS_CFGMODEPIN   (0x00000200)
>  +#define ACE_STATUS_CFGADDR_MASK (0x0000e000)
>  +#define ACE_STATUS_CFBSY        (0x00020000)
>  +#define ACE_STATUS_CFRDY        (0x00040000)
>  +#define ACE_STATUS_CFDWF        (0x00080000)
>  +#define ACE_STATUS_CFDSC        (0x00100000)
>  +#define ACE_STATUS_CFDRQ        (0x00200000)
>  +#define ACE_STATUS_CFCORR       (0x00400000)
>  +#define ACE_STATUS_CFERR        (0x00800000)
>  +
>  +#define ACE_ERROR (0x08)
>  +#define ACE_CFGLBA (0x0c)
>  +#define ACE_MPULBA (0x10)
>  +
>  +#define ACE_SECCNTCMD (0x14)
>  +#define ACE_SECCNTCMD_RESET      (0x0100)
>  +#define ACE_SECCNTCMD_IDENTIFY   (0x0200)
>  +#define ACE_SECCNTCMD_READ_DATA  (0x0300)
>  +#define ACE_SECCNTCMD_WRITE_DATA (0x0400)
>  +#define ACE_SECCNTCMD_ABORT      (0x0600)
>  +
>  +#define ACE_VERSION (0x16)
>  +#define ACE_VERSION_REVISION_MASK (0x00FF)
>  +#define ACE_VERSION_MINOR_MASK    (0x0F00)
>  +#define ACE_VERSION_MAJOR_MASK    (0xF000)
>  +
>  +#define ACE_CTRL (0x18)
>  +#define ACE_CTRL_FORCELOCKREQ   (0x0001)
>  +#define ACE_CTRL_LOCKREQ        (0x0002)
>  +#define ACE_CTRL_FORCECFGADDR   (0x0004)
>  +#define ACE_CTRL_FORCECFGMODE   (0x0008)
>  +#define ACE_CTRL_CFGMODE        (0x0010)
>  +#define ACE_CTRL_CFGSTART       (0x0020)
>  +#define ACE_CTRL_CFGSEL         (0x0040)
>  +#define ACE_CTRL_CFGRESET       (0x0080)
>  +#define ACE_CTRL_DATABUFRDYIRQ  (0x0100)
>  +#define ACE_CTRL_ERRORIRQ       (0x0200)
>  +#define ACE_CTRL_CFGDONEIRQ     (0x0400)
>  +#define ACE_CTRL_RESETIRQ       (0x0800)
>  +#define ACE_CTRL_CFGPROG        (0x1000)
>  +#define ACE_CTRL_CFGADDR_MASK   (0xe000)
>  +
>  +#define ACE_FATSTAT (0x1c)
>  +
>  +#define ACE_NUM_MINORS 16
>  +#define ACE_SECTOR_SIZE (512)
>  +#define ACE_FIFO_SIZE (32)
>  +#define ACE_BUF_PER_SECTOR (ACE_SECTOR_SIZE / ACE_FIFO_SIZE)
>  +
>  +struct ace_reg_ops;
>  +
>  +struct ace_device {
>  +       /* driver state data */
>  +       int id;
>  +       int media_change;
>  +       int users;
>  +       struct list_head list;
>  +
>  +       /* finite state machine data */
>  +       struct tasklet_struct fsm_tasklet;
>  +       uint fsm_task;          /* Current activity (ACE_TASK_*) */
>  +       uint fsm_state;         /* Current state (ACE_FSM_STATE_*) */
>  +       uint fsm_continue_flag; /* cleared to exit FSM mainloop */
>  +       uint fsm_iter_num;
>  +       struct timer_list stall_timer;
>  +
>  +       /* Transfer state/result, use for both id and block request */
>  +       struct request *req;    /* request being processed */
>  +       void *data_ptr;         /* pointer to I/O buffer */
>  +       int data_count;         /* number of buffers remaining */
>  +       int data_result;        /* Result of transfer; 0 := success */
>  +
>  +       int id_req_count;       /* count of id requests */
>  +       int id_result;
>  +       struct completion id_completion;        /* used when id req
> finishes */
>  +       int in_irq;
>  +
>  +       /* Details of hardware device */
>  +       unsigned long physaddr;
>  +       void *baseaddr;
>  +       int irq;
>  +       int bus_width;          /* 0 := 8 bit; 1 := 16 bit */
>  +       struct ace_reg_ops *reg_ops;
>  +       int lock_count;
>  +
>  +       /* Block device data structures */
>  +       spinlock_t lock;
>  +       struct device *dev;
>  +       struct request_queue *queue;
>  +       struct gendisk *gd;
>  +
>  +       /* Inserted CF card parameters */
>  +       struct hd_driveid cf_id;
>  +};
>  +
>  +static int ace_major;
>  +
>  +/*
> ---------------------------------------------------------------------
>  + * Low level register access
>  + */
>  +
>  +struct ace_reg_ops {
>  +       u16(*in) (struct ace_device * ace, int reg);
>  +       void (*out) (struct ace_device * ace, int reg, u16 val);
>  +       void (*datain) (struct ace_device * ace);
>  +       void (*dataout) (struct ace_device * ace);
>  +};
>  +
>  +/* 8 Bit bus width */
>  +static u16 ace_in_8(struct ace_device *ace, int reg)
>  +{
>  +       void *r = ace->baseaddr + reg;
>  +       return in_8(r) | (in_8(r + 1) << 8);
>  +}
>  +
>  +static void ace_out_8(struct ace_device *ace, int reg, u16 val)
>  +{
>  +       void *r = ace->baseaddr + reg;
>  +       out_8(r, val);
>  +       out_8(r + 1, val >> 8);
>  +}
>  +
>  +static void ace_datain_8(struct ace_device *ace)
>  +{
>  +       void *r = ace->baseaddr + 0x40;
>  +       u8 *dst = ace->data_ptr;
>  +       int i = ACE_FIFO_SIZE;
>  +       while (i--)
>  +               *dst++ = in_8(r++);
>  +       ace->data_ptr = dst;
>  +}
>  +
>  +static void ace_dataout_8(struct ace_device *ace)
>  +{
>  +       void *r = ace->baseaddr + 0x40;
>  +       u8 *src = ace->data_ptr;
>  +       int i = ACE_FIFO_SIZE;
>  +       while (i--)
>  +               out_8(r++, *src++);
>  +       ace->data_ptr = src;
>  +}
>  +
>  +static struct ace_reg_ops ace_reg_8_ops = {
>  +       .in = ace_in_8,
>  +       .out = ace_out_8,
>  +       .datain = ace_datain_8,
>  +       .dataout = ace_dataout_8,
>  +};
>  +
>  +/* 16 bit big endian bus attachment */
>  +static u16 ace_in_be16(struct ace_device *ace, int reg)
>  +{
>  +       return in_be16(ace->baseaddr + reg);
>  +}
>  +
>  +static void ace_out_be16(struct ace_device *ace, int reg, u16 val)
>  +{
>  +       out_be16(ace->baseaddr + reg, val);
>  +}
>  +
>  +static void ace_datain_be16(struct ace_device *ace)
>  +{
>  +       int i = ACE_FIFO_SIZE / 2;
>  +       u16 *dst = ace->data_ptr;
>  +       while (i--)
>  +               *dst++ = in_le16(ace->baseaddr + 0x40);
>  +       ace->data_ptr = dst;
>  +}
>  +
>  +static void ace_dataout_be16(struct ace_device *ace)
>  +{
>  +       int i = ACE_FIFO_SIZE / 2;
>  +       u16 *src = ace->data_ptr;
>  +       while (i--)
>  +               out_le16(ace->baseaddr + 0x40, *src++);
>  +       ace->data_ptr = src;
>  +}
>  +
>  +/* 16 bit little endian bus attachment */
>  +static u16 ace_in_le16(struct ace_device *ace, int reg)
>  +{
>  +       return in_le16(ace->baseaddr + reg);
>  +}
>  +
>  +static void ace_out_le16(struct ace_device *ace, int reg, u16 val)
>  +{
>  +       out_le16(ace->baseaddr + reg, val);
>  +}
>  +
>  +static void ace_datain_le16(struct ace_device *ace)
>  +{
>  +       int i = ACE_FIFO_SIZE / 2;
>  +       u16 *dst = ace->data_ptr;
>  +       while (i--)
>  +               *dst++ = in_be16(ace->baseaddr + 0x40);
>  +       ace->data_ptr = dst;
>  +}
>  +
>  +static void ace_dataout_le16(struct ace_device *ace)
>  +{
>  +       int i = ACE_FIFO_SIZE / 2;
>  +       u16 *src = ace->data_ptr;
>  +       while (i--)
>  +               out_be16(ace->baseaddr + 0x40, *src++);
>  +       ace->data_ptr = src;
>  +}
>  +
>  +static struct ace_reg_ops ace_reg_be16_ops = {
>  +       .in = ace_in_be16,
>  +       .out = ace_out_be16,
>  +       .datain = ace_datain_be16,
>  +       .dataout = ace_dataout_be16,
>  +};
>  +
>  +static struct ace_reg_ops ace_reg_le16_ops = {
>  +       .in = ace_in_le16,
>  +       .out = ace_out_le16,
>  +       .datain = ace_datain_le16,
>  +       .dataout = ace_dataout_le16,
>  +};
>  +
>  +static inline u16 ace_in(struct ace_device *ace, int reg)
>  +{
>  +       return ace->reg_ops->in(ace, reg);
>  +}
>  +
>  +static inline u32 ace_in32(struct ace_device *ace, int reg)
>  +{
>  +       return ace_in(ace, reg) | (ace_in(ace, reg + 2) << 16);
>  +}
>  +
>  +static inline void ace_out(struct ace_device *ace, int reg, u16 val)
>  +{
>  +       ace->reg_ops->out(ace, reg, val);
>  +}
>  +
>  +static inline void ace_out32(struct ace_device *ace, int reg, u32 val)
>  +{
>  +       ace_out(ace, reg, val);
>  +       ace_out(ace, reg + 2, val >> 16);
>  +}
>  +
>  +/*
> ---------------------------------------------------------------------
>  + * Debug support functions
>  + */
>  +
>  +#if defined(DEBUG)
>  +static void ace_dump_mem(void *base, int len)
>  +{
>  +       const char *ptr = base;
>  +       int i, j;
>  +
>  +       for (i = 0; i < len; i += 16) {
>  +               printk(KERN_INFO "%.8x:", i);
>  +               for (j = 0; j < 16; j++) {
>  +                       if (!(j % 4))
>  +                               printk(" ");
>  +                       printk("%.2x", ptr[i + j]);
>  +               }
>  +               printk(" ");
>  +               for (j = 0; j < 16; j++)
>  +                       printk("%c", isprint(ptr[i + j]) ? ptr[i + j] :
> '.');
>  +               printk("\n");
>  +       }
>  +}
>  +#else
>  +static inline void ace_dump_mem(void *base, int len)
>  +{
>  +}
>  +#endif
>  +
>  +static void ace_dump_regs(struct ace_device *ace)
>  +{
>  +       dev_info(ace->dev, "    ctrl:  %.8x  seccnt/cmd: %.4x
> ver:%.4x\n"
>  +                "    status:%.8x  mpu_lba:%.8x  busmode:%4x\n"
>  +                "    error: %.8x  cfg_lba:%.8x  fatstat:%.4x\n",
>  +                ace_in32(ace, ACE_CTRL),
>  +                ace_in(ace, ACE_SECCNTCMD),
>  +                ace_in(ace, ACE_VERSION),
>  +                ace_in32(ace, ACE_STATUS),
>  +                ace_in32(ace, ACE_MPULBA),
>  +                ace_in(ace, ACE_BUSMODE),
>  +                ace_in32(ace, ACE_ERROR),
>  +                ace_in32(ace, ACE_CFGLBA), ace_in(ace, ACE_FATSTAT));
>  +}
>  +
>  +void ace_fix_driveid(struct hd_driveid *id)
>  +{
>  +#if defined(__BIG_ENDIAN)
>  +       u16 *buf = (void *)id;
>  +       int i;
>  +
>  +       /* All half words have wrong byte order; swap the bytes */
>  +       for (i = 0; i < sizeof(struct hd_driveid); i += 2, buf++)
>  +               *buf = le16_to_cpu(*buf);
>  +
>  +       /* Some of the data values are 32bit; swap the half words  */
>  +       id->lba_capacity = ((id->lba_capacity >> 16) & 0x0000FFFF) |
>  +           ((id->lba_capacity << 16) & 0xFFFF0000);
>  +       id->spg = ((id->spg >> 16) & 0x0000FFFF) |
>  +           ((id->spg << 16) & 0xFFFF0000);
>  +#endif
>  +}
>  +
>  +/*
> ---------------------------------------------------------------------
>  + * Finite State Machine (FSM) implementation
>  + */
>  +
>  +/* FSM tasks; used to direct state transitions */
>  +#define ACE_TASK_IDLE      0
>  +#define ACE_TASK_IDENTIFY  1
>  +#define ACE_TASK_READ      2
>  +#define ACE_TASK_WRITE     3
>  +#define ACE_FSM_NUM_TASKS  4
>  +
>  +/* FSM state definitions */
>  +#define ACE_FSM_STATE_IDLE               0
>  +#define ACE_FSM_STATE_REQ_LOCK           1
>  +#define ACE_FSM_STATE_WAIT_LOCK          2
>  +#define ACE_FSM_STATE_WAIT_CFREADY       3
>  +#define ACE_FSM_STATE_IDENTIFY_PREPARE   4
>  +#define ACE_FSM_STATE_IDENTIFY_TRANSFER  5
>  +#define ACE_FSM_STATE_IDENTIFY_COMPLETE  6
>  +#define ACE_FSM_STATE_REQ_PREPARE        7
>  +#define ACE_FSM_STATE_REQ_TRANSFER       8
>  +#define ACE_FSM_STATE_REQ_COMPLETE       9
>  +#define ACE_FSM_STATE_ERROR             10
>  +#define ACE_FSM_NUM_STATES              11
>  +
>  +/* Set flag to exit FSM loop and reschedule tasklet */
>  +static inline void ace_fsm_yield(struct ace_device *ace)
>  +{
>  +       dev_dbg(ace->dev, "ace_fsm_yield()\n");
>  +       tasklet_schedule(&ace->fsm_tasklet);
>  +       ace->fsm_continue_flag = 0;
>  +}
>  +
>  +/* Set flag to exit FSM loop and wait for IRQ to reschedule tasklet */
>  +static inline void ace_fsm_yieldirq(struct ace_device *ace)
>  +{
>  +       dev_dbg(ace->dev, "ace_fsm_yieldirq()\n");
>  +
>  +       if (ace->irq == NO_IRQ)
>  +               /* No IRQ assigned, so need to poll */
>  +               tasklet_schedule(&ace->fsm_tasklet);
>  +       ace->fsm_continue_flag = 0;
>  +}
>  +
>  +/* Get the next read/write request; ending requests that we don't handle
> */
>  +struct request *ace_get_next_request(request_queue_t * q)
>  +{
>  +       struct request *req;
>  +
>  +       while ((req = elv_next_request(q)) != NULL) {
>  +               if (blk_fs_request(req))
>  +                       break;
>  +               end_request(req, 0);
>  +       }
>  +       return req;
>  +}
>  +
>  +static void ace_fsm_dostate(struct ace_device *ace)
>  +{
>  +       struct request *req;
>  +       u32 status;
>  +       u16 val;
>  +       int count;
>  +       int i;
>  +
>  +#if defined(DEBUG)
>  +       dev_dbg(ace->dev, "fsm_state=%i, id_req_count=%i\n",
>  +               ace->fsm_state, ace->id_req_count);
>  +#endif
>  +
>  +       switch (ace->fsm_state) {
>  +       case ACE_FSM_STATE_IDLE:
>  +               /* See if there is anything to do */
>  +               if (ace->id_req_count ||
> ace_get_next_request(ace->queue)) {
>  +                       ace->fsm_iter_num++;
>  +                       ace->fsm_state = ACE_FSM_STATE_REQ_LOCK;
>  +                       mod_timer(&ace->stall_timer, jiffies + HZ);
>  +                       if
> (!timer_pending(&ace->stall_timer))
>  +                               add_timer(&ace->stall_timer);
>  +                       break;
>  +               }
>  +               del_timer(&ace->stall_timer);
>  +               ace->fsm_continue_flag = 0;
>  +               break;
>  +
>  +       case ACE_FSM_STATE_REQ_LOCK:
>  +               if (ace_in(ace, ACE_STATUS) & ACE_STATUS_MPULOCK) {
>  +                       /* Already have the lock, jump to next state */
>  +                       ace->fsm_state = ACE_FSM_STATE_WAIT_CFREADY;
>  +                       break;
>  +               }
>  +
>  +               /* Request the lock */
>  +               val = ace_in(ace, ACE_CTRL);
>  +               ace_out(ace, ACE_CTRL, val | ACE_CTRL_LOCKREQ);
>  +               ace->fsm_state = ACE_FSM_STATE_WAIT_LOCK;
>  +               break;
>  +
>  +       case ACE_FSM_STATE_WAIT_LOCK:
>  +               if (ace_in(ace, ACE_STATUS) & ACE_STATUS_MPULOCK) {
>  +                       /* got the lock; move to next state */
>  +                       ace->fsm_state = ACE_FSM_STATE_WAIT_CFREADY;
>  +                       break;
>  +               }
>  +
>  +               /* wait a bit for the lock */
>  +               ace_fsm_yield(ace);
>  +               break;
>  +
>  +       case ACE_FSM_STATE_WAIT_CFREADY:
>  +               status = ace_in32(ace, ACE_STATUS);
>  +               if (!(status & ACE_STATUS_RDYFORCFCMD) ||
>  +                   (status & ACE_STATUS_CFBSY)) {
>  +                       /* CF card isn't ready; it needs to be polled */
>  +                       ace_fsm_yield(ace);
>  +                       break;
>  +               }
>  +
>  +               /* Device is ready for command; determine what to do next
> */
>  +               if (ace->id_req_count)
>  +                       ace->fsm_state = ACE_FSM_STATE_IDENTIFY_PREPARE;
>  +               else
>  +                       ace->fsm_state = ACE_FSM_STATE_REQ_PREPARE;
>  +               break;
>  +
>  +       case ACE_FSM_STATE_IDENTIFY_PREPARE:
>  +               /* Send identify command */
>  +               ace->fsm_task = ACE_TASK_IDENTIFY;
>  +               ace->data_ptr = &ace->cf_id;
>  +               ace->data_count = ACE_BUF_PER_SECTOR;
>  +               ace_out(ace, ACE_SECCNTCMD, ACE_SECCNTCMD_IDENTIFY);
>  +
>  +               /* As per datasheet, put config controller in reset */
>  +               val = ace_in(ace, ACE_CTRL);
>  +               ace_out(ace, ACE_CTRL, val | ACE_CTRL_CFGRESET);
>  +
>  +               /* irq handler takes over from this point; wait for the
>  +                * transfer to complete */
>  +               ace->fsm_state =
> ACE_FSM_STATE_IDENTIFY_TRANSFER;
>  +               ace_fsm_yieldirq(ace);
>  +               break;
>  +
>  +       case ACE_FSM_STATE_IDENTIFY_TRANSFER:
>  +               /* Check that the sysace is ready to receive data */
>  +               status = ace_in32(ace, ACE_STATUS);
>  +               if (status & ACE_STATUS_CFBSY) {
>  +                       dev_dbg(ace->dev, "CFBSY set; t=%i iter=%i
> dc=%i\n",
>  +                               ace->fsm_task, ace->fsm_iter_num,
>  +                               ace->data_count);
>  +                       ace_fsm_yield(ace);
>  +                       break;
>  +               }
>  +               if (!(status & ACE_STATUS_DATABUFRDY)) {
>  +                       ace_fsm_yield(ace);
>  +                       break;
>  +               }
>  +
>  +               /* Transfer the next buffer */
>  +               ace->reg_ops->datain(ace);
>  +               ace->data_count--;
>  +
>  +               /* If there are still buffers to be transfers; jump out
> here */
>  +               if (ace->data_count != 0) {
>  +                       ace_fsm_yieldirq(ace);
>  +                       break;
>  +               }
>  +
>  +               /* transfer finished; kick state machine */
>  +               dev_dbg(ace->dev, "identify finished\n");
>  +               ace->fsm_state =
> ACE_FSM_STATE_IDENTIFY_COMPLETE;
>  +               break;
>  +
>  +       case ACE_FSM_STATE_IDENTIFY_COMPLETE:
>  +               ace_fix_driveid(&ace->cf_id);
>  +               ace_dump_mem(&ace->cf_id, 512); /* Debug: Dump out disk ID
> */
>  +
>  +               if (ace->data_result) {
>  +                       /* Error occured, disable the disk */
>  +                       ace->media_change = 1;
>  +                       set_capacity(ace->gd, 0);
>  +                       dev_err(ace->dev, "error fetching CF id (%i)\n",
>  +                               ace->data_result);
>  +               } else {
>  +                       ace->media_change = 0;
>  +
>  +                       /* Record disk parameters */
>  +                       set_capacity(ace->gd, ace->cf_id.lba_capacity);
>  +                       dev_info(ace->dev, "capacity: %i sectors\n",
>  +                                ace->cf_id.lba_capacity);
>  +               }
>  +
>  +               /* We're done, drop to IDLE state and notify waiters */
>  +               ace->fsm_state = ACE_FSM_STATE_IDLE;
>  +               ace->id_result = ace->data_result;
>  +               while (ace->id_req_count) {
>  +                       complete(&ace->id_completion);
>  +                       ace->id_req_count--;
>  +               }
>  +               break;
>  +
>  +       case ACE_FSM_STATE_REQ_PREPARE:
>  +               req = ace_get_next_request(ace->queue);
>  +               if (!req) {
>  +                       ace->fsm_state = ACE_FSM_STATE_IDLE;
>  +                       break;
>  +               }
>  +
>  +               /* Okay, it's a data request, set it up for transfer */
>  +               dev_dbg(ace->dev,
>  +                       "request: sec=%lx hcnt=%lx, ccnt=%x, dir=%i\n",
>  +                       req->sector, req->hard_nr_sectors,
>  +                       req->current_nr_sectors, rq_data_dir(req));
>  +
>  +               ace->req = req;
>  +               ace->data_ptr = req->buffer;
>  +               ace->data_count = req->current_nr_sectors *
> ACE_BUF_PER_SECTOR;
>  +               ace_out32(ace, ACE_MPULBA, req->sector & 0x0FFFFFFF);
>  +
>  +               count = req->hard_nr_sectors;
>  +               if (rq_data_dir(req)) {
>  +                       /* Kick off write request */
>  +                       dev_dbg(ace->dev, "write data\n");
>  +                       ace->fsm_task = ACE_TASK_WRITE;
>  +                       ace_out(ace, ACE_SECCNTCMD,
>  +                               count | ACE_SECCNTCMD_WRITE_DATA);
>  +               } else {
>  +                       /* Kick off read request */
>  +                       dev_dbg(ace->dev, "read data\n");
>  +                       ace->fsm_task = ACE_TASK_READ;
>  +                       ace_out(ace, ACE_SECCNTCMD,
>  +                               count | ACE_SECCNTCMD_READ_DATA);
>  +               }
>  +
>  +               /* As per datasheet, put config controller in reset */
>  +               val = ace_in(ace, ACE_CTRL);
>  +               ace_out(ace, ACE_CTRL, val | ACE_CTRL_CFGRESET);
>  +
>  +               /* Move to the transfer state.  The systemace will raise
>  +                * an interrupt once there is something to do
>  +                */
>  +               ace->fsm_state = ACE_FSM_STATE_REQ_TRANSFER;
>  +               if (ace->fsm_task == ACE_TASK_READ)
>  +                       ace_fsm_yieldirq(ace);  /* wait for data ready */
>  +               break;
>  +
>  +       case ACE_FSM_STATE_REQ_TRANSFER:
>  +               /* Check that the sysace is ready to receive data */
>  +               status = ace_in32(ace, ACE_STATUS);
>  +               if (status & ACE_STATUS_CFBSY) {
>  +                       dev_dbg(ace->dev,
>  +                               "CFBSY set; t=%i iter=%i c=%i dc=%i
> irq=%i\n",
>  +                               ace->fsm_task, ace->fsm_iter_num,
>  +                               ace->req->current_nr_sectors * 16,
>  +                               ace->data_count, ace->in_irq);
>  +                       ace_fsm_yield(ace);     /* need to poll CFBSY bit
> */
>  +                       break;
>  +               }
>  +               if (!(status & ACE_STATUS_DATABUFRDY)) {
>  +                       dev_dbg(ace->dev,
>  +                               "DATABUF not set; t=%i iter=%i c=%i dc=%i
> irq=%i\n",
>  +                               ace->fsm_task, ace->fsm_iter_num,
>  +                               ace->req->current_nr_sectors * 16,
>  +                               ace->data_count, ace->in_irq);
>  +                       ace_fsm_yieldirq(ace);
>  +                       break;
>  +               }
>  +
>  +               /* Transfer the next buffer */
>  +               i = 16;
>  +               if (ace->fsm_task == ACE_TASK_WRITE)
>  +                       ace->reg_ops->dataout(ace);
>  +               else
>  +                       ace->reg_ops->datain(ace);
>  +               ace->data_count--;
>  +
>  +               /* If there are still buffers to be transfers; jump out
> here */
>  +               if (ace->data_count != 0) {
>  +                       ace_fsm_yieldirq(ace);
>  +                       break;
>  +               }
>  +
>  +               /* bio finished; is there another one? */
>  +               i = ace->req->current_nr_sectors;
>  +               if (end_that_request_first(ace->req, 1,
> i)) {
>  +                       /* dev_dbg(ace->dev, "next block; h=%li c=%i\n",
>  +                        *      ace->req->hard_nr_sectors,
>  +                        *      ace->req->current_nr_sectors);
>  +                        */
>  +                       ace->data_ptr = ace->req->buffer;
>  +                       ace->data_count = ace->req->current_nr_sectors *
> 16;
>  +                       ace_fsm_yieldirq(ace);
>  +                       break;
>  +               }
>  +
>  +               ace->fsm_state = ACE_FSM_STATE_REQ_COMPLETE;
>  +               break;
>  +
>  +       case ACE_FSM_STATE_REQ_COMPLETE:
>  +               /* Complete the block request */
>  +               blkdev_dequeue_request(ace->req);
>  +               end_that_request_last(ace->req, 1);
>  +               ace->req = NULL;
>  +
>  +               /* Finished request; go to idle state */
>  +               ace->fsm_state = ACE_FSM_STATE_IDLE;
>  +               break;
>  +
>  +       default:
>  +               ace->fsm_state = ACE_FSM_STATE_IDLE;
>  +               break;
>  +       }
>  +}
>  +
>  +static void ace_fsm_tasklet(unsigned long data)
>  +{
>  +       struct ace_device *ace = (void *)data;
>  +       unsigned long flags;
>  +
>  +       spin_lock_irqsave(&ace->lock, flags);
>  +
>  +       /* Loop over state machine until told to stop */
>  +       ace->fsm_continue_flag = 1;
>  +       while (ace->fsm_continue_flag)
>  +               ace_fsm_dostate(ace);
>  +
>  +       spin_unlock_irqrestore(&ace->lock, flags);
>  +}
>  +
>  +static void ace_stall_timer(unsigned long data)
>  +{
>  +       struct ace_device *ace = (void *)data;
>  +       unsigned long flags;
>  +
>  +       dev_warn(ace->dev,
>  +                "kicking stalled fsm; state=%i task=%i iter=%i dc=%i\n",
>  +                ace->fsm_state, ace->fsm_task, ace->fsm_iter_num,
>  +                ace->data_count);
>  +       spin_lock_irqsave(&ace->lock, flags);
>  +
>  +       /* Rearm the stall timer *before* entering FSM (which may then
>  +        * delete the timer) */
>  +       mod_timer(&ace->stall_timer, jiffies + HZ);
>  +
>  +       /* Loop over state machine until told to stop */
>  +       ace->fsm_continue_flag = 1;
>  +       while (ace->fsm_continue_flag)
>  +               ace_fsm_dostate(ace);
>  +
>  +       spin_unlock_irqrestore(&ace->lock, flags);
>  +}
>  +
>  +/*
> ---------------------------------------------------------------------
>  + * Interrupt handling routines
>  + */
>  +static int ace_interrupt_checkstate(struct ace_device *ace)
>  +{
>  +       u32 sreg = ace_in32(ace, ACE_STATUS);
>  +       u16 creg = ace_in(ace, ACE_CTRL);
>  +
>  +       /* Check for error occurance */
>  +       if ((sreg & (ACE_STATUS_CFGERROR | ACE_STATUS_CFCERROR)) &&
>  +           (creg & ACE_CTRL_ERRORIRQ)) {
>  +               dev_err(ace->dev, "transfer failure\n");
>  +               ace_dump_regs(ace);
>  +               return -EIO;
>  +       }
>  +
>  +       return 0;
>  +}
>  +
>  +static irqreturn_t ace_interrupt(int irq, void *dev_id)
>  +{
>  +       u16 creg;
>  +       struct ace_device *ace = dev_id;
>  +
>  +       /* be safe and get the lock */
>  +       spin_lock(&ace->lock);
>  +       ace->in_irq = 1;
>  +
>  +       /* clear the interrupt */
>  +       creg = ace_in(ace, ACE_CTRL);
>  +       ace_out(ace, ACE_CTRL, creg | ACE_CTRL_RESETIRQ);
>  +       ace_out(ace, ACE_CTRL, creg);
>  +
>  +       /* check for IO failures */
>  +       if (ace_interrupt_checkstate(ace))
>  +               ace->data_result = -EIO;
>  +
>  +       if (ace->fsm_task == 0) {
>  +               dev_err(ace->dev,
>  +                       "spurious irq; stat=%.8x ctrl=%.8x cmd=%.4x\n",
>  +                       ace_in32(ace, ACE_STATUS), ace_in32(ace, ACE_CTRL),
>  +                       ace_in(ace, ACE_SECCNTCMD));
>  +               dev_err(ace->dev, "fsm_task=%i fsm_state=%i
> data_count=%i\n",
>  +                       ace->fsm_task, ace->fsm_state, ace->data_count);
>  +       }
>  +
>  +       /* Loop over state machine until told to stop */
>  +       ace->fsm_continue_flag = 1;
>  +       while (ace->fsm_continue_flag)
>  +               ace_fsm_dostate(ace);
>  +
>  +       /* done with interrupt; drop the lock */
>  +       ace->in_irq = 0;
>  +       spin_unlock(&ace->lock);
>  +
>  +       return IRQ_HANDLED;
>  +}
>  +
>  +/*
> ---------------------------------------------------------------------
>  + * Block ops
>  + */
>  +static void ace_request(request_queue_t * q)
>  +{
>  +       struct request *req;
>  +       struct ace_device *ace;
>  +
>  +       req = ace_get_next_request(q);
>  +
>  +       if (req) {
>  +               ace = req->rq_disk->private_data;
>  +               tasklet_schedule(&ace->fsm_tasklet);
>  +       }
>  +}
>  +
>  +static int ace_media_changed(struct gendisk *gd)
>  +{
>  +       struct ace_device *ace = gd->private_data;
>  +       dev_dbg(ace->dev, "ace_media_changed(): %i\n", ace->media_change);
>  +
>  +       return ace->media_change;
>  +}
>  +
>  +static int ace_revalidate_disk(struct gendisk *gd)
>  +{
>  +       struct ace_device *ace = gd->private_data;
>  +       unsigned long flags;
>  +
>  +       dev_dbg(ace->dev, "ace_revalidate_disk()\n");
>  +
>  +       if (ace->media_change) {
>  +               dev_dbg(ace->dev, "requesting cf id and scheduling
> tasklet\n");
>  +
>  +               spin_lock_irqsave(&ace->lock, flags);
>  +               ace->id_req_count++;
>  +               spin_unlock_irqrestore(&ace->lock, flags);
>  +
>  +               tasklet_schedule(&ace->fsm_tasklet);
>  +               wait_for_completion(&ace->id_completion);
>  +       }
>  +
>  +       dev_dbg(ace->dev, "revalidate complete\n");
>  +       return ace->id_result;
>  +}
>  +
>  +static int ace_open(struct inode *inode, struct file *filp)
>  +{
>  +       struct ace_device *ace =
> inode->i_bdev->bd_disk->private_data;
>  +       unsigned long flags;
>  +
>  +       dev_dbg(ace->dev, "ace_open() users=%i\n", ace->users + 1);
>  +
>  +       filp->private_data = ace;
>  +       spin_lock_irqsave(&ace->lock, flags);
>  +       ace->users++;
>  +       spin_unlock_irqrestore(&ace->lock, flags);
>  +
>  +       check_disk_change(inode->i_bdev);
>  +       return 0;
>  +}
>  +
>  +static int ace_release(struct inode *inode, struct file *filp)
>  +{
>  +       struct ace_device *ace =
> inode->i_bdev->bd_disk->private_data;
>  +       unsigned long flags;
>  +       u16 val;
>  +
>  +       dev_dbg(ace->dev, "ace_release() users=%i\n", ace->users - 1);
>  +
>  +       spin_lock_irqsave(&ace->lock, flags);
>  +       ace->users--;
>  +       if (ace->users == 0) {
>  +               val = ace_in(ace, ACE_CTRL);
>  +               ace_out(ace, ACE_CTRL, val & ~ACE_CTRL_LOCKREQ);
>  +       }
>  +       spin_unlock_irqrestore(&ace->lock, flags);
>  +       return 0;
>  +}
>  +
>  +static int ace_ioctl(struct inode *inode, struct file *filp,
>  +                    unsigned int cmd, unsigned long arg)
>  +{
>  +       struct ace_device *ace =
> inode->i_bdev->bd_disk->private_data;
>  +       struct hd_geometry __user *geo = (struct hd_geometry __user *)arg;
>  +       struct hd_geometry g;
>  +       dev_dbg(ace->dev, "ace_ioctl()\n");
>  +
>  +       switch (cmd) {
>  +       case HDIO_GETGEO:
>  +               g.heads = ace->cf_id.heads;
>  +               g.sectors = ace->cf_id.sectors;
>  +               g.cylinders = ace->cf_id.cyls;
>  +               g.start = 0;
>  +               return copy_to_user(geo, &g, sizeof(g)) ? -EFAULT : 0;
>  +
>  +       default:
>  +               return -ENOTTY;
>  +       }
>  +       return -ENOTTY;
>  +}
>  +
>  +static struct block_device_operations ace_fops = {
>  +       .owner = THIS_MODULE,
>  +       .open = ace_open,
>  +       .release = ace_release,
>  +       .media_changed = ace_media_changed,
>  +       .revalidate_disk = ace_revalidate_disk,
>  +       .ioctl = ace_ioctl,
>  +};
>  +
>  +/*
> --------------------------------------------------------------------
>  + * SystemACE device setup/teardown code
>  + */
>  +static int __devinit ace_setup(struct ace_device *ace)
>  +{
>  +       u16 version;
>  +       u16 val;
>  +
>  +       int rc;
>  +
>  +       spin_lock_init(&ace->lock);
>  +       init_completion(&ace->id_completion);
>  +
>  +       /*
>  +        * Map the device
>  +        */
>  +       ace->baseaddr = ioremap(ace->physaddr, 0x80);
>  +       if (!ace->baseaddr)
>  +               goto err_ioremap;
>  +
>  +       if (ace->irq != NO_IRQ) {
>  +               rc = request_irq(ace->irq, ace_interrupt, 0, "systemace",
> ace);
>  +               if (rc) {
>  +                       /* Failure - fall back to polled mode */
>  +                       dev_err(ace->dev, "request_irq failed\n");
>  +                       ace->irq = NO_IRQ;
>  +               }
>  +       }
>  +
>  +       /*
>  +        * Initialize the state machine tasklet and stall timer
>  +        */
>  +       tasklet_init(&ace->fsm_tasklet, ace_fsm_tasklet, (unsigned
> long)ace);
>  +       setup_timer(&ace->stall_timer, ace_stall_timer, (unsigned
> long)ace);
>  +
>  +       /*
>  +        * Initialize the request queue
>  +        */
>  +       ace->queue = blk_init_queue(ace_request, &ace->lock);
>  +       if (ace->queue == NULL)
>  +               goto err_blk_initq;
>  +       blk_queue_hardsect_size(ace->queue, 512);
>  +
>  +       /*
>  +        * Allocate and initialize GD structure
>  +        */
>  +       ace->gd = alloc_disk(ACE_NUM_MINORS);
>  +       if (!ace->gd)
>  +               goto err_alloc_disk;
>  +
>  +       ace->gd->major = ace_major;
>  +       ace->gd->first_minor = ace->id * ACE_NUM_MINORS;
>  +       ace->gd->fops = &ace_fops;
>  +       ace->gd->queue = ace->queue;
>  +       ace->gd->private_data = ace;
>  +       snprintf(ace->gd->disk_name, 32, "xs%c", ace->id + 'a');
>  +       device_rename(ace->dev, ace->gd->disk_name);
>  +
>  +       /* set bus width */
>  +       if (ace->bus_width == 1) {
>  +               /* 0x0101 should work regardless of endianess */
>  +               ace_out_le16(ace, ACE_BUSMODE, 0x0101);
>  +
>  +               /* read it back to determine endianess */
>  +               if (ace_in_le16(ace, ACE_BUSMODE) == 0x0001)
>  +                       ace->reg_ops = &ace_reg_le16_ops;
>  +               else
>  +                       ace->reg_ops = &ace_reg_be16_ops;
>  +       } else {
>  +               ace_out_8(ace, ACE_BUSMODE, 0x00);
>  +               ace->reg_ops = &ace_reg_8_ops;
>  +       }
>  +
>  +       /* Make sure version register is sane */
>  +       version = ace_in(ace, ACE_VERSION);
>  +       if ((version == 0) || (version == 0xFFFF))
>  +               goto err_read;
>  +
>  +       /* Put sysace in a sane state by clearing most control reg bits */
>  +       ace_out(ace, ACE_CTRL, ACE_CTRL_FORCECFGMODE |
>  +               ACE_CTRL_DATABUFRDYIRQ | ACE_CTRL_ERRORIRQ);
>  +
>  +       /* Enable interrupts */
>  +       val = ace_in(ace, ACE_CTRL);
>  +       val |= ACE_CTRL_DATABUFRDYIRQ | ACE_CTRL_ERRORIRQ;
>  +       ace_out(ace, ACE_CTRL, val);
>  +
>  +       /* Print the identification */
>  +       dev_info(ace->dev, "Xilinx SystemACE revision %i.%i.%i\n",
>  +                (version >> 12) & 0xf, (version >> 8) & 0x0f, version &
> 0xff);
>  +       dev_dbg(ace->dev, "physaddr 0x%lx, mapped to 0x%p, irq=%i\n",
>  +               ace->physaddr, ace->baseaddr, ace->irq);
>  +
>  +       ace->media_change = 1;
>  +       ace_revalidate_disk(ace->gd);
>  +
>  +       /* Make the sysace device 'live' */
>  +       add_disk(ace->gd);
>  +
>  +       return 0;
>  +
>  +      err_read:
>  +       put_disk(ace->gd);
>  +      err_alloc_disk:
>  +       blk_cleanup_queue(ace->queue);
>  +      err_blk_initq:
>  +       iounmap(ace->baseaddr);
>  +       if (ace->irq != NO_IRQ)
>  +               free_irq(ace->irq, ace);
>  +      err_ioremap:
>  +       printk(KERN_INFO "xsysace: error initializing device at 0x%lx\n",
>  +              ace->physaddr);
>  +       return -ENOMEM;
>  +}
>  +
>  +static void __devexit ace_teardown(struct ace_device *ace)
>  +{
>  +       if (ace->gd) {
>  +               del_gendisk(ace->gd);
>  +               put_disk(ace->gd);
>  +       }
>  +
>  +       if (ace->queue)
>  +               blk_cleanup_queue(ace->queue);
>  +
>  +       tasklet_kill(&ace->fsm_tasklet);
>  +
>  +       if (ace->irq != NO_IRQ)
>  +               free_irq(ace->irq, ace);
>  +
>  +       iounmap(ace->baseaddr);
>  +}
>  +
>  +/*
> ---------------------------------------------------------------------
>  + * Platform Bus Support
>  + */
>  +
>  +static int __devinit ace_probe(struct device *device)
>  +{
>  +       struct platform_device *dev = to_platform_device(device);
>  +       struct ace_device *ace;
>  +       int i;
>  +
>  +       dev_dbg(device, "ace_probe(%p)\n", device);
>  +
>  +       /*
>  +        * Allocate the ace device structure
>  +        */
>  +       ace = kzalloc(sizeof(struct ace_device), GFP_KERNEL);
>  +       if (!ace)
>  +               goto err_alloc;
>  +
>  +       ace->dev = device;
>  +       ace->id = dev->id;
>  +       ace->irq = NO_IRQ;
>  +
>  +       for (i = 0; i < dev->num_resources; i++) {
>  +               if (dev->resource[i].flags & IORESOURCE_MEM)
>  +                       ace->physaddr = dev->resource[i].start;
>  +               if (dev->resource[i].flags & IORESOURCE_IRQ)
>  +                       ace->irq = dev->resource[i].start;
>  +       }
>  +
>  +       /* FIXME: Should get bus_width from the platform_device struct */
>  +       ace->bus_width = 1;
>  +
>  +       dev_set_drvdata(&dev->dev, ace);
>  +
>  +       /* Call the bus-independant setup code */
>  +       if (ace_setup(ace) != 0)
>  +               goto err_setup;
>  +
>  +       return 0;
>  +
>  +      err_setup:
>  +       dev_set_drvdata(&dev->dev, NULL);
>  +       kfree(ace);
>  +      err_alloc:
>  +       printk(KERN_ERR "xsysace: could not initialize device\n");
>  +       return -ENOMEM;
>  +}
>  +
>  +/*
>  + * Platform bus remove() method
>  + */
>  +static int __devexit ace_remove(struct device *device)
>  +{
>  +       struct ace_device *ace = dev_get_drvdata(device);
>  +
>  +       dev_dbg(device, "ace_remove(%p)\n", device);
>  +
>  +       if (ace) {
>  +               ace_teardown(ace);
>  +               kfree(ace);
>  +       }
>  +
>  +       return 0;
>  +}
>  +
>  +static struct device_driver ace_driver = {
>  +       .name = "xsysace",
>  +       .bus = &platform_bus_type,
>  +       .probe = ace_probe,
>  +       .remove = __devexit_p(ace_remove),
>  +};
>  +
>  +/*
> ---------------------------------------------------------------------
>  + * Module init/exit routines
>  + */
>  +static int __init ace_init(void)
>  +{
>  +       ace_major = register_blkdev(ace_major, "xsysace");
>  +       if (ace_major <= 0) {
>  +               printk(KERN_WARNING "xsysace: register_blkdev() failed\n");
>  +               return ace_major;
>  +       }
>  +
>  +       pr_debug("Registering Xilinx SystemACE driver, major=%i\n",
> ace_major);
>  +       return driver_register(&ace_driver);
>  +}
>  +
>  +static void __exit ace_exit(void)
>  +{
>  +       pr_debug("Unregistering Xilinx SystemACE driver\n");
>  +       driver_unregister(&ace_driver);
>  +       if (unregister_blkdev(ace_major, "xsysace"))
>  +               printk(KERN_WARNING "systemace unregister_blkdev(%i)
> failed\n",
>  +                      ace_major);
>  +}
>  +
>  +module_init(ace_init);
>  +module_exit(ace_exit);
>
>
>  CONFIDENTIALITY
>  This e-mail message and any attachments thereto, is intended only for use
> by the addressee(s) named herein and may contain legally privileged and/or
> confidential information. If you are not the intended recipient of this
> e-mail message, you are hereby notified that any dissemination, distribution
> or copying of this e-mail message, and any attachments thereto, is strictly
> prohibited. If you have received this e-mail message in error, please
> immediately notify the sender and permanently delete the original and any
> copies of this email and any prints thereof.
>  ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT
> INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform
> Electronic Transactions Act or the applicability of any other law of similar
> substance and effect, absent an express statement to the contrary
> hereinabove, this e-mail message its contents, and any attachments hereto
> are not intended to represent an offer or acceptance to enter into a
> contract and are not otherwise intended to bind the sender, Sanmina-SCI
> Corporation (or any of its subsidiaries), or any other person or entity.
>


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195


From joseph.robertson at sanmina-sci.com  Sat Jul 14 02:04:19 2007
From: joseph.robertson at sanmina-sci.com (Robertson, Joseph M.)
Date: Fri, 13 Jul 2007 11:04:19 -0500
Subject: [PATCH] Xilinx SystemACE device driver
References: <20070712225138.13213.38257.stgit@trillian><939D37AEB47F1F49B88FAB6599B6023501A1720B@hsv1dafpew02.das.gov.sanm.corp>
	<fa686aa40707130841w6a36146cufc85a62f78a53b0d@mail.gmail.com>
Message-ID: <939D37AEB47F1F49B88FAB6599B6023501A17210@hsv1dafpew02.das.gov.sanm.corp>

Hi,

Ok, so outlook is a problem.  The horror is that, where I work thats all I can use.  They block all the outside systems like gmail, yahoo, etc.  So under linux, I have to use the web access for outlook.  ugh.  
Why I work here I don't know, they think all software HAS to be bought.

Um, so your patch creates another xsysace.c file, all by itself, which is a NEW driver?  
This replaces the 8 files of the previous driver?  What happens to all the low level funcs?

Where can I get your 2.6.22 tree to see how this is all supposed to go together?  Is there a tar.bz2 package?

Thanks for your patience.


Joe Robertson
x8259
Joseph.Robertson at sanmina-sci.com



-----Original Message-----
From: glikely at secretlab.ca on behalf of Grant Likely
Sent: Fri 7/13/2007 10:41 AM
To: Robertson, Joseph M.; Linux PPC Linux PPC
Subject: Re: [PATCH] Xilinx SystemACE device driver
 
On 7/13/07, Robertson, Joseph M. <joseph.robertson at sanmina-sci.com> wrote:
>
>
>
> Hi,
>
>  I apologize if I am just being dense, but cannot get this patch to work.

BTW, please make sure you CC the mailing list when asking questions.
That way more people than just me can offer answers.

You will probably get conflicts when applying the patch which you need
to fixup, but the conflicts should be limited to Kconfig and Makefile.

>  I get the same problem.
>  What command do you use to apply the patch?  patch -p1 < filename
>  I put file in kernel root and change b/drivers/block/xsysace.c ->
> b/drivers/block/xilinx_sysace/xsysace.c  (the 'old'
> location?)

Yes, 'patch -p1 < file' is the correct command.  Make sure you start
at the top of the Linux kernel source tree.  Also make sure that you
are using the raw email that I sent you.  Do *NOT* try to copy and
paste from your mail client.  It will not work.  Outlook is
particularly bad for working with patches, so if you can change mail
clients, or start using a gmail account, your life will get easier.

>  I thought I had a too old version of patch, but its actually later than the
> gnu website(2.5.4), I have 2.5.9

The patch format is *very* stable.  This is certainly not your problem.
>
>  Can you post the complete file for xsysace v1.01a somewhere?
>  Or tell me, does the xsysace.c code completely replace the previous
> xsysace.c file?

The new driver is a 100% rewrite.  In fact, the old and new drivers
can coexist side-by-side.  The new driver is fully contained in a
single source file (xsysace.c).

>
>  Or perhaps point out what xsysace bug we need to fix?

I have no idea.  I cannot say without trying to reproduce the problem,
and 2.6.17 is far to old for me to want to twiddle with.

What xilinx devices are you using?  TEMAC, SystemACE I know.  Any others?

>
>  Thanks a lot.  I hope to be able to contribute one day.

:-)

>
>  Joe Robertson
>  x8259
>  Joseph.Robertson at sanmina-sci.com
>
>
>
>  -----Original Message-----
>  From: Grant Likely [mailto:grant.likely at secretlab.ca]
>  Sent: Thu 7/12/2007 5:51 PM
>  To: Robertson at secretlab.ca; Robertson, Joseph M.
>  Subject: [PATCH] Xilinx SystemACE device driver
>
>  From: Grant Likely <grant.likely at secretlab.ca>
>
>  Add support for block device access to the Xilinx SystemACE Compact
>  flash interface
>
>  Signed-off-by: Grant Likely <grant.likely at secretlab.ca>
>  ---
>
>   drivers/block/Kconfig   |    6
>   drivers/block/Makefile  |    1
>   drivers/block/xsysace.c | 1167
> +++++++++++++++++++++++++++++++++++++++++++++++
>   3 files changed, 1174 insertions(+), 0 deletions(-)
>
>  diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
>  index b4c8319..184b30d 100644
>  --- a/drivers/block/Kconfig
>  +++ b/drivers/block/Kconfig
>  @@ -453,6 +453,12 @@ config ATA_OVER_ETH
>
>   source "drivers/s390/block/Kconfig"
>
>  +config XILINX_SYSACE
>  +       tristate "Xilinx SystemACE support"
>  +       depends on 4xx
>  +       help
>  +         Include support for the Xilinx SystemACE CompactFlash interface
>  +
>   endmenu
>
>   endif
>  diff --git a/drivers/block/Makefile b/drivers/block/Makefile
>  index dd88e33..31ea323 100644
>  --- a/drivers/block/Makefile
>  +++ b/drivers/block/Makefile
>  @@ -28,4 +28,5 @@ obj-$(CONFIG_BLK_DEV_CRYPTOLOOP) +=
> cryptoloop.o
>   obj-$(CONFIG_VIODASD)          += viodasd.o
>   obj-$(CONFIG_BLK_DEV_SX8)      += sx8.o
>   obj-$(CONFIG_BLK_DEV_UB)       += ub.o
>  +obj-$(CONFIG_XILINX_SYSACE)    += xsysace.o
>
>  diff --git a/drivers/block/xsysace.c b/drivers/block/xsysace.c
>  new file mode 100644
>  index 0000000..f8602e6
>  --- /dev/null
>  +++ b/drivers/block/xsysace.c
>  @@ -0,0 +1,1167 @@
>  +/*
>  + * Xilinx SystemACE device driver
>  + *
>  + * Copyright 2007 Secret Lab Technologies Ltd.
>  + *
>  + * This program is free software; you can redistribute it and/or modify it
>  + * under the terms of the GNU General Public License version 2 as
> published
>  + * by the Free Software Foundation.
>  + */
>  +
>  +/*
>  + * The SystemACE chip is designed to configure FPGAs by loading an FPGA
>  + * bitstream from a file on a CF card and squirting it into FPGAs
> connected
>  + * to the SystemACE JTAG chain.  It also has the advantage of providing an
>  + * MPU interface which can be used to control the FPGA configuration
> process
>  + * and to use the attached CF card for general purpose storage.
>  + *
>  + * This driver is a block device driver for the SystemACE.
>  + *
>  + * Initialization:
>  + *    The driver registers itself as a platform_device driver at module
>  + *    load time.  The platform bus will take care of calling the
>  + *    ace_probe() method for all SystemACE instances in the system.  Any
>  + *    number of SystemACE instances are supported.  ace_probe() calls
>  + *    ace_setup() which initialized all data structures, reads the CF
>  + *    id structure and registers the device.
>  + *
>  + * Processing:
>  + *    Just about all of the heavy lifting in this driver is performed by
>  + *    a Finite State Machine (FSM).  The driver needs to wait on a number
>  + *    of events; some raised by interrupts, some which need to be polled
>  + *    for.  Describing all of the behaviour in a FSM seems to be the
>  + *    easiest way to keep the complexity low and make it easy to
>  + *    understand what the driver is doing.  If the block ops or the
>  + *    request function need to interact with the hardware, then they
>  + *    simply need to flag the request and kick of FSM processing.
>  + *
>  + *    The FSM itself is atomic-safe code which can be run from any
>  + *    context.  The general process flow is:
>  + *    1. obtain the ace->lock spinlock.
>  + *    2. loop on ace_fsm_dostate() until the ace->fsm_continue flag is
>  + *       cleared.
>  + *    3. release the lock.
>  + *
>  + *    Individual states do not sleep in any way.  If a condition needs to
>  + *    be waited for then the state much clear the fsm_continue flag and
>  + *    either schedule the FSM to be run again at a later time, or expect
>  + *    an interrupt to call the FSM when the desired condition is met.
>  + *
>  + *    In normal operation, the FSM is processed at interrupt context
>  + *    either when the driver's tasklet is scheduled, or when an irq is
>  + *    raised by the hardware.  The tasklet can be scheduled at any time.
>  + *    The request method in particular schedules the tasklet when a new
>  + *    request has been indicated by the block layer.  Once started, the
>  + *    FSM proceeds as far as it can processing the request until it
>  + *    needs on a hardware event.  At this point, it must yield execution.
>  + *
>  + *    A state has two options when yielding execution:
>  + *    1. ace_fsm_yield()
>  + *       - Call if need to poll for event.
>  + *       - clears the fsm_continue flag to exit the processing loop
>  + *       - reschedules the tasklet to run again as soon as possible
>  + *    2. ace_fsm_yieldirq()
>  + *       - Call if an irq is expected from the HW
>  + *       - clears the fsm_continue flag to exit the processing loop
>  + *       - does not reschedule the tasklet so the FSM will not be
> processed
>  + *         again until an irq is received.
>  + *    After calling a yield function, the state must return control back
>  + *    to the FSM main loop.
>  + *
>  + *    Additionally, the driver maintains a kernel timer which can process
>  + *    the FSM.  If the FSM gets stalled, typically due to a missed
>  + *    interrupt, then the kernel timer will expire and the driver can
>  + *    continue where it left off.
>  + *
>  + * To Do:
>  + *    - Add FPGA configuration control interface.
>  + *    - Request major number from lanana
>  + */
>  +
>  +#undef DEBUG
>  +
>  +#include <linux/module.h>
>  +#include <linux/ctype.h>
>  +#include <linux/init.h>
>  +#include <linux/interrupt.h>
>  +#include <linux/errno.h>
>  +#include <linux/kernel.h>
>  +#include <linux/delay.h>
>  +#include <linux/slab.h>
>  +#include <linux/blkdev.h>
>  +#include <linux/hdreg.h>
>  +#include <linux/platform_device.h>
>  +
>  +MODULE_AUTHOR("Grant Likely <grant.likely at secretlab.ca>");
>  +MODULE_DESCRIPTION("Xilinx SystemACE device driver");
>  +MODULE_LICENSE("GPL");
>  +
>  +/* SystemACE register definitions */
>  +#define ACE_BUSMODE (0x00)
>  +
>  +#define ACE_STATUS (0x04)
>  +#define ACE_STATUS_CFGLOCK      (0x00000001)
>  +#define ACE_STATUS_MPULOCK      (0x00000002)
>  +#define ACE_STATUS_CFGERROR     (0x00000004)   /* config controller error
> */
>  +#define ACE_STATUS_CFCERROR     (0x00000008)   /* CF controller error */
>  +#define ACE_STATUS_CFDETECT     (0x00000010)
>  +#define ACE_STATUS_DATABUFRDY   (0x00000020)
>  +#define ACE_STATUS_DATABUFMODE  (0x00000040)
>  +#define ACE_STATUS_CFGDONE      (0x00000080)
>  +#define ACE_STATUS_RDYFORCFCMD  (0x00000100)
>  +#define ACE_STATUS_CFGMODEPIN   (0x00000200)
>  +#define ACE_STATUS_CFGADDR_MASK (0x0000e000)
>  +#define ACE_STATUS_CFBSY        (0x00020000)
>  +#define ACE_STATUS_CFRDY        (0x00040000)
>  +#define ACE_STATUS_CFDWF        (0x00080000)
>  +#define ACE_STATUS_CFDSC        (0x00100000)
>  +#define ACE_STATUS_CFDRQ        (0x00200000)
>  +#define ACE_STATUS_CFCORR       (0x00400000)
>  +#define ACE_STATUS_CFERR        (0x00800000)
>  +
>  +#define ACE_ERROR (0x08)
>  +#define ACE_CFGLBA (0x0c)
>  +#define ACE_MPULBA (0x10)
>  +
>  +#define ACE_SECCNTCMD (0x14)
>  +#define ACE_SECCNTCMD_RESET      (0x0100)
>  +#define ACE_SECCNTCMD_IDENTIFY   (0x0200)
>  +#define ACE_SECCNTCMD_READ_DATA  (0x0300)
>  +#define ACE_SECCNTCMD_WRITE_DATA (0x0400)
>  +#define ACE_SECCNTCMD_ABORT      (0x0600)
>  +
>  +#define ACE_VERSION (0x16)
>  +#define ACE_VERSION_REVISION_MASK (0x00FF)
>  +#define ACE_VERSION_MINOR_MASK    (0x0F00)
>  +#define ACE_VERSION_MAJOR_MASK    (0xF000)
>  +
>  +#define ACE_CTRL (0x18)
>  +#define ACE_CTRL_FORCELOCKREQ   (0x0001)
>  +#define ACE_CTRL_LOCKREQ        (0x0002)
>  +#define ACE_CTRL_FORCECFGADDR   (0x0004)
>  +#define ACE_CTRL_FORCECFGMODE   (0x0008)
>  +#define ACE_CTRL_CFGMODE        (0x0010)
>  +#define ACE_CTRL_CFGSTART       (0x0020)
>  +#define ACE_CTRL_CFGSEL         (0x0040)
>  +#define ACE_CTRL_CFGRESET       (0x0080)
>  +#define ACE_CTRL_DATABUFRDYIRQ  (0x0100)
>  +#define ACE_CTRL_ERRORIRQ       (0x0200)
>  +#define ACE_CTRL_CFGDONEIRQ     (0x0400)
>  +#define ACE_CTRL_RESETIRQ       (0x0800)
>  +#define ACE_CTRL_CFGPROG        (0x1000)
>  +#define ACE_CTRL_CFGADDR_MASK   (0xe000)
>  +
>  +#define ACE_FATSTAT (0x1c)
>  +
>  +#define ACE_NUM_MINORS 16
>  +#define ACE_SECTOR_SIZE (512)
>  +#define ACE_FIFO_SIZE (32)
>  +#define ACE_BUF_PER_SECTOR (ACE_SECTOR_SIZE / ACE_FIFO_SIZE)
>  +
>  +struct ace_reg_ops;
>  +
>  +struct ace_device {
>  +       /* driver state data */
>  +       int id;
>  +       int media_change;
>  +       int users;
>  +       struct list_head list;
>  +
>  +       /* finite state machine data */
>  +       struct tasklet_struct fsm_tasklet;
>  +       uint fsm_task;          /* Current activity (ACE_TASK_*) */
>  +       uint fsm_state;         /* Current state (ACE_FSM_STATE_*) */
>  +       uint fsm_continue_flag; /* cleared to exit FSM mainloop */
>  +       uint fsm_iter_num;
>  +       struct timer_list stall_timer;
>  +
>  +       /* Transfer state/result, use for both id and block request */
>  +       struct request *req;    /* request being processed */
>  +       void *data_ptr;         /* pointer to I/O buffer */
>  +       int data_count;         /* number of buffers remaining */
>  +       int data_result;        /* Result of transfer; 0 := success */
>  +
>  +       int id_req_count;       /* count of id requests */
>  +       int id_result;
>  +       struct completion id_completion;        /* used when id req
> finishes */
>  +       int in_irq;
>  +
>  +       /* Details of hardware device */
>  +       unsigned long physaddr;
>  +       void *baseaddr;
>  +       int irq;
>  +       int bus_width;          /* 0 := 8 bit; 1 := 16 bit */
>  +       struct ace_reg_ops *reg_ops;
>  +       int lock_count;
>  +
>  +       /* Block device data structures */
>  +       spinlock_t lock;
>  +       struct device *dev;
>  +       struct request_queue *queue;
>  +       struct gendisk *gd;
>  +
>  +       /* Inserted CF card parameters */
>  +       struct hd_driveid cf_id;
>  +};
>  +
>  +static int ace_major;
>  +
>  +/*
> ---------------------------------------------------------------------
>  + * Low level register access
>  + */
>  +
>  +struct ace_reg_ops {
>  +       u16(*in) (struct ace_device * ace, int reg);
>  +       void (*out) (struct ace_device * ace, int reg, u16 val);
>  +       void (*datain) (struct ace_device * ace);
>  +       void (*dataout) (struct ace_device * ace);
>  +};
>  +
>  +/* 8 Bit bus width */
>  +static u16 ace_in_8(struct ace_device *ace, int reg)
>  +{
>  +       void *r = ace->baseaddr + reg;
>  +       return in_8(r) | (in_8(r + 1) << 8);
>  +}
>  +
>  +static void ace_out_8(struct ace_device *ace, int reg, u16 val)
>  +{
>  +       void *r = ace->baseaddr + reg;
>  +       out_8(r, val);
>  +       out_8(r + 1, val >> 8);
>  +}
>  +
>  +static void ace_datain_8(struct ace_device *ace)
>  +{
>  +       void *r = ace->baseaddr + 0x40;
>  +       u8 *dst = ace->data_ptr;
>  +       int i = ACE_FIFO_SIZE;
>  +       while (i--)
>  +               *dst++ = in_8(r++);
>  +       ace->data_ptr = dst;
>  +}
>  +
>  +static void ace_dataout_8(struct ace_device *ace)
>  +{
>  +       void *r = ace->baseaddr + 0x40;
>  +       u8 *src = ace->data_ptr;
>  +       int i = ACE_FIFO_SIZE;
>  +       while (i--)
>  +               out_8(r++, *src++);
>  +       ace->data_ptr = src;
>  +}
>  +
>  +static struct ace_reg_ops ace_reg_8_ops = {
>  +       .in = ace_in_8,
>  +       .out = ace_out_8,
>  +       .datain = ace_datain_8,
>  +       .dataout = ace_dataout_8,
>  +};
>  +
>  +/* 16 bit big endian bus attachment */
>  +static u16 ace_in_be16(struct ace_device *ace, int reg)
>  +{
>  +       return in_be16(ace->baseaddr + reg);
>  +}
>  +
>  +static void ace_out_be16(struct ace_device *ace, int reg, u16 val)
>  +{
>  +       out_be16(ace->baseaddr + reg, val);
>  +}
>  +
>  +static void ace_datain_be16(struct ace_device *ace)
>  +{
>  +       int i = ACE_FIFO_SIZE / 2;
>  +       u16 *dst = ace->data_ptr;
>  +       while (i--)
>  +               *dst++ = in_le16(ace->baseaddr + 0x40);
>  +       ace->data_ptr = dst;
>  +}
>  +
>  +static void ace_dataout_be16(struct ace_device *ace)
>  +{
>  +       int i = ACE_FIFO_SIZE / 2;
>  +       u16 *src = ace->data_ptr;
>  +       while (i--)
>  +               out_le16(ace->baseaddr + 0x40, *src++);
>  +       ace->data_ptr = src;
>  +}
>  +
>  +/* 16 bit little endian bus attachment */
>  +static u16 ace_in_le16(struct ace_device *ace, int reg)
>  +{
>  +       return in_le16(ace->baseaddr + reg);
>  +}
>  +
>  +static void ace_out_le16(struct ace_device *ace, int reg, u16 val)
>  +{
>  +       out_le16(ace->baseaddr + reg, val);
>  +}
>  +
>  +static void ace_datain_le16(struct ace_device *ace)
>  +{
>  +       int i = ACE_FIFO_SIZE / 2;
>  +       u16 *dst = ace->data_ptr;
>  +       while (i--)
>  +               *dst++ = in_be16(ace->baseaddr + 0x40);
>  +       ace->data_ptr = dst;
>  +}
>  +
>  +static void ace_dataout_le16(struct ace_device *ace)
>  +{
>  +       int i = ACE_FIFO_SIZE / 2;
>  +       u16 *src = ace->data_ptr;
>  +       while (i--)
>  +               out_be16(ace->baseaddr + 0x40, *src++);
>  +       ace->data_ptr = src;
>  +}
>  +
>  +static struct ace_reg_ops ace_reg_be16_ops = {
>  +       .in = ace_in_be16,
>  +       .out = ace_out_be16,
>  +       .datain = ace_datain_be16,
>  +       .dataout = ace_dataout_be16,
>  +};
>  +
>  +static struct ace_reg_ops ace_reg_le16_ops = {
>  +       .in = ace_in_le16,
>  +       .out = ace_out_le16,
>  +       .datain = ace_datain_le16,
>  +       .dataout = ace_dataout_le16,
>  +};
>  +
>  +static inline u16 ace_in(struct ace_device *ace, int reg)
>  +{
>  +       return ace->reg_ops->in(ace, reg);
>  +}
>  +
>  +static inline u32 ace_in32(struct ace_device *ace, int reg)
>  +{
>  +       return ace_in(ace, reg) | (ace_in(ace, reg + 2) << 16);
>  +}
>  +
>  +static inline void ace_out(struct ace_device *ace, int reg, u16 val)
>  +{
>  +       ace->reg_ops->out(ace, reg, val);
>  +}
>  +
>  +static inline void ace_out32(struct ace_device *ace, int reg, u32 val)
>  +{
>  +       ace_out(ace, reg, val);
>  +       ace_out(ace, reg + 2, val >> 16);
>  +}
>  +
>  +/*
> ---------------------------------------------------------------------
>  + * Debug support functions
>  + */
>  +
>  +#if defined(DEBUG)
>  +static void ace_dump_mem(void *base, int len)
>  +{
>  +       const char *ptr = base;
>  +       int i, j;
>  +
>  +       for (i = 0; i < len; i += 16) {
>  +               printk(KERN_INFO "%.8x:", i);
>  +               for (j = 0; j < 16; j++) {
>  +                       if (!(j % 4))
>  +                               printk(" ");
>  +                       printk("%.2x", ptr[i + j]);
>  +               }
>  +               printk(" ");
>  +               for (j = 0; j < 16; j++)
>  +                       printk("%c", isprint(ptr[i + j]) ? ptr[i + j] :
> '.');
>  +               printk("\n");
>  +       }
>  +}
>  +#else
>  +static inline void ace_dump_mem(void *base, int len)
>  +{
>  +}
>  +#endif
>  +
>  +static void ace_dump_regs(struct ace_device *ace)
>  +{
>  +       dev_info(ace->dev, "    ctrl:  %.8x  seccnt/cmd: %.4x
> ver:%.4x\n"
>  +                "    status:%.8x  mpu_lba:%.8x  busmode:%4x\n"
>  +                "    error: %.8x  cfg_lba:%.8x  fatstat:%.4x\n",
>  +                ace_in32(ace, ACE_CTRL),
>  +                ace_in(ace, ACE_SECCNTCMD),
>  +                ace_in(ace, ACE_VERSION),
>  +                ace_in32(ace, ACE_STATUS),
>  +                ace_in32(ace, ACE_MPULBA),
>  +                ace_in(ace, ACE_BUSMODE),
>  +                ace_in32(ace, ACE_ERROR),
>  +                ace_in32(ace, ACE_CFGLBA), ace_in(ace, ACE_FATSTAT));
>  +}
>  +
>  +void ace_fix_driveid(struct hd_driveid *id)
>  +{
>  +#if defined(__BIG_ENDIAN)
>  +       u16 *buf = (void *)id;
>  +       int i;
>  +
>  +       /* All half words have wrong byte order; swap the bytes */
>  +       for (i = 0; i < sizeof(struct hd_driveid); i += 2, buf++)
>  +               *buf = le16_to_cpu(*buf);
>  +
>  +       /* Some of the data values are 32bit; swap the half words  */
>  +       id->lba_capacity = ((id->lba_capacity >> 16) & 0x0000FFFF) |
>  +           ((id->lba_capacity << 16) & 0xFFFF0000);
>  +       id->spg = ((id->spg >> 16) & 0x0000FFFF) |
>  +           ((id->spg << 16) & 0xFFFF0000);
>  +#endif
>  +}
>  +
>  +/*
> ---------------------------------------------------------------------
>  + * Finite State Machine (FSM) implementation
>  + */
>  +
>  +/* FSM tasks; used to direct state transitions */
>  +#define ACE_TASK_IDLE      0
>  +#define ACE_TASK_IDENTIFY  1
>  +#define ACE_TASK_READ      2
>  +#define ACE_TASK_WRITE     3
>  +#define ACE_FSM_NUM_TASKS  4
>  +
>  +/* FSM state definitions */
>  +#define ACE_FSM_STATE_IDLE               0
>  +#define ACE_FSM_STATE_REQ_LOCK           1
>  +#define ACE_FSM_STATE_WAIT_LOCK          2
>  +#define ACE_FSM_STATE_WAIT_CFREADY       3
>  +#define ACE_FSM_STATE_IDENTIFY_PREPARE   4
>  +#define ACE_FSM_STATE_IDENTIFY_TRANSFER  5
>  +#define ACE_FSM_STATE_IDENTIFY_COMPLETE  6
>  +#define ACE_FSM_STATE_REQ_PREPARE        7
>  +#define ACE_FSM_STATE_REQ_TRANSFER       8
>  +#define ACE_FSM_STATE_REQ_COMPLETE       9
>  +#define ACE_FSM_STATE_ERROR             10
>  +#define ACE_FSM_NUM_STATES              11
>  +
>  +/* Set flag to exit FSM loop and reschedule tasklet */
>  +static inline void ace_fsm_yield(struct ace_device *ace)
>  +{
>  +       dev_dbg(ace->dev, "ace_fsm_yield()\n");
>  +       tasklet_schedule(&ace->fsm_tasklet);
>  +       ace->fsm_continue_flag = 0;
>  +}
>  +
>  +/* Set flag to exit FSM loop and wait for IRQ to reschedule tasklet */
>  +static inline void ace_fsm_yieldirq(struct ace_device *ace)
>  +{
>  +       dev_dbg(ace->dev, "ace_fsm_yieldirq()\n");
>  +
>  +       if (ace->irq == NO_IRQ)
>  +               /* No IRQ assigned, so need to poll */
>  +               tasklet_schedule(&ace->fsm_tasklet);
>  +       ace->fsm_continue_flag = 0;
>  +}
>  +
>  +/* Get the next read/write request; ending requests that we don't handle
> */
>  +struct request *ace_get_next_request(request_queue_t * q)
>  +{
>  +       struct request *req;
>  +
>  +       while ((req = elv_next_request(q)) != NULL) {
>  +               if (blk_fs_request(req))
>  +                       break;
>  +               end_request(req, 0);
>  +       }
>  +       return req;
>  +}
>  +
>  +static void ace_fsm_dostate(struct ace_device *ace)
>  +{
>  +       struct request *req;
>  +       u32 status;
>  +       u16 val;
>  +       int count;
>  +       int i;
>  +
>  +#if defined(DEBUG)
>  +       dev_dbg(ace->dev, "fsm_state=%i, id_req_count=%i\n",
>  +               ace->fsm_state, ace->id_req_count);
>  +#endif
>  +
>  +       switch (ace->fsm_state) {
>  +       case ACE_FSM_STATE_IDLE:
>  +               /* See if there is anything to do */
>  +               if (ace->id_req_count ||
> ace_get_next_request(ace->queue)) {
>  +                       ace->fsm_iter_num++;
>  +                       ace->fsm_state = ACE_FSM_STATE_REQ_LOCK;
>  +                       mod_timer(&ace->stall_timer, jiffies + HZ);
>  +                       if
> (!timer_pending(&ace->stall_timer))
>  +                               add_timer(&ace->stall_timer);
>  +                       break;
>  +               }
>  +               del_timer(&ace->stall_timer);
>  +               ace->fsm_continue_flag = 0;
>  +               break;
>  +
>  +       case ACE_FSM_STATE_REQ_LOCK:
>  +               if (ace_in(ace, ACE_STATUS) & ACE_STATUS_MPULOCK) {
>  +                       /* Already have the lock, jump to next state */
>  +                       ace->fsm_state = ACE_FSM_STATE_WAIT_CFREADY;
>  +                       break;
>  +               }
>  +
>  +               /* Request the lock */
>  +               val = ace_in(ace, ACE_CTRL);
>  +               ace_out(ace, ACE_CTRL, val | ACE_CTRL_LOCKREQ);
>  +               ace->fsm_state = ACE_FSM_STATE_WAIT_LOCK;
>  +               break;
>  +
>  +       case ACE_FSM_STATE_WAIT_LOCK:
>  +               if (ace_in(ace, ACE_STATUS) & ACE_STATUS_MPULOCK) {
>  +                       /* got the lock; move to next state */
>  +                       ace->fsm_state = ACE_FSM_STATE_WAIT_CFREADY;
>  +                       break;
>  +               }
>  +
>  +               /* wait a bit for the lock */
>  +               ace_fsm_yield(ace);
>  +               break;
>  +
>  +       case ACE_FSM_STATE_WAIT_CFREADY:
>  +               status = ace_in32(ace, ACE_STATUS);
>  +               if (!(status & ACE_STATUS_RDYFORCFCMD) ||
>  +                   (status & ACE_STATUS_CFBSY)) {
>  +                       /* CF card isn't ready; it needs to be polled */
>  +                       ace_fsm_yield(ace);
>  +                       break;
>  +               }
>  +
>  +               /* Device is ready for command; determine what to do next
> */
>  +               if (ace->id_req_count)
>  +                       ace->fsm_state = ACE_FSM_STATE_IDENTIFY_PREPARE;
>  +               else
>  +                       ace->fsm_state = ACE_FSM_STATE_REQ_PREPARE;
>  +               break;
>  +
>  +       case ACE_FSM_STATE_IDENTIFY_PREPARE:
>  +               /* Send identify command */
>  +               ace->fsm_task = ACE_TASK_IDENTIFY;
>  +               ace->data_ptr = &ace->cf_id;
>  +               ace->data_count = ACE_BUF_PER_SECTOR;
>  +               ace_out(ace, ACE_SECCNTCMD, ACE_SECCNTCMD_IDENTIFY);
>  +
>  +               /* As per datasheet, put config controller in reset */
>  +               val = ace_in(ace, ACE_CTRL);
>  +               ace_out(ace, ACE_CTRL, val | ACE_CTRL_CFGRESET);
>  +
>  +               /* irq handler takes over from this point; wait for the
>  +                * transfer to complete */
>  +               ace->fsm_state =
> ACE_FSM_STATE_IDENTIFY_TRANSFER;
>  +               ace_fsm_yieldirq(ace);
>  +               break;
>  +
>  +       case ACE_FSM_STATE_IDENTIFY_TRANSFER:
>  +               /* Check that the sysace is ready to receive data */
>  +               status = ace_in32(ace, ACE_STATUS);
>  +               if (status & ACE_STATUS_CFBSY) {
>  +                       dev_dbg(ace->dev, "CFBSY set; t=%i iter=%i
> dc=%i\n",
>  +                               ace->fsm_task, ace->fsm_iter_num,
>  +                               ace->data_count);
>  +                       ace_fsm_yield(ace);
>  +                       break;
>  +               }
>  +               if (!(status & ACE_STATUS_DATABUFRDY)) {
>  +                       ace_fsm_yield(ace);
>  +                       break;
>  +               }
>  +
>  +               /* Transfer the next buffer */
>  +               ace->reg_ops->datain(ace);
>  +               ace->data_count--;
>  +
>  +               /* If there are still buffers to be transfers; jump out
> here */
>  +               if (ace->data_count != 0) {
>  +                       ace_fsm_yieldirq(ace);
>  +                       break;
>  +               }
>  +
>  +               /* transfer finished; kick state machine */
>  +               dev_dbg(ace->dev, "identify finished\n");
>  +               ace->fsm_state =
> ACE_FSM_STATE_IDENTIFY_COMPLETE;
>  +               break;
>  +
>  +       case ACE_FSM_STATE_IDENTIFY_COMPLETE:
>  +               ace_fix_driveid(&ace->cf_id);
>  +               ace_dump_mem(&ace->cf_id, 512); /* Debug: Dump out disk ID
> */
>  +
>  +               if (ace->data_result) {
>  +                       /* Error occured, disable the disk */
>  +                       ace->media_change = 1;
>  +                       set_capacity(ace->gd, 0);
>  +                       dev_err(ace->dev, "error fetching CF id (%i)\n",
>  +                               ace->data_result);
>  +               } else {
>  +                       ace->media_change = 0;
>  +
>  +                       /* Record disk parameters */
>  +                       set_capacity(ace->gd, ace->cf_id.lba_capacity);
>  +                       dev_info(ace->dev, "capacity: %i sectors\n",
>  +                                ace->cf_id.lba_capacity);
>  +               }
>  +
>  +               /* We're done, drop to IDLE state and notify waiters */
>  +               ace->fsm_state = ACE_FSM_STATE_IDLE;
>  +               ace->id_result = ace->data_result;
>  +               while (ace->id_req_count) {
>  +                       complete(&ace->id_completion);
>  +                       ace->id_req_count--;
>  +               }
>  +               break;
>  +
>  +       case ACE_FSM_STATE_REQ_PREPARE:
>  +               req = ace_get_next_request(ace->queue);
>  +               if (!req) {
>  +                       ace->fsm_state = ACE_FSM_STATE_IDLE;
>  +                       break;
>  +               }
>  +
>  +               /* Okay, it's a data request, set it up for transfer */
>  +               dev_dbg(ace->dev,
>  +                       "request: sec=%lx hcnt=%lx, ccnt=%x, dir=%i\n",
>  +                       req->sector, req->hard_nr_sectors,
>  +                       req->current_nr_sectors, rq_data_dir(req));
>  +
>  +               ace->req = req;
>  +               ace->data_ptr = req->buffer;
>  +               ace->data_count = req->current_nr_sectors *
> ACE_BUF_PER_SECTOR;
>  +               ace_out32(ace, ACE_MPULBA, req->sector & 0x0FFFFFFF);
>  +
>  +               count = req->hard_nr_sectors;
>  +               if (rq_data_dir(req)) {
>  +                       /* Kick off write request */
>  +                       dev_dbg(ace->dev, "write data\n");
>  +                       ace->fsm_task = ACE_TASK_WRITE;
>  +                       ace_out(ace, ACE_SECCNTCMD,
>  +                               count | ACE_SECCNTCMD_WRITE_DATA);
>  +               } else {
>  +                       /* Kick off read request */
>  +                       dev_dbg(ace->dev, "read data\n");
>  +                       ace->fsm_task = ACE_TASK_READ;
>  +                       ace_out(ace, ACE_SECCNTCMD,
>  +                               count | ACE_SECCNTCMD_READ_DATA);
>  +               }
>  +
>  +               /* As per datasheet, put config controller in reset */
>  +               val = ace_in(ace, ACE_CTRL);
>  +               ace_out(ace, ACE_CTRL, val | ACE_CTRL_CFGRESET);
>  +
>  +               /* Move to the transfer state.  The systemace will raise
>  +                * an interrupt once there is something to do
>  +                */
>  +               ace->fsm_state = ACE_FSM_STATE_REQ_TRANSFER;
>  +               if (ace->fsm_task == ACE_TASK_READ)
>  +                       ace_fsm_yieldirq(ace);  /* wait for data ready */
>  +               break;
>  +
>  +       case ACE_FSM_STATE_REQ_TRANSFER:
>  +               /* Check that the sysace is ready to receive data */
>  +               status = ace_in32(ace, ACE_STATUS);
>  +               if (status & ACE_STATUS_CFBSY) {
>  +                       dev_dbg(ace->dev,
>  +                               "CFBSY set; t=%i iter=%i c=%i dc=%i
> irq=%i\n",
>  +                               ace->fsm_task, ace->fsm_iter_num,
>  +                               ace->req->current_nr_sectors * 16,
>  +                               ace->data_count, ace->in_irq);
>  +                       ace_fsm_yield(ace);     /* need to poll CFBSY bit
> */
>  +                       break;
>  +               }
>  +               if (!(status & ACE_STATUS_DATABUFRDY)) {
>  +                       dev_dbg(ace->dev,
>  +                               "DATABUF not set; t=%i iter=%i c=%i dc=%i
> irq=%i\n",
>  +                               ace->fsm_task, ace->fsm_iter_num,
>  +                               ace->req->current_nr_sectors * 16,
>  +                               ace->data_count, ace->in_irq);
>  +                       ace_fsm_yieldirq(ace);
>  +                       break;
>  +               }
>  +
>  +               /* Transfer the next buffer */
>  +               i = 16;
>  +               if (ace->fsm_task == ACE_TASK_WRITE)
>  +                       ace->reg_ops->dataout(ace);
>  +               else
>  +                       ace->reg_ops->datain(ace);
>  +               ace->data_count--;
>  +
>  +               /* If there are still buffers to be transfers; jump out
> here */
>  +               if (ace->data_count != 0) {
>  +                       ace_fsm_yieldirq(ace);
>  +                       break;
>  +               }
>  +
>  +               /* bio finished; is there another one? */
>  +               i = ace->req->current_nr_sectors;
>  +               if (end_that_request_first(ace->req, 1,
> i)) {
>  +                       /* dev_dbg(ace->dev, "next block; h=%li c=%i\n",
>  +                        *      ace->req->hard_nr_sectors,
>  +                        *      ace->req->current_nr_sectors);
>  +                        */
>  +                       ace->data_ptr = ace->req->buffer;
>  +                       ace->data_count = ace->req->current_nr_sectors *
> 16;
>  +                       ace_fsm_yieldirq(ace);
>  +                       break;
>  +               }
>  +
>  +               ace->fsm_state = ACE_FSM_STATE_REQ_COMPLETE;
>  +               break;
>  +
>  +       case ACE_FSM_STATE_REQ_COMPLETE:
>  +               /* Complete the block request */
>  +               blkdev_dequeue_request(ace->req);
>  +               end_that_request_last(ace->req, 1);
>  +               ace->req = NULL;
>  +
>  +               /* Finished request; go to idle state */
>  +               ace->fsm_state = ACE_FSM_STATE_IDLE;
>  +               break;
>  +
>  +       default:
>  +               ace->fsm_state = ACE_FSM_STATE_IDLE;
>  +               break;
>  +       }
>  +}
>  +
>  +static void ace_fsm_tasklet(unsigned long data)
>  +{
>  +       struct ace_device *ace = (void *)data;
>  +       unsigned long flags;
>  +
>  +       spin_lock_irqsave(&ace->lock, flags);
>  +
>  +       /* Loop over state machine until told to stop */
>  +       ace->fsm_continue_flag = 1;
>  +       while (ace->fsm_continue_flag)
>  +               ace_fsm_dostate(ace);
>  +
>  +       spin_unlock_irqrestore(&ace->lock, flags);
>  +}
>  +
>  +static void ace_stall_timer(unsigned long data)
>  +{
>  +       struct ace_device *ace = (void *)data;
>  +       unsigned long flags;
>  +
>  +       dev_warn(ace->dev,
>  +                "kicking stalled fsm; state=%i task=%i iter=%i dc=%i\n",
>  +                ace->fsm_state, ace->fsm_task, ace->fsm_iter_num,
>  +                ace->data_count);
>  +       spin_lock_irqsave(&ace->lock, flags);
>  +
>  +       /* Rearm the stall timer *before* entering FSM (which may then
>  +        * delete the timer) */
>  +       mod_timer(&ace->stall_timer, jiffies + HZ);
>  +
>  +       /* Loop over state machine until told to stop */
>  +       ace->fsm_continue_flag = 1;
>  +       while (ace->fsm_continue_flag)
>  +               ace_fsm_dostate(ace);
>  +
>  +       spin_unlock_irqrestore(&ace->lock, flags);
>  +}
>  +
>  +/*
> ---------------------------------------------------------------------
>  + * Interrupt handling routines
>  + */
>  +static int ace_interrupt_checkstate(struct ace_device *ace)
>  +{
>  +       u32 sreg = ace_in32(ace, ACE_STATUS);
>  +       u16 creg = ace_in(ace, ACE_CTRL);
>  +
>  +       /* Check for error occurance */
>  +       if ((sreg & (ACE_STATUS_CFGERROR | ACE_STATUS_CFCERROR)) &&
>  +           (creg & ACE_CTRL_ERRORIRQ)) {
>  +               dev_err(ace->dev, "transfer failure\n");
>  +               ace_dump_regs(ace);
>  +               return -EIO;
>  +       }
>  +
>  +       return 0;
>  +}
>  +
>  +static irqreturn_t ace_interrupt(int irq, void *dev_id)
>  +{
>  +       u16 creg;
>  +       struct ace_device *ace = dev_id;
>  +
>  +       /* be safe and get the lock */
>  +       spin_lock(&ace->lock);
>  +       ace->in_irq = 1;
>  +
>  +       /* clear the interrupt */
>  +       creg = ace_in(ace, ACE_CTRL);
>  +       ace_out(ace, ACE_CTRL, creg | ACE_CTRL_RESETIRQ);
>  +       ace_out(ace, ACE_CTRL, creg);
>  +
>  +       /* check for IO failures */
>  +       if (ace_interrupt_checkstate(ace))
>  +               ace->data_result = -EIO;
>  +
>  +       if (ace->fsm_task == 0) {
>  +               dev_err(ace->dev,
>  +                       "spurious irq; stat=%.8x ctrl=%.8x cmd=%.4x\n",
>  +                       ace_in32(ace, ACE_STATUS), ace_in32(ace, ACE_CTRL),
>  +                       ace_in(ace, ACE_SECCNTCMD));
>  +               dev_err(ace->dev, "fsm_task=%i fsm_state=%i
> data_count=%i\n",
>  +                       ace->fsm_task, ace->fsm_state, ace->data_count);
>  +       }
>  +
>  +       /* Loop over state machine until told to stop */
>  +       ace->fsm_continue_flag = 1;
>  +       while (ace->fsm_continue_flag)
>  +               ace_fsm_dostate(ace);
>  +
>  +       /* done with interrupt; drop the lock */
>  +       ace->in_irq = 0;
>  +       spin_unlock(&ace->lock);
>  +
>  +       return IRQ_HANDLED;
>  +}
>  +
>  +/*
> ---------------------------------------------------------------------
>  + * Block ops
>  + */
>  +static void ace_request(request_queue_t * q)
>  +{
>  +       struct request *req;
>  +       struct ace_device *ace;
>  +
>  +       req = ace_get_next_request(q);
>  +
>  +       if (req) {
>  +               ace = req->rq_disk->private_data;
>  +               tasklet_schedule(&ace->fsm_tasklet);
>  +       }
>  +}
>  +
>  +static int ace_media_changed(struct gendisk *gd)
>  +{
>  +       struct ace_device *ace = gd->private_data;
>  +       dev_dbg(ace->dev, "ace_media_changed(): %i\n", ace->media_change);
>  +
>  +       return ace->media_change;
>  +}
>  +
>  +static int ace_revalidate_disk(struct gendisk *gd)
>  +{
>  +       struct ace_device *ace = gd->private_data;
>  +       unsigned long flags;
>  +
>  +       dev_dbg(ace->dev, "ace_revalidate_disk()\n");
>  +
>  +       if (ace->media_change) {
>  +               dev_dbg(ace->dev, "requesting cf id and scheduling
> tasklet\n");
>  +
>  +               spin_lock_irqsave(&ace->lock, flags);
>  +               ace->id_req_count++;
>  +               spin_unlock_irqrestore(&ace->lock, flags);
>  +
>  +               tasklet_schedule(&ace->fsm_tasklet);
>  +               wait_for_completion(&ace->id_completion);
>  +       }
>  +
>  +       dev_dbg(ace->dev, "revalidate complete\n");
>  +       return ace->id_result;
>  +}
>  +
>  +static int ace_open(struct inode *inode, struct file *filp)
>  +{
>  +       struct ace_device *ace =
> inode->i_bdev->bd_disk->private_data;
>  +       unsigned long flags;
>  +
>  +       dev_dbg(ace->dev, "ace_open() users=%i\n", ace->users + 1);
>  +
>  +       filp->private_data = ace;
>  +       spin_lock_irqsave(&ace->lock, flags);
>  +       ace->users++;
>  +       spin_unlock_irqrestore(&ace->lock, flags);
>  +
>  +       check_disk_change(inode->i_bdev);
>  +       return 0;
>  +}
>  +
>  +static int ace_release(struct inode *inode, struct file *filp)
>  +{
>  +       struct ace_device *ace =
> inode->i_bdev->bd_disk->private_data;
>  +       unsigned long flags;
>  +       u16 val;
>  +
>  +       dev_dbg(ace->dev, "ace_release() users=%i\n", ace->users - 1);
>  +
>  +       spin_lock_irqsave(&ace->lock, flags);
>  +       ace->users--;
>  +       if (ace->users == 0) {
>  +               val = ace_in(ace, ACE_CTRL);
>  +               ace_out(ace, ACE_CTRL, val & ~ACE_CTRL_LOCKREQ);
>  +       }
>  +       spin_unlock_irqrestore(&ace->lock, flags);
>  +       return 0;
>  +}
>  +
>  +static int ace_ioctl(struct inode *inode, struct file *filp,
>  +                    unsigned int cmd, unsigned long arg)
>  +{
>  +       struct ace_device *ace =
> inode->i_bdev->bd_disk->private_data;
>  +       struct hd_geometry __user *geo = (struct hd_geometry __user *)arg;
>  +       struct hd_geometry g;
>  +       dev_dbg(ace->dev, "ace_ioctl()\n");
>  +
>  +       switch (cmd) {
>  +       case HDIO_GETGEO:
>  +               g.heads = ace->cf_id.heads;
>  +               g.sectors = ace->cf_id.sectors;
>  +               g.cylinders = ace->cf_id.cyls;
>  +               g.start = 0;
>  +               return copy_to_user(geo, &g, sizeof(g)) ? -EFAULT : 0;
>  +
>  +       default:
>  +               return -ENOTTY;
>  +       }
>  +       return -ENOTTY;
>  +}
>  +
>  +static struct block_device_operations ace_fops = {
>  +       .owner = THIS_MODULE,
>  +       .open = ace_open,
>  +       .release = ace_release,
>  +       .media_changed = ace_media_changed,
>  +       .revalidate_disk = ace_revalidate_disk,
>  +       .ioctl = ace_ioctl,
>  +};
>  +
>  +/*
> --------------------------------------------------------------------
>  + * SystemACE device setup/teardown code
>  + */
>  +static int __devinit ace_setup(struct ace_device *ace)
>  +{
>  +       u16 version;
>  +       u16 val;
>  +
>  +       int rc;
>  +
>  +       spin_lock_init(&ace->lock);
>  +       init_completion(&ace->id_completion);
>  +
>  +       /*
>  +        * Map the device
>  +        */
>  +       ace->baseaddr = ioremap(ace->physaddr, 0x80);
>  +       if (!ace->baseaddr)
>  +               goto err_ioremap;
>  +
>  +       if (ace->irq != NO_IRQ) {
>  +               rc = request_irq(ace->irq, ace_interrupt, 0, "systemace",
> ace);
>  +               if (rc) {
>  +                       /* Failure - fall back to polled mode */
>  +                       dev_err(ace->dev, "request_irq failed\n");
>  +                       ace->irq = NO_IRQ;
>  +               }
>  +       }
>  +
>  +       /*
>  +        * Initialize the state machine tasklet and stall timer
>  +        */
>  +       tasklet_init(&ace->fsm_tasklet, ace_fsm_tasklet, (unsigned
> long)ace);
>  +       setup_timer(&ace->stall_timer, ace_stall_timer, (unsigned
> long)ace);
>  +
>  +       /*
>  +        * Initialize the request queue
>  +        */
>  +       ace->queue = blk_init_queue(ace_request, &ace->lock);
>  +       if (ace->queue == NULL)
>  +               goto err_blk_initq;
>  +       blk_queue_hardsect_size(ace->queue, 512);
>  +
>  +       /*
>  +        * Allocate and initialize GD structure
>  +        */
>  +       ace->gd = alloc_disk(ACE_NUM_MINORS);
>  +       if (!ace->gd)
>  +               goto err_alloc_disk;
>  +
>  +       ace->gd->major = ace_major;
>  +       ace->gd->first_minor = ace->id * ACE_NUM_MINORS;
>  +       ace->gd->fops = &ace_fops;
>  +       ace->gd->queue = ace->queue;
>  +       ace->gd->private_data = ace;
>  +       snprintf(ace->gd->disk_name, 32, "xs%c", ace->id + 'a');
>  +       device_rename(ace->dev, ace->gd->disk_name);
>  +
>  +       /* set bus width */
>  +       if (ace->bus_width == 1) {
>  +               /* 0x0101 should work regardless of endianess */
>  +               ace_out_le16(ace, ACE_BUSMODE, 0x0101);
>  +
>  +               /* read it back to determine endianess */
>  +               if (ace_in_le16(ace, ACE_BUSMODE) == 0x0001)
>  +                       ace->reg_ops = &ace_reg_le16_ops;
>  +               else
>  +                       ace->reg_ops = &ace_reg_be16_ops;
>  +       } else {
>  +               ace_out_8(ace, ACE_BUSMODE, 0x00);
>  +               ace->reg_ops = &ace_reg_8_ops;
>  +       }
>  +
>  +       /* Make sure version register is sane */
>  +       version = ace_in(ace, ACE_VERSION);
>  +       if ((version == 0) || (version == 0xFFFF))
>  +               goto err_read;
>  +
>  +       /* Put sysace in a sane state by clearing most control reg bits */
>  +       ace_out(ace, ACE_CTRL, ACE_CTRL_FORCECFGMODE |
>  +               ACE_CTRL_DATABUFRDYIRQ | ACE_CTRL_ERRORIRQ);
>  +
>  +       /* Enable interrupts */
>  +       val = ace_in(ace, ACE_CTRL);
>  +       val |= ACE_CTRL_DATABUFRDYIRQ | ACE_CTRL_ERRORIRQ;
>  +       ace_out(ace, ACE_CTRL, val);
>  +
>  +       /* Print the identification */
>  +       dev_info(ace->dev, "Xilinx SystemACE revision %i.%i.%i\n",
>  +                (version >> 12) & 0xf, (version >> 8) & 0x0f, version &
> 0xff);
>  +       dev_dbg(ace->dev, "physaddr 0x%lx, mapped to 0x%p, irq=%i\n",
>  +               ace->physaddr, ace->baseaddr, ace->irq);
>  +
>  +       ace->media_change = 1;
>  +       ace_revalidate_disk(ace->gd);
>  +
>  +       /* Make the sysace device 'live' */
>  +       add_disk(ace->gd);
>  +
>  +       return 0;
>  +
>  +      err_read:
>  +       put_disk(ace->gd);
>  +      err_alloc_disk:
>  +       blk_cleanup_queue(ace->queue);
>  +      err_blk_initq:
>  +       iounmap(ace->baseaddr);
>  +       if (ace->irq != NO_IRQ)
>  +               free_irq(ace->irq, ace);
>  +      err_ioremap:
>  +       printk(KERN_INFO "xsysace: error initializing device at 0x%lx\n",
>  +              ace->physaddr);
>  +       return -ENOMEM;
>  +}
>  +
>  +static void __devexit ace_teardown(struct ace_device *ace)
>  +{
>  +       if (ace->gd) {
>  +               del_gendisk(ace->gd);
>  +               put_disk(ace->gd);
>  +       }
>  +
>  +       if (ace->queue)
>  +               blk_cleanup_queue(ace->queue);
>  +
>  +       tasklet_kill(&ace->fsm_tasklet);
>  +
>  +       if (ace->irq != NO_IRQ)
>  +               free_irq(ace->irq, ace);
>  +
>  +       iounmap(ace->baseaddr);
>  +}
>  +
>  +/*
> ---------------------------------------------------------------------
>  + * Platform Bus Support
>  + */
>  +
>  +static int __devinit ace_probe(struct device *device)
>  +{
>  +       struct platform_device *dev = to_platform_device(device);
>  +       struct ace_device *ace;
>  +       int i;
>  +
>  +       dev_dbg(device, "ace_probe(%p)\n", device);
>  +
>  +       /*
>  +        * Allocate the ace device structure
>  +        */
>  +       ace = kzalloc(sizeof(struct ace_device), GFP_KERNEL);
>  +       if (!ace)
>  +               goto err_alloc;
>  +
>  +       ace->dev = device;
>  +       ace->id = dev->id;
>  +       ace->irq = NO_IRQ;
>  +
>  +       for (i = 0; i < dev->num_resources; i++) {
>  +               if (dev->resource[i].flags & IORESOURCE_MEM)
>  +                       ace->physaddr = dev->resource[i].start;
>  +               if (dev->resource[i].flags & IORESOURCE_IRQ)
>  +                       ace->irq = dev->resource[i].start;
>  +       }
>  +
>  +       /* FIXME: Should get bus_width from the platform_device struct */
>  +       ace->bus_width = 1;
>  +
>  +       dev_set_drvdata(&dev->dev, ace);
>  +
>  +       /* Call the bus-independant setup code */
>  +       if (ace_setup(ace) != 0)
>  +               goto err_setup;
>  +
>  +       return 0;
>  +
>  +      err_setup:
>  +       dev_set_drvdata(&dev->dev, NULL);
>  +       kfree(ace);
>  +      err_alloc:
>  +       printk(KERN_ERR "xsysace: could not initialize device\n");
>  +       return -ENOMEM;
>  +}
>  +
>  +/*
>  + * Platform bus remove() method
>  + */
>  +static int __devexit ace_remove(struct device *device)
>  +{
>  +       struct ace_device *ace = dev_get_drvdata(device);
>  +
>  +       dev_dbg(device, "ace_remove(%p)\n", device);
>  +
>  +       if (ace) {
>  +               ace_teardown(ace);
>  +               kfree(ace);
>  +       }
>  +
>  +       return 0;
>  +}
>  +
>  +static struct device_driver ace_driver = {
>  +       .name = "xsysace",
>  +       .bus = &platform_bus_type,
>  +       .probe = ace_probe,
>  +       .remove = __devexit_p(ace_remove),
>  +};
>  +
>  +/*
> ---------------------------------------------------------------------
>  + * Module init/exit routines
>  + */
>  +static int __init ace_init(void)
>  +{
>  +       ace_major = register_blkdev(ace_major, "xsysace");
>  +       if (ace_major <= 0) {
>  +               printk(KERN_WARNING "xsysace: register_blkdev() failed\n");
>  +               return ace_major;
>  +       }
>  +
>  +       pr_debug("Registering Xilinx SystemACE driver, major=%i\n",
> ace_major);
>  +       return driver_register(&ace_driver);
>  +}
>  +
>  +static void __exit ace_exit(void)
>  +{
>  +       pr_debug("Unregistering Xilinx SystemACE driver\n");
>  +       driver_unregister(&ace_driver);
>  +       if (unregister_blkdev(ace_major, "xsysace"))
>  +               printk(KERN_WARNING "systemace unregister_blkdev(%i)
> failed\n",
>  +                      ace_major);
>  +}
>  +
>  +module_init(ace_init);
>  +module_exit(ace_exit);
>
>
>  CONFIDENTIALITY
>  This e-mail message and any attachments thereto, is intended only for use
> by the addressee(s) named herein and may contain legally privileged and/or
> confidential information. If you are not the intended recipient of this
> e-mail message, you are hereby notified that any dissemination, distribution
> or copying of this e-mail message, and any attachments thereto, is strictly
> prohibited. If you have received this e-mail message in error, please
> immediately notify the sender and permanently delete the original and any
> copies of this email and any prints thereof.
>  ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT
> INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform
> Electronic Transactions Act or the applicability of any other law of similar
> substance and effect, absent an express statement to the contrary
> hereinabove, this e-mail message its contents, and any attachments hereto
> are not intended to represent an offer or acceptance to enter into a
> contract and are not otherwise intended to bind the sender, Sanmina-SCI
> Corporation (or any of its subsidiaries), or any other person or entity.
>


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195


CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited.  If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING.  Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), or any other person or entity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070713/a80fd87c/attachment.htm 

From grant.likely at secretlab.ca  Sat Jul 14 03:36:08 2007
From: grant.likely at secretlab.ca (Grant Likely)
Date: Fri, 13 Jul 2007 11:36:08 -0600
Subject: [PATCH] Xilinx SystemACE device driver
In-Reply-To: <939D37AEB47F1F49B88FAB6599B6023501A17210@hsv1dafpew02.das.gov.sanm.corp>
References: <20070712225138.13213.38257.stgit@trillian>
	<939D37AEB47F1F49B88FAB6599B6023501A1720B@hsv1dafpew02.das.gov.sanm.corp>
	<fa686aa40707130841w6a36146cufc85a62f78a53b0d@mail.gmail.com>
	<939D37AEB47F1F49B88FAB6599B6023501A17210@hsv1dafpew02.das.gov.sanm.corp>
Message-ID: <fa686aa40707131036k1bc5f2c4t701a44e0ef25acc8@mail.gmail.com>

On 7/13/07, Robertson, Joseph M. <joseph.robertson at sanmina-sci.com> wrote:
>
> Hi,
>
>  Ok, so outlook is a problem.  The horror is that, where I work thats all I
> can use.  They block all the outside systems like gmail, yahoo, etc.  So
> under linux, I have to use the web access for outlook.  ugh.
>  Why I work here I don't know, they think all software HAS to be bought.
>
>  Um, so your patch creates another xsysace.c file, all by itself, which is a
> NEW driver?
>  This replaces the 8 files of the previous driver?  What happens to all the
> low level funcs?
>
>  Where can I get your 2.6.22 tree to see how this is all supposed to go
> together?  Is there a tar.bz2 package?

Start with installing 'git'.  http://git.or.cz/

Then clone Linus' tree:

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

if you're company blocks the git port, then you can use HTTP instead:

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

There are a number of different git repos out there with virtex
support integrated, but I'm going to use the example of my tree...  (I
rebased my tree onto 2.6.22, so it's very up to date)

$ git fetch git://git.secretlab.ca/git/linux-2.6.git virtex-dev:virtex-dev
(Again, you can use http:// if the git port is blocked)

Now you'll have a branch in your git tree called 'virtex-dev' that
includes my patchset.

You can checkout that branch with:
$ git branch mybranch virtex-dev
$ git checkout mybranch

You can view the patchset with:
$ gitk virtex-dev

You can look at in individual patch with:
$ git show <SHA1 id>
(All git commits are identified with a SHA1 hash; you'll see them in
gitk, or when you do a 'git log)

Also, you can view the tree online at:
http://git.secretlab.ca/cgi-bin/gitweb.cgi?p=linux-2.6.git;a=summary

If you click on the 'commitdiff' link for a patch, followed by
'plain', you should get a downloadable version of the patch.

Cheers,
g.


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195


From clemens.koller at anagramm.de  Sat Jul 14 05:17:07 2007
From: clemens.koller at anagramm.de (Clemens Koller)
Date: Fri, 13 Jul 2007 21:17:07 +0200
Subject: Help required for porting ISP1362 usb device driver
In-Reply-To: <003d01c7c4d8$07ea3cc0$66dd47ab@cisco.com>
References: <003d01c7c4d8$07ea3cc0$66dd47ab@cisco.com>
Message-ID: <4697CFB3.8090009@anagramm.de>

Hello, Vikram!

Vikram Kone schrieb:
> Hi..
> I'm a linux newbie and im working on porting the USB driver ISP1362 by 
> Philips on to my Freescale ppc board.

Please don't crosspost.
Please don't write HTML.

> I dont know how to do this... so if any of you can tell me how to do 
> this step by step, i would be very grateful to you
>  
> Few details..
> I'm running RHEL with kernel 2.4.21 on a PC (i386 machine)
> Target Machine is MPC8548 CDS by Free scale (ppc architecture) running 
> kernel version 2.6.11

Did you try something like:
http://www.freescale.com/files/32bit/doc/app_note/AN3094.pdf?fsrch=1
I think it's one of these "step by step" things.

(You should consider moving up to the latest Kernel which is 2.6.22.1
as of today. Nobody fixes bugs on that old kernel.)

> I do have a ppc tool chain, if that helps.....

What tool chain?

 > but i dont know how to use it

Did you read the documentation?
What problem do you have?

> P.S. I downloaded the deive driver and host controller drivers from 
> sourceforge.net and both of them seem to work for 2.6.6 kernel for i386 
> arch ..

Fine!

> P.P.S : Wolfgang ??!1 Can you help me out... I went through the archives 
> on the list and seems thatu answered many Qs on this driver. But i didnt 
> find any post specifcally for my problem..so

Sorry, my crystal ball is broken.
You didn't tell us any details about your problem.

  > This e-mail may contain confidential and privileged material for the
> sole use of the intended recipient. Any review, use, distribution or 
> disclosure by others is strictly prohibited. If you are not the intended 
> recipient (or authorized to receive for the recipient), please contact 
> the sender by reply e-mail and delete all copies of this message.

Oops... If I am not the intended recipient, please: > /dev/null my mail.

Regards,
-- 
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Stra?e 45/1
Linhof Werksgel?nde
D-81379 M?nchen
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com


From clemens.koller at anagramm.de  Sat Jul 14 05:17:16 2007
From: clemens.koller at anagramm.de (Clemens Koller)
Date: Fri, 13 Jul 2007 21:17:16 +0200
Subject: Help required for porting ISP1362 usb device driver
In-Reply-To: <003d01c7c4d8$07ea3cc0$66dd47ab@cisco.com>
References: <003d01c7c4d8$07ea3cc0$66dd47ab@cisco.com>
Message-ID: <4697CFBC.2060700@anagramm.de>

Hello, Vikram!

Vikram Kone schrieb:
> Hi..
> I'm a linux newbie and im working on porting the USB driver ISP1362 by 
> Philips on to my Freescale ppc board.

Please don't crosspost.
Please don't write HTML.

> I dont know how to do this... so if any of you can tell me how to do 
> this step by step, i would be very grateful to you
>  
> Few details..
> I'm running RHEL with kernel 2.4.21 on a PC (i386 machine)
> Target Machine is MPC8548 CDS by Free scale (ppc architecture) running 
> kernel version 2.6.11

Did you try something like:
http://www.freescale.com/files/32bit/doc/app_note/AN3094.pdf?fsrch=1
I think it's one of these "step by step" things.

(You should consider moving up to the latest Kernel which is 2.6.22.1
as of today. Nobody fixes bugs on that old kernel.)

> I do have a ppc tool chain, if that helps.....

What tool chain?

 > but i dont know how to use it

Did you read the documentation?
What problem do you have?

> P.S. I downloaded the deive driver and host controller drivers from 
> sourceforge.net and both of them seem to work for 2.6.6 kernel for i386 
> arch ..

Fine!

> P.P.S : Wolfgang ??!1 Can you help me out... I went through the archives 
> on the list and seems thatu answered many Qs on this driver. But i didnt 
> find any post specifcally for my problem..so

Sorry, my crystal ball is broken.
You didn't tell us any details about your problem.

  > This e-mail may contain confidential and privileged material for the
> sole use of the intended recipient. Any review, use, distribution or 
> disclosure by others is strictly prohibited. If you are not the intended 
> recipient (or authorized to receive for the recipient), please contact 
> the sender by reply e-mail and delete all copies of this message.

Oops... If I am not the intended recipient, please: > /dev/null my mail.

Regards,
-- 
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Stra?e 45/1
Linhof Werksgel?nde
D-81379 M?nchen
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com


From clemens.koller at anagramm.de  Sat Jul 14 06:27:32 2007
From: clemens.koller at anagramm.de (Clemens Koller)
Date: Fri, 13 Jul 2007 22:27:32 +0200
Subject: Help required for porting ISP1362 usb device driver
In-Reply-To: <003901c7c585$24fe3430$66dd47ab@cisco.com>
References: <003901c7c585$24fe3430$66dd47ab@cisco.com>
Message-ID: <4697E034.1080501@anagramm.de>

Don't remove the list, use "reply-to-all".

Vikram Kone schrieb:
> Hi Clemens..
> Thanks for replying..
> 
> The problem that I actually have is..
> The documentation that I got with the device and host controller drivers is
> based on kernel 2.6.6 so I'm not sure whther it works for 2.6.22 or not....
> I followed the instructions in that document and was able to compile to
> modules by running 'make' command in the folder. That's all fine. 
> But the problem is....as I said I'm working on the MPC8548 board by free
> scale and as you know its based on power pc architecture.

> I have attched the device driver files that I got from sourceforge.net

You don't need to attach drivers, when they are somewhere in the
web. Linking to it is fine.
I don't have the hardware and such an old kernel.
(I am using the ISP1563 on PCI and that works just fine.)

The driver is not in the kernel tree. There is no real support
for out of kernel drivers, so these drivers just get old and broken.
Contact the driver author mentioned in the code (Marlon Jose Masbad)
and tell him to push the code into the latest kernel.

> What I did was... Unzipped them and copied the folders in
> /usr/src/linux-2.6.10/drivers/usb 

I prefer not riding dead horses. ;-)

> As you can see the two folders that I have got are ISP1362_Device and
> ISP1362_Host
 >
> When I run 'make' in the Device folder I get the following error
> 
> bash-2.05b$ make
> make -C
> /ws/vkone/usb/Vendor/linux-2.6.10/drivers/usb/ISP1362_Device/device/diskemu
> make[1]: Entering directory
> `/auto/wsvkone/usb/Vendor/linux-2.6.10/drivers/usb/ISP1362_Device/device/dis
> kemu'
> make[1]: Nothing to be done for `all'.
> make[1]: Leaving directory
> `/auto/wsvkone/usb/Vendor/linux-2.6.10/drivers/usb/ISP1362_Device/device/dis
> kemu'
> make -C /ws/vkone/usb/Vendor/linux-2.6.10
> M=/ws/vkone/usb/Vendor/linux-2.6.10/drivers/usb/ISP1362_Device
> make[1]: Entering directory `/auto/wsvkone/usb/Vendor/linux-2.6.10'
> Makefile:531: /auto/wsvkone/usb/Vendor/linux-2.6.10/arch/i386/Makefile: No
> such file or directory
> make[1]: *** No rule to make target
> `/auto/wsvkone/usb/Vendor/linux-2.6.10/arch/i386/Makefile'.  Stop.
> make[1]: Leaving directory `/auto/wsvkone/usb/Vendor/linux-2.6.10'
> make: *** [all] Error 2
> bash-2.05b$
> 
> 
> I guess this is due to the 'arch' problem. I mean since there is no i386
> folder in the arch directory I guess its messing up. 
> 
> Can you help me now

Have you tried
$ export ARCH=ppc
or something similar?
(powerpc is current)

On my MPC8540 and the latest tools (than one still on ARCH=ppc), I ran into some crap:

/usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/devmscd/devmscd.c:35:26: error: linux/config.h: No such file or directory
/usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/devmscd/devmscd.c:61:25: error: asm/segment.h: No such file or directory

So, well, just out of curiosity, I just killed some of the bad stuff and got it to build... :-)

$ make
make -C /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/diskemu
make[1]: Entering directory `/usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/diskemu'
cc  -I../devmscd -D_8MB_SIZE_ -c disk_emu.c
cc -g -s -o msdisk disk_emu.o
make[1]: Leaving directory `/usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/diskemu'
make -C /usr/src/linux-2.6.21.5 M=/usr/src/linux-2.6.21.5/drivers/ISP1362_Device
make[1]: Entering directory `/usr/src/linux-2.6.21.5'
   LD      /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/devmscd/built-in.o
   CC [M]  /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/devmscd/devmscd.o
   CC [M]  /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/devmscd/msbridge.o
   LD [M]  /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/devmscd/mscd.o
   LD      /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/pdc/built-in.o
   CC [M]  /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/pdc/usb_pdc.o
/usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/pdc/usb_pdc.c: In function 'pdc_dev_control':
/usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/pdc/usb_pdc.c:313: warning: format '%d' expects type 'int', but argument 2 has type 'long unsigned int'
/usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/pdc/usb_pdc.c: In function 'rx_command':
/usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/pdc/usb_pdc.c:647: warning: format '%d' expects type 'int', but argument 2 has type 'long unsigned int'
/usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/pdc/usb_pdc.c: In function 'pdc_get_frame_number':
/usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/pdc/usb_pdc.c:851: warning: format '%d' expects type 'int', but argument 2 has type 'long unsigned int'
   CC [M]  /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/pdc/pdc_bus.o
   LD [M]  /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/pdc/pdc.o
   LD      /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/x86pci/built-in.o
   CC [M]  /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/x86pci/hal_pci.o
/usr/src/linux-2.6.21.5/drivers/ISP1362_Device/x86pci/hal_pci.c: In function 'isp1362_request_irq':
/usr/src/linux-2.6.21.5/drivers/ISP1362_Device/x86pci/hal_pci.c:724: warning: passing argument 2 of 'request_irq' from incompatible pointer type
   Building modules, stage 2.
   MODPOST 3 modules
   CC      /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/devmscd/mscd.mod.o
   LD [M]  /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/devmscd/mscd.ko
   CC      /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/pdc/pdc.mod.o
   LD [M]  /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/pdc/pdc.ko
   CC      /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/x86pci/hal_pci.mod.o
   LD [M]  /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/x86pci/hal_pci.ko
make[1]: Leaving directory `/usr/src/linux-2.6.21.5'
root at fox:/usr/src/linux-2.6.21.5/drivers/ISP1362_Device$ make
make -C /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/diskemu
make[1]: Entering directory `/usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/diskemu'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/diskemu'
make -C /usr/src/linux-2.6.21.5 M=/usr/src/linux-2.6.21.5/drivers/ISP1362_Device
make[1]: Entering directory `/usr/src/linux-2.6.21.5'
   CC [M]  /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/x86pci/hal_pci.o
/usr/src/linux-2.6.21.5/drivers/ISP1362_Device/x86pci/hal_pci.c: In function 'isp1362_request_irq':
/usr/src/linux-2.6.21.5/drivers/ISP1362_Device/x86pci/hal_pci.c:724: warning: passing argument 2 of 'request_irq' from incompatible pointer type
   Building modules, stage 2.
   MODPOST 3 modules
   CC      /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/devmscd/mscd.mod.o
   LD [M]  /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/devmscd/mscd.ko
   CC      /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/pdc/pdc.mod.o
   LD [M]  /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/pdc/pdc.ko
   CC      /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/x86pci/hal_pci.mod.o
   LD [M]  /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/x86pci/hal_pci.ko
make[1]: Leaving directory `/usr/src/linux-2.6.21.5'

Quick and dirty patch attached below...
Give it a try and publish your results (also to the list!)

Anybody who wants to see this in mainline?
It would be good to pick up *now*!
For sure it needs more clean up...

Regards,
-- 
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Stra?e 45/1
Linhof Werksgel?nde
D-81379 M?nchen
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ISP1362_Device-2.6.21.5-fix.patch
Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070713/23597c55/attachment.txt 

From sonny at burdell.org  Sat Jul 14 05:10:07 2007
From: sonny at burdell.org (Sonny Rao)
Date: Fri, 13 Jul 2007 15:10:07 -0400
Subject: Help required for porting ISP1362 usb device driver
In-Reply-To: <003d01c7c4d8$07ea3cc0$66dd47ab@cisco.com>
References: <003d01c7c4d8$07ea3cc0$66dd47ab@cisco.com>
Message-ID: <20070713191007.GA1182@kevlar.boston.burdell.org>

On Thu, Jul 12, 2007 at 03:57:32PM -0700, Vikram Kone wrote:
> 
>    Hi..
>    I'm a linux newbie and im working on porting the USB driver ISP1362 by
>    Philips on to my Freescale ppc board.
>    I dont know how to do this... so if any of you can tell me how to do this
>    step by step, i would be very grateful to you

Try posting this question on the kernel newbies mailing list

http://kernelnewbies.org/MailingList


From yiming at windriver.com  Sat Jul 14 08:07:41 2007
From: yiming at windriver.com (meerkat)
Date: Fri, 13 Jul 2007 15:07:41 -0700 (PDT)
Subject: boottime kernel relocation, what I missed?
In-Reply-To: <11574529.post@talk.nabble.com>
References: <11574529.post@talk.nabble.com>
Message-ID: <11588451.post@talk.nabble.com>


Figure that out, the bootstrap actually mapped the first 16M from C000000 to
the physicall address,
so calling a c routine, as long as it is in the first 16M, is OK


meerkat wrote:
> 
> Good day all,
> 
> For the first time I begin working on PPC, and on low level, and right
> start from boot sequence, one issue puzzled me.
> 
> After bootstrap code (zImage) uncompressed the kernel vmLinux to physical
> memory (say from addr 0),
> it jumps to the kernel entry point, _start, using physically address. 
> 
>  At this time, the MMU is not yet setup to map the kernel virtual address 
> (which is statically linked against base address KERNELBASE) to the
> physically address.
> 
> $ nm vmlinux |grep early_init
> c038b8e0 T early_init
> 
> 
> _start calls early_init before mmu is on to map the KERNEL_BASE to
> physically address
> 
> The question is how "bl  early_init"  can branch to the early_init entry
> point, properly, as early_init is still a virtual address?
> 
> Thanks
> 
> Jim
> 

-- 
View this message in context: http://www.nabble.com/boottime-kernel-relocation%2C-what-I-missed--tf4072673.html#a11588451
Sent from the linuxppc-embedded mailing list archive at Nabble.com.



From dhlii at dlasys.net  Sat Jul 14 15:05:45 2007
From: dhlii at dlasys.net (David H. Lynch Jr.)
Date: Sat, 14 Jul 2007 01:05:45 -0400
Subject: OT Re: [PATCH] Xilinx SystemACE device driver
In-Reply-To: <939D37AEB47F1F49B88FAB6599B6023501A17210@hsv1dafpew02.das.gov.sanm.corp>
References: <20070712225138.13213.38257.stgit@trillian><939D37AEB47F1F49B88FAB6599B6023501A1720B@hsv1dafpew02.das.gov.sanm.corp>	<fa686aa40707130841w6a36146cufc85a62f78a53b0d@mail.gmail.com>
	<939D37AEB47F1F49B88FAB6599B6023501A17210@hsv1dafpew02.das.gov.sanm.corp>
Message-ID: <469859A9.408@dlasys.net>

Robertson, Joseph M. wrote:
> Hi,
>
> Ok, so outlook is a problem.  The horror is that, where I work thats all I can use.  They block all the outside systems like gmail, yahoo, etc.  So under linux, I have to use the web access for outlook.  ugh.  
> Why I work here I don't know, they think all software HAS to be bought.
    Yet they want you doing Linux development ?

    I am an MSCE. I tried really really hard to like exchange/outlook.
But after loosing too many weekends and holidays to emergency rebuilds of
    exchange mailstores I switched. Finding a better mail server proved
trivial - I use exim/cyrus, but many many other combinations work well.
    The only time I have had to rebuild a cyrus mailstore was when the
HD it was on coughed up 64K bad sectors in one night.
    I was able to recover 99% of everything, exchange would have chucked
the whole mailstore.
    It has taken a long time for Open Source mail clients to offer
competitive features to OutLook
    But almost every one I have ever tried has been more robust.

    If you are planning on doing embedded linux development you will be
more productive the more immersed you are.
    While you can do alot of linux work from windows - one of my
partners builds Linux apps inside visual studio,
    it is not the same.

    I have had clients with ludicrous self defeating [in]security like
you have described.
    I have never met a firewall I could not pierce - included at some
defense installations I am not supposed to talk about.
    I can pretty much always create a vpn back to my own servers and
then do whatever I please.
   



> Joe Robertson
> x8259
> Joseph.Robertson at sanmina-sci.com
>   
>


-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii at dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 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



From urwithsudheer at gmail.com  Mon Jul 16 15:08:27 2007
From: urwithsudheer at gmail.com (urwithsudheer)
Date: Mon, 16 Jul 2007 10:38:27 +0530
Subject: XSysAce driver cant mount DOS part
In-Reply-To: <939D37AEB47F1F49B88FAB6599B6023501A1720A@hsv1dafpew02.das.gov.sanm.corp>
References: <939D37AEB47F1F49B88FAB6599B6023501A17205@hsv1dafpew02.das.gov.sanm.corp>
	<4697451E.3030409@gmail.com>
	<939D37AEB47F1F49B88FAB6599B6023501A1720A@hsv1dafpew02.das.gov.sanm.corp>
Message-ID: <469AFD4B.3090704@gmail.com>

Hi Joe Robertson,

Thanks for the link.

In the xsa_thread function, can u try changing the hardcoded coded value 
"2" to "xsa_cur_req->current_nr_sectors " 


The actual code in the given link.

for(i = xsa_cur_req->current_nr_sectors; i > 0; i-=2){
+			xsa_device.req_done = 1;
+			while ((stat = cur_req(&SysAce, sector,
+					2,
+					buffer)) == XST_DEVICE_BUSY)
+				xsa_short_delay();


Try changing it to ...

for(i = xsa_cur_req->current_nr_sectors; i > 0; 
i-=xsa_cur_req->current_nr_sectors ){ xsa_device.req_done = 1;
while ((stat = cur_req(&SysAce, sector,
                                     xsa_cur_req->current_nr_sectors ,
                                    buffer)) == XST_DEVICE_BUSY)
                xsa_short_delay();



Due to the hardcoded value, it gave problem while mounting but no issue 
with fdisk. It mounts well but generated a kernel BUG. Tried changing 
the value to '1' from '2' , fdisk crashed but mount is working well. So 
removed the hardcode value and then placed the dynamic variable 
xsa_cur_req->current_nr_sectors which is chosen by kernel. And now fdisk 
and mount both are working fine.


Pl let me know the results in your setup.

Thanks
Sudheer


Robertson, Joseph M. wrote:
>
> Hi,
>
> Yes, I got it from here.
> http://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/patches/linuxppc-2.6.17.1-sysace-1.2.patch
>
> The 'official' one, yes?
>
> Thanks,
>
> Joe Robertson
> Joseph.Robertson at sanmina-sci.com
>
>
>
> -----Original Message-----
> From: urwithsudheer [mailto:urwithsudheer at gmail.com]
> Sent: Fri 7/13/2007 4:25 AM
> To: Robertson, Joseph M.
> Cc: linuxppc-embedded at ozlabs.org
> Subject: Re: XSysAce driver cant mount DOS part
>
> Hi
>
> Robertson, Joseph M. wrote:
> >
> > Hi all,
> >
> > I've been workig with this for a while but have made no progress.
> > Today I got the latest XSysAce patch for kernel 2.6.17.1 and applied
> > it to get clean code.
> > I inherited the previous code from another developer.
> >
> Can you send the link to xsysace driver source code from where you 
> obtained.
>
>
> Thanks
> Sudheer
>
>
> >
> > My problem is that mounting the DOS partition always fails in a short
> > time with a kernel oops.
> >
> > ECAU-9999:# Oops: kernel access of bad area, sig: 11
> > [#1]                     
> > 
> PREEMPT                                                                       
> > NIP: C00701C8 LR: C0070C18 CTR:
> > 00000000                                      
> > REGS: c0391dd0 TRAP: 0300   Not tainted 
> > (2.6.17.1)                           
> > MSR: 00021030 <ME,IR,DR>  CR: 22028082  XER:
> > 0000000B                         
> > DAR: 00000000, DSISR:
> > 00800000                                                
> > TASK = c0373030[4] 'events/0' THREAD:
> > c0390000                                
> > GPR00: 00000080 C0391E80 C0373030 C02CAC00 C0E03000 C0E03154 00000000
> > C02CAC00
> > GPR08: 00200200 00000000 00100100 00000000 00051A4B FFFFDE60 03BD4900
> > 007FFF3B
> > GPR16: 00400000 00000001 FFFFFFFF 03BCDC58 00000000 007FFF00 00000002
> > C0280000
> > GPR24: C0363A10 0000000B 00000000 00000000 00000000 C02CAC00 C035ED20
> > C0E03000
> > NIP [C00701C8]
> > free_block+0x8c/0x138                                          
> > LR [C0070C18]
> > drain_array+0xb8/0x124                                          
> > Call Trace:                                 
> >
> > The setup:
> > My own build system.
> > Kernel 2.6.17.1 with lots of xilinx stuff, eth, i2c, xsysace. 
> > Crosscompiled for PPC405.
> > Latest, clean XSysAce code.  mods:  major hardcoded to = 125.  Polled
> > mode.
> > CF:  3 partitions,
> > 1:  DOS FAT16
> > 2:  Ext2  main
> > 3:  Ext2  rescue
> >
> > This build boots up fine, mounts a ext2 as root fine.  I can also
> > mount the rescue partition with no problems.
> >
> > Does anyone have any pointers of where I should look for problems?
> >
> > My next step is to go and set it up for interrupt service and see if
> > that changes anything.
> >
> > Thanks,
> >
> > Joe Robertson
> > Joseph.Robertson at sanmina-sci.com
> >
> >
> > CONFIDENTIALITY
> > This e-mail message and any attachments thereto, is intended only for
> > use by the addressee(s) named herein and may contain legally
> > privileged and/or confidential information. If you are not the
> > intended recipient of this e-mail message, you are hereby notified
> > that any dissemination, distribution or copying of this e-mail
> > message, and any attachments thereto, is strictly prohibited. If you
> > have received this e-mail message in error, please immediately notify
> > the sender and permanently delete the original and any copies of this
> > email and any prints thereof.
> > ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL
> > IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the
> > Uniform Electronic Transactions Act or the applicability of any other
> > law of similar substance and effect, absent an express statement to
> > the contrary hereinabove, this e-mail message its contents, and any
> > attachments hereto are not intended to represent an offer or
> > acceptance to enter into a contract and are not otherwise intended to
> > bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries),
> > or any other person or entity.
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded at ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
> CONFIDENTIALITY
> This e-mail message and any attachments thereto, is intended only for 
> use by the addressee(s) named herein and may contain legally 
> privileged and/or confidential information. If you are not the 
> intended recipient of this e-mail message, you are hereby notified 
> that any dissemination, distribution or copying of this e-mail 
> message, and any attachments thereto, is strictly prohibited. If you 
> have received this e-mail message in error, please immediately notify 
> the sender and permanently delete the original and any copies of this 
> email and any prints thereof.
> ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL 
> IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the 
> Uniform Electronic Transactions Act or the applicability of any other 
> law of similar substance and effect, absent an express statement to 
> the contrary hereinabove, this e-mail message its contents, and any 
> attachments hereto are not intended to represent an offer or 
> acceptance to enter into a contract and are not otherwise intended to 
> bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), 
> or any other person or entity.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070716/7c8f6f9e/attachment.htm 

From matvejchikov at gmail.com  Mon Jul 16 21:15:44 2007
From: matvejchikov at gmail.com (Matvejchikov Ilya)
Date: Mon, 16 Jul 2007 15:15:44 +0400
Subject: WDT with 82xx
Message-ID: <8496f91a0707160415i251aa027x6ef3899b92a5fccc@mail.gmail.com>

Hi all!

Does anybody use watchdog timer with mpc82xx?


From sureshtang at gmail.com  Mon Jul 16 23:59:59 2007
From: sureshtang at gmail.com (suresh suresh)
Date: Mon, 16 Jul 2007 19:29:59 +0530
Subject: Kmalloc returns which address
Message-ID: <e5eb93010707160659m6a7d0b02p623542739d28ab29@mail.gmail.com>

Hi,

I am porting MPC8280 driver from vxWorks to Linux.

I want know the address return by kmalloc function? is it physical address
or kernel virtual address.

For Tx and Rx, hardware uses buffers, so I have to allocate buffers and pass
the pointer to hardware. Can I pass the pointer returned kmalloc?  or  I
should convert it into physical address?

If it returns kernel virtual address, then how to convert into physical?

Thanks & Regards-
Suresh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070716/fe5b62e0/attachment.htm 

From khollan at daktronics.com  Tue Jul 17 01:38:19 2007
From: khollan at daktronics.com (khollan)
Date: Mon, 16 Jul 2007 08:38:19 -0700 (PDT)
Subject: ML410 PCI support
In-Reply-To: <11547023.post@talk.nabble.com>
References: <11547023.post@talk.nabble.com>
Message-ID: <11620099.post@talk.nabble.com>



khollan wrote:
> 
> I have two questions:
> 1) Has anyone wrote linux 2.6 PCI drviers for the xilinx development
> boards.  I want to get the PCI slots working on my board.
> 2)How do I set the HwAddr for the TEMAC driver?  Im using Grants latest
> git tree.  My board boots and the HwAddr is set to 00:00:00:00:00:00
> Thanks for your help
> Kevin
> 

1) Still waiting to see if someone knows how to go about doing this...
2) Solved this by hardcoding it in the embed_config.c file

Any help would be appreciated for the PCI issue.
Kevin
-- 
View this message in context: http://www.nabble.com/ML410-PCI-support-tf4064052.html#a11620099
Sent from the linuxppc-embedded mailing list archive at Nabble.com.



From grant.likely at secretlab.ca  Tue Jul 17 01:44:02 2007
From: grant.likely at secretlab.ca (Grant Likely)
Date: Mon, 16 Jul 2007 09:44:02 -0600
Subject: ML410 PCI support
In-Reply-To: <11620099.post@talk.nabble.com>
References: <11547023.post@talk.nabble.com> <11620099.post@talk.nabble.com>
Message-ID: <fa686aa40707160844x3bc31c4cw658bb6e4b2cb3bd7@mail.gmail.com>

On 7/16/07, khollan <khollan at daktronics.com> wrote:
>
>
> khollan wrote:
> >
> > I have two questions:
> > 1) Has anyone wrote linux 2.6 PCI drviers for the xilinx development
> > boards.  I want to get the PCI slots working on my board.
> > 2)How do I set the HwAddr for the TEMAC driver?  Im using Grants latest
> > git tree.  My board boots and the HwAddr is set to 00:00:00:00:00:00
> > Thanks for your help
> > Kevin
> >
>
> 1) Still waiting to see if someone knows how to go about doing this...

No, I don't think anyone has done proper PCI support.  But you might
want to double check the MontaVista 2.4 tree.

> 2) Solved this by hardcoding it in the embed_config.c file

Which is probably the best way to do it if you're booting from a
zImage.  If you're booting from u-boot or another bootloader, you can
pass the addr in the board info structure.

Cheers,
g.


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195


From scottwood at freescale.com  Tue Jul 17 01:46:36 2007
From: scottwood at freescale.com (Scott Wood)
Date: Mon, 16 Jul 2007 10:46:36 -0500
Subject: Kmalloc returns which address
In-Reply-To: <e5eb93010707160659m6a7d0b02p623542739d28ab29@mail.gmail.com>
References: <e5eb93010707160659m6a7d0b02p623542739d28ab29@mail.gmail.com>
Message-ID: <469B92DC.50609@freescale.com>

suresh suresh wrote:
> I want know the address return by kmalloc function? is it physical address
> or kernel virtual address.

Kernel virtual.

> For Tx and Rx, hardware uses buffers, so I have to allocate buffers and 
> pass
> the pointer to hardware. Can I pass the pointer returned kmalloc?  or  I
> should convert it into physical address?

You need to convert it; read Documentation/DMA-mapping.txt.

-Scott


From sprasad at bivio.net  Tue Jul 17 01:58:46 2007
From: sprasad at bivio.net (Siva Prasad)
Date: Mon, 16 Jul 2007 08:58:46 -0700
Subject: Linuxppc-embedded Digest, Vol 35, Issue 33
In-Reply-To: <mailman.1061.1184600645.8639.linuxppc-embedded@ozlabs.org>
References: <mailman.1061.1184600645.8639.linuxppc-embedded@ozlabs.org>
Message-ID: <D83235F0F3C86D4D889D8B9A0DA8C6D78D7DE9@corpexc01.corp.networkrobots.com>



It returns kernel virtual address. If you use this buffer space for DMA,
please use appropriate flags. You may use __pa(address) or
virt_to_phys() to convert virtual to physical.

- Siva


-----Original Message-----


Message: 3
Date: Mon, 16 Jul 2007 19:29:59 +0530
From: "suresh suresh" <sureshtang at gmail.com>
Subject: Kmalloc returns which address
To: linuxppc-embedded at ozlabs.org
Message-ID:
	<e5eb93010707160659m6a7d0b02p623542739d28ab29 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi,

I am porting MPC8280 driver from vxWorks to Linux.

I want know the address return by kmalloc function? is it physical
address
or kernel virtual address.

For Tx and Rx, hardware uses buffers, so I have to allocate buffers and
pass
the pointer to hardware. Can I pass the pointer returned kmalloc?  or  I
should convert it into physical address?

If it returns kernel virtual address, then how to convert into physical?

Thanks & Regards-
Suresh
-------------- next part --------------



From bgat at billgatliff.com  Tue Jul 17 01:43:41 2007
From: bgat at billgatliff.com (Bill Gatliff)
Date: Mon, 16 Jul 2007 10:43:41 -0500
Subject: Gdbserver syscall clobber
Message-ID: <469B922D.3050701@billgatliff.com>

Guys:


I'm trying to track down a problem where gdbserver is issuing a bogus 
syscall at the onset of a debugging session.  I'm using gdb-6.6, on an 
(ancient, I know) linux-2.4.16 kernel, pc603e machine.  Gcc-3.4.5, 
glibc-2.2.5 (both built with crosstools-0.43).  Gdbserver is statically 
linked.

When I run gdbserver under strace on the target, I see these in the log 
shortly after initiating the connection from my workstation:

...
ptrace(PTRACE_PEEKTEXT, 947, 0x10405394, [0x103e0cb0]) = 0
ptrace(PTRACE_PEEKTEXT, 947, 0x10405398, [0x103e0ce4]) = 0
ptrace(PTRACE_PEEKTEXT, 947, 0x1040539c, [0x103e0ce8]) = 0
send(4, "$103df2cc103df2e8103df2ec103df2f"..., 644, 0) = 644
recv(4, 0x7ffffd60, 1, 0)               = ? ERESTARTSYS (To be restarted)
--- SIGIO (I/O possible) @ 0 (0) ---
syscall_4294966784(0xa, 0x7ffffd34, 0x1, 0, 0x1008a3c7, 0x1008b5a3, 
0x1008b5a4, 0, 0x1, 0x80808080, 0x1008e778, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
0, 0, 0, 0x10080000, 0x10080000, 0x10080000, 0x1008b5a3, 0x10080000, 
0x1008b320, 0x100291a4, 0xd032, 0xa) = -1 (errno 38)
write(2, "putpkt(read): Function not imple"..., 39) = 39
...


Note the bogus syscall argument 4294966784.  It isn't *completely* 
bogus, interestingly, since if you google for that you come up with a 
few hits.  But no resolutions.

I'm stumped.  Does this problem sound familiar to anyone?  Had the same 
problem with gcc-2.95.3.


Kindest regards,


b.g.

-- 
Bill Gatliff
bgat at billgatliff.com



From scottwood at freescale.com  Tue Jul 17 02:09:09 2007
From: scottwood at freescale.com (Scott Wood)
Date: Mon, 16 Jul 2007 11:09:09 -0500
Subject: Linuxppc-embedded Digest, Vol 35, Issue 33
In-Reply-To: <D83235F0F3C86D4D889D8B9A0DA8C6D78D7DE9@corpexc01.corp.networkrobots.com>
References: <mailman.1061.1184600645.8639.linuxppc-embedded@ozlabs.org>
	<D83235F0F3C86D4D889D8B9A0DA8C6D78D7DE9@corpexc01.corp.networkrobots.com>
Message-ID: <469B9825.6070507@freescale.com>

Siva Prasad wrote:
> It returns kernel virtual address. If you use this buffer space for DMA,
> please use appropriate flags. You may use __pa(address) or
> virt_to_phys() to convert virtual to physical.

No, you may not -- physical and DMA addresses are not always identical. 
  Use the DMA mapping API.

-Scott



From joseph.robertson at sanmina-sci.com  Tue Jul 17 02:19:43 2007
From: joseph.robertson at sanmina-sci.com (Robertson, Joseph M.)
Date: Mon, 16 Jul 2007 11:19:43 -0500
Subject: XSysAce driver cant mount DOS part
References: <939D37AEB47F1F49B88FAB6599B6023501A17205@hsv1dafpew02.das.gov.sanm.corp><4697451E.3030409@gmail.com><939D37AEB47F1F49B88FAB6599B6023501A1720A@hsv1dafpew02.das.gov.sanm.corp>
	<469AFD4B.3090704@gmail.com>
Message-ID: <939D37AEB47F1F49B88FAB6599B6023501A17215@hsv1dafpew02.das.gov.sanm.corp>

Hi,

Thanks for your insight into the older code. 
I tried your fix and came up with this.
I have run e2fsck and the cf card comes up clean with that.

heres a boot sequence:

Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0x40421003 (irq = 4) is a 16550A
serial8250.0: ttyS1 at MMIO 0x40401003 (irq = 5) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 65536K size 1024 blocksize
XSysAce driver  v0771.
IDENTIFY: heads: 16, nsec: 63, cyls: 1011, size= 1019088
REGISTERED: major no.= 125 capacity= 1019088
 xsa: xsa1 xsa2 xsa3
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
mice: PS/2 mouse device common for all mice
TCP bic registered
NET: Registered protocol family 1
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 100k init
EXT2-fs error (device xsa2): ext2_check_page: bad entry in directory #32689: unaligned directory entry - offset=1024, inode=1713398885, rec_len=29295, name_len=109
Warning: unable to open an initial console.
init has generated signal 11 but has no handler for it
Kernel panic - not syncing: Attempted to kill init!


The only thing I notice is that the disk capacity is wrong, its a 512Mb, not a 1Gb as shown.

Any thoughts about what to look into next?

Thanks a lot.


Joe Robertson
Joseph.Robertson at sanmina-sci.com



-----Original Message-----
From: urwithsudheer [mailto:urwithsudheer at gmail.com]
Sent: Mon 7/16/2007 12:08 AM
To: Robertson, Joseph M.
Cc: linuxppc-embedded at ozlabs.org
Subject: Re: XSysAce driver cant mount DOS part
 
Hi Joe Robertson,

Thanks for the link.

In the xsa_thread function, can u try changing the hardcoded coded value 
"2" to "xsa_cur_req->current_nr_sectors " 


The actual code in the given link.

for(i = xsa_cur_req->current_nr_sectors; i > 0; i-=2){
+			xsa_device.req_done = 1;
+			while ((stat = cur_req(&SysAce, sector,
+					2,
+					buffer)) == XST_DEVICE_BUSY)
+				xsa_short_delay();


Try changing it to ...

for(i = xsa_cur_req->current_nr_sectors; i > 0; 
i-=xsa_cur_req->current_nr_sectors ){ xsa_device.req_done = 1;
while ((stat = cur_req(&SysAce, sector,
                                     xsa_cur_req->current_nr_sectors ,
                                    buffer)) == XST_DEVICE_BUSY)
                xsa_short_delay();



Due to the hardcoded value, it gave problem while mounting but no issue 
with fdisk. It mounts well but generated a kernel BUG. Tried changing 
the value to '1' from '2' , fdisk crashed but mount is working well. So 
removed the hardcode value and then placed the dynamic variable 
xsa_cur_req->current_nr_sectors which is chosen by kernel. And now fdisk 
and mount both are working fine.


Pl let me know the results in your setup.

Thanks
Sudheer


Robertson, Joseph M. wrote:
>
> Hi,
>
> Yes, I got it from here.
> http://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/patches/linuxppc-2.6.17.1-sysace-1.2.patch
>
> The 'official' one, yes?
>
> Thanks,
>
> Joe Robertson
> Joseph.Robertson at sanmina-sci.com
>
>
>
> -----Original Message-----
> From: urwithsudheer [mailto:urwithsudheer at gmail.com]
> Sent: Fri 7/13/2007 4:25 AM
> To: Robertson, Joseph M.
> Cc: linuxppc-embedded at ozlabs.org
> Subject: Re: XSysAce driver cant mount DOS part
>
> Hi
>
> Robertson, Joseph M. wrote:
> >
> > Hi all,
> >
> > I've been workig with this for a while but have made no progress.
> > Today I got the latest XSysAce patch for kernel 2.6.17.1 and applied
> > it to get clean code.
> > I inherited the previous code from another developer.
> >
> Can you send the link to xsysace driver source code from where you 
> obtained.
>
>
> Thanks
> Sudheer
>
>
> >
> > My problem is that mounting the DOS partition always fails in a short
> > time with a kernel oops.
> >
> > ECAU-9999:# Oops: kernel access of bad area, sig: 11
> > [#1]                     
> > 
> PREEMPT                                                                       
> > NIP: C00701C8 LR: C0070C18 CTR:
> > 00000000                                      
> > REGS: c0391dd0 TRAP: 0300   Not tainted 
> > (2.6.17.1)                           
> > MSR: 00021030 <ME,IR,DR>  CR: 22028082  XER:
> > 0000000B                         
> > DAR: 00000000, DSISR:
> > 00800000                                                
> > TASK = c0373030[4] 'events/0' THREAD:
> > c0390000                                
> > GPR00: 00000080 C0391E80 C0373030 C02CAC00 C0E03000 C0E03154 00000000
> > C02CAC00
> > GPR08: 00200200 00000000 00100100 00000000 00051A4B FFFFDE60 03BD4900
> > 007FFF3B
> > GPR16: 00400000 00000001 FFFFFFFF 03BCDC58 00000000 007FFF00 00000002
> > C0280000
> > GPR24: C0363A10 0000000B 00000000 00000000 00000000 C02CAC00 C035ED20
> > C0E03000
> > NIP [C00701C8]
> > free_block+0x8c/0x138                                          
> > LR [C0070C18]
> > drain_array+0xb8/0x124                                          
> > Call Trace:                                 
> >
> > The setup:
> > My own build system.
> > Kernel 2.6.17.1 with lots of xilinx stuff, eth, i2c, xsysace. 
> > Crosscompiled for PPC405.
> > Latest, clean XSysAce code.  mods:  major hardcoded to = 125.  Polled
> > mode.
> > CF:  3 partitions,
> > 1:  DOS FAT16
> > 2:  Ext2  main
> > 3:  Ext2  rescue
> >
> > This build boots up fine, mounts a ext2 as root fine.  I can also
> > mount the rescue partition with no problems.
> >
> > Does anyone have any pointers of where I should look for problems?
> >
> > My next step is to go and set it up for interrupt service and see if
> > that changes anything.
> >
> > Thanks,
> >
> > Joe Robertson
> > Joseph.Robertson at sanmina-sci.com
> >
> >
> > CONFIDENTIALITY
> > This e-mail message and any attachments thereto, is intended only for
> > use by the addressee(s) named herein and may contain legally
> > privileged and/or confidential information. If you are not the
> > intended recipient of this e-mail message, you are hereby notified
> > that any dissemination, distribution or copying of this e-mail
> > message, and any attachments thereto, is strictly prohibited. If you
> > have received this e-mail message in error, please immediately notify
> > the sender and permanently delete the original and any copies of this
> > email and any prints thereof.
> > ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL
> > IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the
> > Uniform Electronic Transactions Act or the applicability of any other
> > law of similar substance and effect, absent an express statement to
> > the contrary hereinabove, this e-mail message its contents, and any
> > attachments hereto are not intended to represent an offer or
> > acceptance to enter into a contract and are not otherwise intended to
> > bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries),
> > or any other person or entity.
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded at ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
> CONFIDENTIALITY
> This e-mail message and any attachments thereto, is intended only for 
> use by the addressee(s) named herein and may contain legally 
> privileged and/or confidential information. If you are not the 
> intended recipient of this e-mail message, you are hereby notified 
> that any dissemination, distribution or copying of this e-mail 
> message, and any attachments thereto, is strictly prohibited. If you 
> have received this e-mail message in error, please immediately notify 
> the sender and permanently delete the original and any copies of this 
> email and any prints thereof.
> ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL 
> IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the 
> Uniform Electronic Transactions Act or the applicability of any other 
> law of similar substance and effect, absent an express statement to 
> the contrary hereinabove, this e-mail message its contents, and any 
> attachments hereto are not intended to represent an offer or 
> acceptance to enter into a contract and are not otherwise intended to 
> bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), 
> or any other person or entity.



CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited.  If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING.  Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), or any other person or entity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070716/35e3cedf/attachment.htm 

From drow at false.org  Tue Jul 17 01:53:48 2007
From: drow at false.org (Daniel Jacobowitz)
Date: Mon, 16 Jul 2007 11:53:48 -0400
Subject: Gdbserver syscall clobber
In-Reply-To: <469B922D.3050701@billgatliff.com>
References: <469B922D.3050701@billgatliff.com>
Message-ID: <20070716155348.GA5281@caradoc.them.org>

On Mon, Jul 16, 2007 at 10:43:41AM -0500, Bill Gatliff wrote:
> recv(4, 0x7ffffd60, 1, 0)               = ? ERESTARTSYS (To be restarted)
> --- SIGIO (I/O possible) @ 0 (0) ---
> syscall_4294966784(0xa, 0x7ffffd34, 0x1, 0, 0x1008a3c7, 0x1008b5a3, 0x1008b5a4, 

That's -512, a.k.a. the errno value used by syscall restarting.  I'd
say your glibc does not obey the restartable syscall convention used
by your kernel, and when it tries to restart the syscall the errno
value is not being replaced by the syscall number.  Check the assembly
for recv.

-- 
Daniel Jacobowitz
CodeSourcery


From joseph.robertson at sanmina-sci.com  Tue Jul 17 03:51:42 2007
From: joseph.robertson at sanmina-sci.com (Robertson, Joseph M.)
Date: Mon, 16 Jul 2007 12:51:42 -0500
Subject: XSysAce driver cant mount DOS part
References: <939D37AEB47F1F49B88FAB6599B6023501A17205@hsv1dafpew02.das.gov.sanm.corp><4697451E.3030409@gmail.com><939D37AEB47F1F49B88FAB6599B6023501A1720A@hsv1dafpew02.das.gov.sanm.corp><469AFD4B.3090704@gmail.com>
	<939D37AEB47F1F49B88FAB6599B6023501A17215@hsv1dafpew02.das.gov.sanm.corp>
Message-ID: <939D37AEB47F1F49B88FAB6599B6023501A17216@hsv1dafpew02.das.gov.sanm.corp>

I am sorry, I found a mistake on my part.

I fixed the code 'exactly' as you stated and I believe it is now working.
You are now in my credits page!

Extensive testing will now occur.

Thank you very much.


Joe Robertson
x8259
Joseph.Robertson at sanmina-sci.com



-----Original Message-----
From: linuxppc-embedded-bounces+joseph.robertson=sanmina-sci.com at ozlabs.org on behalf of Robertson, Joseph M.
Sent: Mon 7/16/2007 11:19 AM
To: urwithsudheer
Cc: linuxppc-embedded at ozlabs.org
Subject: RE: XSysAce driver cant mount DOS part
 
Hi,

Thanks for your insight into the older code. 
I tried your fix and came up with this.
I have run e2fsck and the cf card comes up clean with that.

heres a boot sequence:

Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0x40421003 (irq = 4) is a 16550A
serial8250.0: ttyS1 at MMIO 0x40401003 (irq = 5) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 65536K size 1024 blocksize
XSysAce driver  v0771.
IDENTIFY: heads: 16, nsec: 63, cyls: 1011, size= 1019088
REGISTERED: major no.= 125 capacity= 1019088
 xsa: xsa1 xsa2 xsa3
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
mice: PS/2 mouse device common for all mice
TCP bic registered
NET: Registered protocol family 1
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 100k init
EXT2-fs error (device xsa2): ext2_check_page: bad entry in directory #32689: unaligned directory entry - offset=1024, inode=1713398885, rec_len=29295, name_len=109
Warning: unable to open an initial console.
init has generated signal 11 but has no handler for it
Kernel panic - not syncing: Attempted to kill init!


The only thing I notice is that the disk capacity is wrong, its a 512Mb, not a 1Gb as shown.

Any thoughts about what to look into next?

Thanks a lot.


Joe Robertson
Joseph.Robertson at sanmina-sci.com



-----Original Message-----
From: urwithsudheer [mailto:urwithsudheer at gmail.com]
Sent: Mon 7/16/2007 12:08 AM
To: Robertson, Joseph M.
Cc: linuxppc-embedded at ozlabs.org
Subject: Re: XSysAce driver cant mount DOS part
 
Hi Joe Robertson,

Thanks for the link.

In the xsa_thread function, can u try changing the hardcoded coded value 
"2" to "xsa_cur_req->current_nr_sectors " 


The actual code in the given link.

for(i = xsa_cur_req->current_nr_sectors; i > 0; i-=2){
+			xsa_device.req_done = 1;
+			while ((stat = cur_req(&SysAce, sector,
+					2,
+					buffer)) == XST_DEVICE_BUSY)
+				xsa_short_delay();


Try changing it to ...

for(i = xsa_cur_req->current_nr_sectors; i > 0; 
i-=xsa_cur_req->current_nr_sectors ){ xsa_device.req_done = 1;
while ((stat = cur_req(&SysAce, sector,
                                     xsa_cur_req->current_nr_sectors ,
                                    buffer)) == XST_DEVICE_BUSY)
                xsa_short_delay();



Due to the hardcoded value, it gave problem while mounting but no issue 
with fdisk. It mounts well but generated a kernel BUG. Tried changing 
the value to '1' from '2' , fdisk crashed but mount is working well. So 
removed the hardcode value and then placed the dynamic variable 
xsa_cur_req->current_nr_sectors which is chosen by kernel. And now fdisk 
and mount both are working fine.


Pl let me know the results in your setup.

Thanks
Sudheer


Robertson, Joseph M. wrote:
>
> Hi,
>
> Yes, I got it from here.
> http://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/patches/linuxppc-2.6.17.1-sysace-1.2.patch
>
> The 'official' one, yes?
>
> Thanks,
>
> Joe Robertson
> Joseph.Robertson at sanmina-sci.com
>
>
>
> -----Original Message-----
> From: urwithsudheer [mailto:urwithsudheer at gmail.com]
> Sent: Fri 7/13/2007 4:25 AM
> To: Robertson, Joseph M.
> Cc: linuxppc-embedded at ozlabs.org
> Subject: Re: XSysAce driver cant mount DOS part
>
> Hi
>
> Robertson, Joseph M. wrote:
> >
> > Hi all,
> >
> > I've been workig with this for a while but have made no progress.
> > Today I got the latest XSysAce patch for kernel 2.6.17.1 and applied
> > it to get clean code.
> > I inherited the previous code from another developer.
> >
> Can you send the link to xsysace driver source code from where you 
> obtained.
>
>
> Thanks
> Sudheer
>
>
> >
> > My problem is that mounting the DOS partition always fails in a short
> > time with a kernel oops.
> >
> > ECAU-9999:# Oops: kernel access of bad area, sig: 11
> > [#1]                     
> > 
> PREEMPT                                                                       
> > NIP: C00701C8 LR: C0070C18 CTR:
> > 00000000                                      
> > REGS: c0391dd0 TRAP: 0300   Not tainted 
> > (2.6.17.1)                           
> > MSR: 00021030 <ME,IR,DR>  CR: 22028082  XER:
> > 0000000B                         
> > DAR: 00000000, DSISR:
> > 00800000                                                
> > TASK = c0373030[4] 'events/0' THREAD:
> > c0390000                                
> > GPR00: 00000080 C0391E80 C0373030 C02CAC00 C0E03000 C0E03154 00000000
> > C02CAC00
> > GPR08: 00200200 00000000 00100100 00000000 00051A4B FFFFDE60 03BD4900
> > 007FFF3B
> > GPR16: 00400000 00000001 FFFFFFFF 03BCDC58 00000000 007FFF00 00000002
> > C0280000
> > GPR24: C0363A10 0000000B 00000000 00000000 00000000 C02CAC00 C035ED20
> > C0E03000
> > NIP [C00701C8]
> > free_block+0x8c/0x138                                          
> > LR [C0070C18]
> > drain_array+0xb8/0x124                                          
> > Call Trace:                                 
> >
> > The setup:
> > My own build system.
> > Kernel 2.6.17.1 with lots of xilinx stuff, eth, i2c, xsysace. 
> > Crosscompiled for PPC405.
> > Latest, clean XSysAce code.  mods:  major hardcoded to = 125.  Polled
> > mode.
> > CF:  3 partitions,
> > 1:  DOS FAT16
> > 2:  Ext2  main
> > 3:  Ext2  rescue
> >
> > This build boots up fine, mounts a ext2 as root fine.  I can also
> > mount the rescue partition with no problems.
> >
> > Does anyone have any pointers of where I should look for problems?
> >
> > My next step is to go and set it up for interrupt service and see if
> > that changes anything.
> >
> > Thanks,
> >
> > Joe Robertson
> > Joseph.Robertson at sanmina-sci.com
> >
> >
> > CONFIDENTIALITY
> > This e-mail message and any attachments thereto, is intended only for
> > use by the addressee(s) named herein and may contain legally
> > privileged and/or confidential information. If you are not the
> > intended recipient of this e-mail message, you are hereby notified
> > that any dissemination, distribution or copying of this e-mail
> > message, and any attachments thereto, is strictly prohibited. If you
> > have received this e-mail message in error, please immediately notify
> > the sender and permanently delete the original and any copies of this
> > email and any prints thereof.
> > ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL
> > IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the
> > Uniform Electronic Transactions Act or the applicability of any other
> > law of similar substance and effect, absent an express statement to
> > the contrary hereinabove, this e-mail message its contents, and any
> > attachments hereto are not intended to represent an offer or
> > acceptance to enter into a contract and are not otherwise intended to
> > bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries),
> > or any other person or entity.
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded at ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
> CONFIDENTIALITY
> This e-mail message and any attachments thereto, is intended only for 
> use by the addressee(s) named herein and may contain legally 
> privileged and/or confidential information. If you are not the 
> intended recipient of this e-mail message, you are hereby notified 
> that any dissemination, distribution or copying of this e-mail 
> message, and any attachments thereto, is strictly prohibited. If you 
> have received this e-mail message in error, please immediately notify 
> the sender and permanently delete the original and any copies of this 
> email and any prints thereof.
> ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL 
> IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the 
> Uniform Electronic Transactions Act or the applicability of any other 
> law of similar substance and effect, absent an express statement to 
> the contrary hereinabove, this e-mail message its contents, and any 
> attachments hereto are not intended to represent an offer or 
> acceptance to enter into a contract and are not otherwise intended to 
> bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), 
> or any other person or entity.



CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited.  If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING.  Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), or any other person or entity.



CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited.  If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING.  Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), or any other person or entity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070716/b379751c/attachment.htm 

From becky.bruce at freescale.com  Tue Jul 17 05:10:38 2007
From: becky.bruce at freescale.com (Becky Bruce)
Date: Mon, 16 Jul 2007 14:10:38 -0500
Subject: boottime kernel relocation, what I missed?
In-Reply-To: <11588451.post@talk.nabble.com>
References: <11574529.post@talk.nabble.com> <11588451.post@talk.nabble.com>
Message-ID: <0C6B2DC2-7621-4798-B3F7-7F1962A1D1A9@freescale.com>


On Jul 13, 2007, at 5:07 PM, meerkat wrote:

>
> Figure that out, the bootstrap actually mapped the first 16M from  
> C000000 to
> the physicall address,
> so calling a c routine, as long as it is in the first 16M, is OK
>

I think you're still not understanding the fact that "bl" is a  
*relative* branch - the branch target in the instruction encoding is  
just an offset from the current address, not an effective address.   
The bl should work correctly whether the code is actually running at  
the link address reported by nm (0xcxxxxxxx in this case), or if it  
has been loaded and executed elsewhere.

Refer to the 32-bit Programming Environments Manual for PowerPC, or  
in the EREF (if you're using a BookE part - e500/e200) for more  
details.  If you're just learning PowerPC assembler, you should  
really give this book a good thourough read.

>
> meerkat wrote:
>>
>> Good day all,
>>
>> For the first time I begin working on PPC, and on low level, and  
>> right
>> start from boot sequence, one issue puzzled me.
>>
>> After bootstrap code (zImage) uncompressed the kernel vmLinux to  
>> physical
>> memory (say from addr 0),
>> it jumps to the kernel entry point, _start, using physically address.

If you read the book specified above, you will see that branch  
instructions always specify an effective address, not a physical  
address.  You can disable translation or map the address so EA=PA,  
but that's a different issue.

-Becky


From yiming at windriver.com  Tue Jul 17 05:36:55 2007
From: yiming at windriver.com (meerkat)
Date: Mon, 16 Jul 2007 12:36:55 -0700 (PDT)
Subject: boottime kernel relocation, what I missed?
In-Reply-To: <0C6B2DC2-7621-4798-B3F7-7F1962A1D1A9@freescale.com>
References: <11574529.post@talk.nabble.com> <11588451.post@talk.nabble.com>
	<0C6B2DC2-7621-4798-B3F7-7F1962A1D1A9@freescale.com>
Message-ID: <11629480.post@talk.nabble.com>


Becky:

Thanks for the reply.   Agree I should read bookE, which given the short
schedule, it is still on my TODO list yet.

So are you saying linker does all the relative reference, that the bl  foo
is always relative even though the foo is defined in a different module? (In
my case, bl call is made in head.S, early_init() is defined in another file
setup.c).   

Regards,

Jim




Becky Bruce wrote:
> 
> 
> On Jul 13, 2007, at 5:07 PM, meerkat wrote:
> 
>>
>> Figure that out, the bootstrap actually mapped the first 16M from  
>> C000000 to
>> the physicall address,
>> so calling a c routine, as long as it is in the first 16M, is OK
>>
> 
> I think you're still not understanding the fact that "bl" is a  
> *relative* branch - the branch target in the instruction encoding is  
> just an offset from the current address, not an effective address.   
> The bl should work correctly whether the code is actually running at  
> the link address reported by nm (0xcxxxxxxx in this case), or if it  
> has been loaded and executed elsewhere.
> 
> Refer to the 32-bit Programming Environments Manual for PowerPC, or  
> in the EREF (if you're using a BookE part - e500/e200) for more  
> details.  If you're just learning PowerPC assembler, you should  
> really give this book a good thourough read.
> 
>>
>> meerkat wrote:
>>>
>>> Good day all,
>>>
>>> For the first time I begin working on PPC, and on low level, and  
>>> right
>>> start from boot sequence, one issue puzzled me.
>>>
>>> After bootstrap code (zImage) uncompressed the kernel vmLinux to  
>>> physical
>>> memory (say from addr 0),
>>> it jumps to the kernel entry point, _start, using physically address.
> 
> If you read the book specified above, you will see that branch  
> instructions always specify an effective address, not a physical  
> address.  You can disable translation or map the address so EA=PA,  
> but that's a different issue.
> 
> -Becky
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 

-- 
View this message in context: http://www.nabble.com/boottime-kernel-relocation%2C-what-I-missed--tf4072673.html#a11629480
Sent from the linuxppc-embedded mailing list archive at Nabble.com.



From becky.bruce at freescale.com  Tue Jul 17 06:51:31 2007
From: becky.bruce at freescale.com (Becky Bruce)
Date: Mon, 16 Jul 2007 15:51:31 -0500
Subject: boottime kernel relocation, what I missed?
In-Reply-To: <11629480.post@talk.nabble.com>
References: <11574529.post@talk.nabble.com> <11588451.post@talk.nabble.com>
	<0C6B2DC2-7621-4798-B3F7-7F1962A1D1A9@freescale.com>
	<11629480.post@talk.nabble.com>
Message-ID: <F81B60DC-AC55-401C-812D-824C77BDD502@freescale.com>


On Jul 16, 2007, at 2:36 PM, meerkat wrote:

> So are you saying linker does all the relative reference, that the  
> bl  foo
> is always relative even though the foo is defined in a different  
> module? (In
> my case, bl call is made in head.S, early_init() is defined in  
> another file
> setup.c).

If you see "bl foo", it's relative.  It has to be, because that's how  
the instruction works.   Also, it's not really in a different module,  
it's just a different file, but it's all linked into a single  
executable image.

Cheers,
-Becky

>
> Regards,
>
> Jim
>
>
>
>
> Becky Bruce wrote:
>>
>>
>> On Jul 13, 2007, at 5:07 PM, meerkat wrote:
>>
>>>
>>> Figure that out, the bootstrap actually mapped the first 16M from
>>> C000000 to
>>> the physicall address,
>>> so calling a c routine, as long as it is in the first 16M, is OK
>>>
>>
>> I think you're still not understanding the fact that "bl" is a
>> *relative* branch - the branch target in the instruction encoding is
>> just an offset from the current address, not an effective address.
>> The bl should work correctly whether the code is actually running at
>> the link address reported by nm (0xcxxxxxxx in this case), or if it
>> has been loaded and executed elsewhere.
>>
>> Refer to the 32-bit Programming Environments Manual for PowerPC, or
>> in the EREF (if you're using a BookE part - e500/e200) for more
>> details.  If you're just learning PowerPC assembler, you should
>> really give this book a good thourough read.
>>
>>>
>>> meerkat wrote:
>>>>
>>>> Good day all,
>>>>
>>>> For the first time I begin working on PPC, and on low level, and
>>>> right
>>>> start from boot sequence, one issue puzzled me.
>>>>
>>>> After bootstrap code (zImage) uncompressed the kernel vmLinux to
>>>> physical
>>>> memory (say from addr 0),
>>>> it jumps to the kernel entry point, _start, using physically  
>>>> address.
>>
>> If you read the book specified above, you will see that branch
>> instructions always specify an effective address, not a physical
>> address.  You can disable translation or map the address so EA=PA,
>> but that's a different issue.
>>
>> -Becky
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded at ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>
> -- 
> View this message in context: http://www.nabble.com/boottime-kernel- 
> relocation%2C-what-I-missed--tf4072673.html#a11629480
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded



From sureshtang at gmail.com  Tue Jul 17 15:59:04 2007
From: sureshtang at gmail.com (suresh suresh)
Date: Tue, 17 Jul 2007 11:29:04 +0530
Subject: Linuxppc-embedded Digest, Vol 35, Issue 33
In-Reply-To: <469B9825.6070507@freescale.com>
References: <mailman.1061.1184600645.8639.linuxppc-embedded@ozlabs.org>
	<D83235F0F3C86D4D889D8B9A0DA8C6D78D7DE9@corpexc01.corp.networkrobots.com>
	<469B9825.6070507@freescale.com>
Message-ID: <e5eb93010707162259l2e78c524s32ff260b3d930bdb@mail.gmail.com>

Thanks....

MPC8280 has internal memory space which contains Dualport(Dp) RAM. In the
DpRAM we allocate some tables and these has to store pointer of the buffers
which are allocated in external memory. Core will use this pointer to access
the buffers, basically these buffers are used for DMA.

Using IMMR register we can get physical address of the internal memory. Now
can I store the address return by the kmalloc() function? or I should
convert it into physical?

Please help me how to resove this address translation.


Regards,
Suresh

On 7/16/07, Scott Wood <scottwood at freescale.com> wrote:
>
> Siva Prasad wrote:
> > It returns kernel virtual address. If you use this buffer space for DMA,
> > please use appropriate flags. You may use __pa(address) or
> > virt_to_phys() to convert virtual to physical.
>
> No, you may not -- physical and DMA addresses are not always identical.
>   Use the DMA mapping API.
>
> -Scott
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070717/73c0165f/attachment.htm 

From Jorge.Ramirez-Ortiz at xerox.com  Wed Jul 18 00:21:18 2007
From: Jorge.Ramirez-Ortiz at xerox.com (Ramirez-Ortiz, Jorge)
Date: Tue, 17 Jul 2007 15:21:18 +0100
Subject: Machine check exception. 2.6.20 powerpc tree. 
Message-ID: <35786B99AB3FDC45A8215724617919730136DA91@gbrwgceumf01.eu.xerox.net>

Running our multithreaded application on ppc8548 (E500 core) generates a
machine check exception when trying to access some ASIC's registers
mapped on the PCI space (This application maps a PCI device to access
its registers)

 

machine_check_exception: task my_process, MCSR=0x10008, NIP=0x10153530

Machine check in user mode.

Caused by (from MCSR=10008): Guarded Load or Cache-Inhibited stwcx.

Bus - Read Data Bus Error

 

Here is the assembly dump of the region of code containing the offending
instruction in user-space, with SRR0 pointing us at 0x10153530 when the
exception is raised:

 

0x10153528 <_ZN2vk7in_le32EPVKj+16>:    lwz     r0,8(r31)

0x1015352c <_ZN2vk7in_le32EPVKj+20>:    lwz     r9,8(r31)

0x10153530 <_ZN2vk7in_le32EPVKj+24>:    lwbrx   r0,0,r0

0x10153534 <_ZN2vk7in_le32EPVKj+28>:    twi     0,r0,0

0x10153538 <_ZN2vk7in_le32EPVKj+32>:    isync

 

All this is fully reproducible, the offending code is repeatedly the
byte-reverse load within the (m)mapped PCI memory segment. The offset
within the segment may vary, even if most of the hits seem to be taken
when reading 0x20030-0x20034 offsets from 0x80000000 PCI address space
(which is mapped to the application via /dev/mem)

 

/proc/pid/maps reports the following mappings to /dev/mem, with the
first one being an ASIC on the PCI space whose registers we are trying
to access, and the second one being system memory (this system memory is
out of kernel visibility...we use 'mem=256M' as a kernel parameter...):

 

303a9000-304a9000 rw-s 80000000 00:0c 2087       /dev/mem

304a9000-404a9000 rw-s 10000000 00:0c 2087       /dev/mem

 

Has anybody experienced something similar using a kernel based on a
2.6.20 powerpc tree? 

 

Many thanks

 

jorge

 

______________________________

Jorge Ramirez-Ortiz

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070717/4814cca1/attachment.htm 

From borish at batm.co.il  Wed Jul 18 00:42:23 2007
From: borish at batm.co.il (Boris Shteinbock)
Date: Tue, 17 Jul 2007 17:42:23 +0300
Subject: Memory Corruption in Linux kernel MPC8347 revision 3
Message-ID: <1184683343.3337.57.camel@localhost.localdomain>

	Hi Everyone.
I am working on the Linux port for MPC8347 revision 3 custom build board
with DDR2 memory.

I've successfully ported U-boot (latest git) and the kernel itself,
however during kernel boot I am encountering serious memory corruption
errors. The log for one of the examples is at the bottom of this
message.

Basically, the corruption is always happening somewhere at memory
management intensive tasks such as networking, JFFS2 mounting etc.

As far as I can see, it is not related to some specific driver, because
even it happens even at kernel configured at absolute minimum, ( console
serial driver only and even without it)
The place of the corruption depends on kernel configuration.

The DDR2 memory controller is configured correctly as far as I can tell,
since :
1. DDR2 controller register values are taken from VxWorks bootrom 
that works on this board without any problems.
2. u-boot mtest passes successfully
3. u-boot alternative mtest passes successfully
4. My own custom mem tests in u-boot pass successfully
5. If I manage two boot the board into shell prompt (with absolute
minimum configuration) memtester application is also successful. 

The minimum configuration that is one I am able to boot into shell is a
kernel configured with serial console and small busybox JFFS2 file
system in the flash. In this configuration, the boot fails the first
time JFFS2 root FS is mounted. However it does boot after reset.

I've tried different kernels with the same results  starting from, I
think, 2.6.16  up to 2.6.22
I tried the kernel that is provided by Freescale for 834x reference
boards. ( with my board support of course)

I tried booting both OF flat trees (powerpc) and bd_t based builds (ppc)

I've also tried all memory management options :
SLAB, SLOB and SLUB (in the latest kernel). They all failed at some
point of time, so the assumption is that the problem is not in the
memory management facilities.

The board manufacturer swears that DDR2 memory controller values are
correct and should work perfectly.

So now I almost out of options and I am seeking your help.
Any type of input on this issue would be greatly appreciated. 

Thanks,
Boris

PS. Note that an below example represents failure during DHCP
autoconfiguration. However the similar error happens even when
networking is disabled completely. just in a different place.

=> bootm
## Booting image at 00400000 ...
   Image Name:   Linux-.6.21.5
   Created:      2007-07-10  14:20:19 UTC
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    898361 Bytes = 877.3 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
## Current stack ends at 0x07FA3CF8 => set upper limit to 0x00800000
## cmdline at 0x007FFF00 ... 0x007FFF41
bd address  = 0x07FA3FBC
memstart    = 0x00000000
memsize     = 0x08000000
flashstart  = 0xFE000000
flashsize   = 0x02000000
flashoffset = 0x00033000
sramstart   = 0x00000000
sramsize    = 0x00000000
bootflags   = 0x00000001
intfreq     =    528 MHz
busfreq     =    264 MHz
ethaddr     = 00:04:9F:EF:23:35
eth1addr    = 00:E0:0C:00:7E:25
IP addr     = 10.2.222.20
baudrate    = 115200 bps
No initrd
## Transferring control to Linux (at address 00000000) ...
!!!! of_flat_tree = 00000000
Booting without OF Flat tree
Linux version .6.21.5 (me at localhost) (gcc version
4.0.0 (DENX ELDK 4.1 4.0.0)) #24 Tue Jul 10 17:20:09 IDT 2007
Zone PFN ranges:
  DMA             0 ->    32768
  Normal      32768 ->    32768
early_node_map[1] active PFN ranges
    0:        0 ->    32768
Built 1 zonelists.  Total pages: 32512
Kernel command line: console=ttyS0,115200 root=/dev/mtdblock1
rootfstype=jffs2 ip=dhcp
IPIC (128 IRQ sources, 8 External IRQs) at fe000700
PID hash table entries: 512 (order: 9, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 127744k available (1584k kernel code, 444k data, 84k init, 0k
highmem)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
Setup MTD partitions
Generic PHY: Registered new driver
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing
disabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 9) is a 16550A
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 10) is a 16550A
Gianfar MII Bus: probed
eth0: Gianfar Ethernet Controller Version 1.2, 00:04:9f:ef:23:35
eth0: Running with NAPI disabled
eth0: 64/64 RX/TX BD ring size
Broadcom BCM5241: Registered new driver
physmap platform flash device: 02000000 at fe000000
physmap-flash.0: Found 1 x16 devices at 0x0 in 8-bit bank
 Amd/Fujitsu Extended Query Table at 0x0040
physmap-flash.0: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
cmdlinepart partition parsing not available
RedBoot partition parsing not available
Using physmap partition information
Creating 2 MTD partitions on "physmap-flash.0":
0x00000000-0x00100000 : "uboot"
0x00100000-0x02000000 : "rootfs"
IPv4 over IPv4 tunneling driver
GRE over IPv4 tunneling driver
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
!!!! Gianfar init_phy. phy_id = 0:01
!!!! phy_attach. phy_id = 0:01
!!!! phy_attach device found. phy_id = 0:01
Sending DHCP requests .<3>slab: Internal list corruption detected in
cache 'files_cache'(21), slabp c0344000(16). Hexdump:

000: 00 10 01 00 00 20 02 00 00 00 00 70 c0 34 40 70
010: 00 00 00 10 00 00 ff 10 00 00 00 00 ff ff ff fe
020: ff ff ff fe ff ff ff fe ff ff ff fe ff ff ff fe
030: ff ff ff fe ff ff ff fe ff ff ff fe ff ff ff fe
040: ff ff ff fe ff ff ff fe ff ff ff fe ff ff ff fe
050: ff ff ff fe ff ff ff fe ff ff ff fd 00 00 00 11
060: 00 00 00 12 00 00 00 13 00 00 00 14 ff ff ff ff
------------[ cut here ]------------
kernel BUG at mm/slab.c:2936!
Oops: Exception in kernel mode, sig: 5 [#1]
NIP: C0050F80 LR: C0050F80 CTR: 00000000
REGS: c034fe00 TRAP: 0700   Not tainted  (.6.21.5)
MSR: 00021032 <ME,IR,DR>  CR: 24004002  XER: 00000000
TASK = c032a3c0[3] 'events/0' THREAD: c034e000
GPR00: C0050F80 C034FEB0 C032A3C0 00000001 00000DF5 FFFFFFFF C00F5B54
00000010
GPR08: C01D0000 C01E0000 00000DF5 00000DF5 00000000 00F1C5DB 07FFD000
FFFFFFFF
GPR16: 00000001 00000000 00000000 00800000 00000000 007FFF00 00000000
C033DAA0
GPR24: C0339C90 00000007 00000000 C01B0000 C01B0000 C0344000 C033DAA0
00000070
NIP [C0050F80] check_slabp+0xe4/0x11c
LR [C0050F80] check_slabp+0xe4/0x11c
Call Trace:
[C034FEB0] [C0050F80] check_slabp+0xe4/0x11c (unreliable)
[C034FED0] [C0051450] free_block+0x88/0x138
[C034FF00] [C0052188] drain_array+0xa0/0xe0
[C034FF20] [C0052228] cache_reap+0x60/0x144
[C034FF40] [C00257B0] run_workqueue+0xd0/0x170
[C034FF60] [C0025960] worker_thread+0x110/0x144
[C034FFC0] [C00298E4] kthread+0x74/0xb0
[C034FFF0] [C0005F38] kernel_thread+0x44/0x60
Instruction dump:
387b6538 7c9df8ae 4bfc2b49 3bff0001 813e0020 5529103a 3929001c 7f9f4840
419cffcc 3c60c01b 3863336c 4bfc2b25 <0fe00000> 48000000 80030020
2f800000
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070717/a7cc8ae8/attachment.htm 

From scottwood at freescale.com  Wed Jul 18 02:02:18 2007
From: scottwood at freescale.com (Scott Wood)
Date: Tue, 17 Jul 2007 11:02:18 -0500
Subject: Linuxppc-embedded Digest, Vol 35, Issue 33
In-Reply-To: <e5eb93010707162259l2e78c524s32ff260b3d930bdb@mail.gmail.com>
References: <mailman.1061.1184600645.8639.linuxppc-embedded@ozlabs.org>	
	<D83235F0F3C86D4D889D8B9A0DA8C6D78D7DE9@corpexc01.corp.networkrobots.com>	
	<469B9825.6070507@freescale.com>
	<e5eb93010707162259l2e78c524s32ff260b3d930bdb@mail.gmail.com>
Message-ID: <469CE80A.5080204@freescale.com>

suresh suresh wrote:
> MPC8280 has internal memory space which contains Dualport(Dp) RAM. In the
> DpRAM we allocate some tables and these has to store pointer of the buffers
> which are allocated in external memory. Core will use this pointer to 
> access
> the buffers, basically these buffers are used for DMA.
> 
> Using IMMR register we can get physical address of the internal memory. Now
> can I store the address return by the kmalloc() function? or I should
> convert it into physical?

Yes, you need to convert it to physical.  As I said earlier, use the DMA 
mapping API (described in Documentation/DMA-mapping.txt) to do so. 
Specifically, look at the dma_map_single() function.

-Scott


From galak at kernel.crashing.org  Wed Jul 18 02:29:29 2007
From: galak at kernel.crashing.org (Kumar Gala)
Date: Tue, 17 Jul 2007 11:29:29 -0500
Subject: Machine check exception. 2.6.20 powerpc tree. 
In-Reply-To: <35786B99AB3FDC45A8215724617919730136DA91@gbrwgceumf01.eu.xerox.net>
References: <35786B99AB3FDC45A8215724617919730136DA91@gbrwgceumf01.eu.xerox.net>
Message-ID: <43F1785C-E5DA-4460-A9C7-9B02431F1FE0@kernel.crashing.org>


On Jul 17, 2007, at 9:21 AM, Ramirez-Ortiz, Jorge wrote:

> Running our multithreaded application on ppc8548 (E500 core)  
> generates a machine check exception when trying to access some  
> ASIC?s registers mapped on the PCI space (This application maps a  
> PCI device to access its registers)
>
>
>
> machine_check_exception: task my_process, MCSR=0x10008, NIP=0x10153530
>
> Machine check in user mode.
>
> Caused by (from MCSR=10008): Guarded Load or Cache-Inhibited stwcx.
>
> Bus - Read Data Bus Error
>
>
>
> Here is the assembly dump of the region of code containing the  
> offending instruction in user-space, with SRR0 pointing us at  
> 0x10153530 when the exception is raised:
>
>
>
> 0x10153528 <_ZN2vk7in_le32EPVKj+16>:    lwz     r0,8(r31)
>
> 0x1015352c <_ZN2vk7in_le32EPVKj+20>:    lwz     r9,8(r31)
>
> 0x10153530 <_ZN2vk7in_le32EPVKj+24>:    lwbrx   r0,0,r0
>
> 0x10153534 <_ZN2vk7in_le32EPVKj+28>:    twi     0,r0,0
>
> 0x10153538 <_ZN2vk7in_le32EPVKj+32>:    isync

Can you get the code to dump the value of r0.  I'm wondering if  
you're really getting a read data bus error due to the fact that r0  
is pointing to a PCI address that doesn't have a device that will  
respond.

- k




From joseph.robertson at sanmina-sci.com  Wed Jul 18 08:14:56 2007
From: joseph.robertson at sanmina-sci.com (Robertson, Joseph M.)
Date: Tue, 17 Jul 2007 17:14:56 -0500
Subject: Cypress c67x00 Support?
Message-ID: <939D37AEB47F1F49B88FAB6599B6023501A1721C@hsv1dafpew02.das.gov.sanm.corp>

Hi,

I have some questions about the Cypress c67x00 code that was posted a few days ago.
I got the many patches from the git (thanks Grant!), but I am wondering, 

How did you guys fix up the Kconfigs to work with the Xilinx Virtex-4 fpga?

My hw guys have put the cypress chip on 'the system ace'(OPB?) bus, a 16 bit bus, and I have the address to it.

But its definetely not PCI, and if you use a plain kernel tree like I have, I cannot access any features without turning on the PCI options.  Which of course fails, since I have no PCI parameters to feed the code.

Perhaps a better question is: Is this code intended for the Virtex-4?
If no, then I will have to fix it up.


Thanks,

Joe Robertson
Joseph.Robertson at sanmina-sci.com


CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited.  If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING.  Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), or any other person or entity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070717/edb59a79/attachment.htm 

From sprasad at bivio.net  Wed Jul 18 08:41:05 2007
From: sprasad at bivio.net (Siva Prasad)
Date: Tue, 17 Jul 2007 15:41:05 -0700
Subject: Linuxppc-embedded Digest, Vol 35, Issue 33
In-Reply-To: <e5eb93010707162259l2e78c524s32ff260b3d930bdb@mail.gmail.com>
References: <mailman.1061.1184600645.8639.linuxppc-embedded@ozlabs.org>
	<D83235F0F3C86D4D889D8B9A0DA8C6D78D7DE9@corpexc01.corp.networkrobots.com>
	<469B9825.6070507@freescale.com>
	<e5eb93010707162259l2e78c524s32ff260b3d930bdb@mail.gmail.com>
Message-ID: <D83235F0F3C86D4D889D8B9A0DA8C6D78D7FAF@corpexc01.corp.networkrobots.com>

Well!... you can manage any way you want.

 

1) You can store the virtual address in the DpRAM, and convert to
physical (should I say DMA mapped address) and then pass it on to the
device under consideration here.

 

2) Other way would be... store the physical address in DpRAM. Use that
address for the device, and convert to virtual before you use it in the
code.

 

My preference is for first option.

 

- Siva

 

 

________________________________

From: suresh suresh [mailto:sureshtang at gmail.com] 
Sent: Monday, July 16, 2007 10:59 PM
To: Scott Wood
Cc: Siva Prasad; linuxppc-embedded at ozlabs.org
Subject: Re: Linuxppc-embedded Digest, Vol 35, Issue 33

 

Thanks....

MPC8280 has internal memory space which contains Dualport(Dp) RAM. In
the DpRAM we allocate some tables and these has to store pointer of the
buffers which are allocated in external memory. Core will use this
pointer to access the buffers, basically these buffers are used for DMA.

Using IMMR register we can get physical address of the internal memory.
Now can I store the address return by the kmalloc() function? or I
should convert it into physical?

Please help me how to resove this address translation.


Regards,
Suresh

On 7/16/07, Scott Wood <scottwood at freescale.com> wrote:

Siva Prasad wrote:
> It returns kernel virtual address. If you use this buffer space for
DMA,
> please use appropriate flags. You may use __pa(address) or
> virt_to_phys() to convert virtual to physical. 

No, you may not -- physical and DMA addresses are not always identical.
  Use the DMA mapping API.

-Scott

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070717/1a04956f/attachment.htm 

From scottwood at freescale.com  Wed Jul 18 08:51:07 2007
From: scottwood at freescale.com (Scott Wood)
Date: Tue, 17 Jul 2007 17:51:07 -0500
Subject: Linuxppc-embedded Digest, Vol 35, Issue 33
In-Reply-To: <D83235F0F3C86D4D889D8B9A0DA8C6D78D7FAF@corpexc01.corp.networkrobots.com>
References: <mailman.1061.1184600645.8639.linuxppc-embedded@ozlabs.org>
	<D83235F0F3C86D4D889D8B9A0DA8C6D78D7DE9@corpexc01.corp.networkrobots.com>
	<469B9825.6070507@freescale.com>
	<e5eb93010707162259l2e78c524s32ff260b3d930bdb@mail.gmail.com>
	<D83235F0F3C86D4D889D8B9A0DA8C6D78D7FAF@corpexc01.corp.networkrobots.com>
Message-ID: <469D47DB.7070804@freescale.com>

Siva Prasad wrote:
> Well!... you can manage any way you want.
> 
>  
> 
> 1) You can store the virtual address in the DpRAM, and convert to
> physical (should I say DMA mapped address) and then pass it on to the
> device under consideration here.

The DPRAM is read directly by the microcode (if it didn't, you'd just be 
using RAM).  You don't want to put virtual addresses in there.

-Scott


From grant.likely at secretlab.ca  Wed Jul 18 12:18:32 2007
From: grant.likely at secretlab.ca (Grant Likely)
Date: Tue, 17 Jul 2007 20:18:32 -0600
Subject: Cypress c67x00 Support?
In-Reply-To: <939D37AEB47F1F49B88FAB6599B6023501A1721C@hsv1dafpew02.das.gov.sanm.corp>
References: <939D37AEB47F1F49B88FAB6599B6023501A1721C@hsv1dafpew02.das.gov.sanm.corp>
Message-ID: <fa686aa40707171918g2ff34d7kef320c6d409ca676@mail.gmail.com>

On 7/17/07, Robertson, Joseph M. <joseph.robertson at sanmina-sci.com> wrote:
>
>
>
> Hi,
>
>  I have some questions about the Cypress c67x00 code that was posted a few
> days ago.
>  I got the many patches from the git (thanks Grant!), but I am wondering,
>
>  How did you guys fix up the Kconfigs to work with the Xilinx Virtex-4 fpga?

You need to register the device on the platform bus.  Look at
arch/ppc/syslib/virtex_devices.c and
arch/ppc/platforms/4xx/xparameters/xparameters.h.  You need to fixup
your xparameters file to match up with the c67x00 registration in
virtex_devices.c. (hint: look at the XPAR_C67x00_USB macro)

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195


From akpm at linux-foundation.org  Wed Jul 18 17:52:53 2007
From: akpm at linux-foundation.org (Andrew Morton)
Date: Wed, 18 Jul 2007 00:52:53 -0700
Subject: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access
	of bad area during boot with DEBUG_SLAB=y
In-Reply-To: <bug-8778-10286@http.bugzilla.kernel.org/>
References: <bug-8778-10286@http.bugzilla.kernel.org/>
Message-ID: <20070718005253.942f0464.akpm@linux-foundation.org>

On Wed, 18 Jul 2007 00:07:50 -0700 (PDT) bugme-daemon at bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=8778
> 
>            Summary: Ocotea board: kernel reports access of bad area during
>                     boot with DEBUG_SLAB=y
>            Product: Platform Specific/Hardware
>            Version: 2.5
>      KernelVersion: 2.6.22
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: PPC-32
>         AssignedTo: platform_ppc-32 at kernel-bugs.osdl.org
>         ReportedBy: bart.vanassche at gmail.com
> 
> 
> Most recent kernel where this bug did not occur: not known - was probably
> already an issue in 2.6.10
> Distribution: not relevant for this issue.
> Hardware Environment: AMCC Ocotea board
> Software Environment: not relevant for this issue.
> Problem Description: see title.
> 
> Steps to reproduce:
> 1. Compile the 2.6.22 kernel with the attached .config
> 2. Boot an Ocotea  board with this kernel.
> 3. Observe the output that appears on the serial console.
> 
> U-Boot 1.1.1 (Nov 10 2005 - 16:29:34)
> 
> IBM PowerPC 440 GUNKNOWN (PVR=51b21892)
> Board: IBM 440GX Evaluation Board
>         VCO: 1066 MHz
>         CPU: 533 MHz
>         PLB: 152 MHz
>         OPB: 76 MHz
>         EPB: 76 MHz
> I2C:   ready
> DRAM:  I2c read: failed 4
> I2c read: failed 4
> 256 MB
> FLASH:  5 MB
> PCI:   Bus Dev VenId DevId Class Int
> In:    serial
> Out:   serial
> Err:   serial
> KGDB:  kgdb ready
> ready
> Net:   ppc_440x_eth0
> BEDBUG:ready
> => boot
> Waiting for PHY auto negotiation to complete.. done
> ENET Speed is 100 Mbps - FULL duplex connection
> Using ppc_440x_eth0 device
> TFTP from server 172.30.36.154; our IP address is 172.30.39.77
> Filename 'ocotea-vanassb'.
> Load address: 0x1000000
> Loading: T #################################################################
>          #################################################################
>          #################################################################
>          #################################################################
>          #################
> done
> Bytes transferred = 1415440 (159910 hex)
> Automatic boot of image at addr 0x01000000 ...
> ## Booting image at 01000000 ...
>    Image Name:   Linux-2.6.22
>    Created:      2007-07-18   6:53:56 UTC
>    Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>    Data Size:    1415376 Bytes =  1.3 MB
>    Load Address: 00000000
>    Entry Point:  00000000
>    Verifying Checksum ... OK
>    Uncompressing Kernel Image ... OK
> Linux version 2.6.22 (vanassb at sabekorlnx05) (gcc version 3.4.3 (MontaVista
> 3.4.7
> IBM Ocotea port (MontaVista Software, Inc. <source at mvista.com>)
> Zone PFN ranges:
>   DMA             0 ->    65536
>   Normal      65536 ->    65536
> early_node_map[1] active PFN ranges
>     0:        0 ->    65536
> Built 1 zonelists.  Total pages: 65024
> Kernel command line: root=/dev/nfs
> nfsroot=172.30.36.154:/nfs-export/RFS_MVL4-00
> PID hash table entries: 1024 (order: 10, 4096 bytes)
> ------------------------
> | Locking API testsuite:
> ----------------------------------------------------------------------------
>                                  | spin |wlock |rlock |mutex | wsem | rsem |
>   --------------------------------------------------------------------------
>                      A-A deadlock:failed|failed|  ok  |failed|failed|failed|
>                  A-B-B-A deadlock:failed|failed|  ok  |failed|failed|failed|
>              A-B-B-C-C-A deadlock:failed|failed|  ok  |failed|failed|failed|
>              A-B-C-A-B-C deadlock:failed|failed|  ok  |failed|failed|failed|
>          A-B-B-C-C-D-D-A deadlock:failed|failed|  ok  |failed|failed|failed|
>          A-B-C-D-B-D-D-A deadlock:failed|failed|  ok  |failed|failed|failed|
>          A-B-C-D-B-C-D-A deadlock:failed|failed|  ok  |failed|failed|failed|
>                     double unlock:  ok  |  ok  |failed|  ok  |failed|failed|
>                   initialize held:failed|failed|failed|failed|failed|failed|
>                  bad unlock order:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
>   --------------------------------------------------------------------------
>               recursive read-lock:             |  ok  |             |failed|
>            recursive read-lock #2:             |  ok  |             |failed|
>             mixed read-write-lock:             |failed|             |failed|
>             mixed write-read-lock:             |failed|             |failed|
>   --------------------------------------------------------------------------
>      hard-irqs-on + irq-safe-A/12:failed|failed|  ok  |
>      soft-irqs-on + irq-safe-A/12:failed|failed|  ok  |
>      hard-irqs-on + irq-safe-A/21:failed|failed|  ok  |
>      soft-irqs-on + irq-safe-A/21:failed|failed|  ok  |
>        sirq-safe-A => hirqs-on/12:failed|failed|  ok  |
>        sirq-safe-A => hirqs-on/21:failed|failed|  ok  |
>          hard-safe-A + irqs-on/12:failed|failed|  ok  |
>          soft-safe-A + irqs-on/12:failed|failed|  ok  |
>          hard-safe-A + irqs-on/21:failed|failed|  ok  |
>          soft-safe-A + irqs-on/21:failed|failed|  ok  |
>     hard-safe-A + unsafe-B #1/123:failed|failed|  ok  |
>     soft-safe-A + unsafe-B #1/123:failed|failed|  ok  |
>     hard-safe-A + unsafe-B #1/132:failed|failed|  ok  |
>     soft-safe-A + unsafe-B #1/132:failed|failed|  ok  |
>     hard-safe-A + unsafe-B #1/213:failed|failed|  ok  |
>     soft-safe-A + unsafe-B #1/213:failed|failed|  ok  |
>     hard-safe-A + unsafe-B #1/231:failed|failed|  ok  |
>     soft-safe-A + unsafe-B #1/231:failed|failed|  ok  |
>     hard-safe-A + unsafe-B #1/312:failed|failed|  ok  |
>     soft-safe-A + unsafe-B #1/312:failed|failed|  ok  |
>     hard-safe-A + unsafe-B #1/321:failed|failed|  ok  |
>     soft-safe-A + unsafe-B #1/321:failed|failed|  ok  |
>     hard-safe-A + unsafe-B #2/123:failed|failed|  ok  |
>     soft-safe-A + unsafe-B #2/123:failed|failed|  ok  |
>     hard-safe-A + unsafe-B #2/132:failed|failed|  ok  |
>     soft-safe-A + unsafe-B #2/132:failed|failed|  ok  |
>     hard-safe-A + unsafe-B #2/213:failed|failed|  ok  |
>     soft-safe-A + unsafe-B #2/213:failed|failed|  ok  |
>     hard-safe-A + unsafe-B #2/231:failed|failed|  ok  |
>     soft-safe-A + unsafe-B #2/231:failed|failed|  ok  |
>     hard-safe-A + unsafe-B #2/312:failed|failed|  ok  |
>     soft-safe-A + unsafe-B #2/312:failed|failed|  ok  |
>     hard-safe-A + unsafe-B #2/321:failed|failed|  ok  |
>     soft-safe-A + unsafe-B #2/321:failed|failed|  ok  |
>       hard-irq lock-inversion/123:failed|failed|  ok  |
>       soft-irq lock-inversion/123:failed|failed|  ok  |
>       hard-irq lock-inversion/132:failed|failed|  ok  |
>       soft-irq lock-inversion/132:failed|failed|  ok  |
>       hard-irq lock-inversion/213:failed|failed|  ok  |
>       soft-irq lock-inversion/213:failed|failed|  ok  |
>       hard-irq lock-inversion/231:failed|failed|  ok  |
>       soft-irq lock-inversion/231:failed|failed|  ok  |
>       hard-irq lock-inversion/312:failed|failed|  ok  |
>       soft-irq lock-inversion/312:failed|failed|  ok  |
>       hard-irq lock-inversion/321:failed|failed|  ok  |
>       soft-irq lock-inversion/321:failed|failed|  ok  |
>       hard-irq read-recursion/123:  ok  |
>       soft-irq read-recursion/123:  ok  |
>       hard-irq read-recursion/132:  ok  |
>       soft-irq read-recursion/132:  ok  |
>       hard-irq read-recursion/213:  ok  |
>       soft-irq read-recursion/213:  ok  |
>       hard-irq read-recursion/231:  ok  |
>       soft-irq read-recursion/231:  ok  |
>       hard-irq read-recursion/312:  ok  |
>       soft-irq read-recursion/312:  ok  |
>       hard-irq read-recursion/321:  ok  |
>       soft-irq read-recursion/321:  ok  |
> --------------------------------------------------------
> 142 out of 218 testcases failed, as expected. |
> ----------------------------------------------------
> Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
> Memory: 256768k available (2088k kernel code, 816k data, 128k init, 0k highmem)
> Mount-cache hash table entries: 512
> NET: Registered protocol family 16
> PCI: Probing PCI hardware
> NET: Registered protocol family 2
> IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
> TCP established hash table entries: 8192 (order: 5, 163840 bytes)
> TCP bind hash table entries: 8192 (order: 5, 163840 bytes)
> TCP: Hash tables configured (established 8192 bind 8192)
> TCP reno registered
> Installing knfsd (copyright (C) 1996 okir at monad.swb.de).
> io scheduler noop registered
> io scheduler deadline registered (default)
> Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled
> serial8250: ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
> serial8250: ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> loop: module loaded
> PPC 4xx OCP EMAC driver, version 3.54
> mal0: initialized, 4 TX channels, 4 RX channels
> zmii0: bridge in SMII mode
> eth0: emac0, MAC 00:04:ac:e3:28:8a
> eth0: found Generic MII PHY (0x01)
> eth1: emac1, MAC 00:00:00:00:00:00
> eth1: found Generic MII PHY (0x02)
> rgmii0: input 0 in RGMII mode
> eth2: emac2, MAC 00:00:00:00:00:00
> eth2: found CIS8201 Gigabit Ethernet PHY (0x10)
> rgmii0: input 1 in RGMII mode
> eth3: emac3, MAC 00:00:00:00:00:00
> eth3: found CIS8201 Gigabit Ethernet PHY (0x18)
> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
> i2c /dev entries driver
> IBM IIC driver v2.1
> ibm-iic0: using standard (100 kHz) mode
> ibm-iic1: using standard (100 kHz) mode
> Netfilter messages via NETLINK v0.30.
> TCP cubic registered
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> eth0: link is down
> IP-Config: Complete:
>       device=eth0, addr=172.30.39.77, mask=255.255.252.0, gw=172.30.39.254,
>      host=ocotea, domain=, nis-domain=(none),
>      bootserver=172.30.36.154, rootserver=172.30.36.154, rootpath=
> Looking up port of RPC 100003/3 on 172.30.36.154
> eth0: link is up, 100 FDX, pause enabled
> Looking up port of RPC 100005/3 on 172.30.36.154
> VFS: Mounted root (nfs filesystem) readonly.
> Freeing unused kernel memory: 128k init
> Oops: kernel access of bad area, sig: 11 [#1]
> PREEMPT
> NIP: c004be40 LR: c017d9d8 CTR: c01822fc
> REGS: c02b1af0 TRAP: 0300   Not tainted  (2.6.22)
> MSR: 00029000 <EE,ME>  CR: 28f22b24  XER: 20000000
> DAR: 99750000, DSISR: 00000000
> TASK = c0296830[0] 'swapper' THREAD: c02b0000
> GPR00: c017d9d8 c02b1ba0 c0296830 99750000 c026cb38 000000f8 3b92a76c c02d73ec
> GPR08: 0000000c 99750004 00000001 000006a8 00000781 5c8071f0 0fff1200 00000000
> GPR16: 00000001 00000001 c02ae020 c02d0000 080103cf 00000001 000003cf c02b1be8
> GPR24: c01f2c1c c02b1c30 000000f8 c07d3510 000000f8 c0786998 c0786998 99750000
> NIP [c004be40] put_page+0x18/0x170
> LR [c017d9d8] skb_release_data+0x70/0xb4
> Call Trace:
> [c02b1ba0] [000000f8] 0xf8 (unreliable)
> [c02b1bc0] [c017d9d8] skb_release_data+0x70/0xb4
> [c02b1bd0] [c017d730] kfree_skbmem+0x18/0xdc
> [c02b1be0] [c01b0d3c] tcp_read_sock+0x188/0x1d8
> [c02b1c20] [c01f3134] xs_tcp_data_ready+0x70/0x94
> [c02b1c50] [c01b960c] tcp_rcv_established+0x4b4/0x758
> [c02b1c80] [c01c1274] tcp_v4_do_rcv+0x15c/0x44c
> [c02b1cc0] [c01c1efc] tcp_v4_rcv+0x998/0xa58
> [c02b1d10] [c01a3d48] ip_local_deliver+0x1f8/0x320
> [c02b1d40] [c01a4450] ip_rcv+0x298/0x598
> [c02b1d70] [c0185828] netif_receive_skb+0x2d0/0x334
> [c02b1da0] [c01583e4] emac_poll_rx+0x140/0x724
> [c02b1df0] [c0155c50] mal_poll+0xa8/0x26c
> [c02b1e30] [c0185a88] net_rx_action+0x88/0x15c
> [c02b1e60] [c001facc] __do_softirq+0x78/0xd4
> [c02b1e90] [c0006d50] do_softirq+0x54/0x5c
> [c02b1ea0] [c001fb9c] irq_exit+0x60/0x80
> [c02b1eb0] [c0006cac] do_IRQ+0x68/0xb8
> [c02b1ec0] [c000201c] ret_from_except+0x0/0x18
> [c02b1f80] [c0009eb4] cpu_idle+0xe8/0xf8
> [c02b1fa0] [c0205278] rest_init+0x74/0x88
> [c02b1fc0] [c02b2724] start_kernel+0x250/0x2b4
> [c02b1ff0] [c00001e8] skpinv+0x190/0x1cc
> Instruction dump:
> 80010014 38210010 7c0803a6 4e800020 8163000c 4bffffb0 7c0802a6 9421ffe0
> bfa10014 39230004 90010024 7c7f1b78 <80030000> 700a4000 4082013c 7c004828
> Kernel panic - not syncing: Aiee, killing interrupt handler!
> Rebooting in 180 seconds..

hm, it's hard to tell if this is a net problem, a driver problem or
an NFS problem or what.



From laurentp at cse-semaphore.com  Wed Jul 18 18:33:20 2007
From: laurentp at cse-semaphore.com (Laurent Pinchart)
Date: Wed, 18 Jul 2007 10:33:20 +0200
Subject: WDT with 82xx
In-Reply-To: <8496f91a0707160415i251aa027x6ef3899b92a5fccc@mail.gmail.com>
References: <8496f91a0707160415i251aa027x6ef3899b92a5fccc@mail.gmail.com>
Message-ID: <200707181033.21045.laurentp@cse-semaphore.com>

On Monday 16 July 2007 13:15, Matvejchikov Ilya wrote:
> Hi all!
>
> Does anybody use watchdog timer with mpc82xx?

I do.

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chauss?e de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75


From ebs at ebshome.net  Wed Jul 18 18:34:25 2007
From: ebs at ebshome.net (Eugene Surovegin)
Date: Wed, 18 Jul 2007 01:34:25 -0700
Subject: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access
	of bad area during boot with DEBUG_SLAB=y
In-Reply-To: <20070718005253.942f0464.akpm@linux-foundation.org>
References: <bug-8778-10286@http.bugzilla.kernel.org/>
	<20070718005253.942f0464.akpm@linux-foundation.org>
Message-ID: <20070718083425.GA29722@gate.ebshome.net>

On Wed, Jul 18, 2007 at 12:52:53AM -0700, Andrew Morton wrote:
> On Wed, 18 Jul 2007 00:07:50 -0700 (PDT) bugme-daemon at bugzilla.kernel.org wrote:
> 
> > http://bugzilla.kernel.org/show_bug.cgi?id=8778
> > 
> >            Summary: Ocotea board: kernel reports access of bad area during
> >                     boot with DEBUG_SLAB=y

Slab debugging is probably the culprit here. I had similar problem 
couple of years ago, not sure something has changed since then, 
haven't checked.

When slab debugging was enabled it made memory allocations non L1 
cache line aligned. This is very bad for DMA on non-coherent cache 
arches (PPC440 is one of those archs).

I have a hack for EMAC which tries to "workaround" this problem:
	http://kernel.ebshome.net/emac_slab_debug.diff
which might help.

-- 
Eugene




From Jorge.Ramirez-Ortiz at xerox.com  Wed Jul 18 19:27:22 2007
From: Jorge.Ramirez-Ortiz at xerox.com (Ramirez-Ortiz, Jorge)
Date: Wed, 18 Jul 2007 10:27:22 +0100
Subject: Machine check exception. 2.6.20 powerpc tree. 
In-Reply-To: <43F1785C-E5DA-4460-A9C7-9B02431F1FE0@kernel.crashing.org>
Message-ID: <35786B99AB3FDC45A8215724617919730136DC04@gbrwgceumf01.eu.xerox.net>

Hi Kumar

The address we are trying to access corresponds to a mapped device in
the PCI space
Attached some additional debugging information (we have instrumented the
kernel)

Thanks
jorge


INFO [_probe]: Found Device [irq=58]
INFO [_open]: device opened with irq 58
INFO [_read]: waiting for interrupt
INFO [_intr]: ISR 58

PCI1: Error! ERR_DETECT=00000040, ATTR=00516001, addr=80020034,
data=00050000

machine_check_exception: task my_process, MCSR=0x10008, NIP=0x10153530
Machine check in user mode.
Caused by (from MCSR=10008): Guarded Load or Cache-Inhibited stwcx.
Bus - Read Data Bus Error

Call Trace:
[C7355EF0] [C0006E64] show_stack+0x48/0x19c (unreliable)
[C7355F20] [C000C04C] machine_check_exception+0x294/0x484
[C7355F40] [C000E48C] ret_from_mcheck_exc+0x0/0xe0

cat /proc/cpuinfo
processor       : 0
cpu             : e500v2
clock           : 799.500000MHz
revision        : 2.0 (pvr 8021 0020)
bogomips        : 99.84
timebase        : 49968750
platform        : MPC85xx CDS
Vendor          : Freescale Semiconductor
Machine         : MPC85xx CDS (0xff)
PVR             : 0x80210020
SVR             : 0x80390220
PLL setting     : 0x4
Memory          : 256 MB
LAW 1           : 00000000, 20000000 -> DDR SDRAM
LAW 2           : 80000000, 10000000 -> PCI1
LAW 3           : 90000000, 10000000 -> PCI2
LAW 4           : a0000000, 10000000 -> PCI Express
LAW 5           : e1000000, 01000000 -> PCI1
LAW 6           : e2000000, 01000000 -> PCI2
LAW 7           : e3000000, 01000000 -> PCI Express
LAW 8           : f0000000, 10000000 -> Local bus
DDR 0           : 00000000, 20000000 -> 2/14/10 addr bits
PCI1 Out_1      : 80000000, 10000000 -> Mem: 80000000
PCI1 Out_2      : e1000000, 01000000 -> I/O: 00000000
PCI2 Out_1      : 90000000, 10000000 -> Mem: 90000000
PCI2 Out_2      : e2000000, 01000000 -> I/O: 00000000
PCI3 Out_1      : a0000000, 10000000 -> Mem: a0000000
PCI3 Out_2      : e3000000, 01000000 -> I/O: 00000000
PCI1 In_1       : 00000000, 20000000 (Internal,R:snoop,W:snoop) <-
00000000 PF
PCI2 In_1       : 00000000, 20000000 (Internal,R:snoop,W:snoop) <-
00000000 PF
PCI3 In_1       : 00000000, 20000000 (Internal,R:snoop,W:snoop) <-
00000000 PF


______________________________

 

-----Original Message-----
From: Kumar Gala [mailto:galak at kernel.crashing.org] 
Sent: 17 July 2007 17:29
To: Ramirez-Ortiz, Jorge
Cc: linuxppc-embedded at ozlabs.org
Subject: Re: Machine check exception. 2.6.20 powerpc tree. 


On Jul 17, 2007, at 9:21 AM, Ramirez-Ortiz, Jorge wrote:

> Running our multithreaded application on ppc8548 (E500 core)  
> generates a machine check exception when trying to access some  
> ASIC's registers mapped on the PCI space (This application maps a  
> PCI device to access its registers)
>
>
>
> machine_check_exception: task my_process, MCSR=0x10008, NIP=0x10153530
>
> Machine check in user mode.
>
> Caused by (from MCSR=10008): Guarded Load or Cache-Inhibited stwcx.
>
> Bus - Read Data Bus Error
>
>
>
> Here is the assembly dump of the region of code containing the  
> offending instruction in user-space, with SRR0 pointing us at  
> 0x10153530 when the exception is raised:
>
>
>
> 0x10153528 <_ZN2vk7in_le32EPVKj+16>:    lwz     r0,8(r31)
>
> 0x1015352c <_ZN2vk7in_le32EPVKj+20>:    lwz     r9,8(r31)
>
> 0x10153530 <_ZN2vk7in_le32EPVKj+24>:    lwbrx   r0,0,r0
>
> 0x10153534 <_ZN2vk7in_le32EPVKj+28>:    twi     0,r0,0
>
> 0x10153538 <_ZN2vk7in_le32EPVKj+32>:    isync

Can you get the code to dump the value of r0.  I'm wondering if  
you're really getting a read data bus error due to the fact that r0  
is pointing to a PCI address that doesn't have a device that will  
respond.

- k




From kari.davidsson at marel.is  Wed Jul 18 21:13:52 2007
From: kari.davidsson at marel.is (=?iso-8859-1?B?S+FyaSBEYXbt8HNzb24=?=)
Date: Wed, 18 Jul 2007 11:13:52 -0000
Subject: OF devices and non OF devices
In-Reply-To: <4b73d43f0707051020o67e671dft1d3b3816776d8eb7@mail.gmail.com>
Message-ID: <DD39B5C3F4963040ADC9768BE7E430CB0211E4D2@is-hdq-exchange.marel.net>

Yes there was indeed.

Combination of my misunderstanding, device trees and board specific initialization.

Things are working now.

Thanks,
kd


________________________________

From: John Rigby [mailto:jcrigby at gmail.com] 
Sent: 5. j?l? 2007 17:21
To: K?ri Dav??sson
Cc: linuxppc-embedded at ozlabs.org
Subject: Re: OF devices and non OF devices


There must be something else wrong with your configuration.
On my Lite5200B fsl_i2c_probe gets called with no changes to the driver.

The kernel version is 2.6.22-rc7

The relevant part of my device tree is: 

        i2c at 3d00 {
            device_type = "i2c";
            compatible = "mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c";
            cell-index = <0>;
            reg = <3d00 40>; 
            interrupts = <2 f 0>;
            interrupt-parent = <&mpc5200_pic>;
            fsl5200-clocking;
        };

        i2c at 3d40 {
            device_type = "i2c"; 
            compatible = "mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c";
            cell-index = <1>;
            reg = <3d40 40>;
            interrupts = <2 10 0>;
            interrupt-parent = <&mpc5200_pic>; 
            fsl5200-clocking;
        };

I turned on DEBUG in drivers/base/dd.c and a call to pr_debug in the probe routine
and here are the relevant log messages:

[   27.258245] platform: Matched Device fsl-i2c.0 with Driver fsl-i2c
[   27.258269] platform: Probing driver fsl-i2c with device fsl-i2c.0
[   27.258299] I2C: here in fsl_i2c_probe
[   27.258732] bound device 'fsl-i2c.0' to driver 'fsl-i2c' 
[   27.258756] platform: Bound Device fsl-i2c.0 to Driver fsl-i2c
[   27.258776] platform: Matched Device fsl-i2c.1 with Driver fsl-i2c
[   27.258789] platform: Probing driver fsl-i2c with device fsl-i2c.1
[   27.258821] I2C: here in fsl_i2c_probe
[   27.259269] bound device 'fsl-i2c.1' to driver 'fsl-i2c'
[   27.259293] platform: Bound Device fsl-i2c.1 to Driver fsl-i2c

John


On 7/5/07, John Rigby <jcrigby at gmail.com> wrote: 

	kd,
	
	Ok, obviously It doesn't work the way I thought.  Hopefully someone who does
	understand this will comment.
	
	John 
	
	
	
	On 7/4/07, K?ri Dav??sson <kari.davidsson at marel.is> wrote: 

		John, thank you for your answare.
		
		Enabling CONFIG_FSL_SOC only enabled the execution of the init function (fsl_i2c_init())
		of the fsl-i2c driver (i2c-mpc.c). The .probe function of the driver was never called
		until I converted the driver to the OF model and added the .match_table to the driver structure.
		
		Then I get the .probe function (fsl_i2c_probe()) called and the i2c bus set up.
		
		Similar thing happens for the i2c device PCF8563 i.e., the init functin of the driver (pcf8563_init())
		is called the driver is registered with the kernel, but the .probe (pcf8563_probe()) is never called.
		
		The driver pcf8563 has _NO_ exported structures or functions so I basically have no handle on it 
		that I can utilize in board specific setup.
		
		The way I suspect this is supposed to work is that from the board settup files I would do
		rtc_dev = platform_device_register_simple("pcf8563", -1, NULL, 0); 
		which should later trigger the calling of the pcf8563_probe() function.
		
		This is doing things in the same way as the fsl i2c code, i.e.
		i2c_dev = platform_device_register_simple("i2c", i, r, 2);
		which by the way does not work untill I have converted the fsl_i2c (i2c-mpc.c) driver to the OF structure.
		
		So still the method of gluing together the OF drivers and non OF drivers eludes me.
		
		rg
		kd
		
		P.S. I did check the 2.6.21-RC7-git3 and found that the i2c-mpc.c and the rtc-pcf85763.c are basically the same
		as what I am working with in 2.6.20+
		________________________________
		
		From: John Rigby [mailto: jcrigby at gmail.com]
		Sent: 3. j?l? 2007 16:31
		To: K?ri Dav??sson
		Cc: linuxppc-embedded at ozlabs.org 
		Subject: Re: OF devices and non OF devices
		
		
		One place to find binding between OF devices and non OF devices is in arch/powerpc/sysdev/fsl_soc.c 
		The typical pattern is:
		    if of_find_compatible_node "of-device-name"
		        platform_device_register_simple ""platform-device-name"
		        platform_device_add_data ...
		
		
		
		On 7/3/07, K?ri Dav??sson <kari.davidsson at marel.is> wrote:
		
		        Hi,
		
		        I am attempting to get some non OF devices working for an mpc 5200 board, in particular 
		        PCF8563 RTC.
		
		        This device has an non OF device interface which I believe is correct. After all it should work
		        on non OF platforms.
		
		        I have managed to get the board to run the i2c initialization (and probe) for the fsl-mpc i2c driver by 
		        converting the fsl-mpc i2c driver to OF driver (I found some patch here that I based this work on).
		
		
		fsl-i2c is one of the devices handled by fsl_soc.c so you shouldn't need to change anything to 
		make it work in the latest kernel.  CONFIG_FSL_SOC was only added to lite5200_defconfig recently so
		that may explain why it's not on in your kernel.
		
		
		
		        Since the PCF8563 driver is not OF driver only its initaliziation code is run but the .probe function 
		        of the driver is never run. Basically (as far as I can understand) the .probe is never run because the
		        driver is not an OF driver.
		
		        I could convert the PCF8563 driver to OF driver and make it work for our puposes but I feel this is 
		        1) Wrong
		        2) therefore wasted work.
		
		
		Since the driver must run on non OF platforms then it should not be converted.  You just need to add a platform_device_register somewhere.
		I don't think fsl_soc.c is  the right place since it is not part of an freescale SOC. 
		You could probably put it in a board specific startup routine.
		
		
		
		        What seems to elude me is some glue that glues together the OF part of the driver space to the non OF part
		        of the driver space. 
		
		        Any hints or pointers on where to find this glue?
		
		        Regards,
		        kd
		
		        P.S. Kernel is post 2.6.20.
		
		        --
		        K?ri Dav??sson                   | kari.davidsson at marel.is
		        Hugb?na?arger?                   | www.marel.com
		        Tel: 563-8156 Fax: +354 563 8001 
		        Iceland
		        _______________________________________________ 
		        Linuxppc-embedded mailing list
		        Linuxppc-embedded at ozlabs.org
		         https://ozlabs.org/mailman/listinfo/linuxppc-embedded <https://ozlabs.org/mailman/listinfo/linuxppc-embedded> 
		
		
		
		_______________________________________________
		Linuxppc-embedded mailing list
		Linuxppc-embedded at ozlabs.org
		https://ozlabs.org/mailman/listinfo/linuxppc-embedded
		


	


From tnt at 246tNt.com  Wed Jul 18 21:45:19 2007
From: tnt at 246tNt.com (Sylvain Munaut)
Date: Wed, 18 Jul 2007 13:45:19 +0200
Subject: mpc52xx: Correct calculation of FEC RX errors???
In-Reply-To: <469DFC03.9080201@ziv.es>
References: <469DFC03.9080201@ziv.es>
Message-ID: <469DFD4F.7010009@246tNt.com>


> Hi
>
> We are showing figures of more than 4 billion error frames in our
> ethernet interfaces. We have tested that the problem is in a
> substraction (the number of errors decrements with the number of frames).
>
> So... looking in the fec driver (fec.c) for the calculations we have
> seen that the number of multicast packets is added to the number of
> correct frames in order to get the frame errors...
>
> But the interesting thing is that we have checked that this
> calculation is something that we have added with a patch by Grzegorz
> Bernacki in this list.
>
> So... The funny thing is... Why a patch that solves the problem for
> Grzegorz produces "the same problem" for us?
>
> And... by the way... I have seen IEEE802.3, and when they talk about
> aFramesReceivedOK (which I suppose is the ieee_r_frame_ok in the
> driver), and they do not say a word about not including multicast
> packets in it...
>
> Any comment will be appreciate.
The only comment I have, is that yes, the computation are flawed.
And that's not very high in my priority list.

I don't think the path posted on the list fully fix the issue but I
really don't want to spend hours trying to figure out exactly what
values are reported in all those counters. You're welcome to do so if
you have some free time ...

There are other stuff wrong in this driver (try ifconfig eth0 down, then
send some broad cast traffic on the network .... you'll see some fifo
error popping up ) ...


Sylvain


From ma.alvarez at ziv.es  Wed Jul 18 21:39:47 2007
From: ma.alvarez at ziv.es (Miguel Angel Alvarez)
Date: Wed, 18 Jul 2007 13:39:47 +0200
Subject: mpc52xx: Correct calculation of FEC RX errors???
Message-ID: <469DFC03.9080201@ziv.es>

Hi

We are showing figures of more than 4 billion error frames in our 
ethernet interfaces. We have tested that the problem is in a 
substraction (the number of errors decrements with the number of frames).

So... looking in the fec driver (fec.c) for the calculations we have 
seen that the number of multicast packets is added to the number of 
correct frames in order to get the frame errors...

But the interesting thing is that we have checked that this calculation 
is something that we have added with a patch by Grzegorz Bernacki in 
this list.

So... The funny thing is... Why a patch that solves the problem for 
Grzegorz produces "the same problem" for us?

And... by the way... I have seen IEEE802.3, and when they talk about 
aFramesReceivedOK (which I suppose is the ieee_r_frame_ok in the 
driver), and they do not say a word about not including multicast 
packets in it...

Any comment will be appreciate.

Miguel ?ngel ?lvarez
** 
 
----------------------------------------- PLEASE NOTE -------------------------------------------
This message, along with any attachments, may be confidential or legally privileged. 
It is intended only for the named person(s), who is/are the only authorized recipients.
If this message has reached you in error, kindly destroy it without review and notify the sender immediately.
Thank you for your help.
ZIV uses virus scanning software but excludes any liability for viruses contained in any attachment.
 
------------------------------------ ROGAMOS LEA ESTE TEXTO -------------------------------
Este mensaje y sus anexos pueden contener informaci?n confidencial y/o con derecho legal. 
Est? dirigido ?nicamente a la/s persona/s o entidad/es rese?adas como ?nico destinatario autorizado.
Si este mensaje le hubiera llegado por error, por favor elim?nelo sin revisarlo ni reenviarlo y notif?quelo inmediatamente al remitente. Gracias por su colaboraci?n.  
ZIV utiliza software antivirus, pero no se hace responsable de los virus contenidos en los ficheros anexos.


From jwboyer at linux.vnet.ibm.com  Wed Jul 18 23:41:10 2007
From: jwboyer at linux.vnet.ibm.com (Josh Boyer)
Date: Wed, 18 Jul 2007 08:41:10 -0500
Subject: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports
	access of bad area during boot with DEBUG_SLAB=y
In-Reply-To: <20070718083425.GA29722@gate.ebshome.net>
References: <bug-8778-10286@http.bugzilla.kernel.org/>
	<20070718005253.942f0464.akpm@linux-foundation.org>
	<20070718083425.GA29722@gate.ebshome.net>
Message-ID: <1184766070.3699.2.camel@zod.rchland.ibm.com>

On Wed, 2007-07-18 at 01:34 -0700, Eugene Surovegin wrote:
> On Wed, Jul 18, 2007 at 12:52:53AM -0700, Andrew Morton wrote:
> > On Wed, 18 Jul 2007 00:07:50 -0700 (PDT) bugme-daemon at bugzilla.kernel.org wrote:
> > 
> > > http://bugzilla.kernel.org/show_bug.cgi?id=8778
> > > 
> > >            Summary: Ocotea board: kernel reports access of bad area during
> > >                     boot with DEBUG_SLAB=y
> 
> Slab debugging is probably the culprit here. I had similar problem 
> couple of years ago, not sure something has changed since then, 
> haven't checked.
> 
> When slab debugging was enabled it made memory allocations non L1 
> cache line aligned. This is very bad for DMA on non-coherent cache 
> arches (PPC440 is one of those archs).
> 
> I have a hack for EMAC which tries to "workaround" this problem:
> 	http://kernel.ebshome.net/emac_slab_debug.diff
> which might help.

Would you be opposed to including that patch in mainline?  I'd like to
have the bug reporter try it and then get it in if it fixes the issue.

josh



From ebs at ebshome.net  Thu Jul 19 01:59:40 2007
From: ebs at ebshome.net (Eugene Surovegin)
Date: Wed, 18 Jul 2007 08:59:40 -0700
Subject: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access
	of bad area during boot with DEBUG_SLAB=y
In-Reply-To: <1184766070.3699.2.camel@zod.rchland.ibm.com>
References: <bug-8778-10286@http.bugzilla.kernel.org/>
	<20070718005253.942f0464.akpm@linux-foundation.org>
	<20070718083425.GA29722@gate.ebshome.net>
	<1184766070.3699.2.camel@zod.rchland.ibm.com>
Message-ID: <20070718155940.GB29722@gate.ebshome.net>

On Wed, Jul 18, 2007 at 08:41:10AM -0500, Josh Boyer wrote:
> On Wed, 2007-07-18 at 01:34 -0700, Eugene Surovegin wrote:
> > On Wed, Jul 18, 2007 at 12:52:53AM -0700, Andrew Morton wrote:
> > > On Wed, 18 Jul 2007 00:07:50 -0700 (PDT) bugme-daemon at bugzilla.kernel.org wrote:
> > > 
> > > > http://bugzilla.kernel.org/show_bug.cgi?id=8778
> > > > 
> > > >            Summary: Ocotea board: kernel reports access of bad area during
> > > >                     boot with DEBUG_SLAB=y
> > 
> > Slab debugging is probably the culprit here. I had similar problem 
> > couple of years ago, not sure something has changed since then, 
> > haven't checked.
> > 
> > When slab debugging was enabled it made memory allocations non L1 
> > cache line aligned. This is very bad for DMA on non-coherent cache 
> > arches (PPC440 is one of those archs).
> > 
> > I have a hack for EMAC which tries to "workaround" this problem:
> > 	http://kernel.ebshome.net/emac_slab_debug.diff
> > which might help.
> 
> Would you be opposed to including that patch in mainline?

Yes. I don't think it's the right way to fix this issue. IMO, the 
right one is to fix slab allocator. You cannot change all drivers to 
do this kind of cache flushing, and yes, I saw the same problem with 
PCI based NIC I tried on Ocotea at the time.

-- 
Eugene


From jwboyer at linux.vnet.ibm.com  Thu Jul 19 02:28:47 2007
From: jwboyer at linux.vnet.ibm.com (Josh Boyer)
Date: Wed, 18 Jul 2007 11:28:47 -0500
Subject: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports
	access of bad area during boot with DEBUG_SLAB=y
In-Reply-To: <20070718155940.GB29722@gate.ebshome.net>
References: <bug-8778-10286@http.bugzilla.kernel.org/>
	<20070718005253.942f0464.akpm@linux-foundation.org>
	<20070718083425.GA29722@gate.ebshome.net>
	<1184766070.3699.2.camel@zod.rchland.ibm.com>
	<20070718155940.GB29722@gate.ebshome.net>
Message-ID: <1184776127.16299.22.camel@weaponx.rchland.ibm.com>

On Wed, 2007-07-18 at 08:59 -0700, Eugene Surovegin wrote:
> On Wed, Jul 18, 2007 at 08:41:10AM -0500, Josh Boyer wrote:
> > On Wed, 2007-07-18 at 01:34 -0700, Eugene Surovegin wrote:
> > > On Wed, Jul 18, 2007 at 12:52:53AM -0700, Andrew Morton wrote:
> > > > On Wed, 18 Jul 2007 00:07:50 -0700 (PDT) bugme-daemon at bugzilla.kernel.org wrote:
> > > > 
> > > > > http://bugzilla.kernel.org/show_bug.cgi?id=8778
> > > > > 
> > > > >            Summary: Ocotea board: kernel reports access of bad area during
> > > > >                     boot with DEBUG_SLAB=y
> > > 
> > > Slab debugging is probably the culprit here. I had similar problem 
> > > couple of years ago, not sure something has changed since then, 
> > > haven't checked.
> > > 
> > > When slab debugging was enabled it made memory allocations non L1 
> > > cache line aligned. This is very bad for DMA on non-coherent cache 
> > > arches (PPC440 is one of those archs).
> > > 
> > > I have a hack for EMAC which tries to "workaround" this problem:
> > > 	http://kernel.ebshome.net/emac_slab_debug.diff
> > > which might help.
> > 
> > Would you be opposed to including that patch in mainline?
> 
> Yes. I don't think it's the right way to fix this issue. IMO, the 
> right one is to fix slab allocator. You cannot change all drivers to 
> do this kind of cache flushing, and yes, I saw the same problem with 
> PCI based NIC I tried on Ocotea at the time.

Hm... good point.  I'd still like to see if your patch works around the
reporter's problem.

josh



From akpm at linux-foundation.org  Thu Jul 19 02:55:37 2007
From: akpm at linux-foundation.org (Andrew Morton)
Date: Wed, 18 Jul 2007 09:55:37 -0700
Subject: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access
	of bad area during boot with DEBUG_SLAB=y
In-Reply-To: <20070718155940.GB29722@gate.ebshome.net>
References: <bug-8778-10286@http.bugzilla.kernel.org/>
	<20070718005253.942f0464.akpm@linux-foundation.org>
	<20070718083425.GA29722@gate.ebshome.net>
	<1184766070.3699.2.camel@zod.rchland.ibm.com>
	<20070718155940.GB29722@gate.ebshome.net>
Message-ID: <20070718095537.d344dc0a.akpm@linux-foundation.org>

On Wed, 18 Jul 2007 08:59:40 -0700 Eugene Surovegin <ebs at ebshome.net> wrote:

> On Wed, Jul 18, 2007 at 08:41:10AM -0500, Josh Boyer wrote:
> > On Wed, 2007-07-18 at 01:34 -0700, Eugene Surovegin wrote:
> > > On Wed, Jul 18, 2007 at 12:52:53AM -0700, Andrew Morton wrote:
> > > > On Wed, 18 Jul 2007 00:07:50 -0700 (PDT) bugme-daemon at bugzilla.kernel.org wrote:
> > > > 
> > > > > http://bugzilla.kernel.org/show_bug.cgi?id=8778
> > > > > 
> > > > >            Summary: Ocotea board: kernel reports access of bad area during
> > > > >                     boot with DEBUG_SLAB=y
> > > 
> > > Slab debugging is probably the culprit here. I had similar problem 
> > > couple of years ago, not sure something has changed since then, 
> > > haven't checked.
> > > 
> > > When slab debugging was enabled it made memory allocations non L1 
> > > cache line aligned. This is very bad for DMA on non-coherent cache 
> > > arches (PPC440 is one of those archs).
> > > 
> > > I have a hack for EMAC which tries to "workaround" this problem:
> > > 	http://kernel.ebshome.net/emac_slab_debug.diff
> > > which might help.
> > 
> > Would you be opposed to including that patch in mainline?
> 
> Yes. I don't think it's the right way to fix this issue. IMO, the 
> right one is to fix slab allocator. You cannot change all drivers to 
> do this kind of cache flushing, and yes, I saw the same problem with 
> PCI based NIC I tried on Ocotea at the time.
> 

hm.  It should be the case that providing SLAB_HWCACHE_ALIGN at
kmem_cache_create() time will override slab-debugging's offsetting
of the returned addresses.

Or is the problem occurring with memory which is returned from kmalloc(),
rather than from kmem_cache_alloc()?

A complete description of the problem would help here, please.


From ebs at ebshome.net  Thu Jul 19 03:04:33 2007
From: ebs at ebshome.net (Eugene Surovegin)
Date: Wed, 18 Jul 2007 10:04:33 -0700
Subject: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access
	of bad area during boot with DEBUG_SLAB=y
In-Reply-To: <20070718095537.d344dc0a.akpm@linux-foundation.org>
References: <bug-8778-10286@http.bugzilla.kernel.org/>
	<20070718005253.942f0464.akpm@linux-foundation.org>
	<20070718083425.GA29722@gate.ebshome.net>
	<1184766070.3699.2.camel@zod.rchland.ibm.com>
	<20070718155940.GB29722@gate.ebshome.net>
	<20070718095537.d344dc0a.akpm@linux-foundation.org>
Message-ID: <20070718170433.GC29722@gate.ebshome.net>

On Wed, Jul 18, 2007 at 09:55:37AM -0700, Andrew Morton wrote:
> On Wed, 18 Jul 2007 08:59:40 -0700 Eugene Surovegin <ebs at ebshome.net> wrote:
> 
> > On Wed, Jul 18, 2007 at 08:41:10AM -0500, Josh Boyer wrote:
> > > On Wed, 2007-07-18 at 01:34 -0700, Eugene Surovegin wrote:
> > > > On Wed, Jul 18, 2007 at 12:52:53AM -0700, Andrew Morton wrote:
> > > > > On Wed, 18 Jul 2007 00:07:50 -0700 (PDT) bugme-daemon at bugzilla.kernel.org wrote:
> > > > > 
> > > > > > http://bugzilla.kernel.org/show_bug.cgi?id=8778
> > > > > > 
> > > > > >            Summary: Ocotea board: kernel reports access of bad area during
> > > > > >                     boot with DEBUG_SLAB=y
> > > > 
> > > > Slab debugging is probably the culprit here. I had similar problem 
> > > > couple of years ago, not sure something has changed since then, 
> > > > haven't checked.
> > > > 
> > > > When slab debugging was enabled it made memory allocations non L1 
> > > > cache line aligned. This is very bad for DMA on non-coherent cache 
> > > > arches (PPC440 is one of those archs).
> > > > 
> > > > I have a hack for EMAC which tries to "workaround" this problem:
> > > > 	http://kernel.ebshome.net/emac_slab_debug.diff
> > > > which might help.
> > > 
> > > Would you be opposed to including that patch in mainline?
> > 
> > Yes. I don't think it's the right way to fix this issue. IMO, the 
> > right one is to fix slab allocator. You cannot change all drivers to 
> > do this kind of cache flushing, and yes, I saw the same problem with 
> > PCI based NIC I tried on Ocotea at the time.
> > 
> 
> hm.  It should be the case that providing SLAB_HWCACHE_ALIGN at
> kmem_cache_create() time will override slab-debugging's offsetting
> of the returned addresses.
> 
> Or is the problem occurring with memory which is returned from kmalloc(),
> rather than from kmem_cache_alloc()?

It's kmalloc, at least this is how I think skbs are allocated.

Andrew, I don't have access to PPC hw right now (doing MIPS 
development these days), so I cannot quickly check that my theory is 
still correct for the latest kernel. I'd wait for the reporter to try 
my hack and then we can decide what to do. IIRC there was some 
provision in slab allocator to enforce alignment, when I was debugging 
this problem more then a year ago, that option didn't work.

BTW, I think slob allocator had the same issue with alignment as slab 
with enabled debugging (at least at the time I looked at it).

-- 
Eugene



From bgat at billgatliff.com  Thu Jul 19 03:59:42 2007
From: bgat at billgatliff.com (Bill Gatliff)
Date: Wed, 18 Jul 2007 12:59:42 -0500
Subject: Gdbserver syscall clobber
In-Reply-To: <20070716155348.GA5281@caradoc.them.org>
References: <469B922D.3050701@billgatliff.com>
	<20070716155348.GA5281@caradoc.them.org>
Message-ID: <469E550E.5080905@billgatliff.com>

Daniel Jacobowitz wrote:
> On Mon, Jul 16, 2007 at 10:43:41AM -0500, Bill Gatliff wrote:
>   
>> recv(4, 0x7ffffd60, 1, 0)               = ? ERESTARTSYS (To be restarted)
>> --- SIGIO (I/O possible) @ 0 (0) ---
>> syscall_4294966784(0xa, 0x7ffffd34, 0x1, 0, 0x1008a3c7, 0x1008b5a3, 0x1008b5a4, 
>>     
>
> That's -512, a.k.a. the errno value used by syscall restarting.  I'd
> say your glibc does not obey the restartable syscall convention used
> by your kernel, and when it tries to restart the syscall the errno
> value is not being replaced by the syscall number.  Check the assembly
> for recv.
>
>   

Very good catch!  Thanks soooo much.  Here's the code, from my libc.a:

00000000 <__libc_recv>:
    0:   94 21 ff d0     stwu    r1,-48(r1)
    4:   90 61 00 14     stw     r3,20(r1)
    8:   90 81 00 18     stw     r4,24(r1)
    c:   90 a1 00 1c     stw     r5,28(r1)
   10:   90 c1 00 20     stw     r6,32(r1)
   14:   81 42 00 0c     lwz     r10,12(r2)
   18:   2c 0a 00 00     cmpwi   r10,0
   1c:   40 82 00 20     bne-    3c <__libc_recv+0x3c>
   20:   38 60 00 0a     li      r3,10
   24:   38 81 00 14     addi    r4,r1,20
   28:   38 00 00 66     li      r0,102
   2c:   44 00 00 02     sc
   30:   38 21 00 30     addi    r1,r1,48
   34:   4c a3 00 20     bnslr+
   38:   48 00 00 00     b       38 <__libc_recv+0x38>

Again, this is 603e on linux-2.4.16 glibc-2.2.5 gcc-2.95.3.  (Odd, I
can't seem to find this function in a statically-linked gdbserver, nor
any reference to it in the gdbserver-6.5 source code).

On the kernel side:

_GLOBAL(DoSyscall)
...
         blrl                    /* Call handler */
         .globl  ret_from_syscall_1
ret_from_syscall_1:
20:     stw     r3,RESULT(r1)   /* Save result */
         li      r10,-_LAST_ERRNO
         cmpl    0,r3,r10
         blt     30f
         neg     r3,r3
         cmpi    0,r3,ERESTARTNOHAND
         bne     22f
         li      r3,EINTR
22:     lwz     r10,_CCR(r1)    /* Set SO bit in CR */
         oris    r10,r10,0x1000
         stw     r10,_CCR(r1)
30:     stw     r3,GPR3(r1)     /* Update return value */
         b       ret_from_except
...
ret_from_except:
...
         lwz     r3,_CCR(r1)
...
         mtcrf   0xFF,r3
...
         RFI


Now, I'm a little rusty on PPC asm (I've been doing a lot of ARM
lately), but it looks to me like the kernel is setting bit 0 in CR0
(oris r10, r10, 0x1000) a.k.a LT, but the user side is looking at CR0
(bnslr+) bit 3 a.k.a. SO.  Or maybe the other way around, I'm not sure
after reading Sections 1.2 and 2.1 of the Programming Environments manual.

Or am I misinterpreting something?  I must be, this is well-trodden code
I'm thinking...

The readchar() in gdbserver's remote-utils.c just calls read() on the
file descriptor for the socket.  Still trying to track that code down...



b.g.

-- 
Bill Gatliff
bgat at billgatliff.com




From bart.vanassche at gmail.com  Thu Jul 19 04:43:46 2007
From: bart.vanassche at gmail.com (Bart Van Assche)
Date: Wed, 18 Jul 2007 20:43:46 +0200
Subject: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access
	of bad area during boot with DEBUG_SLAB=y
In-Reply-To: <20070718170433.GC29722@gate.ebshome.net>
References: <bug-8778-10286@http.bugzilla.kernel.org/>
	<20070718005253.942f0464.akpm@linux-foundation.org>
	<20070718083425.GA29722@gate.ebshome.net>
	<1184766070.3699.2.camel@zod.rchland.ibm.com>
	<20070718155940.GB29722@gate.ebshome.net>
	<20070718095537.d344dc0a.akpm@linux-foundation.org>
	<20070718170433.GC29722@gate.ebshome.net>
Message-ID: <e2e108260707181143x98760a9gf1734eaaf897cee8@mail.gmail.com>

On 7/18/07, Eugene Surovegin <ebs at ebshome.net> wrote:
>
>
> It's kmalloc, at least this is how I think skbs are allocated.
>
> Andrew, I don't have access to PPC hw right now (doing MIPS
> development these days), so I cannot quickly check that my theory is
> still correct for the latest kernel. I'd wait for the reporter to try
> my hack and then we can decide what to do. IIRC there was some
> provision in slab allocator to enforce alignment, when I was debugging
> this problem more then a year ago, that option didn't work.
>
> BTW, I think slob allocator had the same issue with alignment as slab
> with enabled debugging (at least at the time I looked at it).



Hello Eugene,

In case you didn't notice yet, I have added the following comment to the
kernel bugzilla item:


------- *Comment #5
<http://bugzilla.kernel.org/show_bug.cgi?id=8778#c5>From Bart
Van Assche <bart.vanassche at gmail.com> 2007-07-18 07:12:49 *
[reply<http://bugzilla.kernel.org/show_bug.cgi?id=8778#add_comment>]
-------

I have downloaded the patch from
http://kernel.ebshome.net/emac_slab_debug.diff, and I have tried it. Hereby I
confirm that this patch solves the reported kernel oops.



-- 
Regards,

Bart Van Assche.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070718/36fdf2cf/attachment.htm 

From drow at false.org  Thu Jul 19 04:31:43 2007
From: drow at false.org (Daniel Jacobowitz)
Date: Wed, 18 Jul 2007 14:31:43 -0400
Subject: Gdbserver syscall clobber
In-Reply-To: <469E550E.5080905@billgatliff.com>
References: <469B922D.3050701@billgatliff.com>
	<20070716155348.GA5281@caradoc.them.org>
	<469E550E.5080905@billgatliff.com>
Message-ID: <20070718183143.GA25324@caradoc.them.org>

On Wed, Jul 18, 2007 at 12:59:42PM -0500, Bill Gatliff wrote:
> Now, I'm a little rusty on PPC asm (I've been doing a lot of ARM
> lately), but it looks to me like the kernel is setting bit 0 in CR0
> (oris r10, r10, 0x1000) a.k.a LT, but the user side is looking at CR0
> (bnslr+) bit 3 a.k.a. SO.  Or maybe the other way around, I'm not sure
> after reading Sections 1.2 and 2.1 of the Programming Environments manual.

It's not checking for restart here - userspace isn't supposed to have to.
It's probably checking for error.  Check for the bit of kernel code
that's supposed to back you up two instructions.

-- 
Daniel Jacobowitz
CodeSourcery


From galak at kernel.crashing.org  Thu Jul 19 04:17:51 2007
From: galak at kernel.crashing.org (Kumar Gala)
Date: Wed, 18 Jul 2007 13:17:51 -0500
Subject: Machine check exception. 2.6.20 powerpc tree. 
In-Reply-To: <35786B99AB3FDC45A8215724617919730136DC04@gbrwgceumf01.eu.xerox.net>
References: <35786B99AB3FDC45A8215724617919730136DC04@gbrwgceumf01.eu.xerox.net>
Message-ID: <59116081-3E03-4C3C-AA1A-E1E092595340@kernel.crashing.org>


On Jul 18, 2007, at 4:27 AM, Ramirez-Ortiz, Jorge wrote:

> Hi Kumar
>
> The address we are trying to access corresponds to a mapped device in
> the PCI space
> Attached some additional debugging information (we have  
> instrumented the
> kernel)
>
> Thanks
> jorge
>
>
> INFO [_probe]: Found Device [irq=58]
> INFO [_open]: device opened with irq 58
> INFO [_read]: waiting for interrupt
> INFO [_intr]: ISR 58
>
> PCI1: Error! ERR_DETECT=00000040, ATTR=00516001, addr=80020034,
> data=00050000

So you are getting a master abort from the target.  I think you need  
to look at your PCI device and see what's going on there.

> machine_check_exception: task my_process, MCSR=0x10008, NIP=0x10153530
> Machine check in user mode.
> Caused by (from MCSR=10008): Guarded Load or Cache-Inhibited stwcx.
> Bus - Read Data Bus Error
>
> Call Trace:
> [C7355EF0] [C0006E64] show_stack+0x48/0x19c (unreliable)
> [C7355F20] [C000C04C] machine_check_exception+0x294/0x484
> [C7355F40] [C000E48C] ret_from_mcheck_exc+0x0/0xe0
>
> cat /proc/cpuinfo
> processor       : 0
> cpu             : e500v2
> clock           : 799.500000MHz
> revision        : 2.0 (pvr 8021 0020)
> bogomips        : 99.84
> timebase        : 49968750
> platform        : MPC85xx CDS
> Vendor          : Freescale Semiconductor
> Machine         : MPC85xx CDS (0xff)
> PVR             : 0x80210020
> SVR             : 0x80390220
> PLL setting     : 0x4
> Memory          : 256 MB
> LAW 1           : 00000000, 20000000 -> DDR SDRAM
> LAW 2           : 80000000, 10000000 -> PCI1
> LAW 3           : 90000000, 10000000 -> PCI2
> LAW 4           : a0000000, 10000000 -> PCI Express
> LAW 5           : e1000000, 01000000 -> PCI1
> LAW 6           : e2000000, 01000000 -> PCI2
> LAW 7           : e3000000, 01000000 -> PCI Express
> LAW 8           : f0000000, 10000000 -> Local bus
> DDR 0           : 00000000, 20000000 -> 2/14/10 addr bits
> PCI1 Out_1      : 80000000, 10000000 -> Mem: 80000000
> PCI1 Out_2      : e1000000, 01000000 -> I/O: 00000000
> PCI2 Out_1      : 90000000, 10000000 -> Mem: 90000000
> PCI2 Out_2      : e2000000, 01000000 -> I/O: 00000000
> PCI3 Out_1      : a0000000, 10000000 -> Mem: a0000000
> PCI3 Out_2      : e3000000, 01000000 -> I/O: 00000000
> PCI1 In_1       : 00000000, 20000000 (Internal,R:snoop,W:snoop) <-
> 00000000 PF
> PCI2 In_1       : 00000000, 20000000 (Internal,R:snoop,W:snoop) <-
> 00000000 PF
> PCI3 In_1       : 00000000, 20000000 (Internal,R:snoop,W:snoop) <-
> 00000000 PF
>
>
> ______________________________
>
>
>
> -----Original Message-----
> From: Kumar Gala [mailto:galak at kernel.crashing.org]
> Sent: 17 July 2007 17:29
> To: Ramirez-Ortiz, Jorge
> Cc: linuxppc-embedded at ozlabs.org
> Subject: Re: Machine check exception. 2.6.20 powerpc tree.
>
>
> On Jul 17, 2007, at 9:21 AM, Ramirez-Ortiz, Jorge wrote:
>
>> Running our multithreaded application on ppc8548 (E500 core)
>> generates a machine check exception when trying to access some
>> ASIC's registers mapped on the PCI space (This application maps a
>> PCI device to access its registers)
>>
>>
>>
>> machine_check_exception: task my_process, MCSR=0x10008,  
>> NIP=0x10153530
>>
>> Machine check in user mode.
>>
>> Caused by (from MCSR=10008): Guarded Load or Cache-Inhibited stwcx.
>>
>> Bus - Read Data Bus Error
>>
>>
>>
>> Here is the assembly dump of the region of code containing the
>> offending instruction in user-space, with SRR0 pointing us at
>> 0x10153530 when the exception is raised:
>>
>>
>>
>> 0x10153528 <_ZN2vk7in_le32EPVKj+16>:    lwz     r0,8(r31)
>>
>> 0x1015352c <_ZN2vk7in_le32EPVKj+20>:    lwz     r9,8(r31)
>>
>> 0x10153530 <_ZN2vk7in_le32EPVKj+24>:    lwbrx   r0,0,r0
>>
>> 0x10153534 <_ZN2vk7in_le32EPVKj+28>:    twi     0,r0,0
>>
>> 0x10153538 <_ZN2vk7in_le32EPVKj+32>:    isync
>
> Can you get the code to dump the value of r0.  I'm wondering if
> you're really getting a read data bus error due to the fact that r0
> is pointing to a PCI address that doesn't have a device that will
> respond.
>
> - k
>
>



From bgat at billgatliff.com  Thu Jul 19 03:42:07 2007
From: bgat at billgatliff.com (Bill Gatliff)
Date: Wed, 18 Jul 2007 12:42:07 -0500
Subject: Gdbserver syscall clobber
In-Reply-To: <20070716155348.GA5281@caradoc.them.org>
References: <469B922D.3050701@billgatliff.com>
	<20070716155348.GA5281@caradoc.them.org>
Message-ID: <469E50EF.8000901@billgatliff.com>

Daniel Jacobowitz wrote:
> On Mon, Jul 16, 2007 at 10:43:41AM -0500, Bill Gatliff wrote:
>   
>> recv(4, 0x7ffffd60, 1, 0)               = ? ERESTARTSYS (To be restarted)
>> --- SIGIO (I/O possible) @ 0 (0) ---
>> syscall_4294966784(0xa, 0x7ffffd34, 0x1, 0, 0x1008a3c7, 0x1008b5a3, 0x1008b5a4, 
>>     
>
> That's -512, a.k.a. the errno value used by syscall restarting.  I'd
> say your glibc does not obey the restartable syscall convention used
> by your kernel, and when it tries to restart the syscall the errno
> value is not being replaced by the syscall number.  Check the assembly
> for recv.
>
>   

Very good catch!  Thanks soooo much.  Here's the code, from my libc.a:

00000000 <__libc_recv>:
   0:   94 21 ff d0     stwu    r1,-48(r1)
   4:   90 61 00 14     stw     r3,20(r1)
   8:   90 81 00 18     stw     r4,24(r1)
   c:   90 a1 00 1c     stw     r5,28(r1)
  10:   90 c1 00 20     stw     r6,32(r1)
  14:   81 42 00 0c     lwz     r10,12(r2)
  18:   2c 0a 00 00     cmpwi   r10,0
  1c:   40 82 00 20     bne-    3c <__libc_recv+0x3c>
  20:   38 60 00 0a     li      r3,10
  24:   38 81 00 14     addi    r4,r1,20
  28:   38 00 00 66     li      r0,102
  2c:   44 00 00 02     sc
  30:   38 21 00 30     addi    r1,r1,48
  34:   4c a3 00 20     bnslr+
  38:   48 00 00 00     b       38 <__libc_recv+0x38>

Again, this is 603e on linux-2.4.16 glibc-2.2.5 gcc-2.95.3.  (Odd, I 
can't seem to find this function in a statically-linked gdbserver, nor 
any reference to it in the gdbserver-6.5 source code).

On the kernel side:

_GLOBAL(DoSyscall)
...
        blrl                    /* Call handler */
        .globl  ret_from_syscall_1
ret_from_syscall_1:
20:     stw     r3,RESULT(r1)   /* Save result */
        li      r10,-_LAST_ERRNO
        cmpl    0,r3,r10
        blt     30f
        neg     r3,r3
        cmpi    0,r3,ERESTARTNOHAND
        bne     22f
        li      r3,EINTR
22:     lwz     r10,_CCR(r1)    /* Set SO bit in CR */
        oris    r10,r10,0x1000
        stw     r10,_CCR(r1)
30:     stw     r3,GPR3(r1)     /* Update return value */
        b       ret_from_except
...
ret_from_except:
...
        lwz     r3,_CCR(r1)
...
        mtcrf   0xFF,r3
...
        RFI


Now, I'm a little rusty on PPC asm (I've been doing a lot of ARM 
lately), but it looks to me like the kernel is setting bit 0 in CR0 
(oris r10, r10, 0x1000) a.k.a LT, but the user side is looking at CR0 
(bnslr+) bit 3 a.k.a. SO.  Or maybe the other way around, I'm not sure 
after reading Sections 1.2 and 2.1 of the Programming Environments manual.

Or am I misinterpreting something?  I must be, this is well-trodden code 
I'm thinking...

The readchar() in gdbserver's remote-utils.c just calls read() on the 
file descriptor for the socket.  Still trying to track that code down...



b.g.

-- 
Bill Gatliff
bgat at billgatliff.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070718/03327027/attachment.htm 

From mls.JOFT at gmx.de  Thu Jul 19 06:01:08 2007
From: mls.JOFT at gmx.de (Joachim =?ISO-8859-1?Q?F=F6rster?=)
Date: Wed, 18 Jul 2007 22:01:08 +0200
Subject: can anyone help me to test my ac97 driver
In-Reply-To: <165516780.1952051184304174471.JavaMail.coremail@bj163app130.163.com>
References: <165516780.1952051184304174471.JavaMail.coremail@bj163app130.163.com>
Message-ID: <1184788868.18032.22.camel@localhost>

Hi silicom,

On Fri, 2007-07-13 at 13:22 +0800, silicom wrote:
> I have a simple oss ac97 playback driver for xilinx ml403 and
> linux2.6.17 kernel,but when I test it with a *.wav file with sample
> rate 44.1k, there is much noisy, and I want to know whether there's
> problem with my ml403 board or ac97 driver,could anyone be kind to
> help me test it on your board or point out my problem?

Today I took some time and tried to compile your driver, but one of the
first things I saw was that there is a file missing: "xac97_l.h". I
think, it contains your "low level" functions. If you post the file, and
I have some time, I'll test your driver and what it does on the board,
which I have available.
Furthermore your driver depends on xbasic_types.c/h, xio.c/h, which some
people might not have, too ... especially xio.c/h (in my
experience ;-) ) ...

In my last mail (last week) I announced my driver for the AC97
Controller of Xilinx and said that I'm going to release/post it. Since
then, I worked on it once more and now it seems to be pretty stable and
usable (playback support). I added capture support, too.
[Capturing basically works, but there is a problem with higher rates and
ALSA not reading from the intermediate buffer anymore ... not yet
investigated.]

My driver will be published on a website soon. I'll post the link as
soon as possible. Meanwhile, if you or anyone want to try it, just mail
me (JOFT at gmx.de).

 Joachim


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070718/b2ad3a3a/attachment.pgp 

From bhupi.saharan at gmail.com  Thu Jul 19 07:14:00 2007
From: bhupi.saharan at gmail.com (Bhupender Saharan)
Date: Wed, 18 Jul 2007 14:14:00 -0700
Subject: Memory Corruption in Linux kernel MPC8347 revision 3
In-Reply-To: <1184683343.3337.57.camel@localhost.localdomain>
References: <AcfIgK+rTnCvhttDQ1uQT0I4x0J72Q==>
	<1184683343.3337.57.camel@localhost.localdomain>
Message-ID: <720399a30707181414ube73186n3902f818044bb66a@mail.gmail.com>

Hi Boris,

When you are running the memory test make sure Data cahe and Instruction
caches are enabled.

Also check your BAT setting, there also Cache enable BIT shall be set.

As the burst transcation will happen only when cache is enabled.

How abt ECC...?

Bhupi



On 7/17/07, Boris Shteinbock <borish at batm.co.il> wrote:
>
>          Hi Everyone.
> I am working on the Linux port for MPC8347 revision 3 custom build board
> with DDR2 memory.
>
> I've successfully ported U-boot (latest git) and the kernel itself,
> however during kernel boot I am encountering serious memory corruption
> errors. The log for one of the examples is at the bottom of this
> message.
>
> Basically, the corruption is always happening somewhere at memory
> management intensive tasks such as networking, JFFS2 mounting etc.
>
> As far as I can see, it is not related to some specific driver, because
> even it happens even at kernel configured at absolute minimum, ( console
> serial driver only and even without it)
> The place of the corruption depends on kernel configuration.
>
> The DDR2 memory controller is configured correctly as far as I can tell,
> since :
> 1. DDR2 controller register values are taken from VxWorks bootrom
> that works on this board without any problems.
> 2. u-boot mtest passes successfully
> 3. u-boot alternative mtest passes successfully
> 4. My own custom mem tests in u-boot pass successfully
> 5. If I manage two boot the board into shell prompt (with absolute
> minimum configuration) memtester application is also successful.
>
> The minimum configuration that is one I am able to boot into shell is a
> kernel configured with serial console and small busybox JFFS2 file
> system in the flash. In this configuration, the boot fails the first
> time JFFS2 root FS is mounted. However it does boot after reset.
>
> I've tried different kernels with the same results  starting from, I
> think, 2.6.16  up to 2.6.22
> I tried the kernel that is provided by Freescale for 834x reference
> boards. ( with my board support of course)
>
> I tried booting both OF flat trees (powerpc) and bd_t based builds (ppc)
>
> I've also tried all memory management options :
> SLAB, SLOB and SLUB (in the latest kernel). They all failed at some
> point of time, so the assumption is that the problem is not in the
> memory management facilities.
>
> The board manufacturer swears that DDR2 memory controller values are
> correct and should work perfectly.
>
> So now I almost out of options and I am seeking your help.
> Any type of input on this issue would be greatly appreciated.
>
> Thanks,
> Boris
>
> PS. Note that an below example represents failure during DHCP
> autoconfiguration. However the similar error happens even when
> networking is disabled completely. just in a different place.
>
> => bootm
> ## Booting image at 00400000 ...
>    Image Name:   Linux-.6.21.5
>    Created:      2007-07-10  14:20:19 UTC
>    Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>    Data Size:    898361 Bytes = 877.3 kB
>    Load Address: 00000000
>    Entry Point:  00000000
>    Verifying Checksum ... OK
>    Uncompressing Kernel Image ... OK
> ## Current stack ends at 0x07FA3CF8 => set upper limit to 0x00800000
> ## cmdline at 0x007FFF00 ... 0x007FFF41
> bd address  = 0x07FA3FBC
> memstart    = 0x00000000
> memsize     = 0x08000000
> flashstart  = 0xFE000000
> flashsize   = 0x02000000
> flashoffset = 0x00033000
> sramstart   = 0x00000000
> sramsize    = 0x00000000
> bootflags   = 0x00000001
> intfreq     =    528 MHz
> busfreq     =    264 MHz
> ethaddr     = 00:04:9F:EF:23:35
> eth1addr    = 00:E0:0C:00:7E:25
> IP addr     = 10.2.222.20
> baudrate    = 115200 bps
> No initrd
> ## Transferring control to Linux (at address 00000000) ...
> !!!! of_flat_tree = 00000000
> Booting without OF Flat tree
> Linux version .6.21.5 (me at localhost) (gcc version
> 4.0.0 (DENX ELDK 4.1 4.0.0)) #24 Tue Jul 10 17:20:09 IDT 2007
> Zone PFN ranges:
>   DMA             0 ->    32768
>   Normal      32768 ->    32768
> early_node_map[1] active PFN ranges
>     0:        0 ->    32768
> Built 1 zonelists.  Total pages: 32512
> Kernel command line: console=ttyS0,115200 root=/dev/mtdblock1
> rootfstype=jffs2 ip=dhcp
> IPIC (128 IRQ sources, 8 External IRQs) at fe000700
> PID hash table entries: 512 (order: 9, 2048 bytes)
> Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
> Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
> Memory: 127744k available (1584k kernel code, 444k data, 84k init, 0k
> highmem)
> Mount-cache hash table entries: 512
> NET: Registered protocol family 16
> Setup MTD partitions
> Generic PHY: Registered new driver
> NET: Registered protocol family 2
> IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
> TCP established hash table entries: 4096 (order: 3, 32768 bytes)
> TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
> TCP: Hash tables configured (established 4096 bind 4096)
> TCP reno registered
> JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc.
> io scheduler noop registered
> io scheduler anticipatory registered (default)
> io scheduler deadline registered
> io scheduler cfq registered
> Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing
> disabled
> serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 9) is a 16550A
> serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 10) is a 16550A
> Gianfar MII Bus: probed
> eth0: Gianfar Ethernet Controller Version 1.2, 00:04:9f:ef:23:35
> eth0: Running with NAPI disabled
> eth0: 64/64 RX/TX BD ring size
> Broadcom BCM5241: Registered new driver
> physmap platform flash device: 02000000 at fe000000
> physmap-flash.0: Found 1 x16 devices at 0x0 in 8-bit bank
>  Amd/Fujitsu Extended Query Table at 0x0040
> physmap-flash.0: CFI does not contain boot bank location. Assuming top.
> number of CFI chips: 1
> cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
> cmdlinepart partition parsing not available
> RedBoot partition parsing not available
> Using physmap partition information
> Creating 2 MTD partitions on "physmap-flash.0":
> 0x00000000-0x00100000 : "uboot"
> 0x00100000-0x02000000 : "rootfs"
> IPv4 over IPv4 tunneling driver
> GRE over IPv4 tunneling driver
> TCP cubic registered
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> !!!! Gianfar init_phy. phy_id = 0:01
> !!!! phy_attach. phy_id = 0:01
> !!!! phy_attach device found. phy_id = 0:01
> Sending DHCP requests .<3>slab: Internal list corruption detected in
> cache 'files_cache'(21), slabp c0344000(16). Hexdump:
>
> 000: 00 10 01 00 00 20 02 00 00 00 00 70 c0 34 40 70
> 010: 00 00 00 10 00 00 ff 10 00 00 00 00 ff ff ff fe
> 020: ff ff ff fe ff ff ff fe ff ff ff fe ff ff ff fe
> 030: ff ff ff fe ff ff ff fe ff ff ff fe ff ff ff fe
> 040: ff ff ff fe ff ff ff fe ff ff ff fe ff ff ff fe
> 050: ff ff ff fe ff ff ff fe ff ff ff fd 00 00 00 11
> 060: 00 00 00 12 00 00 00 13 00 00 00 14 ff ff ff ff
> ------------[ cut here ]------------
> kernel BUG at mm/slab.c:2936!
> Oops: Exception in kernel mode, sig: 5 [#1]
> NIP: C0050F80 LR: C0050F80 CTR: 00000000
> REGS: c034fe00 TRAP: 0700   Not tainted  (.6.21.5)
> MSR: 00021032 <ME,IR,DR>  CR: 24004002  XER: 00000000
> TASK = c032a3c0[3] 'events/0' THREAD: c034e000
> GPR00: C0050F80 C034FEB0 C032A3C0 00000001 00000DF5 FFFFFFFF C00F5B54
> 00000010
> GPR08: C01D0000 C01E0000 00000DF5 00000DF5 00000000 00F1C5DB 07FFD000
> FFFFFFFF
> GPR16: 00000001 00000000 00000000 00800000 00000000 007FFF00 00000000
> C033DAA0
> GPR24: C0339C90 00000007 00000000 C01B0000 C01B0000 C0344000 C033DAA0
> 00000070
> NIP [C0050F80] check_slabp+0xe4/0x11c
> LR [C0050F80] check_slabp+0xe4/0x11c
> Call Trace:
> [C034FEB0] [C0050F80] check_slabp+0xe4/0x11c (unreliable)
> [C034FED0] [C0051450] free_block+0x88/0x138
> [C034FF00] [C0052188] drain_array+0xa0/0xe0
> [C034FF20] [C0052228] cache_reap+0x60/0x144
> [C034FF40] [C00257B0] run_workqueue+0xd0/0x170
> [C034FF60] [C0025960] worker_thread+0x110/0x144
> [C034FFC0] [C00298E4] kthread+0x74/0xb0
> [C034FFF0] [C0005F38] kernel_thread+0x44/0x60
> Instruction dump:
> 387b6538 7c9df8ae 4bfc2b49 3bff0001 813e0020 5529103a 3929001c 7f9f4840
> 419cffcc 3c60c01b 3863336c 4bfc2b25 <0fe00000> 48000000 80030020
> 2f800000
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070718/89d59c6f/attachment.htm 

From linux-ppc at eurotel.it  Thu Jul 19 23:51:28 2007
From: linux-ppc at eurotel.it (linux-ppc at eurotel.it)
Date: Thu, 19 Jul 2007 15:51:28 +0200
Subject: ML403 Hard TEMAC, PLB and Linux 2.6
In-Reply-To: <20070208162356.3E8B45C6C3A@mail77-cpk.bigfish.com>
Message-ID: <OF313D78D4.648AA3F0-ONC125731D.004BF98E-C125731D.004C2CC5@eurotel.it>

Hi, we are trying to use both side of an hard temac + 2 plb temac in a 
Virtex4FX12 project.
we succesfull implemented a single temac Montavista tree with eth0.
when trying to use both temac, devices are correctly registered with 
kernel-
eth0 comes up and working ok-
when manually start eth1 (/sbin/ifconfig eth1 up) kernel hang without any 
error or info in the console

# dmesg
Linux version 2.6.10_mvl401-ml40x (massimiliano at linux-yhbz) (gcc version 
3.4.3 (MontaVista 3.4.3-25.0.135.0702900 2007-04-01)) #250 Wed Jul 18 
12:20:43 CEST 2007
Eurotel motherboard init
Port by MontaVista Software, Inc. (source at mvista.com)
On node 0 totalpages: 7812
  DMA zone: 7812 pages, LIFO batch:1
  Normal zone: 0 pages, LIFO batch:1
  HighMem zone: 0 pages, LIFO batch:1
Built 1 zonelists
Kernel command line: console=ttl0 root=/dev/xsysace2 rw ip=off
Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFF000
PID hash table entries: 128 (order: 7, 2048 bytes)
hr_time_init: arch_to_nsec = 8192000, nsec_to_arch = 1099511627
Console: colour dummy device 80x25
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 28420k available (1864k kernel code, 528k data, 124k init, 0k 
highmem)
Calibrating delay loop... 252.92 BogoMIPS (lpj=126464)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
spawn_desched_task(00000000)
desched cpu_callback 3/00000000
ksoftirqd started up.
desched cpu_callback 2/00000000
desched thread 0 started up.
NET: Registered protocol family 16
Registering platform device 'xilinx_temac.0'. Parent at platform
Registering platform device 'xilinx_temac.1'. Parent at platform
Registering platform device 'xilinx_sysace.0'. Parent at platform
Registering platform device 'xilinx_gpio.0'. Parent at platform
Registering platform device 'xilinx_gpio.1'. Parent at platform
Registering platform device 'oled_fb.0'. Parent at platform
Generic PHY: Registered new driver
oled_fb: 4096 video memory mapped to c2011000
Console: switching to colour frame buffer device 16x8
xgpio #0 at 0x40000000 mapped to 0xC2020000
xgpio #1 at 0x40020000 mapped to 0xC2040000
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
loop: loaded (max 8 devices)
elevator: using anticipatory as default io scheduler
System ACE at 0x41800000 mapped to 0xC2060000, irq=4, 1000944KB
 xsysace: xsysace1 xsysace2
Universal TUN/TAP device driver 1.5 (C)1999-2002 Maxim Krasnyansky
XTemac: using FIFO direct interrupt driven mode.
eth0: Xilinx TEMAC #0 at 0x20000000 mapped to 0xC2080000, irq=0
eth0: XTemac id 1.0f, block id 5, type 8
XTemac: using FIFO direct interrupt driven mode.
eth1: Xilinx TEMAC #1 at 0x20010000 mapped to 0xC20A0000, irq=10
eth1: XTemac id 1.0f, block id 5, type 8
i2c /dev entries driver
i2c-xil_custom: registered with I2C (0)
i2c-xil_custom: registered with I2C (1)
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 2048 bind 4096)
NET: Registered protocol family 1
NET: Registered protocol family 17
EXT3-fs warning: maximal mount count reached, running e2fsck is 
recommended
kjournald starting.  Commit interval 5 seconds
EXT3 FS on xsysace2, internal journal
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem).
Freeing unused kernel memory: 124k init
eth0: XTemac: Options: 0xb8f2
eth0: XTemac: speed set to 100Mb/s
eth0: XTemac: PHY Link carrier lost.

# /sbin/ifconfig eth1 up
# eth1: XTemac: Options: 0xb8f2

Any suggestion?




"Rick Moleres" <Rick.Moleres at xilinx.com> 
Sent by: linuxppc-embedded-bounces+linux-ppc=eurotel.it at ozlabs.org
08/02/2007 17.23

To
"Ming Liu" <eemingliu at hotmail.com>, <mamsadegh at hotmail.com>
cc
linuxppc-embedded at ozlabs.org
Subject
RE: ML403 Hard TEMAC, PLB and Linux 2.6






Hi,

As Ming says the Linux 2.6 TEMAC driver is made available in EDK 8.2.2 as 
part of the BSP and Libraries generation for Linux 2.6.  Note that we made 
a recent fix for better PHY address detection and speed negotiation. I've 
attached the adapter here, and it will be available in EDK 9.1.1 when 
that's released.

Thanks,
Rick

-----Original Message-----
From: linuxppc-embedded-bounces+moleres=xilinx.com at ozlabs.org 
[mailto:linuxppc-embedded-bounces+moleres=xilinx.com at ozlabs.org] On Behalf 
Of Ming Liu
Sent: Thursday, February 08, 2007 2:31 AM
To: mamsadegh at hotmail.com
Cc: linuxppc-embedded at ozlabs.org
Subject: RE: ML403 Hard TEMAC, PLB and Linux 2.6

Hi,
In xapp902, they are using the old cores for Temac. So it will be easier 
to 
generate a project in EDK 8.2. Not only the cores there are new, but also 
it can generate the driver for linux 2.6.

BR
Ming

>From: Mohammad Sadegh Sadri <mamsadegh at hotmail.com>
>To: <christophe.alayrac at cresitt.com>
>CC: linuxppc-embedded at ozlabs.org
>Subject: RE: ML403 Hard TEMAC, PLB and Linux 2.6
>Date: Thu, 8 Feb 2007 07:13:47 +0000
>
>
>Hi
>Thanks for reply
>Well, regarding xapp902, there is a very simple question, Where can I 
find 
it? It seems that Xilinx has deleted all of the links to these files.
>
>
>
>
>
>----------------------------------------
> > Subject: Re: ML403 Hard TEMAC, PLB and Linux 2.6
> > From: christophe.alayrac at cresitt.com
> > To: mamsadegh at hotmail.com
> > CC: linuxppc-embedded at ozlabs.org
> > Date: Thu, 8 Feb 2007 06:51:45 +0100
> >
> > Le mercredi 07 f?vrier 2007 ?22:30 +0000, Mohammad Sadegh Sadri a
> > ?crit :
> > Hi Mohammad,
> >
> > Please find here after some answer
> >
> > > 1- I want to use, ML403, Hard TEMAC and PLB TEMAC cores. Is there 
any 
ready to use design, or any reference design available for this?
> > > I'm using EDK 8.1 and I understood that, when I choose the ML403 
board , EDK does not use hard temac, so , should I add it manually? ( well 

this is funny, but the wizard does not use hard temac , is it true? )
> > > Is there any ready EDK projects for ML403, with TEMAC and PLB TEMAC 
modules already inserted and cofigured? (I don't want to use GSRD ) ( If 
yes would you please put the link here )
> > >
> > You can start from XAPP 902 from Xilinx, this design demonstrate TEMAC
> > use in loopback mode. Some memers from that community have tried from
> > that design as a starting point. I did not nknow if the succeed.
> > I would recommand to get EDK 8.2 SP2 and use the Wizard to build a new
> > design with TEMAC.
> >
> > > 2- Simply, Is there any driver available for linux 2.6 , for PLB 
TEMAC and Hard TEMAC modules? If yes , can you put the link here, so that 
I 
can download it?
> > >
> > For the kernel you can get it from Montavista source code site using 
GIT
> > to download it (linux-xilinx-26). This is 2.6.17.4 version (last 
week!)
> >
> > Then you will need to pacth the Kernel with TEMAC drivers (look for
> > TEMAC PAULUS MVISTA with google, or follow my messages in that mailing
> > list)
> > NOTE: If you use that TEMAC patch do not use SGDMA on your TEMAC, use
> > FIFO.
> >
> > > thanks
> > Regards
> >
> > Chris
> > > _________________________________________________________________
> > > Personalize your Live.com homepage with the news, weather, and 
photos 
you care about.
> > > http://www.live.com/getstarted.aspx?icid=T001MSN30A0701
> > > _______________________________________________
> > > Linuxppc-embedded mailing list
> > > Linuxppc-embedded at ozlabs.org
> > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
>
>_________________________________________________________________
>Live Search: New search found
>http://get.live.com/search/overview
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded at ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded

_________________________________________________________________
???????????????????????????? MSN Messenger:  http://messenger.msn.com/cn 

_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded at ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070719/1f019a50/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: adapter.tar.gz
Type: application/octet-stream
Size: 24141 bytes
Desc: not available
Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070719/1f019a50/attachment.obj 

From Rick.Moleres at xilinx.com  Fri Jul 20 01:00:33 2007
From: Rick.Moleres at xilinx.com (Rick Moleres)
Date: Thu, 19 Jul 2007 09:00:33 -0600
Subject: ML403 Hard TEMAC, PLB and Linux 2.6
In-Reply-To: <OF313D78D4.648AA3F0-ONC125731D.004BF98E-C125731D.004C2CC5@eurotel.it>
Message-ID: <20070719150106.669DC6805D@mail55-fra.bigfish.com>

Hi,

 

The first thing I would try is to make sure eth1 comes up without first bringing up eth0.  In other words, does it come up independently?  If not, there could be something wrong with its configuration in the kernel or perhaps a hardware design issue.  If both interfaces come up independently, but not together, then there??s likely a driver issue as we have not tested dual channel TEMAC with the Linux plb_temac driver.  Perhaps others on the list have.  The areas that I would look at would be:  make sure each interface is getting a unique and correct PHY address; make sure any calls to the shared registers of the two channels are protected with semaphores/spinlocks.  For example, I??m pretty sure the PHY registers are shared, so any PHY accesses should be protected.  I would think other Xilinx driver accesses like Start/Stop/Reset/Get or SetOptions/etc?? should be protected as they may access shared registers.

 

-Rick

 

________________________________

From: Massimiliano.Patriarca at eurotel.it [mailto:Massimiliano.Patriarca at eurotel.it] On Behalf Of linux-ppc at eurotel.it
Sent: Thursday, July 19, 2007 7:51 AM
To: Rick Moleres
Cc: Ming Liu; linuxppc-embedded at ozlabs.org; linuxppc-embedded-bounces+linux-ppc=eurotel.it at ozlabs.org; mamsadegh at hotmail.com
Subject: RE: ML403 Hard TEMAC, PLB and Linux 2.6

 


Hi, we are trying to use both side of an hard temac + 2 plb temac in a Virtex4FX12 project. 
we succesfull implemented a single temac Montavista tree with eth0. 
when trying to use both temac, devices are correctly registered with kernel- 
eth0 comes up and working ok- 
when manually start eth1 (/sbin/ifconfig eth1 up) kernel hang without any error or info in the console 

# dmesg 
Linux version 2.6.10_mvl401-ml40x (massimiliano at linux-yhbz) (gcc version 3.4.3 (MontaVista 3.4.3-25.0.135.0702900 2007-04-01)) #250 Wed Jul 18 12:20:43 CEST 2007 
Eurotel motherboard init 
Port by MontaVista Software, Inc. (source at mvista.com) 
On node 0 totalpages: 7812 
  DMA zone: 7812 pages, LIFO batch:1 
  Normal zone: 0 pages, LIFO batch:1 
  HighMem zone: 0 pages, LIFO batch:1 
Built 1 zonelists 
Kernel command line: console=ttl0 root=/dev/xsysace2 rw ip=off 
Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFF000 
PID hash table entries: 128 (order: 7, 2048 bytes) 
hr_time_init: arch_to_nsec = 8192000, nsec_to_arch = 1099511627 
Console: colour dummy device 80x25 
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes) 
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes) 
Memory: 28420k available (1864k kernel code, 528k data, 124k init, 0k highmem) 
Calibrating delay loop... 252.92 BogoMIPS (lpj=126464) 
Mount-cache hash table entries: 512 (order: 0, 4096 bytes) 
spawn_desched_task(00000000) 
desched cpu_callback 3/00000000 
ksoftirqd started up. 
desched cpu_callback 2/00000000 
desched thread 0 started up. 
NET: Registered protocol family 16 
Registering platform device 'xilinx_temac.0'. Parent at platform 
Registering platform device 'xilinx_temac.1'. Parent at platform 
Registering platform device 'xilinx_sysace.0'. Parent at platform 
Registering platform device 'xilinx_gpio.0'. Parent at platform 
Registering platform device 'xilinx_gpio.1'. Parent at platform 
Registering platform device 'oled_fb.0'. Parent at platform 
Generic PHY: Registered new driver 
oled_fb: 4096 video memory mapped to c2011000 
Console: switching to colour frame buffer device 16x8 
xgpio #0 at 0x40000000 mapped to 0xC2020000 
xgpio #1 at 0x40020000 mapped to 0xC2040000 
io scheduler noop registered 
io scheduler anticipatory registered 
io scheduler deadline registered 
io scheduler cfq registered 
loop: loaded (max 8 devices) 
elevator: using anticipatory as default io scheduler 
System ACE at 0x41800000 mapped to 0xC2060000, irq=4, 1000944KB 
 xsysace: xsysace1 xsysace2 
Universal TUN/TAP device driver 1.5 (C)1999-2002 Maxim Krasnyansky 
XTemac: using FIFO direct interrupt driven mode. 
eth0: Xilinx TEMAC #0 at 0x20000000 mapped to 0xC2080000, irq=0 
eth0: XTemac id 1.0f, block id 5, type 8 
XTemac: using FIFO direct interrupt driven mode. 
eth1: Xilinx TEMAC #1 at 0x20010000 mapped to 0xC20A0000, irq=10 
eth1: XTemac id 1.0f, block id 5, type 8 
i2c /dev entries driver 
i2c-xil_custom: registered with I2C (0) 
i2c-xil_custom: registered with I2C (1) 
mice: PS/2 mouse device common for all mice 
NET: Registered protocol family 2 
IP: routing cache hash table of 512 buckets, 4Kbytes 
TCP: Hash tables configured (established 2048 bind 4096) 
NET: Registered protocol family 1 
NET: Registered protocol family 17 
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended 
kjournald starting.  Commit interval 5 seconds 
EXT3 FS on xsysace2, internal journal 
EXT3-fs: recovery complete. 
EXT3-fs: mounted filesystem with ordered data mode. 
VFS: Mounted root (ext3 filesystem). 
Freeing unused kernel memory: 124k init 
eth0: XTemac: Options: 0xb8f2 
eth0: XTemac: speed set to 100Mb/s 
eth0: XTemac: PHY Link carrier lost. 

# /sbin/ifconfig eth1 up 
# eth1: XTemac: Options: 0xb8f2 

Any suggestion? 




"Rick Moleres" <Rick.Moleres at xilinx.com> 
Sent by: linuxppc-embedded-bounces+linux-ppc=eurotel.it at ozlabs.org 

08/02/2007 17.23 

To

"Ming Liu" <eemingliu at hotmail.com>, <mamsadegh at hotmail.com> 

cc

linuxppc-embedded at ozlabs.org 

Subject

RE: ML403 Hard TEMAC, PLB and Linux 2.6

 

 

 




Hi,

As Ming says the Linux 2.6 TEMAC driver is made available in EDK 8.2.2 as part of the BSP and Libraries generation for Linux 2.6.  Note that we made a recent fix for better PHY address detection and speed negotiation. I've attached the adapter here, and it will be available in EDK 9.1.1 when that's released.

Thanks,
Rick

-----Original Message-----
From: linuxppc-embedded-bounces+moleres=xilinx.com at ozlabs.org [mailto:linuxppc-embedded-bounces+moleres=xilinx.com at ozlabs.org] On Behalf Of Ming Liu
Sent: Thursday, February 08, 2007 2:31 AM
To: mamsadegh at hotmail.com
Cc: linuxppc-embedded at ozlabs.org
Subject: RE: ML403 Hard TEMAC, PLB and Linux 2.6

Hi,
In xapp902, they are using the old cores for Temac. So it will be easier to 
generate a project in EDK 8.2. Not only the cores there are new, but also 
it can generate the driver for linux 2.6.

BR
Ming

>From: Mohammad Sadegh Sadri <mamsadegh at hotmail.com>
>To: <christophe.alayrac at cresitt.com>
>CC: linuxppc-embedded at ozlabs.org
>Subject: RE: ML403 Hard TEMAC, PLB and Linux 2.6
>Date: Thu, 8 Feb 2007 07:13:47 +0000
>
>
>Hi
>Thanks for reply
>Well, regarding xapp902, there is a very simple question, Where can I find 
it? It seems that Xilinx has deleted all of the links to these files.
>
>
>
>
>
>----------------------------------------
> > Subject: Re: ML403 Hard TEMAC, PLB and Linux 2.6
> > From: christophe.alayrac at cresitt.com
> > To: mamsadegh at hotmail.com
> > CC: linuxppc-embedded at ozlabs.org
> > Date: Thu, 8 Feb 2007 06:51:45 +0100
> >
> > Le mercredi 07 f?vrier 2007 ?22:30 +0000, Mohammad Sadegh Sadri a
> > ?crit :
> > Hi Mohammad,
> >
> > Please find here after some answer
> >
> > > 1- I want to use, ML403, Hard TEMAC and PLB TEMAC cores. Is there any 
ready to use design, or any reference design available for this?
> > > I'm using EDK 8.1 and I understood that, when I choose the ML403 
board , EDK does not use hard temac, so , should I add it manually? ( well 
this is funny, but the wizard does not use hard temac , is it true? )
> > > Is there any ready EDK projects for ML403, with TEMAC and PLB TEMAC 
modules already inserted and cofigured? (I don't want to use GSRD ) ( If 
yes would you please put the link here )
> > >
> > You can start from XAPP 902 from Xilinx, this design demonstrate TEMAC
> > use in loopback mode. Some memers from that community have tried from
> > that design as a starting point. I did not nknow if the succeed.
> > I would recommand to get EDK 8.2 SP2 and use the Wizard to build a new
> > design with TEMAC.
> >
> > > 2- Simply, Is there any driver available for linux 2.6 , for PLB 
TEMAC and Hard TEMAC modules? If yes , can you put the link here, so that I 
can download it?
> > >
> > For the kernel you can get it from Montavista source code site using 
GIT
> > to download it (linux-xilinx-26). This is 2.6.17.4 version (last week!)
> >
> > Then you will need to pacth the Kernel with TEMAC drivers (look for
> > TEMAC PAULUS MVISTA with google, or follow my messages in that mailing
> > list)
> > NOTE: If you use that TEMAC patch do not use SGDMA on your TEMAC, use
> > FIFO.
> >
> > > thanks
> > Regards
> >
> > Chris
> > > _________________________________________________________________
> > > Personalize your Live.com homepage with the news, weather, and photos 
you care about.
> > > http://www.live.com/getstarted.aspx?icid=T001MSN30A0701
> > > _______________________________________________
> > > Linuxppc-embedded mailing list
> > > Linuxppc-embedded at ozlabs.org
> > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
>
>_________________________________________________________________
>Live Search: New search found
>http://get.live.com/search/overview
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded at ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded

_________________________________________________________________
???????????????????????????? MSN Messenger:  http://messenger.msn.com/cn  

_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded at ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070719/7e64885e/attachment.htm 

From grant.likely at secretlab.ca  Fri Jul 20 01:40:43 2007
From: grant.likely at secretlab.ca (Grant Likely)
Date: Thu, 19 Jul 2007 09:40:43 -0600
Subject: ML403 Hard TEMAC, PLB and Linux 2.6
In-Reply-To: <BAY115-W1CC92C2510304D9E26E06B29E0@phx.gbl>
References: <BAY115-W1CC92C2510304D9E26E06B29E0@phx.gbl>
Message-ID: <fa686aa40707190840u2e2bd57dme1c4829c63a8280a@mail.gmail.com>

On 2/7/07, Mohammad Sadegh Sadri <mamsadegh at hotmail.com> wrote:
> 2- Simply, Is there any driver available for linux 2.6 , for PLB TEMAC and Hard TEMAC modules? If yes , can you put the link here, so that I can download it?

You can grab my 2.6 git tree.  It already has the TEMAC driver integrated.

webview:
http://git.secretlab.ca/cgi-bin/gitweb.cgi

URLs for pulling
git://git.secretlab.ca/git/linux-2.6.git
http://git.secretlab.ca/git/linux-2.6.git

Cheers,
g.


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195


From grant.likely at secretlab.ca  Fri Jul 20 01:42:42 2007
From: grant.likely at secretlab.ca (Grant Likely)
Date: Thu, 19 Jul 2007 09:42:42 -0600
Subject: ML403 Hard TEMAC, PLB and Linux 2.6
In-Reply-To: <fa686aa40707190840u2e2bd57dme1c4829c63a8280a@mail.gmail.com>
References: <BAY115-W1CC92C2510304D9E26E06B29E0@phx.gbl>
	<fa686aa40707190840u2e2bd57dme1c4829c63a8280a@mail.gmail.com>
Message-ID: <fa686aa40707190842i522e8389id0834db8c3b3f284@mail.gmail.com>

Gah!  Sorry; ignore my reply; this is a very old thread.

g.

On 7/19/07, Grant Likely <grant.likely at secretlab.ca> wrote:
> On 2/7/07, Mohammad Sadegh Sadri <mamsadegh at hotmail.com> wrote:
> > 2- Simply, Is there any driver available for linux 2.6 , for PLB TEMAC and Hard TEMAC modules? If yes , can you put the link here, so that I can download it?
>
> You can grab my 2.6 git tree.  It already has the TEMAC driver integrated.
>
> webview:
> http://git.secretlab.ca/cgi-bin/gitweb.cgi
>
> URLs for pulling
> git://git.secretlab.ca/git/linux-2.6.git
> http://git.secretlab.ca/git/linux-2.6.git
>
> Cheers,
> g.
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely at secretlab.ca
> (403) 399-0195
>


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195


From domen.puncer at telargo.com  Fri Jul 20 18:19:36 2007
From: domen.puncer at telargo.com (Domen Puncer)
Date: Fri, 20 Jul 2007 10:19:36 +0200
Subject: [PATCH] ucc_geth_mii: fix __exit called from __init
Message-ID: <20070720081936.GB4529@moe.telargo.com>

void __exit uec_mdio_exit(void) is called from
- static int __init ucc_geth_init(void)
- static void __exit ucc_geth_exit(void)

First one would make error path more than just an error.


Signed-off-by: Domen Puncer <domen.puncer at telargo.com>

---
 drivers/net/ucc_geth_mii.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Index: work-powerpc.git/drivers/net/ucc_geth_mii.c
===================================================================
--- work-powerpc.git.orig/drivers/net/ucc_geth_mii.c
+++ work-powerpc.git/drivers/net/ucc_geth_mii.c
@@ -272,7 +272,8 @@ int __init uec_mdio_init(void)
 	return of_register_platform_driver(&uec_mdio_driver);
 }
 
-void __exit uec_mdio_exit(void)
+/* called from __init ucc_geth_init, therefore can not be __exit */
+void uec_mdio_exit(void)
 {
 	of_unregister_platform_driver(&uec_mdio_driver);
 }


From mamsadegh at hotmail.com  Fri Jul 20 19:27:58 2007
From: mamsadegh at hotmail.com (Mohammad Sadegh Sadri)
Date: Fri, 20 Jul 2007 09:27:58 +0000
Subject: ML403 Hard TEMAC, PLB and Linux 2.6
Message-ID: <BAY115-W3E40B1AA7056BDABCB768B2F40@phx.gbl>


Dear Massimiliano
Well I do not know the solution to the problem, but just,
In your post, there is some thing interesting for me,

How could you implement such large circuit on one FX12 FPGA?
We have done many experineces with both of AVNET MM and ML403,

you have, DDR SDRAM Controller, GPIO, UART, SYSACE and two intances of Tri-mode TEMAC GMII, 
In our tests, with one instance of Tri mode TEMAC and UART and DDR controller, the whole FPGA resource were consumed we could not even put sysace interface.

For me, another important question is, how many PHY chips are available on your board? Each of Tri-mode temac modules are connected to a separate phy chip, yes?





________________________________
> Subject: RE: ML403 Hard TEMAC, PLB and Linux 2.6
> Date: Thu, 19 Jul 2007 09:00:33 -0600
> From: Rick.Moleres at xilinx.com
> To: linux-ppc at eurotel.it
> CC: eemingliu at hotmail.com; linuxppc-embedded at ozlabs.org; mamsadegh at hotmail.com
> 
> Hi,
> The first thing I would try is to make sure eth1 comes up without first bringing up eth0.  In other words, does it come up independently?  If not, there could be something wrong with its configuration in the kernel or perhaps a hardware design issue.  If both interfaces come up independently, but not together, then there??s likely a driver issue as we have not tested dual channel TEMAC with the Linux plb_temac driver.  Perhaps others on the list have.  The areas that I would look at would be:  make sure each interface is getting a unique and correct PHY address; make sure any calls to the shared registers of the two channels are protected with semaphores/spinlocks.  For example, I??m pretty sure the PHY registers are shared, so any PHY accesses should be protected.  I would think other Xilinx driver accesses like Start/Stop/Reset/Get or SetOptions/etc?? should be protected as they may access shared registers.
> -Rick
> ________________________________
> From: Massimiliano.Patriarca at eurotel.it [mailto:Massimiliano.Patriarca at eurotel.it] On Behalf Of linux-ppc at eurotel.it
> Sent: Thursday, July 19, 2007 7:51 AM
> To: Rick Moleres
> Cc: Ming Liu; linuxppc-embedded at ozlabs.org; linuxppc-embedded-bounces+linux-ppc=eurotel.it at ozlabs.org; mamsadegh at hotmail.com
> Subject: RE: ML403 Hard TEMAC, PLB and Linux 2.6
> Hi, we are trying to use both side of an hard temac + 2 plb temac in a Virtex4FX12 project.
> we succesfull implemented a single temac Montavista tree with eth0.
> when trying to use both temac, devices are correctly registered with kernel-
> eth0 comes up and working ok-
> when manually start eth1 (/sbin/ifconfig eth1 up) kernel hang without any error or info in the console
> # dmesg
> Linux version 2.6.10_mvl401-ml40x (massimiliano at linux-yhbz) (gcc version 3.4.3 (MontaVista 3.4.3-25.0.135.0702900 2007-04-01)) #250 Wed Jul 18 12:20:43 CEST 2007
> Eurotel motherboard init
> Port by MontaVista Software, Inc. (source at mvista.com)
> On node 0 totalpages: 7812
>   DMA zone: 7812 pages, LIFO batch:1
>   Normal zone: 0 pages, LIFO batch:1
>   HighMem zone: 0 pages, LIFO batch:1
> Built 1 zonelists
> Kernel command line: console=ttl0 root=/dev/xsysace2 rw ip=off
> Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFF000
> PID hash table entries: 128 (order: 7, 2048 bytes)
> hr_time_init: arch_to_nsec = 8192000, nsec_to_arch = 1099511627
> Console: colour dummy device 80x25
> Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
> Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
> Memory: 28420k available (1864k kernel code, 528k data, 124k init, 0k highmem)
> Calibrating delay loop... 252.92 BogoMIPS (lpj=126464)
> Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
> spawn_desched_task(00000000)
> desched cpu_callback 3/00000000
> ksoftirqd started up.
> desched cpu_callback 2/00000000
> desched thread 0 started up.
> NET: Registered protocol family 16
> Registering platform device 'xilinx_temac.0'. Parent at platform
> Registering platform device 'xilinx_temac.1'. Parent at platform
> Registering platform device 'xilinx_sysace.0'. Parent at platform
> Registering platform device 'xilinx_gpio.0'. Parent at platform
> Registering platform device 'xilinx_gpio.1'. Parent at platform
> Registering platform device 'oled_fb.0'. Parent at platform
> Generic PHY: Registered new driver
> oled_fb: 4096 video memory mapped to c2011000
> Console: switching to colour frame buffer device 16x8
> xgpio #0 at 0x40000000 mapped to 0xC2020000
> xgpio #1 at 0x40020000 mapped to 0xC2040000
> io scheduler noop registered
> io scheduler anticipatory registered
> io scheduler deadline registered
> io scheduler cfq registered
> loop: loaded (max 8 devices)
> elevator: using anticipatory as default io scheduler
> System ACE at 0x41800000 mapped to 0xC2060000, irq=4, 1000944KB
>  xsysace: xsysace1 xsysace2
> Universal TUN/TAP device driver 1.5 (C)1999-2002 Maxim Krasnyansky
> XTemac: using FIFO direct interrupt driven mode.
> eth0: Xilinx TEMAC #0 at 0x20000000 mapped to 0xC2080000, irq=0
> eth0: XTemac id 1.0f, block id 5, type 8
> XTemac: using FIFO direct interrupt driven mode.
> eth1: Xilinx TEMAC #1 at 0x20010000 mapped to 0xC20A0000, irq=10
> eth1: XTemac id 1.0f, block id 5, type 8
> i2c /dev entries driver
> i2c-xil_custom: registered with I2C (0)
> i2c-xil_custom: registered with I2C (1)
> mice: PS/2 mouse device common for all mice
> NET: Registered protocol family 2
> IP: routing cache hash table of 512 buckets, 4Kbytes
> TCP: Hash tables configured (established 2048 bind 4096)
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
> kjournald starting.  Commit interval 5 seconds
> EXT3 FS on xsysace2, internal journal
> EXT3-fs: recovery complete.
> EXT3-fs: mounted filesystem with ordered data mode.
> VFS: Mounted root (ext3 filesystem).
> Freeing unused kernel memory: 124k init
> eth0: XTemac: Options: 0xb8f2
> eth0: XTemac: speed set to 100Mb/s
> eth0: XTemac: PHY Link carrier lost.
> # /sbin/ifconfig eth1 up
> # eth1: XTemac: Options: 0xb8f2
> Any suggestion?
> "Rick Moleres" 
> Sent by: linuxppc-embedded-bounces+linux-ppc=eurotel.it at ozlabs.org
> 08/02/2007 17.23
> To
> "Ming Liu" , 
> cc
> linuxppc-embedded at ozlabs.org
> Subject
> RE: ML403 Hard TEMAC, PLB and Linux 2.6
> Hi,
> As Ming says the Linux 2.6 TEMAC driver is made available in EDK 8.2.2 as part of the BSP and Libraries generation for Linux 2.6.  Note that we made a recent fix for better PHY address detection and speed negotiation. I've attached the adapter here, and it will be available in EDK 9.1.1 when that's released.
> Thanks,
> Rick
> -----Original Message-----
> From: linuxppc-embedded-bounces+moleres=xilinx.com at ozlabs.org [mailto:linuxppc-embedded-bounces+moleres=xilinx.com at ozlabs.org] On Behalf Of Ming Liu
> Sent: Thursday, February 08, 2007 2:31 AM
> To: mamsadegh at hotmail.com
> Cc: linuxppc-embedded at ozlabs.org
> Subject: RE: ML403 Hard TEMAC, PLB and Linux 2.6
> Hi,
> In xapp902, they are using the old cores for Temac. So it will be easier to
> generate a project in EDK 8.2. Not only the cores there are new, but also
> it can generate the driver for linux 2.6.
> BR
> Ming
> >From: Mohammad Sadegh Sadri 
> >To: 
> >CC: linuxppc-embedded at ozlabs.org
> >Subject: RE: ML403 Hard TEMAC, PLB and Linux 2.6
> >Date: Thu, 8 Feb 2007 07:13:47 +0000
> >
> >
> >Hi
> >Thanks for reply
> >Well, regarding xapp902, there is a very simple question, Where can I find
> it? It seems that Xilinx has deleted all of the links to these files.
> >
> >
> >
> >
> >
> >----------------------------------------
> > > Subject: Re: ML403 Hard TEMAC, PLB and Linux 2.6
> > > From: christophe.alayrac at cresitt.com
> > > To: mamsadegh at hotmail.com
> > > CC: linuxppc-embedded at ozlabs.org
> > > Date: Thu, 8 Feb 2007 06:51:45 +0100
> > >
> > > Le mercredi 07 f?vrier 2007 ?22:30 +0000, Mohammad Sadegh Sadri a
> > > ?crit :
> > > Hi Mohammad,
> > >
> > > Please find here after some answer
> > >
> > > > 1- I want to use, ML403, Hard TEMAC and PLB TEMAC cores. Is there any
> ready to use design, or any reference design available for this?
> > > > I'm using EDK 8.1 and I understood that, when I choose the ML403
> board , EDK does not use hard temac, so , should I add it manually? ( well
> this is funny, but the wizard does not use hard temac , is it true? )
> > > > Is there any ready EDK projects for ML403, with TEMAC and PLB TEMAC
> modules already inserted and cofigured? (I don't want to use GSRD ) ( If
> yes would you please put the link here )
> > > >
> > > You can start from XAPP 902 from Xilinx, this design demonstrate TEMAC
> > > use in loopback mode. Some memers from that community have tried from
> > > that design as a starting point. I did not nknow if the succeed.
> > > I would recommand to get EDK 8.2 SP2 and use the Wizard to build a new
> > > design with TEMAC.
> > >
> > > > 2- Simply, Is there any driver available for linux 2.6 , for PLB
> TEMAC and Hard TEMAC modules? If yes , can you put the link here, so that I
> can download it?
> > > >
> > > For the kernel you can get it from Montavista source code site using
> GIT
> > > to download it (linux-xilinx-26). This is 2.6.17.4 version (last week!)
> > >
> > > Then you will need to pacth the Kernel with TEMAC drivers (look for
> > > TEMAC PAULUS MVISTA with google, or follow my messages in that mailing
> > > list)
> > > NOTE: If you use that TEMAC patch do not use SGDMA on your TEMAC, use
> > > FIFO.
> > >
> > > > thanks
> > > Regards
> > >
> > > Chris
> > > > _________________________________________________________________
> > > > Personalize your Live.com homepage with the news, weather, and photos
> you care about.
> > > > http://www.live.com/getstarted.aspx?icid=T001MSN30A0701
> > > > _______________________________________________
> > > > Linuxppc-embedded mailing list
> > > > Linuxppc-embedded at ozlabs.org
> > > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> > >
> >
> >_________________________________________________________________
> >Live Search: New search found
> >http://get.live.com/search/overview
> >_______________________________________________
> >Linuxppc-embedded mailing list
> >Linuxppc-embedded at ozlabs.org
> >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> _________________________________________________________________
> ???????????????????????????? MSN Messenger:  http://messenger.msn.com/cn
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

_________________________________________________________________
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE


From misbah_khan at engineer.com  Fri Jul 20 20:40:55 2007
From: misbah_khan at engineer.com (Misbah khan)
Date: Fri, 20 Jul 2007 03:40:55 -0700 (PDT)
Subject: Problem faced while using workqueue in the character driver.
Message-ID: <11705912.post@talk.nabble.com>


Hi all,

I am working on a character driver for FPGA, in which i am using a blocked
read call on workqueue. The read call will be unblocked by the Interrupt
from the Fpga to PPC Cpu.

The problem is that if the process is in blocked mode and then an Interrupt
occurs the system gives kernel Panic where as it get unblocked and start
reading the data but very soon it gets crashed.

Please send me your suggessins regarding the mentioned problem.
Thanks in advance 
with regard
Misbah
-- 
View this message in context: http://www.nabble.com/Problem-faced-while-using-workqueue-in-the-character-driver.-tf4116327.html#a11705912
Sent from the linuxppc-embedded mailing list archive at Nabble.com.



From misbah_khan at engineer.com  Fri Jul 20 20:52:21 2007
From: misbah_khan at engineer.com (Misbah khan)
Date: Fri, 20 Jul 2007 03:52:21 -0700 (PDT)
Subject: Kmalloc returns which address
In-Reply-To: <e5eb93010707160659m6a7d0b02p623542739d28ab29@mail.gmail.com>
References: <e5eb93010707160659m6a7d0b02p623542739d28ab29@mail.gmail.com>
Message-ID: <11705981.post@talk.nabble.com>


hi Suresh

In linux kmelloc returns the pointer to virtual address not the physical
address, to return to the physical address there is different function
called ioremap 

for eg :-
char *buf_tx =kmalloc(100,GFP_KERNEL); // Tx buffer
char *buf_rx=kmalloc(100,GFP_KERNEL); // Rx buffer

ptr_tx=ioremap( buf_tx,100);
ptr_rx=ioremap(buf_rx,100);

To learn more about this go through Linux device driver by rubini 

I hope this will work for you 
regard 
Misbah

suresh suresh wrote:
> 
> Hi,
> 
> I am porting MPC8280 driver from vxWorks to Linux.
> 
> I want know the address return by kmalloc function? is it physical address
> or kernel virtual address.
> 
> For Tx and Rx, hardware uses buffers, so I have to allocate buffers and
> pass
> the pointer to hardware. Can I pass the pointer returned kmalloc?  or  I
> should convert it into physical address?
> 
> If it returns kernel virtual address, then how to convert into physical?
> 
> Thanks & Regards-
> Suresh
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 

-- 
View this message in context: http://www.nabble.com/Kmalloc-returns-which-address-tf4086826.html#a11705981
Sent from the linuxppc-embedded mailing list archive at Nabble.com.



From misbah_khan at engineer.com  Fri Jul 20 21:32:17 2007
From: misbah_khan at engineer.com (Misbah khan)
Date: Fri, 20 Jul 2007 04:32:17 -0700 (PDT)
Subject: How to access physical memory from user space for MPC8260 chip
In-Reply-To: <0B45E93C5FF65740AEAE690BF3848B7A4AB178@rennsmail04.eu.thmulti.com>
References: <e5eb93010707120307h785bf195n7a649363e4e455f@mail.gmail.com>
	<0B45E93C5FF65740AEAE690BF3848B7A4AB178@rennsmail04.eu.thmulti.com>
Message-ID: <11706536.post@talk.nabble.com>


Physical address you can map to  kernel space using ioremap() function 
but you are not clear whether you want to map it to the user space / kernel
space. To map kernel space to user space you should use mmap() functionality
in your driver.

I hope you got the answer to what you were expecting else send the clear
query

regard 
misbah


Fillod Stephane wrote:
> 
> suresh suresh wrote:
>>I have to map physical memory to user space or kernel space. I am
> writing >driver for MPC8260 chip and I want to know how to map any
> 32-bit address >space to user space and kernel space.
> 
> Your question is a linuxppc-embedded FAQ. User-land access is documented
> 
> in Denx's FAQ[1], and accessible through shorter URL[2]. For more 
> information, please follow this thread[3] (not ppc specific actually).
> 
> [1]
> http://www.denx.de/twiki/bin/view/PPCEmbedded/DeviceDrivers#Section_Acce
> ssingPeripheralsFromUserSpace
> [2] http://tinyurl.com/6c7th
> [3] http://article.gmane.org/gmane.linux.ports.ppc.embedded/5053
> 
> In kernel land, ioremap() is all you need.
> 
> Don't forget to use the 'eieio' asm instruction if you want explicit 
> I/O ordering.
> 
> Best Regards,
> -- 
> Stephane, the userland ioremap bot
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 

-- 
View this message in context: http://www.nabble.com/How-to-access-physical-memory-from-user-space-for-MPC8260-chip-tf4067159.html#a11706536
Sent from the linuxppc-embedded mailing list archive at Nabble.com.



From rubini at gnudd.com  Fri Jul 20 22:13:22 2007
From: rubini at gnudd.com (Alessandro Rubini)
Date: Fri, 20 Jul 2007 14:13:22 +0200
Subject: Kmalloc returns which address
In-Reply-To: <11705981.post@talk.nabble.com>
References: <11705981.post@talk.nabble.com>
	<e5eb93010707160659m6a7d0b02p623542739d28ab29@mail.gmail.com>
Message-ID: <20070720121322.GA24055@mail.gnudd.com>


Hello.

> In linux kmelloc returns the pointer to virtual address not the physical
> address, to return to the physical address there is different function
> called ioremap 

Not exactly. Both return virtual addresses. The kmalloc one is allocated
RAM memory, the ioremap is the virtual address built for you to
access a physical address you specified (i.e., a device memory area).

>> For Tx and Rx, hardware uses buffers, so I have to allocate buffers and
>> pass
>> the pointer to hardware. Can I pass the pointer returned kmalloc?  or  I
>> should convert it into physical address?

If you allocate with kmalloc, use __pa(addr) to turn the virtual
address addr into the physical address you need to pass to the device,
ad DMA access is outside of the virtual view of the address space.

However, please note that according to how your device is connected
and what bus it is using, the design can get more hairy, you may need
to study the consistent memory allocations.

Hope this helps
/alessandro


From miroslaw.dach at psi.ch  Fri Jul 20 23:52:12 2007
From: miroslaw.dach at psi.ch (Mirek23)
Date: Fri, 20 Jul 2007 06:52:12 -0700 (PDT)
Subject: Interrupts on xilinx ml403
Message-ID: <11708607.post@talk.nabble.com>


Dear All,

      I use linux kernel 2.6 on ppc405 of my Avnet (xilinx like ml403)
evaluation board.

I have setup the virtex-4 FPGA to deal with Themac and Serial interfaces. As
input/output devices I have chosen 8 LEDs and DIP Switches.

With such a configuration I am able to control from Linux user applications
via GPIO driver the LEDs and DIP Switches.

Right now I just wanted to make use of the interrupts. I have configured the
Dip switches to use interrupt. The interrupt accoures when the DIP Switches
state has changed.

In the BSP generated by EDK 9.1 I see that macro :   

#define XPAR_DIP_SWITCHES_8BIT_INTERRUPT_PRESENT 1

has changed from zero to one.
The macro XPAR_INTC_MAX_NUM_INTR_INPUTS is set to 1 as it was before. This
is due to the fact that 
TEMAC uses one interrupt line.

Does it mean that DIP Switches do not use INTC interrupt controller?
How to handle the DIP Switches interrupt?
Does the Interrupt handler routine have to acknowledge the interrupt from
Dip Switches?

Many thanks in advance for any hint on that.

Best Regards

Mirek




 
-- 
View this message in context: http://www.nabble.com/Interrupts-on-xilinx-ml403-tf4117226.html#a11708607
Sent from the linuxppc-embedded mailing list archive at Nabble.com.



From grant.likely at secretlab.ca  Sat Jul 21 01:12:04 2007
From: grant.likely at secretlab.ca (Grant Likely)
Date: Fri, 20 Jul 2007 09:12:04 -0600
Subject: Interrupts on xilinx ml403
In-Reply-To: <11708607.post@talk.nabble.com>
References: <11708607.post@talk.nabble.com>
Message-ID: <fa686aa40707200812w3427c12dwd10b08c8433af2fc@mail.gmail.com>

On 7/20/07, Mirek23 <miroslaw.dach at psi.ch> wrote:
> Does it mean that DIP Switches do not use INTC interrupt controller?
> How to handle the DIP Switches interrupt?
> Does the Interrupt handler routine have to acknowledge the interrupt from
> Dip Switches?

It probably means that the GPIO irq out line is not hooked up to your
INTC in the system.mhs file.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195


From lokowich at acdstar.com  Sat Jul 21 01:40:30 2007
From: lokowich at acdstar.com (lokowich)
Date: Fri, 20 Jul 2007 10:40:30 -0500
Subject: SDRAM failures on MPC5200B
Message-ID: <46A0D76E.4030101@acdstar.com>

We're working on bringing up a MPC5200B version of our original MPC5200 
board using U-Boot 1.1.4 configured for Icecube/Lite5200B.  Other than 
the CPU, the board is identical.  The bootloader crashes just after 
relocation to RAM, often with a Program Check Exception, typically a 
memory corruption issue.  I noticed failures at different stages after 
relocation based on content, suggesting problems with upper SDRAM.  If I 
force the initram to 1/2 the determined size (64MB instead of 128MB), 
then everything works well through kernel load and initialization.  
We've added termination resistors to improve AD signals, to no avail.  
Memory tests work fine too.  Any help is appreciated.

Thanks,
Mark Lokowich
Systems Engineer
Advanced Communication Design
7901 12th Ave. So.
Bloomington, MN 55425
952-854-4000
lokowich at acdstar.com

This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070720/71b9f422/attachment.htm 

From jdboyer at mediatrix.com  Sat Jul 21 02:07:40 2007
From: jdboyer at mediatrix.com (Jean-Denis Boyer)
Date: Fri, 20 Jul 2007 12:07:40 -0400
Subject: Bug in PowerPC math emulator (stfiwx)
Message-ID: <6C7A33B8773A2E4C9BDF935D13FA3E71C2B2B6@MAIL1.mediatrix.com>


Hi,

I encountered a problem while running "valgrind" on my 8323E based
system, running kernel 2.6.19.7. My userland program performs a few
floating point operations at initialization, which is normally handled
by the math emulator. But when running it through valgrind, the VEX will
"regenerate" code dynamically, and internally uses instruction "stfiwx".
Here is a disassembly of that instruction taken from gdb.

	0x42336e64:     stfiwx  f15,0,r1

Although this instruction is valid, the math-emulator rejects it as
invalid. I looked into arch/powerpc/math-emu/math.c, and this is caused
by the second argument which is 0 (rA=0).

In fact, it appears to me that the case XE and XEU are swapped. The
argument rA=0 is invalid for the instructions which updates rA after
computing the effective address, but this is checked in the XE case
instead of XEU.

In attachement, there is a patch for this. The valgrind is very happy
with it now.

There is also a test program (fputest.c) which no longer produces a
SIGILL with the patch.


P.S.: Please CC me cause I'm not on your mailing list.

Sincerely,

Jean-Denis Boyer, Eng.
Mediatrix Telecom, a division of Media5 Corporation
(819)829-8749 x241 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: math.patch
Type: application/octet-stream
Size: 589 bytes
Desc: math.patch
Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070720/212e4a51/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fputest.c
Type: application/octet-stream
Size: 143 bytes
Desc: fputest.c
Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070720/212e4a51/attachment-0001.obj 

From scottwood at freescale.com  Sat Jul 21 02:58:38 2007
From: scottwood at freescale.com (Scott Wood)
Date: Fri, 20 Jul 2007 11:58:38 -0500
Subject: Kmalloc returns which address
In-Reply-To: <11705981.post@talk.nabble.com>
References: <e5eb93010707160659m6a7d0b02p623542739d28ab29@mail.gmail.com>
	<11705981.post@talk.nabble.com>
Message-ID: <46A0E9BE.4020305@freescale.com>

Misbah khan wrote:
> hi Suresh
> 
> In linux kmelloc returns the pointer to virtual address not the physical
> address, to return to the physical address there is different function
> called ioremap 
> 
> for eg :-
> char *buf_tx =kmalloc(100,GFP_KERNEL); // Tx buffer
> char *buf_rx=kmalloc(100,GFP_KERNEL); // Rx buffer
> 
> ptr_tx=ioremap( buf_tx,100);
> ptr_rx=ioremap(buf_rx,100);

That's a really easy way to cause a machine check.

-Scott


From raj at semihalf.com  Sat Jul 21 02:46:31 2007
From: raj at semihalf.com (Rafal Jaworowski)
Date: Fri, 20 Jul 2007 18:46:31 +0200
Subject: SDRAM failures on MPC5200B
In-Reply-To: <46A0D76E.4030101@acdstar.com>
References: <46A0D76E.4030101@acdstar.com>
Message-ID: <46A0E6E7.3050309@semihalf.com>

lokowich wrote:
> We're working on bringing up a MPC5200B version of our original MPC5200 
> board using U-Boot 1.1.4 configured for Icecube/Lite5200B.  Other than 
> the CPU, the board is identical.  The bootloader crashes just after 
> relocation to RAM, often with a Program Check Exception, typically a 
> memory corruption issue.  I noticed failures at different stages after 
> relocation based on content, suggesting problems with upper SDRAM.  If I 
> force the initram to 1/2 the determined size (64MB instead of 128MB), 
> then everything works well through kernel load and initialization.  
> We've added termination resistors to improve AD signals, to no avail.  
> Memory tests work fine too.  Any help is appreciated.
> 

Assuming your RAM chips are fine, are you setting the SDelay register 
(MBAR + 0x0190)? If not, this can lead to a strange hangs similar to the 
described. For details please see the current U-Boot's initdram() for 
icecube, and AN3221.

Rafal


From dwh at ovro.caltech.edu  Sat Jul 21 03:18:35 2007
From: dwh at ovro.caltech.edu (David Hawkins)
Date: Fri, 20 Jul 2007 10:18:35 -0700
Subject: Problem faced while using workqueue in the character driver.
In-Reply-To: <11705912.post@talk.nabble.com>
References: <11705912.post@talk.nabble.com>
Message-ID: <46A0EE6B.3000904@ovro.caltech.edu>

Hi Misbah,

> I am working on a character driver for FPGA, in which i am using a blocked
> read call on workqueue. The read call will be unblocked by the Interrupt
> from the Fpga to PPC Cpu.
> 
> The problem is that if the process is in blocked mode and then an Interrupt
> occurs the system gives kernel Panic where as it get unblocked and start
> reading the data but very soon it gets crashed.
> 
> Please send me your suggessins regarding the mentioned problem.

Er, without seeing the code, its a bit difficult to suggest
anything.

Perhaps you are using work-queues incorrectly?

Take a look at:

simple_work_queue.c

In the tar-ball

http://www.ovro.caltech.edu/~dwh/correlator/software/driver_design.tar.gz

Which is described in:

http://www.ovro.caltech.edu/~dwh/correlator/pdf/LNX-723-Hawkins.pdf

There's also a more complex 'COBRA driver' here:

http://www.ovro.caltech.edu/~dwh/correlator/cobra_docs.html

Having an example of a working driver that uses work-queues
might help you.

Dave


From khollan at daktronics.com  Sat Jul 21 05:57:23 2007
From: khollan at daktronics.com (khollan)
Date: Fri, 20 Jul 2007 12:57:23 -0700 (PDT)
Subject: Xilinx OPB_PCI support in 2.6
In-Reply-To: <46772167.5090808@itee.uq.edu.au>
References: <46772167.5090808@itee.uq.edu.au>
Message-ID: <11714957.post@talk.nabble.com>


Im also looking for ML410 PCI support.  Any progress on this John?

-- 
View this message in context: http://www.nabble.com/Xilinx-OPB_PCI-support-in-2.6-tf3943615.html#a11714957
Sent from the linuxppc-embedded mailing list archive at Nabble.com.



From bennett78 at lpbroadband.net  Sat Jul 21 03:03:40 2007
From: bennett78 at lpbroadband.net (Frank Bennett)
Date: Fri, 20 Jul 2007 11:03:40 -0600
Subject: SDRAM failures on MPC5200B
In-Reply-To: <46A0D76E.4030101@acdstar.com>
References: <46A0D76E.4030101@acdstar.com>
Message-ID: <46A0EAEC.9010607@lpbroadband.net>

lokowich wrote:
> We're working on bringing up a MPC5200B version of our original 
> MPC5200 board using U-Boot 1.1.4 configured for Icecube/Lite5200B.  
> Other than the CPU, the board is identical.  The bootloader crashes 
> just after relocation to RAM, often with a Program Check Exception, 
> typically a memory corruption issue.  I noticed failures at different 
> stages after relocation based on content, suggesting problems with 
> upper SDRAM.  If I force the initram to 1/2 the determined size (64MB 
> instead of 128MB), then everything works well through kernel load and 
> initialization.  We've added termination resistors to improve AD 
> signals, to no avail.  Memory tests work fine too.  Any help is 
> appreciated.
Review MPC5200B errata data sheets.  I found a BDI2000 + RS232 console 
port most useful for turning on a new design.  Even
the exercise of BDI commands to tftp load/verify, memory write/verify, 
debugging u-boot to run out of ram, with & w/o cache
turned on can be enlightening.

/*/Frank Bennett
President/*/

Mathegraphics,LLC
613 Bentley Pl
Fort Collins,CO 80526
www.mathegraphics.com <http://www.mathegraphics.com/>_
_

>
> Thanks,
> Mark Lokowich
> Systems Engineer
> Advanced Communication Design
> 7901 12th Ave. So.
> Bloomington, MN 55425
> 952-854-4000
> lokowich at acdstar.com
> This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070720/847cd61a/attachment.htm 

From fvoegel at carangul.com  Sat Jul 21 03:39:27 2007
From: fvoegel at carangul.com (Florian A. Voegel)
Date: Fri, 20 Jul 2007 19:39:27 +0200
Subject: SDRAM failures on MPC5200B
In-Reply-To: <46A0D76E.4030101@acdstar.com>
References: <46A0D76E.4030101@acdstar.com>
Message-ID: <20070720193927.858cd85b.fvoegel@carangul.com>

Hi,

Considering the age of the U-Boot version you're using, it's most likely the problem with the SD-RAM controller of the 5200B. Later U-Boot versions fix this I think by writing a value of 4 to the register at MBAR+0x0190, which does _something_ to resolve the problem. It worked for us. However, we still had problems with SD-RAM in conjunction with other components, so we switched to DDR which has worked flawlessly so far - you might want to consider doing the same.

Greets,

Florian Voegel
Carangul.Tech

On Fri, 20 Jul 2007 10:40:30 -0500
lokowich <lokowich at acdstar.com> wrote:

> We're working on bringing up a MPC5200B version of our original MPC5200 
> board using U-Boot 1.1.4 configured for Icecube/Lite5200B.  Other than 
> the CPU, the board is identical.  The bootloader crashes just after 
> relocation to RAM, often with a Program Check Exception, typically a 
> memory corruption issue.  I noticed failures at different stages after 
> relocation based on content, suggesting problems with upper SDRAM.  If I 
> force the initram to 1/2 the determined size (64MB instead of 128MB), 
> then everything works well through kernel load and initialization.  
> We've added termination resistors to improve AD signals, to no avail.  
> Memory tests work fine too.  Any help is appreciated.
> 
> Thanks,
> Mark Lokowich
> Systems Engineer
> Advanced Communication Design
> 7901 12th Ave. So.
> Bloomington, MN 55425
> 952-854-4000
> lokowich at acdstar.com
> 
> This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com
> 
> 


From g.liakhovetski at gmx.de  Sat Jul 21 10:03:06 2007
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Sat, 21 Jul 2007 02:03:06 +0200 (CEST)
Subject: [i2c] [PATCH] i2c-mpc: work around missing-9th-clock-pulse bug
In-Reply-To: <20070709071955.GD4186@moe.telargo.com>
References: <20070709071955.GD4186@moe.telargo.com>
Message-ID: <Pine.LNX.4.60.0707210154330.3946@poirot.grange>

On Mon, 9 Jul 2007, Domen Puncer wrote:

> Work around a problem reported on:
> http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019038.html
> Without this patch I2C on mpc5200 becomes unusable after a while.
> Tested on mpc5200 based boards by Matthias and me.

Domen, unfortunately, your suspicion, expressed on IRC, was right. It is 
this patch that breaks i2c on mpc8241 (linkstation). Reverting it fixes 
the problem. For reference, here's a rtc-debug log with this patch 
(linux-2.6 tree of 19.07):

rtc-rs5c372 0-0032: rs5c372_probe
rtc-rs5c372 0-0032: 52 28 21 (04) 19 07 07 (15), 04 00 6a, 08 00 3e; 00 20
rtc-rs5c372 0-0032: 28 21 04 (19) 07 07 15 (04), 00 6a 08, 00 3e 00; 20 52
rtc-rs5c372 0-0032: rs5c372_get_datetime: tm is secs=28, mins=21, hours=4, mday=7, mon=6, year=115, wday=1
rtc-rs5c372 0-0032: rs5c372b found, 24hr, driver version 0.5
rtc-rs5c372: dev (254:0)
rtc-rs5c372 0-0032: rtc core: registered rtc-rs5c372 as rtc0
rtc-rs5c372 0-0032: 21 04 19 (07) 07 15 04 (00), 6a 08 00, 3e 00 20; 52 28
rtc-rs5c372 0-0032: rs5c372_get_datetime: tm is secs=21, mins=4, hours=19, mday=7, mon=14, year=104, wday=7
rtc-rs5c372 0-0032: hctosys: unable to read the hardware clock

Let me know when you'll have any patches to test.

Thanks
Guennadi

> 
> 
> Signed-off-by: Domen Puncer <domen.puncer at telargo.com>
> 
> ---
>  drivers/i2c/busses/i2c-mpc.c |   19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> Index: work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
> ===================================================================
> --- work-powerpc.git.orig/drivers/i2c/busses/i2c-mpc.c
> +++ work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
> @@ -74,6 +74,20 @@ static irqreturn_t mpc_i2c_isr(int irq, 
>  	return IRQ_HANDLED;
>  }
>  
> +static void mpc_i2c_fixup(struct mpc_i2c *i2c)
> +{
> +	writeccr(i2c, 0);
> +	udelay(30);
> +	writeccr(i2c, CCR_MEN);
> +	udelay(30);
> +	writeccr(i2c, CCR_MSTA | CCR_MTX);
> +	udelay(30);
> +	writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);
> +	udelay(30);
> +	writeccr(i2c, CCR_MEN);
> +	udelay(30);
> +}
> +
>  static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
>  {
>  	unsigned long orig_jiffies = jiffies;
> @@ -153,6 +167,9 @@ static void mpc_i2c_start(struct mpc_i2c
>  static void mpc_i2c_stop(struct mpc_i2c *i2c)
>  {
>  	writeccr(i2c, CCR_MEN);
> +	mb();
> +	writeccr(i2c, 0);
> +	mb();
>  }
>  
>  static int mpc_write(struct mpc_i2c *i2c, int target,
> @@ -245,6 +262,8 @@ static int mpc_xfer(struct i2c_adapter *
>  		}
>  		if (time_after(jiffies, orig_jiffies + HZ)) {
>  			pr_debug("I2C: timeout\n");
> +			if (readb(i2c->base + MPC_I2C_SR) == (CSR_MCF | CSR_MBB | CSR_RXAK))
> +				mpc_i2c_fixup(i2c);
>  			return -EIO;
>  		}
>  		schedule();
> 
> _______________________________________________
> i2c mailing list
> i2c at lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/i2c
> 

---
Guennadi Liakhovetski


From xiay at nari-relays.com  Sat Jul 21 11:48:06 2007
From: xiay at nari-relays.com (=?gb2312?B?z8TT6g==?=)
Date: Sat, 21 Jul 2007 09:48:06 +0800
Subject: SDRAM failures on MPC5200B (Xia Yu)
In-Reply-To: <mailman.1484.1184968961.8639.linuxppc-embedded@ozlabs.org>
References: <mailman.1484.1184968961.8639.linuxppc-embedded@ozlabs.org>
Message-ID: <000601c7cb39$2f4390c0$596657c6@rcs9000.com>

Hi! According to the MPC5200B user's manual, you should define the S-delay
register(MBAR + 0x0190) to 0x04 ,and the initialization sequence of the DDR
should be modified according to the data sheet from MICRON. I have rewrite
the function as below:
static void sdram_start (int hi_addr)
{
	long hi_addr_bit = hi_addr ? 0x01000000 : 0;

	/* unlock mode register */
	*(vu_long *)MPC5XXX_SDRAM_CTRL = (SDRAM_CONTROL & 0xefffffff)|
0x80000000 | hi_addr_bit;
	__asm__ volatile ("sync");

	/* precharge all banks */
	*(vu_long *)MPC5XXX_SDRAM_CTRL = (SDRAM_CONTROL & 0xefffffff)|
0x80000002 | hi_addr_bit;
	__asm__ volatile ("sync");

#if SDRAM_DDR
	/* set mode register: extended mode */
	*(vu_long *)MPC5XXX_SDRAM_MODE = SDRAM_EMODE;
	__asm__ volatile ("sync");

	/* set mode register: reset DLL */
	*(vu_long *)MPC5XXX_SDRAM_MODE = SDRAM_MODE | 0x04000000;
	__asm__ volatile ("sync");
#endif

	/* precharge all banks */
	*(vu_long *)MPC5XXX_SDRAM_CTRL = (SDRAM_CONTROL & 0xefffffff) |
0x80000002 | hi_addr_bit;
	__asm__ volatile ("sync");

	/* auto refresh */
	*(vu_long *)MPC5XXX_SDRAM_CTRL = (SDRAM_CONTROL & 0xefffffff) |
0x80000004 | hi_addr_bit;
	__asm__ volatile ("sync");
	
	/* auto refresh */
	*(vu_long *)MPC5XXX_SDRAM_CTRL = (SDRAM_CONTROL & 0xefffffff) |
0x80000004 | hi_addr_bit;
	__asm__ volatile ("sync");
	
	/* set mode register */
	*(vu_long *)MPC5XXX_SDRAM_MODE = SDRAM_MODE;
	__asm__ volatile ("sync");

	/* normal operation */
	*(vu_long *)MPC5XXX_SDRAM_CTRL = SDRAM_CONTROL | hi_addr_bit;
	__asm__ volatile ("sync");
	
	udelay(3); //delay 400clks;

}

Hope to be helpful!



From jesper.juhl at gmail.com  Sun Jul 22 01:02:45 2007
From: jesper.juhl at gmail.com (Jesper Juhl)
Date: Sat, 21 Jul 2007 17:02:45 +0200
Subject: [PATCH][12/37] Clean up duplicate includes in drivers/net/
Message-ID: <200707211702.46375.jesper.juhl@gmail.com>

Hi,

This patch cleans up duplicate includes in
	 drivers/net/


Signed-off-by: Jesper Juhl <jesper.juhl at gmail.com>
---

diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c
index fd1e156..4a18b88 100644
--- a/drivers/net/atl1/atl1_main.c
+++ b/drivers/net/atl1/atl1_main.c
@@ -75,7 +75,6 @@
 #include <linux/compiler.h>
 #include <linux/delay.h>
 #include <linux/mii.h>
-#include <linux/interrupt.h>
 #include <net/checksum.h>
 
 #include <asm/atomic.h>
diff --git a/drivers/net/bfin_mac.c b/drivers/net/bfin_mac.c
index 9a08d65..01281ee 100644
--- a/drivers/net/bfin_mac.c
+++ b/drivers/net/bfin_mac.c
@@ -47,15 +47,10 @@
 #include <linux/spinlock.h>
 #include <linux/ethtool.h>
 #include <linux/mii.h>
-
 #include <linux/netdevice.h>
 #include <linux/etherdevice.h>
 #include <linux/skbuff.h>
-
 #include <linux/platform_device.h>
-#include <linux/netdevice.h>
-#include <linux/etherdevice.h>
-#include <linux/skbuff.h>
 
 #include <asm/dma.h>
 #include <linux/dma-mapping.h>
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index 60cccf2..9afd172 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -31,7 +31,6 @@
 #include <linux/inetdevice.h>
 #include <linux/in.h>
 #include <linux/sysfs.h>
-#include <linux/string.h>
 #include <linux/ctype.h>
 #include <linux/inet.h>
 #include <linux/rtnetlink.h>
diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
index a4a2a0e..27de3d8 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -39,8 +39,6 @@
 
 #include <linux/vmalloc.h>
 #include <asm/pgtable.h>
-
-#include <asm/pgtable.h>
 #include <asm/irq.h>
 #include <asm/uaccess.h>
 
diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
index d8e779c..43c8668 100644
--- a/drivers/net/gianfar.h
+++ b/drivers/net/gianfar.h
@@ -45,7 +45,6 @@
 #include <linux/crc32.h>
 #include <linux/workqueue.h>
 #include <linux/ethtool.h>
-#include <linux/netdevice.h>
 #include <linux/fsl_devices.h>
 #include "gianfar_mii.h"
 
diff --git a/drivers/net/gianfar_ethtool.c b/drivers/net/gianfar_ethtool.c
index 7b411c1..2470903 100644
--- a/drivers/net/gianfar_ethtool.c
+++ b/drivers/net/gianfar_ethtool.c
@@ -34,7 +34,6 @@
 #include <linux/module.h>
 #include <linux/crc32.h>
 #include <asm/types.h>
-#include <asm/uaccess.h>
 #include <linux/ethtool.h>
 #include <linux/mii.h>
 #include <linux/phy.h>
diff --git a/drivers/net/irda/kingsun-sir.c b/drivers/net/irda/kingsun-sir.c
index bdd5c97..4c0d379 100644
--- a/drivers/net/irda/kingsun-sir.c
+++ b/drivers/net/irda/kingsun-sir.c
@@ -66,7 +66,6 @@
 #include <linux/errno.h>
 #include <linux/init.h>
 #include <linux/slab.h>
-#include <linux/module.h>
 #include <linux/kref.h>
 #include <linux/usb.h>
 #include <linux/device.h>
diff --git a/drivers/net/irda/mcs7780.c b/drivers/net/irda/mcs7780.c
index 0de8672..bfc5752 100644
--- a/drivers/net/irda/mcs7780.c
+++ b/drivers/net/irda/mcs7780.c
@@ -50,7 +50,6 @@
 #include <linux/errno.h>
 #include <linux/init.h>
 #include <linux/slab.h>
-#include <linux/module.h>
 #include <linux/kref.h>
 #include <linux/usb.h>
 #include <linux/device.h>
diff --git a/drivers/net/mipsnet.c b/drivers/net/mipsnet.c
index 9853c74..c0f5ad3 100644
--- a/drivers/net/mipsnet.c
+++ b/drivers/net/mipsnet.c
@@ -11,7 +11,6 @@
 #include <linux/module.h>
 #include <linux/netdevice.h>
 #include <linux/etherdevice.h>
-#include <linux/netdevice.h>
 #include <linux/platform_device.h>
 #include <asm/io.h>
 #include <asm/mips-boards/simint.h>
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index b703ccf..6ba8e07 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -39,7 +39,6 @@
 #include "netxen_nic_phan_reg.h"
 
 #include <linux/dma-mapping.h>
-#include <linux/vmalloc.h>
 #include <net/ip.h>
 
 MODULE_DESCRIPTION("NetXen Multi port (1/10) Gigabit Network Driver");
diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
index 8be8be4..c2fc2f7 100755
--- a/drivers/net/qla3xxx.c
+++ b/drivers/net/qla3xxx.c
@@ -31,7 +31,6 @@
 #include <linux/skbuff.h>
 #include <linux/rtnetlink.h>
 #include <linux/if_vlan.h>
-#include <linux/init.h>
 #include <linux/delay.h>
 #include <linux/mm.h>
 
diff --git a/drivers/net/tsi108_eth.c b/drivers/net/tsi108_eth.c
index 1aabc91..a059f3d 100644
--- a/drivers/net/tsi108_eth.c
+++ b/drivers/net/tsi108_eth.c
@@ -47,7 +47,6 @@
 #include <linux/rtnetlink.h>
 #include <linux/timer.h>
 #include <linux/platform_device.h>
-#include <linux/etherdevice.h>
 
 #include <asm/system.h>
 #include <asm/io.h>
diff --git a/drivers/net/wireless/ipw2200.h b/drivers/net/wireless/ipw2200.h
index 626a240..9c973b9 100644
--- a/drivers/net/wireless/ipw2200.h
+++ b/drivers/net/wireless/ipw2200.h
@@ -45,7 +45,6 @@
 
 #include <linux/firmware.h>
 #include <linux/wireless.h>
-#include <linux/dma-mapping.h>
 #include <linux/jiffies.h>
 #include <asm/io.h>
 
diff --git a/drivers/net/wireless/zd1211rw/zd_def.h b/drivers/net/wireless/zd1211rw/zd_def.h
index deb99d1..505b4d7 100644
--- a/drivers/net/wireless/zd1211rw/zd_def.h
+++ b/drivers/net/wireless/zd1211rw/zd_def.h
@@ -21,7 +21,6 @@
 #include <linux/kernel.h>
 #include <linux/stringify.h>
 #include <linux/device.h>
-#include <linux/kernel.h>
 
 typedef u16 __nocast zd_addr_t;
 


From csnook at redhat.com  Sun Jul 22 02:40:28 2007
From: csnook at redhat.com (Chris Snook)
Date: Sat, 21 Jul 2007 12:40:28 -0400
Subject: [PATCH][12/37] Clean up duplicate includes in drivers/net/
In-Reply-To: <200707211702.46375.jesper.juhl@gmail.com>
References: <200707211702.46375.jesper.juhl@gmail.com>
Message-ID: <46A236FC.2080300@redhat.com>

Jesper Juhl wrote:
> Hi,
> 
> This patch cleans up duplicate includes in
> 	 drivers/net/
> 
> 
> Signed-off-by: Jesper Juhl <jesper.juhl at gmail.com>
> ---
> 
> diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c
> index fd1e156..4a18b88 100644
> --- a/drivers/net/atl1/atl1_main.c
> +++ b/drivers/net/atl1/atl1_main.c
> @@ -75,7 +75,6 @@
>  #include <linux/compiler.h>
>  #include <linux/delay.h>
>  #include <linux/mii.h>
> -#include <linux/interrupt.h>
>  #include <net/checksum.h>
>  
>  #include <asm/atomic.h>

Define "duplicate".  I ask because this patch just got posted a few days ago:

Signed-off-by: Al Viro <viro at zeniv.linux.org.uk>
---
  drivers/net/atl1/atl1_main.c |    1 +
  1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c
index 4a18b88..fd1e156 100644
--- a/drivers/net/atl1/atl1_main.c
+++ b/drivers/net/atl1/atl1_main.c
@@ -75,6 +75,7 @@
  #include <linux/compiler.h>
  #include <linux/delay.h>
  #include <linux/mii.h>
+#include <linux/interrupt.h>
  #include <net/checksum.h>

  #include <asm/atomic.h>

I've always been under the impression that one should include all the files 
whose contents you use directly, because other includes that happen to include 
them might no longer need to in the future and cease including them.  You can 
fight it out with Al if you feel like it.  I'm keeping the rest of the CC list 
because the other maintainers might have similar feelings about the 
appropriateness of these includes in their drivers.

	-- Chris


From viro at ftp.linux.org.uk  Sun Jul 22 02:46:21 2007
From: viro at ftp.linux.org.uk (Al Viro)
Date: Sat, 21 Jul 2007 17:46:21 +0100
Subject: [PATCH][12/37] Clean up duplicate includes in drivers/net/
In-Reply-To: <46A236FC.2080300@redhat.com>
References: <200707211702.46375.jesper.juhl@gmail.com>
	<46A236FC.2080300@redhat.com>
Message-ID: <20070721164621.GN21668@ftp.linux.org.uk>

On Sat, Jul 21, 2007 at 12:40:28PM -0400, Chris Snook wrote:
> Define "duplicate".  I ask because this patch just got posted a few days 
> ago:

... and it had been wrong - it's really a duplicate (check several lines
above).  My apologies.


From jesper.juhl at gmail.com  Sun Jul 22 02:48:07 2007
From: jesper.juhl at gmail.com (Jesper Juhl)
Date: Sat, 21 Jul 2007 18:48:07 +0200
Subject: [PATCH][12/37] Clean up duplicate includes in drivers/net/
In-Reply-To: <46A236FC.2080300@redhat.com>
References: <200707211702.46375.jesper.juhl@gmail.com>
	<46A236FC.2080300@redhat.com>
Message-ID: <9a8748490707210948k468f8f32k718d84279aa56ce9@mail.gmail.com>

On 21/07/07, Chris Snook <csnook at redhat.com> wrote:
> Jesper Juhl wrote:
> > Hi,
> >
> > This patch cleans up duplicate includes in
> >        drivers/net/
> >
> >
> > Signed-off-by: Jesper Juhl <jesper.juhl at gmail.com>
> > ---
> >
> > diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c
> > index fd1e156..4a18b88 100644
> > --- a/drivers/net/atl1/atl1_main.c
> > +++ b/drivers/net/atl1/atl1_main.c
> > @@ -75,7 +75,6 @@
> >  #include <linux/compiler.h>
> >  #include <linux/delay.h>
> >  #include <linux/mii.h>
> > -#include <linux/interrupt.h>
> >  #include <net/checksum.h>
> >
> >  #include <asm/atomic.h>
>
> Define "duplicate".  I ask because this patch just got posted a few days ago:
>

duplicate == present more than once in the same source file.
Did you try looking at the includes in the source file the patch modifies?


> Signed-off-by: Al Viro <viro at zeniv.linux.org.uk>
> ---
>   drivers/net/atl1/atl1_main.c |    1 +
>   1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c
> index 4a18b88..fd1e156 100644
> --- a/drivers/net/atl1/atl1_main.c
> +++ b/drivers/net/atl1/atl1_main.c
> @@ -75,6 +75,7 @@
>   #include <linux/compiler.h>
>   #include <linux/delay.h>
>   #include <linux/mii.h>
> +#include <linux/interrupt.h>
>   #include <net/checksum.h>
>
>   #include <asm/atomic.h>
>
> I've always been under the impression that one should include all the files
> whose contents you use directly, because other includes that happen to include
> them might no longer need to in the future and cease including them.

I agree completely. But that's completely beside the point here.

Before Al's patch, drivers/net/atl1/atl1_main.c already contained
"#include <linux/interrupt.h>".

> You can
> fight it out with Al if you feel like it.  I'm keeping the rest of the CC list
> because the other maintainers might have similar feelings about the
> appropriateness of these includes in their drivers.
>

Take a look at the file. These are the includes at the top of
drivers/net/atl1/atl1_main.c :

...
#include <linux/types.h>
#include <linux/netdevice.h>
#include <linux/pci.h>
#include <linux/spinlock.h>
#include <linux/slab.h>
#include <linux/string.h>
#include <linux/skbuff.h>
#include <linux/etherdevice.h>
#include <linux/if_vlan.h>
#include <linux/irqreturn.h>
#include <linux/workqueue.h>
#include <linux/timer.h>
#include <linux/jiffies.h>
#include <linux/hardirq.h>
#include <linux/interrupt.h>          <--- Here we have linux/interrupt.h
#include <linux/irqflags.h>
#include <linux/dma-mapping.h>
#include <linux/net.h>
#include <linux/pm.h>
#include <linux/in.h>
#include <linux/ip.h>
#include <linux/tcp.h>
#include <linux/compiler.h>
#include <linux/delay.h>
#include <linux/mii.h>
#include <linux/interrupt.h>          <--- And here we include it again.
#include <net/checksum.h>

#include <asm/atomic.h>
#include <asm/byteorder.h>

#include "atl1.h"
...

Now please tell me why it makes sense to include the same header twice
and why my patch that removes the duplicate does not make sense.

-- 
Jesper Juhl <jesper.juhl at gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html


From mls.JOFT at gmx.de  Sun Jul 22 05:57:58 2007
From: mls.JOFT at gmx.de (Joachim =?ISO-8859-1?Q?F=F6rster?=)
Date: Sat, 21 Jul 2007 21:57:58 +0200
Subject: ML403 / ALSA driver for AC97 Controller
Message-ID: <1185047879.15040.34.camel@localhost>

Hi all,

some days ago I "finished" a first working version of my ALSA driver for
Xilinx' AC97 Controller Reference ip core, usually used on Xilinx' ML403
board. In fact it's a kind of byproduct of another project I am
currently working on.

Anybody interested in the driver may download it here:
http://www.esic-solutions.com/support.html

The version number 0.0.1-pre1 indicates, that it is a kind of (early)
prerelease, which might be far from a "complete" state. So, if you have
any problems with it, feel free to mail me (JOFT at gmx.de). Or, if there
are any suggestions, opinions, special experience ... etc., let me know
it.

The tar file contains a README, with all relevant info - I hope I didn't
forget something important. Just one thing: Capture support basically
works, but there are overruns after ~30s with rates > ~20kHz at least on
the board and setup I'm working on => consider this to be a know bug.
Playback support (which was the primary goal) seems to be pretty stable.

I thought it would be a good idea to publish the driver, because over
the last few months, there were - not much - but several mails on this
list on sound support for the ML403.

 Joachim




From grant.likely at secretlab.ca  Sun Jul 22 06:17:21 2007
From: grant.likely at secretlab.ca (Grant Likely)
Date: Sat, 21 Jul 2007 14:17:21 -0600
Subject: ML403 / ALSA driver for AC97 Controller
In-Reply-To: <1185047879.15040.34.camel@localhost>
References: <1185047879.15040.34.camel@localhost>
Message-ID: <fa686aa40707211317q47b12a38jbe05e4d2c89767f4@mail.gmail.com>

On 7/21/07, Joachim F?rster <mls.JOFT at gmx.de> wrote:
> Hi all,

Thanks Joachim, this is interesting work.  I'd like to see this get
into mainline.

A few initial comments:
1. You should post this code as a patch against the kernel tree.
Links to tarballs are not the best way to get code reviewed.  Post
your patches to both the ALSA and linuxppc-dev mailing lists.
2. (get this out of the way quickly) Coding standard doesn't match the
kernel (indent w/ tabs, keep lines < 80 chars, etc).  You should run
your code through 'scripts/Lindent' in the kernel tree.  That will
sort out many of the whitespace issues.
3. In the same vein, c++ style comments need to be scrubbed.
4. Do not directly include xparameters.h in your driver.  The driver
should get it's data from the platform bus registration (of the
of_device registration when we move to arch/powerpc).
5. struct 'platform_device devices[]' needs to be moved to
arch/ppc/sysdev/virtex_devices.c
6. Have you looked into the new ALSA infrastructure which separates
Codecs from controllers (in sound/soc)?  It might be a good idea to go
that route for this driver.

That being said, it looks like good work.  Please cc me when you send
the next version.

Thanks,
g.

---
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195


From csnook at redhat.com  Sun Jul 22 02:50:26 2007
From: csnook at redhat.com (Chris Snook)
Date: Sat, 21 Jul 2007 12:50:26 -0400
Subject: [PATCH][12/37] Clean up duplicate includes in drivers/net/
In-Reply-To: <9a8748490707210948k468f8f32k718d84279aa56ce9@mail.gmail.com>
References: <200707211702.46375.jesper.juhl@gmail.com>	
	<46A236FC.2080300@redhat.com>
	<9a8748490707210948k468f8f32k718d84279aa56ce9@mail.gmail.com>
Message-ID: <46A23952.6060207@redhat.com>

Jesper Juhl wrote:
> On 21/07/07, Chris Snook <csnook at redhat.com> wrote:
>> Jesper Juhl wrote:
>> > Hi,
>> >
>> > This patch cleans up duplicate includes in
>> >        drivers/net/
>> >
>> >
>> > Signed-off-by: Jesper Juhl <jesper.juhl at gmail.com>
>> > ---
>> >
>> > diff --git a/drivers/net/atl1/atl1_main.c 
>> b/drivers/net/atl1/atl1_main.c
>> > index fd1e156..4a18b88 100644
>> > --- a/drivers/net/atl1/atl1_main.c
>> > +++ b/drivers/net/atl1/atl1_main.c
>> > @@ -75,7 +75,6 @@
>> >  #include <linux/compiler.h>
>> >  #include <linux/delay.h>
>> >  #include <linux/mii.h>
>> > -#include <linux/interrupt.h>
>> >  #include <net/checksum.h>
>> >
>> >  #include <asm/atomic.h>
>>
>> Define "duplicate".  I ask because this patch just got posted a few 
>> days ago:
>>
> 
> duplicate == present more than once in the same source file.
> Did you try looking at the includes in the source file the patch modifies?

Nope!  Mea Culpa.

	-- Chris


From poorbeyond at 163.com  Sun Jul 22 17:39:22 2007
From: poorbeyond at 163.com (poorbeyond)
Date: Sun, 22 Jul 2007 15:39:22 +0800
Subject: ask some questions about u-boot's bootm command
Message-ID: <200707221539215465156@163.com>

my cpu is 860T, using bootm command boot a linux kernel image, the following message print by smc1:

bootm 300000

## Booting image at 00300000 ...
   Image Name:   Linux-2.6.20.14
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    1081591 Bytes =  1 MB
   Load Address: 00100000
   Entry Point:  00100000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
## Current stack ends at 0x01D5DB10 => set upper limit to 0x00800000
No initrd
## Transferring control to Linux (at address 00100000) ...



then, the program has no response.

i debug it througth BDM, in u-boot function "do_bootm_linux", execute at "kernel = (void (*)(bd_t *, ulong, ulong, ulong, ulong))hdr->ih_ep", the program branch to address "0x00000000", the code is shown as following:
00000000    mr    r31,r3
00000004    mr    r30,r4
00000008    mr    r29,r5
0000000C    mr    r28,r6
00000010    mr    r27,r7
00000014    bl    0x000020C8
00000018    mfmsr    r0
0000001C    ori    r0,r0,0x30
00000020    mtspr    SRR1,r0
00000024    lis    r0,0xC0002004 at h
00000028    ori    r0,r0,0xC0002004 at l
0000002C    mtspr    SRR0,r0
00000030    rfi


my questions are:

1. Is the code "kernel = (void (*)(bd_t *, ulong, ulong, ulong, ulong))hdr->ih_ep" branch right?

2. What's the expected code after "kernel = (void (*)(bd_t *, ulong, ulong, ulong, ulong))hdr->ih_ep"?

3. When the kernel run to the "boot/simple/head.s"?


thanks a lot





poorbeyond
2007-07-22
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070722/6f2dbc9d/attachment.htm 

From misbah_khan at engineer.com  Mon Jul 23 13:35:44 2007
From: misbah_khan at engineer.com (Misbah khan)
Date: Sun, 22 Jul 2007 20:35:44 -0700 (PDT)
Subject: Problem faced while using workqueue in the character driver.
In-Reply-To: <46A0EE6B.3000904@ovro.caltech.edu>
References: <11705912.post@talk.nabble.com> <46A0EE6B.3000904@ovro.caltech.edu>
Message-ID: <11737447.post@talk.nabble.com>


hi David

Thanks for your reply I really appreciate it from the heart.

The problem is solved now ,Actually I was using a kernel timer in open call
(to run for the first time which ever application would open it and deleting
the timer for the last exit ) to simulate for an Interrupt in the same
driver. There i did mistake in the implimentation in the logic and as a
consiquence of which it was crashing the system and not because of the
workqueue.

thanks 
misbah

David Hawkins-3 wrote:
> 
> Hi Misbah,
> 
>> I am working on a character driver for FPGA, in which i am using a
>> blocked
>> read call on workqueue. The read call will be unblocked by the Interrupt
>> from the Fpga to PPC Cpu.
>> 
>> The problem is that if the process is in blocked mode and then an
>> Interrupt
>> occurs the system gives kernel Panic where as it get unblocked and start
>> reading the data but very soon it gets crashed.
>> 
>> Please send me your suggessins regarding the mentioned problem.
> 
> Er, without seeing the code, its a bit difficult to suggest
> anything.
> 
> Perhaps you are using work-queues incorrectly?
> 
> Take a look at:
> 
> simple_work_queue.c
> 
> In the tar-ball
> 
> http://www.ovro.caltech.edu/~dwh/correlator/software/driver_design.tar.gz
> 
> Which is described in:
> 
> http://www.ovro.caltech.edu/~dwh/correlator/pdf/LNX-723-Hawkins.pdf
> 
> There's also a more complex 'COBRA driver' here:
> 
> http://www.ovro.caltech.edu/~dwh/correlator/cobra_docs.html
> 
> Having an example of a working driver that uses work-queues
> might help you.
> 
> Dave
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 

-- 
View this message in context: http://www.nabble.com/Problem-faced-while-using-workqueue-in-the-character-driver.-tf4116327.html#a11737447
Sent from the linuxppc-embedded mailing list archive at Nabble.com.



From misbah_khan at engineer.com  Mon Jul 23 13:47:47 2007
From: misbah_khan at engineer.com (Misbah khan)
Date: Sun, 22 Jul 2007 20:47:47 -0700 (PDT)
Subject: Kmalloc returns which address
In-Reply-To: <469B92DC.50609@freescale.com>
References: <e5eb93010707160659m6a7d0b02p623542739d28ab29@mail.gmail.com>
	<469B92DC.50609@freescale.com>
Message-ID: <11737504.post@talk.nabble.com>


hi Scott

yes really it would really generate a machine check... but i guess if you
convert this virt address to physical address using __pa() then pass it to
the ioremap() i guess things will work .

Please correct me if i am wrong

regard 
misbah
 

Scott Wood-2 wrote:
> 
> suresh suresh wrote:
>> I want know the address return by kmalloc function? is it physical
>> address
>> or kernel virtual address.
> 
> Kernel virtual.
> 
>> For Tx and Rx, hardware uses buffers, so I have to allocate buffers and 
>> pass
>> the pointer to hardware. Can I pass the pointer returned kmalloc?  or  I
>> should convert it into physical address?
> 
> You need to convert it; read Documentation/DMA-mapping.txt.
> 
> -Scott
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 

-- 
View this message in context: http://www.nabble.com/Kmalloc-returns-which-address-tf4086826.html#a11737504
Sent from the linuxppc-embedded mailing list archive at Nabble.com.



From linville at tuxdriver.com  Mon Jul 23 23:22:25 2007
From: linville at tuxdriver.com (John W. Linville)
Date: Mon, 23 Jul 2007 09:22:25 -0400
Subject: [PATCH][12/37] Clean up duplicate includes in drivers/net/
In-Reply-To: <200707211702.46375.jesper.juhl@gmail.com>
References: <200707211702.46375.jesper.juhl@gmail.com>
Message-ID: <20070723132225.GA3723@tuxdriver.com>

On Sat, Jul 21, 2007 at 05:02:45PM +0200, Jesper Juhl wrote:
> Hi,
> 
> This patch cleans up duplicate includes in
> 	 drivers/net/
> 
> 
> Signed-off-by: Jesper Juhl <jesper.juhl at gmail.com>

> diff --git a/drivers/net/wireless/ipw2200.h b/drivers/net/wireless/ipw2200.h
> index 626a240..9c973b9 100644
> --- a/drivers/net/wireless/ipw2200.h
> +++ b/drivers/net/wireless/ipw2200.h
> @@ -45,7 +45,6 @@
>  
>  #include <linux/firmware.h>
>  #include <linux/wireless.h>
> -#include <linux/dma-mapping.h>
>  #include <linux/jiffies.h>
>  #include <asm/io.h>
>  
> diff --git a/drivers/net/wireless/zd1211rw/zd_def.h b/drivers/net/wireless/zd1211rw/zd_def.h
> index deb99d1..505b4d7 100644
> --- a/drivers/net/wireless/zd1211rw/zd_def.h
> +++ b/drivers/net/wireless/zd1211rw/zd_def.h
> @@ -21,7 +21,6 @@
>  #include <linux/kernel.h>
>  #include <linux/stringify.h>
>  #include <linux/device.h>
> -#include <linux/kernel.h>
>  
>  typedef u16 __nocast zd_addr_t;

ACK

-- 
John W. Linville
linville at tuxdriver.com

From Martin.Leisner at xerox.com  Tue Jul 24 01:27:00 2007
From: Martin.Leisner at xerox.com (Leisner, Martin)
Date: Mon, 23 Jul 2007 11:27:00 -0400
Subject: support for MPC8220?
Message-ID: <556445368AFA1C438794ABDA8901891C066B5B56@usa0300ms03.na.xerox.net>

Is there support for MPC8220 in current kernels?

I didn't see it there, in freescale's site it mentions Montavista Pro
3.1.

marty

From bgat at billgatliff.com  Tue Jul 24 01:37:13 2007
From: bgat at billgatliff.com (Bill Gatliff)
Date: Mon, 23 Jul 2007 10:37:13 -0500
Subject: Gdbserver syscall clobber
In-Reply-To: <20070718183143.GA25324@caradoc.them.org>
References: <469B922D.3050701@billgatliff.com>
	<20070716155348.GA5281@caradoc.them.org>
	<469E550E.5080905@billgatliff.com>
	<20070718183143.GA25324@caradoc.them.org>
Message-ID: <46A4CB29.9080705@billgatliff.com>

Daniel Jacobowitz wrote:
> On Wed, Jul 18, 2007 at 12:59:42PM -0500, Bill Gatliff wrote:
>   
>> Now, I'm a little rusty on PPC asm (I've been doing a lot of ARM
>> lately), but it looks to me like the kernel is setting bit 0 in CR0
>> (oris r10, r10, 0x1000) a.k.a LT, but the user side is looking at CR0
>> (bnslr+) bit 3 a.k.a. SO.  Or maybe the other way around, I'm not sure
>> after reading Sections 1.2 and 2.1 of the Programming Environments manual.
>>     
>
> It's not checking for restart here - userspace isn't supposed to have to.
> It's probably checking for error.  Check for the bit of kernel code
> that's supposed to back you up two instructions.
>
>   

I don't see it in this kernel.  What I see is this after the call to the 
syscall handler:

    li    r10,-_LAST_ERRNO
    cmpl    0,r3,r10
    blt    30f
    neg    r3,r3
    cmpi    0,r3,ERESTARTNOHAND
    bne    22f
    li    r3,EINTR
22:    lwz    r10,_CCR(r1)    /* Set SO bit in CR */
    oris    r10,r10,0x1000
    stw    r10,_CCR(r1)
30:    stw    r3,GPR3(r1)    /* Update return value */
    b    ret_from_except
66:    li    r3,ENOSYS
    b    22b


?

-- 
Bill Gatliff
bgat at billgatliff.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070723/0003f27f/attachment.htm 

From bgat at billgatliff.com  Tue Jul 24 01:38:36 2007
From: bgat at billgatliff.com (Bill Gatliff)
Date: Mon, 23 Jul 2007 10:38:36 -0500
Subject: Gdbserver syscall clobber
In-Reply-To: <20070718183143.GA25324@caradoc.them.org>
References: <469B922D.3050701@billgatliff.com>
	<20070716155348.GA5281@caradoc.them.org>
	<469E550E.5080905@billgatliff.com>
	<20070718183143.GA25324@caradoc.them.org>
Message-ID: <46A4CB7C.8090806@billgatliff.com>

Daniel Jacobowitz wrote:
> On Wed, Jul 18, 2007 at 12:59:42PM -0500, Bill Gatliff wrote:
>   
>> Now, I'm a little rusty on PPC asm (I've been doing a lot of ARM
>> lately), but it looks to me like the kernel is setting bit 0 in CR0
>> (oris r10, r10, 0x1000) a.k.a LT, but the user side is looking at CR0
>> (bnslr+) bit 3 a.k.a. SO.  Or maybe the other way around, I'm not sure
>> after reading Sections 1.2 and 2.1 of the Programming Environments manual.
>>     
>
> It's not checking for restart here - userspace isn't supposed to have to.
> It's probably checking for error.  Check for the bit of kernel code
> that's supposed to back you up two instructions.
>
>   

I don't see it in this kernel.  What I see is this after the call to the 
syscall handler:

    li    r10,-_LAST_ERRNO
    cmpl    0,r3,r10
    blt    30f
    neg    r3,r3
    cmpi    0,r3,ERESTARTNOHAND
    bne    22f
    li    r3,EINTR
22:    lwz    r10,_CCR(r1)    /* Set SO bit in CR */
    oris    r10,r10,0x1000
    stw    r10,_CCR(r1)
30:    stw    r3,GPR3(r1)    /* Update return value */
    b    ret_from_except
66:    li    r3,ENOSYS
    b    22b


?

-- 
Bill Gatliff
bgat at billgatliff.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070723/acc3fa3f/attachment.htm 

From bgat at billgatliff.com  Tue Jul 24 02:06:13 2007
From: bgat at billgatliff.com (Bill Gatliff)
Date: Mon, 23 Jul 2007 11:06:13 -0500
Subject: Gdbserver syscall clobber
In-Reply-To: <20070718183143.GA25324@caradoc.them.org>
References: <469B922D.3050701@billgatliff.com>
	<20070716155348.GA5281@caradoc.them.org>
	<469E550E.5080905@billgatliff.com>
	<20070718183143.GA25324@caradoc.them.org>
Message-ID: <46A4D1F5.1060005@billgatliff.com>

Daniel Jacobowitz wrote:
> On Wed, Jul 18, 2007 at 12:59:42PM -0500, Bill Gatliff wrote:
>   
>> Now, I'm a little rusty on PPC asm (I've been doing a lot of ARM
>> lately), but it looks to me like the kernel is setting bit 0 in CR0
>> (oris r10, r10, 0x1000) a.k.a LT, but the user side is looking at CR0
>> (bnslr+) bit 3 a.k.a. SO.  Or maybe the other way around, I'm not sure
>> after reading Sections 1.2 and 2.1 of the Programming Environments manual.
>>     
>
> It's not checking for restart here - userspace isn't supposed to have to.
> It's probably checking for error.  Check for the bit of kernel code
> that's supposed to back you up two instructions.
>
>   

I don't see it in this kernel.  What I see is this after the call to the 
syscall handler:

    li    r10,-_LAST_ERRNO
    cmpl    0,r3,r10
    blt    30f
    neg    r3,r3
    cmpi    0,r3,ERESTARTNOHAND
    bne    22f
    li    r3,EINTR
22:    lwz    r10,_CCR(r1)    /* Set SO bit in CR */
    oris    r10,r10,0x1000
    stw    r10,_CCR(r1)
30:    stw    r3,GPR3(r1)    /* Update return value */
    b    ret_from_except
66:    li    r3,ENOSYS
    b    22b


?

-- 
Bill Gatliff
bgat at billgatliff.com


From drow at false.org  Tue Jul 24 02:15:12 2007
From: drow at false.org (Daniel Jacobowitz)
Date: Mon, 23 Jul 2007 12:15:12 -0400
Subject: Gdbserver syscall clobber
In-Reply-To: <46A4D1F5.1060005@billgatliff.com>
References: <469B922D.3050701@billgatliff.com>
	<20070716155348.GA5281@caradoc.them.org>
	<469E550E.5080905@billgatliff.com>
	<20070718183143.GA25324@caradoc.them.org>
	<46A4D1F5.1060005@billgatliff.com>
Message-ID: <20070723161512.GA3235@caradoc.them.org>

On Mon, Jul 23, 2007 at 11:06:13AM -0500, Bill Gatliff wrote:
> Daniel Jacobowitz wrote:
> > On Wed, Jul 18, 2007 at 12:59:42PM -0500, Bill Gatliff wrote:
> >   
> >> Now, I'm a little rusty on PPC asm (I've been doing a lot of ARM
> >> lately), but it looks to me like the kernel is setting bit 0 in CR0
> >> (oris r10, r10, 0x1000) a.k.a LT, but the user side is looking at CR0
> >> (bnslr+) bit 3 a.k.a. SO.  Or maybe the other way around, I'm not sure
> >> after reading Sections 1.2 and 2.1 of the Programming Environments manual.
> >>     
> >
> > It's not checking for restart here - userspace isn't supposed to have to.
> > It's probably checking for error.  Check for the bit of kernel code
> > that's supposed to back you up two instructions.
> >
> >   
> 
> I don't see it in this kernel.  What I see is this after the call to the 
> syscall handler:

Look around do_signal:

                        regs->nip -= 4; /* Back up & retry system call */

If your kernel has corrupted the register containing the syscall
number at this point, that would explain your problem.  It will then
do the wrong syscall.  I guess PPC only backs up one instruction.

-- 
Daniel Jacobowitz
CodeSourcery

From schwab at suse.de  Tue Jul 24 02:19:37 2007
From: schwab at suse.de (Andreas Schwab)
Date: Mon, 23 Jul 2007 18:19:37 +0200
Subject: Gdbserver syscall clobber
In-Reply-To: <46A4D1F5.1060005@billgatliff.com> (Bill Gatliff's message of
	"Mon\, 23 Jul 2007 11\:06\:13 -0500")
References: <469B922D.3050701@billgatliff.com>
	<20070716155348.GA5281@caradoc.them.org>
	<469E550E.5080905@billgatliff.com>
	<20070718183143.GA25324@caradoc.them.org>
	<46A4D1F5.1060005@billgatliff.com>
Message-ID: <jemyxn6qjq.fsf@sykes.suse.de>

Bill Gatliff <bgat at billgatliff.com> writes:

> Daniel Jacobowitz wrote:
>> On Wed, Jul 18, 2007 at 12:59:42PM -0500, Bill Gatliff wrote:
>>   
>>> Now, I'm a little rusty on PPC asm (I've been doing a lot of ARM
>>> lately), but it looks to me like the kernel is setting bit 0 in CR0
>>> (oris r10, r10, 0x1000) a.k.a LT, but the user side is looking at CR0
>>> (bnslr+) bit 3 a.k.a. SO.

Bits are numbered from left to right, thus 0x10000000 is bit 3 of CR0

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab at suse.de
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

From scottwood at freescale.com  Tue Jul 24 04:35:11 2007
From: scottwood at freescale.com (Scott Wood)
Date: Mon, 23 Jul 2007 13:35:11 -0500
Subject: Kmalloc returns which address
In-Reply-To: <11737504.post@talk.nabble.com>
References: <e5eb93010707160659m6a7d0b02p623542739d28ab29@mail.gmail.com>
	<469B92DC.50609@freescale.com> <11737504.post@talk.nabble.com>
Message-ID: <20070723183510.GA29223@ld0162-tx32.am.freescale.net>

On Sun, Jul 22, 2007 at 08:47:47PM -0700, Misbah khan wrote:
> yes really it would really generate a machine check... but i guess if you
> convert this virt address to physical address using __pa() then pass it to
> the ioremap() i guess things will work .

What would be the point?  All you'd get is another virtual mapping.

Is the DMA mapping API that difficult?

-Scott

From clameter at sgi.com  Tue Jul 24 06:34:50 2007
From: clameter at sgi.com (Christoph Lameter)
Date: Mon, 23 Jul 2007 13:34:50 -0700
Subject: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access
	of bad area during boot with DEBUG_SLAB=y
In-Reply-To: <20070718095537.d344dc0a.akpm@linux-foundation.org>
References: <bug-8778-10286@http.bugzilla.kernel.org/>
	<20070718005253.942f0464.akpm@linux-foundation.org>
	<20070718083425.GA29722@gate.ebshome.net>
	<1184766070.3699.2.camel@zod.rchland.ibm.com>
	<20070718155940.GB29722@gate.ebshome.net>
	<20070718095537.d344dc0a.akpm@linux-foundation.org>
Message-ID: <20070723133450.3de91b33@schroedinger.engr.sgi.com>

On Wed, 18 Jul 2007 09:55:37 -0700
Andrew Morton <akpm at linux-foundation.org> wrote:

> hm.  It should be the case that providing SLAB_HWCACHE_ALIGN at
> kmem_cache_create() time will override slab-debugging's offsetting
> of the returned addresses.


That is true for SLUB but not in SLAB. SLAB has always ignored
SLAB_HWCACHE_ALIGN when debugging is on because of the issues involved
in placing the redzone values etc.  Could be fun to fix.


From domen.puncer at telargo.com  Tue Jul 24 15:14:31 2007
From: domen.puncer at telargo.com (Domen Puncer)
Date: Tue, 24 Jul 2007 07:14:31 +0200
Subject: [PATCH] i2c-mpc: don't disable I2C module on stop condition.
In-Reply-To: <Pine.LNX.4.60.0707210154330.3946@poirot.grange>
References: <20070709071955.GD4186@moe.telargo.com>
	<Pine.LNX.4.60.0707210154330.3946@poirot.grange>
Message-ID: <20070724051431.GF4529@moe.telargo.com>

Disabling module on stop doesn't work on some CPUs (ie. mpc8241,
as reported by Guennadi Liakhovetski), so remove that.

Disable I2C module on errors/interrupts to prevent it from
locking up on mpc5200b.


Signed-off-by: Domen Puncer <domen.puncer at telargo.com>
---
Hi!

So I fixed i2c on one board, and broke it on another :-(
This patch works on both Guennadi's and mine (hey, it might break
a third one!).
Jean, can you please push this, if there are no objections
and "doesn't work for me" reports.


	Domen


 drivers/i2c/busses/i2c-mpc.c |    9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

Index: work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
===================================================================
--- work-powerpc.git.orig/drivers/i2c/busses/i2c-mpc.c
+++ work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
@@ -105,6 +105,7 @@ static int i2c_wait(struct mpc_i2c *i2c,
 			schedule();
 			if (time_after(jiffies, orig_jiffies + timeout)) {
 				pr_debug("I2C: timeout\n");
+				writeccr(i2c, 0);
 				result = -EIO;
 				break;
 			}
@@ -116,10 +117,12 @@ static int i2c_wait(struct mpc_i2c *i2c,
 		result = wait_event_interruptible_timeout(i2c->queue,
 			(i2c->interrupt & CSR_MIF), timeout * HZ);
 
-		if (unlikely(result < 0))
+		if (unlikely(result < 0)) {
 			pr_debug("I2C: wait interrupted\n");
-		else if (unlikely(!(i2c->interrupt & CSR_MIF))) {
+			writeccr(i2c, 0);
+		} else if (unlikely(!(i2c->interrupt & CSR_MIF))) {
 			pr_debug("I2C: wait timeout\n");
+			writeccr(i2c, 0);
 			result = -ETIMEDOUT;
 		}
 
@@ -172,7 +175,6 @@ static void mpc_i2c_start(struct mpc_i2c
 static void mpc_i2c_stop(struct mpc_i2c *i2c)
 {
 	writeccr(i2c, CCR_MEN);
-	writeccr(i2c, 0);
 }
 
 static int mpc_write(struct mpc_i2c *i2c, int target,
@@ -261,6 +263,7 @@ static int mpc_xfer(struct i2c_adapter *
 	while (readb(i2c->base + MPC_I2C_SR) & CSR_MBB) {
 		if (signal_pending(current)) {
 			pr_debug("I2C: Interrupted\n");
+			writeccr(i2c, 0);
 			return -EINTR;
 		}
 		if (time_after(jiffies, orig_jiffies + HZ)) {

From misbah_khan at engineer.com  Tue Jul 24 17:03:33 2007
From: misbah_khan at engineer.com (Misbah khan)
Date: Tue, 24 Jul 2007 00:03:33 -0700 (PDT)
Subject: Kmalloc returns which address
In-Reply-To: <469B92DC.50609@freescale.com>
References: <e5eb93010707160659m6a7d0b02p623542739d28ab29@mail.gmail.com>
	<469B92DC.50609@freescale.com>
Message-ID: <11757911.post@talk.nabble.com>


Hi Scott

The while idea behind my logic was something this :-

 Conver the physical address into virtual address and every time you read or
write to that virtual you are reading or writing to the physical address.
For that i suggested for ioremap(), some may suggest for __pa() to translate
the physical address to logical address. The whole idea behind this is to
make the task much easy and less complicated as if you are working on memory
mapped address.

DMA operation will make the application process to access the device
directly this i guess is little more complicated in implimentation and
passing a pointer to the application is a serious security concern untill
and unless only one thread is accessing .

well i will try this with a test driver as soon as i get the free time and
let you know with the findings

Thanks 
Misbah  

Scott Wood-2 wrote:
> 
> suresh suresh wrote:
>> I want know the address return by kmalloc function? is it physical
>> address
>> or kernel virtual address.
> 
> Kernel virtual.
> 
>> For Tx and Rx, hardware uses buffers, so I have to allocate buffers and 
>> pass
>> the pointer to hardware. Can I pass the pointer returned kmalloc?  or  I
>> should convert it into physical address?
> 
> You need to convert it; read Documentation/DMA-mapping.txt.
> 
> -Scott
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 

-- 
View this message in context: http://www.nabble.com/Kmalloc-returns-which-address-tf4086826.html#a11757911
Sent from the linuxppc-embedded mailing list archive at Nabble.com.


From misbah_khan at engineer.com  Tue Jul 24 17:31:59 2007
From: misbah_khan at engineer.com (Misbah khan)
Date: Tue, 24 Jul 2007 00:31:59 -0700 (PDT)
Subject: Interrupts on xilinx ml403
In-Reply-To: <11708607.post@talk.nabble.com>
References: <11708607.post@talk.nabble.com>
Message-ID: <11758237.post@talk.nabble.com>


hi ..

If you could send me the code and the config related doc . I could then be
able to suggest you something. As per the understanding of the problem i
guess you are not congiguring the interrupt controller properly. you have to
use correct IRQ no for  that ports then other configuration such as
interrupt type, and whenever you service the interrupt you have to clear the
interrupt etc are to be taken care ....Please see the interrupt controller
register and do your settings correctly . If the same persists then you
please send me the code and the documents then only i could give the exact
explaination on this 

----misbah

Mirek23 wrote:
> 
> Dear All,
> 
>       I use linux kernel 2.6 on ppc405 of my Avnet (xilinx like ml403)
> evaluation board.
> 
> I have setup the virtex-4 FPGA to deal with Themac and Serial interfaces.
> As input/output devices I have chosen 8 LEDs and DIP Switches.
> 
> With such a configuration I am able to control from Linux user
> applications via GPIO driver the LEDs and DIP Switches.
> 
> Right now I just wanted to make use of the interrupts. I have configured
> the Dip switches to use interrupt. The interrupt accoures when the DIP
> Switches state has changed.
> 
> In the BSP generated by EDK 9.1 I see that macro :   
> 
> #define XPAR_DIP_SWITCHES_8BIT_INTERRUPT_PRESENT 1
> 
> has changed from zero to one.
> The macro XPAR_INTC_MAX_NUM_INTR_INPUTS is set to 1 as it was before. This
> is due to the fact that 
> TEMAC uses one interrupt line.
> 
> Does it mean that DIP Switches do not use INTC interrupt controller?
> How to handle the DIP Switches interrupt?
> Does the Interrupt handler routine have to acknowledge the interrupt from
> Dip Switches?
> 
> Many thanks in advance for any hint on that.
> 
> Best Regards
> 
> Mirek
> 
> 
> 
> 
>  
> 

-- 
View this message in context: http://www.nabble.com/Interrupts-on-xilinx-ml403-tf4117226.html#a11758237
Sent from the linuxppc-embedded mailing list archive at Nabble.com.


From gerrit.vandevelde at gmail.com  Tue Jul 24 17:33:33 2007
From: gerrit.vandevelde at gmail.com (Gerrit Van de Velde)
Date: Tue, 24 Jul 2007 09:33:33 +0200
Subject: [U-Boot-Users] MPC8540, UPM Writeburst generating also read bursts
In-Reply-To: <46A51C3F.2070408@anagramm.de>
References: <d07a51700707200345g48ae4585wdfe55b02569a6a07@mail.gmail.com>
	<46A09CF1.1050705@anagramm.de>
	<d07a51700707230805u347feb73sf97c45676882f89e@mail.gmail.com>
	<46A51C3F.2070408@anagramm.de>
Message-ID: <d07a51700707240033t7ca17dc1ic6c24c708405b78a@mail.gmail.com>

Hello again,

> Please don't top-post and please don't remove the list. (use reply-to-all)
> (and please move this thread over to linuxppc-embedded, as we are OT here)

Ok, I'll never do that again. And the topic has been moved.

> You don't have single read and write instructions in your UPM?
> Please post your UPM table.

I do have single reads and writes. The UPM is as follows (taken from
the upmtool output)

/* MxMR Configuration Code */
unsigned long MAMR = 0x40000;
unsigned long MBMR = 0x40000;
unsigned long MCMR = 0x40000;

/* UPM Table Configuration Code */
static unsigned long UPMATable[] =
{
	0x0faffc00,  0x0faffc00,  0x0fafdc04,  0x3fbffc01, //Words 0 to 3
	0xfffffc00,  0xfffffc00,  0xfffffc00,  0xfffffc00, //Words 4 to 7
	0x0ffffc00,  0x0ffffc00,  0x0ffffc0c,  0x0ffffc0c, //Words 8 to 11
	0x0ffffc0c,  0x0ffffc0c,  0x0ffffc0c,  0x0ffffc0c, //Words 12 to 15
	0x0ffffc0c,  0x0ffffc04,  0x3ffffc01,  0xfffffc00, //Words 16 to 19
	0xfffffc00,  0xfffffc00,  0xfffffc00,  0xfffffc00, //Words 20 to 23
	0x0fa3fc00,  0x0fa3fc00,  0x0fa3fc04,  0x3fb7fc01, //Words 24 to 27
	0xfffffc00,  0xfffffc00,  0xfffffc00,  0xfffffc00, //Words 28 to 31
	0x0ff3fc00,  0x0ff3fc00,  0x0ff3fc0c,  0x0ff3fc0c, //Words 32 to 35
	0x0ff3fc0c,  0x0ff3fc0c,  0x0ff3fc0c,  0x0ff3fc0c, //Words 36 to 39
	0x0ff3fc0c,  0x0ff3fc04,  0x3ff7fc00,  0xfffffc01, //Words 40 to 43
	0xfffffc00,  0xfffffc00,  0xfffffc00,  0xfffffc01, //Words 44 to 47
	0xfffffc00,  0xfffffc01,  0xfffffc00,  0xfffffc00, //Words 48 to 51
	0xfffffc00,  0xfffffc00,  0xfffffc00,  0xfffffc00, //Words 52 to 55
	0xfffffc00,  0xfffffc00,  0xfffffc00,  0xfffffc01, //Words 56 to 59
	0xfffffc00,  0xfffffc01,  0xfffffc00,  0xfffffc01  //Words 60 to 63
};

> Do you access the DDR memory aligned in 32byte cacheline sizes?
> The UPM propably cannot burst unaligned chunks properly.
> (I'm not sure about that, comments are welcome).
> 500MBit/s should be easy to handle with the UPM, if done right.

Yes target addresses are aligned to 32 byte words. I 'm not sure what
you mean with cachelines.

> 1) It makes sense to use the DMA to offload the CPU for copying bulk
> data if the CPU can be used for other stuff.

Ok, but currently our MPC8540 is a bit overkill, maybe later in the
life of our board it will be come necessary but at least not now.

> 2) Can you first make sure that your Gbit link is working fine by copying
> data from/to the CPU's memory without using the UPM?

That's something I should try first indeed, I'll update you/the list
if I know about the results

> I guess you will need to post more information about your
> system (schematics, code, UPM)...

I'll do that when UPM-less writes are much faster and you don't see
anything strange in the UPM table.

Regards,
Gerrit Van de Velde

From dhlii at dlasys.net  Tue Jul 24 18:18:02 2007
From: dhlii at dlasys.net (David H. Lynch Jr.)
Date: Tue, 24 Jul 2007 04:18:02 -0400
Subject: Circular queue
Message-ID: <46A5B5BA.2080707@dlasys.net>

    Is there a standard linux datastructure and routines to manage
circular queues ?

    I have a device that is not fundimentally different from a serial
character device
    except it is faster and the fundimental data type is 36 bits large.

    I have coded my own routines to setup and maintain a simple circular
queue,
    but I was hoping that there might be something more standard that
already exists.

    Anyone know of anything ?
   

   





-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii at dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 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


From misbah_khan at engineer.com  Tue Jul 24 19:19:12 2007
From: misbah_khan at engineer.com (misbah khan)
Date: Tue, 24 Jul 2007 04:19:12 -0500
Subject: Linuxppc-embedded Digest, Vol 35, Issue 51
Message-ID: <20070724091912.98B0C478077@ws1-5.us4.outblaze.com>

Can you please check the data format . PPC works on BigEndian format.
Please do this and let me know ....  --- misbah

  ----- Original Message -----
  From: linuxppc-embedded-request at ozlabs.org
  To: linuxppc-embedded at ozlabs.org
  Subject: Linuxppc-embedded Digest, Vol 35, Issue 51
  Date: Tue, 24 Jul 2007 12:00:02 +1000


  Send Linuxppc-embedded mailing list submissions to
  linuxppc-embedded at ozlabs.org

  To subscribe or unsubscribe via the World Wide Web, visit
  https://ozlabs.org/mailman/listinfo/linuxppc-embedded
  or, via email, send a message with subject or body 'help' to
  linuxppc-embedded-request at ozlabs.org

  You can reach the person managing the list at
  linuxppc-embedded-owner at ozlabs.org

  When replying, please edit your Subject line so it is more specific
  than "Re: Contents of Linuxppc-embedded digest..."


  Today's Topics:

  1. Re: Gdbserver syscall clobber (Andreas Schwab)
  2. Re: Kmalloc returns which address (Scott Wood)
  3. Re: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports
  access of bad area during boot with DEBUG_SLAB=y (Christoph Lameter)


  ----------------------------------------------------------------------

  Message: 1
  Date: Mon, 23 Jul 2007 18:19:37 +0200
  From: Andreas Schwab
  Subject: Re: Gdbserver syscall clobber
  To: Bill Gatliff
  Cc: gdb at sourceware.org, linuxppc-embedded at ozlabs.org
  Message-ID:
  Content-Type: text/plain; charset=iso-8859-1

  Bill Gatliff writes:

  > Daniel Jacobowitz wrote:
  >> On Wed, Jul 18, 2007 at 12:59:42PM -0500, Bill Gatliff wrote:
  >>
  >>> Now, I'm a little rusty on PPC asm (I've been doing a lot of ARM
  >>> lately), but it looks to me like the kernel is setting bit 0 in
  CR0
  >>> (oris r10, r10, 0x1000) a.k.a LT, but the user side is looking at
  CR0
  >>> (bnslr+) bit 3 a.k.a. SO.

  Bits are numbered from left to right, thus 0x10000000 is bit 3 of CR0

  Andreas.

  --
  Andreas Schwab, SuSE Labs, schwab at suse.de
  SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
  PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276
  4ED5
  "And now for something completely different."


  ------------------------------

  Message: 2
  Date: Mon, 23 Jul 2007 13:35:11 -0500
  From: Scott Wood
  Subject: Re: Kmalloc returns which address
  To: Misbah khan
  Cc: linuxppc-embedded at ozlabs.org
  Message-ID: <20070723183510.GA29223 at ld0162-tx32.am.freescale.net>
  Content-Type: text/plain; charset=us-ascii

  On Sun, Jul 22, 2007 at 08:47:47PM -0700, Misbah khan wrote:
  > yes really it would really generate a machine check... but i guess
  if you
  > convert this virt address to physical address using __pa() then
  pass it to
  > the ioremap() i guess things will work .

  What would be the point? All you'd get is another virtual mapping.

  Is the DMA mapping API that difficult?

  -Scott


  ------------------------------

  Message: 3
  Date: Mon, 23 Jul 2007 13:34:50 -0700
  From: Christoph Lameter
  Subject: Re: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports
  access of bad area during boot with DEBUG_SLAB=y
  To: Andrew Morton
  Cc: netdev at vger.kernel.org, bart.vanassche at gmail.com,
  linux-mm at kvack.org, "bugme-daemon at kernel-bugs.osdl.org"
  , linuxppc-embedded at ozlabs.org
  Message-ID: <20070723133450.3de91b33 at schroedinger.engr.sgi.com>
  Content-Type: text/plain; charset=US-ASCII

  On Wed, 18 Jul 2007 09:55:37 -0700
  Andrew Morton wrote:

  > hm. It should be the case that providing SLAB_HWCACHE_ALIGN at
  > kmem_cache_create() time will override slab-debugging's offsetting
  > of the returned addresses.


  That is true for SLUB but not in SLAB. SLAB has always ignored
  SLAB_HWCACHE_ALIGN when debugging is on because of the issues
  involved
  in placing the redzone values etc. Could be fun to fix.



  ------------------------------

  _______________________________________________
  Linuxppc-embedded mailing list
  Linuxppc-embedded at ozlabs.org
  https://ozlabs.org/mailman/listinfo/linuxppc-embedded

  End of Linuxppc-embedded Digest, Vol 35, Issue 51
  *************************************************

-- 
We've Got Your Name at http://www.mail.com!
Get a FREE E-mail Account Today - Choose From 100+ Domains

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070724/f39cab49/attachment-0001.htm 

From nethra_gmit at yahoo.co.in  Tue Jul 24 21:41:34 2007
From: nethra_gmit at yahoo.co.in (Nethra)
Date: Tue, 24 Jul 2007 04:41:34 -0700 (PDT)
Subject: ask some questions about u-boot's bootm command
In-Reply-To: <200707221539215465156@163.com>
References: <200707221539215465156@163.com>
Message-ID: <11761280.post@talk.nabble.com>


can u send me output of printenv in boot loader..?

Nethra

poorbeyond wrote:
> 
> my cpu is 860T, using bootm command boot a linux kernel image, the
> following message print by smc1:
> 
> bootm 300000
> 
> ## Booting image at 00300000 ...
>    Image Name:   Linux-2.6.20.14
>    Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>    Data Size:    1081591 Bytes =  1 MB
>    Load Address: 00100000
>    Entry Point:  00100000
>    Verifying Checksum ... OK
>    Uncompressing Kernel Image ... OK
> ## Current stack ends at 0x01D5DB10 => set upper limit to 0x00800000
> No initrd
> ## Transferring control to Linux (at address 00100000) ...
> 
> 
> 
> then, the program has no response.
> 
> i debug it througth BDM, in u-boot function "do_bootm_linux", execute at
> "kernel = (void (*)(bd_t *, ulong, ulong, ulong, ulong))hdr->ih_ep", the
> program branch to address "0x00000000", the code is shown as following:
> 00000000    mr    r31,r3
> 00000004    mr    r30,r4
> 00000008    mr    r29,r5
> 0000000C    mr    r28,r6
> 00000010    mr    r27,r7
> 00000014    bl    0x000020C8
> 00000018    mfmsr    r0
> 0000001C    ori    r0,r0,0x30
> 00000020    mtspr    SRR1,r0
> 00000024    lis    r0,0xC0002004 at h
> 00000028    ori    r0,r0,0xC0002004 at l
> 0000002C    mtspr    SRR0,r0
> 00000030    rfi
> 
> 
> my questions are:
> 
> 1. Is the code "kernel = (void (*)(bd_t *, ulong, ulong, ulong,
> ulong))hdr->ih_ep" branch right?
> 
> 2. What's the expected code after "kernel = (void (*)(bd_t *, ulong,
> ulong, ulong, ulong))hdr->ih_ep"?
> 
> 3. When the kernel run to the "boot/simple/head.s"?
> 
> 
> thanks a lot
> 
> 
> 
> 
> 
> poorbeyond
> 2007-07-22
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 

-- 
View this message in context: http://www.nabble.com/ask-some-questions-about-u-boot%27s-bootm-command-tf4124319.html#a11761280
Sent from the linuxppc-embedded mailing list archive at Nabble.com.


From miroslaw.dach at psi.ch  Wed Jul 25 01:19:06 2007
From: miroslaw.dach at psi.ch (Mirek23)
Date: Tue, 24 Jul 2007 08:19:06 -0700 (PDT)
Subject: Interrupts on xilinx ml403
In-Reply-To: <fa686aa40707200812w3427c12dwd10b08c8433af2fc@mail.gmail.com>
References: <11708607.post@talk.nabble.com>
	<fa686aa40707200812w3427c12dwd10b08c8433af2fc@mail.gmail.com>
Message-ID: <11765478.post@talk.nabble.com>


Hi Grant,

   Thanks for the suggestion. I will fix that and see what the EDK will
generate.

Best Regards

Mirek



Grant Likely-2 wrote:
> 
> On 7/20/07, Mirek23 <miroslaw.dach at psi.ch> wrote:
>> Does it mean that DIP Switches do not use INTC interrupt controller?
>> How to handle the DIP Switches interrupt?
>> Does the Interrupt handler routine have to acknowledge the interrupt from
>> Dip Switches?
> 
> It probably means that the GPIO irq out line is not hooked up to your
> INTC in the system.mhs file.
> 
> g.
> 
> -- 
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely at secretlab.ca
> (403) 399-0195
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 

-- 
View this message in context: http://www.nabble.com/Interrupts-on-xilinx-ml403-tf4117226.html#a11765478
Sent from the linuxppc-embedded mailing list archive at Nabble.com.


From miroslaw.dach at psi.ch  Wed Jul 25 01:22:00 2007
From: miroslaw.dach at psi.ch (Mirek23)
Date: Tue, 24 Jul 2007 08:22:00 -0700 (PDT)
Subject: Interrupts on xilinx ml403
In-Reply-To: <11758237.post@talk.nabble.com>
References: <11708607.post@talk.nabble.com> <11758237.post@talk.nabble.com>
Message-ID: <11765540.post@talk.nabble.com>


I will try to go further with that after trying Grant's suggestion. When I
still have a problem I will contact you.

Best Regards

Mirek

Misbah khan wrote:
> 
> hi ..
> 
> If you could send me the code and the config related doc . I could then be
> able to suggest you something. As per the understanding of the problem i
> guess you are not congiguring the interrupt controller properly. you have
> to use correct IRQ no for  that ports then other configuration such as
> interrupt type, and whenever you service the interrupt you have to clear
> the interrupt etc are to be taken care ....Please see the interrupt
> controller register and do your settings correctly . If the same persists
> then you please send me the code and the documents then only i could give
> the exact explaination on this 
> 
> ----misbah
> 
> Mirek23 wrote:
>> 
>> Dear All,
>> 
>>       I use linux kernel 2.6 on ppc405 of my Avnet (xilinx like ml403)
>> evaluation board.
>> 
>> I have setup the virtex-4 FPGA to deal with Themac and Serial interfaces.
>> As input/output devices I have chosen 8 LEDs and DIP Switches.
>> 
>> With such a configuration I am able to control from Linux user
>> applications via GPIO driver the LEDs and DIP Switches.
>> 
>> Right now I just wanted to make use of the interrupts. I have configured
>> the Dip switches to use interrupt. The interrupt accoures when the DIP
>> Switches state has changed.
>> 
>> In the BSP generated by EDK 9.1 I see that macro :   
>> 
>> #define XPAR_DIP_SWITCHES_8BIT_INTERRUPT_PRESENT 1
>> 
>> has changed from zero to one.
>> The macro XPAR_INTC_MAX_NUM_INTR_INPUTS is set to 1 as it was before.
>> This is due to the fact that 
>> TEMAC uses one interrupt line.
>> 
>> Does it mean that DIP Switches do not use INTC interrupt controller?
>> How to handle the DIP Switches interrupt?
>> Does the Interrupt handler routine have to acknowledge the interrupt from
>> Dip Switches?
>> 
>> Many thanks in advance for any hint on that.
>> 
>> Best Regards
>> 
>> Mirek
>> 
>> 
>> 
>> 
>>  
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Interrupts-on-xilinx-ml403-tf4117226.html#a11765540
Sent from the linuxppc-embedded mailing list archive at Nabble.com.


From r.schwebel at pengutronix.de  Wed Jul 25 07:11:04 2007
From: r.schwebel at pengutronix.de (Robert Schwebel)
Date: Tue, 24 Jul 2007 23:11:04 +0200
Subject: support for MPC8220?
In-Reply-To: <556445368AFA1C438794ABDA8901891C066B5B56@usa0300ms03.na.xerox.net>
References: <556445368AFA1C438794ABDA8901891C066B5B56@usa0300ms03.na.xerox.net>
Message-ID: <20070724211104.GL1678@pengutronix.de>

On Mon, Jul 23, 2007 at 11:27:00AM -0400, Leisner, Martin wrote:
> Is there support for MPC8220 in current kernels?

8220? Are you sure? That part doesn't exist on the freescale site.

Robert 
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9


From dhlii at dlasys.net  Tue Jul 24 19:14:45 2007
From: dhlii at dlasys.net (David H. Lynch Jr.)
Date: Tue, 24 Jul 2007 05:14:45 -0400
Subject: [PATCH] Xilinx TEMAC driver
Message-ID: <46A5C305.5000903@dlasys.net>

    Hopefully this is not too much of a mess.

    This is a very preliminary patch to add support for the Xilinx TEMAC.
    This is closer approximation to a normal linux driver.
    There are no external dependencies aside from a properly setup
xparameters.h and
    platform data structure for the TEMAC - i.e. no need for xilinx_edk,
xilinx_common, ...
    The whole driver is in a single source file.
    It autonegotiates, and it actually works in some Pico Firmware where
the MV/Xilinx driver does not.
   
    Somewhere long ago this started out based on the Xilinx code from
the Trek Webserver sample.
    As such it is also losely based on the xilinx_edk code.
    Hopefully, I remembered to provide proper attribution. This is
preliminary so things like that will get fixed.
    It includes support for the LocalLink TEMAC, though the LL_TEMAC
performance is poor, and I could not figure
    out anyway to make it interrupt driven so it had a fairly high rate
of dropped packets.
    It ONLY supports the FIFO based PLB TEMAC. If you want SGDMA add it
or use the Xilinx/MV driver.

    There is alot of cruft in the driver that needs yanked, bits and
peices of #ifdefed out code from the xilinx EDK or ldd3
    or whatever I thought I needed, and have not yet been willing to delete.

    I am also using dman near the same identical source for a TEMAC
driver for GreenHills, and there are likely some
    #ifdef's that only make sense in that context.

    At somepoint I will try to clean all of the above crap out.

    I also need to clean up my git tree so that I can produce a proper
patch.

    Enough caveats - patch follows.


   

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 7d57f4a..fe5aa83 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2332,6 +2337,59 @@ config ATL1
 
 endif # NETDEV_1000
 
+config PICO_TEMAC
+    tristate "Pico Xilinx 10/100/1000 Mbit Local Link/PLB TEMAC support"
+    depends on XILINX_VIRTEX && !XILINX_OLD_TEMAC && !XILINX_TEMAC
+    select MII
+    select NET_POLL_CONTROLLER
+#    select PHYLIB
+    help
+      This driver supports Tri-Mode, 10/100/1000 Mbit EMAC IP
+      from Xilinx EDK.
+
+config PICO_DEBUG_TEMAC
+    bool 'Pico TEMAC Debugging'
+    default y
+    depends on PICO_TEMAC && PICO_DEBUG
+
+
 #
 #    10 Gigabit Ethernet
 #
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index a77affa..2248dd4 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -227,3 +227,8 @@ obj-$(CONFIG_NETCONSOLE) += netconsole.o
 obj-$(CONFIG_FS_ENET) += fs_enet/
 
 obj-$(CONFIG_NETXEN_NIC) += netxen/
+obj-$(CONFIG_PICO_TEMAC) += temac.o
diff --git a/drivers/net/temac.c b/drivers/net/temac.c
new file mode 100644
index 0000000..01d30c4
--- /dev/null
+++ b/drivers/net/temac.c
@@ -0,0 +1,3742 @@
+/*
+
+ linux/drivers/net/temac.c
+
+ Driver for Xilinx hard temac ethernet NIC's
+
+ Author: David H. Lynch Jr. <dhlii at dlasys.net>
+ Copyright (C) 2005 DLA Systems
+ The author may be reached as dhlii at sdlasys.net, or C/O
+       DLA Systems
+       354 Rudy Dam rd.
+       Lititz PA 17543
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2 of the License, or
+(at your option) any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program; if not, write to the Free Software
+Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ things that need looked at:
+    process_transmits
+    temac_EtherRead
+    temac_hard_start_xmit
+    ehter_reset
+    temac_get_link_status
+
+$Id: temac.c,v 0.10 2005/12/14 10:03:27 dhlii Exp $
+
+*/
+#define DRV_NAME        "temac"
+#define DRV_DESCRIPTION "Xilinx hard Tri-Mode Eth MAC driver"
+#define DRV_VERSION     "0.10a"
+#define DRV_RELDATE     "07/10/2006"
+
+#if defined(__KERNEL__)
+#define LINUX 1
+#endif
+static const char version[] = DRV_NAME ".c:v" DRV_VERSION " "
DRV_RELDATE "  David H. Lynch Jr. (dhlii at dlasys.net)\n";
+
+#if defined(LINUX)
+#include <linux/module.h>
+#include <linux/ioport.h>
+#include <linux/netdevice.h>
+#include <linux/etherdevice.h>
+#include <linux/init.h>
+#include <linux/skbuff.h>
+#include <linux/spinlock.h>
+#include <linux/crc32.h>
+
+#include <linux/mii.h>
+#include <linux/delay.h>
+#include <linux/platform_device.h>
+#include <linux/xilinx_devices.h>
+#include <linux/ethtool.h>
+#include <asm/delay.h>
+#include <asm/irq.h>
+#include <asm/io.h>
+
+#define FRAME_ALIGNMENT                 8                       /* Byte
alignment of ethernet frames */
+typedef char EthFrame[9000] __attribute__ ((aligned(FRAME_ALIGNMENT)));
+
+#define TRUE                                    1
+#define FALSE                                   0
+
+#define TEMAC_RX_TIMEOUT            (jiffies + ((1 * HZ)/5))
+#define TEMAC_TX_TIMEOUT            (jiffies + (2 * HZ))
+#define TEMAC_MII_TIMEOUT           (jiffies + (2 * HZ))    /* timer
wakeup time : 2 second */
+
+/*
+Transmit timeout, default 5 seconds.
+ */
+static int
+watchdog = 5000;
+module_param(watchdog, int, 0400);
+MODULE_PARM_DESC(watchdog, "transmit timeout in milliseconds");
+
+static struct platform_device *temac_device;
+
+/* for exclusion of all program flows (processes, ISRs and BHs) */
+DEFINE_SPINLOCK(XTE_spinlock);
+#define res_size(_r) (((_r)->end - (_r)->start) + 1)
+#define EnetDbPrint(dev,msg)
+#define Success 0
+#define Failure -1
+#define Error int
+
+
+#else
+
+#define EIO             500
+
+// additional MII defines
+#define MII_BMCR            0x00        /* Basic mode control register */
+#define BMCR_ANRESTART          0x0200  /* Auto negotiation restart    */
+#define BMCR_ANENABLE           0x1000  /* Enable auto negotiation     */
+#define BMCR_RESET              0x8000  /* Reset the DP83840           */
+#define MII_BMSR            0x01        /* Basic mode status register  */
+#define BMSR_LSTATUS            0x0004  /* Link status                 */
+#define MII_PHYSID1         0x02        /* PHYS ID 1                   */
+#define MII_PHYSID2         0x03        /* PHYS ID 2                   */
+#define MII_ADVERTISE       0x04        /* Advertisement control reg   */
+#define ADVERTISE_CSMA          0x0001  /* Only selector supported     */
+#define ADVERTISE_10FULL        0x0040  /* Try for 10mbps full-duplex  */
+#define ADVERTISE_100FULL       0x0100  /* Try for 100mbps full-duplex */
+#define MII_LPA             0x05        /* Link partner ability reg    */
+#define MII_EXPANSION       0x06        /* Expansion register          */
+
+#define MII_CTRL1000        0x09        /* 1000BASE-T control          */
+#define ADVERTISE_1000FULL      0x0200  /* Advertise 1000BASE-T full
duplex */
+#define MII_STAT1000        0x0a        /* 1000BASE-T status           */
+#define MII_ESTATUS     0x0f    /* Extended Status */
+#define MII_DCOUNTER        0x12        /* Disconnect counter          */
+#define MII_FCSCOUNTER      0x13        /* False carrier counter       */
+#define MII_NWAYTEST        0x14        /* N-way auto-neg test reg     */
+#define MII_RERRCOUNTER     0x15        /* Receive error counter       */
+#define MII_SREVISION       0x16        /* Silicon revision            */
+#define MII_RESV1           0x17        /* Reserved...                 */
+#define MII_LBRERROR        0x18        /* Lpback, rx, bypass error    */
+#define MII_PHYADDR         0x19        /* PHY address                 */
+#define MII_RESV2           0x1a        /* Reserved...                 */
+#define MII_TPISTATUS       0x1b        /* TPI status for 10mbps       */
+#define MII_NCONFIG         0x1c        /* Network interface config    */
+
+#define MAX_TEMAC_DEVS  2
+
+#ifndef NUM_TX_BDS
+# define NUM_TX_BDS 32
+#endif
+#ifndef NUM_RX_BDS
+# define NUM_RX_BDS 32
+#endif
+
+
+#include "miiphy.h"
+#include "enet_iodevice.h"
+#include "interrupt.h"
+#include "interruptcontroller.h"
+#include "cksum.h"
+#include <string.h>
+
+#define spin_lock(lock)
+#define spin_unlock(lock)
+#define spin_lock_irqsave(lock, flags)
+#define spin_unlock_irqrestore(lock, flags)
+int is_valid_ether_addr(const UINT1 *addr);
+// #define is_valid_ether_addr(addr) 0          // this is in Pico BSP now
+#define mfdcr(addr)             -1
+#define mtdcr(addr,val)
+#define netif_wake_queue(lp)    0
+#define netif_stop_queue(lp)    0
+#define netif_rx(lp)            0
+#define printk_ratelimit()      0
+#define eth_type_trans(skb, lp) 0
+typedef unsigned long   spinlock_t;
+typedef unsigned long   irqreturn_t;
+#define IRQ_HANDLED EVENT_HANDLED
+
+
+
+#define MAX_CACHE_LINE_SIZE     64
+
+#define NUM_RX_EVENTS   (NUM_RX_BDS)
+#define NUM_TX_EVENTS   (NUM_TX_BDS * 2)
+
+#ifndef NUM_CLOSE_ACTIONS
+# define NUM_CLOSE_ACTIONS 32
+#endif
+
+#ifndef MAXMOVELEN
+# define MAXMOVELEN 12800
+#endif
+
+#define MINIMUM_PACKET_LENGTH 64
+
+typedef unsigned long   u32;
+typedef unsigned int    u16;
+typedef unsigned char   u8;
+
+/*
+ *  Network device statistics. Akin to the 2.0 ether stats but
+ *  with byte counters.
+ */
+
+struct net_device_stats
+{
+    unsigned long   rx_packets;     /* total packets received   */
+    unsigned long   tx_packets;     /* total packets transmitted    */
+    unsigned long   rx_bytes;       /* total bytes received     */
+    unsigned long   tx_bytes;       /* total bytes transmitted  */
+    unsigned long   rx_errors;      /* bad packets received     */
+    unsigned long   tx_errors;      /* packet transmit problems */
+    unsigned long   rx_dropped;     /* no space in linux buffers    */
+    unsigned long   tx_dropped;     /* no space available in linux  */
+    unsigned long   multicast;      /* multicast packets received   */
+    unsigned long   collisions;
+
+    /* detailed rx_errors: */
+    unsigned long   rx_length_errors;
+    unsigned long   rx_over_errors;     /* receiver ring buff overflow  */
+    unsigned long   rx_crc_errors;      /* recved pkt with crc error    */
+    unsigned long   rx_frame_errors;    /* recv'd frame alignment error */
+    unsigned long   rx_fifo_errors;     /* recv'r fifo overrun      */
+    unsigned long   rx_missed_errors;   /* receiver missed packet   */
+
+    /* detailed tx_errors */
+    unsigned long   tx_aborted_errors;
+    unsigned long   tx_carrier_errors;
+    unsigned long   tx_fifo_errors;
+    unsigned long   tx_heartbeat_errors;
+    unsigned long   tx_window_errors;
+   
+    /* for cslip etc */
+    unsigned long   rx_compressed;
+    unsigned long   tx_compressed;
+};
+
+struct timer_list
+{
+    unsigned long   rx_packets;     /* total packets received   */
+};
+
+#define SKB_RX      (1 << 0)
+#define SKB_TX      (1 << 1)
+#define SKB_INUSE   (1 << 2)
+#define SKB_ALLOC   (1 << 3)
+#define SKB_FULL    (1 << 4)
+#define SKB_PAD     (1 << 5)
+
+struct sk_buff {
+        UINT4           flags;          // asorted flag bits
+        UINT4           fifo_data;      // fifo address
+        UINT4           fifo_reg;       // fifo address
+        UINT4           size;
+        UINT4           len;                    // Owner, Status,
Buffer Length      
+        UINT4           user;                   // values from ghs     
+        UINT4           user_data;              // value from ghs
+        UINT4           protocol;  
+        struct temac_local *    dev;
+            unsigned char       *data;
+            unsigned char       *tail;
+} ;
+
+#define net_device temac_local
+#define jiffies 0
+#endif
+
+// board types
+#define TEMAC_LL                                0
+#define TEMAC_PLB                               1
+
+#define PHY_DCR                                 1
+
+#define ALIGNMENT_SEND                          8
+#define ALIGNMENT_RECV                          8
+
+#define MII_ANI                                 0x10
+#define PHY_NUM                                 0
+
+#define MII_SSR                                 0x11
+#define MII_SSR_LINK                                    (1 << 10)
+#define MII_SSR_SPDMASK                         0xC000
+#define MII_SSR_SPD1000                                 (1 << 15)
+#define MII_SSR_SPD100                                  (1 << 14)
+#define MII_SSR_SPD10                                   0
+#define MII_SSR_FD                                      (1 << 13)
+
+#define MII_ISR                     0x13
+
+// packet size info
+#define XTE_MTU                         1500                    /* max
MTU size of Ethernet frame */
+#define XTE_HDR_SIZE                    14                      /* size
of Ethernet header */
+#define XTE_TRL_SIZE                    4                       /* size
of Ethernet trailer (FCS) */
+#define XTE_MAX_FRAME_SIZE              (XTE_MTU + XTE_HDR_SIZE +
XTE_TRL_SIZE)
+
+#define TIMEOUT_ERROR                   -1
+#define SRC_RDY_TIMEOUT_ERROR           -2
+#define SOF_TIMEOUT_ERROR               -3
+#define UNKNOWN_ERROR                   -4
+
+#define XST_FAILURE                     1L
+#define XST_DEVICE_NOT_FOUND            2L
+#define XST_DEVICE_IS_STARTED           5L
+#define XST_DEVICE_IS_STOPPED           6L
+#define XST_FIFO_ERROR                  7L                      /* an
error occurred during an operation with a FIFO such as an underrun or
overrun, this error requires the device to be reset */
+#define XST_NOT_POLLED                  10L                     /* the
device is not configured for polled mode operation */
+#define XST_FIFO_NO_ROOM                11L                     /* a
FIFO did not have room to put the specified data into */
+#define XST_NO_DATA                     13L                     /*
there was no data available */
+#define XST_NO_FEATURE                  19L                     /*
device is not configured with the requested feature */
+#define XST_DATA_LOST                   26L                     /*
driver defined error */
+#define XST_RECV_ERROR                  27L                     /*
generic receive error */
+#define XST_SEND_ERROR                  28L                     /*
generic transmit error */
+#define XST_PFIFO_ERROR                 504L                    /*
generic packet FIFO error */
+#define XST_PFIFO_DEADLOCK              505L                    /*
packet FIFO is reporting * empty and full simultaneously */
+#define XST_IPIF_ERROR                  541L                    /*
generic ipif error */
+
+
+
+/**  Configuration options
+ *
+ * Device configuration options. See the temac_setoptions(),
+ * XTemac_ClearOptions() and XTemac_GetOptions() for information on how
to use
+ * options.
+ *
+ * The default state of the options are noted and are what the device
and driver
+ * will be set to after calling XTemac_Reset() or XTemac_Initialize().
+ *
+ */
+
+#define XTE_PROMISC_OPTION                      (1 << 0)        /**<
Accept all incoming packets. This option defaults to disabled (cleared) */
+#define XTE_JUMBO_OPTION                        (1 << 1)        /**<
Jumbo frame support for Tx & Rx. This option defaults to disabled
(cleared) */
+#define XTE_VLAN_OPTION                         (1 << 2)        /**<
VLAN Rx & Tx frame support.  This option defaults to disabled (cleared) */
+#define XTE_FLOW_CONTROL_OPTION                 (1 << 4)        /**<
Enable recognition of flow control frames on Rx This option defaults to
enabled (set) */
+#define XTE_FCS_STRIP_OPTION                    (1 << 5)        /**<
Strip FCS and PAD from incoming frames. Note: PAD from VLAN frames is
not stripped.  This option defaults to disabled (set) */
+#define XTE_FCS_INSERT_OPTION                   (1 << 6)        /**<
Generate FCS field and add PAD automatically for outgoing frames.  This
option defaults to enabled (set) */
+#define XTE_LENTYPE_ERR_OPTION                  (1 << 7)        /**<
Enable Length/Type error checking for incoming frames. When this option is
+                                                                    
set, the MAC will filter frames that have a mismatched type/length field
+                                                                    
and if XTE_REPORT_RXERR_OPTION is set, the user is notified when these
+                                                                    
types of frames are encountered. When this option is cleared, the MAC will
+                                                                    
allow these types of frames to be received.
+                                                                    
This option defaults to enabled (set) */
+#define XTE_POLLED_OPTION                       (1 << 9)        /**<
Polled mode communications.
+                                                                    
Users may enter/exit polled mode
+                                                                    
from any interrupt driven mode.
+                                                                    
This option defaults to disabled (cleared) */
+
+#define XTE_REPORT_RXERR_OPTION                 (1 << 10)       /**<
Enable reporting of dropped receive packets due to errors This option
defaults to enabled (set) */
+#define XTE_TRANSMITTER_ENABLE_OPTION           (1 << 11)       /**<
Enable the transmitter.  This option defaults to enabled (set) */
+#define XTE_RECEIVER_ENABLE_OPTION              (1 << 12)       /**<
Enable the receiver This option defaults to enabled (set) */
+#define XTE_BROADCAST_OPTION                    (1 << 13)       /**<
Allow reception of the broadcast address This option defaults to enabled
(set) */
+#define XTE_MULTICAST_CAM_OPTION                (1 << 14)       /**<
Allows reception of multicast addresses programmed into CAM This option
defaults to disabled (clear) */
+#define XTE_REPORT_TXSTATUS_OVERRUN_OPTION      (1 << 15)       /**<
Enable reporting the overrun of the Transmit status FIFO. This type of
+                                                                    
error is latched by HW and can be cleared only by a reset. SGDMA systems,
+                                                                    
this option should be enabled since the DMA engine is responsible for
+                                                                    
keeping this from occurring. For FIFO direct systems, this error may be
+                                                                     a
nuisance because a SW system may be able to transmit frames faster
+                                                                    
than the interrupt handler can handle retrieving statuses.
+                                                                    
This option defaults to enabled (set) */
+#define XTE_ANEG_OPTION                         (1 << 16)       /**<
Enable autonegotiation interrupt This option defaults to disabled (clear) */
+
+#define XTE_DEFAULT_OPTIONS                     \
+    (XTE_FLOW_CONTROL_OPTION |                  \
+     XTE_BROADCAST_OPTION |                     \
+     XTE_FCS_INSERT_OPTION |                    \
+     XTE_FCS_STRIP_OPTION |                     \
+     XTE_LENTYPE_ERR_OPTION |                   \
+     XTE_TRANSMITTER_ENABLE_OPTION |            \
+     XTE_REPORT_RXERR_OPTION |                  \
+     XTE_REPORT_TXSTATUS_OVERRUN_OPTION |       \
+     XTE_RECEIVER_ENABLE_OPTION)                                /**<
Default options set when device is initialized or reset */
+
+
+#define XTE_END_OF_PACKET                   1                   /**<
The data written is the last for the *  current packet */
+#define XTE_PARTIAL_PACKET                  0                   /**<
There is more data to come for the *  current packet */
+
+//------------------------------------------------
+
+#define PHY_TIMEOUT                         10000
+
+/**  Register offsets
+ *
+ * These constants define the offsets to each of the registers from the
+ * register base address, each of the constants are a number of bytes
+ */
+#define XPF_V200A_RESET_REG_OFFSET          0UL                    
/**< Reset register */
+#define XPF_V200A_COUNT_STATUS_REG_OFFSET   4UL                    
/**< Count/Status register */
+
+#define XPF_V200A_RESET_FIFO_MASK           0x0000000A              /**
* This constant is used with the Reset Register */
+
+/**  Occupancy/Vacancy Count Register constants
+ */
+/** Constant used with the Occupancy/Vacancy Count Register. This
+ *  register also contains FIFO status
+ */
+#define XPF_V200A_COUNT_MASK            0x00FFFFFF
+
+
+/************************** Constant Definitions
*****************************/
+
+#define XTE_RESET_IPIF_DELAY_US         1                       /**<
Number of Us to delay after IPIF reset */
+
+/* Register offset definitions. Unless otherwise noted, register access
is 32 bit.  */
+/**  IPIF interrupt and reset registers */
+#define XTE_DISR_OFFSET                 0x00000000              /**<
Device interrupt status */
+#define XTE_DIPR_OFFSET                 0x00000004              /**<
Device interrupt pending */
+/**  Interrupt status bits for top level interrupts
+ *  These bits are associated with the XTE_DISR_OFFSET, XTE_DIPR_OFFSET,
+ *  and XTE_DIER_OFFSET registers.
+ */
+#define XTE_DXR_SEND_FIFO_MASK                  (1 << 6)        /**<
Send FIFO channel */
+#define XTE_DXR_RECV_FIFO_MASK                  (1 << 5)        /**<
Receive FIFO channel */
+#define XTE_DXR_CORE_MASK                       (1 << 2)        /**<
Core */
+#define XTE_DXR_DPTO_MASK                       (1 << 1)        /**<
Data phase timeout */
+#define XTE_DXR_TERR_MASK                       (1 << 0)        /**<
Transaction error */
+#define XTE_DIER_OFFSET                 0x00000008              /**<
Device interrupt enable */
+#define XTE_DGIE_OFFSET                 0x0000001C              /**<
Device global interrupt enable */
+#define XTE_DGIE_ENABLE_MASK                    (1 << 31)       /**<
Write this value to DGIE to enable interrupts from this device */
+#define XTE_IPISR_OFFSET                0x00000020              /**< IP
interrupt status */
+#define XTE_IPIER_OFFSET                0x00000028              /**< IP
interrupt enable */
+#define XTE_DSR_OFFSET                  0x00000040              /**<
Device software reset (write) */
+#define XTE_DSR_RESET_MASK              0x0000000A              /**<
Write this value to DSR to reset entire core */
+// #define XTE_MIR_OFFSET               0x00000040              /**<
Identification (read) */
+
+/**  Interrupt status bits for MAC interrupts
+ *  These bits are associated with XTE_IPISR_OFFSET and XTE_IPIER_OFFSET
+ *  registers.
+ *
+ */
+#define XTE_IPXR_XMIT_DONE_MASK                 (1 << 0)        /**< Tx
complete  MUST read TSR to clear */
+#define XTE_IPXR_RECV_DONE_MASK                 (1 << 1)        /**< Rx
complete  MUST read RSR to clear */
+#define XTE_IPXR_AUTO_NEG_MASK                  (1 << 2)        /**<
Auto negotiation complete */
+#define XTE_IPXR_RECV_REJECT_MASK               (1 << 3)        /**< Rx
packet rejected */
+//#define XTE_IPXR_XMIT_SFIFO_EMPTY_MASK        (1 << 4)        /**< Tx
status fifo empty */
+//#define XTE_IPXR_RECV_LFIFO_EMPTY_MASK        (1 << 5)        /**< Rx
length fifo empty */
+#define XTE_IPXR_XMIT_LFIFO_FULL_MASK           (1 << 6)        /**< Tx
length fifo full */
+#define XTE_IPXR_RECV_LFIFO_OVER_MASK           (1 << 7)        /**< Rx
length fifo overrun Note that this signal is no longer asserted by HW */
+#define XTE_IPXR_RECV_LFIFO_UNDER_MASK          (1 << 8)        /**< Rx
length fifo underrun requires RESET to clear */
+#define XTE_IPXR_XMIT_SFIFO_OVER_MASK           (1 << 9)        /**< Tx
status fifo overrun  requires RESET to clear */
+#define XTE_IPXR_XMIT_SFIFO_UNDER_MASK          (1 << 10)       /**< Tx
status fifo underrun requires RESET to clear */
+#define XTE_IPXR_XMIT_LFIFO_OVER_MASK           (1 << 11)       /**< Tx
length fifo overrun  requires RESET to clear */
+#define XTE_IPXR_XMIT_LFIFO_UNDER_MASK          (1 << 12)       /**< Tx
length fifo underrun requires RESET to clear */
+#define XTE_IPXR_RECV_PFIFO_ABORT_MASK          (1 << 13)       /**< Rx
packet rejected due to full packet FIFO */
+#define XTE_IPXR_RECV_LFIFO_ABORT_MASK          (1 << 14)       /**< Rx
packet rejected due to full length FIFO */
+#define XTE_IPXR_MII_PEND_MASK                  (1 << 15)       /**<
Mii operation now pending */
+#define XTE_IPXR_MII_DONE_MASK                  (1 << 16)       /**<
Mii operation has completed */
+#define XTE_IPXR_XMIT_PFIFO_UNDER_MASK          (1 << 17)       /**< Tx
packet FIFO underrun requires RESET to clear */
+//#define XTE_IPXR_XMIT_DMA_MASK                (1 << 19)       /**< Rx
dma channel */
+//#define XTE_IPXR_RECV_DMA_MASK                (1 << 20)       /**< Tx
dma channel */
+#define XTE_IPXR_RECV_FIFO_LOCK_MASK            (1 << 21)       /**< Rx
FIFO deadlock         requires RESET to clear */
+#define XTE_IPXR_XMIT_FIFO_LOCK_MASK            (1 << 22)       /**< Tx
FIFO deadlock         requires RESET to clear */
+
+
+#define XTE_IPXR_RECV_DROPPED_MASK                                      \
+    (XTE_IPXR_RECV_REJECT_MASK |                                        \
+     XTE_IPXR_RECV_PFIFO_ABORT_MASK |                                   \
+     XTE_IPXR_RECV_LFIFO_ABORT_MASK)                            /**<
IPXR bits that indicate a dropped receive frame */
+
+#define XTE_IPXR_RECV_ERROR_MASK                                        \
+    (XTE_IPXR_RECV_DROPPED_MASK |                                       \
+     XTE_IPXR_RECV_LFIFO_UNDER_MASK)                            /**<
IPXR bits that indicate receive errors */
+
+#define XTE_IPXR_FIFO_FATAL_ERROR_MASK                                  \
+    (XTE_IPXR_RECV_FIFO_LOCK_MASK |                                     \
+     XTE_IPXR_XMIT_FIFO_LOCK_MASK |                                     \
+     XTE_IPXR_XMIT_PFIFO_UNDER_MASK |                                   \
+     XTE_IPXR_XMIT_LFIFO_UNDER_MASK |                                   \
+     XTE_IPXR_XMIT_LFIFO_OVER_MASK |                                    \
+     XTE_IPXR_XMIT_SFIFO_UNDER_MASK |                                   \
+     XTE_IPXR_XMIT_SFIFO_OVER_MASK |                                    \
+     XTE_IPXR_RECV_LFIFO_UNDER_MASK)                            /**<
IPXR bits that indicate fatal FIFO errors. These bits can only be
cleared by a device reset */
+
+
+/**  IPIF transmit and receive packet fifo base offsets
+ *        Individual registers and bit definitions are defined in
+ *        xpacket_fifo_l_v2_00_a.h. This register group is not
accessible if
+ *        the device instance is configured for SGDMA.
+ */
+#define XTE_PFIFO_TXREG_OFFSET          0x00002000              /**<
Packet FIFO Tx channel */
+#define XTE_PFIFO_TXDATA_OFFSET         0x00002100              /**<
IPIF Tx packet fifo port */
+
+#define XTE_PFIFO_RXREG_OFFSET          0x00002010              /**<
Packet FIFO Rx channel */
+#define XTE_PFIFO_RXDATA_OFFSET         0x00002200              /**<
IPIF Rx packet fifo port */
+// #define XTE_IPIF_ISC_TXISR_OFFSET    0x00002318             
+// #define XTE_IPIF_ISC_TXIER_OFFSET    0x0000231c             
+// #define XTE_IPIF_ISC_RXISR_OFFSET    0x00002358             
+// #define XTE_IPIF_ISC_RXIER_OFFSET    0x0000235c             
+
+/**  PLB_TEMAC registers. The TPLR, TSR, RPLR, and RSR are not accessible
+ *        when a device instance is configured for SGDMA. LLPS is not
accessible
+ *        when a device instance is configured for FIFO direct.
+ */
+#define XTE_CR_OFFSET                   0x00001000              /**<  
Control Register (CR) */
+#define XTE_CR_BCREJ_MASK                   (1 << 2)            /**<
Disable broadcast address filtering */
+#define XTE_CR_MCREJ_MASK                   (1 << 1)            /**<
Disable multicast address filtering */
+#define XTE_CR_HRST_MASK                    (1 << 0)            /**<
Reset the hard TEMAC core */
+
+#define XTE_TPLR_OFFSET                 0x00001004              /**< Tx
packet length (FIFO) */
+#define XTE_TSR_OFFSET                  0x00001008              /**< Tx
status (FIFO) */
+#define XTE_TSR_TXED_MASK               0x80000000              /**<
Excess deferral error */
+#define XTE_TSR_PFIFOU_MASK             0x40000000              /**<
Packet FIFO underrun */
+#define XTE_TSR_TXLC_MASK               0x01000000              /**<
Late collision error */
+#define XTE_TSR_ERROR_MASK  (XTE_TSR_TXED_MASK | XTE_TSR_PFIFOU_MASK |
XTE_TSR_TXLC_MASK)    /**< TSR bits that indicate an error */
+#define XTE_RPLR_OFFSET                 0x0000100C              /**< Rx
packet length (FIFO) */
+#define XTE_RSR_OFFSET                  0x00001010              /**<
Receive status */
+#define XTE_TPPR_OFFSET                 0x00001014              /**< Tx
pause packet */
+// #define XTE_LLPS_OFFSET              0x00001018              /**<
LLINK PFIFO status */
+
+
+/**  HARD_TEMAC Core Registers
+ * These are registers defined within the device's hard core located in the
+ * processor block. They are accessed with the host interface. These
registers
+ * are addressed offset by XTE_HOST_IPIF_OFFSET or by the DCR base address
+ * if so configured.
+ *
+ * Access to these registers should go through macros
XIo_In32(XTE_HOST_IPIF_OFFSET+)
+ * and XIo_Out32(XTE_HOST_IPIF_OFFSET+) to guarantee proper access.
+ */
+#define XTE_HOST_IPIF_OFFSET            0x00003000              /**<
Offset of host registers when memory mapped into IPIF */
+#define XTE_RXC0_OFFSET                 0x00000200              /**< Rx
configuration word 0 */
+#define XTE_RXC1_OFFSET                 0x00000240              /**< Rx
configuration word 1 */
+//#define XTE_RXC1_RXRST_MASK               (1 << 31)           /**<
Receiver reset */
+#define XTE_RXC1_RXJMBO_MASK                (1 << 30)           /**<
Jumbo frame enable */
+#define XTE_RXC1_RXFCS_MASK                 (1 << 29)           /**<
FCS not stripped */
+#define XTE_RXC1_RXEN_MASK                  (1 << 28)           /**<
Receiver enable */
+#define XTE_RXC1_RXVLAN_MASK                (1 << 27)           /**<
VLAN enable */
+#define XTE_RXC1_RXHD_MASK                  (1 << 26)           /**<
Half duplex */
+#define XTE_RXC1_RXLT_MASK                  (1 << 25)           /**<
Length/type check disable */
+//#define XTE_RXC1_ERXC1_MASK           0x0000FFFF              /**<
Pause frame source address bits [47:32]. Bits [31:0] are stored in
register ERXC0 */
+
+#define XTE_TXC_OFFSET                  0x00000280              /**< Tx
configuration */
+#define XTE_TXC_TXRST_MASK                  (1 << 31)           /**<
Transmitter reset */
+#define XTE_TXC_TXJMBO_MASK                 (1 << 30)           /**<
Jumbo frame enable */
+#define XTE_TXC_TXFCS_MASK                  (1 << 29)           /**<
Generate FCS */
+#define XTE_TXC_TXEN_MASK                   (1 << 28)           /**<
Transmitter enable */
+#define XTE_TXC_TXVLAN_MASK                 (1 << 27)           /**<
VLAN enable */
+#define XTE_TXC_TXHD_MASK                   (1 << 26)           /**<
Half duplex */
+#define XTE_TXC_TXIFG_MASK                  (1 << 25)           /**<
IFG adjust enable */
+
+#define XTE_FCC_OFFSET                  0x000002C0              /**<
Flow control configuration */
+#define XTE_FCC_RXFLO_MASK                  (1 << 29)           /**< Rx
flow control enable */
+//#define XTE_FCC_TXFLO_MASK                (1 << 30)           /**< Tx
flow control enable */
+
+#define XTE_EMCFG_OFFSET                0x00000300              /**<
EMAC configuration */
+#define XTE_EMCFG_LINKSPD_MASK          0xC0000000              /**<
Link speed */
+//#define XTE_EMCFG_RGMII_MASK              (1 << 29)           /**<
RGMII mode enable */
+//#define XTE_EMCFG_SGMII_MASK              (1 << 28)           /**<
SGMII mode enable */
+//#define XTE_EMCFG_1000BASEX_MASK          (1 << 27)           /**<
1000BaseX mode enable */
+//#define XTE_EMCFG_HOSTEN_MASK             (1 << 26)           /**<
Host interface enable */
+//#define XTE_EMCFG_TX16BIT                 (1 << 25)           /**< 16
bit Tx client enable */
+//#define XTE_EMCFG_RX16BIT                 (1 << 24)           /**< 16
bit Rx client enable */
+#define XTE_EMCFG_LINKSPD_10            0x00000000              /**<
XTE_EMCFG_LINKSPD_MASK for 10 Mbit */
+#define XTE_EMCFG_LINKSPD_100               (1 << 30)           /**<
XTE_EMCFG_LINKSPD_MASK for 100 Mbit */
+#define XTE_EMCFG_LINKSPD_1000              (1 << 31)           /**<
XTE_EMCFG_LINKSPD_MASK for 1000 Mbit */
+
+// #define XTE_GMIC_OFFSET              0x00000320              /**<
RGMII/SGMII configuration */
+#define XTE_MC_OFFSET                   0x00000340              /**<
Management configuration */
+#define XTE_MC_MDIO_MASK                    (1 << 6)            /**<
MII management enable */
+#define XTE_MDIO_CLOCK_DIV_100MHz       0x28                    /* 100
MHz host clock */
+#define XTE_MDIO_DIV_DFT                29                      /*
Default MDIO clock divisor */
+// #define XTE_MC_CLK_DVD_MAX           0x3F                    /**<
Maximum MDIO divisor */
+
+#define XTE_UAW0_OFFSET                 0x00000380              /**<
Unicast address word 0 */
+#define XTE_UAW1_OFFSET                 0x00000384              /**<
Unicast address word 1 */
+#define XTE_UAW1_MASK                   0x0000FFFF              /**<
Station address bits [47:32] Station address bits [31:0] are stored in
register UAW0 */
+
+#define XTE_MAW0_OFFSET                 0x00000388              /**<
Multicast address word 0 */
+#define XTE_MAW1_OFFSET                 0x0000038C              /**<
Multicast address word 1 */
+#define XTE_AFM_OFFSET                  0x00000390              /**<
Promisciuous mode */
+#define XTE_AFM_EPPRM_MASK                  (1 << 31)           /**<
Promiscuous mode enable */
+
+#define XGP_IRSTATUS                0x3A0                       /*
Interrupt Request status */
+#define XGP_IRENABLE                0x3A4                       /*
Interrupt Request enable */
+
+    /**  MII Mamagement Control register (MGTCR) */
+#define XTE_MGTDR_OFFSET                0x000003B0              /**<
MII data */
+#define XGP_E0_MIIM_ADDR                0x000003B4              /**<
MII control */
+#define XTE_MGTCR_RWN_MASK                  (1 << 10)           /**<
Read-not-write,0=read 1=write */
+#define XTE_MGTCR_PHYAD_MASK            0x000003E0              /**<
PHY address */
+#define XTE_MGTCR_REGAD_MASK            0x0000001F              /**<
PHY register address */
+#define XTE_MGTCR_PHYAD_SHIFT_MASK      5                       /**<
Shift bits for PHYAD */
+#define MGTCR_PHYAD(x)              ((x & 0x1f) << 5)       /**< PHY
address */
+#define MGTCR_REGAD(x)              (x & 0x1f)              /**< PHY
register address */
+
+
+#define PFIFO_64BIT_WIDTH_BYTES 8
+
+#define XGP_HIF_BASEADDR                    0x10c
+#define XGP_HIF_DATA_REG_MSW_OFFSET         0x000
+#define XGP_HIF_DATA_REG_LSW_OFFSET         0x001
+#define XGP_HIF_CNTL_REG_OFFSET             0x002
+#define XGP_CON_REG_PERIPH_RESET                (1 << 31)
+#define XGP_CON_REG_TEMAC_RESET                 (1 << 30)
+#define XGP_CON_REG_PHY_RESET                   (1 << 29)
+#define XGP_HIF_RDY_STATUS_OFFSET           0x003  
+
+/** DCR Ready Status Register masks for EMAC0 */
+#define XGP_HIF_RDYSTAT_CONFIG0_READ_MASK           (1 << 5)
+#define XGP_HIF_RDYSTAT_CONFIG0_WRITE_MASK          (1 << 6)
+#define XGP_HIF_RDYSTAT_AF0_WRITE_MASK              (1 << 4)
+#define XGP_HIF_RDYSTAT_AF0_READ_MASK               (1 << 3)
+#define XGP_HIF_RDYSTAT_MIIM0_WRITE_MASK            (1 << 2)
+#define XGP_HIF_RDYSTAT_MIIM0_READ_MASK             (1 << 1)
+
+/** DCR control register CntlReg masks * */
+#define XGP_HIF_CNTL_REG_OFFSET_DCR_WRITE           (1 << 15)       /*
Write enable */
+
+
+
+#define db_printf       DEBUG_PRINTK
+/* use 0 for production, 1 for verification, >1 for debug */
+#if defined(CONFIG_PICO_DEBUG_TEMAC)
+#define DEBUG_FUNC              if (lp->dbg)
{dbg_printk("\n%s:%s()",DRV_NAME, __FUNCTION__);}
+#define DEBUG_FUNC_EXIT         if (lp->dbg) {dbg_printk("\n%s:%s()
exit",DRV_NAME,__FUNCTION__);}
+#define DEBUG_FUNC_EX(ret)      if (lp->dbg)
{dbg_printk("\n%s:%s(%d)exit",DRV_NAME,__FUNCTION__,ret);}
+#define DEBUG_PRINTL(args...)   if (lp->dbg) dbg_printk("\n" __FILE__
": " args)
+#define DEBUG_PRINTK(args...)   if (lp->dbg) dbg_printk(args)
+#define DEBUG_PUTS(fmt...)      if (lp->dbg) dbg_puts(fmt)
+void dbg_printk(unsigned char *fmt, ...);
+static unsigned int debug = 1;
+#else
+#define DEBUG_FUNC              do { } while(0)
+#define DEBUG_FUNC_EXIT         do { } while(0)
+#define DEBUG_PRINTL(args...)   do { } while(0)
+#define DEBUG_PRINTK(args...)   do { } while(0)
+#define DEBUG_PUTS(args...)     do { } while(0)
+#define dump_skb(lp, skb) 0
+#define dump_skb_data(lp, skb, str) 0
+static unsigned int debug = 1;
+#endif
+
+#define mHoldS_SetEmpty(F)  ((F)->ByteIndex = 0)
+#define mHoldR_SetEmpty(F)  ((F)->ByteIndex = (F)->Width)
+/*******************************************************************************
+ * Primitive read from 64 bit FIFO. Use two 32-bit wide I/O accesses.
+ *
+ * @param F - Address to a temac_pktFifo structure
+ * @param DestPtr - Destination data address aligned on 4 byte boundary
+ *
+
******************************************************************************/
+#define mReadFifo64(F, DestPtr)                                \
+    (DestPtr)[0] = _ior(F->DataBaseAddress);          \
+    (DestPtr)[1] = _ior(F->DataBaseAddress + 4);
+
+#define mPush64(F) mWriteFifo64(F, &F->Hold[0])
+#define mHold_GetIndex(F)      ((F)->ByteIndex)
+#define mHoldS_IsEmpty(F)   ((F)->ByteIndex == 0)
+#define mHoldR_IsEmpty(F)   ((F)->ByteIndex >= (F)->Width)
+#define mHold_CopyOut(F, I, D) ((D) = (*(u8*)(((u8*)(&(F)->Hold[0])) +
(I))))
+#define mHold_SetIndex(F, D)   ((F)->ByteIndex = (D))
+#define mHold_CopyIn(F, I, D)  (*(u8*)(((u8*)(&(F)->Hold[0])) + (I)) = (D))
+#define mPop64(F) mReadFifo64(F, &F->Hold[0])
+#define mHold_SetIndex(F, D)   ((F)->ByteIndex = (D))
+#define mHoldS_IsFull(F)    ((F)->ByteIndex >= (F)->Width)
+#define mHold_Advance(F, D)    ((F)->ByteIndex += (D))
+/*******************************************************************************
+ * Primitive write to 64 bit FIFO. Use two 32-bit wide I/O accesses.
+ *
+ * @param F - Address to a temac_pktFifo structure
+ * @param SrcPtr - Source data address aligned on 4 byte boundary
+ *
+
******************************************************************************/
+#define mWriteFifo64(F, SrcPtr)                                \
+    {                                                          \
+        register u32 Faddr = F->DataBaseAddress;      \
+        _iow(Faddr, (SrcPtr)[0]);                         \
+        _iow(Faddr + 4, (SrcPtr)[1]);                     \
+    }
+
+
+
+/* Structure/enum declaration ------------------------------- */
+
+/* This type encapsulates a packet FIFO channel and support attributes to
+ * allow unaligned data transfers.
+ */
+struct temac_pktFifo {
+    u32             Hold[2];                /* Holding register */
+    unsigned        ByteIndex;              /* Holding register index */
+    unsigned        Width;                  /* Width of packet FIFO's
keyhole data port in bytes */
+    u32             RegBaseAddress;         /**< Base address of
registers */
+    u32             DataBaseAddress;        /**< Base address of data
for FIFOs */
+} ;
+
+struct temac_local {
+#if defined(LINUX)
+    struct sk_buff              *deferred_skb;     /* buffer for one
skb in case no room is available for transmission */
+
+//  void                        *RxFramePtr;       /* Address of first
RxFrame */
+    unsigned                    MaxFrameSz;        /* Size in bytes of
largest frame for Tx or Rx */
+//  u32                         RxPktFifoDepth;    /**< Depth of
receive packet FIFO in bits */
+//  u32                         TxPktFifoDepth;    /**< Depth of
transmit packet FIFO in bits */
+//  u16                         MacFifoDepth;      /**< Depth of the
status/length FIFOs in entries */
+
+    struct resource             *nic_addr_res;     /* resources found */
+    struct resource             *phy_addr_res;
+    struct resource             *nic_addr_req;     /* resources
requested */
+    struct resource             *phy_addr_req;
+    void __iomem                *nic_vaddr;        /* Register I/O base
address */
+
+    struct mii_if_info          mii_if;
+#else
+    EnetDevice                  enetDevice;
+    InterruptHandler            handler;
+    struct sk_buff              __skb[(NUM_TX_BDS+NUM_RX_BDS) +
(MAX_CACHE_LINE_SIZE/sizeof(struct sk_buff))];
+    char                        name[20];
+    u32                         base_addr;
+    u8                          dev_addr[6];
+
+    u32                         disablecount;
+    u32                         enablecount;
+    u32                         tx_reset_pending;
+    u32                         rx_reset_pending;
+    u32                         reads_denied_during_reset;
+    u32                         writes_denied_during_reset;
+
+    int                         devno;
+    Error                       (*GetLinkStatus)(struct temac_local *
lp, LinkSpeed *linkSpeed, LinkStatus *linkStatus, LinkDuplex  *linkDuplex);
+
+    PHY                         mii_if;
+    u32                         trans_start;
+    u32                         last_rx;
+#endif
+    unsigned int                mii:1;              /* mii port
available */
+    u8                          regshift;
+    u32                         msg_enable;         /* debug message
level */
+    struct net_device_stats     stats;              /* Statistics for
this device */
+    unsigned int                phy_mode;          /* dcr */
+    u16                         phy_addr;
+    u32                         phy_status;
+    unsigned int                poll:1;
+    unsigned int                dbg:1;              /* debug ? */
+    unsigned int                nic_type;           /* plb/ll */
+    int                         LinkSpeed;          /* Speed of link
10/100/1000 */
+    u32                         options;            /* Current options
word */
+//  u32                         TxPktFifoErrors;    /**< Number of Tx
packet FIFO errors detected */
+//  u32                         TxStatusErrors;
+//  u32                         RxPktFifoErrors;    /**< Number of Rx
packet FIFO errors detected */
+//  u32                         RxRejectErrors;
+//  u32                         FifoErrors;         /**< Number of
length/status FIFO errors detected */
+//  u32                         IpifErrors;         /**< Number of IPIF
transaction and data phase errors detected */
+//  u32                         Interrupts;         /**< Number of
interrupts serviced */
+    spinlock_t                  lock;
+    u16                         dcr_host;
+    struct timer_list           rx_timer;
+    struct timer_list           mii_timer;
+
+    /* Packet FIFO channels */
+    struct temac_pktFifo        RecvFifo;           /* Receive channel */
+    struct temac_pktFifo        SendFifo;           /* Transmit channel */
+
+} ;
+
+#if !defined(LINUX)
+static void EmacPhyInit(struct temac_local* lp);
+
+#define DEBUG_LOG
+
+extern void usDelay(u32 usec);
+
+static void
+mdelay(u32 delay) {
+    while(delay--) {
+        usDelay(1000);
+    }
+}
+
+/****************************************************************************/
+static struct sk_buff*
+get_free_skb(struct temac_local* lp, int num_skb) {
+    int ii;
+    // DEBUG_FUNC;
+    for(ii=0;ii < (NUM_TX_BDS+NUM_RX_BDS);ii++){
+        struct sk_buff *skb = &lp->__skb[ii];
+        // DEBUG_PRINTK("\n__skb[%d]
flags=%0x,%0x",ii,lp->__skb[ii].flags, skb->flags );
+        // if (lp->dbg) dump_skb(lp, skb);
+        if ((skb->flags & SKB_INUSE) == 0) {
+                skb->flags |= SKB_INUSE ;
+            // DEBUG_PRINTK(" found %d %0x %0x",ii, skb, &lp->__skb[ii]);
+            // this cast appears critical
+            return  (struct sk_buff *) &lp->__skb[ii];
+        }
+    }
+    // DEBUG_PRINTK(" ~found\n");
+    return NULL;
+}
+
+static u32
+get_free_skb_count(struct temac_local* lp) {
+    int ii;
+    struct sk_buff *skb ;
+    u32 ret = 0;
+    // DEBUG_PRINTK("\nget_free_skb_count()=");
+    for(ii=0;ii < (NUM_TX_BDS+NUM_RX_BDS);ii++){
+        skb = &lp->__skb[ii];
+        if ((skb->flags & SKB_INUSE) == 0) ret++;
+       
+    }
+    // DEBUG_PRINTK("%d",ret);
+    return ret;
+}
+
+static void
+skb_put(struct sk_buff *skb, u32 len) {
+    skb->len = len;
+    skb->tail = skb->data+len;
+}
+
+#define dev_kfree_skb_irq dev_kfree_skb
+static void
+dev_kfree_skb(struct sk_buff *skb) {
+    memset((void*)skb, 0, sizeof(struct sk_buff));
+}
+
+static struct sk_buff *
+dev_alloc_skb(u32 len) {
+    static struct sk_buff *skb;
+    struct temac_local* lp = &temac_dev_array[0];
+    int ii;
+    // DEBUG_PRINTK("\ndev_alloc_skb(len=%d)",len);
+    for(ii=0;ii < (NUM_TX_BDS+NUM_RX_BDS);ii++){
+        skb = &lp->__skb[ii];
+
+        // DEBUG_PRINTK("\nskb[%d] flags=%0x, len=%d", ii, skb->flags,
skb->size );
+        if (((skb->flags & (SKB_INUSE | SKB_RX | SKB_ALLOC)) ==
(SKB_INUSE | SKB_RX)) && (skb->size >= len) && (skb->len == 0)) {
+            skb->flags |= SKB_ALLOC;
+             // DEBUG_PRINTK(" found %d %0x %0x",ii, skb, &lp->__skb[ii]);
+            return skb;
+        }
+    }
+    return NULL;
+}
+static struct temac_local   temac_dev_array[MAX_TEMAC_DEVS];
+static u8           num_devs = 0;
+
+static struct temac_local*
+temac_allocate(void) {
+    struct temac_local* lp;
+
+    if (num_devs >= MAX_TEMAC_DEVS) {
+        return NULL;
+    }
+
+    lp = &temac_dev_array[num_devs];
+    num_devs++;
+
+    return lp;
+}
+#endif
+
+static u32
+_ior(u32 offset) {
+    u32 value;
+    value = (*(volatile u32 *) (offset));
+    __asm__ __volatile__("eieio");
+    return value;
+}
+
+static void
+_iow(u32 offset, u32 value) {
+    (*(volatile u32 *) (offset) = value);
+    __asm__ __volatile__("eieio");
+}
+
+static u32
+ior(struct net_device *ndev, int offset) {
+    return _ior(ndev->base_addr + offset);
+}
+
+static u32
+ios(struct net_device *ndev) {
+    return ior(ndev, XTE_IPIER_OFFSET) & ior(ndev, XTE_IPISR_OFFSET);
+}
+
+static void
+iow(struct net_device *ndev, int offset, u32 value) {
+    _iow(ndev->base_addr + offset, value);
+}
+
+/***************************************************************************
+ * Reads an MII register from the MII PHY attached to the Xilinx Temac.
+ *
+ * Parameters:
+ *   dev      - the temac device.
+ *   phy_addr - the address of the PHY [0..31]
+ *   reg_num  - the number of the register to read. 0-6 are defined by
+ *              the MII spec, but most PHYs have more.
+ *   reg_value - this is set to the specified register's value
+ *
+ * Returns:
+ *   Success or Failure
+ */
+static Error
+g_mdio_read(struct net_device *ndev, int phy_id, int reg_num, u16 *
reg_val) {
+    struct temac_local *lp = ndev->priv;
+    u32 timeout, status;
+    unsigned long flags;
+    *reg_val = 0;
+    // unsigned long flags;
+
+    // DEBUG_PRINTK("\nmdio_read(%x,%x)= ", phy_id, reg_num);
+    timeout = PHY_TIMEOUT;
+    /* Start a read */
+
+    /* Make sure no other PHY operation is currently in progress */
+    if (ior(ndev, XTE_IPISR_OFFSET) & XTE_IPXR_MII_PEND_MASK)
+        return Failure;
+
+    if (lp->mii) {
+        spin_lock_irqsave(&lp->lock, flags);
+
+        switch (lp->phy_mode) {
+            case PHY_DCR:
+                mtdcr(lp->phy_addr + XGP_HIF_DATA_REG_LSW_OFFSET,
((phy_id << 5) | (reg_num)));
+                mtdcr(lp->phy_addr + XGP_HIF_CNTL_REG_OFFSET,
XGP_E0_MIIM_ADDR);
+                while (!(mfdcr(lp->phy_addr +
XGP_HIF_RDY_STATUS_OFFSET) & XGP_HIF_RDYSTAT_MIIM0_READ_MASK));
+                *reg_val = (u16) mfdcr(lp->phy_addr +
XGP_HIF_DATA_REG_LSW_OFFSET);
+                break;
+
+            default:
+                /* Construct Mgtcr mask for the operation */
+                /* Write and wait for completion */
+                iow(ndev, XTE_HOST_IPIF_OFFSET + XGP_E0_MIIM_ADDR,
(reg_num & XTE_MGTCR_REGAD_MASK) | ((phy_id <<
XTE_MGTCR_PHYAD_SHIFT_MASK) & XTE_MGTCR_PHYAD_MASK) | XTE_MGTCR_RWN_MASK);
+
+                while (!(status = ior(ndev, XTE_IPISR_OFFSET) &
XTE_IPXR_MII_DONE_MASK) && timeout--) ;
+                if (!(status & (XTE_IPXR_MII_DONE_MASK)))
+                    return Failure;
+
+                *reg_val = ior(ndev, XTE_HOST_IPIF_OFFSET +
XTE_MGTDR_OFFSET);      /* Read data */
+
+                /* Clear MII status bits */
+                iow(ndev, XTE_IPISR_OFFSET, ior(ndev, XTE_IPISR_OFFSET)
& (XTE_IPXR_MII_DONE_MASK | XTE_IPXR_MII_PEND_MASK));
+                break;
+        }
+        spin_unlock_irqrestore(&lp->lock, flags);
+    }
+//  DEBUG_PRINTK("%x", *reg_val);
+    return Success;
+}
+
+static int
+mdio_read(struct net_device *ndev, int phy_id, int reg_num) {
+    u16 ret = 0;
+    g_mdio_read(ndev, phy_id, reg_num, &ret);
+    return ret;
+}
+
+/***************************************************************************
+ * Writes an MII register from the MII PHY attached to the Xilinx Temac.
+ *
+ * Parameters:
+ *   dev      - the temac device.
+ *   phy_id - the address of the PHY [0..31]
+ *   reg_num  - the number of the register to read. 0-6 are defined by
+ *              the MII spec, but most PHYs have more.
+ *   reg_value - the value to set
+ *
+ * Returns:
+ *   Success or Failure
+ */
+static void
+mdio_write(struct net_device *ndev, int phy_id, int reg_num, int reg_val) {
+    struct temac_local *lp = ndev->priv;
+    u32 timeout, status;
+    unsigned long flags;
+    int EmacNum = 0;
+    // DEBUG_FUNC;
+    // DEBUG_PRINTK("\nmdio_write(%x,%x, %x)= ", phy_id,
reg_num,reg_value);
+    timeout = PHY_TIMEOUT;
+
+    if (lp->mii) {
+        spin_lock_irqsave(&lp->lock, flags);
+        switch (lp->phy_mode) {
+            case PHY_DCR:
+                mtdcr(lp->phy_addr + XGP_HIF_DATA_REG_LSW_OFFSET,
(reg_val));
+                mtdcr(lp->phy_addr + XGP_HIF_CNTL_REG_OFFSET,
XGP_HIF_CNTL_REG_OFFSET_DCR_WRITE | XTE_MGTDR_OFFSET);
+                mtdcr(lp->phy_addr + XGP_HIF_DATA_REG_LSW_OFFSET,
((phy_id << 5) | (reg_num)));
+                mtdcr(lp->phy_addr + XGP_HIF_CNTL_REG_OFFSET,
XGP_HIF_CNTL_REG_OFFSET_DCR_WRITE | ((EmacNum) << 10) | XGP_E0_MIIM_ADDR);
+                while (!(mfdcr(lp->phy_addr +
XGP_HIF_RDY_STATUS_OFFSET) & XGP_HIF_RDYSTAT_MIIM0_WRITE_MASK));
+                break;
+
+            default:
+                /* Make sure no other PHY operation is currently in
progress */
+                if (ior(ndev, XTE_IPISR_OFFSET) & XTE_IPXR_MII_PEND_MASK)
+                    return ;
+                /* Construct Mgtcr mask for the operation */
+                /* Write and wait for completion */
+                iow(ndev, XTE_HOST_IPIF_OFFSET + XTE_MGTDR_OFFSET,
reg_val & 0xffff);
+                iow(ndev, XTE_HOST_IPIF_OFFSET + XGP_E0_MIIM_ADDR,
(reg_num & XTE_MGTCR_REGAD_MASK) | ((phy_id <<
XTE_MGTCR_PHYAD_SHIFT_MASK) & XTE_MGTCR_PHYAD_MASK));
+
+                while (!(status = ior(ndev, XTE_IPISR_OFFSET) &
XTE_IPXR_MII_DONE_MASK) && timeout--) ;
+                if (!(status & (XTE_IPXR_MII_DONE_MASK)))
+                    return ;
+
+                /* Clear MII status bits */
+                iow(ndev, XTE_IPISR_OFFSET, ior(ndev, XTE_IPISR_OFFSET)
& (XTE_IPXR_MII_DONE_MASK | XTE_IPXR_MII_PEND_MASK));
+                break;
+        }
+        spin_unlock_irqrestore(&lp->lock, flags);
+    }
+    // return Success;
+}
+
+static u32
+emac_cfg_read(struct net_device *ndev, u16 phy_id, u16 reg_num) {
+    struct temac_local *lp = ndev->priv;
+    int EmacNum = 0;
+    u32 ret = 0;
+
+    if (lp->mii) {
+        switch (lp->phy_mode) {
+            case PHY_DCR:
+                mtdcr(lp->phy_addr + XGP_HIF_CNTL_REG_OFFSET, (EmacNum
<< 10) | (reg_num));
+                while (!(mfdcr(lp->phy_addr +
XGP_HIF_RDY_STATUS_OFFSET) & (XGP_HIF_RDYSTAT_CONFIG0_READ_MASK << (8 *
(EmacNum)))));
+                return (u32) mfdcr(lp->phy_addr +
XGP_HIF_DATA_REG_LSW_OFFSET);
+            default:
+                return ior(ndev, XTE_HOST_IPIF_OFFSET + reg_num);
+        }
+    }
+
+    return ret;
+}
+
+static void
+emac_cfg_write(struct net_device *ndev, u16 phy_id, u32 reg_num, u32 val) {
+    struct temac_local *lp = ndev->priv;
+    int EmacNum = 0;
+
+    if (lp->mii) {
+        switch (lp->phy_mode) {
+            case PHY_DCR:
+                mtdcr(lp->phy_addr + XGP_HIF_DATA_REG_LSW_OFFSET, (val));
+                mtdcr(lp->phy_addr + XGP_HIF_CNTL_REG_OFFSET,
XGP_HIF_CNTL_REG_OFFSET_DCR_WRITE | (EmacNum << 10) | (reg_num));
+                while (!(mfdcr(lp->phy_addr +
XGP_HIF_RDY_STATUS_OFFSET) & XGP_HIF_RDYSTAT_CONFIG0_WRITE_MASK));
+                break;
+            default:
+                iow(ndev, XTE_HOST_IPIF_OFFSET + reg_num, val);
+                break;
+        }
+    }
+}
+
+static u32
+emac_AF_read(struct net_device *ndev, int reg_num) {
+    struct temac_local *lp = ndev->priv;
+    int EmacNum = 0;
+        switch (lp->phy_mode) {
+            case PHY_DCR:
+                mtdcr((lp->phy_addr) + XGP_HIF_CNTL_REG_OFFSET,
(EmacNum << 10) | (reg_num));
+                while ( !(mfdcr(lp->phy_addr +
XGP_HIF_RDY_STATUS_OFFSET )  & (XGP_HIF_RDYSTAT_AF0_READ_MASK <<
(8*(EmacNum)))));
+                return (u32) mfdcr((lp->phy_addr) +
XGP_HIF_DATA_REG_LSW_OFFSET) ;
+            default:
+                return ior(ndev, XTE_HOST_IPIF_OFFSET + reg_num);
+        }
+        return 0;
+}
+
+static void
+emac_AF_write(struct net_device *ndev, int reg_num, u32 val) {
+    struct temac_local *lp = ndev->priv;
+    int EmacNum = 0;
+
+    if (lp->mii) {
+        switch (lp->phy_mode) {
+            case PHY_DCR:
+                mtdcr(lp->phy_addr + XGP_HIF_DATA_REG_LSW_OFFSET, (val));
+                mtdcr(lp->phy_addr + XGP_HIF_CNTL_REG_OFFSET,
XGP_HIF_CNTL_REG_OFFSET_DCR_WRITE | ((EmacNum) << 10) | (reg_num));
+                while (!(mfdcr(lp->phy_addr +
XGP_HIF_RDY_STATUS_OFFSET) & XGP_HIF_RDYSTAT_AF0_WRITE_MASK));
+                break;
+            default:
+                iow(ndev, XTE_HOST_IPIF_OFFSET + reg_num, val);
+                break;
+        }
+    }
+}
+#if defined(CONFIG_PICO_DEBUG_TEMAC)
+
+static void
+dump_skb(struct temac_local* lp, struct sk_buff *skb) {
+#if !defined(LINUX)
+    DEBUG_PRINTK("\nskb->flags\t%0x",  skb->flags);
+    DEBUG_PRINTK("\nskb->fifo_data\t%0x",  skb->fifo_data);
+    DEBUG_PRINTK("\nskb->fifo_reg\t%0x",  skb->fifo_reg);
+    DEBUG_PRINTK("\nskb->size\t%d",  skb->size);
+#endif
+    DEBUG_PRINTK("\nskb->len\t%0d",  skb->len);
+#if !defined(LINUX)
+    DEBUG_PRINTK("\nskb->user\t%0x",  skb->user);
+    DEBUG_PRINTK("\nskb->user_data\t%0x",  skb->user_data);
+#endif
+    DEBUG_PRINTK("\nskb->dev\t%0x",  skb->dev);
+    DEBUG_PRINTK("\nskb->data\t%0x",  skb->data);
+    DEBUG_PRINTK("\nskb->tail\t%0x",  skb->tail);
+}
+
+static void
+dump_skb_data(struct temac_local *lp, struct sk_buff *skb, char *str) {
+    int ii;
+    u8 *cp = skb->data ;
+
+    DEBUG_PRINTK("\n%s %d bytes", str, skb->len);
+    for (ii = 0; ii < skb->len; ii++) {
+        if (( ii % 16) == 0) DEBUG_PRINTK("\n");
+        if (( ii % 8) == 0) DEBUG_PRINTK(" ");
+        DEBUG_PRINTK("%02x ", cp[ii]);
+    }
+    DEBUG_PRINTK("\n");
+}
+
+static void
+disp_emac_cfg(struct net_device *ndev, char *rname, int  regnum, int idx) {
+    struct temac_local *lp = ndev->priv;
+    u32 ret;
+    int ii;
+
+    if ((idx % 4) == 0) DEBUG_PRINTK("\n\t");
+    ret = emac_cfg_read(ndev, PHY_NUM, regnum);
+    if (rname) {
+        DEBUG_PRINTK("%s:", rname);
+        for(ii=strlen(rname);ii<10;ii++) DEBUG_PRINTK(" ");
+        DEBUG_PRINTK("0x%08x  ", ret);
+    } else
+        DEBUG_PRINTK("R%03d:      0x%08x  ",  regnum, ret);
+}
+
+static void
+disp_temac_cfg(struct net_device *ndev, char *rname, int  addr, int idx) {
+    struct temac_local *lp = ndev->priv;
+    u32 ret = 0;
+    int ii;
+
+    if ((idx % 4) == 0) DEBUG_PRINTK("\n\t");
+    switch (lp->phy_mode) {
+        case PHY_DCR:
+            break;
+        default:
+            ret = _ior(ndev->base_addr + addr);
+            break;
+    }
+    if (rname) {
+        DEBUG_PRINTK("%s:", rname);
+        for(ii=strlen(rname);ii<10;ii++) DEBUG_PRINTK(" ");
+        DEBUG_PRINTK("0x%08x  ", ret);
+    } else
+        DEBUG_PRINTK("R%03d:      0x%08x  ",  addr, ret);
+}
+
+static void
+disp_mii(struct net_device *ndev, char *rname, int  regnum) {
+    struct temac_local *lp = ndev->priv;
+    u32 ret;
+    int ii;
+    if ((regnum % 4) == 0) DEBUG_PRINTK("\n\t");
+    ret =  mdio_read(ndev, PHY_NUM, regnum);
+    if (rname) {
+        DEBUG_PRINTK("%s:", rname);
+        for(ii=strlen(rname);ii<10;ii++) DEBUG_PRINTK(" ");
+        DEBUG_PRINTK("0x%08x  ", ret);
+    } else
+        DEBUG_PRINTK("R%02d:       0x%08x  ",  regnum, ret);
+}
+
+static void
+temac_dump(struct net_device *ndev) {
+    struct temac_local *lp = ndev->priv;
+    u32 ret;
+    int ii, jj;
+
+#if defined(LINUX)
+    DEBUG_PRINTK("\nresources:\n\tirq=%d ", ndev->irq);
+    DEBUG_PRINTK("\n\tnic  physical address =%x ",
lp->nic_addr_res->start);
+    DEBUG_PRINTK("size %x ", res_size(lp->nic_addr_res));
+    DEBUG_PRINTK("virtual address %lx", ndev->base_addr);
+    DEBUG_PRINTK("\n\t irq=%d mem=%lx phy=%x", ndev->irq,
ndev->base_addr, lp->phy_addr);
+#else
+    DEBUG_PRINTK("\nresources:\n\tirq=%d ", ndev->handler.vect);
+    DEBUG_PRINTK("virtual address %x ", ndev->base_addr);
+    DEBUG_PRINTK("\n\t irq=%d mem=%x phy=%x", ndev->handler.vect,
ndev->base_addr, ndev->phy_addr);
+#endif
+
+    DEBUG_PRINTK("\n\t");
+    ret = mdio_read(ndev, PHY_NUM, MII_SSR) ;
+    switch (ret & MII_SSR_SPDMASK) {
+        case MII_SSR_SPD1000:
+            DEBUG_PRINTK("1000");
+            break;
+        case MII_SSR_SPD100:
+            DEBUG_PRINTK("100");
+            break;
+        case MII_SSR_SPD10:
+            DEBUG_PRINTK("10");
+            break;
+        default:
+            DEBUG_PRINTK("Error : invalid PHY mode/speed");
+    };
+    DEBUG_PRINTK("BASE-T, ");
+    if ((ret & MII_SSR_FD) == MII_SSR_FD) {
+        DEBUG_PRINTK("FD");
+    } else {
+        DEBUG_PRINTK("HD");
+    }
+    if ((ret & MII_SSR_LINK)  == 0) {
+        DEBUG_PRINTK(" Ethernet Link Down");
+    }
+    /* read mii phy registers */
+    DEBUG_PRINTK("\nReading PHY Regs through DCR:\n\t");
+    for (ii = 0; ii < 32; ii++) {
+        switch (ii) {
+            case MII_ANI:
+                disp_mii(ndev, "ANI", ii);
+                break;
+            case MII_SSR:
+                disp_mii(ndev, "SSR", ii);
+                break;
+            case MII_ISR:
+                disp_mii(ndev, "ISR", ii);
+                break;
+            case MII_BMCR:
+                disp_mii(ndev, "MCR", ii);
+                break;
+            case MII_BMSR:
+                disp_mii(ndev, "MSR", ii);
+                break;
+            case MII_PHYSID1:
+                disp_mii(ndev,"PHYSID1",ii);
+                break;
+            case MII_PHYSID2:
+                disp_mii(ndev,"PHYSID2",ii);
+                break;
+            case MII_ADVERTISE:
+                disp_mii(ndev,"ADV", ii);
+                break;
+            case MII_LPA:
+                disp_mii(ndev,"LPA", ii);
+                break;
+            case MII_EXPANSION:
+                disp_mii(ndev,"EXPANSION", ii);
+                break;
+            case MII_CTRL1000:
+                disp_mii(ndev,"CTRL1000", ii);
+                break;
+            case MII_STAT1000:
+                disp_mii(ndev,"STAT1000", ii);
+                break;
+            case MII_ESTATUS:
+                disp_mii(ndev,"ESTATUS", ii);
+                break;
+            case MII_DCOUNTER:
+                disp_mii(ndev,"DCOUNTER", ii);
+                break;
+            case MII_NWAYTEST:
+                disp_mii(ndev,"NWAYTEST", ii);
+                break;
+            case MII_RERRCOUNTER:
+                disp_mii(ndev,"RERRCOUNT", ii);
+                break;
+            case MII_SREVISION:
+                disp_mii(ndev,"SREVISION",ii);
+                break;
+            case MII_RESV1:
+                disp_mii(ndev,"RESV1",ii);
+                break;
+            case MII_LBRERROR:
+                disp_mii(ndev,"LBERROR",ii);
+                break;
+            case MII_PHYADDR:
+                disp_mii(ndev,"PHYADDR",ii);
+                break;
+            case MII_RESV2:
+                disp_mii(ndev,"RESV2",ii);
+                break;
+            case MII_TPISTATUS:
+                disp_mii(ndev,"TPISTATUS",ii);
+                break;
+            case MII_NCONFIG:
+                disp_mii(ndev,"NCONFIG",ii);
+                break;
+#if 0
+            case MII_FCSCOUNTER:
+                disp_mii(ndev,"FCSCOUNTER",ii);
+                break;
+#endif
+            default:
+                disp_mii(ndev,0, ii);
+                break;
+        }
+    }
+    /*
+    Print TEMAC Receiver and Transmitter configuration
+    */
+    DEBUG_PRINTK("\nReading Hard TEMAC Regs:\n");
+
+    for (ii = 0x200,jj = 0; ii <= 0x3a4; ii += 4) {
+        switch (ii) {
+            case XTE_RXC0_OFFSET:
+                disp_emac_cfg(ndev, "RxCW0", ii, jj++);
+                break;
+            case XTE_RXC1_OFFSET:
+                disp_emac_cfg(ndev, "RxCW1", ii, jj++);
+                break;
+            case XTE_TXC_OFFSET:
+                disp_emac_cfg(ndev, "TxCW", ii, jj++);
+                break;
+            case XTE_FCC_OFFSET:
+                disp_emac_cfg(ndev, "Flow", ii, jj++);
+                break;
+            case XTE_EMCFG_OFFSET:
+                disp_emac_cfg(ndev, "ModeCfg", ii, jj++);
+                break;
+            case XTE_MC_OFFSET:
+                disp_emac_cfg(ndev, "MgmtCfg", ii, jj++);
+                break;
+            case XTE_UAW0_OFFSET:
+                disp_emac_cfg(ndev, "MacAddr0", ii, jj++);
+                break;
+            case XTE_UAW1_OFFSET:
+                disp_emac_cfg(ndev, "MacAddr1", ii, jj++);
+                break;
+            case XTE_MAW0_OFFSET:
+                disp_emac_cfg(ndev, "AtAddr0", ii, jj++);
+                break;
+            case XTE_MAW1_OFFSET:
+                disp_emac_cfg(ndev, "AtAddr1", ii, jj++);
+                break;
+            case XTE_AFM_OFFSET:
+                disp_emac_cfg(ndev, "AtCAF", ii, jj++);
+                break;
+            case XGP_IRSTATUS:
+                disp_emac_cfg(ndev, "ISR", ii, jj++);
+                break;
+            case XGP_IRENABLE:
+                disp_emac_cfg(ndev, "IER", ii, jj++);
+                break;
+            default:
+                break;
+        }
+    }
+    DEBUG_PRINTK("\n");
+
+    if (lp->nic_type == TEMAC_PLB) {
+        DEBUG_PRINTK("\nReading PLB TEMAC Regs:\n");
+
+        for (ii = 0x0,jj = 4;ii <= 0x1020; ii += 4) {
+            switch (ii) {
+                case XTE_DISR_OFFSET:
+                    disp_temac_cfg(ndev, "DISR", ii, jj++);
+                    break;
+                case XTE_DIPR_OFFSET:
+                    disp_temac_cfg(ndev, "DIPR", ii, jj++);
+                    break;
+                case XTE_DIER_OFFSET:
+                    disp_temac_cfg(ndev, "DIER", ii, jj++);
+                    break;
+                case XTE_DGIE_OFFSET:
+                    disp_temac_cfg(ndev, "DGIE", ii, jj++);
+                    break;
+                case XTE_IPISR_OFFSET:
+                    disp_temac_cfg(ndev, "IPISR", ii, jj++);
+                    break;
+                case XTE_IPIER_OFFSET:
+                    disp_temac_cfg(ndev, "IPIER", ii, jj++);
+                    break;
+                case XTE_DSR_OFFSET:
+                    disp_temac_cfg(ndev, "MIR", ii, jj++);
+                    break;
+                case XTE_TPLR_OFFSET:
+                    // disp_temac_cfg(ndev, "TPLR", ii, jj++);  // do
not try to display this register - BAD things will happen
+                    break;
+                case XTE_CR_OFFSET:
+                    disp_temac_cfg(ndev, "CR", ii, jj++);
+                    break;
+                case XTE_TSR_OFFSET:
+                    // disp_temac_cfg(ndev, "TSR", ii, jj++);
+                    break;
+                case XTE_RPLR_OFFSET:
+                    // disp_temac_cfg(ndev, "RPLR", ii, jj++);
+                    break;
+                case XTE_RSR_OFFSET:
+                    disp_temac_cfg(ndev, "RSR", ii, jj++);
+                    break;
+                case XTE_TPPR_OFFSET:
+                    disp_temac_cfg(ndev, "TPPR", ii, jj++);
+                    break;
+                default:
+                    break;
+            }
+        }
+    }
+    DEBUG_PRINTK("\nDisplaying Options:\n");
+
+    for (ii = 0, jj = 0;ii < 32; ii++) {
+        if ( lp->options & ( 1 << ii)) {
+            jj++;
+            if ((jj % 4) == 0) DEBUG_PRINTK("\n\t");
+            switch ( 1 << ii) {
+                case XTE_PROMISC_OPTION:
+                    DEBUG_PRINTK("PROMISC ");
+                    break;
+                case XTE_JUMBO_OPTION:
+                    DEBUG_PRINTK("JUMBO ");
+                    break;
+                case XTE_VLAN_OPTION:
+                    DEBUG_PRINTK("VLAN ");
+                    break;
+                case XTE_FLOW_CONTROL_OPTION:
+                    DEBUG_PRINTK("FLOW_CONTROL ");
+                    break;
+                case XTE_FCS_STRIP_OPTION:
+                    DEBUG_PRINTK("FCS_STRIP ");
+                    break;
+                case XTE_FCS_INSERT_OPTION:
+                    DEBUG_PRINTK("FCS_INSERT ");
+                    break;
+                case XTE_LENTYPE_ERR_OPTION:
+                    DEBUG_PRINTK("LENTYPE ERR ");
+                    break;
+                case XTE_POLLED_OPTION:
+                    DEBUG_PRINTK("POLLED ");
+                    break;
+                case XTE_REPORT_RXERR_OPTION:
+                    DEBUG_PRINTK("REPORT_RXERR ");
+                    break;
+                case XTE_TRANSMITTER_ENABLE_OPTION:
+                    DEBUG_PRINTK("TRANSMITTER_ENABLE ");
+                    break;
+                case XTE_RECEIVER_ENABLE_OPTION:
+                    DEBUG_PRINTK("RECEIVER_ENABLE ");
+                    break;
+                case XTE_BROADCAST_OPTION:
+                    DEBUG_PRINTK("BROADCAST ");
+                    break;
+                case XTE_MULTICAST_CAM_OPTION:
+                    DEBUG_PRINTK("MULTICAST_CAM ");
+                    break;
+                case XTE_REPORT_TXSTATUS_OVERRUN_OPTION:
+                    DEBUG_PRINTK("REPORT_TXSTATUS_OVERRUN ");
+                    break;
+                case XTE_ANEG_OPTION:
+                    DEBUG_PRINTK("ANEG ");
+                    break;
+                default:
+                    DEBUG_PRINTK("UNK ");
+                    break;
+            }
+        }
+    }
+    DEBUG_PRINTK("\n");
+}
+#endif
+
+/*
+Changes the mac address if the controller is not running.
+
+static int (*set_mac_address)(struct net_device *dev, void *addr);
+Function that can be implemented if the interface supports the ability
to change its
+hardware address. Many interfaces don't support this ability at all.
Others use the
+default eth_mac_addr implementation (from drivers/net/net_init.c).
eth_mac_addr
+only copies the new address into dev->dev_addr, and it does so only if
the interface
+is not running. Drivers that use eth_mac_addr should set the hardware MAC
+address from dev->dev_addr in their open method.
+
+*/
+static u32
+temac_set_mac_address(struct net_device *ndev, void *address) {
+    struct temac_local *lp = ndev->priv;
+#if defined(LINUX)
+    u8 addr[] = { 0x0, 0x50, 0xc2, 0x44, 0x2f, 0xff };
+    int ii;
+
+    // DEBUG_FUNC;
+    if (address)
+        memcpy(ndev->dev_addr, address, ETH_ALEN);
+
+    if (!is_valid_ether_addr(ndev->dev_addr)) {
+        printk(KERN_ERR "%s: Invalid ethernet MAC address.  Please set
using ifconfig\n", ndev->name);
+        for (ii=0; ii<6; ii++)
+            ndev->dev_addr[ii] = addr[ii];
+    }
+#endif
+    /* set up unicast MAC address filter set its mac address */
+    emac_AF_write(ndev,  XTE_UAW0_OFFSET, ((ndev->dev_addr[3] << 24) |
(ndev->dev_addr[2] << 16) | (ndev->dev_addr[1] << 8) |
(ndev->dev_addr[0])));
+    /* There are reserved bits in EUAW1 so don't affect them Set MAC
bits [47:32] in EUAW1 */
+    emac_AF_write(ndev, XTE_UAW1_OFFSET, (ndev->dev_addr[4] &
0x000000FF) | (ndev->dev_addr[5] << 8) | (emac_AF_read(ndev,
XTE_UAW1_OFFSET) & ~XTE_UAW1_MASK));
+
+    /* enable address filter */
+    emac_AF_write(ndev, XTE_AFM_OFFSET, 0);
+    return Success;
+}
+
+/*
+OPTIONAL
+static void (*set_multicast_list)(struct net_device *dev);
+Method called when the multicast list for the device changes and when the
+flags change. See the section Multicast for further details and a sample
+implementation.
+*/
+static void
+temac_set_multicast_list(struct net_device *ndev) {
+}
+
+static u32 temac_setoptions(struct net_device *ndev, u32 Options) ;
+/*
+Initilize temac board
+ */
+static void
+temac_device_reset(struct net_device *ndev) {
+    struct temac_local *lp = ndev->priv;
+    u32 ret;
+    u32 Reg;
+    int ii;
+
+    // DEBUG_FUNC;
+    /* Perform a software reset */
+    /* Reset the device */
+    switch (lp->nic_type) {
+        case TEMAC_PLB:
+            iow(ndev, XTE_DSR_OFFSET,
XTE_DSR_RESET_MASK);                 // reset everything
+#if 0
+            iow(ndev, XTE_CR_OFFSET,   XTE_CR_HRST_MASK);             
// Reset HARD TEMAC
+            emac_cfg_write(lp, PHY_NUM, XTE_RXC1_OFFSET,
XTE_RXC1_RXRST_MASK);
+            while (emac_cfg_read(lp, PHY_NUM, XTE_RXC1_OFFSET) & 
XTE_RXC1_RXRST_MASK);     // Wait for the receiver to finish reset
+            emac_cfg_write(lp, PHY_NUM, XTE_TXC_OFFSET,
XTE_TXC_TXRST_MASK);
+            while (emac_cfg_read(lp, PHY_NUM, XTE_TXC_OFFSET) & 
XTE_TXC_TXRST_MASK);   // Wait for the receiver to finish reset
+#endif
+
+            /* Initialize the packet FIFOs */
+            lp->RecvFifo.RegBaseAddress = (u32) (ndev->base_addr +
XTE_PFIFO_RXREG_OFFSET);
+            lp->RecvFifo.DataBaseAddress =  (u32) (ndev->base_addr +
XTE_PFIFO_RXDATA_OFFSET);
+            _iow(lp->RecvFifo.RegBaseAddress +
XPF_V200A_RESET_REG_OFFSET, XPF_V200A_RESET_FIFO_MASK);
+            lp->SendFifo.RegBaseAddress = (u32) (ndev->base_addr +
XTE_PFIFO_TXREG_OFFSET);
+            lp->SendFifo.DataBaseAddress =  (u32) (ndev->base_addr +
XTE_PFIFO_TXDATA_OFFSET);
+            _iow(lp->SendFifo.RegBaseAddress +
XPF_V200A_RESET_REG_OFFSET, XPF_V200A_RESET_FIFO_MASK);
+
+            /* Choose an access algorithm.
+             * Note: 64-bit wide FIFO is the only width supported at
this time
+             */
+            lp->RecvFifo.Width = PFIFO_64BIT_WIDTH_BYTES;
+            lp->SendFifo.Width = PFIFO_64BIT_WIDTH_BYTES;
+
+            /* Initialize the holds */
+            mHoldS_SetEmpty(&lp->SendFifo);
+            mHoldR_SetEmpty(&lp->RecvFifo);
+
+            /* Reset the hardware and set default options */
+
+            /* Stop the device and reset HW */
+            iow(ndev, XTE_DGIE_OFFSET, 0); /* Disable interrupts */
+
+            /* Disable the receiver */
+            emac_cfg_write(ndev, PHY_NUM, XTE_RXC1_OFFSET,
emac_cfg_read(ndev, PHY_NUM, XTE_RXC1_OFFSET)& ~XTE_RXC1_RXEN_MASK);
+
+            /* Stopping the receiver in mid-packet causes a dropped
packet indication
+             * from HW. Clear it.
+             */
+            if (ior(ndev, XTE_IPISR_OFFSET) & XTE_IPXR_RECV_REJECT_MASK)
+                iow(ndev, XTE_IPISR_OFFSET, XTE_IPXR_RECV_REJECT_MASK);
+           
+            /* Reset IPIF */
+            iow(ndev, XTE_DSR_OFFSET, XTE_DSR_RESET_MASK);
+            udelay(XTE_RESET_IPIF_DELAY_US);
+
+            /* Default IPIF interrupt block enable mask */
+            iow(ndev, XTE_DIER_OFFSET, XTE_DXR_CORE_MASK |
XTE_DXR_DPTO_MASK | XTE_DXR_TERR_MASK | XTE_DXR_RECV_FIFO_MASK |
XTE_DXR_SEND_FIFO_MASK);
+#if 0
+            // Interframe gap: The HW has an enable bit to change the
IFG through the
+            // XTE_TPPR_OFFSET register. Rather than make the user set
this bit then
+            // change the register, simplifiy the process by always
setting the
+            // enable bit. All the user needs to do is use
XTemac_SetIfg() thereafter.
+            // The default IFG is 96 bit times. Whatever is in the
register adds to that.
+            // By default leave this register at 0 so we have 96 bit times.
+            // Now set IFG adjust enable
+            iow(ndev, XTE_TPPR_OFFSET, 0);
+            emac_cfg_write(lp, PHY_NUM, XTE_TXC_OFFSET,
emac_cfg_read(lp, PHY_NUM, XTE_TXC_OFFSET) | XTE_TXC_TXIFG_MASK);
+            emac_cfg_write(lp, PHY_NUM, XTE_MC_OFFSET,
XTE_XTE_MDIO_DIV_DFT | XTE_MC_MDIO_MASK); // Set default MDIO divisor
+
+            // Reset the FIFOs  - check this out for TEMAC
+            iow(ndev,
(XTE_PFIFO_TXREG_OFFSET+XPF_V200A_RESET_REG_OFFSET),
XPF_V200A_RESET_FIFO_MASK);
+            iow(ndev,
(XTE_PFIFO_RXREG_OFFSET+XPF_V200A_RESET_REG_OFFSET),
XPF_V200A_RESET_FIFO_MASK);
+#endif
+            break;
+#if defined(CONFIG_PICO_LL_TEMAC)
+        case TEMAC_LL:
+            /* Hold the PHY in reset */
+            mtdcr(lp->dcr_host, XGP_CON_REG_PHY_RESET);
+            mdelay(40);
+            /* reset the peripheral and the emac hold the temac in
reset since this bit is not self-clearing */
+            mtdcr(lp->dcr_host, XGP_CON_REG_TEMAC_RESET);
+            mdelay(40);
+
+            /*
+               reset the peripheral. This is self-clearing. This will
also kick
+               the temac and PHY out of reset. 
+               Note that this may enable the Tx/Rx of the
+               temac if tied-off that way in hardware, but that should
be OK.
+             */
+            mtdcr(lp->dcr_host, XGP_CON_REG_PERIPH_RESET);
+            mdelay(40);
+
+            mtdcr(lp->dcr_host, 0);
+            mdelay(40);
+            break;
+#endif
+    }
+    /* Sync default options with HW but leave receiver and transmitter
disabled.  */
+    temac_setoptions(ndev, lp->options &
~(XTE_TRANSMITTER_ENABLE_OPTION | XTE_RECEIVER_ENABLE_OPTION));
+
+    /* Set default MDIO divisor */
+    /* Set up MII management registers to write to PHY  */
+    emac_cfg_write(ndev, PHY_NUM, XTE_MC_OFFSET, XTE_MC_MDIO_MASK |
XTE_MDIO_DIV_DFT);
+
+    /*
+    Set A-N Advertisement Regs for Full Duplex modes ONLY
+    address 4 = Autonegotiate Advertise Register
+    Disable 1000 Mbps for negotiation if not built for GEth
+    */
+    mdio_write(ndev, PHY_NUM, MII_ADVERTISE,  mdio_read(ndev, PHY_NUM,
MII_ADVERTISE) | ADVERTISE_10FULL | ADVERTISE_100FULL | ADVERTISE_CSMA);
+    mdio_write(ndev, PHY_NUM, MII_CTRL1000, ADVERTISE_1000FULL);
+
+    /*
+    Soft reset the PHY
+    address 0 = Basic Mode Control Register
+    */
+    mdio_write(ndev, PHY_NUM, MII_BMCR, mdio_read(ndev, PHY_NUM,
MII_BMCR) | BMCR_RESET | BMCR_ANENABLE | BMCR_ANRESTART);
+
+    /* Wait for a PHY Link (auto-negotiation to complete)...  */
+    // if (lp->dbg) printk("\nWaiting for ethernet link..");
+    ret = mdio_read(ndev, PHY_NUM, MII_BMSR);
+    ii = 64;
+    while (((ret & BMSR_LSTATUS) != BMSR_LSTATUS) && ii--) {
+        DEBUG_PRINTK(".");
+        mdelay(500);
+        ret = mdio_read(ndev, PHY_NUM, MII_BMSR);
+    }
+    ret = mdio_read(ndev, PHY_NUM, MII_SSR) ;
+
+    Reg = emac_cfg_read(ndev, PHY_NUM, XTE_EMCFG_OFFSET) &
~XTE_EMCFG_LINKSPD_MASK;
+    if (ret & MII_SSR_LINK) {
+        switch (ret & MII_SSR_SPDMASK) {
+            case MII_SSR_SPD1000:                           /*
1000Base-T */
+                lp->LinkSpeed = 1000;
+                emac_cfg_write(ndev, PHY_NUM, XTE_EMCFG_OFFSET, Reg |
(u32)XTE_EMCFG_LINKSPD_1000);
+                break;
+            case MII_SSR_SPD100:                            /* 100Base-T */
+                lp->LinkSpeed = 100;
+                emac_cfg_write(ndev, PHY_NUM, XTE_EMCFG_OFFSET, Reg |
XTE_EMCFG_LINKSPD_100);
+                break;
+            case MII_SSR_SPD10:                             /* 10Base-T */
+                lp->LinkSpeed = 10;
+                // emac_cfg_write(ndev, 0, XTE_EMCFG_OFFSET,
XTE_EMCFG_LINKSPD_10);
+                break;
+        };
+        if ((ret & MII_SSR_FD) == 0x0){
+            /* set up Tx/Rx config reg for half duplex */
+            ret = emac_cfg_read(ndev, 0, XTE_TXC_OFFSET);
+            emac_cfg_write(ndev, 0, XTE_TXC_OFFSET, ret |
XTE_TXC_TXHD_MASK);
+            ret = emac_cfg_read(ndev, 0, XTE_RXC1_OFFSET);
+            emac_cfg_write(ndev, 0, XTE_RXC1_OFFSET, ret |
XTE_RXC1_RXHD_MASK);
+        }
+        // DEBUG_PRINTK("\nEthernet connected at %dMbps Full-Duplex",
lp->LinkSpeed);
+    } else {
+        if ((ret & MII_SSR_LINK) == 0x0)
+            DEBUG_PRINTK("\nEthernet Link Down");
+    }
+    temac_set_mac_address(ndev,0);
+    /* Set address filter table */
+    temac_set_multicast_list(ndev);
+    if (lp->nic_type == TEMAC_PLB) {
+        lp->options &=  ~XTE_FCS_INSERT_OPTION  ;
+            // XTE_JUMBO_OPTION | XTE_TRANSMITTER_ENABLE_OPTION |
XTE_RECEIVER_ENABLE_OPTION | XTE_FLOW_CONTROL_OPTION |
XTE_BROADCAST_OPTION | XTE_FCS_STRIP_OPTION  | XTE_LENTYPE_ERR_OPTION |
XTE_REPORT_RXERR_OPTION | XTE_REPORT_TXSTATUS_OVERRUN_OPTION;
+    }
+    if (lp->poll) lp->options |= XTE_POLLED_OPTION ;
+    if (temac_setoptions(ndev, lp->options))
+         DEBUG_PRINTK("Error setting TEMAC options, code %d\r\n", ret);
+    if (lp->nic_type == TEMAC_PLB) {
+        /* Allow interrupts (if not in polled mode) and exit */
+        // DEBUG_PRINTK("temac->options %0x\n", lp->options);
+        if ((lp->options & XTE_POLLED_OPTION) == 0) {
+            iow(ndev, XTE_DGIE_OFFSET, (u32) XTE_DGIE_ENABLE_MASK);
+            // DEBUG_PRINTK("enable interrupts\n");
+        }
+    }
+#if !defined(LINUX)
+    phyInit(&lp->mii_if, (void *) lp, g_mdio_read, mdio_write);
+
+    result = phySearch(&lp->mii_if);
+
+    if (result == Success) {
+        LinkSpeed   linkSpeed;
+        LinkStatus  linkStatus;
+        LinkDuplex  linkDuplex;
+
+        lp->mii_if.GetLinkStatus(&lp->mii_if, &linkSpeed, &linkStatus,
&linkDuplex);
+        if (linkDuplex == LinkFullDuplex) {
+            emac_cfg_write(lp, PHY_NUM, XTE_RXC1_OFFSET,
(emac_cfg_read(lp, PHY_NUM, XTE_RXC1_OFFSET) & ~XTE_RXC1_RXHD_MASK));
+            emac_cfg_write(lp, PHY_NUM, XTE_TXC_OFFSET, 
(emac_cfg_read(lp, PHY_NUM, XTE_TXC_OFFSET) & ~XTE_TXC_TXHD_MASK));
+            DEBUG_PRINTK("\ntemac_phy_init(FD)");
+        } else {
+            emac_cfg_write(lp, PHY_NUM, XTE_RXC1_OFFSET,
(emac_cfg_read(lp, PHY_NUM, XTE_RXC1_OFFSET) | XTE_RXC1_RXHD_MASK));
+            emac_cfg_write(lp, PHY_NUM, XTE_TXC_OFFSET, 
(emac_cfg_read(lp, PHY_NUM, XTE_TXC_OFFSET) | XTE_TXC_TXHD_MASK));
+            DEBUG_PRINTK("\ntemac_phy_init(HD)");
+        }
+        Reg = emac_cfg_read(lp, PHY_NUM, XTE_EMCFG_OFFSET) &
~XTE_EMCFG_LINKSPD_MASK;
+        switch (linkSpeed) {
+            case Link1000Mbps:
+                emac_cfg_write(lp, PHY_NUM, XTE_EMCFG_OFFSET, Reg |
(u32) XTE_EMCFG_LINKSPD_1000);
+                DEBUG_PRINTK("\ntemac_phy_init(1000)");
+                break;
+            case Link100Mbps:
+                emac_cfg_write(lp, PHY_NUM, XTE_EMCFG_OFFSET, Reg |
XTE_EMCFG_LINKSPD_100);
+                DEBUG_PRINTK("\ntemac_phy_init(100)");
+                break;
+            case Link10Mbps:
+                emac_cfg_write(lp, PHY_NUM, XTE_EMCFG_OFFSET, Reg |
XTE_EMCFG_LINKSPD_10);
+                DEBUG_PRINTK("\ntemac_phy_init(10)");
+                break;
+            case LinkSpeedAuto:
+                emac_cfg_write(lp, PHY_NUM, XTE_EMCFG_OFFSET, Reg |
XTE_EMCFG_LINKSPD_100);
+                DEBUG_PRINTK("\ntemac_phy_init(auto)");
+            default:
+                emac_cfg_write(lp, PHY_NUM, XTE_EMCFG_OFFSET, Reg |
XTE_EMCFG_LINKSPD_100);
+                DEBUG_PRINTK("\ntemac_phy_init(??)
linkSpeed=%d",linkSpeed);
+                break;
+        }
+    }
+#endif
+    /*
+    Print PHY regs so that we can see if they are configured correctly
+    */
+    // if(lp->dbg) temac_dump(ndev);
+// Turns on packet generator and stops (Test Only)
+#if(0)
+    mdio_write(ndev, 0, XGP_PCS_EXTADDR_REG, 0x12);
+    Data = mdio_read(ndev, 0, XGP_PCS_EXTADDR_REG);
+    mdio_write(ndev, 0, XGP_PCS_EXTFUNC_REG, Data | 0x38);
+    while (1);
+#endif
+
+    /* Init Driver variable */
+    ndev->trans_start = 0;
+    spin_lock_init(&lp->lock);
+}
+
+/*****************************************************************************/
+/**
+ * Set options for the driver/device. The driver should be stopped with
+ * XTemac_Stop() before changing options.
+ *
+ * @param InstancePtr is a pointer to the instance to be worked on.
+ * @param Options are the options to set. Multiple options can be set
by OR'ing
+ *        XTE_*_OPTIONS constants together. Options not specified are not
+ *        affected.
+ *
+ * @return
+ * - 0 if the options were set successfully
+ * - XST_DEVICE_IS_STARTED if the device has not yet been stopped
+ * - XST_NO_FEATURE if setting an option requires HW support not present
+ *
+ * @note
+ * See xtemac.h for a description of the available options.
+ *
+
******************************************************************************/
+static u32
+temac_setoptions(struct net_device *ndev, u32 Options) {
+    struct temac_local *lp = ndev->priv;
+
+    /* Turn on jumbo packet support for both Rx and Tx */
+    if (Options & XTE_JUMBO_OPTION) {
+        emac_cfg_write(ndev, PHY_NUM, XTE_TXC_OFFSET,
emac_cfg_read(ndev, PHY_NUM, XTE_TXC_OFFSET) | XTE_TXC_TXJMBO_MASK);
+        emac_cfg_write(ndev, PHY_NUM, XTE_RXC1_OFFSET,
emac_cfg_read(ndev, PHY_NUM, XTE_RXC1_OFFSET) | XTE_RXC1_RXJMBO_MASK);
+    } else {
+        emac_cfg_write(ndev, PHY_NUM, XTE_TXC_OFFSET,
emac_cfg_read(ndev, PHY_NUM, XTE_TXC_OFFSET) & ~XTE_TXC_TXJMBO_MASK);
+        emac_cfg_write(ndev, PHY_NUM, XTE_RXC1_OFFSET,
emac_cfg_read(ndev, PHY_NUM, XTE_RXC1_OFFSET) & ~XTE_RXC1_RXJMBO_MASK);
+    }
+
+    /* Turn on VLAN packet support for both Rx and Tx */
+    if (Options & XTE_VLAN_OPTION) {
+        emac_cfg_write(ndev, PHY_NUM, XTE_TXC_OFFSET,
emac_cfg_read(ndev, PHY_NUM, XTE_TXC_OFFSET) | XTE_TXC_TXVLAN_MASK);
+        emac_cfg_write(ndev, PHY_NUM, XTE_RXC1_OFFSET,
emac_cfg_read(ndev, PHY_NUM, XTE_RXC1_OFFSET) | XTE_RXC1_RXVLAN_MASK);
+    } else {
+        emac_cfg_write(ndev, PHY_NUM, XTE_TXC_OFFSET,
emac_cfg_read(ndev, PHY_NUM, XTE_TXC_OFFSET) & ~XTE_TXC_TXVLAN_MASK);
+        emac_cfg_write(ndev, PHY_NUM, XTE_RXC1_OFFSET,
emac_cfg_read(ndev, PHY_NUM, XTE_RXC1_OFFSET) & ~XTE_RXC1_RXVLAN_MASK);
+    }
+
+    /* Turn on FCS stripping on receive packets */
+    if (Options & XTE_FCS_STRIP_OPTION) {
+        emac_cfg_write(ndev, PHY_NUM, XTE_RXC1_OFFSET,
emac_cfg_read(ndev, PHY_NUM, XTE_RXC1_OFFSET) | XTE_RXC1_RXFCS_MASK);
+    } else {
+        emac_cfg_write(ndev, PHY_NUM, XTE_RXC1_OFFSET,
emac_cfg_read(ndev, PHY_NUM, XTE_RXC1_OFFSET) & ~ XTE_RXC1_RXFCS_MASK);
+    }
+
+    /* Turn on FCS insertion on transmit packets */
+    if (Options & XTE_FCS_INSERT_OPTION) {
+        emac_cfg_write(ndev, PHY_NUM, XTE_TXC_OFFSET,
emac_cfg_read(ndev, PHY_NUM, XTE_TXC_OFFSET) | XTE_TXC_TXFCS_MASK);
+    } else {
+        emac_cfg_write(ndev, PHY_NUM, XTE_TXC_OFFSET,
emac_cfg_read(ndev, PHY_NUM, XTE_TXC_OFFSET) & ~XTE_TXC_TXFCS_MASK);
+    }
+
+    /* Turn on length/type field checking on receive packets */
+    if (Options & XTE_LENTYPE_ERR_OPTION) {
+        emac_cfg_write(ndev, PHY_NUM, XTE_RXC1_OFFSET,
emac_cfg_read(ndev, PHY_NUM, XTE_RXC1_OFFSET) | XTE_RXC1_RXLT_MASK);
+    } else {
+        emac_cfg_write(ndev, PHY_NUM, XTE_RXC1_OFFSET,
emac_cfg_read(ndev, PHY_NUM, XTE_RXC1_OFFSET) & ~XTE_RXC1_RXLT_MASK);
+    }
+
+
+    /* Rest of options twiddle bits of other registers. Handle them one at
+     * a time
+     */
+
+    /* Turn on flow control */
+    if (Options & XTE_FLOW_CONTROL_OPTION) {
+        emac_cfg_write(ndev, PHY_NUM, XTE_FCC_OFFSET,
emac_cfg_read(ndev, PHY_NUM, XTE_FCC_OFFSET) | XTE_FCC_RXFLO_MASK);
+    } else {
+        emac_cfg_write(ndev, PHY_NUM, XTE_FCC_OFFSET,
emac_cfg_read(ndev, PHY_NUM, XTE_FCC_OFFSET) & ~XTE_FCC_RXFLO_MASK);
+    }
+
+    /* Turn on promiscuous frame filtering (all frames are received ) */
+    if (Options & XTE_PROMISC_OPTION) {
+        emac_cfg_write(ndev, PHY_NUM, XTE_AFM_OFFSET,
emac_cfg_read(ndev, PHY_NUM, XTE_AFM_OFFSET) | XTE_AFM_EPPRM_MASK);
+    } else {
+        emac_cfg_write(ndev, PHY_NUM, XTE_AFM_OFFSET,
emac_cfg_read(ndev, PHY_NUM, XTE_AFM_OFFSET) & ~XTE_AFM_EPPRM_MASK);
+    }
+
+    /* Allow broadcast address filtering */
+    if (Options & XTE_BROADCAST_OPTION) {
+        iow(ndev, XTE_CR_OFFSET, ior(ndev, XTE_CR_OFFSET) &
~XTE_CR_BCREJ_MASK);
+    } else {
+        iow(ndev, XTE_CR_OFFSET, ior(ndev, XTE_CR_OFFSET) |
XTE_CR_BCREJ_MASK);
+    }
+
+    /* Allow multicast address filtering */
+    if (Options & XTE_MULTICAST_CAM_OPTION) {
+        iow(ndev, XTE_CR_OFFSET, ior(ndev, XTE_CR_OFFSET) &
~XTE_CR_MCREJ_MASK);
+    } else {
+        iow(ndev, XTE_CR_OFFSET, ior(ndev, XTE_CR_OFFSET) |
XTE_CR_MCREJ_MASK);
+    }
+
+    /* Enable interrupts related to rejection of bad frames */
+    if (Options & XTE_REPORT_RXERR_OPTION) {
+        /* Clear out any previous error conditions that may have existed
+         * prior to enabling the reporting of these types of errors
+         */
+        iow(ndev, XTE_IPISR_OFFSET, ior(ndev, XTE_IPISR_OFFSET) &
XTE_IPXR_RECV_DROPPED_MASK );
+
+        /* Whether these are enabled here are based on the last call to
+         * XTemac_IntrFifoEnable/Disable() and
XTemac_IntrSgDmaEnable/Disable()
+         * for the receive channel.
+         *
+         * If receive interrupts are enabled, then enable these
interrupts. This
+         * way, when XTemac_Start() is called, these interrupt enables
take
+         * effect right away.
+         *
+         * If receive interrupts are disabled, then don't do anything
here. The
+         * XTemac_IntrFifoEnable() and XTemac_IntrSgDmaEnable()
functions when
+         * called will check this option and enable these interrupts if
needed.
+         */
+        // if (lp->Flags & (XTE_FLAGS_RECV_FIFO_INT_ENABLE)) {
+            iow(ndev, XTE_IPIER_OFFSET, ior(ndev, XTE_IPIER_OFFSET) |
XTE_IPXR_RECV_DROPPED_MASK );
+        // }
+    } else {
+        iow(ndev,  XTE_IPIER_OFFSET, ior(ndev,  XTE_IPIER_OFFSET) &
~XTE_IPXR_RECV_DROPPED_MASK);
+    }
+   
+
+    /* Enable interrrupt related to assertion of auto-negotiate HW
interrupt */
+    if (Options & XTE_ANEG_OPTION) {
+        /* Clear out any previous interupt condition that may have existed
+         * prior to enabling the reporting of auto negotiation
+         */
+        iow(ndev, XTE_IPISR_OFFSET, ior(ndev, XTE_IPISR_OFFSET) &
XTE_IPXR_AUTO_NEG_MASK);
+
+        /* Make this interupt source enabled when XTemac_Start() is
called */
+        iow(ndev, XTE_IPIER_OFFSET, ior(ndev, XTE_IPIER_OFFSET) &
XTE_IPXR_AUTO_NEG_MASK);
+    } else {
+        iow(ndev, XTE_IPIER_OFFSET, ior(ndev, XTE_IPIER_OFFSET) &
~XTE_IPXR_AUTO_NEG_MASK);
+    }
+   
+
+    /* Enable transmitter if not already enabled */
+    if (Options & XTE_TRANSMITTER_ENABLE_OPTION) {
+        emac_cfg_write(ndev, PHY_NUM, XTE_TXC_OFFSET,
emac_cfg_read(ndev, PHY_NUM, XTE_TXC_OFFSET) | XTE_TXC_TXEN_MASK); 
+        if (!(lp->options & XTE_POLLED_OPTION)) {
+            iow(ndev, XTE_IPIER_OFFSET, ior(ndev, XTE_IPIER_OFFSET) |
XTE_IPXR_XMIT_DONE_MASK);
+            if (lp->options & XTE_REPORT_TXSTATUS_OVERRUN_OPTION)
+                iow(ndev, XTE_IPIER_OFFSET, ior(ndev, XTE_IPIER_OFFSET)
| XTE_IPXR_XMIT_SFIFO_OVER_MASK);
+        }
+    } else {
+        emac_cfg_write(ndev, PHY_NUM, XTE_TXC_OFFSET,
emac_cfg_read(ndev, PHY_NUM, XTE_TXC_OFFSET) & ~XTE_TXC_TXEN_MASK);
+    }
+
+
+    /* Enable receiver? */
+    if (Options & XTE_RECEIVER_ENABLE_OPTION) {
+        emac_cfg_write(ndev, PHY_NUM, XTE_RXC1_OFFSET,
emac_cfg_read(ndev, PHY_NUM, XTE_RXC1_OFFSET) | XTE_RXC1_RXEN_MASK);
+        if (!(lp->options & XTE_POLLED_OPTION)) {
+            iow(ndev, XTE_IPIER_OFFSET, ior(ndev, XTE_IPIER_OFFSET) |
XTE_IPXR_RECV_DONE_MASK);
+            if (lp->options & XTE_REPORT_TXSTATUS_OVERRUN_OPTION)
+                iow(ndev, XTE_IPIER_OFFSET, ior(ndev, XTE_IPIER_OFFSET)
| XTE_IPXR_RECV_DROPPED_MASK);
+        }
+    } else {
+        emac_cfg_write(ndev, PHY_NUM, XTE_RXC1_OFFSET,
emac_cfg_read(ndev, PHY_NUM, XTE_RXC1_OFFSET) & ~XTE_RXC1_RXEN_MASK);
+    }
+
+    /* The remaining options not handled here are managed elsewhere in the
+ * driver. No register modifications are needed at this time.
Reflecting the
+     * option in lp->Options is good enough for now.
+     */
+
+    /* Set options word to its new value */
+    lp->options |= Options;
+
+    return (0);
+}
+
+#if defined(CONFIG_PICO_LL_TEMAC)
+#define LL_SOF_MASK                     ((1 << 8))
+#define LL_EOF_MASK                     ((1 << 7))
+#define LL_SOP_MASK                     ((1 << 6))
+#define LL_EOP_MASK                     ((1 << 5))
+#define LL_RX_SRC_RDY_MASK              ((1 << 4))
+#define LL_REM_MASK                     (0x0000000F)
+
+#define LL_TX_DATA                      0x00
+#define LL_TX_CTRL                      0x08
+#define LL_TX_RDY                       0x10
+#define LL_RX_DATA                      0x20
+#define LL_RX_CTRL                      0x28
+#define LL_RX_RDY                       0x30
+
+static int
+ll_recvFrame(struct net_device *ndev, struct sk_buff *skb, u8 *bd) {
+    struct temac_local *lp = ndev->priv;
+    u32 cw;
+    u32 dw;
+    u32 src_rdy_counter = 0;
+    u32 sof_counter = 0;
+    enum { S_IDLE=1, S_HEADER, S_PAYLOAD, S_FOOTER } state = S_IDLE;
+    const u32 src_rdy_counter_max = 10;
+    const u32 sof_counter_max = 10;
+    u8 *b ;
+
+    // DEBUG_FUNC;
+    // skb->data SHOULD == skb-->tail;
+    b = skb->tail ;
+    skb->len = 0;
+    while (1) {
+
+        /*  read the control word to see if the source ready bit is
active (low) */
+        while (((cw = ior(ndev,LL_RX_CTRL)) & LL_RX_SRC_RDY_MASK) ==
LL_RX_SRC_RDY_MASK) {
+
+            /* only hang around for some amount of time waiting for
data to be present */
+            if (++src_rdy_counter == src_rdy_counter_max) {
+                skb->len = 0;
+                return SRC_RDY_TIMEOUT_ERROR;
+            }
+        }
+
+        /* reset watchdog counter */
+        src_rdy_counter = 0;
+        /*
+        IDLE STATE
+        */
+        if (state == S_IDLE) {
+
+            /*
+            haven't reached the SOF yet
+            only hang around for so long awaiting an SOF before returning
+            */
+            if ((cw & LL_SOF_MASK)) {
+                if (++sof_counter == sof_counter_max) {
+                    skb->len = 0;
+                    return SOF_TIMEOUT_ERROR;
+                }
+            }
+
+            else {
+
+                /*
+                reset watchdog counter
+                */
+                sof_counter = 0;
+                /*
+                ensure we record the start of a frame
+                */
+                state = S_HEADER;
+            }
+
+            /* ignore the LocalLink Header Words */
+            dw = ior(ndev,LL_RX_DATA);
+        }
+        /*
+        HEADER STATE
+        */
+        else if (state == S_HEADER) {
+            dw = ior(ndev, LL_RX_DATA);
+            if (!(cw & LL_SOP_MASK)) {
+                state = S_PAYLOAD;
+                *((u32 *) b) = dw;
+                b += 4;
+                skb->len += 4;
+                skb->tail += 4;
+            }
+        }
+        /* PAYLOAD STATE */
+        else if (state == S_PAYLOAD) {
+            *((u32 *) b) = ior(ndev,LL_RX_DATA);
+            b += 4;
+            skb->len += 4;
+            skb->tail += 4;
+            if (!(cw & LL_EOP_MASK))
+                state = S_FOOTER;
+        }
+        /* FOOTER STATE */
+        else if (state == S_FOOTER) {
+            *((u32 *) bd) = ior(ndev,LL_RX_DATA);
+            bd += 4;
+            if (!(cw & LL_EOF_MASK)) {
+
+                /* we've got the last data word */
+                cw = ~cw & LL_REM_MASK;
+                /* update the payload count according to the (masked)
rem value */
+                while (cw) {
+                    if (cw & 1)
+                        skb->len++;
+                    cw >>= 1;
+                }
+
+                /* return success */
+                return 0;
+            }
+        }
+    }
+}
+
+static u8
+recvBd[] = {
+    0x00, 0x00, 0x00, 0x00,
+    0x00, 0x00, 0x00, 0x00,
+    0x00, 0x00, 0x00, 0x00,
+    0x00, 0x00, 0x00, 0x00,
+    0x00, 0x00, 0x00, 0x00,
+    0x00, 0x00, 0x00, 0x00,
+    0x00, 0x00, 0x00, 0x00,
+    0x00, 0x00, 0x00, 0x00
+};
+
+static void
+ll_temac_interrupt(struct net_device *ndev) {
+    struct temac_local *lp = ndev->priv;
+    /*  read the control word to see if the source ready bit is active
(low) */
+    while ((ior(ndev, LL_RX_CTRL) & LL_RX_SRC_RDY_MASK) !=
LL_RX_SRC_RDY_MASK)  {
+        u32 ret ;
+        struct sk_buff *skb;
+        skb = dev_alloc_skb(XTE_MAX_FRAME_SIZE);
+        if (!skb) {
+            if (printk_ratelimit())
+                DEBUG_PRINTK("temac: low on memory - packet dropped\n");
+            lp->stats.rx_dropped++;
+            spin_unlock(&lp->lock);
+            return ;
+            // return IRQ_HANDLED;
+        }
+        if ((ret = ll_recvFrame(ndev, skb, recvBd))) {
+            DEBUG_PRINTK("\nwhoops=%x",ret);
+        } else {
+            // if (lp->dbg) dump_skb_data(skb, "Recv");
+            /* Pass to upper layer */
+            skb->dev = ndev;
+            skb->protocol = eth_type_trans(skb, ndev);
+            lp->stats.rx_bytes += skb->len;
+            lp->stats.rx_packets++;
+            netif_rx(skb);
+        }
+    }
+}
+#endif
+
+static void
+FifoRecvHandler(struct net_device *ndev);
+
+static void
+plb_temac_interrupt(struct net_device *ndev) {
+    struct temac_local *lp = ndev->priv;
+    u32 disr ;
+    u32 ipisr ;
+ 
+    // DEBUG_FUNC;
+    /* Get top level interrupt status. The status is self clearing when
the interrupt source is cleared */
+    disr = ior(ndev, XTE_DISR_OFFSET);
+#if 0
+    DEBUG_PRINTK("\nDISR %08x",disr);
+    if (disr & (XTE_DXR_DPTO_MASK | XTE_DXR_TERR_MASK)) {
+        lp->IpifErrors++;
+        DEBUG_PRINTK("\ntemac_interrupt_fifo() TERR");
+        // ErrorHandler(XST_IPIF_ERROR, disr, 0);
+    }
+    /* Receive packet FIFO is deadlocked */
+    if (disr & XTE_DXR_RECV_FIFO_MASK) {
+        lp->RxPktFifoErrors++;
+        DEBUG_PRINTK("\ntemac_interrupt_fifo() RX DEADLOCK");
+    }
+    /* Transmit packet FIFO is deadlocked */
+    if (disr & XTE_DXR_SEND_FIFO_MASK) {
+        lp->TxPktFifoErrors++;
+        DEBUG_PRINTK("\ntemac_interrupt_fifo() TX DEADLOCK");          
+    }
+#endif
+    /* Handle core interrupts */
+    if (disr & XTE_DXR_CORE_MASK) {
+        /* Calculate which enabled interrupts have been asserted */
+        ipisr = ios(ndev);
+        if (!ipisr) {
+            DEBUG_PRINTK("\ntemac_interrupt_fifo() !ipisr");           
+            return ;
+        }
+
+        // DEBUG_PRINTK("\nIPISR %0x", ior(ndev, XTE_IPISR_OFFSET));
+        // DEBUG_PRINTK("\nIPIER %0x", ior(ndev, XTE_IPIER_OFFSET));
+
+        /* Check for fatal status/length FIFO errors. These errors
can't be * cleared */
+        if (ipisr & XTE_IPXR_FIFO_FATAL_ERROR_MASK) {
+#if 0
+            lp->FifoErrors++;
+            DEBUG_PRINTK("\ntemac_interrupt_fifo() Fatal FIFO ERR");
+
+#if !defined(LINUX)
+            if (ipisr & XTE_IPXR_RECV_LFIFO_OVER_MASK) {    /* requires
reset */
+                EnetDbPrint(&lp->enetDevice, "Rx Length FIFO Overrun");
+                DEBUG_PRINTK("\nRx Length FIFO Overrun");
+            }
+
+            if (ipisr & XTE_IPXR_RECV_LFIFO_UNDER_MASK) {   /* requires
reset */
+                EnetDbPrint(&lp->enetDevice, "Rx Length FIFO Underrun");
+                DEBUG_PRINTK("\nRx Length FIFO Underrun");
+            }
+#endif
+            if (ipisr & XTE_IPXR_XMIT_SFIFO_OVER_MASK) {    /* requires
reset */
+                EnetDbPrint(&lp->enetDevice, "Tx Status FIFO Overrun");
+                DEBUG_PRINTK("\nTx Status FIFO Overrun");
+            }
+
+            if (ipisr & XTE_IPXR_XMIT_SFIFO_UNDER_MASK) {   /* requires
reset */
+                EnetDbPrint(&lp->enetDevice, "Tx Status FIFO Underrun");
+                DEBUG_PRINTK("\nTx Status FIFO Underrun");
+            }
+
+            if (ipisr & XTE_IPXR_XMIT_LFIFO_OVER_MASK) {    /* requires
reset */
+                EnetDbPrint(&lp->enetDevice, "Tx Length FIFO Overrun");
+                DEBUG_PRINTK("\nTx Length FIFO Overrun");
+            }
+
+            if (ipisr & XTE_IPXR_XMIT_LFIFO_UNDER_MASK) {   /* requires
reset */
+                EnetDbPrint(&lp->enetDevice, "Tx Length FIFO Underrun");
+                DEBUG_PRINTK("\nTx Length FIFO Underrun");
+            }
+#endif
+            // ErrorHandler(XST_FIFO_ERROR, CorePending &
XTE_IPXR_FIFO_FATAL_ERROR_MASK, 0);
+            temac_device_reset(ndev);
+        }
+        /* A receive packet has arrived. Call the receive handler.
+         *
+         * Acking this interrupt is not done here. The handler has a
choice:
+         * 1) Call XTemac_FifoRecv() which will ack this interrupt
source, or
+         * 2) Call XTemac_IntrFifoDisable() and defer XTEmac_FifoRecv()
to a
+         * later time. Failure to do one of these actions will leave this
+         * interupt still pending resulting in an exception loop.
+         */
+        if (ipisr & XTE_IPXR_RECV_DONE_MASK) {
+            // DEBUG_PRINTK("\ntemac_interrupt_fifo() FifoRecv()");
+            FifoRecvHandler(ndev);
+        }
+
+        /* A transmit has completed. Pull off all statuses that are
available.
+         * For each status that contains a non-fatal error, the error
handler
+         * is invoked. For fatal errors, the error handler is invoked
once and
+         * assumes the callback will reset the device.
+         *
+         * Unless there was a fatal error, then call the send handler since
+         * resources in the packet FIFO, transmit length FIFO, and transmit
+         * status FIFO have been freed up. This gives the handler a chance
+         * to enqueue new frame(s).
+         */
+        if (ipisr & XTE_IPXR_XMIT_DONE_MASK) {
+           
+            // DEBUG_PRINTK("\nplb_temac_interrupt()
XTE_IPXR_XMIT_DONE_MASK");
+            // DEBUG_PRINTK("\ntemac_interrupt_fifo() XMIT DONE");
+            /* While XMIT_DONE persists */
+            do {
+                u32 Reg;
+                /* Get TSR, try to clear XMIT_DONE */
+                Reg = ior(ndev, XTE_TSR_OFFSET);
+                iow(ndev, XTE_IPISR_OFFSET, XTE_IPXR_XMIT_DONE_MASK);
+
+                /* Does TSR indicate error? */
+                if (Reg & XTE_TSR_ERROR_MASK) {
+                    // lp->TxStatusErrors++;
+                    DEBUG_PRINTK("\ntemac_interrupt_fifo() Send Error");
+                    // ErrorHandler(XST_SEND_ERROR, Reg, 0);
+
+                    /* Fatal errors end processing immediately */
+                    if (Reg & XTE_TSR_PFIFOU_MASK) {
+                        return;
+                    }
+                }
+
+                /* Read IPISR and test XMIT_DONE again */
+                ipisr = ior(ndev, XTE_IPISR_OFFSET);
+            } while (ipisr & XTE_IPXR_XMIT_DONE_MASK);
+            // lp->stats.tx_packets++;
+        }
+
+        /* Check for dropped receive frame. Ack the interupt then call the
+         * error handler
+         */
+        if (ipisr & XTE_IPXR_RECV_DROPPED_MASK) {
+            iow(ndev, XTE_IPISR_OFFSET, ipisr &
XTE_IPXR_RECV_DROPPED_MASK);
+            // lp->RxRejectErrors++;
+            // DEBUG_PRINTK("\nplb_temac_interrupt_fifo() RX DROPPED");
+        }
+    }
+    // DEBUG_FUNC_EXIT;
+}
+/****************************************************************************
+ *                         Device Operational Functions                 *
+ *                                          *
+ * These functions are used to operate the device at runtime            *
+
****************************************************************************/
+
+static irqreturn_t
+temac_interrupt(int irq, void *ndev_id, struct pt_regs *regs) {
+    struct net_device *ndev = ndev_id;
+    struct temac_local *lp = ndev->priv;
+    // DEBUG_FUNC;
+    if (!ndev) {
+        if (lp->dbg) printk ("temac_interrupt() without DEVICE arg\n");
+        return IRQ_HANDLED;
+    }
+#if 0
+    switch (irq) {
+        case -1:
+            if (lp->dbg) printk ("temac_interrupt() NET_POLL\n");
+            break;
+        case -2:
+            // if (lp->dbg) printk ("temac_interrupt()
temac_rx_timeout()\n");
+            break;
+        case 0:
+            /* Call it. */
+            // if (lp->dbg) printk("temac_interrupt() INT\n");
+           //  lp->Interrupts++;                               /* Log
interrupt */
+            break;
+        default:
+            /* Call it. */
+            if (lp->dbg) printk("temac_interrupt() IRQ=%d\n",irq);
+            break;
+    }
+#endif
+
+    /* A real interrupt coming */
+    spin_lock(&lp->lock);
+#if defined(CONFIG_PICO_LL_TEMAC)
+    switch (lp->nic_type) {
+        case TEMAC_PLB:
+            plb_temac_interrupt(ndev);
+            break;
+
+        case TEMAC_LL:
+            ll_temac_interrupt(ndev);
+            break;
+    }
+#else
+    plb_temac_interrupt(ndev);
+#endif
+
+#if 0
+    /* read from PHY status register */
+    ret = mdio_read(ndev, PHY_NUM, MII_FCSCOUNTER);
+    if (lp->phy_status != ret) {
+        lp->phy_status = ret;
+        if (lp->dbg) DEBUG_PRINTK("\nPHY interrupt status register
%08x", ret);
+        if ((ret & 0x00000c00) == (0x00000c00)) {
+            if (lp->dbg) DEBUG_PRINTK("\nautoneg complete , link up");
+        } else if (ret & 0x00000400) {
+            if (lp->dbg) DEBUG_PRINTK("\nlink down");
+        }
+    }
+#endif
+
+#if defined(LINUX)
+    #warning "need to tell linux transmission complete"
+#else
+    EnetNotifyTask(&lp->enetDevice);            // must be called on
transmission or reception complete - should only be called once/interrupt
+#endif
+    spin_unlock(&lp->lock);
+    /* Ack the interrupts we saw and processed */
+    // iow(ndev, XTE_IPISR_OFFSET, ints);
+    // iow(ndev, XTE_DISR_OFFSET, dev_ints);
+    // DEBUG_FUNC_EXIT;
+    return IRQ_HANDLED;
+}
+
+#if defined(CONFIG_PICO_LL_TEMAC)
+static u32
+rem_table[] = {
+    0x0000000F, 0x00000008, 0x0000000C, 0x0000000E,
+};
+
+static int
+ll_sendFrame(struct net_device *ndev, struct sk_buff *skb, u8 *bd) {
+    int i;
+    u32 cw;
+    u32 *bp = (u32 *) skb->data;
+    u32 *bdesc = (u32 *) bd;
+
+    // DEBUG_FUNC;
+    /*
+    Send Buffer Descriptor as LocalLink Header
+    */
+
+    iow(ndev, LL_TX_DATA, bdesc[0]);
+    iow(ndev, LL_TX_CTRL, ~(0xffffffff & (LL_SOF_MASK | LL_REM_MASK)));
+    iow(ndev, LL_TX_DATA, bdesc[1]);
+    iow(ndev, LL_TX_CTRL, ~(0xffffffff & LL_REM_MASK));
+    iow(ndev, LL_TX_DATA, bdesc[2]);
+    iow(ndev, LL_TX_CTRL, ~(0xffffffff & LL_REM_MASK));
+    iow(ndev, LL_TX_DATA, bdesc[3]);
+    iow(ndev, LL_TX_CTRL, ~(0xffffffff & LL_REM_MASK));
+    iow(ndev, LL_TX_DATA, bdesc[4]);
+    iow(ndev, LL_TX_CTRL, ~(0xffffffff & LL_REM_MASK));
+    iow(ndev, LL_TX_DATA, bdesc[5]);
+    iow(ndev, LL_TX_CTRL, ~(0xffffffff & LL_REM_MASK));
+    iow(ndev, LL_TX_DATA, bdesc[6]);
+    iow(ndev, LL_TX_CTRL, ~(0xffffffff & LL_REM_MASK));
+    iow(ndev, LL_TX_DATA, bdesc[7]);
+    iow(ndev, LL_TX_CTRL, ~(0xffffffff & LL_REM_MASK));
+
+    /*
+    Send Ethernet Frame in LocalLink payload
+    */
+    for (i = 0; i < skb->len / 4; i++) {
+
+        /* Assume caches are off */
+        iow(ndev, LL_TX_DATA, bp[i]);
+        cw = 0;
+        /* Detect End of Packet */
+        if (i == (skb->len / 4 - 1)) {
+            if (skb->len % 4) {
+                cw |= LL_REM_MASK;
+            } else {
+                cw |= LL_EOP_MASK | LL_REM_MASK;
+            }
+        }
+        /* Detect Start of Packet */
+        if (i == 0)
+            cw |= LL_SOP_MASK | LL_REM_MASK;
+        if (i > 0 && i < (skb->len / 4 - 1))
+            cw |= LL_REM_MASK;
+        iow(ndev, LL_TX_CTRL, ~(0xffffffff & cw));
+    }
+
+    /*  If skb->len is not a multiple of 4, then send last 1, 2, or 3
bytes... */
+    if (skb->len % 4) {
+        iow(ndev, LL_TX_DATA, bp[i]);
+        cw = LL_EOP_MASK | rem_table[skb->len % 4];
+        iow(ndev, LL_TX_CTRL, ~(0xffffffff & cw));
+    }
+    /*
+    Send Dummy LocalLink Footer
+    */
+    iow(ndev, LL_TX_DATA, 0);
+    iow(ndev, LL_TX_CTRL, ~(0xffffffff & LL_EOF_MASK));
+    return 0;
+}
+#endif
+
+u8 bDescriptor[] = {
+    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0
+};
+static u32 Read_64(struct temac_local *lp, void *BufPtr, u32 ByteCount,
int Eop);
+static u32 Write_64(struct temac_local *lp, void *BufPtr, u32 ByteCount);
+
+static int
+plb_sendFrame(struct net_device *ndev, struct sk_buff *skb, u8 * bd) {
+    struct temac_local *lp = ndev->priv;
+    u32 Reg;
+
+    // DEBUG_FUNC;
+    /* Load the FIFO */
+    /* Transfer the data using the best/fastest method */
+    Write_64(lp, skb->data, skb->len);
+
+    /* Make sure the packet FIFO didn't report an error */
+    Reg = ior(ndev, XTE_DISR_OFFSET);
+    if (Reg & XTE_DXR_SEND_FIFO_MASK) {
+        // DEBUG_PRINTK("\nplb_sendFrame() Error: XTE_DXR_SEND_FIFO_MASK");
+        return -EIO;
+    }
+
+    /* Verify no IPIF errors */
+    if (Reg & (XTE_DXR_DPTO_MASK | XTE_DXR_TERR_MASK)) {
+        /* Only bump stats in polled mode. For interrupt driven mode,
this stat
+         * is bumped in temac_interrupt_fifo()
+         */
+        // DEBUG_PRINTK("\nplb_sendFrame() Error: XTE_DXR_TERR_MASK");
+        return -EIO;
+    }
+
+    /* Initiate transmit */
+    /* See if transmit length FIFO is full. If it is, try to clear the
+     * status. If it the status remains, then return an error
+     */
+    Reg = ior(ndev, XTE_IPISR_OFFSET);
+    if (Reg & XTE_IPXR_XMIT_LFIFO_FULL_MASK) {
+        iow(ndev, XTE_IPISR_OFFSET, XTE_IPXR_XMIT_LFIFO_FULL_MASK);
+
+        Reg = ior(ndev, XTE_IPISR_OFFSET);
+        if (Reg & XTE_IPXR_XMIT_LFIFO_FULL_MASK) {
+            // lp->FifoErrors++;
+            // DEBUG_PRINTK("\nplb_sendFrame() Error:
XTE_IPIXR_XMIT_LFIFO_FULL_MASK");
+            return -EIO;
+        }
+    }
+
+    // DEBUG_PRINTK("\nplb_sendFrame() XTE_TPLR_OFFSET -start xmit");
+    /* Start transmit */
+    iow(ndev, XTE_TPLR_OFFSET, skb->len);
+   
+    // DEBUG_FUNC_EXIT;
+    return 0;
+}
+
+#define XTE_RX_SINK_BUFFER_SIZE 1024
+static void
+FifoRecvHandler(struct net_device *ndev) {
+    struct temac_local *lp = ndev->priv;
+    struct sk_buff *skb;
+    u32 len;
+    u32 ret = 0;
+    static u32 rx_buffer_sink[XTE_RX_SINK_BUFFER_SIZE / sizeof(u32)];
+
+    // DEBUG_FUNC;
+    spin_lock(&XTE_spinlock);
+    // while ((ret  = XTemac_FifoQueryRecvStatus(ndev)) == XST_NO_DATA
&& NumTries--); // not in interrupt version
+
+    /* If the receive length FIFO is empty, then there's no packet
waiting */
+    if (!((ret = ior(ndev, XTE_IPISR_OFFSET)) & XTE_IPXR_RECV_DONE_MASK)) {
+        // DEBUG_PRINTK("\n%s: XTemac could not read received packet
length, error=%d.\n", ndev->name, ret);
+        lp->stats.rx_errors++;
+        // reset(ndev, __LINE__);
+        spin_unlock(&XTE_spinlock);
+        return;
+    }
+    /* Get the length */
+    len = ior(ndev, XTE_RPLR_OFFSET);
+    // DEBUG_PRINTK("\nlen=%d.\n", len);
+
+    /* The IPXR_RECV_DONE_MASK status bit is tied to the RSR register.
To clear
+     * this condition, read from the RSR (which has no information)
then write
+     * to the IPISR register to ack the status.
+     */
+    ret = ior(ndev, XTE_RSR_OFFSET);
+    iow(ndev, XTE_IPISR_OFFSET, XTE_IPXR_RECV_DONE_MASK);
+
+    if (!(skb = dev_alloc_skb(len + ALIGNMENT_RECV))) {
+        /* Couldn't get memory. */
+        lp->stats.rx_dropped++;
+        // DEBUG_PRINTK("\n%s: XTemac could not allocate receive
buffer.", ndev->name);
+
+        /* consume data in Xilinx TEMAC RX data fifo so it is sync with
RX length fifo */
+        for (; len > XTE_RX_SINK_BUFFER_SIZE; len -=
XTE_RX_SINK_BUFFER_SIZE) {
+            Read_64(lp, rx_buffer_sink, XTE_RX_SINK_BUFFER_SIZE,
XTE_PARTIAL_PACKET);
+        }
+        Read_64(lp, rx_buffer_sink, len, XTE_END_OF_PACKET);
+
+        spin_unlock(&XTE_spinlock);
+        return;
+    }
+    /* Read the packet data */
+    if ((ret = Read_64(lp, skb->data, len, XTE_END_OF_PACKET))) {
+        lp->stats.rx_errors++;
+        dev_kfree_skb_irq(skb);
+        // DEBUG_PRINTK("\n%s: XTemac could not receive buffer,
error=%d.", ndev->name, ret);
+        // reset(lp, __LINE__);
+        spin_unlock(&XTE_spinlock);
+        return;
+    }
+    spin_unlock(&XTE_spinlock);
+
+    skb_put(skb, len);  /* Tell the skb how much data we got. */
+    // if (lp->dbg) dump_skb(lp, skb);
+    // if (lp->dbg) dump_skb_data(lp, skb, "recv");
+    skb->dev = ndev;  /* Fill out required meta-data. */
+    lp->stats.rx_bytes += skb->len;
+
+#if !defined(LINUX)
+/*
+This function must be called when a packet is successfully received.
+user_data should be the value that was passed in as an argument to
EtherRead().
+pkt and len specify the packet that was received.
+ returns true/false. if false the buffer should be reused
+*/
+       
+    packetUsed = EnetPacketReceived(&lp->enetDevice, (Address)
skb->data, skb->len, skb->user_data);
+    if (packetUsed) {
+        dev_kfree_skb_irq(skb);
+    } else {
+        // mark SKB available
+        skb->flags &= ~SKB_ALLOC ;              // not allocated
+        skb->len = 0;
+        skb->tail = skb->data;
+    }
+
+#endif
+    skb->protocol = eth_type_trans(skb, ndev);
+    // DEBUG_PRINTK("\nskb->protocol=%x", skb->protocol);
+    /* skb->ip_summed = CHECKSUM_NONE; */
+    ret = netif_rx(skb);                     /* Send the packet
upstream. */
+    ndev->last_rx = jiffies;
+    lp->stats.rx_packets++;
+    // DEBUG_FUNC_EXIT;
+}
+
+/*******************************************************************************
+* Read into the 64 bit holding buffer from the receive packet FIFO.
+* Each time the holding buffer becomes full, then it is flushed to the
+* provided buffer.
+*
+* @param F is a pointer to the packet FIFO instance to be worked on.
+* @param BufPtr is the destination buffer address on any alignment
+* @param ByteCount is the number of bytes to transfer
+*
+*******************************************************************************/
+static void
+Read64_Unaligned(struct temac_local *lp, void *BufPtr, u32 ByteCount) {
+    struct temac_pktFifo * F = &lp->RecvFifo;
+    u8 *DestPtr = (u8 *) BufPtr;
+    unsigned FifoTransfersLeft;
+    unsigned PartialBytes;
+    unsigned BytesLeft;
+    int i;
+
+    // DEBUG_FUNC;
+    /* Stage 1: The hold may have some residual bytes that must be flushed
+     * to the buffer before anything is read from the FIFO
+     */
+
+    /* Calculate the number of bytes to flush to the buffer from the hold.
+     * If the number of bytes to flush is greater than the "Bytes"
requested,
+     * then adjust accordingly.
+     */
+    i = mHold_GetIndex(F);
+    PartialBytes = PFIFO_64BIT_WIDTH_BYTES - i;
+
+    if (PartialBytes > ByteCount) {
+        PartialBytes = ByteCount;
+    }
+
+    /* Calculate the number of bytes remaining after flushing to the
buffer */
+    BytesLeft = ByteCount - PartialBytes;
+
+    /* Move the hold's index forward */
+    mHold_Advance(F, PartialBytes);
+
+    /* Copy bytes */
+    while (PartialBytes--) {
+        mHold_CopyOut(F, i, *DestPtr);
+        i++;
+        DestPtr++;
+    }
+
+    /* No more data to process */
+    if (!BytesLeft) {
+        return;
+    }
+
+    /* Stage 2: The hold is empty now, if any more bytes are left to
process, then
+     * it will begin with nothing in the hold. Use the hold as a
temporary storage
+     * area to contain the data.
+     *
+     * The hold is filled with FIFO data, then that data is written to
the buffer.
+     * Do this FifoTransfersLeft times
+     */
+
+    /* Calculate the number of times a push will need to occur */
+    FifoTransfersLeft = BytesLeft / PFIFO_64BIT_WIDTH_BYTES;
+
+    /* Calculate the number of partial bytes left after this stage */
+    PartialBytes = BytesLeft - (FifoTransfersLeft *
PFIFO_64BIT_WIDTH_BYTES);
+
+    /* Write to the hold and push data to the FIFO */
+    while (FifoTransfersLeft--) {
+        /* Load the hold with the next data set from the FIFO */
+        mPop64(F);
+
+        /* Write hold to buffer */
+        for (i = 0; i < PFIFO_64BIT_WIDTH_BYTES; i++) {
+            mHold_CopyOut(F, i, *DestPtr);
+            DestPtr++;
+        }
+    }
+
+    /* No more data to process
+     * After processing full FIFO chunks of data, the hold is empty at this
+     * point
+     */
+    if (!PartialBytes) {
+        return;
+    }
+
+    /* Stage 3: All that is left is to fill the hold one more time with
FIFO
+     * data, then write the remaining requested bytes to the buffer
+     */
+
+    /* Get FIFO data */
+    mPop64(F);
+
+    /* Copy bytes from the hold to the buffer */
+    for (i = 0; i < PartialBytes; i++) {
+        mHold_CopyOut(F, i, *DestPtr);
+        DestPtr++;
+    }
+
+    /* Set the hold's index to its final correct value */
+    mHold_SetIndex(F, PartialBytes);
+    // DEBUG_FUNC_EXIT;
+}
+
+/*******************************************************************************
+* Read directly from the 64 bit wide receive FIFO into an aligned
destination
+* buffer. Leftover bytes are written to the holding buffer.
+*
+* @param F is a pointer to the packet FIFO instance to be worked on.
+* @param BufPtr is the destination buffer address on 32-bit alignment
+* @param ByteCount is the number of bytes to transfer
+*
+*******************************************************************************/
+static void
+Read64_Aligned(struct temac_local *lp, u32 * BufPtr, u32 ByteCount) {
+    struct temac_pktFifo * F = &lp->RecvFifo;
+    unsigned FifoTransfersLeft = ByteCount / PFIFO_64BIT_WIDTH_BYTES;
+    unsigned PartialBytes = ByteCount & (PFIFO_64BIT_WIDTH_BYTES - 1);
+
+    // DEBUG_FUNC;
+    /* Direct transfer */
+    while (FifoTransfersLeft--) {
+        mReadFifo64(F, BufPtr);
+        BufPtr += 2;
+    }
+
+    /* Leftover bytes are left in the holding area */
+    if (PartialBytes) {
+        Read64_Unaligned(lp, BufPtr, PartialBytes);
+    }
+    // DEBUG_FUNC_EXIT;
+}
+
+/*******************************************************************************
+* Write to the 64 bit holding buffer. Each time it becomes full, then it is
+* pushed to the transmit FIFO.
+*
+* @param F is a pointer to the packet FIFO instance to be worked on.
+* @param BufPtr is the source buffer address on any alignment
+* @param ByteCount is the number of bytes to transfer
+*
+*******************************************************************************/
+static void
+Write64_Unaligned(struct temac_local *lp, void *BufPtr, u32 ByteCount) {
+    struct temac_pktFifo * F = &lp->SendFifo;
+    u8 *SrcPtr = (u8 *) BufPtr;
+    unsigned FifoTransfersLeft;
+    unsigned PartialBytes;
+    unsigned BytesLeft;
+    int i;
+
+    // DEBUG_FUNC;
+    /* Stage 1: The hold may be partially full. Write enough bytes to it to
+     * cause a push to the FIFO
+     */
+
+    /* Calculate the number of bytes needed to trigger a push, if not
enough
+     * bytes have been specified to cause a push, then adjust accordingly
+     */
+    i = mHold_GetIndex(F);
+    PartialBytes = PFIFO_64BIT_WIDTH_BYTES - i;
+    if (PartialBytes > ByteCount) {
+        PartialBytes = ByteCount;
+    }
+
+    /* Calculate the number of bytes remaining after the first push */
+    BytesLeft = ByteCount - PartialBytes;
+
+    /* Write to the hold and advance its index */
+    mHold_Advance(F, PartialBytes);
+
+    while (PartialBytes--) {
+        mHold_CopyIn(F, i, *SrcPtr);
+        SrcPtr++;
+        i++;
+    }
+
+    /* Push to fifo if needed */
+    if (mHoldS_IsFull(F)) {
+        mPush64(F);
+        mHoldS_SetEmpty(F);
+    }
+
+    /* No more data to process */
+    if (!BytesLeft) {
+        return;
+    }
+
+    /* Stage 2: The hold is empty now, if any more bytes are left to
process, then
+     * it will begin with nothing in the hold. Use the hold as a
temporary storage
+     * area to contain the data.
+     *
+     * The hold is filled then pushed out to the FIFOs a number of
times based on
+     * how many bytes are left to process.
+     */
+
+    /* Calculate the number of times a push will need to occur */
+    FifoTransfersLeft = BytesLeft / PFIFO_64BIT_WIDTH_BYTES;
+
+    /* Calculate the number of partial bytes left after this stage */
+    PartialBytes = BytesLeft - (FifoTransfersLeft *
PFIFO_64BIT_WIDTH_BYTES);
+
+    /* Write to the hold and push data to the FIFO */
+    while (FifoTransfersLeft--) {
+        for (i = 0; i < PFIFO_64BIT_WIDTH_BYTES; i++) {
+            mHold_CopyIn(F, i, *SrcPtr);
+            SrcPtr++;
+        }
+        mPush64(F);
+    }
+
+    /* No more data to process
+     * HoldIndex was left at 0 by stage 1, at this point, that is
+     * still the correct value.
+     */
+    if (!PartialBytes) {
+        return;
+    }
+
+    /* Stage 3: All that is left is to fill the hold with the remaining
data
+     * to be processed. There will be no push to the FIFO because there
is not
+     * enough data left to cause one.
+     */
+
+    /* Write to the hold and push data to the FIFO */
+    for (i = 0; i < PartialBytes; i++) {
+        mHold_CopyIn(F, i, *SrcPtr);
+        SrcPtr++;
+    }
+
+    /* Set the hold's index to its final correct value */
+    mHold_SetIndex(F, PartialBytes);
+    // DEBUG_FUNC_EXIT;
+}
+
+/*******************************************************************************
+* Write directly to the 64 bit wide transmit FIFO from an aligned source
+* buffer. Leftover bytes are written to the holding buffer.
+*
+* @param F is a pointer to the packet FIFO instance to be worked on.
+* @param BufPtr is the source buffer address on 32-bit alignment
+* @param ByteCount is the number of bytes to transfer
+*
+*******************************************************************************/
+static void
+Write64_Aligned(struct temac_local *lp, u32 * BufPtr, u32 ByteCount) {
+    struct temac_pktFifo * F = &lp->SendFifo;
+    unsigned FifoTransfersLeft = ByteCount / PFIFO_64BIT_WIDTH_BYTES;
+    unsigned PartialBytes = ByteCount & (PFIFO_64BIT_WIDTH_BYTES - 1);
+
+    // DEBUG_FUNC;
+    /* Direct transfer */
+    while (FifoTransfersLeft--) {
+        _iow(F->DataBaseAddress + 0, (BufPtr)[0]);                        
+        _iow(F->DataBaseAddress + 4, (BufPtr)[1]);                   
+        BufPtr += 2;
+    }
+
+    /* Leftover bytes are left in the holding area */
+    if (PartialBytes) {
+        Write64_Unaligned(lp, BufPtr, PartialBytes);
+    }
+    // DEBUG_FUNC_EXIT;
+}
+
+/*******************************************************************************
+* Algorithm to read from a 64 bit wide receive packet FIFO with through
the
+* holding buffer.
+*
+* @param F is a pointer to a Temac FIFO instance to worked on.
+* @param BufPtr is the destination address on any alignment
+* @param ByteCount is the number of bytes to transfer
+*
+* @return 0 if transfer completed or XST_NO_DATA if the amount of
+*         data being buffered by the driver plus the amount of data in the
+*         packet FIFO is not enough to satisfy the number of bytes
requested
+*         by the ByteCount parameter.
+*******************************************************************************/
+static u32
+Read_64(struct temac_local *lp, void *BufPtr, u32 ByteCount, int Eop) {
+    struct temac_pktFifo * F = &lp->RecvFifo;
+    unsigned BufAlignment = (unsigned) BufPtr & 3;
+    unsigned PartialBytes;
+    unsigned MaxBytes;
+    int HoldAlignment = mHold_GetIndex(F);
+
+    // DEBUG_FUNC;
+    /* Determine how many bytes can be read from the packet FIFO */
+    MaxBytes = _ior(lp->RecvFifo.RegBaseAddress +
XPF_V200A_COUNT_STATUS_REG_OFFSET) & XPF_V200A_COUNT_MASK;
+    MaxBytes *= PFIFO_64BIT_WIDTH_BYTES;
+
+    /* Case 1: Buffer aligned on 4-byte boundary and Hold is empty
+     *  
+     *   1. Read all bytes using the fastest transfer method
+     */
+    if ((BufAlignment == 0) && (mHoldR_IsEmpty(F))) {
+        /* Enough data in fifo? */
+        if (ByteCount > MaxBytes) {
+            return (XST_NO_DATA);
+        }
+
+        Read64_Aligned(lp, (u32 *) BufPtr, ByteCount);
+    }
+
+    /* Case 2: Buffer and Hold are byte aligned with each other
+     *
+     *   1. Transfer enough bytes from the Hold to the buffer to trigger a
+     *      read from the FIFO.
+     *
+     *   2. The state of the buffer and Hold are now as described by
Case 1 so
+     *      read remaining bytes using the fastest transfer method
+     */
+    else if (BufAlignment == (HoldAlignment % PFIFO_64BIT_WIDTH_BYTES)) {
+        PartialBytes = PFIFO_64BIT_WIDTH_BYTES - HoldAlignment;
+
+        if (ByteCount < PartialBytes) {
+            PartialBytes = ByteCount;
+        }
+
+        /* Enough data in fifo? Must account for the number of bytes
the driver
+         * is currently buffering
+         */
+        if (ByteCount > (MaxBytes + PartialBytes)) {
+            return (XST_NO_DATA);
+        }
+
+        Read64_Unaligned(lp, BufPtr, PartialBytes);
+        Read64_Aligned(lp, (u32 *) ((u32) BufPtr + PartialBytes),
ByteCount - PartialBytes);
+    }
+
+    /* Case 3: No alignment to take advantage of
+     *
+     *    1. Read FIFOs using the slower method.
+     */
+    else {
+        /* Enough data in fifo? Must account for the number of bytes
the driver
+         * is currently buffering
+         */
+        PartialBytes = PFIFO_64BIT_WIDTH_BYTES - HoldAlignment;
+        if (ByteCount > (MaxBytes + PartialBytes)) {
+            return (XST_NO_DATA);
+        }
+
+        Read64_Unaligned(lp, BufPtr, ByteCount);
+    }
+
+    /* If this marks the end of packet, then dump any remaining data in the
+     * hold. The dumped data in this context is meaningless.
+     */
+    if (Eop == XTE_END_OF_PACKET) {
+        mHoldR_SetEmpty(F);
+    }
+    // DEBUG_FUNC_EXIT;
+    return (0);
+}
+/*******************************************************************************
+* Algorithm to write to a 64 bit wide transmit packet FIFO through the
holding
+* buffer.
+*
+* @param FPtr is a pointer to a Temac FIFO instance to worked on.
+* @param BufPtr is the source buffer address on any alignment
+* @param ByteCount is the number of bytes to transfer
+* @param Eop specifies whether the last byte written is the last byte
of the
+*        packet.
+*
+* @return 0
+*******************************************************************************/
+static u32
+Write_64(struct temac_local *lp, void *BufPtr, u32 ByteCount) {
+    struct temac_pktFifo * F = &lp->SendFifo;
+    unsigned BufAlignment = (unsigned) BufPtr & 3;
+    unsigned PartialBytes;
+    int HoldAlignment = mHold_GetIndex(F);
+
+    // DEBUG_FUNC;
+    /* Case 1: Buffer aligned on 4-byte boundary and Hold is empty
+     *  
+     *   1. Write all bytes using the fastest transfer method
+     */
+    if ((BufAlignment == 0) && (mHoldS_IsEmpty(F))) {
+        Write64_Aligned(lp, (u32 *) BufPtr, ByteCount);
+    }
+
+    /* Case 2: Buffer and Hold are byte aligned with each other
+     *
+     *   1. Transfer enough bytes from the buffer to the Hold to
trigger a flush
+     *      to the FIFO.
+     *
+     *   2. The state of the buffer and Hold are as described by Case 1 so
+     *      write remaining bytes using the fastest transfer method
+     */
+    else if (BufAlignment == (HoldAlignment % PFIFO_64BIT_WIDTH_BYTES)) {
+        PartialBytes = PFIFO_64BIT_WIDTH_BYTES - HoldAlignment;
+
+        if (ByteCount < PartialBytes) {
+            PartialBytes = ByteCount;
+        }
+
+        Write64_Unaligned(lp, BufPtr, PartialBytes);
+        Write64_Aligned(lp, (u32 *) ((u32) BufPtr + PartialBytes),
ByteCount - PartialBytes);
+    }
+
+    /* Case 3: No alignment to take advantage of
+     *
+     *    1. Read FIFOs using the slower method.
+     */
+    else {
+        Write64_Unaligned(lp, BufPtr, ByteCount);
+    }
+
+    /* If TxBytes is non-zero then the caller wants to transmit data
from the
+     * FIFO
+     */
+
+    /* Push the hold to the FIFO if data is present */
+    if (!mHoldS_IsEmpty(F)) {
+        mPush64(F);
+        mHoldS_SetEmpty(F);
+    }
+
+    // DEBUG_FUNC_EXIT;
+    return (0);
+}
+#if 0
+
+static u32
+Read64(struct temac_local *lp, void *BufPtr, u32 ByteCount, int Eop) {
+    u8      *rbuf = BufPtr ;   
+    u32     ret ;
+    u32     len ;
+    int     ii ;
+
+    // DEBUG_FUNC;
+    while (ior(ndev, XTE_IPISR_OFFSET) & XTE_IPXR_RECV_DONE_MASK) {
+        /* Get the length */
+        len = ior(ndev, XTE_RPLR_OFFSET);
+        DEBUG_PRINTK("\nRead64()=%0x",len);
+
+        /* The IPXR_RECV_DONE_MASK status bit is tied to the RSR
register. To clear
+        * this condition, read from the RSR (which has no information)
then write
+        * to the IPISR register to ack the status.
+        */
+        ret = ior(ndev, XTE_RSR_OFFSET);
+        iow(ndev, XTE_IPISR_OFFSET, XTE_IPXR_RECV_DONE_MASK);
+        ret = Read_64(lp, BufPtr, ByteCount, Eop) ;
+        if (lp->dbg) {
+            for(ii=0;ii<len;ii++){
+                if ((ii%16)==0) DEBUG_PRINTK("\n%08x ", ii);   
+                DEBUG_PRINTK("%02x ", rbuf[ii]);   
+            }
+            DEBUG_PRINTK("\n");
+        }
+    }
+    DEBUG_FUNC_EXIT;
+    return ret;
+}
+
+static void
+sendTest(struct temac_local *lp) {
+    unsigned char sbuf[]  = { 0xff,0xff,0xff,0xff,0xff,0xff,
+                              0x08,0x00,0x3e,0x26,0x15,0x59,
+                              0x00, 0x42,
+                              0xfe, 0xff,
+                             
0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0a,0x0b,0x0c,0x0d,0x0e,0x0f,
+                             
0x10,0x11,0x12,0x13,0x14,0x15,0x16,0x17,0x18,0x19,0x1a,0x1b,0x1c,0x1d,0x1e,0x1f,
+                             
0x20,0x21,0x22,0x23,0x24,0x25,0x26,0x27,0x28,0x29,0x2a,0x2b,0x2c,0x2d,0x2e,0x2f,
+                             
0x30,0x31,0x32,0x33,0x34,0x35,0x36,0x37,0x38,0x39,0x3a,0x3b,0x3c,0x3d,0x3e,0x3f
+                            };
+    unsigned char rbuf[512]  ;
+    int ii;
+    u32 Status;
+    int len = sizeof(sbuf);
+
+    DEBUG_FUNC;
+#if 0
+    iow(ndev,XTE_DSR_OFFSET,    XTE_DSR_RESET_MASK);            //
Reset PLB TEMAC
+    iow(ndev, XTE_CR_OFFSET,    XTE_CR_HRST_MASK);          // Reset
HARD TEMAC
+    emac_cfg_write(lp, PHY_NUM, XTE_RXC1_OFFSET,    XTE_RXC1_RXRST_MASK);
+    emac_cfg_write(lp, PHY_NUM, XTE_TXC_OFFSET,     XTE_TXC_TXRST_MASK);
+    emac_cfg_write(lp, PHY_NUM, XTE_MC_OFFSET,  XTE_XTE_MDIO_DIV_DFT |
XTE_MC_MDIO_MASK);   // Set default MDIO divisor
+
+    emac_cfg_write(lp, PHY_NUM, XTE_RXC1_OFFSET,   
XTE_RXC1_RXEN_MASK);            // Enable Rx, VLAN, Jumbo, Strip FCS
+    emac_cfg_write(lp, PHY_NUM, XTE_TXC_OFFSET,    
XTE_TXC_TXEN_MASK+XTE_TXC_TXIFG_MASK);      // Enable Tx, VLAN, Jumbo,
No client supplied FCS
+    emac_cfg_write(lp, PHY_NUM, XTE_EMCFG_OFFSET,  
XTE_EMCFG_LINKSPD_10+XTE_EMCFG_HOSTEN_MASK);    // Set 1G Host Interface
+    emac_cfg_write(lp, PHY_NUM, XTE_UAW0_OFFSET, ((buf[6]<<8) | (buf[7])));
+    emac_cfg_write(lp, PHY_NUM, XTE_UAW1_OFFSET, ((buf[8]<<24) |
(buf[9]<<16) | (buf[10]<<8) | (buf[11])));
+#endif
+    iow(ndev, XTE_DGIE_OFFSET,0);                   // disable interrupts
+    emac_cfg_write(lp, PHY_NUM, XTE_AFM_OFFSET, (u32)
XTE_AFM_EPPRM_MASK);          // temporarily enable Promiscuous  
+    // for(ii=0;ii<len;ii++)
+    //  sbuf[ii] = 0xff;   
+
+    Write_64(lp, sbuf, len);
+    Status = Read64(lp, rbuf, len, XTE_END_OF_PACKET);
+    DEBUG_PRINTK("\ndone\n");      
+    iow(ndev, XTE_DGIE_OFFSET, 0xffffffff);
+}
+#endif
+/************************** Variable Definitions
*****************************/
+
+/*
+ * array of masks associated with the bit position, improves performance
+ * in the ISR and acknowledge functions, this table is shared between all
+ * instances of the driver, this table is not statically initialized
because
+ * the size of the table is based upon the maximum used interrupt id
+ */
+
+
+/*
+Hardware start transmission.
+Send a packet to media from the upper layer.
+Method that initiates the transmission of a packet.
+The full packet (protocol headers and all) is contained in a socket
buffer (sk_buff) structure.
+Socket buffers are introduced later in this chapter.
+skb->data points to the packet
+skb->len is its length
+ */
+static int
+temac_hard_start_xmit(struct sk_buff *skb, struct net_device *ndev) {
+    struct temac_local *lp = ndev->priv;
+    u32 ret = 0;
+    unsigned long  flags = 0;
+
+    // DEBUG_FUNC;
+    netif_stop_queue(ndev);
+    spin_lock_irqsave(&XTE_spinlock, flags);
+    ndev->trans_start = jiffies;
+
+#if defined(CONFIG_PICO_LL_TEMAC)
+    switch (lp->nic_type) {
+        case TEMAC_PLB:
+            ret = plb_sendFrame(ndev,skb, bDescriptor);
+            break;
+        case TEMAC_LL:
+            ret = ll_sendFrame(ndev,skb, bDescriptor);
+            break;
+    }
+#else
+    // DEBUG_PRINTK("\n>plb_sendFrame()");
+    ret = plb_sendFrame(ndev,skb, bDescriptor);
+#endif
+    // DEBUG_PRINTK("\n<plb_sendFrame()");
+    if (ret) {
+        // reset(dev, __LINE__);
+        lp->stats.tx_errors++;
+        spin_unlock_irqrestore(&XTE_spinlock, flags);
+        // DEBUG_PRINTK("\n%d=temac_hard_start_transmit() error", ret);
+        // DEBUG_FUNC_EX(ret);
+        return  -EIO;
+    }
+    lp->stats.tx_bytes += skb->len;
+    lp->stats.tx_packets++;
+
+    dev_kfree_skb(skb); /* free this SKB */      // this crashes driver
eventually
+
+    // dump_skb_data(lp,skb, "Send");
+    netif_wake_queue(ndev);
+    spin_unlock_irqrestore(&XTE_spinlock, flags);
+    // DEBUG_PRINTK("\n%d=temac_hard_start_transmit() exit",ret);
+    // DEBUG_FUNC_EX(0);
+    return 0;
+}
+
+static void
+temac_shutdown(struct net_device *ndev) {
+    struct temac_local *lp = ndev->priv;
+    
+    // DEBUG_FUNC;
+    /* RESET device */
+    mdio_write(ndev, 0, MII_BMCR, BMCR_RESET);  /* PHY RESET */
+    /* Power-Down PHY */
+    /* Disable all interrupt */
+    /* Disable RX */
+}
+
+/*
+Stop the interface.
+Stops the interface. The interface is stopped when it is brought down.
+This function should reverse operations performed at open time.
+*/
+static int
+temac_stop(struct net_device *ndev) {
+    struct temac_local *lp = ndev->priv;
+    unsigned long flags;
+
+    // DEBUG_FUNC;
+    spin_lock_irqsave(&XTE_spinlock, flags);
+
+    del_timer(&lp->rx_timer);
+    del_timer(&lp->mii_timer);
+
+    /* Stop Send queue */
+    netif_stop_queue(ndev);
+    /* Now we could stop the ndevice */
+    netif_carrier_off(ndev);
+    /*
+     * If not in polled mode, free the interrupt.  Currently, there
+     * isn't any code to set polled mode, so this check is probably
+     * superfluous.
+     */
+    free_irq(ndev->irq, ndev);
+    temac_shutdown(ndev);
+    return 0;
+}
+
+/* temac_release_board release a board, and any mapped resources */
+static void
+temac_release_board(struct platform_device *pdev, struct net_device
*ndev) {
+    struct temac_local *lp = ndev->priv;
+
+    // DEBUG_FUNC;
+    /* unmap our resources */
+    iounmap((void *) ndev->base_addr);
+
+    /* release the resources */
+
+    if (lp->phy_addr_req != NULL) {
+        release_resource(lp->phy_addr_req);
+        kfree(lp->phy_addr_req);
+    }
+
+    if (lp->nic_addr_res != NULL) {
+        release_resource(lp->nic_addr_res);
+        kfree(lp->nic_addr_req);
+    }
+}
+
+/*
+Whenever an application needs to get statistics for the interface, this
method is
+called. This happens, for example, when ifconfig or netstat -i is run.
A sample
+implementation for snull is introduced in the section Statistical
Information.
+ */
+static struct net_device_stats
+*temac_get_stats(struct net_device *ndev) {
+    struct temac_local *lp = ndev->priv;
+
+    // DEBUG_FUNC;
+    return &lp->stats;
+}
+
+/*
+ * This function is used to handle ports that do not have an interrupt.
+ */
+static void
+temac_rx_timeout(unsigned long data) {
+    struct net_device *ndev = (struct net_device *) data;
+    struct temac_local *lp = ndev->priv;
+
+    // DEBUG_FUNC;
+    disable_irq(ndev->irq);
+    temac_interrupt(-2, ndev, NULL);
+    enable_irq(ndev->irq);
+
+    mod_timer(&lp->rx_timer, TEMAC_RX_TIMEOUT);
+}
+/*
+ A periodic timer routine
+ Dynamic media sense, allocated Rx buffer...
+ */
+static void
+temac_mii_timeout(unsigned long data) {
+    struct net_device *ndev = (struct net_device *) data;
+    struct temac_local *lp = ndev->priv;
+
+    // DEBUG_FUNC;
+    mii_check_media(&lp->mii_if, netif_msg_link(lp), 0);
+    /* Set timer again */
+    mod_timer(&lp->mii_timer, TEMAC_MII_TIMEOUT);
+}
+
+static int
+temac_open(struct net_device *ndev) {
+    struct temac_local *lp = ndev->priv;
+    unsigned long flags;
+
+    // DEBUG_FUNC;
+
+    /*
+     * Just to be safe, stop TX queue and the ndevice first. If the
ndevice is
+     * already stopped, an error will be returned. In this case, we don't
+     * really care,.
+     */
+    netif_stop_queue(ndev);
+    spin_lock_irqsave(&XTE_spinlock, flags);
+
+    if (ndev->mtu > XTE_MTU)
+        ndev->mtu = XTE_MTU;
+
+    /*
+    Enable interrupts if not in polled mode
+    */
+    if (ndev->irq < 0) {
+        lp->poll = 1;
+    } else if (request_irq(ndev->irq, &temac_interrupt, 0, ndev->name,
ndev)) {
+            printk(KERN_ERR "%s: XTemac could not allocate interrupt
%d. reverting to polled IO\n", ndev->name, ndev->irq);
+            lp->poll = 1;
+    }
+
+    /* Initialize TEMAC board */
+    temac_device_reset(ndev);
+
+    /* set and active a timer process */
+    lp->mii_timer.data     = (unsigned long) ndev;
+    lp->mii_timer.function = &temac_mii_timeout;
+    init_timer(&lp->mii_timer);
+    mod_timer(&lp->mii_timer, TEMAC_MII_TIMEOUT);
+
+    lp->rx_timer.data     = (unsigned long) ndev;
+    lp->rx_timer.function = &temac_rx_timeout;
+    init_timer(&lp->rx_timer);
+    mod_timer(&lp->rx_timer, TEMAC_RX_TIMEOUT);
+
+    mii_check_media(&lp->mii_if, netif_msg_link(lp), 1);
+    /* We're ready to go. */
+    netif_start_queue(ndev);
+    spin_unlock_irqrestore(&XTE_spinlock, flags);
+
+    return 0;
+}
+static int
+temac_do_ioctl(struct net_device *ndev, struct ifreq *rq, int cmd) {
+    struct temac_local *lp = ndev->priv;
+    int rc;
+    unsigned long flags;
+
+    /* SIOC[GS]MIIxxx ioctls */
+    if (lp->mii) {
+        spin_lock_irqsave(&lp->lock, flags);
+        rc = generic_mii_ioctl(&lp->mii_if, if_mii(rq), cmd, NULL);
+        spin_unlock_irqrestore(&lp->lock, flags);
+    } else {
+        rc = -EOPNOTSUPP;
+    }
+
+    return rc;
+}
+
+/*
+Our watchdog timed out. Called by the networking layer
+Method called by the networking code when a packet transmission fails
to complete within a reasonable period, on the assumption that an
interrupt has been
+missed or the interface has locked up. It should handle the problem and
resume packet transmission.
+*/
+static void
+temac_tx_timeout(struct net_device *ndev) {
+    struct temac_local *lp = ndev->priv;
+    unsigned long flags;
+
+    // DEBUG_FUNC;
+    spin_lock_irqsave(&lp->lock, flags);
+
+    netif_stop_queue(ndev);
+    printk(KERN_ERR "%s: XTemac exceeded transmit timeout of %lu ms. 
Resetting emac.\n", ndev->name, TEMAC_TX_TIMEOUT * 1000UL / HZ);
+    lp->stats.tx_errors++;
+    temac_device_reset(ndev);
+    ndev->trans_start = jiffies;
+    netif_wake_queue(ndev);                         /* We can accept TX
packets again */
+
+    spin_unlock_irqrestore(&lp->lock, flags);
+}
+
+/*
+OPTIONAL
+void (*poll_controller)(struct net_device *dev);
+Function that asks the driver to check for events on the interface in
situations
+where interrupts are disabled. It is used for specific in-kernel
networking tasks,
+such as remote consoles and kernel debugging over the network.
+
+*/
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static void
+temac_poll_controller(struct net_device *ndev) {
+    // DEBUG_FUNC;
+    disable_irq(ndev->irq);
+    temac_interrupt(-1, ndev, NULL);
+    enable_irq(ndev->irq);
+}
+#endif
+/*
+OPTIONAL
+
+int (*change_mtu)(struct net_device *dev, int new_mtu);
+Function that takes action if there is a change in the maximum transfer
unit (MTU)
+for the interface. If the driver needs to do anything particular when
the MTU is
+changed by the user, it should declare its own function; otherwise, the
default does
+the right thing. snull has a template for the function if you are
interested.
+*/
+int temac_change_mtu(struct net_device *dev, int new_mtu) {
+#if 0
+    int head_size = XTE_HDR_SIZE;
+    struct temac_local *lp = (struct temac_local *)dev->priv;
+    int max_frame = new_mtu + head_size + XTE_TRL_SIZE;
+    int min_frame = 1 + head_size + XTE_TRL_SIZE;
+
+    // DEBUG_FUNC;
+    if ((max_frame < min_frame) || (max_frame > lp->max_frame_size))
+        return -EINVAL;
+
+    dev->mtu = new_mtu; /* change mtu in net_device structure */
+#endif
+    return 0;
+}
+
+static int
+temac_ethtool_get_settings(struct net_device *ndev, struct ethtool_cmd
*cmd) {
+    struct temac_local *lp = ndev->priv;
+    unsigned long flags;
+    int r = -EOPNOTSUPP;
+
+    if (lp->mii) {
+        spin_lock_irqsave(&lp->lock, flags);
+        mii_ethtool_gset(&lp->mii_if, cmd);
+        spin_unlock_irqrestore(&lp->lock, flags);
+        r = 0;
+    }
+    return r;
+}
+
+static int
+temac_ethtool_set_settings(struct net_device *ndev, struct ethtool_cmd
*cmd) {
+    struct temac_local *lp = ndev->priv;
+    unsigned long flags;
+    int r = -EOPNOTSUPP;
+
+    if (lp->mii) {
+        spin_lock_irqsave(&lp->lock, flags);
+        r = mii_ethtool_sset(&lp->mii_if, cmd);
+        spin_unlock_irqrestore(&lp->lock, flags);
+    }
+    return r;
+}
+
+static void
+temac_ethtool_get_drvinfo(struct net_device *ndev, struct
ethtool_drvinfo *info) {
+
+    memset(info, 0, sizeof(struct ethtool_drvinfo));
+    strncpy(info->driver, DRV_NAME, sizeof(info->driver) - 1);
+    strncpy(info->version, DRV_VERSION, sizeof(info->version) - 1);
+    /* Also tell how much memory is neinfoinfo for dumping register
values */
+    info->regdump_len = 0;
+}
+
+static u32
+temac_ethtool_get_link(struct net_device *ndev) {
+    struct temac_local *lp = ndev->priv;
+    unsigned long flags;
+    int r;
+
+    spin_lock_irqsave(&lp->lock, flags);
+    r = mii_link_ok(&lp->mii_if);
+    spin_unlock_irqrestore(&lp->lock, flags);
+
+    return r;
+}
+
+static u32
+temac_ethtool_get_msglevel(struct net_device *ndev) {
+    struct temac_local *lp = ndev->priv;
+    return lp->msg_enable;
+}
+
+static void
+temac_ethtool_set_msglevel(struct net_device *ndev, u32 value) {
+    struct temac_local *lp = ndev->priv;
+    lp->msg_enable = value;
+}
+
+static int
+temac_ethtool_nway_reset(struct net_device *ndev) {
+    struct temac_local *lp = ndev->priv;
+    unsigned long flags;
+    int r = -EOPNOTSUPP;
+
+    if (lp->mii) {
+        spin_lock_irqsave(&lp->lock, flags);
+        r = mii_nway_restart(&lp->mii_if);
+        spin_unlock_irqrestore(&lp->lock, flags);
+    }
+    return r;
+}
+
+static struct ethtool_ops temac_ethtool_ops = {
+    .get_settings = temac_ethtool_get_settings,
+    .set_settings = temac_ethtool_set_settings,
+    .get_drvinfo = temac_ethtool_get_drvinfo,
+    .get_msglevel = temac_ethtool_get_msglevel,
+    .set_msglevel = temac_ethtool_set_msglevel,
+    .nway_reset = temac_ethtool_nway_reset,
+    .get_link = temac_ethtool_get_link,
+    .get_tx_csum = ethtool_op_get_tx_csum,
+    .get_sg = ethtool_op_get_sg,
+    .get_tso = ethtool_op_get_tso,
+    .get_perm_addr = ethtool_op_get_perm_addr,
+};
+/*
+Search TEMAC board, allocate space and register it
+ */
+static int
+temac_device_probe(struct platform_device *pdev) {
+    struct net_device *ndev;
+    struct xtemac_platform_data *pdata = pdev->dev.platform_data;
+    struct temac_local *lp; /* Point a board information structure */
+    int i;
+    u32 ret = 0;
+    int nic_size;
+    // DEBUG_FUNC;
+    printk(version);
+    /* Init network device */
+    ndev = alloc_etherdev(sizeof(struct temac_local));
+    if (!ndev) {
+        printk("%s: could not allocate device.\n", DRV_NAME);
+        return -ENOMEM;
+    }
+
+    SET_MODULE_OWNER(ndev);
+    SET_NETDEV_DEV(ndev, &pdev->dev);
+    /* setup board info structure */
+    lp = (struct temac_local *) ndev->priv;
+    // lp->einfo = einfo;
+    /* Clear memory */
+    memset(lp, 0, sizeof(*lp));
+    spin_lock_init(&lp->lock);
+/*  get device configuration from platform Device */
+    ndev->irq = platform_get_irq(pdev, 0);
+    lp->nic_type = TEMAC_PLB;
+    lp->dbg = 1;
+    lp->options = XTE_DEFAULT_OPTIONS;
+
+    if (pdev->num_resources < 2) {
+        printk("%s: insufficient resources %d.\n", DRV_NAME,
pdev->num_resources);
+        ret = -ENODEV;
+        goto out;
+    }
+    lp->nic_type            = pdata->nic_type;
+    if ((pdata->rx_pkt_fifo_depth >= 131072) &&
(pdata->tx_pkt_fifo_depth >= 131072)) {
+        lp->MaxFrameSz = sizeof(EthFrame);
+    } else {
+        lp->MaxFrameSz = 1536;  /* Sized to fit within cache lines */
+    }
+//    lp->MacFifoDepth        = pdata->mac_fifo_depth;
+    lp->dcr_host            = pdata->dcr_host;
+#if defined(CONFIG_PICO_LL_TEMAC)
+    switch (lp->nic_type) {
+        case TEMAC_PLB:
+            // ndev->base_addr      = XPAR_PLB_TEMAC_0_BASEADDR;
+            lp->phy_mode            = 0;     
+            break;
+        case TEMAC_LL:
+            // ndev->base_addr      = XPAR_PLB_LL_IF_0_BASEADDR ;
+            lp->phy_addr            =
XGP_HIF_BASEADDR;                                     /* set default
address of PHY */
+            lp->phy_mode            = PHY_DCR;     
+            break;
+    }
+#else
+    lp->phy_mode            = 0;     
+#endif
+    lp->nic_addr_res = platform_get_resource(pdev, IORESOURCE_MEM,
0);      /* address of NIC */
+    if (lp->nic_addr_res == NULL) {
+        printk(KERN_ERR DRV_NAME ":insufficient resources\n");
+        ret = -ENOENT;
+        goto out;
+    }
+    nic_size = res_size(lp->nic_addr_res);
+    lp->nic_addr_req = request_mem_region(lp->nic_addr_res->start,
nic_size, pdev->name);
+    if (lp->nic_addr_req == NULL) {
+        printk(KERN_ERR DRV_NAME ":cannot claim address reg area\n");
+        ret = -EIO;
+        goto out;
+    }
+
+    ndev->base_addr = (u32) ioremap(lp->nic_addr_res->start, nic_size);
+    if (ndev->base_addr == 0) {
+        printk(KERN_ERR "failed to ioremap address reg\n");
+        ret = -EINVAL;
+        goto out;
+    }
+
+    /* fill in parameters for net-dev structure */
+
+/*      done getting platform_device parameters start initializine
device */
+    /* Set all handlers to stub values, let user configure this data */
+    lp->mii = 1;            /*  really important can't read/write
anyting until set */
+    lp->regshift = 3;      
+
+    lp->LinkSpeed = 1000;                                   // Tell
driver that the PHY is 10/100/1000 capable
+    lp->mii_if.full_duplex = 1;
+    lp->mii_if.phy_id_mask = 0x1f;
+    lp->mii_if.reg_num_mask = 0x1f;
+    lp->mii = 1;
+    lp->msg_enable = debug;
+    lp->mii_if.dev = ndev;
+    lp->mii_if.mdio_read = mdio_read;
+    lp->mii_if.mdio_write = mdio_write;
+    /* Set the mii phy_id so that we can query the link state */
+    //  if (lp->mii)
+    //      lp->mii_if.phy_id = ((lp->a.read_bcr (ioaddr, 33)) >> 5) &
0x1f;
+    // memcpy(ndev->dev_addr, "\0\1\2345", ETH_ALEN);
+
+    temac_set_mac_address(ndev,pdata->mac_addr);
+    /* from this point we assume that we have found a TEMAC */
+    /* driver system function */
+    ether_setup(ndev);
+    /* The TEMAC-specific entries in the device structure. */
+    ndev->open = &temac_open;
+    ndev->stop = &temac_stop;
+    ndev->get_stats = &temac_get_stats;
+    ndev->do_ioctl = &temac_do_ioctl;
+    ndev->tx_timeout = &temac_tx_timeout;
+    ndev->watchdog_timeo = msecs_to_jiffies(watchdog);
+    ndev->hard_start_xmit = &temac_hard_start_xmit;
+    ndev->set_multicast_list = &temac_set_multicast_list;
+    ndev->ethtool_ops = &temac_ethtool_ops;
+#ifdef CONFIG_NET_POLL_CONTROLLER
+    ndev->poll_controller = temac_poll_controller;
+#endif
+    ndev->flags &= ~IFF_MULTICAST;                  /* clear multicast */
+    ndev->change_mtu = temac_change_mtu;
+    platform_set_drvdata(pdev, ndev);
+    ret = register_netdev(ndev);
+    if (ret == 0) {
+        printk("%s: %s_temac at %lx,%x IRQ %d MAC: ", ndev->name,
(lp->nic_type == TEMAC_PLB) ? "plb" : "ll", ndev->base_addr,
lp->phy_addr, ndev->irq);
+        for (i = 0; i < 5; i++)
+            printk("%02x:", ndev->dev_addr[i]);
+        printk("%02x", ndev->dev_addr[5]);
+#ifdef CONFIG_NET_POLL_CONTROLLER
+        printk(" NET_POLL");
+#endif
+        /* print h/w id  */
+        if (lp->nic_type == TEMAC_PLB) {
+            ret = ior(ndev,XTE_DSR_OFFSET);
+            printk(KERN_INFO " id %d.%d%c, block id %d, type %d\n",
((ret >> 28) & 0xf), ((ret >> 21) & 0x7f), (((ret >> 16) & 0x1f) + 'a'),
((ret >> 16) & 0xff), ((ret >> 0) & 0xff));
+        }
+    }
+    return 0;
+//  release:
+    out:
+    printk("%s: not found (%d).\n", DRV_NAME, ret);
+    temac_release_board(pdev, ndev);
+    kfree(ndev);
+    return ret;
+}
+
+
+static int
+temac_device_suspend(struct platform_device *pdev, pm_message_t state) {
+    struct net_device *ndev = platform_get_drvdata(pdev);
+    //  DEBUG_FUNC;
+    if (ndev) {
+        if (netif_running(ndev)) {
+            netif_device_detach(ndev);
+            temac_shutdown(ndev);
+        }
+    }
+    return 0;
+}
+
+static int
+temac_device_resume(struct platform_device *pdev) {
+    struct net_device *ndev = platform_get_drvdata(pdev);
+    // DEBUG_FUNC;
+    if (ndev) {
+
+        if (netif_running(ndev)) {
+            temac_device_reset(ndev);
+            netif_device_attach(ndev);
+        }
+    }
+    return 0;
+}
+
+static int __devexit
+temac_device_remove(struct platform_device *pdev) {
+    struct net_device *ndev = platform_get_drvdata(pdev);
+    // DEBUG_FUNC;
+    platform_set_drvdata(pdev, NULL);
+    unregister_netdev(ndev);
+    temac_release_board(pdev, ndev);
+    free_netdev(ndev);  /* free device structure */
+    // DEBUG_FUNC_EXIT;
+    return 0;
+}
+
+static struct platform_driver temac_driver = {
+    .probe = temac_device_probe,
+    .remove = temac_device_remove,
+    .suspend = temac_device_suspend,
+    .resume = temac_device_resume,.driver = {
+    .name = DRV_NAME,
+    },
+};
+
+static int __init
+temac_init_module(void) {
+    int err;
+    if ((err = platform_driver_register(&temac_driver))) {  /* search
board and register */
+        printk(KERN_ERR "Driver registration failed\n");
+        return err;
+    }
+#if 0
+    temac_device = platform_device_alloc(DRV_NAME, 0);
+    if (!temac_device) {
+        goto out_unregister;
+    }
+
+    if (platform_device_add(temac_device)) {
+        platform_device_put(temac_device);
+        temac_device = NULL;
+    }
+    return 0;
+out_unregister:
+    platform_driver_unregister(&temac_driver);
+    return -ENOMEM;
+#else
+    return 0;
+
+#endif
+}
+
+static void __exit
+temac_cleanup_module(void) {
+    platform_driver_unregister(&temac_driver);
+    if (temac_device) {
+        platform_device_unregister(temac_device);
+        temac_device = NULL;
+    }
+}
+
+module_init(temac_init_module);
+module_exit(temac_cleanup_module);
+MODULE_DESCRIPTION(DRV_DESCRIPTION);
+module_param(debug, int, 0);
+MODULE_PARM_DESC(debug, "temac debug level (1-4)");
+//module_param(speed, int, 0);
+//static unsigned int speed = CONFIG_XILINX_OLD_TEMAC_SPEED;
+//MODULE_PARM_DESC(speed, "temac speed 10,100,1000");
+MODULE_AUTHOR("David H. Lynch Jr. <dhlii at dlasys.net>");
+MODULE_LICENSE("GPL");
+
+/*
+
+OPTIONAL functions
+
+Function (called before hard_start_xmit) that builds the hardware
header from
+the source and destination hardware addresses that were previously
retrieved; its
+job is to organize the information passed to it as arguments into an
appropriate,
+device-specific hardware header. eth_header is the default function for
Ethernet-
+like interfaces, and ether_setup assigns this field accordingly.
+int (*hard_header) (struct sk_buff *skb, struct net_device *dev,
unsigned short type, void *daddr, void *saddr, unsigned len);
+
+Function used to rebuild the hardware header after ARP resolution
completes
+but before a packet is transmitted. The default function used by
Ethernet devices
+uses the ARP support code to fill the packet with missing information.
+int (*rebuild_header)(struct sk_buff *skb);
+
+Changes the interface configuration. This method is the entry point for
configuring the driver. The I/O address for the device and its interrupt
number can be
+changed at runtime using set_config. This capability can be used by the
system
+administrator if the interface cannot be probed for. Drivers for modern
hardware normally do not need to implement this method.
+int (*set_config)(struct net_device *dev, struct ifmap *map);
+
+Method provided by NAPI-compliant drivers to operate the interface in a
polled
+mode, with interrupts disabled. NAPI (and the weight field) are covered
in the
+section Receive Interrupt Mitigation.
+int (*poll)(struct net_device *dev; int *quota) L
+
+header_cache is called to fill in the hh_cache structure with the
results of an ARP
+query. Almost all Ethernet-like drivers can use the default
eth_header_cache
+implementation.
+int (*header_cache) (struct neighbour *neigh, struct hh_cache *hh);
+
+Method that updates the destination address in the hh_cache structure in
+response to a change. Ethernet devices use eth_header_cache_update.
+int (*header_cache_update) (struct hh_cache *hh, struct net_device
*dev, unsigned char *haddr);
+
+The hard_header_parse method extracts the source address from the
packet contained in skb,
+copying it into the buffer at haddr. The return value from the function
is the length of that address. Ethernet devices normally use
eth_header_parse.
+int (*hard_header_parse) (struct sk_buff *skb, unsigned char *haddr);
+
+Utility Fields
+
+The remaining struct net_device data fields are used by the interface
to hold useful
+status information. Some of the fields are used by ifconfig and netstat
to provide the
+user with information about the current configuration. Therefore, an
interface
+should assign values to these fields:
+
+unsigned long trans_start;
+unsigned long last_rx;
+
+Fields that hold a jiffies value. The driver is responsible for
updating these values when transmission begins and when a packet is
received, respectively. The
+trans_start value is used by the networking subsystem to detect
transmitter
+lockups. last_rx is currently unused, but the driver should maintain
this field
+anyway to be prepared for future use.
+
+int watchdog_timeo;
+
+The minimum time (in jiffies) that should pass before the networking layer
+decides that a transmission timeout has occurred and calls the drivers
tx_timeout function.
+
+static void *priv;
+The equivalent of filp->private_data. In modern drivers, this field is
set by
+alloc_netdev and should not be accessed directly; use netdev_priv instead.
+
+struct dev_mc_list *mc_list;
+
+int mc_count;
+Fields that handle multicast transmission. mc_count is the count of
items in mc_list.
+See the section Multicast for further details.
+
+spinlock_t xmit_lock;
+
+int xmit_lock_owner;
+The xmit_lock is used to avoid multiple simultaneous calls to the drivers
+hard_start_xmit function. xmit_lock_owner is the number of the CPU that
has
+obtained xmit_lock. The driver should make no changes to these fields.
+*/
+#if 0
+static u32
+emac_AFM_read(struct net_device *ndev, int reg_num, int MultAddrReg,
u32 *mult_addr_msw, u32 *mult_addr_lsw)  {
+    struct temac_local *lp = ndev->priv;
+    int EmacNum = 0;
+    mtdcr((lp->phy_addr) + XGP_HIF_DATA_REG_LSW_OFFSET, MultAddrReg );
+    mtdcr((lp->phy_addr) + XGP_HIF_CNTL_REG_OFFSET,
XGP_HIF_CNTL_REG_OFFSET_DCR_WRITE | (EmacNum << 10) | reg_num);
+    while ( !(mfdcr(lp->phy_addr + XGP_HIF_RDY_STATUS_OFFSET )  &
(XGP_HIF_RDYSTAT_AF0_READ_MASK << (8*EmacNum))));
+    *mult_addr_lsw = mfdcr((lp->phy_addr) + XGP_HIF_DATA_REG_LSW_OFFSET);
+    *mult_addr_msw = mfdcr((lp->phy_addr) + XGP_HIF_DATA_REG_MSW_OFFSET);
+}
+
+static void
+emac_AFM_write(struct net_device *ndev, int reg_num, u32 mult_addr_msw,
u32 mult_addr_lsw)  {
+    emac_AF_write(ndev, XTE_MAW0_OFFSET, (((mult_addr_msw << 24) &
0xff000000) | ((mult_addr_msw << 8) & 0x00ff0000) | ((mult_addr_msw >>
8) &  0x0000ff00) | ((mult_addr_msw >> 24) & 0x000000ff)));
+    emac_AF_write(ndev, XTE_MAW1_OFFSET, (reg_num << 16) |
((mult_addr_lsw<<8) & 0xff00) | ((mult_addr_lsw >>8 ) & 0x00ff)) ;
+
+}
+#endif
+/*
+ vim: tabstop=4 shiftwidth=4 softtabstop=4 nolist expandtab
+*/
diff --git a/include/linux/xilinx_devices.h b/include/linux/xilinx_devices.h
new file mode 100755
index 0000000..747453a
--- /dev/null
+++ b/include/linux/xilinx_devices.h
@@ -0,0 +1,104 @@
+/*
+ * include/linux/xilinx_devices.h
+ *
+ * Definitions for any platform device related flags or structures for
+ * Xilinx EDK IPs
+ *
+ * Author: MontaVista Software, Inc.
+ *         source at mvista.com
+ *
+ * 2002-2005 (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.
+ */
+
+#ifdef __KERNEL__
+#ifndef _XILINX_DEVICE_H_
+#define _XILINX_DEVICE_H_
+
+#include <linux/types.h>
+#include <linux/version.h>
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,15)
+#include <linux/device.h>
+#else
+#include <linux/platform_device.h>
+#endif
+
+/*- 10/100 Mb Ethernet Controller IP (XEMAC) -*/
+
+struct xemac_platform_data {
+    u32 device_flags;
+    u32 dma_mode;
+    u32 has_mii;
+    u32 has_err_cnt;
+    u32 has_cam;
+    u32 has_jumbo;
+    u32 tx_dre;
+    u32 rx_dre;
+    u32 tx_hw_csum;
+    u32 rx_hw_csum;
+    u8 mac_addr[6];
+};
+
+/* Flags related to XEMAC device features */
+#define XEMAC_HAS_ERR_COUNT    0x00000001
+#define XEMAC_HAS_MII        0x00000002
+#define XEMAC_HAS_CAM        0x00000004
+#define XEMAC_HAS_JUMBO        0x00000008
+
+/* Possible DMA modes supported by XEMAC */
+#define XEMAC_DMA_NONE        1
+#define XEMAC_DMA_SIMPLE    2    /* simple 2 channel DMA */
+#define XEMAC_DMA_SGDMA        3    /* scatter gather DMA */
+
+/*- 10/100/1000 Mb Ethernet Controller IP (XTEMAC) -*/
+
+struct xtemac_platform_data {
+#ifdef XPAR_TEMAC_0_INCLUDE_RX_CSUM
+    u8 tx_dre;
+    u8 rx_dre;
+    u8 tx_csum;
+    u8 rx_csum;
+    u8 phy_type;
+#endif
+    u8 dma_mode;
+    u32 rx_pkt_fifo_depth;
+    u32 tx_pkt_fifo_depth;
+    u16 mac_fifo_depth;
+    u8 dcr_host;
+    u8 dre;
+
+    u8 mac_addr[6];
+
+#if defined(CONFIG_XILINX_OLD_TEMAC)
+    u16 speed;
+#endif
+#if defined(CONFIG_PICO_TEMAC) || defined(CONFIG_XILINX_OLD_TEMAC)
+    u8     phy_type;
+    u8     nic_type;
+#endif
+};
+
+/* Possible DMA modes supported by XTEMAC */
+#define XTEMAC_DMA_NONE        1
+#define XTEMAC_DMA_SIMPLE    2    /* simple 2 channel DMA */
+#define XTEMAC_DMA_SGDMA    3    /* scatter gather DMA */
+
+/*- SPI -*/
+
+struct xspi_platform_data {
+    u32 device_flags;
+    u8 num_slave_bits;
+};
+
+/* Flags related to XSPI device features */
+#define XSPI_HAS_FIFOS        0x00000001
+#define XSPI_SLAVE_ONLY        0x00000002
+
+/*- GPIO -*/
+
+/* Flags related to XGPIO device features */
+#define XGPIO_IS_DUAL        0x00000001
+
+#endif /* _XILINX_DEVICE_H_ */
+#endif /* __KERNEL__ */






-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii at dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 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



From grant.likely at secretlab.ca  Wed Jul 25 14:29:48 2007
From: grant.likely at secretlab.ca (Grant Likely)
Date: Tue, 24 Jul 2007 22:29:48 -0600
Subject: [PATCH] Xilinx TEMAC driver
In-Reply-To: <46A5C305.5000903@dlasys.net>
References: <46A5C305.5000903@dlasys.net>
Message-ID: <fa686aa40707242129p1b5f5299i44818ead5ed4d2f3@mail.gmail.com>

On 7/24/07, David H. Lynch Jr. <dhlii at dlasys.net> wrote:
>     Hopefully this is not too much of a mess.
>
>     This is a very preliminary patch to add support for the Xilinx TEMAC.
>     This is closer approximation to a normal linux driver.
>     There are no external dependencies aside from a properly setup
> xparameters.h and
>     platform data structure for the TEMAC - i.e. no need for xilinx_edk,
> xilinx_common, ...
>     The whole driver is in a single source file.
>     It autonegotiates, and it actually works in some Pico Firmware where
> the MV/Xilinx driver does not.

Hooray!  Thanks for posting your work.  I'm keen to try this on my
platform.  Comments below.

General comments:
- Remove the c++ (//) style comments
- indentation should be by tabs, not spaces.  Run the whole file
through the scripts/Lindent utility.
- Your patch has been damaged by your mailer (by wrapping lines).  I
cannot apply this patch as-is.  Maybe take a look at git-send-email
for sending patches.
- Keep lines < 80 characters long.
- CamelCaseVariablesStructuresAndFunctions don't match the Linux coding style.
- rather than commenting out DEBUG_PRINTK's, instead add "#define
DEBUG" before the #include statements, and use the dev_dbg() macro.

>
>     Somewhere long ago this started out based on the Xilinx code from
> the Trek Webserver sample.
>     As such it is also losely based on the xilinx_edk code.
>     Hopefully, I remembered to provide proper attribution. This is
> preliminary so things like that will get fixed.
>     It includes support for the LocalLink TEMAC, though the LL_TEMAC
> performance is poor, and I could not figure
>     out anyway to make it interrupt driven so it had a fairly high rate
> of dropped packets.
>     It ONLY supports the FIFO based PLB TEMAC. If you want SGDMA add it
> or use the Xilinx/MV driver.
>
>     There is alot of cruft in the driver that needs yanked, bits and
> peices of #ifdefed out code from the xilinx EDK or ldd3
>     or whatever I thought I needed, and have not yet been willing to delete.
>
>     I am also using dman near the same identical source for a TEMAC
> driver for GreenHills, and there are likely some
>     #ifdef's that only make sense in that context.
>
>     At somepoint I will try to clean all of the above crap out.
>
>     I also need to clean up my git tree so that I can produce a proper
> patch.
>
>     Enough caveats - patch follows.
>
>
>
>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 7d57f4a..fe5aa83 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -2332,6 +2337,59 @@ config ATL1
>
>  endif # NETDEV_1000
>
> +config PICO_TEMAC
> +    tristate "Pico Xilinx 10/100/1000 Mbit Local Link/PLB TEMAC support"

Drop the PICO name, this should work with any TEMAC implementation.

> +    depends on XILINX_VIRTEX && !XILINX_OLD_TEMAC && !XILINX_TEMAC
> +    select MII
> +    select NET_POLL_CONTROLLER
> +#    select PHYLIB

Drop the commented out bits, they can always be added back in when
phylib support is added.

> +    help
> +      This driver supports Tri-Mode, 10/100/1000 Mbit EMAC IP
> +      from Xilinx EDK.
> +
> +config PICO_DEBUG_TEMAC
> +    bool 'Pico TEMAC Debugging'
> +    default y
> +    depends on PICO_TEMAC && PICO_DEBUG
> +
> +
>  #
>  #    10 Gigabit Ethernet
>  #
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index a77affa..2248dd4 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -227,3 +227,8 @@ obj-$(CONFIG_NETCONSOLE) += netconsole.o
>  obj-$(CONFIG_FS_ENET) += fs_enet/
>
>  obj-$(CONFIG_NETXEN_NIC) += netxen/
> +obj-$(CONFIG_PICO_TEMAC) += temac.o
> diff --git a/drivers/net/temac.c b/drivers/net/temac.c
> new file mode 100644
> index 0000000..01d30c4
> --- /dev/null
> +++ b/drivers/net/temac.c
> @@ -0,0 +1,3742 @@
> +/*
> +
> + linux/drivers/net/temac.c
> +
> + Driver for Xilinx hard temac ethernet NIC's
> +
> + Author: David H. Lynch Jr. <dhlii at dlasys.net>
> + Copyright (C) 2005 DLA Systems
> + The author may be reached as dhlii at sdlasys.net, or C/O
> +       DLA Systems
> +       354 Rudy Dam rd.
> +       Lititz PA 17543

Drop the contact info, you can add stuff to MAINTAINERS if you prefer
in a separate patch.

> +
> +This program is free software; you can redistribute it and/or modify
> +it under the terms of the GNU General Public License as published by
> +the Free Software Foundation; either version 2 of the License, or
> +(at your option) any later version.
> +
> +This program is distributed in the hope that it will be useful,
> +but WITHOUT ANY WARRANTY; without even the implied warranty of
> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +GNU General Public License for more details.
> +
> +You should have received a copy of the GNU General Public License
> +along with this program; if not, write to the Free Software
> +Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> + things that need looked at:
> +    process_transmits
> +    temac_EtherRead
> +    temac_hard_start_xmit
> +    ehter_reset
> +    temac_get_link_status
> +
> +$Id: temac.c,v 0.10 2005/12/14 10:03:27 dhlii Exp $

Drop the CVS-fu.  It's irrelevant for mainline.

> +
> +*/
> +#define DRV_NAME        "temac"
> +#define DRV_DESCRIPTION "Xilinx hard Tri-Mode Eth MAC driver"
> +#define DRV_VERSION     "0.10a"
> +#define DRV_RELDATE     "07/10/2006"

For mainline submission, VERSION and RELDATE are irrelevant.

> +
> +#if defined(__KERNEL__)
> +#define LINUX 1
> +#endif
> +static const char version[] = DRV_NAME ".c:v" DRV_VERSION " "
> DRV_RELDATE "  David H. Lynch Jr. (dhlii at dlasys.net)\n";
> +
> +#if defined(LINUX)

Heh; I'm pretty sure we're running on Linux here.

> +#include <linux/module.h>
> +#include <linux/ioport.h>
> +#include <linux/netdevice.h>
> +#include <linux/etherdevice.h>
> +#include <linux/init.h>
> +#include <linux/skbuff.h>
> +#include <linux/spinlock.h>
> +#include <linux/crc32.h>
> +
> +#include <linux/mii.h>
> +#include <linux/delay.h>
> +#include <linux/platform_device.h>
> +#include <linux/xilinx_devices.h>
> +#include <linux/ethtool.h>
> +#include <asm/delay.h>
> +#include <asm/irq.h>
> +#include <asm/io.h>
> +
> +#define FRAME_ALIGNMENT                 8                       /* Byte
> alignment of ethernet frames */
> +typedef char EthFrame[9000] __attribute__ ((aligned(FRAME_ALIGNMENT)));
> +
> +#define TRUE                                    1
> +#define FALSE                                   0
> +
> +#define TEMAC_RX_TIMEOUT            (jiffies + ((1 * HZ)/5))
> +#define TEMAC_TX_TIMEOUT            (jiffies + (2 * HZ))
> +#define TEMAC_MII_TIMEOUT           (jiffies + (2 * HZ))    /* timer
> wakeup time : 2 second */
> +
> +/*
> +Transmit timeout, default 5 seconds.
> + */
> +static int
> +watchdog = 5000;
> +module_param(watchdog, int, 0400);
> +MODULE_PARM_DESC(watchdog, "transmit timeout in milliseconds");

Is this best done as a module parm?  I would think this is something
you'd want to change of the fily... then again, it's just a watchdog
timer.  How often is in necessary to fiddle with the timeout?

> +
> +static struct platform_device *temac_device;
> +
> +/* for exclusion of all program flows (processes, ISRs and BHs) */
> +DEFINE_SPINLOCK(XTE_spinlock);

Avoid uppercase in variable defines.

> +#define res_size(_r) (((_r)->end - (_r)->start) + 1)
> +#define EnetDbPrint(dev,msg)

Avoid CamelCaseFunctionsAndDefines.

> +#define Success 0
> +#define Failure -1

0 as success is a pretty well defined convention.  Don't add new
defines for it here.

> +#define Error int

Remove this, just use 'int'

<snip>

> +
> +#define db_printf       DEBUG_PRINTK
> +/* use 0 for production, 1 for verification, >1 for debug */
> +#if defined(CONFIG_PICO_DEBUG_TEMAC)
> +#define DEBUG_FUNC              if (lp->dbg)
> {dbg_printk("\n%s:%s()",DRV_NAME, __FUNCTION__);}
> +#define DEBUG_FUNC_EXIT         if (lp->dbg) {dbg_printk("\n%s:%s()
> exit",DRV_NAME,__FUNCTION__);}
> +#define DEBUG_FUNC_EX(ret)      if (lp->dbg)
> {dbg_printk("\n%s:%s(%d)exit",DRV_NAME,__FUNCTION__,ret);}
> +#define DEBUG_PRINTL(args...)   if (lp->dbg) dbg_printk("\n" __FILE__
> ": " args)
> +#define DEBUG_PRINTK(args...)   if (lp->dbg) dbg_printk(args)
> +#define DEBUG_PUTS(fmt...)      if (lp->dbg) dbg_puts(fmt)
> +void dbg_printk(unsigned char *fmt, ...);
> +static unsigned int debug = 1;
> +#else
> +#define DEBUG_FUNC              do { } while(0)
> +#define DEBUG_FUNC_EXIT         do { } while(0)
> +#define DEBUG_PRINTL(args...)   do { } while(0)
> +#define DEBUG_PRINTK(args...)   do { } while(0)
> +#define DEBUG_PUTS(args...)     do { } while(0)
> +#define dump_skb(lp, skb) 0
> +#define dump_skb_data(lp, skb, str) 0
> +static unsigned int debug = 1;
> +#endif

Not a good idea to add your own debug print functions.  Drivers should
use dev_dbg(), dev_info(), etc.  Or in the odd case where the dev
structure is not available, user the pr_debug() macro.

<snip>

> +/* This type encapsulates a packet FIFO channel and support attributes to
> + * allow unaligned data transfers.
> + */
> +struct temac_pktFifo {
> +    u32             Hold[2];                /* Holding register */
> +    unsigned        ByteIndex;              /* Holding register index */
> +    unsigned        Width;                  /* Width of packet FIFO's
> keyhole data port in bytes */
> +    u32             RegBaseAddress;         /**< Base address of
> registers */
> +    u32             DataBaseAddress;        /**< Base address of data
> for FIFOs */
> +} ;
> +
> +struct temac_local {
> +#if defined(LINUX)
> +    struct sk_buff              *deferred_skb;     /* buffer for one
> skb in case no room is available for transmission */
> +
> +//  void                        *RxFramePtr;       /* Address of first
> RxFrame */
> +    unsigned                    MaxFrameSz;        /* Size in bytes of
> largest frame for Tx or Rx */
> +//  u32                         RxPktFifoDepth;    /**< Depth of
> receive packet FIFO in bits */
> +//  u32                         TxPktFifoDepth;    /**< Depth of
> transmit packet FIFO in bits */
> +//  u16                         MacFifoDepth;      /**< Depth of the
> status/length FIFOs in entries */
> +
> +    struct resource             *nic_addr_res;     /* resources found */
> +    struct resource             *phy_addr_res;
> +    struct resource             *nic_addr_req;     /* resources
> requested */
> +    struct resource             *phy_addr_req;
> +    void __iomem                *nic_vaddr;        /* Register I/O base
> address */
> +
> +    struct mii_if_info          mii_if;
> +#else
> +    EnetDevice                  enetDevice;
> +    InterruptHandler            handler;
> +    struct sk_buff              __skb[(NUM_TX_BDS+NUM_RX_BDS) +
> (MAX_CACHE_LINE_SIZE/sizeof(struct sk_buff))];
> +    char                        name[20];
> +    u32                         base_addr;
> +    u8                          dev_addr[6];
> +
> +    u32                         disablecount;
> +    u32                         enablecount;
> +    u32                         tx_reset_pending;
> +    u32                         rx_reset_pending;
> +    u32                         reads_denied_during_reset;
> +    u32                         writes_denied_during_reset;
> +
> +    int                         devno;
> +    Error                       (*GetLinkStatus)(struct temac_local *
> lp, LinkSpeed *linkSpeed, LinkStatus *linkStatus, LinkDuplex  *linkDuplex);
> +
> +    PHY                         mii_if;
> +    u32                         trans_start;
> +    u32                         last_rx;
> +#endif
> +    unsigned int                mii:1;              /* mii port
> available */
> +    u8                          regshift;
> +    u32                         msg_enable;         /* debug message
> level */
> +    struct net_device_stats     stats;              /* Statistics for
> this device */
> +    unsigned int                phy_mode;          /* dcr */
> +    u16                         phy_addr;
> +    u32                         phy_status;
> +    unsigned int                poll:1;
> +    unsigned int                dbg:1;              /* debug ? */
> +    unsigned int                nic_type;           /* plb/ll */
> +    int                         LinkSpeed;          /* Speed of link
> 10/100/1000 */
> +    u32                         options;            /* Current options
> word */
> +//  u32                         TxPktFifoErrors;    /**< Number of Tx
> packet FIFO errors detected */
> +//  u32                         TxStatusErrors;
> +//  u32                         RxPktFifoErrors;    /**< Number of Rx
> packet FIFO errors detected */
> +//  u32                         RxRejectErrors;
> +//  u32                         FifoErrors;         /**< Number of
> length/status FIFO errors detected */
> +//  u32                         IpifErrors;         /**< Number of IPIF
> transaction and data phase errors detected */
> +//  u32                         Interrupts;         /**< Number of

Remove the commented out members; they can be added in when needed.

<snip>

> +static u32
> +_ior(u32 offset) {
> +    u32 value;
> +    value = (*(volatile u32 *) (offset));
> +    __asm__ __volatile__("eieio");
> +    return value;
> +}
> +
> +static void
> +_iow(u32 offset, u32 value) {
> +    (*(volatile u32 *) (offset) = value);
> +    __asm__ __volatile__("eieio");
> +}
> +
> +static u32
> +ior(struct net_device *ndev, int offset) {
> +    return _ior(ndev->base_addr + offset);
> +}
> +
> +static u32
> +ios(struct net_device *ndev) {
> +    return ior(ndev, XTE_IPIER_OFFSET) & ior(ndev, XTE_IPISR_OFFSET);
> +}
> +
> +static void
> +iow(struct net_device *ndev, int offset, u32 value) {
> +    _iow(ndev->base_addr + offset, value);
> +}

Don't define new IO functions.  Use the ones in <asm/io.h>

> +
> +/***************************************************************************
> + * Reads an MII register from the MII PHY attached to the Xilinx Temac.
> + *
> + * Parameters:
> + *   dev      - the temac device.
> + *   phy_addr - the address of the PHY [0..31]
> + *   reg_num  - the number of the register to read. 0-6 are defined by
> + *              the MII spec, but most PHYs have more.
> + *   reg_value - this is set to the specified register's value
> + *
> + * Returns:
> + *   Success or Failure
> + */
> +static Error
> +g_mdio_read(struct net_device *ndev, int phy_id, int reg_num, u16 *
> reg_val) {

what does the 'g_' prefix signify?

<snip>

> +        switch (ii) {
> +            case MII_ANI:
> +                disp_mii(ndev, "ANI", ii);
> +                break;
> +            case MII_SSR:
> +                disp_mii(ndev, "SSR", ii);
> +                break;
> +            case MII_ISR:
> +                disp_mii(ndev, "ISR", ii);
> +                break;
> +            case MII_BMCR:
> +                disp_mii(ndev, "MCR", ii);
> +                break;
> +            case MII_BMSR:
> +                disp_mii(ndev, "MSR", ii);
> +                break;
> +            case MII_PHYSID1:
> +                disp_mii(ndev,"PHYSID1",ii);
> +                break;
> +            case MII_PHYSID2:
> +                disp_mii(ndev,"PHYSID2",ii);
> +                break;
> +            case MII_ADVERTISE:
> +                disp_mii(ndev,"ADV", ii);
> +                break;
> +            case MII_LPA:
> +                disp_mii(ndev,"LPA", ii);
> +                break;
> +            case MII_EXPANSION:
> +                disp_mii(ndev,"EXPANSION", ii);
> +                break;
> +            case MII_CTRL1000:
> +                disp_mii(ndev,"CTRL1000", ii);
> +                break;
> +            case MII_STAT1000:
> +                disp_mii(ndev,"STAT1000", ii);
> +                break;
> +            case MII_ESTATUS:
> +                disp_mii(ndev,"ESTATUS", ii);
> +                break;
> +            case MII_DCOUNTER:
> +                disp_mii(ndev,"DCOUNTER", ii);
> +                break;
> +            case MII_NWAYTEST:
> +                disp_mii(ndev,"NWAYTEST", ii);
> +                break;
> +            case MII_RERRCOUNTER:
> +                disp_mii(ndev,"RERRCOUNT", ii);
> +                break;
> +            case MII_SREVISION:
> +                disp_mii(ndev,"SREVISION",ii);
> +                break;
> +            case MII_RESV1:
> +                disp_mii(ndev,"RESV1",ii);
> +                break;
> +            case MII_LBRERROR:
> +                disp_mii(ndev,"LBERROR",ii);
> +                break;
> +            case MII_PHYADDR:
> +                disp_mii(ndev,"PHYADDR",ii);
> +                break;
> +            case MII_RESV2:
> +                disp_mii(ndev,"RESV2",ii);
> +                break;
> +            case MII_TPISTATUS:
> +                disp_mii(ndev,"TPISTATUS",ii);
> +                break;
> +            case MII_NCONFIG:
> +                disp_mii(ndev,"NCONFIG",ii);
> +                break;
> +#if 0
> +            case MII_FCSCOUNTER:
> +                disp_mii(ndev,"FCSCOUNTER",ii);
> +                break;
> +#endif

This case statement is a *really* good candidate to be replaced with a
lookup table.

> +            default:
> +                disp_mii(ndev,0, ii);
> +                break;
> +        }
> +    }
> +    /*
> +    Print TEMAC Receiver and Transmitter configuration
> +    */
> +    DEBUG_PRINTK("\nReading Hard TEMAC Regs:\n");
> +
> +    for (ii = 0x200,jj = 0; ii <= 0x3a4; ii += 4) {
> +        switch (ii) {
> +            case XTE_RXC0_OFFSET:
> +                disp_emac_cfg(ndev, "RxCW0", ii, jj++);
> +                break;
> +            case XTE_RXC1_OFFSET:
> +                disp_emac_cfg(ndev, "RxCW1", ii, jj++);
> +                break;
> +            case XTE_TXC_OFFSET:
> +                disp_emac_cfg(ndev, "TxCW", ii, jj++);
> +                break;
> +            case XTE_FCC_OFFSET:
> +                disp_emac_cfg(ndev, "Flow", ii, jj++);
> +                break;
> +            case XTE_EMCFG_OFFSET:
> +                disp_emac_cfg(ndev, "ModeCfg", ii, jj++);
> +                break;
> +            case XTE_MC_OFFSET:
> +                disp_emac_cfg(ndev, "MgmtCfg", ii, jj++);
> +                break;
> +            case XTE_UAW0_OFFSET:
> +                disp_emac_cfg(ndev, "MacAddr0", ii, jj++);
> +                break;
> +            case XTE_UAW1_OFFSET:
> +                disp_emac_cfg(ndev, "MacAddr1", ii, jj++);
> +                break;
> +            case XTE_MAW0_OFFSET:
> +                disp_emac_cfg(ndev, "AtAddr0", ii, jj++);
> +                break;
> +            case XTE_MAW1_OFFSET:
> +                disp_emac_cfg(ndev, "AtAddr1", ii, jj++);
> +                break;
> +            case XTE_AFM_OFFSET:
> +                disp_emac_cfg(ndev, "AtCAF", ii, jj++);
> +                break;
> +            case XGP_IRSTATUS:
> +                disp_emac_cfg(ndev, "ISR", ii, jj++);
> +                break;
> +            case XGP_IRENABLE:
> +                disp_emac_cfg(ndev, "IER", ii, jj++);
> +                break;

Same with this one.

> +            default:
> +                break;
> +        }
> +    }
> +    DEBUG_PRINTK("\n");
> +
> +    if (lp->nic_type == TEMAC_PLB) {
> +        DEBUG_PRINTK("\nReading PLB TEMAC Regs:\n");
> +
> +        for (ii = 0x0,jj = 4;ii <= 0x1020; ii += 4) {
> +            switch (ii) {
> +                case XTE_DISR_OFFSET:
> +                    disp_temac_cfg(ndev, "DISR", ii, jj++);
> +                    break;
> +                case XTE_DIPR_OFFSET:
> +                    disp_temac_cfg(ndev, "DIPR", ii, jj++);
> +                    break;
> +                case XTE_DIER_OFFSET:
> +                    disp_temac_cfg(ndev, "DIER", ii, jj++);
> +                    break;
> +                case XTE_DGIE_OFFSET:
> +                    disp_temac_cfg(ndev, "DGIE", ii, jj++);
> +                    break;
> +                case XTE_IPISR_OFFSET:
> +                    disp_temac_cfg(ndev, "IPISR", ii, jj++);
> +                    break;
> +                case XTE_IPIER_OFFSET:
> +                    disp_temac_cfg(ndev, "IPIER", ii, jj++);
> +                    break;
> +                case XTE_DSR_OFFSET:
> +                    disp_temac_cfg(ndev, "MIR", ii, jj++);
> +                    break;
> +                case XTE_TPLR_OFFSET:
> +                    // disp_temac_cfg(ndev, "TPLR", ii, jj++);  // do
> not try to display this register - BAD things will happen
> +                    break;
> +                case XTE_CR_OFFSET:
> +                    disp_temac_cfg(ndev, "CR", ii, jj++);
> +                    break;
> +                case XTE_TSR_OFFSET:
> +                    // disp_temac_cfg(ndev, "TSR", ii, jj++);
> +                    break;
> +                case XTE_RPLR_OFFSET:
> +                    // disp_temac_cfg(ndev, "RPLR", ii, jj++);
> +                    break;
> +                case XTE_RSR_OFFSET:
> +                    disp_temac_cfg(ndev, "RSR", ii, jj++);
> +                    break;
> +                case XTE_TPPR_OFFSET:
> +                    disp_temac_cfg(ndev, "TPPR", ii, jj++);
> +                    break;

Ditto

> +                default:
> +                    break;
> +            }
> +        }
> +    }
> +    DEBUG_PRINTK("\nDisplaying Options:\n");
> +
> +    for (ii = 0, jj = 0;ii < 32; ii++) {
> +        if ( lp->options & ( 1 << ii)) {
> +            jj++;
> +            if ((jj % 4) == 0) DEBUG_PRINTK("\n\t");
> +            switch ( 1 << ii) {
> +                case XTE_PROMISC_OPTION:
> +                    DEBUG_PRINTK("PROMISC ");
> +                    break;
> +                case XTE_JUMBO_OPTION:
> +                    DEBUG_PRINTK("JUMBO ");
> +                    break;
> +                case XTE_VLAN_OPTION:
> +                    DEBUG_PRINTK("VLAN ");
> +                    break;
> +                case XTE_FLOW_CONTROL_OPTION:
> +                    DEBUG_PRINTK("FLOW_CONTROL ");
> +                    break;
> +                case XTE_FCS_STRIP_OPTION:
> +                    DEBUG_PRINTK("FCS_STRIP ");
> +                    break;
> +                case XTE_FCS_INSERT_OPTION:
> +                    DEBUG_PRINTK("FCS_INSERT ");
> +                    break;
> +                case XTE_LENTYPE_ERR_OPTION:
> +                    DEBUG_PRINTK("LENTYPE ERR ");
> +                    break;
> +                case XTE_POLLED_OPTION:
> +                    DEBUG_PRINTK("POLLED ");
> +                    break;
> +                case XTE_REPORT_RXERR_OPTION:
> +                    DEBUG_PRINTK("REPORT_RXERR ");
> +                    break;
> +                case XTE_TRANSMITTER_ENABLE_OPTION:
> +                    DEBUG_PRINTK("TRANSMITTER_ENABLE ");
> +                    break;
> +                case XTE_RECEIVER_ENABLE_OPTION:
> +                    DEBUG_PRINTK("RECEIVER_ENABLE ");
> +                    break;
> +                case XTE_BROADCAST_OPTION:
> +                    DEBUG_PRINTK("BROADCAST ");
> +                    break;
> +                case XTE_MULTICAST_CAM_OPTION:
> +                    DEBUG_PRINTK("MULTICAST_CAM ");
> +                    break;
> +                case XTE_REPORT_TXSTATUS_OVERRUN_OPTION:
> +                    DEBUG_PRINTK("REPORT_TXSTATUS_OVERRUN ");
> +                    break;
> +                case XTE_ANEG_OPTION:
> +                    DEBUG_PRINTK("ANEG ");
> +                    break;

Ditto

<snip>

> +
> +static u8
> +recvBd[] = {
> +    0x00, 0x00, 0x00, 0x00,
> +    0x00, 0x00, 0x00, 0x00,
> +    0x00, 0x00, 0x00, 0x00,
> +    0x00, 0x00, 0x00, 0x00,
> +    0x00, 0x00, 0x00, 0x00,
> +    0x00, 0x00, 0x00, 0x00,
> +    0x00, 0x00, 0x00, 0x00,
> +    0x00, 0x00, 0x00, 0x00
> +};

Global variables are automatically zeroed.  No need to zero it explicitly.

<snip>

> +#else
> +    plb_temac_interrupt(ndev);
> +#...
>
> [Message clipped]

Heh; too big for my email client.... anyway; clean up the basic
comments, eliminate the non-Linux stuff and repost.  It will be much
easier to review when the coding style issues are sorted out.  Also,
take a look at your mailer and make sure you can email inline patches
without word wrapping.

Cheers and thanks,
g.


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

From misbah_khan at engineer.com  Wed Jul 25 14:44:55 2007
From: misbah_khan at engineer.com (Misbah khan)
Date: Tue, 24 Jul 2007 21:44:55 -0700 (PDT)
Subject: Interrupts on xilinx ml403
In-Reply-To: <11765540.post@talk.nabble.com>
References: <11708607.post@talk.nabble.com> <11758237.post@talk.nabble.com>
	<11765540.post@talk.nabble.com>
Message-ID: <11776097.post@talk.nabble.com>


hi ...

Well you are always welcome to contact me . Just look at the configuration
of registers are proper or not and you have followed Bigendian format or
not. more than 90 % of the problem comes when you dont configure the
controler registers properly.

----Misbah

Mirek23 wrote:
> 
> I will try to go further with that after trying Grant's suggestion. When I
> still have a problem I will contact you.
> 
> Best Regards
> 
> Mirek
> 
> Misbah khan wrote:
>> 
>> hi ..
>> 
>> If you could send me the code and the config related doc . I could then
>> be able to suggest you something. As per the understanding of the problem
>> i guess you are not congiguring the interrupt controller properly. you
>> have to use correct IRQ no for  that ports then other configuration such
>> as interrupt type, and whenever you service the interrupt you have to
>> clear the interrupt etc are to be taken care ....Please see the interrupt
>> controller register and do your settings correctly . If the same persists
>> then you please send me the code and the documents then only i could give
>> the exact explaination on this 
>> 
>> ----misbah
>> 
>> Mirek23 wrote:
>>> 
>>> Dear All,
>>> 
>>>       I use linux kernel 2.6 on ppc405 of my Avnet (xilinx like ml403)
>>> evaluation board.
>>> 
>>> I have setup the virtex-4 FPGA to deal with Themac and Serial
>>> interfaces. As input/output devices I have chosen 8 LEDs and DIP
>>> Switches.
>>> 
>>> With such a configuration I am able to control from Linux user
>>> applications via GPIO driver the LEDs and DIP Switches.
>>> 
>>> Right now I just wanted to make use of the interrupts. I have configured
>>> the Dip switches to use interrupt. The interrupt accoures when the DIP
>>> Switches state has changed.
>>> 
>>> In the BSP generated by EDK 9.1 I see that macro :   
>>> 
>>> #define XPAR_DIP_SWITCHES_8BIT_INTERRUPT_PRESENT 1
>>> 
>>> has changed from zero to one.
>>> The macro XPAR_INTC_MAX_NUM_INTR_INPUTS is set to 1 as it was before.
>>> This is due to the fact that 
>>> TEMAC uses one interrupt line.
>>> 
>>> Does it mean that DIP Switches do not use INTC interrupt controller?
>>> How to handle the DIP Switches interrupt?
>>> Does the Interrupt handler routine have to acknowledge the interrupt
>>> from Dip Switches?
>>> 
>>> Many thanks in advance for any hint on that.
>>> 
>>> Best Regards
>>> 
>>> Mirek
>>> 
>>> 
>>> 
>>> 
>>>  
>>> 
>> 
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Interrupts-on-xilinx-ml403-tf4117226.html#a11776097
Sent from the linuxppc-embedded mailing list archive at Nabble.com.


From misbah_khan at engineer.com  Wed Jul 25 16:26:33 2007
From: misbah_khan at engineer.com (Misbah khan)
Date: Tue, 24 Jul 2007 23:26:33 -0700 (PDT)
Subject: Circular queue
In-Reply-To: <46A5B5BA.2080707@dlasys.net>
References: <46A5B5BA.2080707@dlasys.net>
Message-ID: <11777050.post@talk.nabble.com>


hi ....

Yes ofcourse there is a data structure for circular buffer implementation in
the driver but for the version 2.6.10 and onwards. Just see the
documentation on header file <linux/kfifo.h> I myself never tried with this
,where in i had implimented a circular buffer in the kernel and you need to
take care with the read index and write index. I suggest you to built your
own circular buffer insted on relaying on the standered because as far as i
know you should not relay on something new and untested . If you feel any
problem in the implementation i can help you in that. 

regard 
Misbah


David H. Lynch Jr.-2 wrote:
> 
>     Is there a standard linux datastructure and routines to manage
> circular queues ?
> 
>     I have a device that is not fundimentally different from a serial
> character device
>     except it is faster and the fundimental data type is 36 bits large.
> 
>     I have coded my own routines to setup and maintain a simple circular
> queue,
>     but I was hoping that there might be something more standard that
> already exists.
> 
>     Anyone know of anything ?
>    
> 
>    
> 
> 
> 
> 
> 
> -- 
> Dave Lynch 					  	    DLA Systems
> Software Development:  				         Embedded Linux
> 717.627.3770 	       dhlii at dlasys.net 	  http://www.dlasys.net
> fax: 1.253.369.9244 			           Cell: 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 at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 

-- 
View this message in context: http://www.nabble.com/Circular-queue-tf4134423.html#a11777050
Sent from the linuxppc-embedded mailing list archive at Nabble.com.


From nethra_gmit at yahoo.co.in  Wed Jul 25 19:29:09 2007
From: nethra_gmit at yahoo.co.in (Nethra)
Date: Wed, 25 Jul 2007 02:29:09 -0700 (PDT)
Subject: ping command
Message-ID: <11779249.post@talk.nabble.com>


hi,

I m using custom board same as eval board MPC8272ADS board.

IP assigned for both ethernets are...

              ifconfig eth1 192.168.33.135 up
	 ifconfig eth1 netmask 255.255.248.0
 	 route add default gw 192.168.32.47 eth1
 
 
	 ifconfig eth0 192.168.178.89 up
	 ifconfig eth0netmask 255.255.255.0
	 route add default gw 192.168.178.47 eth0

but if i try for ping 192.168.33.135 command pails by the server of 178
series
similarly ping 192.168.178.89 command pails by the server of 33 series..

what is the problem..and whre i m going wrong..?

thanks in advance..

Nethra

-- 
View this message in context: http://www.nabble.com/ping-command-tf4141032.html#a11779249
Sent from the linuxppc-embedded mailing list archive at Nabble.com.


From zhia.howe.chong at intel.com  Wed Jul 25 19:03:05 2007
From: zhia.howe.chong at intel.com (Chong, Zhia Howe)
Date: Wed, 25 Jul 2007 17:03:05 +0800
Subject: EST's VisionClick debugger fixes for Elf files from GNU tools
Message-ID: <ED3AB1534F018544848A18EE0E01E0AC117CCB@pgsmsx414.gar.corp.intel.com>

Hi,

            I am currently learning to use VisionClick with the
VisionICE II debugger. Are you aware of using it in Linux? I can only
use in VxWorks OS. If you know how to use in Linux, mind show me some
steps in doing it? 

 

Thanks.

 

 

Thanks.

 

Regards,

Chong Zhia Howe

Industrial Internship Trainee(TME)

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070725/a568481f/attachment.htm 

From tglx at linutronix.de  Thu Jul 26 05:10:56 2007
From: tglx at linutronix.de (Thomas Gleixner)
Date: Wed, 25 Jul 2007 21:10:56 +0200
Subject: [PATCH] mpx5200_uart: drop port lock across tty_flip_buffer() call
Message-ID: <1185390656.3227.12.camel@chaos>

The port lock needs to be dropped across the tty_flip_buffer call, as it
would lead to a deadlock with the spin_lock(&port->lock) in uart_start()

Uncovered by lockdep / preempt-rt

Signed-off-by: Thomas Gleixner <tglx at linutronix.de>


Index: linux-2.6.22/drivers/serial/mpc52xx_uart.c
===================================================================
--- linux-2.6.22.orig/drivers/serial/mpc52xx_uart.c	2007-07-09 01:32:17.000000000 +0200
+++ linux-2.6.22/drivers/serial/mpc52xx_uart.c	2007-07-25 21:06:11.000000000 +0200
@@ -501,7 +501,9 @@ mpc52xx_uart_int_rx_chars(struct uart_po
 		}
 	}
 
+	spin_unlock(&port->lock);
 	tty_flip_buffer_push(tty);
+	spin_lock(&port->lock);
 
 	return in_be16(&PSC(port)->mpc52xx_psc_status) & MPC52xx_PSC_SR_RXRDY;
 }



From grant.likely at secretlab.ca  Thu Jul 26 05:42:36 2007
From: grant.likely at secretlab.ca (Grant Likely)
Date: Wed, 25 Jul 2007 13:42:36 -0600
Subject: [PATCH] mpx5200_uart: drop port lock across tty_flip_buffer() call
In-Reply-To: <1185390656.3227.12.camel@chaos>
References: <1185390656.3227.12.camel@chaos>
Message-ID: <fa686aa40707251242i6be0e30pd3b4019686308b0@mail.gmail.com>

On 7/25/07, Thomas Gleixner <tglx at linutronix.de> wrote:
> The port lock needs to be dropped across the tty_flip_buffer call, as it
> would lead to a deadlock with the spin_lock(&port->lock) in uart_start()
>
> Uncovered by lockdep / preempt-rt
>
> Signed-off-by: Thomas Gleixner <tglx at linutronix.de>

Instead of dropping the lock and reclaiming it, would it be better for
me to rework the driver to only grab the lock in the 'meat' of
mpc52xx_uart_int_rx_chars() and mpc52xx_uart_int_tx_chars()?   (As
opposed to holding the lock for the entirety of mpc52xx_uart_int())
What convention is used in other drivers?

Cheers,
g.

>
>
> Index: linux-2.6.22/drivers/serial/mpc52xx_uart.c
> ===================================================================
> --- linux-2.6.22.orig/drivers/serial/mpc52xx_uart.c     2007-07-09 01:32:17.000000000 +0200
> +++ linux-2.6.22/drivers/serial/mpc52xx_uart.c  2007-07-25 21:06:11.000000000 +0200
> @@ -501,7 +501,9 @@ mpc52xx_uart_int_rx_chars(struct uart_po
>                 }
>         }
>
> +       spin_unlock(&port->lock);
>         tty_flip_buffer_push(tty);
> +       spin_lock(&port->lock);
>
>         return in_be16(&PSC(port)->mpc52xx_psc_status) & MPC52xx_PSC_SR_RXRDY;
>  }
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

From tglx at linutronix.de  Thu Jul 26 05:47:18 2007
From: tglx at linutronix.de (Thomas Gleixner)
Date: Wed, 25 Jul 2007 21:47:18 +0200
Subject: [PATCH] mpx5200_uart: drop port lock across tty_flip_buffer() call
In-Reply-To: <fa686aa40707251242i6be0e30pd3b4019686308b0@mail.gmail.com>
References: <1185390656.3227.12.camel@chaos>
	<fa686aa40707251242i6be0e30pd3b4019686308b0@mail.gmail.com>
Message-ID: <1185392838.3227.13.camel@chaos>

On Wed, 2007-07-25 at 13:42 -0600, Grant Likely wrote:
> On 7/25/07, Thomas Gleixner <tglx at linutronix.de> wrote:
> > The port lock needs to be dropped across the tty_flip_buffer call, as it
> > would lead to a deadlock with the spin_lock(&port->lock) in uart_start()
> >
> > Uncovered by lockdep / preempt-rt
> >
> > Signed-off-by: Thomas Gleixner <tglx at linutronix.de>
> 
> Instead of dropping the lock and reclaiming it, would it be better for
> me to rework the driver to only grab the lock in the 'meat' of
> mpc52xx_uart_int_rx_chars() and mpc52xx_uart_int_tx_chars()?   (As
> opposed to holding the lock for the entirety of mpc52xx_uart_int())

No, it's not worth the trouble. You need to protect the hardware access.

> What convention is used in other drivers?

The same.

	tglx



From grant.likely at secretlab.ca  Thu Jul 26 05:54:06 2007
From: grant.likely at secretlab.ca (Grant Likely)
Date: Wed, 25 Jul 2007 13:54:06 -0600
Subject: [PATCH] mpx5200_uart: drop port lock across tty_flip_buffer() call
In-Reply-To: <1185392838.3227.13.camel@chaos>
References: <1185390656.3227.12.camel@chaos>
	<fa686aa40707251242i6be0e30pd3b4019686308b0@mail.gmail.com>
	<1185392838.3227.13.camel@chaos>
Message-ID: <fa686aa40707251254q150b8f30k292c2163df02be4c@mail.gmail.com>

On 7/25/07, Thomas Gleixner <tglx at linutronix.de> wrote:
> On Wed, 2007-07-25 at 13:42 -0600, Grant Likely wrote:
> > On 7/25/07, Thomas Gleixner <tglx at linutronix.de> wrote:
> > > The port lock needs to be dropped across the tty_flip_buffer call, as it
> > > would lead to a deadlock with the spin_lock(&port->lock) in uart_start()
> > >
> > > Uncovered by lockdep / preempt-rt
> > >
> > > Signed-off-by: Thomas Gleixner <tglx at linutronix.de>
> >
> > Instead of dropping the lock and reclaiming it, would it be better for
> > me to rework the driver to only grab the lock in the 'meat' of
> > mpc52xx_uart_int_rx_chars() and mpc52xx_uart_int_tx_chars()?   (As
> > opposed to holding the lock for the entirety of mpc52xx_uart_int())
>
> No, it's not worth the trouble. You need to protect the hardware access.
>
> > What convention is used in other drivers?
>
> The same.

Okay, thanks.

Signed-off-by: Grant Likely <grant.likely at secretlab.ca>

Kumar, this is a bug fix, can you pick it up please?

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

From ma.harounansari at gdatech.co.in  Thu Jul 26 16:55:38 2007
From: ma.harounansari at gdatech.co.in (Ansari)
Date: Thu, 26 Jul 2007 12:25:38 +0530
Subject: Reboot Command Makes kernel to hang (MPC8560)
Message-ID: <000801c7cf51$f98ebb90$9503a8c0@Ansari>

Hi all,

Processor (MPC8560)

Whenever reboot command is given in the linux console. The processor gets reset and it loads bootloader , kernel and when uncompressing the ramdisk it gets hang. The sample log is given below. Any u please tell me what are the factors that can makes this to happen.

Log 
----

070500 U-Boot 1.1.2 (May 30 2007 - 20:20:09)

Motorola PowerPC ProcessorID=00000000 Rev. PVR=80200020
Board: XXX MPC8560 [PowerQUICC III]
        CPU: 660 MHz
        CCB: 330 MHz
        DDR: 165 MHz
Performing version scanning
I2C:   ready
DRAM:  Configuring UPM for NAND
Configuring UPM for MSC8122 DSI Port
Initializing DRAM
    DDR: 256 MB
Relocating POST functions.
FLASH: 16 MB
L2 cache enabled: 256KB
In:    serial
Out:   serial
Err:   serial
Net:   MOTO ENET0: PHY is Intel LXT971A (1378e2)
MOTO ENET1: PHY is Intel LXT971A (1378e2)
MOTO ENET0, MOTO ENET1
POST I: Before relocation. <DEL> to start...   1 
POST II: After relocation. <DEL> to start...   1 
Micro Controller version 75
Hit any key to stop autoboot:  0 
## Booting image at ffd00000 ...
   Image Name:   070500 Linux-cscpp
   Created:      2007-05-30  14:49:24 UTC
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    938254 Bytes = 916.3 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at ff000000 ...
   Image Name:   070500 cscpp-REL_7_5
   Created:      2007-05-30  14:51:09 UTC
   Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
   Data Size:    3543240 Bytes =  3.4 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Loading Ramdisk to 0fc4e000, end 0ffaf0c8 ... OK
Memory CAM mapping: CAM0=256Mb, CAM1=0Mb, CAM2=0Mb residual: 0Mb
Linux version 2.4.20_mvlcge31-cscpp-7.5 (root at turing) (gcc version 3.3.1 (MontaVista 3.3.1-3.0.10.0300532 2003-12-24)) #1 Wed May 30 20:14:43 IST 2007
max_pfn = 8192
On node 0 totalpages: 65536
zone(0): 65536 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/ram rw console=ttyS0,115200 ip=off
OpenPIC Version 1.2 (1 CPUs and 44 IRQ sources) at fdf80000
time_init: decrementer frequency = 41.250000 MHz
hr_time_init: arch_to_nsec = 50840048, nsec_to_arch = 177167400
Calibrating delay loop... 658.63 BogoMIPS
Memory: 253056k available (1696k kernel code, 760k data, 68k init, 0k highmem)
RMON - kernel resource monitoring
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
LSP Revision 14
ikconfig 0.5 with /proc/ikconfig
Starting kswapd
Journalled Block Device driver loaded
JFFS version 1.0, (C) 1999, 2000  Axis Communications AB
JFFS2 version 2.1. (C) 2001, 2002 Red Hat, Inc., designed by Axis Communications AB.
CPM UART driver version 0.01
ttyS0 on SCC1 at 0x8000, BRG1
pty: 256 Unix98 ptys configured
eth0: FCC ENET Version 0.3, 02:e0:0c:80:31:03
eth0: RMON initialized
RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize
loop: loaded (max 8 devices)
eth1: Gianfar Ethernet Controller Version 1.0, 02:e0:0c:00:31:03 
eth1: Running with NAPI disabled
eth1: 64/64 RX/TX BD ring size
eth1: RMON initialized
eth2: Gianfar Ethernet Controller Version 1.0, 02:e0:0c:00:31:02 
eth2: Running with NAPI disabled
eth2: 64/64 RX/TX BD ring size
eth2: RMON initialized
network device driver for LKCD registered
Crash dump driver initialized.
CSC flash: Found 1 x16 devices at 0x0 in 16-bit bank
 Intel/Sharp Extended Query Table at 0x0031
Using buffer write method
cfi_cmdset_0001: Erase suspend on write enabled
Creating 7 MTD partitions on "CSC flash":
0x00f80000-0x01000000 : "uboot"
0x00d00000-0x00e00000 : "kernel0"
0x00e00000-0x00f00000 : "kernel1"
0x00700000-0x00d00000 : "app"
0x00000000-0x00380000 : "root0"
0x00380000-0x00700000 : "root1"
0x00f00000-0x00f80000 : "env"
Creating 2 MTD partitions on "CSC NVRAM":
0x00000000-0x00010000 : "applog"
0x00010000-0x00020000 : "kernellog"
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xca (Unknown NAND 256MiB 3,3V 16-bit)
Scanning device for bad blocks
Bad eraseblock 1780 at 0x0de80000
Creating 1 MTD partitions on "NAND 256MiB 3,3V 16-bit":
0x00000000-0x10000000 : "NAND Partition"
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
ip_conntrack version 2.1 (2048 buckets, 16384 max) - 296 bytes per conntrack
ip_tables: (C) 2000-2002 Netfilter core team
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Event Broker Driver (C) 2001,2002 MontaVista Software (source at mvista.com)
Done starting sysfs
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 3460k freed
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 68k init

Welcome to Linux Group

Starting system...
Mounting /proc: done.
Brining up loopback interface: done.
Mounting /tmp: done.
Starting syslogd: done.
Starting klogd: done.
Starting telnetd: done.

MC-I2C DRIVER Successfully Installed
mcc: mcc_dev_siram_entries_config: siram config: start entry: 0, start channel: 128, count: 64
mcc: mcc_dev_siram_entries_config: siram config: start entry: 128, start channel: 192, count: 64
mcc: mcc_dev_iopin_init: IO port init done
mcc: mcc_dev_clock_mux_init: clock mux init done 0x88
mcc: mcc_dev_init: Board specific init done.
mcc: mcc_dev_init: BDs init done
mcc: mcc_dev_init: global param init done
mcc: mcc_dev_init: extra channel param init done
mcc: mcc_dev_init: channel param init done
[: 1: unknown operand

DSP-7116: Driver registered. 
DSP MSC 7116 Driver for HDI Interface May 30 2007  20:19:35
DSP-7116: Insmoded Successfully Default Status & Control Register 426 6618

MSC8122_DSI driver registered. 
MSC8122_DSI Driver for DSI Interface May 30 2007  20:19:35DSI init...[2]
loading LSCL module...May 30 2007 ,20:19:36
scc  at 0x8100
sccp 0xd2575a20
priv size 176
dev name lscl0
scc1 clk 0x000100b2
device lscl0 
lscl module loaded
Setting the LSCL address & IP address
setting slot id 0x0021
bonding.c:v2.2.5 (May 22, 2003)
bonding_init(): eth1 primary device specified but has no effect in fault-tolerance (broadcast) mode
bond0 registered with MII link monitoring set to 200 ms, in fault-tolerance (broadcast) mode.
bond0 registered without ARP monitoring
eth1: PHY is Intel LXT971A (1378e2)
eth1: No link detected
bond0: enslaving eth1 as an active interface with a down link.
eth1: Auto-negotiation done
eth1: Full Duplex
eth1: Speed 100BT
eth1: Link is up
eth2: PHY is Intel LXT971A (1378e2)
eth2: No link detected
bond0: enslaving eth2 as an active interface with a down link.
eth2: Auto-negotiation done
eth2: Full Duplex
eth2: Speed 100BT
eth2: Link is up
Setting system time from hardware clock.
yaffs: dev is 7945 name is "1f:09"
bond0: link status definitely up for interface eth2.
bond0: link status definitely up for interface eth1.
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000000: 0xd355 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000004: 0xcf85 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000008: 0x435c instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000000c: 0xc451 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000010: 0xb677 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000014: 0x15f5 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000018: 0xfbfb instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000001c: 0x4491 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000020: 0x543a instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000024: 0x1193 instead
Further such events for this erase block will not be printed
Cowardly refusing to erase blocks on filesystem with no valid JFFS2 nodes
empty_blocks 0, bad_blocks 0, c->nr_blocks 16
mount: Mounting /dev/mtdblock7 on /mnt/app-nvram failed: Invalid argument
Punching Microcontroller. 
Creating TSI LOCK fileDone
Starting the xxx agent

                 ====== SYSTEM STARTED ======


System started

  _____  _   _  _    _      __ _       _                     
 / ____|| \ | || |  | |    / /| |     (_)                    
| |  __ |  \| || |  | |   / / | |      _  _ __   _   _ __  __
| | |_ || .   || |  | |  / /  | |     | || '_ \ | | | |\ \/ /
| |__| || |\  || |__| | / /   | |____ | || | | || |_| | >  < 
 \_____||_| \_| \____/ /_/    |______||_||_| |_| \__,_|/_/\_\

(none) login: root


BusyBox v1.1.0 (2006.03.23-09:02+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

[root@(none) /root]# reboot

The system is going down NOW !!
Sending SIGTERM to all processeExiting Syslogd!
Sending SIGKILL to all processes.
Please stand by while rebooting the system.
Restarting systemste?

070500 U-Boot 1.1.2 (May 30 2007 - 20:20:09)

Motorola PowerPC ProcessorID=00000000 Rev. PVR=80200020
Board: XXX MPC8560 [PowerQUICC III]
        CPU: 660 MHz
        CCB: 330 MHz
        DDR: 165 MHz
Performing version scanning
I2C:   ready
DRAM:  Configuring UPM for NAND
Configuring UPM for MSC8122 DSI Port
Initializing DRAM
    DDR: 256 MB
Relocating POST functions.
FLASH: 16 MB
L2 cache enabled: 256KB
In:    serial
Out:   serial
Err:   serial
Net:   MOTO ENET0: PHY is Intel LXT971A (1378e2)
MOTO ENET1: PHY is Intel LXT971A (1378e2)
MOTO ENET0, MOTO ENET1
POST I: Before relocation. <DEL> to start...   1 
POST II: After relocation. <DEL> to start...   1 
Micro Controller version 75
Hit any key to stop autoboot:  0 
## Booting image at ffd00000 ...
   Image Name:   070500 Linux-cscpp
   Created:      2007-05-30  14:49:24 UTC
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    938254 Bytes = 916.3 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at ff000000 ...
   Image Name:   070500 cscpp-REL_7_5
   Created:      2007-05-30  14:51:09 UTC
   Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
   Data Size:    3543240 Bytes =  3.4 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Loading Ramdisk to 0fc4e000, end 0ffaf0c8 ... OK
Memory CAM mapping: CAM0=256Mb, CAM1=0Mb, CAM2=0Mb residual: 0Mb
Linux version 2.4.20_mvlcge31-cscpp-7.5 (root at turing) (gcc version 3.3.1 (MontaVista 3.3.1-3.0.10.0300532 2003-12-24)) #1 Wed May 30 20:14:43 IST 2007
max_pfn = 8192
On node 0 totalpages: 65536
zone(0): 65536 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/ram rw console=ttyS0,115200 ip=off
OpenPIC Version 1.2 (1 CPUs and 44 IRQ sources) at fdf80000
time_init: decrementer frequency = 41.250000 MHz
hr_time_init: arch_to_nsec = 50840048, nsec_to_arch = 177167400
Calibrating delay loop... 658.63 BogoMIPS
Memory: 253056k available (1696k kernel code, 760k data, 68k init, 0k highmem)
RMON - kernel resource monitoring
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
LSP Revision 14
ikconfig 0.5 with /proc/ikconfig
Starting kswapd
Journalled Block Device driver loaded
JFFS version 1.0, (C) 1999, 2000  Axis Communications AB
JFFS2 version 2.1. (C) 2001, 2002 Red Hat, Inc., designed by Axis Communications AB.
CPM UART driver version 0.01
ttyS0 on SCC1 at 0x8000, BRG1
pty: 256 Unix98 ptys configured
eth0: FCC ENET Version 0.3, 02:e0:0c:80:31:03
eth0: RMON initialized
RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize
loop: loaded (max 8 devices)
eth1: Gianfar Ethernet Controller Version 1.0, 02:e0:0c:00:31:03 
eth1: Running with NAPI disabled
eth1: 64/64 RX/TX BD ring size
eth1: RMON initialized
eth2: Gianfar Ethernet Controller Version 1.0, 02:e0:0c:00:31:02 
eth2: Running with NAPI disabled
eth2: 64/64 RX/TX BD ring size
eth2: RMON initialized
network device driver for LKCD registered
Crash dump driver initialized.
CSC flash: Found 1 x16 devices at 0x0 in 16-bit bank
 Intel/Sharp Extended Query Table at 0x0031
Using buffer write method
cfi_cmdset_0001: Erase suspend on write enabled
Creating 7 MTD partitions on "CSC flash":
0x00f80000-0x01000000 : "uboot"
0x00d00000-0x00e00000 : "kernel0"
0x00e00000-0x00f00000 : "kernel1"
0x00700000-0x00d00000 : "app"
0x00000000-0x00380000 : "root0"
0x00380000-0x00700000 : "root1"
0x00f00000-0x00f80000 : "env"
Creating 2 MTD partitions on "CSC NVRAM":
0x00000000-0x00010000 : "applog"
0x00010000-0x00020000 : "kernellog"
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xca (Unknown NAND 256MiB 3,3V 16-bit)
Scanning device for bad blocks
Bad eraseblock 1780 at 0x0de80000
Creating 1 MTD partitions on "NAND 256MiB 3,3V 16-bit":
0x00000000-0x10000000 : "NAND Partition"
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
ip_conntrack version 2.1 (2048 buckets, 16384 max) - 296 bytes per conntrack
ip_tables: (C) 2000-2002 Netfilter core team
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Event Broker Driver (C) 2001,2002 MontaVista Software (source at mvista.com)
Done starting sysfs
RAMDISK: Compressed image found at block 0
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<Hangs Here>>>>>>>>>>>>>>>>>>>>>>


Thanks in advance

Haroun Ansari M A

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070726/8e8ce313/attachment-0001.htm 

From cmoszhang at yahoo.com.cn  Thu Jul 26 17:58:04 2007
From: cmoszhang at yahoo.com.cn (=?gb2312?q?=C0=FB=C6=BD=20=D5=C5?=)
Date: Thu, 26 Jul 2007 15:58:04 +0800 (CST)
Subject: i have a question about:ppc pci and frame_buffer
Message-ID: <749612.18053.qm@web15210.mail.cnb.yahoo.com>

now i have a question:
  i know ppc is big_endian and pci bus is little_endian.i made a graphics pci card use big_endian.
  when i use graphics card to show QT 's picture through VGA ,the color is not what i wanted, it's inversed ,others are in right position.
  here below is what i want :
  #################################################
  0..................7  8............15 16..............24 25.................31 
           B                    G                   R                TRANS
  now it is this:
  #################################################
  0..................7  8............15 16..............24 25.................31 
        TRANS               R                   G                   B
  #################################################
   
  through mmap, the ppc display the screen color through direct pci bus control ,how can i change it?? 
  change kernel?? (i don't know where to change)
  or change others?? 

       
---------------------------------
????????3.5G???20M??? 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070726/a6b33d0e/attachment.htm 

From erik at dd.nec.com.au  Thu Jul 26 19:11:10 2007
From: erik at dd.nec.com.au (Erik Christiansen)
Date: Thu, 26 Jul 2007 19:11:10 +1000
Subject: I have a question about:ppc pci and frame_buffer
In-Reply-To: <749612.18053.qm@web15210.mail.cnb.yahoo.com>
References: <749612.18053.qm@web15210.mail.cnb.yahoo.com>
Message-ID: <20070726091110.GB8884@dd.nec.com.au>

On Thu, Jul 26, 2007 at 03:58:04PM +0800, ???? ?? wrote:
>   here below is what i want :
>   #################################################
>   0..................7  8............15 16..............24 25.................31 
>            B                    G                   R                TRANS
>   now it is this:
>   #################################################
>   0..................7  8............15 16..............24 25.................31 
>         TRANS               R                   G                   B

In U-boot, there is what you might do yourself, perhaps:

#define LONGSWAP(x) ((((x) & 0x000000ff) << 24) | (((x) & 0x0000ff00) << 8)|\
           (((x) & 0x00ff0000) >>  8) | (((x) & 0xff000000) >> 24) )
#define PCISWAP(x)   LONGSWAP(x)

Any good for your purpose?

Erik

From daniel.schnell at marel.com  Thu Jul 26 19:25:05 2007
From: daniel.schnell at marel.com (Daniel Schnell)
Date: Thu, 26 Jul 2007 09:25:05 -0000
Subject: [PATCH] mpx5200_uart: drop port lock across tty_flip_buffer() call
In-Reply-To: <1185392838.3227.13.camel@chaos>
References: <1185390656.3227.12.camel@chaos><fa686aa40707251242i6be0e30pd3b4019686308b0@mail.gmail.com>
	<1185392838.3227.13.camel@chaos>
Message-ID: <DD39B5C3F4963040ADC9768BE7E430CB02178125@is-hdq-exchange.marel.net>

Thomas Gleixner wrote:

> On Wed, 2007-07-25 at 13:42 -0600, Grant Likely wrote:
>> On 7/25/07, Thomas Gleixner <tglx at linutronix.de> wrote:
>>> The port lock needs to be dropped across the tty_flip_buffer call,
>>> as it would lead to a deadlock with the spin_lock(&port->lock) in
>>> uart_start() 
>>> 
>>> Uncovered by lockdep / preempt-rt
>>> 
>>> Signed-off-by: Thomas Gleixner <tglx at linutronix.de>

While you are at it 8?> ... the mpc5200-fec driver has serious problems with preempt-rt, similar to what the IBM emac had ....


Best regards,

Daniel Schnell.

From tglx at linutronix.de  Thu Jul 26 19:41:18 2007
From: tglx at linutronix.de (Thomas Gleixner)
Date: Thu, 26 Jul 2007 11:41:18 +0200
Subject: [PATCH] mpx5200_uart: drop port lock across tty_flip_buffer() call
In-Reply-To: <DD39B5C3F4963040ADC9768BE7E430CB02178125@is-hdq-exchange.marel.net>
References: <1185390656.3227.12.camel@chaos>
	<fa686aa40707251242i6be0e30pd3b4019686308b0@mail.gmail.com>
	<1185392838.3227.13.camel@chaos>
	<DD39B5C3F4963040ADC9768BE7E430CB02178125@is-hdq-exchange.marel.net>
Message-ID: <1185442878.3227.23.camel@chaos>

On Thu, 2007-07-26 at 09:25 +0000, Daniel Schnell wrote:
> Thomas Gleixner wrote:
> 
> > On Wed, 2007-07-25 at 13:42 -0600, Grant Likely wrote:
> >> On 7/25/07, Thomas Gleixner <tglx at linutronix.de> wrote:
> >>> The port lock needs to be dropped across the tty_flip_buffer call,
> >>> as it would lead to a deadlock with the spin_lock(&port->lock) in
> >>> uart_start() 
> >>> 
> >>> Uncovered by lockdep / preempt-rt
> >>> 
> >>> Signed-off-by: Thomas Gleixner <tglx at linutronix.de>
> 
> While you are at it 8?> ... the mpc5200-fec driver has serious
> problems with preempt-rt, similar to what the IBM emac had ....

Care to whip up a patch ?

	tglx



From pradyumna.sampath at gmail.com  Thu Jul 26 22:34:21 2007
From: pradyumna.sampath at gmail.com (Pradyumna Sampath)
Date: Thu, 26 Jul 2007 18:04:21 +0530
Subject: [Trace how to] Kernel Bug when entering something after login
In-Reply-To: <200707261000.25465.juergen127@kreuzholzen.de>
References: <200707251900.47704.juergen127@kreuzholzen.de>
	<1185390398.3227.8.camel@chaos>
	<200707261000.25465.juergen127@kreuzholzen.de>
Message-ID: <f87351060707260534k2f87ff47rdcfd0b787d5a0132@mail.gmail.com>

Hi Everyone,

On 7/26/07, Juergen Beisert <juergen127 at kreuzholzen.de> wrote:
> On Wednesday 25 July 2007 21:06, Thomas Gleixner wrote:
> > Solution below
>
> Seems to work now. Thanks.
>
> Juergen
> -

First of all very sorry to cross post.

I discovered the same problem on our MPC5200 and it after patching, it
now works. But I could somehow not get the call trace and hence could
not report the bug.

I compiled the kernel with "CONFIG_FUNCTION_TRACE" and then I get
undefined references on "early_printk". Is there something I am doing
wrong in the kernel config or was there an additional patch to enable
this support for MPC5200 ?

I see more bugs when I run "stress" but I cant solve them or even
report them, because I cant see the trace information.

thanks in advance
regards
/prady

-- 
htp://prady.livejournal.com

From bwarren at qstreams.com  Fri Jul 27 00:09:25 2007
From: bwarren at qstreams.com (Ben Warren)
Date: Thu, 26 Jul 2007 10:09:25 -0400
Subject: ping command
In-Reply-To: <11779249.post@talk.nabble.com>
References: <11779249.post@talk.nabble.com>
Message-ID: <1185458965.6839.8.camel@saruman.qstreams.net>

Nethra,

On Wed, 2007-07-25 at 02:29 -0700, Nethra wrote:
> hi,
> 
> I m using custom board same as eval board MPC8272ADS board.
> 
> IP assigned for both ethernets are...
> 
>               ifconfig eth1 192.168.33.135 up
> 	 ifconfig eth1 netmask 255.255.248.0
>  	 route add default gw 192.168.32.47 eth1
>  
> 
> 	 ifconfig eth0 192.168.178.89 up
> 	 ifconfig eth0netmask 255.255.255.0
> 	 route add default gw 192.168.178.47 eth0
> 
> but if i try for ping 192.168.33.135 command pails by the server of 178
> series
> similarly ping 192.168.178.89 command pails by the server of 33 series..
> 
> what is the problem..and whre i m going wrong..?

What does your routing table show?  (route -n).  It wouldn't hurt to
also post the output of ifconfig for both interfaces.

regards,
Ben


From Martin.Leisner at xerox.com  Fri Jul 27 01:17:32 2007
From: Martin.Leisner at xerox.com (Leisner, Martin)
Date: Thu, 26 Jul 2007 11:17:32 -0400
Subject: support for MPC8220?
In-Reply-To: <20070724211104.GL1678@pengutronix.de>
References: <556445368AFA1C438794ABDA8901891C066B5B56@usa0300ms03.na.xerox.net>
	<20070724211104.GL1678@pengutronix.de>
Message-ID: <556445368AFA1C438794ABDA8901891C066B5B5E@usa0300ms03.na.xerox.net>

 
actually, it's there -- you have to find it (I saw it once, I can't
find it again).  (other search engines seem to do a better job).

I think MPC8220 runs well without MMU -- the montavista PRO 3.1 the
freescale
site discusses 2.4.20...

We ran an 8220 at one time on 2.4.20 -- I recall there was some
flakiness, and we used
a montavista system, so it must have been 3.1...


marty

> -----Original Message-----
> From: Robert Schwebel [mailto:rsc at pengutronix.de] On Behalf 
> Of Robert Schwebel
> Sent: Tuesday, July 24, 2007 5:11 PM
> To: Leisner, Martin
> Cc: linuxppc-embedded at ozlabs.org
> Subject: Re: support for MPC8220?
> 
> On Mon, Jul 23, 2007 at 11:27:00AM -0400, Leisner, Martin wrote:
> > Is there support for MPC8220 in current kernels?
> 
> 8220? Are you sure? That part doesn't exist on the freescale site.
> 
> Robert 
> -- 
>  Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
>  Pengutronix - Linux Solutions for Science and Industry
>    Handelsregister:  Amtsgericht Hildesheim, HRA 2686
>      Hannoversche Str. 2, 31134 Hildesheim, Germany
>    Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9
> 
> 

From bgat at billgatliff.com  Fri Jul 27 02:28:48 2007
From: bgat at billgatliff.com (Bill Gatliff)
Date: Thu, 26 Jul 2007 11:28:48 -0500
Subject: Gdbserver syscall clobber
In-Reply-To: <20070723161512.GA3235@caradoc.them.org>
References: <469B922D.3050701@billgatliff.com>
	<20070716155348.GA5281@caradoc.them.org>
	<469E550E.5080905@billgatliff.com>
	<20070718183143.GA25324@caradoc.them.org>
	<46A4D1F5.1060005@billgatliff.com>
	<20070723161512.GA3235@caradoc.them.org>
Message-ID: <46A8CBC0.8010909@billgatliff.com>

Daniel Jacobowitz wrote:
> Look around do_signal:
>
>                         regs->nip -= 4; /* Back up & retry system call */
>
> If your kernel has corrupted the register containing the syscall
> number at this point, that would explain your problem.  It will then
> do the wrong syscall.  I guess PPC only backs up one instruction.
>
>   

Found the code in do_signal, right where you said it would be.  I threw 
in a printk or two to see what's up when an ERESTARTSYS is detected, and 
started getting OOPSes all over the place.  Apparently that's not a good 
place for printk.  :)

Before I go on, can anyone confirm that gdbserver and/or strace _ever_ 
worked with circa 2.4.16 PPC kernels?



b.g.

-- 
Bill Gatliff
bgat at billgatliff.com


From galak at kernel.crashing.org  Fri Jul 27 05:51:31 2007
From: galak at kernel.crashing.org (Kumar Gala)
Date: Thu, 26 Jul 2007 14:51:31 -0500
Subject: Reboot Command Makes kernel to hang (MPC8560)
In-Reply-To: <000801c7cf51$f98ebb90$9503a8c0@Ansari>
References: <000801c7cf51$f98ebb90$9503a8c0@Ansari>
Message-ID: <880B302A-742A-4CC1-BB41-E7BD1CE570C6@kernel.crashing.org>


On Jul 26, 2007, at 1:55 AM, Ansari wrote:

> Hi all,
>
> Processor (MPC8560)
>
> Whenever reboot command is given in the linux console. The  
> processor gets reset and it loads bootloader , kernel and when  
> uncompressing the ramdisk it gets hang. The sample log is given  
> below. Any u please tell me what are the factors that can makes  
> this to happen.

This is very board dependant.  The MPC8560 doesn't have a clean way  
to request reset, and odds are you're only getting the core reset and  
not the full chip.

- k


From dwh at ovro.caltech.edu  Fri Jul 27 05:55:11 2007
From: dwh at ovro.caltech.edu (David Hawkins)
Date: Thu, 26 Jul 2007 12:55:11 -0700
Subject: Circular queue
In-Reply-To: <46A5B5BA.2080707@dlasys.net>
References: <46A5B5BA.2080707@dlasys.net>
Message-ID: <46A8FC1F.5070807@ovro.caltech.edu>

David H. Lynch Jr. wrote:
>     Is there a standard linux datastructure and routines to manage
> circular queues ?
> 
>     I have a device that is not fundimentally different from a serial
> character device
>     except it is faster and the fundimental data type is 36 bits large.
> 
>     I have coded my own routines to setup and maintain a simple circular
> queue,
>     but I was hoping that there might be something more standard that
> already exists.
> 
>     Anyone know of anything ?

Hi David,

Have you looked at the linked-list support? You can use it
for a circular queue.

I just copied the following comments from some driver examples
I wrote a while back:

http://www.ovro.caltech.edu/~dwh/correlator/software/driver_design.tar.gz
http://www.ovro.caltech.edu/~dwh/correlator/pdf/LNX-723-Hawkins.pdf

  simple_page_buffer.c

  *-----------------------------------------------------------------
  * References:
  * [1] "Linux device drivers", 3rd Ed, J. Corbet, A. Rubini,
  *      G. Kroah-Hartman, 2005
  * [2] "Linux kernel development", 2nd Ed., R. Love.
  *-----------------------------------------------------------------
  */

  * For details on linked-lists, see p295 [1] and p345 [2].

I didn't look at the code again, but I'm pretty sure I used the
linked list for a circular buffer.

Cheers
Dave

From mederle_nicolas at yahoo.fr  Fri Jul 27 16:36:10 2007
From: mederle_nicolas at yahoo.fr (Nicolas Mederle)
Date: Fri, 27 Jul 2007 08:36:10 +0200
Subject: Decermenter overflow interrupt atfer the init.d launch.
Message-ID: <46A9925A.2060508@yahoo.fr>

Hi,

       I want to know how the kernel switch the task. Because my kernel 
start very well, and it launch  the init.d. With the log, i can see that 
the kernel launch the getty task. But after, there is a decrementer 
overflow interrupt  ( vector at adress 900 ). Is it the task switch? Or 
is it an error in the decrementer init.

-- 

Cordialement,

MEDERLE Nicolas.


From nethra_gmit at yahoo.co.in  Fri Jul 27 16:41:32 2007
From: nethra_gmit at yahoo.co.in (Nethra)
Date: Thu, 26 Jul 2007 23:41:32 -0700 (PDT)
Subject: creation of jffs2 rootfile system..
Message-ID: <11823840.post@talk.nabble.com>


when boot the board with jffs2 rootfile system i m getting output like this,

TCP: Hash tables configured (established 4096 bind 8192)
IPv4 over IPv4 tunneling driver
NET: Registered protocol family 1
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
Disabled Privacy Extensions on device c02527a0(lo)
IP-Config: Incomplete network configuration information.
Empty flash at 0x0000ffa0 ends at 0x00010000
Empty flash at 0x0002ffec ends at 0x00030000
Empty flash at 0x0004ffe8 ends at 0x00050000
Empty flash at 0x0006ffc8 ends at 0x00070000
Empty flash at 0x0008fffc ends at 0x00090000
Empty flash at 0x000afffc ends at 0x000b0000
Empty flash at 0x000cfffc ends at 0x000d0000
Empty flash at 0x000efffc ends at 0x000f0000
Empty flash at 0x0010fffc ends at 0x00110000
Empty flash at 0x0012fffc ends at 0x00130000
Empty flash at 0x0014fffc ends at 0x00150000
Empty flash at 0x0016fffc ends at 0x00170000
Empty flash at 0x0018fffc ends at 0x00190000
Empty flash at 0x001cfffc ends at 0x001d0000
Empty flash at 0x001efffc ends at 0x001f0000
Empty flash at 0x0020fffc ends at 0x00210000
Empty flash at 0x0022fffc ends at 0x00230000
Empty flash at 0x0024fffc ends at 0x00250000
Empty flash at 0x0026fffc ends at 0x00270000
Empty flash at 0x002afffc ends at 0x002b0000
Empty flash at 0x002cfffc ends at 0x002d0000
VFS: Mounted root (jffs2 filesystem).
Freeing unused kernel memory: 108k init

Please press Enter to activate this console.
/ #
/ #
/ #

login prompt itself is not coming and
 
ps command is not working....
# ps
  PID  Uid     VmSize Stat Command
#

what is the problem..?

waiting for early response,
Nethra

-- 
View this message in context: http://www.nabble.com/creation-of-jffs2-rootfile-system..-tf4155759.html#a11823840
Sent from the linuxppc-embedded mailing list archive at Nabble.com.


From galak at kernel.crashing.org  Fri Jul 27 16:46:42 2007
From: galak at kernel.crashing.org (Kumar Gala)
Date: Fri, 27 Jul 2007 01:46:42 -0500
Subject: Decermenter overflow interrupt atfer the init.d launch.
In-Reply-To: <46A9925A.2060508@yahoo.fr>
References: <46A9925A.2060508@yahoo.fr>
Message-ID: <D4037DB6-8832-4057-A9FF-BAD32592E6C9@kernel.crashing.org>


On Jul 27, 2007, at 1:36 AM, Nicolas Mederle wrote:

> Hi,
>
>        I want to know how the kernel switch the task. Because my  
> kernel
> start very well, and it launch  the init.d. With the log, i can see  
> that
> the kernel launch the getty task. But after, there is a decrementer
> overflow interrupt  ( vector at adress 900 ). Is it the task  
> switch? Or
> is it an error in the decrementer init.

This should be a task switch.  The decrementer is used to handle the  
periodic interrupt to switch processes.

- k

From nethra_gmit at yahoo.co.in  Fri Jul 27 16:46:52 2007
From: nethra_gmit at yahoo.co.in (Nethra)
Date: Thu, 26 Jul 2007 23:46:52 -0700 (PDT)
Subject: ping command
In-Reply-To: <1185458965.6839.8.camel@saruman.qstreams.net>
References: <11779249.post@talk.nabble.com>
	<1185458965.6839.8.camel@saruman.qstreams.net>
Message-ID: <11823845.post@talk.nabble.com>


root at cashel:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use
Iface
192.168.178.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.32.0    0.0.0.0         255.255.248.0   U     0      0        0 eth1
0.0.0.0         192.168.32.47   0.0.0.0         UG    0      0        0 eth1
0.0.0.0         192.168.178.47  0.0.0.0         UG    0      0        0 eth0
root at cashel:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:13:72:FE:A9:02
          inet addr:192.168.178.89  Bcast:192.168.178.255 
Mask:255.255.255.0
          inet6 addr: fe80::213:72ff:fefe:a902/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:15665 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9285 errors:0 dropped:0 overruns:0 carrier:9019
          collisions:0 txqueuelen:1000
          RX bytes:12957285 (12.3 MiB)  TX bytes:2720267 (2.5 MiB)
          Base address:0x8400

eth1      Link encap:Ethernet  HWaddr 00:13:72:7E:A9:02
          inet addr:192.168.33.135  Bcast:192.168.33.255  Mask:255.255.248.0
          inet6 addr: fe80::213:72ff:fe7e:a902/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:634 errors:0 dropped:0 overruns:0 frame:0
          TX packets:84 errors:0 dropped:0 overruns:0 carrier:82
          collisions:0 txqueuelen:1000
          RX bytes:103558 (101.1 KiB)  TX bytes:12832 (12.5 KiB)
          Base address:0x8500

lo        Link encap:Local Loopback
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

root at cashel:~#


On Wed, 2007-07-25 at 02:29 -0700, Nethra wrote:
> hi,
> 
> I m using custom board same as eval board MPC8272ADS board.
> 
> IP assigned for both ethernets are...
> 
>               ifconfig eth1 192.168.33.135 up
> 	 ifconfig eth1 netmask 255.255.248.0
>  	 route add default gw 192.168.32.47 eth1
>  
> 
> 	 ifconfig eth0 192.168.178.89 up
> 	 ifconfig eth0netmask 255.255.255.0
> 	 route add default gw 192.168.178.47 eth0
> 
> but if i try for ping 192.168.33.135 command pails by the server of 178
> series
> similarly ping 192.168.178.89 command pails by the server of 33 series..
> 
> what is the problem..and whre i m going wrong..?

What does your routing table show?  (route -n).  It wouldn't hurt to
also post the output of ifconfig for both interfaces.

regards,
Ben

_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded at ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded



-- 
View this message in context: http://www.nabble.com/ping-command-tf4141032.html#a11823845
Sent from the linuxppc-embedded mailing list archive at Nabble.com.


From benh at kernel.crashing.org  Fri Jul 27 17:26:20 2007
From: benh at kernel.crashing.org (Benjamin Herrenschmidt)
Date: Fri, 27 Jul 2007 17:26:20 +1000
Subject: Decermenter overflow interrupt atfer the init.d launch.
In-Reply-To: <D4037DB6-8832-4057-A9FF-BAD32592E6C9@kernel.crashing.org>
References: <46A9925A.2060508@yahoo.fr>
	<D4037DB6-8832-4057-A9FF-BAD32592E6C9@kernel.crashing.org>
Message-ID: <1185521180.5495.194.camel@localhost.localdomain>

On Fri, 2007-07-27 at 01:46 -0500, Kumar Gala wrote:
> On Jul 27, 2007, at 1:36 AM, Nicolas Mederle wrote:
> 
> > Hi,
> >
> >        I want to know how the kernel switch the task. Because my  
> > kernel
> > start very well, and it launch  the init.d. With the log, i can see  
> > that
> > the kernel launch the getty task. But after, there is a decrementer
> > overflow interrupt  ( vector at adress 900 ). Is it the task  
> > switch? Or
> > is it an error in the decrementer init.
> 
> This should be a task switch.  The decrementer is used to handle the  
> periodic interrupt to switch processes.

I would have expected quite of few of these actually before you get
there :-)

Ben.



From fvoegel at carangul.com  Fri Jul 27 18:40:23 2007
From: fvoegel at carangul.com (Florian A. Voegel)
Date: Fri, 27 Jul 2007 10:40:23 +0200
Subject: creation of jffs2 rootfile system..
In-Reply-To: <11823840.post@talk.nabble.com>
References: <11823840.post@talk.nabble.com>
Message-ID: <20070727104023.78048ea4.fvoegel@carangul.com>


Hi Nethra,

what does your inittab and your startup files look like? It looks like

- your inittab does not start a getty but rather a shell, thus no login
- your /proc isn't mounted, and it's needed for ps to work properly


Greets,

Florian Voegel
Carangul.Tech

On Thu, 26 Jul 2007 23:41:32 -0700 (PDT)
Nethra <nethra_gmit at yahoo.co.in> wrote:

> 
> when boot the board with jffs2 rootfile system i m getting output like this,
> 
> TCP: Hash tables configured (established 4096 bind 8192)
> IPv4 over IPv4 tunneling driver
> NET: Registered protocol family 1
> NET: Registered protocol family 10
> IPv6 over IPv4 tunneling driver
> NET: Registered protocol family 17
> Disabled Privacy Extensions on device c02527a0(lo)
> IP-Config: Incomplete network configuration information.
> Empty flash at 0x0000ffa0 ends at 0x00010000
> Empty flash at 0x0002ffec ends at 0x00030000
> Empty flash at 0x0004ffe8 ends at 0x00050000
> Empty flash at 0x0006ffc8 ends at 0x00070000
> Empty flash at 0x0008fffc ends at 0x00090000
> Empty flash at 0x000afffc ends at 0x000b0000
> Empty flash at 0x000cfffc ends at 0x000d0000
> Empty flash at 0x000efffc ends at 0x000f0000
> Empty flash at 0x0010fffc ends at 0x00110000
> Empty flash at 0x0012fffc ends at 0x00130000
> Empty flash at 0x0014fffc ends at 0x00150000
> Empty flash at 0x0016fffc ends at 0x00170000
> Empty flash at 0x0018fffc ends at 0x00190000
> Empty flash at 0x001cfffc ends at 0x001d0000
> Empty flash at 0x001efffc ends at 0x001f0000
> Empty flash at 0x0020fffc ends at 0x00210000
> Empty flash at 0x0022fffc ends at 0x00230000
> Empty flash at 0x0024fffc ends at 0x00250000
> Empty flash at 0x0026fffc ends at 0x00270000
> Empty flash at 0x002afffc ends at 0x002b0000
> Empty flash at 0x002cfffc ends at 0x002d0000
> VFS: Mounted root (jffs2 filesystem).
> Freeing unused kernel memory: 108k init
> 
> Please press Enter to activate this console.
> / #
> / #
> / #
> 
> login prompt itself is not coming and
>  
> ps command is not working....
> # ps
>   PID  Uid     VmSize Stat Command
> #
> 
> what is the problem..?
> 
> waiting for early response,
> Nethra
> 
> -- 
> View this message in context: http://www.nabble.com/creation-of-jffs2-rootfile-system..-tf4155759.html#a11823840
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 

From nethra_gmit at yahoo.co.in  Fri Jul 27 20:22:59 2007
From: nethra_gmit at yahoo.co.in (Nethra)
Date: Fri, 27 Jul 2007 03:22:59 -0700 (PDT)
Subject: creation of jffs2 rootfile system..
In-Reply-To: <20070727104023.78048ea4.fvoegel@carangul.com>
References: <11823840.post@talk.nabble.com>
	<20070727104023.78048ea4.fvoegel@carangul.com>
Message-ID: <11826448.post@talk.nabble.com>


I m creating jffs2 root file system using devrocket,

this is the bootlog i m getting....

VFS: Mounted root (jffs2 filesystem).
Freeing unused kernel memory: 108k init
readlink: /etc/mtab: No such file or directory
0
readlink: /etc/mtab: No such file or directory
Mounting local filesystems: mount nothing was mounted
Cleaning: /tmp BusyBox v1.01 (2005.12.18-04:27+0000) multi-call binary

Usage: find [PATH...] [EXPRESSION]

Search for files in a directory hierarchy.  The default PATH is
the current directory; default EXPRESSION is '-print'

EXPRESSION may consist of:
        -follow         Dereference symbolic links.
        -name PATTERN   File name (leading directories removed) matches
PATTERN.
        -print          Print (default and assumed).

        -type X         Filetype matches X (where X is one of:
f,d,l,b,c,...)
        -perm PERMS     Permissions match any of (+NNN); all of (-NNN);
                        or exactly (NNN)
        -mtime TIME     Modified time is greater than (+N); less than (-N);
                        or exactly (N) days

/var/lock cd: 77: can't cd to /var/lock
/var/run BusyBox v1.01 (2005.12.18-04:27+0000) multi-call binary

Usage: find [PATH...] [EXPRESSION]

Search for files in a directory hierarchy.  The default PATH is
the current directory; default EXPRESSION is '-print'

EXPRESSION may consist of:
        -follow         Dereference symbolic links.
        -name PATTERN   File name (leading directories removed) matches
PATTERN.
        -print          Print (default and assumed).

        -type X         Filetype matches X (where X is one of:
f,d,l,b,c,...)
        -perm PERMS     Permissions match any of (+NNN); all of (-NNN);
                        or exactly (NNN)
        -mtime TIME     Modified time is greater than (+N); less than (-N);
                        or exactly (N) days

grep: /etc/group: No such file or directory
done.
Setting pseudo-terminal access permissions...chown: unknown group name: tty
done.
Updating /etc/motd...sed: /etc/motd: No such file or directory
done.
/etc/rc.d/rcS.d/S55bootmisc.sh: 119: cannot create /var/log/dmesg: Directory
nonexistent
: done.

Please press Enter to activate this console.
/#

now ps command is working properly.

why i m not getting login..?


Florian A. Voegel wrote:
> 
> 
> Hi Nethra,
> 
> what does your inittab and your startup files look like? It looks like
> 
> - your inittab does not start a getty but rather a shell, thus no login
> - your /proc isn't mounted, and it's needed for ps to work properly
> 
> 
> Greets,
> 
> Florian Voegel
> Carangul.Tech
> 
> On Thu, 26 Jul 2007 23:41:32 -0700 (PDT)
> Nethra <nethra_gmit at yahoo.co.in> wrote:
> 
>> 
>> when boot the board with jffs2 rootfile system i m getting output like
>> this,
>> 
>> TCP: Hash tables configured (established 4096 bind 8192)
>> IPv4 over IPv4 tunneling driver
>> NET: Registered protocol family 1
>> NET: Registered protocol family 10
>> IPv6 over IPv4 tunneling driver
>> NET: Registered protocol family 17
>> Disabled Privacy Extensions on device c02527a0(lo)
>> IP-Config: Incomplete network configuration information.
>> Empty flash at 0x0000ffa0 ends at 0x00010000
>> Empty flash at 0x0002ffec ends at 0x00030000
>> Empty flash at 0x0004ffe8 ends at 0x00050000
>> Empty flash at 0x0006ffc8 ends at 0x00070000
>> Empty flash at 0x0008fffc ends at 0x00090000
>> Empty flash at 0x000afffc ends at 0x000b0000
>> Empty flash at 0x000cfffc ends at 0x000d0000
>> Empty flash at 0x000efffc ends at 0x000f0000
>> Empty flash at 0x0010fffc ends at 0x00110000
>> Empty flash at 0x0012fffc ends at 0x00130000
>> Empty flash at 0x0014fffc ends at 0x00150000
>> Empty flash at 0x0016fffc ends at 0x00170000
>> Empty flash at 0x0018fffc ends at 0x00190000
>> Empty flash at 0x001cfffc ends at 0x001d0000
>> Empty flash at 0x001efffc ends at 0x001f0000
>> Empty flash at 0x0020fffc ends at 0x00210000
>> Empty flash at 0x0022fffc ends at 0x00230000
>> Empty flash at 0x0024fffc ends at 0x00250000
>> Empty flash at 0x0026fffc ends at 0x00270000
>> Empty flash at 0x002afffc ends at 0x002b0000
>> Empty flash at 0x002cfffc ends at 0x002d0000
>> VFS: Mounted root (jffs2 filesystem).
>> Freeing unused kernel memory: 108k init
>> 
>> Please press Enter to activate this console.
>> / #
>> / #
>> / #
>> 
>> login prompt itself is not coming and
>>  
>> ps command is not working....
>> # ps
>>   PID  Uid     VmSize Stat Command
>> #
>> 
>> what is the problem..?
>> 
>> waiting for early response,
>> Nethra
>> 
>> -- 
>> View this message in context:
>> http://www.nabble.com/creation-of-jffs2-rootfile-system..-tf4155759.html#a11823840
>> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>> 
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded at ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 

-- 
View this message in context: http://www.nabble.com/creation-of-jffs2-rootfile-system..-tf4155759.html#a11826448
Sent from the linuxppc-embedded mailing list archive at Nabble.com.


From juergen127 at kreuzholzen.de  Thu Jul 26 22:45:29 2007
From: juergen127 at kreuzholzen.de (Juergen Beisert)
Date: Thu, 26 Jul 2007 14:45:29 +0200
Subject: [Trace how to] Kernel Bug when entering something after login
In-Reply-To: <f87351060707260534k2f87ff47rdcfd0b787d5a0132@mail.gmail.com>
References: <200707251900.47704.juergen127@kreuzholzen.de>
	<200707261000.25465.juergen127@kreuzholzen.de>
	<f87351060707260534k2f87ff47rdcfd0b787d5a0132@mail.gmail.com>
Message-ID: <200707261445.30391.juergen127@kreuzholzen.de>

On Thursday 26 July 2007 14:34, Pradyumna Sampath wrote:
> Hi Everyone,
>
> On 7/26/07, Juergen Beisert <juergen127 at kreuzholzen.de> wrote:
> > On Wednesday 25 July 2007 21:06, Thomas Gleixner wrote:
> > > Solution below
> >
> > Seems to work now. Thanks.
> >
> > Juergen
> > -
>
> First of all very sorry to cross post.
>
> I discovered the same problem on our MPC5200 and it after patching, it
> now works. But I could somehow not get the call trace and hence could
> not report the bug.
>
> I compiled the kernel with "CONFIG_FUNCTION_TRACE" and then I get
> undefined references on "early_printk". Is there something I am doing
> wrong in the kernel config or was there an additional patch to enable
> this support for MPC5200 ?
>
> I see more bugs when I run "stress" but I cant solve them or even
> report them, because I cant see the trace information.

Activate "General setup" -> "Configure standard kernel features (for small 
systems)" -> "Load all symbols for debugging/ksymoops"

Juergen

From poorbeyond at 163.com  Fri Jul 27 23:11:19 2007
From: poorbeyond at 163.com (poorbeyond)
Date: Fri, 27 Jul 2007 21:11:19 +0800
Subject: a question about mpc8xx linux
Message-ID: <200707272111187341027@163.com>

my cpu is MPC860, use u-boot-1.1.4, linux-2.6.20.14

i use the "tftp 300000 uImage" command download kernel image,

then use the "bootm 300000" command boot the image.


i found the bootm cmd entered the /arch/ppc/kernel/head_8xx.s, stop at the instruction "rfi".
is it right? after the instruction, where does the code go normally ? what should i do now?

thanks

 .globl __start
__start:
 mr r31,r3   /* save parameters */
 mr r30,r4
 mr r29,r5
 mr r28,r6
 mr r27,r7

 /* We have to turn on the MMU right away so we get cache modes
  * set correctly.
  */
 bl initial_mmu

/* We now have the lower 8 Meg mapped into TLB entries, and the caches
 * ready to work.
 */

turn_on_mmu:
 mfmsr r0
 ori r0,r0,MSR_DR|MSR_IR
 mtspr SPRN_SRR1,r0
 lis r0,start_here at h
 ori r0,r0,start_here at l
 mtspr SPRN_SRR0,r0
 SYNC
 rfi    /* enables MMU */







poorbeyond
2007-07-27
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070727/11d7dbc7/attachment-0001.htm 

From scottwood at freescale.com  Sat Jul 28 03:53:43 2007
From: scottwood at freescale.com (Scott Wood)
Date: Fri, 27 Jul 2007 12:53:43 -0500
Subject: a question about mpc8xx linux
In-Reply-To: <200707272111187341027@163.com>
References: <200707272111187341027@163.com>
Message-ID: <46AA3127.4060806@freescale.com>

poorbeyond wrote:
> my cpu is MPC860, use u-boot-1.1.4, linux-2.6.20.14
> 
> i use the "tftp 300000 uImage" command download kernel image,
> 
> then use the "bootm 300000" command boot the image.

You'll need either a device-tree-aware u-boot or 8xx cuImage support; 
you can get the latter from the patchset I posted recently.

> i found the bootm cmd entered the /arch/ppc/kernel/head_8xx.s, stop at the instruction "rfi".
> is it right? after the instruction, where does the code go normally ? what should i do now?

The rfi transfers control to start_here:

-Scott

From scottwood at freescale.com  Sat Jul 28 03:56:06 2007
From: scottwood at freescale.com (Scott Wood)
Date: Fri, 27 Jul 2007 12:56:06 -0500
Subject: a question about mpc8xx linux
In-Reply-To: <46AA3127.4060806@freescale.com>
References: <200707272111187341027@163.com> <46AA3127.4060806@freescale.com>
Message-ID: <46AA31B6.4040809@freescale.com>

Scott Wood wrote:
> poorbeyond wrote:
> 
>>my cpu is MPC860, use u-boot-1.1.4, linux-2.6.20.14
>>
>>i use the "tftp 300000 uImage" command download kernel image,
>>
>>then use the "bootm 300000" command boot the image.
> 
> 
> You'll need either a device-tree-aware u-boot or 8xx cuImage support; 
> you can get the latter from the patchset I posted recently.

Sorry, I missed that you're using arch/ppc rather than arch/powerpc.

arch/ppc doesn't require a device tree, though it would be good to 
switch to arch/powerpc once my 8xx fixes go in -- arch/ppc is deprecated.

-Scott

From radanter at googlemail.com  Sat Jul 28 21:20:40 2007
From: radanter at googlemail.com (Richard Danter)
Date: Sat, 28 Jul 2007 12:20:40 +0100
Subject: EST's VisionClick debugger fixes for Elf files from GNU tools
In-Reply-To: <ED3AB1534F018544848A18EE0E01E0AC117CCB@pgsmsx414.gar.corp.intel.com>
References: <ED3AB1534F018544848A18EE0E01E0AC117CCB@pgsmsx414.gar.corp.intel.com>
Message-ID: <f75c52840707280420q3a051840s598a30a7bbc35ebc@mail.gmail.com>

On 25/07/07, Chong, Zhia Howe <zhia.howe.chong at intel.com> wrote:
>
>  Hi,
>
>             I am currently learning to use VisionClick with the VisionICE
> II debugger. Are you aware of using it in Linux? I can only use in VxWorks
> OS. If you know how to use in Linux, mind show me some steps in doing it?
>

Yes, depending on what version of vClick and vICE  firmware you have it is
possible to debug some things in Linux. What are you trying to do exactly?
Debug the kernel, modules, applications? What is the target? vClick is old
now, Wind River has newer and much better JTAG/BDM tools (Workbench OCD) for
working with Linux.

Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070728/873c003f/attachment.htm 

From mls.JOFT at gmx.de  Sun Jul 29 18:48:08 2007
From: mls.JOFT at gmx.de (Joachim =?ISO-8859-1?Q?F=F6rster?=)
Date: Sun, 29 Jul 2007 10:48:08 +0200
Subject: ml403 ac97 driver
In-Reply-To: <2ec96d6e0707280204k50efb707q99a824c37f539309@mail.gmail.com>
References: <28652204.1477431184843737431.JavaMail.nabble@isper.nabble.com>
	<1184918815.5886.13.camel@localhost>
	<2ec96d6e0707280204k50efb707q99a824c37f539309@mail.gmail.com>
Message-ID: <1185698888.6397.37.camel@localhost>

Hi qin lin,

On Sat, 2007-07-28 at 17:04 +0800, qin lin wrote:
> I have add the driver to kernel as a module in ml403.When i insmod 
> the module ,there are warnings followed here:
> [  250.795594] snd-ml403_ac97cr: write access to codec register 0x26
> with bad value 0x800f / 32783! 
> [  250.911545] snd-ml403_ac97cr: write access to codec register 0x26
> with bad value 0xf / 15!
> [  251.015576] snd-ml403_ac97cr: write access to codec register 0x2a
> with bad value 0x2801 / 10241!
> [  251.127524] snd-ml403_ac97cr: write access to codec register 0x2a
> with bad value 0x3801 / 14337! 
> 
> And i check the warring find the warnings should be from function
> snd_ml403_ac97cr_codec_write() ?i have check the lm4550 codec
> datasheet to make sure the mask is what you have written.

These warnings are ok. Codec register 0x26 is the "PowerDown
Status/Control" register and the ALSA AC97 layer tries to write ones to
the lower 4 bits (which are AFAIK read only bits). LM4550 register 0x2a
has only one valid bit (lowest), but ALSA tries to write to a not
existing bit. So my driver masks out these bits.
The warnings show the invalid numbers ALSA wants to write to these
registers.

> What  confused  me is that where call the fuction
> snd_ml403_ac97cr_codec_write in the module_init program, would you
> mind if you point it for me? 

Well, the function alsa_card_ml403_ac97cr_init() is registered as the
module_init function. It registers the driver and the device to the
kernel via platform_driver/device_register(). As a consequence the
kernel will call the registered probe() function called
snd_ml403_ac97cr_probe(). Among other things, the function called
snd_ml403_ac97cr_mixer() is invoked. Finally this function registers a
mixer device and the codec_read() and codec_write() functions with the
ALSA AC97 layer. While registering the ALSA AC97 layer calls the read
and write functions several times - a kind of initialization sequence.
That's the usual structure of an ALSA driver - not that simple - I
know :-) .

> There is another problem trouble me .I find a simple test program to
> check  the codec playback work .But all it said that it cannot find
> the pcm file.Would you mind if you suggest something or paste what you
> have do to mknod the device? 

Oh, I forgot to mention that in the README file. I used the "snddevices"
script found in ALSA's alsa-driver package (form version 1.0.13, but
version shouldn't matter).

> # ./test_sound.out  /dev/snd/pcmC0D0
> ALSA lib pcm.c:2090:(snd_pcm_open_noupdate) Unknown
> PCM /dev/snd/pcmC0D0 
> cannot open audio device /dev/snd/pcmC0D0 (No such file or directory)

Hmmm, try to create the device files with the script from above and see
if that happens again ...
BTW: (After having created the device files) you can also use aplay
(alsa-utils package) for testing. Where did you find "test_sound"?

 Joachim



From niklaus.giger at member.fsf.org  Mon Jul 30 02:07:51 2007
From: niklaus.giger at member.fsf.org (Niklaus Giger)
Date: Sun, 29 Jul 2007 18:07:51 +0200
Subject: [PATCH] Fix compilation for non CONFIG_HOTPLUG case
Message-ID: <200707291807.52042.niklaus.giger@member.fsf.org>

Fixes compilation issues for embedded boards which do not support HOTPLUG

Signed-off-by: Niklaus Giger <niklaus.giger at member.fsf.org>
---
 drivers/base/core.c |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index 3599ab2..a09bfc8 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -24,7 +24,9 @@
 #include "base.h"
 #include "power/power.h"

+#ifdef CONFIG_HOTPLUG
 extern const char *kobject_actions[];
+#endif

 int (*platform_notify)(struct device * dev) = NULL;
 int (*platform_notify_remove)(struct device * dev) = NULL;
@@ -306,11 +308,13 @@ static ssize_t store_uevent(struct device *dev, struct 
device_attribute *attr,
 			    const char *buf, size_t count)
 {
 	size_t len = count;
+#ifdef CONFIG_HOTPLUG
 	enum kobject_action action;
-
+#endif
 	if (len && buf[len-1] == '\n')
 		len--;

+#ifdef CONFIG_HOTPLUG
 	for (action = 0; action < KOBJ_MAX; action++) {
 		if (strncmp(kobject_actions[action], buf, len) != 0)
 			continue;
@@ -319,11 +323,14 @@ static ssize_t store_uevent(struct device *dev, struct 
device_attribute *attr,
 		kobject_uevent(&dev->kobj, action);
 		goto out;
 	}
+#endif

 	dev_err(dev, "uevent: unsupported action-string; this will "
 		     "be ignored in a future kernel version\n");
 	kobject_uevent(&dev->kobj, KOBJ_ADD);
+#ifdef CONFIG_HOTPLUG
 out:
+#endif
 	return count;
 }

--
1.5.2.4

From sshtylyov at ru.mvista.com  Mon Jul 30 02:45:34 2007
From: sshtylyov at ru.mvista.com (Sergei Shtylyov)
Date: Sun, 29 Jul 2007 20:45:34 +0400
Subject: [PATCH] Fix compilation for non CONFIG_HOTPLUG case
In-Reply-To: <200707291807.52042.niklaus.giger@member.fsf.org>
References: <200707291807.52042.niklaus.giger@member.fsf.org>
Message-ID: <46ACC42E.8040907@ru.mvista.com>

Hello.

Niklaus Giger wrote:

> Fixes compilation issues for embedded boards which do not support HOTPLUG

> Signed-off-by: Niklaus Giger <niklaus.giger at member.fsf.org>

> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 3599ab2..a09bfc8 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -24,7 +24,9 @@
>  #include "base.h"
>  #include "power/power.h"
> 
> +#ifdef CONFIG_HOTPLUG
>  extern const char *kobject_actions[];
> +#endif

    No need for #ifdef around extern declarations.

>  int (*platform_notify)(struct device * dev) = NULL;
>  int (*platform_notify_remove)(struct device * dev) = NULL;
> @@ -306,11 +308,13 @@ static ssize_t store_uevent(struct device *dev, struct 
> device_attribute *attr,
>  			    const char *buf, size_t count)
>  {
>  	size_t len = count;
> +#ifdef CONFIG_HOTPLUG
>  	enum kobject_action action;
> -
> +#endif

    Please don't remove newline between the declaration block and the code.

>  	if (len && buf[len-1] == '\n')
>  		len--;
> 
> +#ifdef CONFIG_HOTPLUG
>  	for (action = 0; action < KOBJ_MAX; action++) {
>  		if (strncmp(kobject_actions[action], buf, len) != 0)
>  			continue;
> @@ -319,11 +323,14 @@ static ssize_t store_uevent(struct device *dev, struct 
> device_attribute *attr,
>  		kobject_uevent(&dev->kobj, action);
>  		goto out;

    Grr... cleanup style abuse -- ISO a mere return they used goto. :-/

>  	}
> +#endif
> 
>  	dev_err(dev, "uevent: unsupported action-string; this will "
>  		     "be ignored in a future kernel version\n");
>  	kobject_uevent(&dev->kobj, KOBJ_ADD);
> +#ifdef CONFIG_HOTPLUG
>  out:
> +#endif

    Well, #ifdef'ing out label seems too much.

>  	return count;
>  }

WBR, Sergei

From linkinge at gmail.com  Sun Jul 29 22:50:05 2007
From: linkinge at gmail.com (aq)
Date: Sun, 29 Jul 2007 05:50:05 -0700 (PDT)
Subject: ml403 ac97 driver
In-Reply-To: <1185698888.6397.37.camel@localhost>
References: <1185698888.6397.37.camel@localhost>
Message-ID: <11851202.post@talk.nabble.com>


 Joachim:

Thanks for your information. I will try it sooner.
The test program is A Minimal Playback Program   from website: 
http://equalarea.com/paul/alsa-audio.html

PS:Besides that test program i also used aplay to test codec ,the result is
no different. 

qin lin



Joachim F?rster wrote:
> 
> Hi qin lin,
> 
> On Sat, 2007-07-28 at 17:04 +0800, qin lin wrote:
>> I have add the driver to kernel as a module in ml403.When i insmod 
>> the module ,there are warnings followed here:
>> [  250.795594] snd-ml403_ac97cr: write access to codec register 0x26
>> with bad value 0x800f / 32783! 
>> [  250.911545] snd-ml403_ac97cr: write access to codec register 0x26
>> with bad value 0xf / 15!
>> [  251.015576] snd-ml403_ac97cr: write access to codec register 0x2a
>> with bad value 0x2801 / 10241!
>> [  251.127524] snd-ml403_ac97cr: write access to codec register 0x2a
>> with bad value 0x3801 / 14337! 
>> 
>> And i check the warring find the warnings should be from function
>> snd_ml403_ac97cr_codec_write() ?i have check the lm4550 codec
>> datasheet to make sure the mask is what you have written.
> 
> These warnings are ok. Codec register 0x26 is the "PowerDown
> Status/Control" register and the ALSA AC97 layer tries to write ones to
> the lower 4 bits (which are AFAIK read only bits). LM4550 register 0x2a
> has only one valid bit (lowest), but ALSA tries to write to a not
> existing bit. So my driver masks out these bits.
> The warnings show the invalid numbers ALSA wants to write to these
> registers.
> 
>> What  confused  me is that where call the fuction
>> snd_ml403_ac97cr_codec_write in the module_init program, would you
>> mind if you point it for me? 
> 
> Well, the function alsa_card_ml403_ac97cr_init() is registered as the
> module_init function. It registers the driver and the device to the
> kernel via platform_driver/device_register(). As a consequence the
> kernel will call the registered probe() function called
> snd_ml403_ac97cr_probe(). Among other things, the function called
> snd_ml403_ac97cr_mixer() is invoked. Finally this function registers a
> mixer device and the codec_read() and codec_write() functions with the
> ALSA AC97 layer. While registering the ALSA AC97 layer calls the read
> and write functions several times - a kind of initialization sequence.
> That's the usual structure of an ALSA driver - not that simple - I
> know :-) .
> 
>> There is another problem trouble me .I find a simple test program to
>> check  the codec playback work .But all it said that it cannot find
>> the pcm file.Would you mind if you suggest something or paste what you
>> have do to mknod the device? 
> 
> Oh, I forgot to mention that in the README file. I used the "snddevices"
> script found in ALSA's alsa-driver package (form version 1.0.13, but
> version shouldn't matter).
> 
>> # ./test_sound.out  /dev/snd/pcmC0D0
>> ALSA lib pcm.c:2090:(snd_pcm_open_noupdate) Unknown
>> PCM /dev/snd/pcmC0D0 
>> cannot open audio device /dev/snd/pcmC0D0 (No such file or directory)
> 
> Hmmm, try to create the device files with the script from above and see
> if that happens again ...
> BTW: (After having created the device files) you can also use aplay
> (alsa-utils package) for testing. Where did you find "test_sound"?
> 
>  Joachim
> 
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 

-- 
View this message in context: http://www.nabble.com/Re%3A-ml403-ac97-driver-tf4164866.html#a11851202
Sent from the linuxppc-embedded mailing list archive at Nabble.com.


From nix.or.die at googlemail.com  Mon Jul 30 03:07:41 2007
From: nix.or.die at googlemail.com (Gabriel C)
Date: Sun, 29 Jul 2007 19:07:41 +0200
Subject: [PATCH] Fix compilation for non CONFIG_HOTPLUG case
In-Reply-To: <46ACC42E.8040907@ru.mvista.com>
References: <200707291807.52042.niklaus.giger@member.fsf.org>
	<46ACC42E.8040907@ru.mvista.com>
Message-ID: <46ACC95D.5010702@googlemail.com>

This problem is already fixed in -mm .

http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc1/2.6.23-rc1-mm1/broken-out/gregkh-driver-kobject-fix-link-error-when-config_hotplug-is-disabled.patch


Regards,

Gabriel

From linkinge at gmail.com  Mon Jul 30 15:40:12 2007
From: linkinge at gmail.com (Qin Lin)
Date: Sun, 29 Jul 2007 22:40:12 -0700 (PDT)
Subject: ml403 ac97 driver
In-Reply-To: <1185698888.6397.37.camel@localhost>
References: <1185698888.6397.37.camel@localhost>
Message-ID: <11858308.post@talk.nabble.com>


Hi Joachim
I re-coross-compile alsa-lib and alsa-utils and install them in /usr on
board ,but the result is really no different .Would you mind if you point
out what i forget to do ? 



# insmod ac97_bus.ko
# insmod snd-ac97-codec.ko
# insmod ml403_ac97cr.ko
[   79.529114] ml403_ac97cr: remap controller memory region to 0xc500e000
done
[   79.611803] ml403_ac97cr: request (playback) irq 7 done
[   79.674236] ml403_ac97cr: request (capture) irq 6 done
[   79.784291] snd-ml403_ac97cr: write access to codec register 0x26 with
bad value 0x800f / 32783!
[   79.900247] snd-ml403_ac97cr: write access to codec register 0x26 with
bad value 0xf / 15!
[   80.004284] snd-ml403_ac97cr: write access to codec register 0x2a with
bad value 0x2801 / 10241!
[   80.116228] snd-ml403_ac97cr: write access to codec register 0x2a with
bad value 0x3801 / 14337!
# ./snddevices                      .........//use alsa-driver-1.0.14 
creating device nod script
Creating mixer?...done.
Creating sequencer...done.
Creating midi0?...done.
Creating dsp?...done.
Creating audio?...done.
Creating sndstat...done.
Creating music...done.
Creating dmmidi?...done.
Creating dmfm?...done.
Creating amixer?...done.
Creating adsp?...done.
Creating amidi?...done.
Creating admmidi?...done.
rm: /dev/snd: is a directory
Creating snd/control?...done.
Creating snd/seq...done.
Creating snd/timer...done.
Creating snd/hw??...done.
Creating snd/midi??...done.
Creating snd/pcm??p...done.
Creating snd/pcm??c...done.
Creating aload?...done.
Creating aloadSEQ...done.

# ls -l /dev/snd
crw-rw-rw-    1 root     root     116,   0 Jan  1 00:01 controlC0
crw-rw-rw-    1 root     root     116,   4 Jan  1 00:01 hwC0D0
crw-rw-rw-    1 root     root     116,   5 Jan  1 00:01 hwC0D1
crw-rw-rw-    1 root     root     116,   6 Jan  1 00:01 hwC0D2
crw-rw-rw-    1 root     root     116,   7 Jan  1 00:01 hwC0D3
crw-rw-rw-    1 root     root     116,  24 Jan  1 00:01 pcmC0D0c
crw-rw-rw-    1 root     root     116,  16 Jan  1 00:01 pcmC0D0p
crw-rw-rw-    1 root     root     116,   1 Jan  1 00:01 seq
crw-rw-rw-    1 root     root     116,  33 Jan  1 00:01 timer

# cat /proc/devices
Character devices:
  1 mem
  4 /dev/vc/0
  4 tty
  4 ttyS
  5 /dev/tty
  5 /dev/console
  5 /dev/ptmx
  7 vcs
 10 misc
 13 input
 14 sound
 29 fb
116 alsa
128 ptm
136 pts
254 keyboard
# cat /proc/asound/devices
  0: [ 0]   : control
 16: [ 0- 0]: digital audio playback
 24: [ 0- 0]: digital audio capture
 33:        : timer

# aplay -D /dev/snd/pcmC0D0p
ALSA lib pcm.c:2144:(snd_pcm_open_noupdate) Unknown PCM /dev/snd/pcmC0D0p

# ./test_sound.out /dev/snd/pcmC0D0p 
ALSA lib pcm.c:2090:(snd_pcm_open_noupdate) Unknown PCM /dev/snd/pcmC0D0p
cannot open audio device /dev/snd/pcmC0D0p (No such file or directory)

.............test_sound.out   is   A Minimal Playback Program  from  
http://equalarea.com/paul/alsa-audio.html


thanks for your help!

Qin Lin














Joachim F?rster wrote:
> 
> Hi qin lin,
> 
> On Sat, 2007-07-28 at 17:04 +0800, qin lin wrote:
>> I have add the driver to kernel as a module in ml403.When i insmod 
>> the module ,there are warnings followed here:
>> [  250.795594] snd-ml403_ac97cr: write access to codec register 0x26
>> with bad value 0x800f / 32783! 
>> [  250.911545] snd-ml403_ac97cr: write access to codec register 0x26
>> with bad value 0xf / 15!
>> [  251.015576] snd-ml403_ac97cr: write access to codec register 0x2a
>> with bad value 0x2801 / 10241!
>> [  251.127524] snd-ml403_ac97cr: write access to codec register 0x2a
>> with bad value 0x3801 / 14337! 
>> 
>> And i check the warring find the warnings should be from function
>> snd_ml403_ac97cr_codec_write() ?i have check the lm4550 codec
>> datasheet to make sure the mask is what you have written.
> 
> These warnings are ok. Codec register 0x26 is the "PowerDown
> Status/Control" register and the ALSA AC97 layer tries to write ones to
> the lower 4 bits (which are AFAIK read only bits). LM4550 register 0x2a
> has only one valid bit (lowest), but ALSA tries to write to a not
> existing bit. So my driver masks out these bits.
> The warnings show the invalid numbers ALSA wants to write to these
> registers.
> 
>> What  confused  me is that where call the fuction
>> snd_ml403_ac97cr_codec_write in the module_init program, would you
>> mind if you point it for me? 
> 
> Well, the function alsa_card_ml403_ac97cr_init() is registered as the
> module_init function. It registers the driver and the device to the
> kernel via platform_driver/device_register(). As a consequence the
> kernel will call the registered probe() function called
> snd_ml403_ac97cr_probe(). Among other things, the function called
> snd_ml403_ac97cr_mixer() is invoked. Finally this function registers a
> mixer device and the codec_read() and codec_write() functions with the
> ALSA AC97 layer. While registering the ALSA AC97 layer calls the read
> and write functions several times - a kind of initialization sequence.
> That's the usual structure of an ALSA driver - not that simple - I
> know :-) .
> 
>> There is another problem trouble me .I find a simple test program to
>> check  the codec playback work .But all it said that it cannot find
>> the pcm file.Would you mind if you suggest something or paste what you
>> have do to mknod the device? 
> 
> Oh, I forgot to mention that in the README file. I used the "snddevices"
> script found in ALSA's alsa-driver package (form version 1.0.13, but
> version shouldn't matter).
> 
>> # ./test_sound.out  /dev/snd/pcmC0D0
>> ALSA lib pcm.c:2090:(snd_pcm_open_noupdate) Unknown
>> PCM /dev/snd/pcmC0D0 
>> cannot open audio device /dev/snd/pcmC0D0 (No such file or directory)
> 
> Hmmm, try to create the device files with the script from above and see
> if that happens again ...
> BTW: (After having created the device files) you can also use aplay
> (alsa-utils package) for testing. Where did you find "test_sound"?
> 
>  Joachim
> 
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 

-- 
View this message in context: http://www.nabble.com/Re%3A-ml403-ac97-driver-tf4164866.html#a11858308
Sent from the linuxppc-embedded mailing list archive at Nabble.com.


From mls.JOFT at gmx.de  Mon Jul 30 17:33:35 2007
From: mls.JOFT at gmx.de (Joachim =?ISO-8859-1?Q?F=F6rster?=)
Date: Mon, 30 Jul 2007 09:33:35 +0200
Subject: ml403 ac97 driver
In-Reply-To: <11858308.post@talk.nabble.com>
References: <1185698888.6397.37.camel@localhost>
	<11858308.post@talk.nabble.com>
Message-ID: <1185780815.5454.18.camel@localhost>

Hi Qin Lin,

On Sun, 2007-07-29 at 22:40 -0700, Qin Lin wrote:
> # insmod ac97_bus.ko
> # insmod snd-ac97-codec.ko
> # insmod ml403_ac97cr.ko
> [   79.529114] ml403_ac97cr: remap controller memory region to 0xc500e000
> done
> [   79.611803] ml403_ac97cr: request (playback) irq 7 done
> [   79.674236] ml403_ac97cr: request (capture) irq 6 done
> [   79.784291] snd-ml403_ac97cr: write access to codec register 0x26 with
> bad value 0x800f / 32783!
> [   79.900247] snd-ml403_ac97cr: write access to codec register 0x26 with
> bad value 0xf / 15!
> [   80.004284] snd-ml403_ac97cr: write access to codec register 0x2a with
> bad value 0x2801 / 10241!
> [   80.116228] snd-ml403_ac97cr: write access to codec register 0x2a with
> bad value 0x3801 / 14337!

Completely fine.

> # ls -l /dev/snd
> crw-rw-rw-    1 root     root     116,   0 Jan  1 00:01 controlC0
> crw-rw-rw-    1 root     root     116,   4 Jan  1 00:01 hwC0D0
> crw-rw-rw-    1 root     root     116,   5 Jan  1 00:01 hwC0D1
> crw-rw-rw-    1 root     root     116,   6 Jan  1 00:01 hwC0D2
> crw-rw-rw-    1 root     root     116,   7 Jan  1 00:01 hwC0D3
> crw-rw-rw-    1 root     root     116,  24 Jan  1 00:01 pcmC0D0c
> crw-rw-rw-    1 root     root     116,  16 Jan  1 00:01 pcmC0D0p
> crw-rw-rw-    1 root     root     116,   1 Jan  1 00:01 seq
> crw-rw-rw-    1 root     root     116,  33 Jan  1 00:01 timer

Ok, should suffice. [In my case snddevices made many other device
files.]

> # aplay -D /dev/snd/pcmC0D0p
> ALSA lib pcm.c:2144:(snd_pcm_open_noupdate) Unknown PCM /dev/snd/pcmC0D0p

Well, I think the way you specify the device is wrong. AFAIK the -D
option only accepts names which are defined in an ALSA configuration
file (.asoundrc & friends).
Furthermore: Did you try without any device (without -D option)? The
defaults should make ALSA pick the first available sound device. At
least, while I was testing, I didn't have to specify any device.

BTW: You need to specify the (.wav) file you want to play:
# aplay music.wav
Otherwise you won't here anything ;-). Read "man aplay" !

> # ./test_sound.out /dev/snd/pcmC0D0p 
> ALSA lib pcm.c:2090:(snd_pcm_open_noupdate) Unknown PCM /dev/snd/pcmC0D0p
> cannot open audio device /dev/snd/pcmC0D0p (No such file or directory)

Ditto. But I haven't had a look into test_sound source yet, but it might
be the same issue.

 Joachim




From linkinge at gmail.com  Mon Jul 30 18:28:34 2007
From: linkinge at gmail.com (Qin Lin)
Date: Mon, 30 Jul 2007 01:28:34 -0700 (PDT)
Subject: ml403 ac97 driver
In-Reply-To: <1185780815.5454.18.camel@localhost>
References: <1185698888.6397.37.camel@localhost>
	<11858308.post@talk.nabble.com>
	<1185780815.5454.18.camel@localhost>
Message-ID: <11859770.post@talk.nabble.com>


hi Joachim

i have hearing the music . Thanks.   just use 
#aplay music.wav 

Before that i recompile the alsa-lib again. change configure options
later i will paste the whole  commands so as anybody can reference it .




Joachim F?rster wrote:
> 
> Hi Qin Lin,
> 
> On Sun, 2007-07-29 at 22:40 -0700, Qin Lin wrote:
>> # insmod ac97_bus.ko
>> # insmod snd-ac97-codec.ko
>> # insmod ml403_ac97cr.ko
>> [   79.529114] ml403_ac97cr: remap controller memory region to 0xc500e000
>> done
>> [   79.611803] ml403_ac97cr: request (playback) irq 7 done
>> [   79.674236] ml403_ac97cr: request (capture) irq 6 done
>> [   79.784291] snd-ml403_ac97cr: write access to codec register 0x26 with
>> bad value 0x800f / 32783!
>> [   79.900247] snd-ml403_ac97cr: write access to codec register 0x26 with
>> bad value 0xf / 15!
>> [   80.004284] snd-ml403_ac97cr: write access to codec register 0x2a with
>> bad value 0x2801 / 10241!
>> [   80.116228] snd-ml403_ac97cr: write access to codec register 0x2a with
>> bad value 0x3801 / 14337!
> 
> Completely fine.
> 
>> # ls -l /dev/snd
>> crw-rw-rw-    1 root     root     116,   0 Jan  1 00:01 controlC0
>> crw-rw-rw-    1 root     root     116,   4 Jan  1 00:01 hwC0D0
>> crw-rw-rw-    1 root     root     116,   5 Jan  1 00:01 hwC0D1
>> crw-rw-rw-    1 root     root     116,   6 Jan  1 00:01 hwC0D2
>> crw-rw-rw-    1 root     root     116,   7 Jan  1 00:01 hwC0D3
>> crw-rw-rw-    1 root     root     116,  24 Jan  1 00:01 pcmC0D0c
>> crw-rw-rw-    1 root     root     116,  16 Jan  1 00:01 pcmC0D0p
>> crw-rw-rw-    1 root     root     116,   1 Jan  1 00:01 seq
>> crw-rw-rw-    1 root     root     116,  33 Jan  1 00:01 timer
> 
> Ok, should suffice. [In my case snddevices made many other device
> files.]
> 
>> # aplay -D /dev/snd/pcmC0D0p
>> ALSA lib pcm.c:2144:(snd_pcm_open_noupdate) Unknown PCM /dev/snd/pcmC0D0p
> 
> Well, I think the way you specify the device is wrong. AFAIK the -D
> option only accepts names which are defined in an ALSA configuration
> file (.asoundrc & friends).
> Furthermore: Did you try without any device (without -D option)? The
> defaults should make ALSA pick the first available sound device. At
> least, while I was testing, I didn't have to specify any device.
> 
> BTW: You need to specify the (.wav) file you want to play:
> # aplay music.wav
> Otherwise you won't here anything ;-). Read "man aplay" !
> 
>> # ./test_sound.out /dev/snd/pcmC0D0p 
>> ALSA lib pcm.c:2090:(snd_pcm_open_noupdate) Unknown PCM /dev/snd/pcmC0D0p
>> cannot open audio device /dev/snd/pcmC0D0p (No such file or directory)
> 
> Ditto. But I haven't had a look into test_sound source yet, but it might
> be the same issue.
> 
>  Joachim
> 
> 
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 

-- 
View this message in context: http://www.nabble.com/Re%3A-ml403-ac97-driver-tf4164866.html#a11859770
Sent from the linuxppc-embedded mailing list archive at Nabble.com.


From ckrinke at istor.com  Tue Jul 31 02:51:44 2007
From: ckrinke at istor.com (Charles Krinke)
Date: Mon, 30 Jul 2007 09:51:44 -0700
Subject: I2C interrupts on 8541
In-Reply-To: <11816893411272-git-send-email-grant.likely@secretlab.ca>
Message-ID: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06A2A4@MERCURY.inside.istor.com>

I'm puzzled about how to setup interrupts for the second I2C interface
in an 8541. This is the CPM interface, the one with buffer descriptors.

I see mention of its I2CER/I2CMR registers, but am having trouble
figuring out how to enable and interrupt so that when the interface is
in slave mode and a packet is received, it will vector to an interrupt
service routine.

I am using Linux-2.7.17.11 and I know you-all have gone past this a bit,
but in the midst of a project, we are constrained to finish with the
kernel we started with.

A few pointers on enabling an interrupt from this interface would be
greatly appreciated.

Charles

From linkinge at gmail.com  Tue Jul 31 14:22:52 2007
From: linkinge at gmail.com (Qin Lin)
Date: Mon, 30 Jul 2007 21:22:52 -0700 (PDT)
Subject: ml403 ac97 driver
In-Reply-To: <11859770.post@talk.nabble.com>
References: <1185698888.6397.37.camel@localhost>
	<11858308.post@talk.nabble.com>
	<1185780815.5454.18.camel@localhost>
	<11859770.post@talk.nabble.com>
Message-ID: <11918008.post@talk.nabble.com>


HI ALL
I have compile the driver and test it with the help of Joachim.

1.add the lm4550 driver to kernel source
(someboby may can add them as a patch to kernel source)

#cp -r ml403_ac97cr $(KERNEL)/sound/drivers/
#vi $(KERNEL)/sound/drivers/Makefile
=add=
obj-$(CONFIG_SND_ML403_AC97)	+=ml403_ac97cr/
#vi $(KERNEL)/sound/drivers/
=add=
config SND_ML403_AC97
        tristate "ml403 ac97 codec(LM4550)"
        depends on SND
        select SND_AC97_CODEC
        help
          ml403 ac97 codec added by Joachim
          enjoy it !

#vi $(KERNEL)/sound/drivers/ml403_ac97cr/Makefile
obj-$(CONFIG_SND_ML403_AC97) += ml403_ac97cr.o

#make xconfig 
you can see the ml403_ac97cr in SOUND ALSA 

2.cross-compile alsa-lib
I use ELDK4.0 to install cross compile in XILINX ML403.
$echo $CROSS_COMPILE
 ppc_4xx-
$export CC=${CROSS_COMPILE}gcc
$export CPP=${CROSS_COMPILE}cpp
$export CXX=${CROSS_COMPILE}g++
$export LDD=${CROSS_COMPILE}ldd
$export AR=${CROSS_COMPILE}ar
$export LD=${CROSS_COMPILE}ld
$export RANLIB=${CROSS_COMPILE}ranlib
$export STRIP=${CROSS_COMPILE}strip
$cd ${ALSA-LIB-SOURCE}
$./configure --host=ppc-4xx-linux --target=ppc  --prefix=/usr
$make install  DESTDIR=${ALSA}

ps:ALSA lib will be install in path ${ALSA}/usr.Here use prefix=/usr is
important,do not change to another 
path. Otherwise in the target board alsa will not find the config file by
default.You can use DESTDIR to set the lib path .

3.cross-compile alsa-utils
$export CC=${CROSS_COMPILE}gcc
$export CPP=${CROSS_COMPILE}cpp
$export CXX=${CROSS_COMPILE}g++
$export LDD=${CROSS_COMPILE}ldd
$export AR=${CROSS_COMPILE}ar
$export LD=${CROSS_COMPILE}ld
$export RANLIB=${CROSS_COMPILE}ranlib
$export STRIP=${CROSS_COMPILE}strip
$export CFLAGS="-I${ALSA}/usr/include  -L${ALSA}/usr/lib"

$cd ${ALSA-UTILS-SOURCE}
$./configure --host=ppc-4xx-linux --target=ppc  --prefix=/usr --disable-nls 
$make install  DESTDIR=${ALSA}

ps:use --disable-nls,otherwise there is an error about LC_ALL not defined.

3.copy the ${ALSA}/usr/* to the target rootfile /usr/  ,so you can use the
alsa utils.

4.insmod the drive module and create device node ,use 
#aplay music.wav
to test the drive.
-- 
View this message in context: http://www.nabble.com/Re%3A-ml403-ac97-driver-tf4164866.html#a11918008
Sent from the linuxppc-embedded mailing list archive at Nabble.com.


From ma.harounansari at gdatech.co.in  Tue Jul 31 17:10:07 2007
From: ma.harounansari at gdatech.co.in (Ansari)
Date: Tue, 31 Jul 2007 12:40:07 +0530
Subject: Reboot Command Makes kernel to hang (MPC8560)
References: <000801c7cf51$f98ebb90$9503a8c0@Ansari>
	<880B302A-742A-4CC1-BB41-E7BD1CE570C6@kernel.crashing.org>
Message-ID: <007001c7d341$d3ae29d0$9503a8c0@Ansari>

Hi Kumar,

First of all thanks for ur reply .

Even i went through the linux source . And i have observe that the reboot 
command used to hard reset the core . I have few doubts can u please clarify 
me.

1. Is there any way to reset the full chip with out using any external 
signal (MPC8560) ? (like any register that can be used for reseting the 
processor)
2. Even same reboot command works fine for MPC8540 Processor ?.
3. what are the factors that makes ramdisk hangs . When its uncompressing ?

Regards
Haroun Ansari


----- Original Message ----- 
From: "Kumar Gala" <galak at kernel.crashing.org>
To: "Ansari" <ma.harounansari at gdatech.co.in>
Cc: <linuxppc-embedded at ozlabs.org>
Sent: Friday, July 27, 2007 1:21 AM
Subject: Re: Reboot Command Makes kernel to hang (MPC8560)


>
> On Jul 26, 2007, at 1:55 AM, Ansari wrote:
>
>> Hi all,
>>
>> Processor (MPC8560)
>>
>> Whenever reboot command is given in the linux console. The  processor 
>> gets reset and it loads bootloader , kernel and when  uncompressing the 
>> ramdisk it gets hang. The sample log is given  below. Any u please tell 
>> me what are the factors that can makes  this to happen.
>
> This is very board dependant.  The MPC8560 doesn't have a clean way  to 
> request reset, and odds are you're only getting the core reset and  not 
> the full chip.
>
> - k
> 

From mls.JOFT at gmx.de  Tue Jul 31 17:50:40 2007
From: mls.JOFT at gmx.de (Joachim =?ISO-8859-1?Q?F=F6rster?=)
Date: Tue, 31 Jul 2007 09:50:40 +0200
Subject: ml403 ac97 driver
In-Reply-To: <11918008.post@talk.nabble.com>
References: <1185698888.6397.37.camel@localhost>
	<11858308.post@talk.nabble.com> <1185780815.5454.18.camel@localhost>
	<11859770.post@talk.nabble.com>  <11918008.post@talk.nabble.com>
Message-ID: <1185868239.5527.9.camel@localhost>

Hi Qin Lin,

On Mon, 2007-07-30 at 21:22 -0700, Qin Lin wrote:
> 1.add the lm4550 driver to kernel source
> (someboby may can add them as a patch to kernel source)

In fact, in the last few days, I worked on my driver, made changes
according to Grant Likely's list of comments (see the thread where I
announced the driver). And right now, I'm preparing a patch against the
official kernel tree. So, I'll post a patch soon myself - just view more
days.

 Joachim




From yoni.l at slyde-tech.com  Tue Jul 31 17:53:17 2007
From: yoni.l at slyde-tech.com (Yoni Levin)
Date: Tue, 31 Jul 2007 10:53:17 +0300
Subject: interrupts in mpc8313
Message-ID: <1A95C6D899744E16A71AFFB2CF1C11B1.MAI@mail.livedns.co.il>

Hi, I am working on the MPC8313E board , 

 

I work with the DMA that works fine, but I want to get the interrupt when it
finish.

 

I am working under linux 2.6.20

 

I tried to use the function request_irq :

 

Ret=Request_irq(71,interrupt_handler,SA_INTERUPT,"dma_irq",NULL);

 

But I receive an error -ENOSYS

 

Do I need to do something before call the Request_irq?

 

You know what is wrong?

 

Thank you for your help, 

 

Yehonatan.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070731/5389b6c4/attachment.htm 

From clemens.koller at anagramm.de  Tue Jul 31 21:44:05 2007
From: clemens.koller at anagramm.de (Clemens Koller)
Date: Tue, 31 Jul 2007 13:44:05 +0200
Subject: Reboot Command Makes kernel to hang (MPC8560)
In-Reply-To: <007001c7d341$d3ae29d0$9503a8c0@Ansari>
References: <000801c7cf51$f98ebb90$9503a8c0@Ansari>	<880B302A-742A-4CC1-BB41-E7BD1CE570C6@kernel.crashing.org>
	<007001c7d341$d3ae29d0$9503a8c0@Ansari>
Message-ID: <46AF2085.1060603@anagramm.de>

Hi, Ansari!

Ansari schrieb:
> Hi Kumar,
> 
> First of all thanks for ur reply .
> 
> Even i went through the linux source . And i have observe that the reboot 
> command used to hard reset the core . I have few doubts can u please clarify 
> me.
> 
> 1. Is there any way to reset the full chip with out using any external 
> signal (MPC8560) ? (like any register that can be used for reseting the 
> processor)

I RTFM:
It should be the bits RST[1:0] in the Debug Control Register 0 (DBCR0).

I didn't find details how the external signals are affected: HRESET_REQ# and friends.
The HRESET_REQ# is usually fed back to the CPU's HRESET#.
So if the HRESET_REQ# gets asserted by writing to above registers it should really bring
down the CPU, it's internal as well as it's external components, which are usually
connected to a replication of that signal.

However the existence of cpm2_reset() and a qe_reset() (QuiccEngine?)
in the code tells me that the above expectations could be wrong.

Would be nice to have that verified by some hardware guys from freescale...

> 2. Even same reboot command works fine for MPC8540 Processor ?.

...because it doesn't have a cpm ?

> 3. what are the factors that makes ramdisk hangs . When its uncompressing ?

Well, side effects ?

Regards,
-- 
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Stra?e 45/1
Linhof Werksgel?nde
D-81379 M?nchen
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com

From linkinge at gmail.com  Tue Jul 31 21:49:07 2007
From: linkinge at gmail.com (Qin Lin)
Date: Tue, 31 Jul 2007 04:49:07 -0700 (PDT)
Subject: BUG-REPORT Re: ml403 ac97 driver
In-Reply-To: <1185698888.6397.37.camel@localhost>
References: <1185698888.6397.37.camel@localhost>
Message-ID: <11922613.post@talk.nabble.com>


HI Joachim


When i used the aplay to test the drive first time,it played well. But 
after restart the board 
it is not well again.

Qin Lin

# aplay yonggan.wav
Playing WAVE 'yonggan.wav' : Signed 16 bit Little Endian, Rate 44100 Hz,
Stereo
[  258.518119] Kernel stack overflow in process c039ec00, r1=c3e0bf50

#strace  aplay yonggan.wav
......................
stat64("/usr/share/alsa/alsa.conf", {st_mode=S_IFREG|0644, st_size=7701,
...}) = 0
open("/dev/snd/controlC0", O_RDONLY)    = 3
close(3)                                = 0
open("/dev/snd/controlC0", O_RDWR)      = 3
ioctl(3, USBDEVFS_CONTROL, 0x7f9a25b8)  = 0
ioctl(3, 0x41785501, 0x7f9a2560)        = 0
close(3)                                = 0
open("/dev/snd/controlC0", O_RDONLY)    = 3
close(3)                                = 0
open("/dev/snd/controlC0", O_RDWR)      = 3
ioctl(3, USBDEVFS_CONTROL, 0x7f9a2808)  = 0
ioctl(3, 0x80045532, 0x7f9a2838)        = 0
open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK) = 4
close(3)                                = 0
ioctl(4, AGPIOC_ACQUIRE or APM_IOC_STANDBY, 0x7f9a2718) = 0
fcntl64(4, F_GETFL)                     = 0x802 (flags O_RDWR|O_NONBLOCK)
ioctl(4, AGPIOC_INFO, 0x7f9a2688)       = 0
ioctl(4, AGPIOC_RELEASE or APM_IOC_SUSPEND, 0x7f9a2690) = 0
mmap(NULL, 4096, PROT_READ, MAP_SHARED, 4, 0x80000000) = 0x30018000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0x81000000) =
0x30019000
fcntl64(4, F_GETFL)                     = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(4, F_SETFL, O_RDWR)             = 0
ioctl(4, AGPIOC_ACQUIRE or APM_IOC_STANDBY, 0x7f9a2c60) = 0
rt_sigaction(SIGINT, {0xfdabf30, [INT], SA_RESTART}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGTERM, {0xfdabf30, [TERM], SA_RESTART}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGABRT, {0xfdabf30, [ABRT], SA_RESTART}, {SIG_DFL}, 8) = 0
open("yonggan.wav", O_RDONLY|O_LARGEFILE) = 3
read(3, "RIFF$VR\0WAVEfmt \20\0\0\0\1\0\2\0", 24) = 24
read(3, "D\254", 2)                     = 2
read(3, "\0\0\20\261\2\0\4\0\20\0", 10) = 10
read(3, "data\\TR\0", 8)                = 8
write(2, "Playing WAVE \'yonggan.wav\' : ", 29Playing WAVE 'yonggan.wav' : )
= 29
write(2, "Signed 16 bit Little Endian, ", 29Signed 16 bit Little Endian, ) =
29
write(2, "Rate 44100 Hz, ", 15Rate 44100 Hz, )         = 15
write(2, "Stereo", 6Stereo)                   = 6
write(2, "\n", 1
)                       = 1
ioctl(4, 0xc25c4110, 0x7f9a2518)        = 0
ioctl(4, 0xc25c4110, 0x7f9a21b0)        = 0
ioctl(4, 0xc25c4110, 0x7f9a21b0)        = 0
ioctl(4, 0xc25c4110, 0x7f9a2518)        = 0
ioctl(4, 0xc25c4110, 0x7f9a21b0)        = 0
ioctl(4, 0xc25c4110, 0x7f9a21b0)        = 0
ioctl(4, 0xc25c4110, 0x7f9a2518)        = 0
ioctl(4, 0xc25c4110, 0x7f9a2298)        = 0
ioctl(4, 0xc25c4110, 0x7f9a1f30)        = 0
ioctl(4, 0xc25c4110, 0x7f9a1f30)        = 0
ioctl(4, 0xc25c4110, 0x7f9a2298)        = 0
ioctl(4, 0xc25c4110, 0x7f9a2298[  213.220781] Kernel stack overflow in
process c039c030, r1=c0395f50


-- 
View this message in context: http://www.nabble.com/Re%3A-ml403-ac97-driver-tf4164866.html#a11922613
Sent from the linuxppc-embedded mailing list archive at Nabble.com.


From scottwood at freescale.com  Tue Jul 31 23:35:24 2007
From: scottwood at freescale.com (Scott Wood)
Date: Tue, 31 Jul 2007 08:35:24 -0500
Subject: interrupts in mpc8313
In-Reply-To: <1A95C6D899744E16A71AFFB2CF1C11B1.MAI@mail.livedns.co.il>
References: <1A95C6D899744E16A71AFFB2CF1C11B1.MAI@mail.livedns.co.il>
Message-ID: <46AF3A9C.4090007@freescale.com>

Yoni Levin wrote:
> I tried to use the function request_irq :
> 
>  
> 
> Ret=Request_irq(71,interrupt_handler,SA_INTERUPT,"dma_irq",NULL);

arch/ppc or arch/powerpc?

If the latter, you need to translate the hardware IRQ into a virtual 
IRQ.  The easiest way to do this is to put the DMA node into the device 
tree and use of_irq_to_resource().

Plus, this obviously isn't the exact code you're running, as the 
spelling and capitalization errors would keep it from compiling.

-Scott

From yoni.l at slyde-tech.com  Tue Jul 31 23:53:20 2007
From: yoni.l at slyde-tech.com (Yoni Levin)
Date: Tue, 31 Jul 2007 16:53:20 +0300
Subject: interrupts in mpc8313
In-Reply-To: <46AF3A9C.4090007@freescale.com>
Message-ID: <DD658DAB65814DF6A223A007EC5735FE.MAI@mail.livedns.co.il>

All I had to do was to add :
irq_create_mapping(NULL,71)
and yes it not the exact code , I work with 2 computers...
thanks.


-----Original Message-----
From: Scott Wood [mailto:scottwood at freescale.com] 
Sent: Tuesday, July 31, 2007 4:35 PM
To: Yoni Levin
Cc: linuxppc-embedded at ozlabs.org
Subject: Re: interrupts in mpc8313

Yoni Levin wrote:
> I tried to use the function request_irq :
> 
>  
> 
> Ret=Request_irq(71,interrupt_handler,SA_INTERUPT,"dma_irq",NULL);

arch/ppc or arch/powerpc?

If the latter, you need to translate the hardware IRQ into a virtual 
IRQ.  The easiest way to do this is to put the DMA node into the device 
tree and use of_irq_to_resource().

Plus, this obviously isn't the exact code you're running, as the 
spelling and capitalization errors would keep it from compiling.

-Scott






From bogus@does.not.exist.com  Mon Jul 23 18:04:32 2007
From: bogus@does.not.exist.com ()
Date: Mon, 23 Jul 2007 08:04:32 -0000
Subject: No subject
Message-ID: <mailman.3.1186035114.2003.linuxppc-embedded@ozlabs.org>

38  * IRQF_DISABLED - keep irqs disabled when calling the action handler


>> irq_create_mapping(NULL,74);
>> request_irq(74,handler,IRQF_DISABLED,"GPIO",NULL);

Request irq should use virq that irq_create_mapping returns.

Maybe there's another "enable global GPIO interrupts" register, that
needs to be set too?


	Domen

From bogus@does.not.exist.com  Mon Jul 23 18:04:32 2007
From: bogus@does.not.exist.com ()
Date: Mon, 23 Jul 2007 08:04:32 -0000
Subject: No subject
Message-ID: <mailman.6.1186994025.2003.linuxppc-embedded@ozlabs.org>

msleep(), like what you mentioned, to release its executing. Instead, it 
uses schedule() to do that. 


>- wake_up
>   Just wake_up isn't enough, you get a race:
>   |   interrupt handler   |   process      |
>   ------------------------------------------
>   |   do_something()      |                |
>   |   wake_up()           |                |
>   |   ...                 |   wait on wq   |
>
>   And so you have a process waiting on waitqueue, that just missed the
>   wakeup. Obviously should not be used.
>
>- wake_up & condition
>   |   interrupt handler   |   process      |
>   ------------------------------------------
>   |   flag = 1            |                |
>   |   wake_up()           |                |
>   |   ...                 |   wait_event   |
>   |   ...                 |   flag = 0     |
>
>   This will work properly and if wait_event misses a wake_up, the
>   condition check (flag)  will kick in before putting it to sleep.
>

Thanks for your explaining on the race problem. I can understand this now. 
However I still cannot understand, is such a problem: In the above figures 
for my case, if flag=1 could wake the process up, then what's the use of 
wake_up()? From my understanding if the condition turns true, then the 
process which depends on this condition will be waken up. Thus what's the 
exact use of wake_up()? Also in my program, I tried to remove wake_up() 
sentence and it seems that there is no difference on the result.

Thanks for the explanation.

BR
Ming

_________________________________________________________________
???????????????????????????? MSN Messenger:  http://messenger.msn.com/cn