some questions about FEC?

[Liu HongXun-a16975]

Hi, all,
I am trying to support FEC on my ppc 857 based custom board.
I have some questions on the current fec.c code.
1. what is usage of the define " CONFIG_FEC_PACKETHOOK" ?
Is it used to hook the packet before it is processed for info gathering 
purpose?
Can I just discard it ?
2. My PHY doesn't support MII . So I need not pay attention to the 
"CONFIG_USE_MDIO" ?
Any other suggestions on running FEC are really appreciated.

Thanks a lot
Rolf Liu


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

8xx SPI drivers

[Dan Malek]

Navin Boppuri wrote:

> I have no website of my own to put this stuff on yet.

Just ask to post it on penguinppc.org.  There is an embedded section
there.but why do you want to post something like this?  I mean,
we don't post any of the other drivers or code we do anywhere but in
the sources themselves.

> Also, I would like to thank Alex for cleaning up my driver and for
> actually using it.

Keep in mind that SPI designs are very dependent upon the board/product
design.  Many of the systems that use SPI have external hardware for
device selection and control.  The generic driver is suitable for clocking
bits in/out but often isn't sufficient to make everything work.  Due to the
timing of SPISEL, I sometimes had to just write a software bit-toggle function
to make it work.

Thanks.


-- Dan


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

AW: MPC755 Porting Problem

[Babic Stefano]

Hi,

we have already ported linux on our board based on MPC 755. The kernel is set 
at 0xc000, as you can see on arch/ppc/Makefile (KERNELLOAD=0xc000). We 
did not want to change it, because it is quite a standard value for external 
tools.
We are using the boot loader in mbx directory (or mbxboot, depending on version 
you are using), so we are using really the head_8260.S file instead of head.S.
>From the sources of the loader it seems necessary to load the kernel in high 
>memory range (physical address), in any case greater as 0x40 (which 
>address is not important). Then the loader remapped it to 0xc000.
For us it is not a problem to load the kernel at a higher address and in this 
way the loader can correctly start the kernel.

I hope it could be help.

stefano babic

-Ursprungliche Nachricht-
Von: Sangmoon Kim [mailto:dogoil at etinsys.com]
Gesendet: Samstag, 15. Dezember 2001 07:24
An: linuxppc-embedded at lists.linuxppc.org
Betreff: MPC755 Porting Problem



Hi?
I'm porting linux for a MPC755 board which I designed,
and having some trouble with arch/ppc/kernel/head.S
I load the kernel at phiscal address 0x
and head.S seams to relocate it to 0xc000
The code is like this

mfmsr   r0 /* Inst and data addr translations are disabled */
ori r0,r0,MSR_DR|MSR_IR /* enable Inst and data addr translation */
mtspr   SRR1,r0
lis r0,start_here at h
ori r0,r0,start_here at l
mtspr   SRR0,r0
SYNC
RFI /* jump to SRR0 */

start_here:
/* Call setup_cpu for CPU 0 */
li  r3,0/* data offset */
li  r24,0   /* cpu# */
bl  call_setup_cpu

It is running at base address 0x.
start_here is at address 0xc000369c.
And the IBAT0, and DBAT0 is C0001FFE-0002.
So after RFI it should go to start_here.

But If I insert some code like 'bl serial_hello',
which prints hello? to serial console after start_here.
It never prints a message. It works before the RFI.

Where can I start to debug it?

serial_hello is like this.

void
serial_hello()
{
serial_putc(SCC_A_ADDRESS,'h');
serial_putc(SCC_A_ADDRESS,'e');
serial_putc(SCC_A_ADDRESS,'l');
serial_putc(SCC_A_ADDRESS,'l');
serial_putc(SCC_A_ADDRESS,'o');
serial_putc(SCC_A_ADDRESS,'?');
serial_putc(SCC_A_ADDRESS,'\n');
serial_putc(SCC_A_ADDRESS,'\r');
}
Thanks in advance.
- Sangmoon Kim -


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

PPC bootloader cache enabling

[Mark A. Greer]

Tom,

In the bootloader, we enable the L1 instruction cache and disable the L1
data cache.  If I understood the manuals correctly:

