PPC440EPx GPIO control help

PPC440EPx GPIO control help

[Dell Query]

[-- Attachment #1: Type: text/plain, Size: 542 bytes --]

Hi,

I am a Linux and PPC newbie.

I have a PPC440EPx Sequoia Evaluation board that runs on Linux 2.6.21. What I would want to do is to control (write and read values to) its GPIO. Perhaps similar to Turbo C's outputb(0x378,0x01) to write and inportb(0x378) to read. I read the PPC440EPx manual but I find it difficult to understand.

Could anyone show me any tutorial or some sample codes?

Thanks,
Dell
       
---------------------------------
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. 

[-- Attachment #2: Type: text/html, Size: 884 bytes --]

Re: PPC440EPx GPIO control help

[David Hawkins]

Hi Dell,

> I am a Linux and PPC newbie.

Ok.

> I have a PPC440EPx Sequoia Evaluation board that runs on Linux 2.6.21. 
> What I would want to do is to control (write and read values to) its 
> GPIO. Perhaps similar to Turbo C's outputb(0x378,0x01) to write and 
> inportb(0x378) to read. I read the PPC440EPx manual but I find it 
> difficult to understand.
> 
> Could anyone show me any tutorial or some sample codes?

I copied the code below from some test code I wrote for a TS7300
board (uses an ARM EP9302 processor). However, since its user-space
code it should work fine.

Generally for manipulating I/Os you write a custom driver. However,
when getting to know a processor, it sometimes helps to cheat and
just write to registers directly.

The code below uses /dev/mem to map a page or more of the processor
address space into your process. Go find the byte address of your
GPIO registers and pass that as the argument.

Google for /dev/mem and you'll find lots of code that looks more
or less like this. This code just gives you a minimal console so
that you can mess with multiple registers.

BTW, you can really screw yourself if you mess with registers
you shouldn't, eg. memory controller settings etc. So be careful.

 From the looks of the code, it provides options for
32-bit access or 8-bit access.

Cheers,
Dave



/*
  * mem_debug.c
  *
  * 5/10/07 D. W. Hawkins (dwh@ovro.caltech.edu)
  *
  * A debug console for read/write access to /dev/mem mapped
  * areas.
  */
#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <signal.h>
#include <sys/mman.h>
#include <stdlib.h>
#include <unistd.h>

void display_help();
void change_mem(char *cmd);
void display_mem(char *cmd);
void process_command(char *cmd);

/* Mapped address and size */
static char        *mem_addr  = NULL;
static unsigned int mem_phys  = 0;
static unsigned int mem_pages = 0;
static unsigned int mem_size = 0;

static void show_usage()
{
	printf("\nUsage: mem_debug -a <address> -n <pages>\n"\
		 "  -h            Help (this message)\n"\
		 "  -a <address>  Hex address to start the map\n"\
		 "  -n <pages>    Number of pages to map\n\n");
}

int main(int argc, char *argv[])
{
	int opt;       /* getopt processing         */
	int fd;        /* /dev/mem file descriptor  */
	char buf[200]; /* command processing buffer */
	int len = 200;
	int page_size = getpagesize();
	int status;

	while ((opt = getopt(argc, argv, "a:hn:")) != -1) {
		switch (opt) {
			case 'a':
				status = sscanf(optarg, "%X", &mem_phys);
				if (status != 1) {
					printf("Parse error for -a option\n");
					show_usage();
					return -1;
				}
				break;
			case 'h':
				show_usage();
				return -1;
			case 'n':
				mem_pages = atoi(optarg);
				break;
			default:
				show_usage();
				return -1;
		}
	}
	if (mem_phys != (mem_phys/page_size)*page_size) {
		printf("Error: the address must be page-aligned (0x%X)\n",
				page_size);
		return -1;
	}
	if (mem_pages == 0) {
		mem_pages = 1;
	}
	mem_size = mem_pages*page_size;

	/* Startup */
	printf("\n------------------------\n");
	printf("/dev/mem debug interface\n");
	printf("========================\n\n");

	/* Open /dev/mem and map it */
	printf(" * open /dev/mem\n");
	fd = open("/dev/mem", O_RDWR | O_SYNC);
	if (fd < 0) {
		printf("Open /dev/mem failed - %s\n",
			strerror(errno));
		return -1;
	}
	printf(" * map %d page(s) (%d-bytes) at address 0x%.8X\n",
			mem_pages, mem_size, mem_phys);
	mem_addr = (char *)mmap(
		0,
		mem_size,
		PROT_READ|PROT_WRITE,
		MAP_SHARED,
		fd,
		mem_phys);
	if (mem_addr == (char *)MAP_FAILED) {
		printf("Error: mmap failed\n");
		close(fd);
		return -1;
	}

	/* Display help */
	display_help();

	/* Process commands */
	while (1) {
		printf("CMD> ");
		fflush(stdout);
		fgets(buf,len,stdin);
		process_command(buf);
	}

	/* Cleanup */
	munmap((void *)mem_addr, mem_pages*page_size);
	close(fd);
	return 0;
}

/*--------------------------------------------------------------------
  * User interface
  *--------------------------------------------------------------------
  */
void display_help()
{
	printf("\n  ?              Help\n");
	printf("  dw addr len    Display len words starting from  addr\n");
	printf("  db addr len    Display len bytes starting from addr\n");
	printf("  cw addr val    Change word at addr to val\n");
	printf("  cb addr val    Change byte at addr to val\n");
	printf("  q              Quit\n");
	printf("\n  Notes:\n");
	printf("    * addr, len, and val are interpreted as hex values\n");
	printf("    * addresses are always byte based\n");
	printf("    * addresses are offsets relative to the base address\n\n");
}

void process_command(char *cmd)
{
	if (cmd[0] == '\0') {
		return;
	}
	switch (cmd[0]) {
		case '?':
			display_help();
			break;
		case 'd':
		case 'D':
			display_mem(cmd);
			break;
		case 'c':
		case 'C':
			change_mem(cmd);
			break;
		case 'q':
		case 'Q':
			exit(0);
		default:
			break;
	}

	return;
}

void display_mem(char *cmd)
{
	char width = 0;
	int addr = 0;
	int len = 0;
	int status;
	int i, data;

	/* d, db, dw */
	status = sscanf(cmd, "%*c%c %x %x", &width, &addr, &len);
	if (status != 3) {
		printf("syntax error (use ? for help)\n");
		return;
	}
	if (len > mem_size) {
		len = mem_size;
	}
	/* Convert to offset if required */
	if (addr >= mem_phys) {
		addr -= mem_phys;
	}
	if (addr >= mem_size) {
		printf("Illegal address\n");
		return;
	}
	switch (width) {
		case 'b':
			for (i = 0; i < len; i++) {
				if ((i%16) == 0) {
					printf("\n%.8X: ", mem_phys + addr + i);
				}
				data = (int)(mem_addr[addr+i]) & 0xFF;
				printf("%.02X ", data);
			}
			printf("\n");
			break;
		default:
			for (i = 0; i < len; i+=4) {
				if ((i%16) == 0) {
					printf("\n%.8X: ", mem_phys + addr + i);
				}
				data = *(int *)(mem_addr + addr + i);
				printf("%.08X ", data);
			}
			printf("\n");
			break;
	}
	printf("\n");
	return;
}

void change_mem(char *cmd)
{
	char width = 0;
	int addr = 0;
	int data = 0;
	int status;

	/* c, cb, cw */
	status = sscanf(cmd, "%*c%c %x %x", &width, &addr, &data);
	if (status != 3) {
		printf("syntax error (use ? for help)\n");
		return;
	}
	/* Convert to offset if required */
	if (addr >= mem_phys) {
		addr -= mem_phys;
	}
	if (addr >= mem_size) {
		printf("Illegal address\n");
		return;
	}
	switch (width) {
		case 'b':
			mem_addr[addr] = data & 0xFF;
			break;
		default:
			*(int *)(mem_addr + addr) = data;
			break;
	}
	return;
}

Re: PPC440EPx GPIO control help

[Jeff Mock]

David Hawkins wrote:
>> I have a PPC440EPx Sequoia Evaluation board that runs on Linux 2.6.21. 
>> What I would want to do is to control (write and read values to) its 
>> GPIO. Perhaps similar to Turbo C's outputb(0x378,0x01) to write and 
>> inportb(0x378) to read. I read the PPC440EPx manual but I find it 
>> difficult to understand.
>>
>> Could anyone show me any tutorial or some sample codes?
> 
> I copied the code below from some test code I wrote for a TS7300
> board (uses an ARM EP9302 processor). However, since its user-space
> code it should work fine.
> 

I might be a little out of date, but I think you must write your own 
driver to wiggle the GPIO pins on a 440 processor.  I just finished a 
project using a 440GX with a 2.6.15 kernel (we froze the code about 8 
months ago).

The 440 powerPC core is a 32-bit processor with 36-bit physical 
addresses.  The physical address for the GPIO pins is someplace above 
4GB.  An mmap() of /dev/mem only lets you map the lower 4GB of the 
address space, as a result you can't write a user space program on the 
440 to wiggle the GPIO pins.  (This was true with 2.6.15, I can't speak 
for later kernels).

This tossed me into writing device drivers, which turned out to be not 
nearly as scary as I imagined.  The Linux Device Drivers book is fabulous:

    http://lwn.net/Kernel/LDD3/

Here is a driver for the 440GX that controls an LED on one of the GPIO 
pins you can use as an example.  The device /dev/pdev-led has a 
read/write interface so you can do something like this:

    # echo "1" > /dev/pdev-led      # turn on LED
    # echo "0" > /dev/pdev-led      # turn off LED

It also has a /proc interface so you can cat /proc/pdev-led to read the 
status of the LED.  There are several other drivers there that probably 
won't be interesting, but pdev-led.c is probably a good starting point:
 
http://www.mock.com/wsvn/listing.php?repname=mock.pdev&path=/trunk/sw/driver/

jeff

Re: PPC440EPx GPIO control help

[Josh Boyer]

On Tue, 2007-10-16 at 23:21 -0700, Jeff Mock wrote:
> David Hawkins wrote:
> >> I have a PPC440EPx Sequoia Evaluation board that runs on Linux 2.6.21. 
> >> What I would want to do is to control (write and read values to) its 
> >> GPIO. Perhaps similar to Turbo C's outputb(0x378,0x01) to write and 
> >> inportb(0x378) to read. I read the PPC440EPx manual but I find it 
> >> difficult to understand.
> >>
> >> Could anyone show me any tutorial or some sample codes?
> > 
> > I copied the code below from some test code I wrote for a TS7300
> > board (uses an ARM EP9302 processor). However, since its user-space
> > code it should work fine.
> > 
> 
> I might be a little out of date, but I think you must write your own 
> driver to wiggle the GPIO pins on a 440 processor.  I just finished a 
> project using a 440GX with a 2.6.15 kernel (we froze the code about 8 
> months ago).
> 
> The 440 powerPC core is a 32-bit processor with 36-bit physical 
> addresses.  The physical address for the GPIO pins is someplace above 
> 4GB.  An mmap() of /dev/mem only lets you map the lower 4GB of the 
> address space, as a result you can't write a user space program on the 
> 440 to wiggle the GPIO pins.  (This was true with 2.6.15, I can't speak 
> for later kernels).

This depends on the 440 chip itself.  If I recall correctly, the
440EP(x) chips don't have I/O above 4GB.

josh

Re: PPC440EPx GPIO control help

[Misbah khan]

I Prefer that you write a coustem driver. map the GPIO address (Either make
use of mapped area of GPIO that u may find in the source for comercial
kernel or else map the physical address in the driver and access it ).

---Misbah


Josh Boyer-4 wrote:
> 
> On Tue, 2007-10-16 at 23:21 -0700, Jeff Mock wrote:
>> David Hawkins wrote:
>> >> I have a PPC440EPx Sequoia Evaluation board that runs on Linux 2.6.21. 
>> >> What I would want to do is to control (write and read values to) its 
>> >> GPIO. Perhaps similar to Turbo C's outputb(0x378,0x01) to write and 
>> >> inportb(0x378) to read. I read the PPC440EPx manual but I find it 
>> >> difficult to understand.
>> >>
>> >> Could anyone show me any tutorial or some sample codes?
>> > 
>> > I copied the code below from some test code I wrote for a TS7300
>> > board (uses an ARM EP9302 processor). However, since its user-space
>> > code it should work fine.
>> > 
>> 
>> I might be a little out of date, but I think you must write your own 
>> driver to wiggle the GPIO pins on a 440 processor.  I just finished a 
>> project using a 440GX with a 2.6.15 kernel (we froze the code about 8 
>> months ago).
>> 
>> The 440 powerPC core is a 32-bit processor with 36-bit physical 
>> addresses.  The physical address for the GPIO pins is someplace above 
>> 4GB.  An mmap() of /dev/mem only lets you map the lower 4GB of the 
>> address space, as a result you can't write a user space program on the 
>> 440 to wiggle the GPIO pins.  (This was true with 2.6.15, I can't speak 
>> for later kernels).
> 
> This depends on the 440 chip itself.  If I recall correctly, the
> 440EP(x) chips don't have I/O above 4GB.
> 
> josh
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 

-- 
View this message in context: http://www.nabble.com/PPC440EPx-GPIO-control-help-tf4638058.html#a13252501
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

Re: PPC440EPx GPIO control help

[Jeff Mock]

Josh Boyer wrote:
> On Tue, 2007-10-16 at 23:21 -0700, Jeff Mock wrote:
>> David Hawkins wrote:
>>>> I have a PPC440EPx Sequoia Evaluation board that runs on Linux 2.6.21. 
>>>> What I would want to do is to control (write and read values to) its 
>>>> GPIO. Perhaps similar to Turbo C's outputb(0x378,0x01) to write and 
>>>> inportb(0x378) to read. I read the PPC440EPx manual but I find it 
>>>> difficult to understand.
>>>>
>>>> Could anyone show me any tutorial or some sample codes?
>>> I copied the code below from some test code I wrote for a TS7300
>>> board (uses an ARM EP9302 processor). However, since its user-space
>>> code it should work fine.
>>>
>> I might be a little out of date, but I think you must write your own 
>> driver to wiggle the GPIO pins on a 440 processor.  I just finished a 
>> project using a 440GX with a 2.6.15 kernel (we froze the code about 8 
>> months ago).
>>
>> The 440 powerPC core is a 32-bit processor with 36-bit physical 
>> addresses.  The physical address for the GPIO pins is someplace above 
>> 4GB.  An mmap() of /dev/mem only lets you map the lower 4GB of the 
>> address space, as a result you can't write a user space program on the 
>> 440 to wiggle the GPIO pins.  (This was true with 2.6.15, I can't speak 
>> for later kernels).
> 
> This depends on the 440 chip itself.  If I recall correctly, the
> 440EP(x) chips don't have I/O above 4GB.
> 

At first I thought you were right, I remember something about the 440GX 
being the weird processor with I/O mapped above 4GB.  I just took a look 
at the 440EPx datasheet on the AMCC website and it looks like the GPIO 
registers are mapped above 4GB:

    GPIO0 controller       1 EF60 0B00
    GPIO1 controller       1 EF60 0C00

Someone has to do the ioremap() to get at these physical addresses, so I 
think you have to write a driver to get them mapped into user space. 
It's unfortunate, especially for someone just getting started with the 
processor that just wants to turn on an LED...

jeff

Re: PPC440EPx GPIO control help

[Josh Boyer]

On Wed, 17 Oct 2007 13:26:42 -0700
Jeff Mock <jeff@mock.com> wrote:

> 
> 
> Josh Boyer wrote:
> > On Tue, 2007-10-16 at 23:21 -0700, Jeff Mock wrote:
> >> David Hawkins wrote:
> >>>> I have a PPC440EPx Sequoia Evaluation board that runs on Linux 2.6.21. 
> >>>> What I would want to do is to control (write and read values to) its 
> >>>> GPIO. Perhaps similar to Turbo C's outputb(0x378,0x01) to write and 
> >>>> inportb(0x378) to read. I read the PPC440EPx manual but I find it 
> >>>> difficult to understand.
> >>>>
> >>>> Could anyone show me any tutorial or some sample codes?
> >>> I copied the code below from some test code I wrote for a TS7300
> >>> board (uses an ARM EP9302 processor). However, since its user-space
> >>> code it should work fine.
> >>>
> >> I might be a little out of date, but I think you must write your own 
> >> driver to wiggle the GPIO pins on a 440 processor.  I just finished a 
> >> project using a 440GX with a 2.6.15 kernel (we froze the code about 8 
> >> months ago).
> >>
> >> The 440 powerPC core is a 32-bit processor with 36-bit physical 
> >> addresses.  The physical address for the GPIO pins is someplace above 
> >> 4GB.  An mmap() of /dev/mem only lets you map the lower 4GB of the 
> >> address space, as a result you can't write a user space program on the 
> >> 440 to wiggle the GPIO pins.  (This was true with 2.6.15, I can't speak 
> >> for later kernels).
> > 
> > This depends on the 440 chip itself.  If I recall correctly, the
> > 440EP(x) chips don't have I/O above 4GB.
> > 
> 
> At first I thought you were right, I remember something about the 440GX 
> being the weird processor with I/O mapped above 4GB.  I just took a look 
> at the 440EPx datasheet on the AMCC website and it looks like the GPIO 
> registers are mapped above 4GB:
> 
>     GPIO0 controller       1 EF60 0B00
>     GPIO1 controller       1 EF60 0C00

Actually, it's 440EP that has the addresses below 4GB, not 440EPx.  My
apologies for the confusion.  As far as "weird" goes in the 44x world,
440EP is the oddball as I believe most all other 44x versions have some
if not all I/O above 4GB.

josh

Re: PPC440EPx GPIO control help

[David Hawkins]

Hi Dell,

If you do decide to look at kernel drivers, Jeff has sent you
code, and I also have a tutorial with example code you are
welcome to look at:

http://www.ovro.caltech.edu/~dwh/correlator/pdf/LNX-723-Hawkins.pdf
http://www.ovro.caltech.edu/~dwh/correlator/software/driver_design.tar.gz

Feel free to ask questions. I recall writing some test driver
code for the 440EP Yosemite board too. I'm just not sure where
I put it ...  :)

Cheers,
Dave

Re: PPC440EPx GPIO control help

[Dell Query]

[-- Attachment #1: Type: text/plain, Size: 725 bytes --]


Hi David,

I'll take a look at the PDF file you sent me.

Thanks,
dell
David Hawkins <dwh@ovro.caltech.edu> wrote: Hi Dell,

If you do decide to look at kernel drivers, Jeff has sent you
code, and I also have a tutorial with example code you are
welcome to look at:

http://www.ovro.caltech.edu/~dwh/correlator/pdf/LNX-723-Hawkins.pdf
http://www.ovro.caltech.edu/~dwh/correlator/software/driver_design.tar.gz

Feel free to ask questions. I recall writing some test driver
code for the 440EP Yosemite board too. I'm just not sure where
I put it ...  :)

Cheers,
Dave




 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[-- Attachment #2: Type: text/html, Size: 961 bytes --]

Re: PPC440EPx GPIO control help

[Dell Query]

[-- Attachment #1: Type: text/plain, Size: 2408 bytes --]

Hi Jeff,

I read the device drivers part of the LDD3, it's really difficult as I expected. Thanks for the sample codes. I'll develop my own driver basing from your samples. Regarding reading the status of the LED, is it really necessary to use proc?

Regards,
dell

Jeff Mock <jeff@mock.com> wrote: 
David Hawkins wrote:
>> I have a PPC440EPx Sequoia Evaluation board that runs on Linux 2.6.21. 
>> What I would want to do is to control (write and read values to) its 
>> GPIO. Perhaps similar to Turbo C's outputb(0x378,0x01) to write and 
>> inportb(0x378) to read. I read the PPC440EPx manual but I find it 
>> difficult to understand.
>>
>> Could anyone show me any tutorial or some sample codes?
> 
> I copied the code below from some test code I wrote for a TS7300
> board (uses an ARM EP9302 processor). However, since its user-space
> code it should work fine.
> 

I might be a little out of date, but I think you must write your own 
driver to wiggle the GPIO pins on a 440 processor.  I just finished a 
project using a 440GX with a 2.6.15 kernel (we froze the code about 8 
months ago).

The 440 powerPC core is a 32-bit processor with 36-bit physical 
addresses.  The physical address for the GPIO pins is someplace above 
4GB.  An mmap() of /dev/mem only lets you map the lower 4GB of the 
address space, as a result you can't write a user space program on the 
440 to wiggle the GPIO pins.  (This was true with 2.6.15, I can't speak 
for later kernels).

This tossed me into writing device drivers, which turned out to be not 
nearly as scary as I imagined.  The Linux Device Drivers book is fabulous:

    http://lwn.net/Kernel/LDD3/

Here is a driver for the 440GX that controls an LED on one of the GPIO 
pins you can use as an example.  The device /dev/pdev-led has a 
read/write interface so you can do something like this:

    # echo "1" > /dev/pdev-led      # turn on LED
    # echo "0" > /dev/pdev-led      # turn off LED

It also has a /proc interface so you can cat /proc/pdev-led to read the 
status of the LED.  There are several other drivers there that probably 
won't be interesting, but pdev-led.c is probably a good starting point:
 
http://www.mock.com/wsvn/listing.php?repname=mock.pdev&path=/trunk/sw/driver/

jeff




 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[-- Attachment #2: Type: text/html, Size: 2806 bytes --]

Re: PPC440EPx GPIO control help

[Jeff Mock]

Oh no, it's not necessary to use /proc, pdev-lcd was my first device 
driver.  I wanted to try out all of the different features and it was 
fun to add a /proc interface.  It could just as easily have a read 
interface or an ioctl() or whatever.

I think LDD3 is fantastic, stick with it and go slowly.  Start out by 
writing little test drivers on your desktop machine where it's easy to 
debug.  LDD3 really got me over the hump of writing device drivers.

jeff



Dell Query wrote:
> Hi Jeff,
> 
> I read the device drivers part of the LDD3, it's really difficult as
> I
expected. Thanks for the sample codes. I'll develop my own driver basing
from your samples. Regarding reading the status of the LED, is it really
necessary to use proc?

> Regards,
> dell
> 
> Jeff Mock <jeff@mock.com> wrote: 
> David Hawkins wrote:
>>> I have a PPC440EPx Sequoia Evaluation board that runs on Linux 2.6.21. 
>>> What I would want to do is to control (write and read values to) its 
>>> GPIO. Perhaps similar to Turbo C's outputb(0x378,0x01) to write and 
>>> inportb(0x378) to read. I read the PPC440EPx manual but I find it 
>>> difficult to understand.
>>>
>>> Could anyone show me any tutorial or some sample codes?
>> I copied the code below from some test code I wrote for a TS7300
>> board (uses an ARM EP9302 processor). However, since its user-space
>> code it should work fine.
>>
> 
> I might be a little out of date, but I think you must write your own 
> driver to wiggle the GPIO pins on a 440 processor.  I just finished a 
> project using a 440GX with a 2.6.15 kernel (we froze the code about 8 
> months ago).
> 
> The 440 powerPC core is a 32-bit processor with 36-bit physical 
> addresses.  The physical address for the GPIO pins is someplace above 
> 4GB.  An mmap() of /dev/mem only lets you map the lower 4GB of the 
> address space, as a result you can't write a user space program on the 
> 440 to wiggle the GPIO pins.  (This was true with 2.6.15, I can't speak 
> for later kernels).
> 
> This tossed me into writing device drivers, which turned out to be not 
> nearly as scary as I imagined.  The Linux Device Drivers book is fabulous:
> 
>     http://lwn.net/Kernel/LDD3/
> 
> Here is a driver for the 440GX that controls an LED on one of the GPIO 
> pins you can use as an example.  The device /dev/pdev-led has a 
> read/write interface so you can do something like this:
> 
>     # echo "1" > /dev/pdev-led      # turn on LED
>     # echo "0" > /dev/pdev-led      # turn off LED
> 
> It also has a /proc interface so you can cat /proc/pdev-led to read the 
> status of the LED.  There are several other drivers there that probably 
> won't be interesting, but pdev-led.c is probably a good starting point:
>  
> http://www.mock.com/wsvn/listing.php?repname=mock.pdev&path=/trunk/sw/driver/
> 
> jeff
> 
> 
> 
> 
>  __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 

PPC440EPx GPIO control help

[Dell Query]

[-- Attachment #1: Type: text/plain, Size: 555 bytes --]

Hi,

I am a Linux and PPC newbie.

I have a PPC440EPx Sequoia Evaluation board that runs on Linux 2.6.21. What I would want to do is to control (write and read values to) its GPIO. Perhaps similar to Turbo C's outputb(0x378,0x01) to write and inportb(0x378) to read. I read the PPC440EPx manual but I find it difficult to understand.

Could anyone show me any tutorial or some sample codes?

Thanks,
Dell
       
---------------------------------
Moody friends. Drama queens. Your life? Nope! - their life, your story.
 Play Sims Stories at Yahoo! Games. 

[-- Attachment #2: Type: text/html, Size: 639 bytes --]