On a 750 (according to user's manual):
- The cache is unified so even though you have the L1 data cache
disabled, if you have L2 on, data will get cached there.

On a 7400/7410 (according to user's manuals):
- Last sentence in the first paragraph of section 3.7.3.1 states, "if
the L1 data cache is disabled, the L2 cache must also be disabled."

In _setup_L2CR, the L2 cache is invalidated but its then enabled at the
end.  Am I missing something or is this a bug in _setup_L2CR?  If its a
bug, maybe we should rename it to invalidate_disable_l2 or something
like that?

Mark


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

8xx SPI drivers

[Navin Boppuri]

I have no website of my own to put this stuff on yet. I will do so
shortly and I'll let you all know. Meanwhile, I am hoping Alex could do
this.

Also, I would like to thank Alex for cleaning up my driver and for
actually using it.

Navin.

-Original Message-
From: Kevin Fry [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 18, 2001 1:39 PM
To: Navin Boppuri
Cc: linuxppc-embedded at lists.linuxppc.org
Subject: Re:8xx SPI drivers


Thanks for the SPI driver help,  I've started porting Alex's code (based
off
Navin's) to the 8260.
 Would either of you mind if I made a quick SPI webpage and posted your
drivers there? To help those in the future who will have this problem
and
need to find spi stuff not in the kernel.

The people on this list rock!

Kevin


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

PCI QSPAN2 resource conflicts

[Jeff Studer]

I downloaded lspci and ran it on my embedded system,
here is the results:

# lspci -vv
00:03.0 Class : 16b2:5100 (prog-if 02)
Control: I/O- Mem- BusMaster- SpecCycle-
MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr-
DEVSEL=fast >TAbort- SERR-  [disabled]
[size=65]
Region 1: I/O ports at  [disabled]
[size=129]

00:04.0 Class 0200: 10b7:9055 (rev 30)
Subsystem: 10b7:9055
Control: I/O+ Mem+ BusMaster+ SpecCycle-
MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr-
DEVSEL=medium >TAbort- SERR-  [disabled]
[size=128K]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+
AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot
+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0
PME-

# lspci -xxx
00:03.0 Class : 16b2:5100
00: b2 16 00 51 00 00 00 00 00 02 00 00 00 40 00 00
10: 41 ff ff f5 81 ff ff f5 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 06 01 0a 0a
40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

00:04.0 Class 0200: 10b7:9055 (rev 30)
00: b7 10 55 90 07 00 10 02 30 00 00 02 00 00 00 00
10: 01 00 00 f4 80 ff ff f5 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 b7 10 55 90
30: 00 00 00 00 dc 00 00 00 00 00 00 00 08 01 0a 0a
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 01 00 01 76
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

The arch/ppc/kernel/qspan_pci.c file doesn't have a
debug macro, and its basically totally rewritten anyway,
so I can't provide any information that way.  I'll gladly
add any printks for various pieces of data in whatever
functions needed to provide any information that would
help.

The backplane has 2 PCI slots. In the first slot is our
PCI card, in the 2nd slot is the 3c905B-TXNM 3COM
card.  If I can provide any more information that could
help, please let me know.


Peter Desnoyers wrote:

> Two pieces of information that would be useful for anyone to debug this:
>
> 1. lspci -vv and lspci -xx output
> 2. console output of boot with DEBUG turned on in the qspan file.  (not
> the bootloader one, but kernel/qspan_pci.c or whatever)
>
> Send them to the list and a few of us might have some ideas.
>
> If all else fails, do what I did - call the Tundra people for help.
> (although in my case it was a hardware issue. They were pretty helpful,
> though.)
>
> Jeff Studer wrote:
> >
> > I am working with a linux 2.4.2 kernel in an MPC860 custom board using a
> > Tundra QSPAN2 PCI controller.  I have set up configuration space and can
> > successfully probe for PCI cards. When I load PCI drivers, I get into
> > trouble.
> >
> > When I insmod the 3c59x.o module, I can access I/O space, but my MAC
> > address is read as 00:00:00:00:00:00.  I can't find manuals for this
> > card to verify what is going wrong, but I can see data in the I/O space
> > when I use our ADS board and the mpc8bug program.
> >
> > When I load another driver specific to this project, therefore the need
> > for PCI at all, I get resource conflicts.  The 3c59x.o driver actually
> > uses the value I set bus->resource->start to,  whereas the other PCI
> > driver uses 0.
> >
> > I've tried various setups for the resource.  I have set
> > bus->resource->start to the address in the QSPAN2's Slave0 address
> > setting. And I also tried do this and using the arch/ppc/mbxboot/pci.c's
> > functions: probe_addresses and map_pci_addrs.
> >
> > I really wish there was a detailed HOWTO for all this, but in the
> > meantime, does anyone have any idea what are the proper steps to
> > complete this PCI support and/or what I may be doing wrong?

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

ATM driver for 8260 (linux 2.4.x) + more questions

[Alex Zeffertt]

None Atall wrote:
>
>  By the way, as I can see from mpc860sar code, the
> ATM device is connected on SCCx via utopia. Our board
> (MPC8260ADS and our custom one) have the ATM connected
> on FCC1. Will I need too many changes after the patch?
> Can anyone evaluate the changes that i will need?
> We are running out of time, so I wonder...
>
>   Thanks a lot!
>   D.Meidanis
>


As I understand it there is no FCC1 on the 860.  This is something you get with 
the 8260 only.  With
the 860 you need to use the utopia interface.

I wrote the code for the 860 so there is no support for FCC ATM.  You'll have 
to read the 8260 UM to
work out how much there is to do.

Alex

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

SPI driver?

[Rod Boyce]

Have you tried looking in the /arch/ppc/8xx_io directory there
is a file there called spi.c This believe it or not is a SPI driver in a
limited form for the 8XX powerpc cpu.  The kernel I'm using is 2.2.14 from
ftp://ftp.denx.de   this is a very good kernel I suggest
you look it over at least once.


Rod

-Original Message-
From:   Kevin Fry [mailto:kevin at carts.com]
Sent:   Tuesday, 18 December 2001 13:49
To: linuxppc-embedded at lists.linuxppc.org
Subject:SPI driver?


Is there an MPC8260 SPI driver out there for Linux?  It
wouldn't be
terribly hard to write one on my own, but why re-invent the
wheel?

A link to an 8xx driver would be almost as good. The only
one I've found
so far has been SPI over a PC's parallel port. heh

Thanks

Kevin Fry


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

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

PCI QSPAN2 resource conflicts

[Jeff Studer]

Hello list,

I am working with a linux 2.4.2 kernel in an MPC860 custom board using a
Tundra QSPAN2 PCI controller.  I have set up configuration space and can
successfully probe for PCI cards. When I load PCI drivers, I get into
trouble.

When I insmod the 3c59x.o module, I can access I/O space, but my MAC
address is read as 00:00:00:00:00:00.  I can't find manuals for this
card to verify what is going wrong, but I can see data in the I/O space
when I use our ADS board and the mpc8bug program.

When I load another driver specific to this project, therefore the need
for PCI at all, I get resource conflicts.  The 3c59x.o driver actually
uses the value I set bus->resource->start to,  whereas the other PCI
driver uses 0.

I've tried various setups for the resource.  I have set
bus->resource->start to the address in the QSPAN2's Slave0 address
setting. And I also tried do this and using the arch/ppc/mbxboot/pci.c's
functions: probe_addresses and map_pci_addrs.

I really wish there was a detailed HOWTO for all this, but in the
meantime, does anyone have any idea what are the proper steps to
complete this PCI support and/or what I may be doing wrong?

Thank you,

Jeff Studer
Software Engineer
Aquila Technologies Group

jstuder at aquilagroup.com
ph:  505-828-9100
fax: 505-828-9115


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

8xx SPI drivers

[Kevin Fry]

Thanks for the SPI driver help,  I've started porting Alex's code (based off
Navin's) to the 8260.
 Would either of you mind if I made a quick SPI webpage and posted your
drivers there? To help those in the future who will have this problem and
need to find spi stuff not in the kernel.

The people on this list rock!

Kevin


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

SPI driver?

[Alex Zeffertt]

Alex Zeffertt wrote:
>
> >
> > A link to an 8xx driver would be almost as good. The only one I've found
> > so far has been SPI over a PC's parallel port. heh
>

Kevin,

Sorry, I forgot to add that you need to make the following mods to 
arch/ppc/8xx_io/commproc.h

Alex

diff -u linux-2.4.4-2001-11-24/arch/ppc/8xx_io/commproc.h
linux-2.4.4-2001-11-24.new/arch/ppc/8xx_io/commproc.h
--- linux-2.4.4-2001-11-24/arch/ppc/8xx_io/commproc.h   Mon Sep 10 16:29:33
2001   +++
linux-2.4.4-2001-11-24.new/arch/ppc/8xx_io/commproc.h   Fri Dec  7 11:54:58 
2001
@@ -37,6 +37,7 @@
 #define CPM_CR_RESTART_TX  ((ushort)0x0006)
 #define CPM_CR_SET_GADDR   ((ushort)0x0008)
 #define CPM_CR_SET_TIMER   CPM_CR_SET_GADDR
+#define CPM_CR_CLOSE_RX_BD  ((ushort)0x0007)

 /* Channel numbers.
 */
@@ -93,7 +94,9 @@
 #define BD_SC_PR   ((ushort)0x0008)/* Parity error */
 #define BD_SC_NAK  ((ushort)0x0004)/* NAK - did not respond */
 #define BD_SC_OV   ((ushort)0x0002)/* Overrun */
+#define BD_SC_UN((ushort)0x0002)/* Underrun */
 #define BD_SC_CD   ((ushort)0x0001)/* ?? */
+#define BD_SC_CL((ushort)0x0001)/* Collision */

 /* Parameter RAM offsets.
 */
@@ -704,7 +707,11 @@
 #define SICR_ENET_MASK ((uint)0xff00)
 #define SICR_ENET_CLKRT((uint)0x3E00)

-#undef USE_IIC_PATCH   /* We need the I?C ?Code Patch 
*/
+#ifdef CONFIG_UCODE_PATCH
+#  define USE_IIC_PATCH
+#else
+#  undef  USE_IIC_PATCH/* We need the I?C 
?Code Patch */
+#endif

 #endif /* CONFIG_LWMON */

@@ -962,6 +969,16 @@
 #define SPMODE_EN  ((ushort)0x0100)/* Enable */
 #define SPMODE_LENMSK  ((ushort)0x00f0)/* character length */
 #define SPMODE_PMMSK   ((ushort)0x000f)/* prescale modulus */
+#define SPMODE_MASTER  ((ushort)0x0200) /* Am SPI master */
+#define SPMODE_LEN_SHIFT 4  /* shift of character length field 
*/
+#define SPMODE_PM_SHIFT  0  /* shift of Prescale Modulus field 
*/
+
+/* SPIE fields */
+#define SPIE_MME  0x20
+#define SPIE_TXE  0x10
+#define SPIE_BSY  0x04
+#define SPIE_TXB  0x02
+#define SPIE_RXB  0x01

 /* CPM interrupts.  There are nearly 32 interrupts generated by CPM
  * channels or devices.  All of these are presented to the PPC core

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

A dirty 8xx SPI driver.

[Navin Boppuri]

Hello Kevin,

I am sending you a simple spi driver for the 8xx machine that I
developed a long time back. Please dont send hate mails to me cause the
this was a driver that I wrote to just get something done fast. There
are no proper defines for anything. There is a small HOWTO for this
driver that I beleive will help you get going. Please note that this
driver was a kernel level driver used with the 2.2.14 kernel. But with a
little tweaking, you should be able to make it make it work for the new
kernel. Also, make it a loadable kernel module if you are interested. 

Anyone and everyone is free to clean up the crappy code in the driver
and put in nice defines to make the code readable. You may also put in
IOCTL's for all the configuration options for the SPI controller.  

I have been busy with other things and have not had the time to clean up
this driver. Please note that this driver was my first Linux device
driver, so please be forgiving.

At the end, if you beleive that it is easier to write a driver from
scratch, get rid of it. But I beleive that this peice of code will
surely be helpful for someone trying to get things going with the SPI.
Have fun. :):) 

Navin.

P.S ( This driver was written to interface the SPI to an UART. Ignore
all the UART specific defines).



-Original Message-
From: Kevin Fry [mailto:[EMAIL PROTECTED]
Sent: Monday, December 17, 2001 6:49 PM
To: linuxppc-embedded at lists.linuxppc.org
Subject: SPI driver?



Is there an MPC8260 SPI driver out there for Linux?  It wouldn't be
terribly hard to write one on my own, but why re-invent the wheel?

A link to an 8xx driver would be almost as good. The only one I've found
so far has been SPI over a PC's parallel port. heh

Thanks

Kevin Fry



-- next part --
A non-text attachment was scrubbed...
Name: spi.c
Type: application/octet-stream
Size: 12300 bytes
Desc: spi.c
Url : 
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20011218/5d6657ae/attachment.obj
 
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: spinotes.txt
Url: 
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20011218/5d6657ae/attachment.txt
 

SPI driver?

[Alex Zeffertt]

>
> A link to an 8xx driver would be almost as good. The only one I've found
> so far has been SPI over a PC's parallel port. heh

Kevin,

Here's one (below) for the 860.  You'll probably need to change the GPIO pin 
used to select the SPI
slave.  You may also want get rid of the semaphore ioctl call.  I put this in 
as a way to allow
processes to do a sequence of reads/writes atomically.  However, it also allows 
one process to
permanently lock out all others :-(

Alex

/*
   MPC8xx CPM SPI interface.
   Copyright (c) 2001 Navin Boppuri/Prashant Patel
   (nboppuri at trinetcommunication.com/pmpatel at trinetcommunication.com)
   This interface requires the microcode patches.
   Helper functions for memdump put in by Ralph Nichols (ralphn at 
trinetcommunication.com)

   Alex Zeffertt 06Sep01
   Notes:

   0.

   This code drives the MPC860 SPI as a master device.

   1.

   The Chip selects are controlled by the ioctl interface.
   This is necessary because some SPI devices lose state
   information when the CS is unasserted.
   For example, with an SPI EEPROM (e.g. AT25010) you may
   have to assert the CS, send a READ command, receive
   some data, and then unassert the CS.  The corresponding
   user commands are:

   ioctl(s, SPI_IOCTL_RESET, 1);   // 3rd argument selects port A pin 1
   write(s, readcmdstring, sizeof(readcmdstring));
   read(s, buffer, sizeof(buffer);
   ioctl(s, SPI_IOCTL_SET, 1); // 3rd argument selects port A pin 1

   For such a device we cannot assert the CS at the start of
   write/read and unassert it at the end of write/read, because
   it would forget what command it was processing.

   Since all devices will differ in this respect we have left
   the decision of when to assert the CS to the user.

   2.

   Several processes may have this device open at a time.  However,
   this may result in one process interferring with the other
   process.  To prevent this we have introduced a semaphore:

   // To gain semaphore
   ioctl(s, SPI_IOCTL_SEMAPHORE_DOWN, 0); // 3rd argument is unused

   ... do reads and writes and non-semaphore ioctls

   // To release semaphore
   ioctl(s, SPI_IOCTL_SEMAPHORE_UP, 0);   // 3rd argument is unused

   If every process uses these two ioctls before and after any device
   operations, then every device operation will be atomic.

   3.

   This driver protects against simultaneous calls to read/write
   by the use of wait queues.

   4.

   This driver uses interrupts to indicate when the TX buffer is sent
   or the RX buffer is full.

*/

/*### Includes ###*/

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include "commproc.h"

/*### Defines/typedefs */
//#define DEBUG
#ifdef DEBUG
#define DPRINTK(format,args...) printk(format,##args)
#else
#define DPRINTK(format,args...)
#endif


/* This is the SPI device number, but I use the minors to indicate
 * the SPI device address.
 */
#define CPM_SPI_CDEV_MAJOR 89
#define SPI_BUFFER_SIZE 64

typedef int SPI_IOCTL_FN(uint cmd, ulong arg);

typedef struct _spi_ioctl_cmds
{
char *name;
SPI_IOCTL_FN *fn;
} SPI_IOCTL_CMDS;


typedef enum _spi_ioctls
{
SPI_IOCTL_INIT,
SPI_IOCTL_RESET,
SPI_IOCTL_SET,
SPI_IOCTL_SEMAPHORE_UP,
SPI_IOCTL_SEMAPHORE_DOWN,
NUM_SPI_IOCTL_CMDS
} SPI_IOCTLS;

// number of bits in a character
#define CHAR_BITS 8

#define SPI_CLK_SPEED 50  // Max = 2.1MHz (see data sheet) Minium = 
BRGCLK/1024

/*## Forward declarations #*/

static int cpm_spi_open(struct inode *, struct file *);
static int cpm_spi_close(struct inode *, struct file *);
static ssize_t cpm_spi_write(struct file *, const char *, size_t, loff_t *);
static ssize_t cpm_spi_read(struct file *, char *, size_t, loff_t *);
static void cpm_spi_interrupt(void *);
static int cpm_spi_ioctl(struct inode *, struct file *, uint, ulong);
static int t1_semaphore_down(uint cmd, ulong arg);
static int t1_semaphore_up(uint cmd, ulong arg);
static int t1_cs_set(uint cmd, ulong arg);
static int t1_cs_reset(uint cmd, ulong arg);
static int t1_cs_init(uint cmd, ulong arg);
int spi_ioctl_set_clk(uint cmd, ulong arg);

/*## File scope variables #*/

static SPI_IOCTL_CMDS spi_ioctl_cmds[NUM_SPI_IOCTL_CMDS] = {
{"Initialise CS",   &t1_cs_init },
{"Reset CS",&t1_cs_reset},
{"Set CS",  &t1_cs_set},
{"Semaphore UP",&t1_semaphore_up},
{"Semaphore DOWN",  &t1_semaphore_down},
};

/* Number of users of the driver at any one time */
static int  cpm_spi_users = 0;

DECLARE_WAIT_QUEUE_HEAD(waitq);  // For waiting for SPI hardware to 
complete operation
DECLARE_WAIT_QUEU

Good GDB Version?

[Kent Borg]

On Fri, Dec 14, 2001 at 01:53:12PM -0500, I wrote:
> We are having problems with gdb.

And, though we have not gotten to the bottom of it, we seem to have a
hardware problem.  But a bizarre one.

We download our code, watch the kernel boot, get an sh prompt.  Fire
up ethernet, do an NFS mount of a directory on the development
machine.  Launch gdbserver on a trivial helloworld program, attach
from gdb on the development machine (using ethernet).

All that works.  It would seem to suggest the hardware is working,
right?  Well, that's what we thought.

Tell gdb to continue.  Immediately get a SIGTRAP.  And further
attempts to use gdb act strange, such as after hitting a breakpoint
not being able to continue from there.

Re-downloading the boot ROM does not fix it.

Swap in a different logic card, do all the above, and everything is
the same except that initial SIGTRAP doesn't happen and breakpoints
can be continued from and everything seems completely happy.  That
board works.

Swap in the physical boot ROM from the good board to the bad board and
the problem stays with the bad board.  Both boards have the same rev
of the 405GP.

How could we have crafted a custom board that can recognize that gdb
is running an only malfunction then?  I didn't know hardware could be
so clever.

My only guess is something hanging around the JTAG (or is it BDM?)
debug port might be funny--for the debug port has privileged access to
some of the same internal hardware that gdb uses.  Maybe a hardware
fault there could cause spurious SIGTRAPs--or maybe something is
fritzed inside the 405's debug hardware.

Strange.

-kb

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

ATM driver for 8260 (linux 2.4.x) + more questions

[None Atall]

 By the way, as I can see from mpc860sar code, the
ATM device is connected on SCCx via utopia. Our board
(MPC8260ADS and our custom one) have the ATM connected
on FCC1. Will I need too many changes after the patch?
Can anyone evaluate the changes that i will need?
We are running out of time, so I wonder...

  Thanks a lot!
  D.Meidanis




=
-
  Dhmhtrios Meidanis
-Degree in Mathematics, University of the Aegean.
-Master in Computer Architecture and Digital
 Systems, University of Crete.
  Greece.
-


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

Synchronous (HDLC) driver for MPC82xx SCC and kernel 2.4.x

[Ricardo Scop]

Hi,

I'm in the process of adapting an SCC HDLC driver for the Motorola
MPC8260 CPM. I'm aware of SNMC's Daris Nevil hdlc_ppp driver for the
8xx SCC, which works on Linux 2.2.x version, but I decided to start
from 8260 Dan Malek's scc_enet driver as a framework (which works on
2.4.x Linux version, and works very fast), and use the former as a
guideline.

In it's final shape, the driver will attach to the generic hdlc driver
available at the current kernel source tree, with support for PPP,
Cisco HDLC, raw HDLC, Frame Relay and X.25 WAN protocols. Plus, it
should be fast enough to handle 4 SCCs at a high rate aggregate (maybe
8 Mbps or more... the sky is the limit).

What I would like to know is:

- Is my approach a good one? (IMHO, yes :-))

- Should I take the risk of not having an interrupt routine's bottom
half, as in the SCC ethernet driver?

- Are there any other 8xx/82xx SCC synchronous driver implementations
other then the above mentioned?

I would be very glad to share my present (and future) knowledge and
experience with those working on this subject.

Thanks in advance for any suggestions/pointers...

Ricardo Scop  mailto:scop at vanet.com.br
R SCOP Consult.
-
"Don't hate, it's too big a burden to bear."
~Martin Luther King Jr.


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