* RE: Xilinx_uartlite
From: Jaap de Jong @ 2005-12-01 7:13 UTC (permalink / raw)
To: T Ziomek, linuxppc-embedded
Hi Tom,
Thanks for your reply, but then I only get:
Now booting the kernel
Beste regards,
Jaap
-----Oorspronkelijk bericht-----
Van: T Ziomek [mailto:ctz001@email.mot.com]=20
Verzonden: donderdag 1 december 2005 02:06
Aan: Jaap de Jong; linuxppc-embedded
Onderwerp: Re: Xilinx_uartlite
> I'm trying to get my avnet virtex4fx12 running with linux.
> It boots, but ends with:
> Warning: unable to open an initial console.
> This means /dev/console was not opened; init is running.
> Since my board has no 16550 uart I must use xilinx_uartlite Part of my
> configuration:
> +--Character devices
> +--Xilinx UART Lite ON
> +--Console on UART Lite port ON
> Any ideas?
/dev/console may not be tied to your UARTLite. If you don't specify the
console on your kernel command line, try adding something along the
lines of "console=3DttyS0,19200" to it (with the appropriate device and
baud rate of course).
Tom
--=20
/"\ ASCII Ribbon Campaign |
\ / | Email to user 'CTZ001'
X Against HTML | at 'email.mot.com'
/ \ in e-mail & news |
^ permalink raw reply
* Re:RE: linuxppc-embedded help needed:kernel access of bad area
From: zengshuai @ 2005-12-01 6:52 UTC (permalink / raw)
To: Fillod Stephane; +Cc: Linuxppc-embedded
thanks very much.but i'm not going to write a user space program.
this is the detail:
//led-module.c
#ifndef __KERNEL__
#define __KERNEL__
#endif
#ifndef MODULE
#define MODULE
#endif
#include <linux/config.h>
#include <linux/module.h>
MODULE_LICENSE("GPL");
#ifdef CONFIG_SMP
#define __SMP__
#endif
#define CONFIG_TASK_SIZE 0x80000000
#include <asm/processor.h>
#include <linux/init.h>
#include <asm/uaccess.h> /* copy_to_user(), copy_from_user() */
#include <linux/fs.h> /* struct file_operations, register_chrdev(), ... */
#include <linux/kernel.h> /* printk()*/
#include <linux/sched.h>
#include "led-module.h"
#define BCSRADDR 0x04500000
static int PQ2FADS_GPL_open (struct inode *inode, struct file *filp);
static ssize_t PQ2FADS_GPL_read (struct file *filp, char *buf, size_t count,loff_t *f_pos);
static ssize_t PQ2FADS_GPL_write (struct file *filp, const char *buf, size_t count,loff_t *f_pos);
static int PQ2FADS_GPL_ioctl (struct inode *inode,struct file *filp,unsigned int cmd,unsigned long scmd);
static int PQ2FADS_GPL_release (struct inode *inode, struct file *filp);
struct file_operations PQ2FADS_GPL_fops = {
open: PQ2FADS_GPL_open,
release: PQ2FADS_GPL_release,
ioctl: PQ2FADS_GPL_ioctl,
read: PQ2FADS_GPL_read,
write: PQ2FADS_GPL_write,
};
static int PQ2FADS_GPL_major;
static int PQ2FADS_GPL_state;
static volatile PQ2FADS_BCSR *PQ2FADS_GPL_CSR=0;
static int init_module(void)
{
printk ("This' a PQ2FADS_ZU board GPL LED Device File!\n");
PQ2FADS_GPL_major = register_chrdev (0, "GPL LED Device", &PQ2FADS_GPL_fops);
if (PQ2FADS_GPL_major < 0)
{
printk("error1");
return PQ2FADS_GPL_major;
}
printk ("The major is:%d\n", PQ2FADS_GPL_major);
return 0;
}
static void cleanup_module(void)
{
unregister_chrdev(PQ2FADS_GPL_major, "GPL LED Device");
printk("PQ2FADS_ZU board GPL LED Device has been removed! bye!\n");
}
static int PQ2FADS_GPL_open(struct inode *inode,struct file *filp)
{
PQ2FADS_GPL_CSR=(PQ2FADS_BCSR*)BCSRADDR;
printk("open %s...OK!\n ", current->comm);
return 0;
}
static int PQ2FADS_GPL_release(struct inode *inode,struct file *filp)
{
printk("close....OK!\n ");
return 0;
}
static ssize_t PQ2FADS_GPL_read(struct file *filp,char *buf,size_t count,loff_t *f_pos)
{
// char ledopen[20]="led is open.";
// char ledclose[20]="led is close.";
// count=20;
if(((PQ2FADS_GPL_CSR->bcsr0) & 0x02000000) == 0x0) printk("led is open");
// else copy_to_user(buf,ledclose,20);
return count;
}
static ssize_t PQ2FADS_GPL_write(struct file *filp,const char *buf,size_t count,loff_t *f_pos)
{
PQ2FADS_GPL_CSR->bcsr0 |=0x02000000;
return 0;
}
static int PQ2FADS_GPL_ioctl(struct inode *inode,struct file *filp,unsigned int cmd,unsigned long scmd)
{
return 0;
}
//led-app.c
#include <stdio.h>
int main(void)
{
int mydev,err;
char resultchar[20]="begin...";
mydev=open("/dev/PQ2FADS_GPL","rb+");
if(mydev<0)
{
printf("open error.\n");
return 1;
}
err=read(mydev,resultchar,20);
if(err !=20) printf("read1 error!\n");
printf("read1=%s",resultchar);
err=write(mydev,resultchar,20);
if(err !=0) printf("write error!\n");
err=read(mydev,resultchar,20);
if(err !=20) printf("read2 error!\n");
printf("read2=%s",resultchar);
return 0;
}
i got led-module.o and led-app.exe
i insmod led-module.o
mknod /dev/PQ2FADS_GPL
and when i run led-app.exe
show:
# ./led-app.exe
open led-app.exe...OK!
Oops: kernel access of bad area, sig: 11
NIP: C30B11B4 XER: 00000000 LR: C003A310 SP: C06B1F00 REGS: c06b1e50 TRAP: 0300
Not tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 04500000, DSISR: 20000000
TASK = c06b0000[201] 'led-app.exe' Last syscall: 3
last math c06b0000 last altivec 00000000
GPR00: C003A310 C06B1F00 C06B0000 C01A5AA0 7FFFFDE0 00000014 C01A5AC0 00000000
GPR08: 00000000 04500000 0000000C C01A0000 30025CE8 10018B5C 00000000 00000000
GPR16: 00000000 00000000 00000000 00000000 00009032 006B1F40 00000000 C0003E88
GPR24: C0003BE0 00000001 10000500 7FFFFEA4 7FFFFDE0 FFFFFFEA C01A5AA0 00000014
Call backtrace:
10000A1C C003A310 C0003C3C 100004AC 0FEC6D74 00000000
Segmentation fault
#
as you know,i am really a new gay.help me please.
----- Original Message -----
From: Fillod Stephane
To: zengshuai@sogou.com ;ppc
Subject: RE: linuxppc-embedded help needed:kernel access of bad area
Sent: Wed Nov 30 17:33:25 CST 2005
> Dear zengshuai,
>
> zengshuai@sogou.com wrote:
> > i writed a led driver for PQ2FADS(a ppc board).
> > but i can't read/write 0x04500000 where led register addr locate in.
> > i tested two ways to do that.
> > first,
> > p=0x04500000;
> > *p=0x12;
> > ....
> > second,
> > outb(0x12,0x04500000);
> > ...
> > two ways both didn't work.they had a some wrong:kernel access of bad
> area.
> > how can i know which area is bad area or good area?
> > and what can i do next? thanks.
>
> Do yourself a favor, read a book about Linux device driver development,
> for example one listed[1] in the excellent Denx's DLUG FAQ[2].
> Getting some training on PowerPC development is a good idea too.
> [1] http://www.denx.de/wiki/view/DULG/MoreInformationBooks
> [2] http://www.denx.de/wiki/DULG/Manual
>
> Peruse also your chip data-sheet, and you will see that outb() is
> non-sense.
>
> If you are accessing the led register from kernel space, you'll find
> a solution using ioremap(). Otherwise, if you are accessing the led
> register
> from user space, this link[3] will help you, or this shorter one[4].
> You can follow this thread[5] for more information.
>
> [3]
> http://www.denx.de/twiki/bin/view/PPCEmbedded/DeviceDrivers#Section_Acce
> ssingPeripheralsFromUserSpace
> [4] http://tinyurl.com/6c7th
> [5] http://lists.linuxppc.org/linuxppc-embedded/200403/msg00059.html
>
> Please next time, do ourselves a favor, try some searching first
> (google,
> whatever). Your question is a FAQ.
>
> Regards,
> --
> Stephane
>
------------------------------
?????Sogou.com?2G??????????!
http://mail.sogou.com/recommend/sogoumail_invite_reg1.jsp?from=sogouinvitation&s_EMAIL=zengshuai%40sogou.com&username=&FullName=&Email=&verify=e197bd6dbd1fc7f8d6a035729df08d63
^ permalink raw reply
* Re: Xilinx_uartlite
From: T Ziomek @ 2005-12-01 1:06 UTC (permalink / raw)
To: jaap.dejong, linuxppc-embedded
In-Reply-To: <20051201010004.9B1FF68869@ozlabs.org>
> I'm trying to get my avnet virtex4fx12 running with linux.
> It boots, but ends with:
> Warning: unable to open an initial console.
> This means /dev/console was not opened; init is running.
> Since my board has no 16550 uart I must use xilinx_uartlite
> Part of my configuration:
> +--Character devices
> +--Xilinx UART Lite ON
> +--Console on UART Lite port ON
> Any ideas?
/dev/console may not be tied to your UARTLite. If you don't specify the
console on your kernel command line, try adding something along the lines
of "console=ttyS0,19200" to it (with the appropriate device and baud rate
of course).
Tom
--
/"\ ASCII Ribbon Campaign |
\ / | Email to user 'CTZ001'
X Against HTML | at 'email.mot.com'
/ \ in e-mail & news |
^ permalink raw reply
* Re: PowerBook5,8 - TrackPad update
From: Michael Hanselmann @ 2005-11-30 23:46 UTC (permalink / raw)
To: Parag Warudkar; +Cc: linuxppc-dev, johannes, debian-powerpc, linux-kernel
In-Reply-To: <20051130223917.GA15102@hansmi.ch>
[-- Attachment #1: Type: text/plain, Size: 213 bytes --]
On Wed, Nov 30, 2005 at 11:39:17PM +0100, Michael Hanselmann wrote:
> The patch is attached for easier use.
There was a mistake in it due to which the mouse button wouldn't work.
Fixed in the now attached patch.
[-- Attachment #2: linux-2.6.15-rc3-appletouch-relayfs-0x0215.diff --]
[-- Type: text/plain, Size: 9993 bytes --]
--- linux-2.6.15-rc3/drivers/usb/input/appletouch.c.orig 2005-11-29 21:30:37.000000000 +0100
+++ linux-2.6.15-rc3/drivers/usb/input/appletouch.c 2005-11-30 23:40:19.000000000 +0100
@@ -6,9 +6,19 @@
* Copyright (C) 2005 Stelian Pop (stelian@popies.net)
* Copyright (C) 2005 Frank Arnold (frank@scirocco-5v-turbo.de)
* Copyright (C) 2005 Peter Osterlund (petero2@telia.com)
+ * Copyright (C) 2005 Parag Warudkar (parag.warudkar@gmail.com)
+ * Copyright (C) 2005 Michael hanselmann (linux-kernel@hansmi.ch)
*
* Thanks to Alex Harper <basilisk@foobox.net> for his inputs.
*
+ * Nov 2005 - Parag Warudkar
+ * o Added ability to export data via relayfs
+ *
+ * Nov 2005 - Michael Hanselmann
+ * o Compile relayfs support only if enabled in the kernel
+ * o Enable relayfs only if requested by the user
+ * o Added support for new October 2005 PowerBooks (0x0215)
+ *
* 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
@@ -35,6 +45,10 @@
#include <linux/input.h>
#include <linux/usb_input.h>
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+#include <linux/relayfs_fs.h>
+#endif
+
/* Apple has powerbooks which have the keyboard with different Product IDs */
#define APPLE_VENDOR_ID 0x05AC
@@ -51,14 +65,17 @@
static struct usb_device_id atp_table [] = {
{ ATP_DEVICE(0x020E) },
{ ATP_DEVICE(0x020F) },
+ { ATP_DEVICE(0x0215) }, /* PowerBook 1.67 GHz, Oct 2005, PowerBook5,8 */
{ ATP_DEVICE(0x030A) },
{ ATP_DEVICE(0x030B) },
{ } /* Terminating entry */
};
MODULE_DEVICE_TABLE (usb, atp_table);
-/* size of a USB urb transfer */
-#define ATP_DATASIZE 81
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+struct rchan* rch = NULL;
+struct rchan_callbacks* rcb = NULL;
+#endif
/*
* number of sensors. Note that only 16 instead of 26 X (horizontal)
@@ -108,6 +125,9 @@
signed char xy_old[ATP_XSENSORS + ATP_YSENSORS];
/* accumulated sensors */
int xy_acc[ATP_XSENSORS + ATP_YSENSORS];
+ int is0215; /* is the device a 0x0215? */
+ int overflowwarn; /* overflow warning printed? */
+ int datalen; /* size of a USB urb transfer */
};
#define dbg_dump(msg, tab) \
@@ -132,6 +152,10 @@
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, "Activate debugging output");
+static int relayfs = 0;
+module_param(relayfs, int, 0644);
+MODULE_PARM_DESC(relayfs, "Activate relayfs support");
+
static int atp_calculate_abs(int *xy_sensors, int nb_sensors, int fact,
int *z, int *fingers)
{
@@ -175,6 +199,13 @@
case 0:
/* success */
break;
+ case -EOVERFLOW:
+ if(!dev->overflowwarn) {
+ printk("appletouch: OVERFLOW with data "
+ "length %d, actual length is %d\n",
+ dev->datalen, dev->urb->actual_length);
+ dev->overflowwarn = 1;
+ }
case -ECONNRESET:
case -ENOENT:
case -ESHUTDOWN:
@@ -189,23 +220,84 @@
}
/* drop incomplete datasets */
- if (dev->urb->actual_length != ATP_DATASIZE) {
+ if (dev->urb->actual_length != dev->datalen) {
dprintk("appletouch: incomplete data package.\n");
goto exit;
}
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+ if (relayfs && dev->data) {
+ relay_write(rch, dev->data, dev->urb->actual_length);
+ }
+#endif
+
/* reorder the sensors values */
- for (i = 0; i < 8; i++) {
- /* X values */
- dev->xy_cur[i ] = dev->data[5 * i + 2];
- dev->xy_cur[i + 8] = dev->data[5 * i + 4];
- dev->xy_cur[i + 16] = dev->data[5 * i + 42];
- if (i < 2)
- dev->xy_cur[i + 24] = dev->data[5 * i + 44];
-
- /* Y values */
- dev->xy_cur[i + 26] = dev->data[5 * i + 1];
- dev->xy_cur[i + 34] = dev->data[5 * i + 3];
+ if (dev->is0215) {
+ memset(dev->xy_cur, 0, sizeof(dev->xy_cur));
+
+ // Read the X values
+ i = 0;
+ dev->xy_cur[i++] = dev->data[19];
+ dev->xy_cur[i++] = dev->data[20];
+ dev->xy_cur[i++] = dev->data[22];
+ dev->xy_cur[i++] = dev->data[23];
+ dev->xy_cur[i++] = dev->data[25];
+ dev->xy_cur[i++] = dev->data[26];
+ dev->xy_cur[i++] = dev->data[28];
+ dev->xy_cur[i++] = dev->data[29];
+ dev->xy_cur[i++] = dev->data[31];
+ dev->xy_cur[i++] = dev->data[32];
+ dev->xy_cur[i++] = dev->data[34];
+ dev->xy_cur[i++] = dev->data[35];
+ dev->xy_cur[i++] = dev->data[37];
+ dev->xy_cur[i++] = dev->data[38];
+ dev->xy_cur[i++] = dev->data[40];
+
+ // Read the Y values
+ i = ATP_XSENSORS;
+ dev->xy_cur[i++] = dev->data[1];
+ dev->xy_cur[i++] = dev->data[2];
+ dev->xy_cur[i++] = dev->data[4];
+ dev->xy_cur[i++] = dev->data[5];
+ dev->xy_cur[i++] = dev->data[7];
+ dev->xy_cur[i++] = dev->data[8];
+ dev->xy_cur[i++] = dev->data[10];
+ dev->xy_cur[i++] = dev->data[11];
+ dev->xy_cur[i++] = dev->data[13];
+
+#if 0
+ /* Some debug code */
+ for (i = 0; i < dev->urb->actual_length; i++) {
+ printk("%2x,", (unsigned char)dev->data[i]);
+ }
+ printk("\n");
+#endif
+
+ /* Prints the read values */
+ if (debug > 1) {
+ printk("appletouch: X=");
+ for (i = 0; i < 15; i++) {
+ printk("%2x,", (unsigned char)dev->xy_cur[i]);
+ }
+ printk(" Y=");
+ for (i = ATP_XSENSORS; i < (ATP_XSENSORS + (9 - 1)); i++) {
+ printk("%2x,", (unsigned char)dev->xy_cur[i]);
+ }
+ printk("\n");
+ }
+ } else {
+ for (i = 0; i < 8; i++) {
+ /* X values */
+ dev->xy_cur[i ] = dev->data[5 * i + 2];
+ dev->xy_cur[i + 8] = dev->data[5 * i + 4];
+ dev->xy_cur[i + 16] = dev->data[5 * i + 42];
+ if (i < 2)
+ dev->xy_cur[i + 24] = dev->data[5 * i + 44];
+
+ /* Y values */
+ dev->xy_cur[i + 26] = dev->data[5 * i + 1];
+ dev->xy_cur[i + 34] = dev->data[5 * i + 3];
+ }
}
dbg_dump("sample", dev->xy_cur);
@@ -216,16 +308,18 @@
dev->x_old = dev->y_old = -1;
memcpy(dev->xy_old, dev->xy_cur, sizeof(dev->xy_old));
- /* 17" Powerbooks have 10 extra X sensors */
- for (i = 16; i < ATP_XSENSORS; i++)
- if (dev->xy_cur[i]) {
- printk("appletouch: 17\" model detected.\n");
- input_set_abs_params(dev->input, ABS_X, 0,
- (ATP_XSENSORS - 1) *
- ATP_XFACT - 1,
- ATP_FUZZ, 0);
- break;
- }
+ if (!dev->is0215) {
+ /* 17" Powerbooks have 10 extra X sensors */
+ for (i = 16; i < ATP_XSENSORS; i++)
+ if (dev->xy_cur[i]) {
+ printk("appletouch: 17\" model detected.\n");
+ input_set_abs_params(dev->input, ABS_X, 0,
+ (ATP_XSENSORS - 1) *
+ ATP_XFACT - 1,
+ ATP_FUZZ, 0);
+ break;
+ }
+ }
goto exit;
}
@@ -323,7 +417,6 @@
int int_in_endpointAddr = 0;
int i, retval = -ENOMEM;
-
/* set up the endpoint information */
/* use only the first interrupt-in endpoint */
iface_desc = iface->cur_altsetting;
@@ -335,6 +428,8 @@
== USB_ENDPOINT_XFER_INT)) {
/* we found an interrupt in endpoint */
int_in_endpointAddr = endpoint->bEndpointAddress;
+ printk(KERN_INFO "appletouch: atp_probe found interrupt "
+ "in endpoint: %d\n", int_in_endpointAddr);
break;
}
}
@@ -353,6 +448,13 @@
dev->udev = udev;
dev->input = input_dev;
+ dev->is0215 = (le16_to_cpu(dev->udev->descriptor.idProduct) == 0x0215);
+ dev->overflowwarn = 0;
+ if (dev->is0215) {
+ dev->datalen = 64;
+ } else {
+ dev->datalen = 81;
+ }
dev->urb = usb_alloc_urb(0, GFP_KERNEL);
if (!dev->urb) {
@@ -360,7 +462,7 @@
goto err_free_devs;
}
- dev->data = usb_buffer_alloc(dev->udev, ATP_DATASIZE, GFP_KERNEL,
+ dev->data = usb_buffer_alloc(dev->udev, dev->datalen, GFP_KERNEL,
&dev->urb->transfer_dma);
if (!dev->data) {
retval = -ENOMEM;
@@ -369,7 +471,7 @@
usb_fill_int_urb(dev->urb, udev,
usb_rcvintpipe(udev, int_in_endpointAddr),
- dev->data, ATP_DATASIZE, atp_complete, dev, 1);
+ dev->data, dev->datalen, atp_complete, dev, 1);
usb_make_path(udev, dev->phys, sizeof(dev->phys));
strlcat(dev->phys, "/input0", sizeof(dev->phys));
@@ -385,14 +487,21 @@
set_bit(EV_ABS, input_dev->evbit);
- /*
- * 12" and 15" Powerbooks only have 16 x sensors,
- * 17" models are detected later.
- */
- input_set_abs_params(input_dev, ABS_X, 0,
- (16 - 1) * ATP_XFACT - 1, ATP_FUZZ, 0);
- input_set_abs_params(input_dev, ABS_Y, 0,
- (ATP_YSENSORS - 1) * ATP_YFACT - 1, ATP_FUZZ, 0);
+ if (dev->is0215) {
+ input_set_abs_params(input_dev, ABS_X, 0,
+ ((15 - 1) * ATP_XFACT) - 1, ATP_FUZZ, 0);
+ input_set_abs_params(input_dev, ABS_Y, 0,
+ ((9 - 1) * ATP_YFACT) - 1, ATP_FUZZ, 0);
+ } else {
+ /*
+ * 12" and 15" Powerbooks only have 16 x sensors,
+ * 17" models are detected later.
+ */
+ input_set_abs_params(input_dev, ABS_X, 0,
+ (16 - 1) * ATP_XFACT - 1, ATP_FUZZ, 0);
+ input_set_abs_params(input_dev, ABS_Y, 0,
+ (ATP_YSENSORS - 1) * ATP_YFACT - 1, ATP_FUZZ, 0);
+ }
input_set_abs_params(input_dev, ABS_PRESSURE, 0, ATP_PRESSURE, 0, 0);
set_bit(EV_KEY, input_dev->evbit);
@@ -427,7 +536,7 @@
usb_kill_urb(dev->urb);
input_unregister_device(dev->input);
usb_free_urb(dev->urb);
- usb_buffer_free(dev->udev, ATP_DATASIZE,
+ usb_buffer_free(dev->udev, dev->datalen,
dev->data, dev->urb->transfer_dma);
kfree(dev);
}
@@ -463,11 +572,30 @@
static int __init atp_init(void)
{
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+ if (relayfs) {
+ rcb = kmalloc(sizeof(struct rchan_callbacks), GFP_KERNEL);
+ rcb->subbuf_start = NULL;
+ rcb->buf_mapped = NULL;
+ rcb->buf_unmapped = NULL;
+ rch = relay_open("atpdata", NULL, 256, 256, NULL);
+ if (!rch) return -ENOMEM;
+ printk("appletouch: Relayfs enabled.\n");
+ } else {
+ printk("appletouch: Relayfs disabled.\n");
+ }
+#endif
return usb_register(&atp_driver);
}
static void __exit atp_exit(void)
{
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+ if (relayfs) {
+ relay_close(rch);
+ kfree(rcb);
+ }
+#endif
usb_deregister(&atp_driver);
}
^ permalink raw reply
* Re: PowerBook5,8 - TrackPad update
From: Michael Hanselmann @ 2005-11-30 22:39 UTC (permalink / raw)
To: Parag Warudkar; +Cc: linuxppc-dev, johannes, debian-powerpc, linux-kernel
In-Reply-To: <20051129000615.GA20843@hansmi.ch>
[-- Attachment #1: Type: text/plain, Size: 521 bytes --]
> My changes do that definitively, but it's only a hack.
I now integrated support for the 0x0215 device into the driver of
2.6.15-rc3, in addition to the relayfs functions.
It would be great to get some feedback from people who have touchpads
handled by appletouch.c other than 0x0215.
The patch is attached for easier use. If nobody speaks up, I'll submit
this one, as it's simply required for the touchpad on the new Oct 2005
PowerBooks (at least 15").
--
Gentoo Linux Developer using m0n0wall | http://hansmi.ch/
[-- Attachment #2: linux-2.6.15-rc3-appletouch-relayfs-0x0215.diff --]
[-- Type: text/plain, Size: 10045 bytes --]
--- linux-2.6.15-rc3/drivers/usb/input/appletouch.c.orig 2005-11-29 21:30:37.000000000 +0100
+++ linux-2.6.15-rc3/drivers/usb/input/appletouch.c 2005-11-30 23:23:26.000000000 +0100
@@ -6,9 +6,19 @@
* Copyright (C) 2005 Stelian Pop (stelian@popies.net)
* Copyright (C) 2005 Frank Arnold (frank@scirocco-5v-turbo.de)
* Copyright (C) 2005 Peter Osterlund (petero2@telia.com)
+ * Copyright (C) 2005 Parag Warudkar (parag.warudkar@gmail.com)
+ * Copyright (C) 2005 Michael hanselmann (linux-kernel@hansmi.ch)
*
* Thanks to Alex Harper <basilisk@foobox.net> for his inputs.
*
+ * Nov 2005 - Parag Warudkar
+ * o Added ability to export data via relayfs
+ *
+ * Nov 2005 - Michael Hanselmann
+ * o Compile relayfs support only if enabled in the kernel
+ * o Enable relayfs only if requested by the user
+ * o Added support for new October 2005 PowerBooks (0x0215)
+ *
* 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
@@ -35,6 +45,10 @@
#include <linux/input.h>
#include <linux/usb_input.h>
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+#include <linux/relayfs_fs.h>
+#endif
+
/* Apple has powerbooks which have the keyboard with different Product IDs */
#define APPLE_VENDOR_ID 0x05AC
@@ -51,14 +65,17 @@
static struct usb_device_id atp_table [] = {
{ ATP_DEVICE(0x020E) },
{ ATP_DEVICE(0x020F) },
+ { ATP_DEVICE(0x0215) }, /* PowerBook 1.67 GHz, Oct 2005, PowerBook5,8 */
{ ATP_DEVICE(0x030A) },
{ ATP_DEVICE(0x030B) },
{ } /* Terminating entry */
};
MODULE_DEVICE_TABLE (usb, atp_table);
-/* size of a USB urb transfer */
-#define ATP_DATASIZE 81
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+struct rchan* rch = NULL;
+struct rchan_callbacks* rcb = NULL;
+#endif
/*
* number of sensors. Note that only 16 instead of 26 X (horizontal)
@@ -108,6 +125,9 @@
signed char xy_old[ATP_XSENSORS + ATP_YSENSORS];
/* accumulated sensors */
int xy_acc[ATP_XSENSORS + ATP_YSENSORS];
+ int is0215; /* is the device a 0x0215? */
+ int overflowwarn; /* overflow warning printed? */
+ int datalen; /* size of a USB urb transfer */
};
#define dbg_dump(msg, tab) \
@@ -132,6 +152,10 @@
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, "Activate debugging output");
+static int relayfs = 0;
+module_param(relayfs, int, 0644);
+MODULE_PARM_DESC(relayfs, "Activate relayfs support");
+
static int atp_calculate_abs(int *xy_sensors, int nb_sensors, int fact,
int *z, int *fingers)
{
@@ -175,6 +199,13 @@
case 0:
/* success */
break;
+ case -EOVERFLOW:
+ if(!dev->overflowwarn) {
+ printk("appletouch: OVERFLOW with data "
+ "length %d, actual length is %d\n",
+ dev->datalen, dev->urb->actual_length);
+ dev->overflowwarn = 1;
+ }
case -ECONNRESET:
case -ENOENT:
case -ESHUTDOWN:
@@ -189,23 +220,84 @@
}
/* drop incomplete datasets */
- if (dev->urb->actual_length != ATP_DATASIZE) {
+ if (dev->urb->actual_length != dev->datalen) {
dprintk("appletouch: incomplete data package.\n");
goto exit;
}
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+ if (relayfs && dev->data) {
+ relay_write(rch, dev->data, dev->urb->actual_length);
+ }
+#endif
+
/* reorder the sensors values */
- for (i = 0; i < 8; i++) {
- /* X values */
- dev->xy_cur[i ] = dev->data[5 * i + 2];
- dev->xy_cur[i + 8] = dev->data[5 * i + 4];
- dev->xy_cur[i + 16] = dev->data[5 * i + 42];
- if (i < 2)
- dev->xy_cur[i + 24] = dev->data[5 * i + 44];
-
- /* Y values */
- dev->xy_cur[i + 26] = dev->data[5 * i + 1];
- dev->xy_cur[i + 34] = dev->data[5 * i + 3];
+ if (dev->is0215) {
+ memset(dev->xy_cur, 0, sizeof(dev->xy_cur));
+
+ // Read the X values
+ i = 0;
+ dev->xy_cur[i++] = dev->data[19];
+ dev->xy_cur[i++] = dev->data[20];
+ dev->xy_cur[i++] = dev->data[22];
+ dev->xy_cur[i++] = dev->data[23];
+ dev->xy_cur[i++] = dev->data[25];
+ dev->xy_cur[i++] = dev->data[26];
+ dev->xy_cur[i++] = dev->data[28];
+ dev->xy_cur[i++] = dev->data[29];
+ dev->xy_cur[i++] = dev->data[31];
+ dev->xy_cur[i++] = dev->data[32];
+ dev->xy_cur[i++] = dev->data[34];
+ dev->xy_cur[i++] = dev->data[35];
+ dev->xy_cur[i++] = dev->data[37];
+ dev->xy_cur[i++] = dev->data[38];
+ dev->xy_cur[i++] = dev->data[40];
+
+ // Read the Y values
+ i = ATP_XSENSORS;
+ dev->xy_cur[i++] = dev->data[1];
+ dev->xy_cur[i++] = dev->data[2];
+ dev->xy_cur[i++] = dev->data[4];
+ dev->xy_cur[i++] = dev->data[5];
+ dev->xy_cur[i++] = dev->data[7];
+ dev->xy_cur[i++] = dev->data[8];
+ dev->xy_cur[i++] = dev->data[10];
+ dev->xy_cur[i++] = dev->data[11];
+ dev->xy_cur[i++] = dev->data[13];
+
+#if 0
+ /* Some debug code */
+ for (i = 0; i < dev->urb->actual_length; i++) {
+ printk("%2x,", (unsigned char)dev->data[i]);
+ }
+ printk("\n");
+#endif
+
+ /* Prints the read values */
+ if (debug > 1) {
+ printk("appletouch: X=");
+ for (i = 0; i < 15; i++) {
+ printk("%2x,", (unsigned char)dev->xy_cur[i]);
+ }
+ printk(" Y=");
+ for (i = ATP_XSENSORS; i < (ATP_XSENSORS + (9 - 1)); i++) {
+ printk("%2x,", (unsigned char)dev->xy_cur[i]);
+ }
+ printk("\n");
+ }
+ } else {
+ for (i = 0; i < 8; i++) {
+ /* X values */
+ dev->xy_cur[i ] = dev->data[5 * i + 2];
+ dev->xy_cur[i + 8] = dev->data[5 * i + 4];
+ dev->xy_cur[i + 16] = dev->data[5 * i + 42];
+ if (i < 2)
+ dev->xy_cur[i + 24] = dev->data[5 * i + 44];
+
+ /* Y values */
+ dev->xy_cur[i + 26] = dev->data[5 * i + 1];
+ dev->xy_cur[i + 34] = dev->data[5 * i + 3];
+ }
}
dbg_dump("sample", dev->xy_cur);
@@ -216,16 +308,18 @@
dev->x_old = dev->y_old = -1;
memcpy(dev->xy_old, dev->xy_cur, sizeof(dev->xy_old));
- /* 17" Powerbooks have 10 extra X sensors */
- for (i = 16; i < ATP_XSENSORS; i++)
- if (dev->xy_cur[i]) {
- printk("appletouch: 17\" model detected.\n");
- input_set_abs_params(dev->input, ABS_X, 0,
- (ATP_XSENSORS - 1) *
- ATP_XFACT - 1,
- ATP_FUZZ, 0);
- break;
- }
+ if (!dev->is0215) {
+ /* 17" Powerbooks have 10 extra X sensors */
+ for (i = 16; i < ATP_XSENSORS; i++)
+ if (dev->xy_cur[i]) {
+ printk("appletouch: 17\" model detected.\n");
+ input_set_abs_params(dev->input, ABS_X, 0,
+ (ATP_XSENSORS - 1) *
+ ATP_XFACT - 1,
+ ATP_FUZZ, 0);
+ break;
+ }
+ }
goto exit;
}
@@ -323,7 +417,6 @@
int int_in_endpointAddr = 0;
int i, retval = -ENOMEM;
-
/* set up the endpoint information */
/* use only the first interrupt-in endpoint */
iface_desc = iface->cur_altsetting;
@@ -335,6 +428,8 @@
== USB_ENDPOINT_XFER_INT)) {
/* we found an interrupt in endpoint */
int_in_endpointAddr = endpoint->bEndpointAddress;
+ printk(KERN_INFO "appletouch: atp_probe found interrupt "
+ "in endpoint: %d\n", int_in_endpointAddr);
break;
}
}
@@ -353,6 +448,13 @@
dev->udev = udev;
dev->input = input_dev;
+ dev->is0215 = (le16_to_cpu(dev->udev->descriptor.idProduct) == 0x0215);
+ dev->overflowwarn = 0;
+ if (dev->is0215) {
+ dev->datalen = 64;
+ } else {
+ dev->datalen = 81;
+ }
dev->urb = usb_alloc_urb(0, GFP_KERNEL);
if (!dev->urb) {
@@ -360,7 +462,7 @@
goto err_free_devs;
}
- dev->data = usb_buffer_alloc(dev->udev, ATP_DATASIZE, GFP_KERNEL,
+ dev->data = usb_buffer_alloc(dev->udev, dev->datalen, GFP_KERNEL,
&dev->urb->transfer_dma);
if (!dev->data) {
retval = -ENOMEM;
@@ -369,7 +471,7 @@
usb_fill_int_urb(dev->urb, udev,
usb_rcvintpipe(udev, int_in_endpointAddr),
- dev->data, ATP_DATASIZE, atp_complete, dev, 1);
+ dev->data, dev->datalen, atp_complete, dev, 1);
usb_make_path(udev, dev->phys, sizeof(dev->phys));
strlcat(dev->phys, "/input0", sizeof(dev->phys));
@@ -385,14 +487,21 @@
set_bit(EV_ABS, input_dev->evbit);
- /*
- * 12" and 15" Powerbooks only have 16 x sensors,
- * 17" models are detected later.
- */
- input_set_abs_params(input_dev, ABS_X, 0,
- (16 - 1) * ATP_XFACT - 1, ATP_FUZZ, 0);
- input_set_abs_params(input_dev, ABS_Y, 0,
- (ATP_YSENSORS - 1) * ATP_YFACT - 1, ATP_FUZZ, 0);
+ if (dev->is0215) {
+ input_set_abs_params(input_dev, ABS_X, 0,
+ ((15 - 1) * ATP_XFACT) - 1, ATP_FUZZ, 0);
+ input_set_abs_params(input_dev, ABS_Y, 0,
+ ((9 - 1) * ATP_YFACT) - 1, ATP_FUZZ, 0);
+ } else {
+ /*
+ * 12" and 15" Powerbooks only have 16 x sensors,
+ * 17" models are detected later.
+ */
+ input_set_abs_params(input_dev, ABS_X, 0,
+ (16 - 1) * ATP_XFACT - 1, ATP_FUZZ, 0);
+ input_set_abs_params(input_dev, ABS_Y, 0,
+ (ATP_YSENSORS - 1) * ATP_YFACT - 1, ATP_FUZZ, 0);
+ }
input_set_abs_params(input_dev, ABS_PRESSURE, 0, ATP_PRESSURE, 0, 0);
set_bit(EV_KEY, input_dev->evbit);
@@ -427,7 +536,7 @@
usb_kill_urb(dev->urb);
input_unregister_device(dev->input);
usb_free_urb(dev->urb);
- usb_buffer_free(dev->udev, ATP_DATASIZE,
+ usb_buffer_free(dev->udev, dev->datalen,
dev->data, dev->urb->transfer_dma);
kfree(dev);
}
@@ -463,11 +572,30 @@
static int __init atp_init(void)
{
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+ if (relayfs) {
+ rcb = kmalloc(sizeof(struct rchan_callbacks), GFP_KERNEL);
+ rcb->subbuf_start = NULL;
+ rcb->buf_mapped = NULL;
+ rcb->buf_unmapped = NULL;
+ rch = relay_open("atpdata", NULL, 256, 256, NULL);
+ if (!rch) return -ENOMEM;
+ printk("appletouch: Relayfs enabled.\n");
+ } else {
+ printk("appletouch: Relayfs disabled.\n");
+ }
+#endif
return usb_register(&atp_driver);
}
static void __exit atp_exit(void)
{
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+ if (relayfs) {
+ relay_close(rch);
+ kfree(rcb);
+ }
+#endif
usb_deregister(&atp_driver);
}
^ permalink raw reply
* RE: Booting hangs after "Calibrating delay loop..."
From: Autran, Guillaume @ 2005-11-30 21:58 UTC (permalink / raw)
To: 'n_tbinh@yahoo.com '; +Cc: 'linuxppc-embedded@ozlabs.org '
Hi Binh Nguyen,
m8xx_setup.c moved in the recent 2.6 kernels to the syslib directory. I am
using the 2.6.14 and the external RTC works with the modification I gave
you.
The only other thing different is the initialization of the stamp variable
in time.c
I added the line: 'stamp = get_native_tbl();' right before
'last_jiffy_stamp(0) = tb_last_stamp = stamp;'
That's all.
Guillaume
^ permalink raw reply
* user thread will occassionally get a mysterious floating point exception
From: Joe Birch @ 2005-11-30 22:02 UTC (permalink / raw)
To: Linuxppc-embedded
user thread cores occassionally because of a floating
point exception
when the exception occurs it usually happens on
multiple threads, even across different processes
and they all have the same fpscr values.
As far as I can tell none of the applications are even
enabling the fp exceptions in the fpscr.
If fact the coredump shows the fp operation to be just
a 64bit move like lfd.
some details:
2.4.20 (I know i have to go to 2.6 i just can't
right now)
~300 threads
cpu : 8270
core clock : 450 MHz
CPM clock : 300 MHz
bus clock : 100 MHz
revision : 32.19 (pvr 8082 2013)
bogomips : 299.82
The various fpscr that have occurred:
0x6002c2ed 0110 0000 0000 0010 1100 0010 1110 1101
0xec1642e6 1110 1100 0001 0110 0100 0010 1110 0110
0x7649e0ea 0111 0110 0100 1001 1110 0000 1110 1010
0x6009c7ba 0110 0000 0000 1001 1100 0111 1011 1010
0xf30c346f 1111 0011 0000 1100 0011 0100 0110 1111
0xe833f39d 1110 1000 0011 0011 1111 0011 1001 1101
0xfdb3e1e3 1111 1101 1011 0011 1110 0001 1110 0011
I've put in debug to dump the thread_struct when the
exception occurs hoping to find a corruption of the
floating point registers but they look OK.
Any help is greatly appreciated
Joe
^ permalink raw reply
* Re: [PATCH 2/3] ppc32: PCIX support for Yucca board
From: Roland Dreier @ 2005-11-30 18:11 UTC (permalink / raw)
To: Ruslan V. Sushko; +Cc: linuxppc-embedded
In-Reply-To: <1132763369.31328.22.camel@mephisto.spb.rtsoft.ru>
Again, looks pretty good, but I would like to see the whitespace fixes
separated from adding PCI-X support.
- R.
^ permalink raw reply
* Re: [PATCH 1/3] ppc32: Fix a few issues in Yucca PCIe functionality
From: Roland Dreier @ 2005-11-30 18:09 UTC (permalink / raw)
To: Ruslan V. Sushko; +Cc: linuxppc-embedded
In-Reply-To: <1132763364.31328.21.camel@mephisto.spb.rtsoft.ru>
This looks OK, although I would prefer to see this split into a few
patches, for example, first kill off dead code, then add more error
checking, and so on.
Also, one question/comment:
> @@ -335,44 +337,47 @@ int ppc440spe_init_pcie_rootport(int por
> /*
> * Check for VC0 active and assert RDY.
> */
> +
> + attempts = 10;
> switch (port) {
> case 0:
> - if (!(SDR_READ(PESDR0_RCSSTS) & (1 << 16)))
> - printk(KERN_WARNING "PCIE0: VC0 not active\n");
> + while(!(SDR_READ(PESDR0_RCSSTS) & (1 << 16))) {
> + if (!(attempts--)) {
> + printk(KERN_WARNING "PCIE0: VC0 not active\n");
> + return -1;
> + }
> + mdelay(1000);
> + }
> SDR_WRITE(PESDR0_RCSSET, SDR_READ(PESDR0_RCSSET) | 1 << 20);
what lead you to add 10 tries here? Did this fix an issue you saw
with a device?
- R.
^ permalink raw reply
* RE: [PATCH 2.6.14] mm: 8xx MM fix for
From: Joakim Tjernlund @ 2005-11-30 17:34 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Tom Rini, Dan Malek, gtolstolytkin, linuxppc-embedded
>=20
> On Mon, Nov 07, 2005 at 07:37:45PM +0100, Joakim Tjernlund wrote:
> > >=20
> > > On Mon, Nov 07, 2005 at 07:14:15PM +0100, Joakim Tjernlund wrote:
> > > > > -----Original Message-----
> > > > > From: Tom Rini [mailto:trini@kernel.crashing.org]=20
> > > > > Sent: 07 November 2005 16:52
> > > > > To: Marcelo Tosatti
> > > > > Cc: Joakim Tjernlund; Pantelis Antoniou; Dan Malek;=20
> > > > > linuxppc-embedded@ozlabs.org; gtolstolytkin@ru.mvista.com
> > > > > Subject: Re: [PATCH 2.6.14] mm: 8xx MM fix for
> > > > >=20
> > > > > On Mon, Nov 07, 2005 at 08:16:18AM -0200, Marcelo=20
> Tosatti wrote:
> > > > > > Joakim!
> > > > > >=20
> > > > > > On Mon, Nov 07, 2005 at 03:32:52PM +0100, Joakim=20
> > > Tjernlund wrote:
> > > > > > > Hi Marcelo
> > > > > > >=20
> > > > > > > [SNIP]=20
> > > > > > > > The root of the problem are the changes against=20
> the 8xx TLB=20
> > > > > > > > handlers introduced
> > > > > > > > during v2.6. What happens is the TLBMiss=20
> handlers load the=20
> > > > > > > > zeroed pte into
> > > > > > > > the TLB, causing the TLBError handler to be=20
> invoked (thats=20
> > > > > > > > two TLB faults per=20
> > > > > > > > pagefault), which then jumps to the generic MM code to=20
> > > > > setup the pte.
> > > > > > > >=20
> > > > > > > > The bug is that the zeroed TLB is not invalidated (the=20
> > > > > same reason
> > > > > > > > for the "dcbst" misbehaviour), resulting in infinite=20
> > > > > TLBError faults.
> > > > > > > >=20
> > > > > > > > Dan, I wonder why we just don't go back to v2.4=20
> behaviour.
> > > > > > >=20
> > > > > > > This is one reason why it is the way it is:
> > > > > > >=20
> > > > >=20
> > >=20
> http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016382.html
> > > > > > > This details are little fuzzy ATM, but I think the=20
> > > reason for the
> > > > > > > current
> > > > > > > impl. was only that it was less intrusive to impl.
> > > > > >=20
> > > > > > Ah, I see. I wonder if the bug is processor specific: we=20
> > > > > don't have such
> > > > > > changes in our v2.4 tree and never experienced such problem.
> > > > > >=20
> > > > > > It should be pretty easy to hit it right? (instruction=20
> > > > > pagefaults should
> > > > > > fail).
> > > > > >=20
> > > > > > Grigori, Tom, can you enlight us about the issue on the URL=20
> > > > > above. How
> > > > > > can it be triggered?
> > > > >=20
> > > > > So after looking at the code in 2.6.14 and current git, I=20
> > > think the
> > > > > above URL isn't relevant, unless there was a change I=20
> > > missed (which
> > > > > could totally be possible) that reverted the patch there and=20
> > > > > fixed that
> > > > > issue in a different manner. But since I didn't figure that=20
> > > > > out until I
> > > > > had finished researching it again:
> > > >=20
> > > > I wasn't clear enough. What I meant was that the above=20
> patch made me
> > > > think and
> > > > the result was that I came up with a simpler fix, the "two=20
> > > exception"
> > > > fix that
> > > > is in current kernels. See
> > > >=20
> > >
http://linux.bkbits.net:8080/linux-2.6/diffs/arch/ppc/kernel/head_8xx.S@
> > > >=20
> > > 1.19?nav=3Dindex.html|src/.|src/arch|src/arch/ppc|src/arch/ppc/k
> > > ernel|hist
> > > > /arch/ppc/kernel/head_8xx.S
> > > > It appears this fix has some other issues :(
> > > >=20
> > > > How do the other ppc arches do? I am guessing that they=20
> don't double
> > > > fault, but bails
> > > > out to do_page_fault from the TLB Miss handler, like=20
> 8xx used to do.
> > >=20
> > > Assuming Dan doesn't come up with a more simple & better=20
> fix, maybe we
> > > should go back to the original patch I made?
> >=20
> > That was what I was thinking too(or some variation of your patch)
> > I wonder if that would solve the misbehaving dcbst problem=20
> Marcelo found
> > some time ago too?
>=20
> Hi Joakim,
>=20
> Yes, it would fix the "dcbst" issue. That problem was triggered by a
> zeroed TLB entry.
>=20
> In practice it seems that the "three exception" approach does=20
> not impose
> a significant overhead in comparison with the "two exception" version
> (as can be seen by the results of the latency tests).
>=20
> Anyway, if decided upon, the "two exception" version (no zeroed TLB
> entry state) needs the TLBMiss handler should to the present=20
> bit as Dan
> mentioned.
>=20
> I don't know what Dan is up to, he meant to be doing=20
> significant changes.
Dan, any progress?
>=20
> I'll be playing with TLB preloading next week... how's your=20
> TLB handler
> shrinkage idea?
Well, here is a first step.
This patch will save 2 instructions in the hot path and removes the need
to save=20
registers around address 0 in the ITLB Miss handler IFF you use pinned
TLBs and no modules.
What do you think?
Jocke
--- head_8xx.S.org Wed Nov 30 16:38:30 2005
+++ head_8xx.S Wed Nov 30 18:19:16 2005
@@ -300,14 +300,17 @@
#endif
DO_8xx_CPU6(0x3f80, r3)
mtspr SPRN_M_TW, r10 /* Save a couple of working registers */
+#if !CONFIG_PIN_TLB || CONFIG_MODULES
mfcr r10
stw r10, 0(r0)
- stw r11, 4(r0)
+#endif
+ mtspr SPRN_SPRG2, r11 /* Save a couple of working registers */
mfspr r10, SPRN_SRR0 /* Get effective address of fault */
DO_8xx_CPU6(0x3780, r3)
mtspr SPRN_MD_EPN, r10 /* Have to use MD_EPN for walk,
MI_EPN can't */
mfspr r10, SPRN_M_TWB /* Get level 1 table entry address */
=20
+#if !CONFIG_PIN_TLB || CONFIG_MODULES
/* If we are faulting a kernel address, we have to use the
* kernel page tables.
*/
@@ -319,12 +322,19 @@
3:
lwz r11, 0(r10) /* Get the level 1 entry */
rlwinm. r10, r11,0,0,19 /* Extract page descriptor page address
*/
- beq 2f /* If zero, don't try to find a pte */
-
+ ori r11,r11,1 /* Set valid bit */
+ beq- 2f /* If zero, don't try to find a pte */
+#else
+ lwz r11, 0(r10) /* Get the level 1 entry */
+ mfcr r10 /* Save CR */
+ cmplwi cr0,r11,0x0fff /* Test page descriptor page address */
+ ori r11,r11,1 /* Set valid bit */
+ bng- 3f /* If zero, don't try to find a pte */
+ mtcr r10 /* Restore CR */
+#endif
/* We have a pte table, so load the MI_TWC with the attributes
* for this "segment."
*/
- ori r11,r11,1 /* Set valid bit */
DO_8xx_CPU6(0x2b80, r3)
mtspr SPRN_MI_TWC, r11 /* Set segment attributes */
DO_8xx_CPU6(0x3b80, r3)
@@ -347,13 +357,19 @@
mtspr SPRN_MI_RPN, r10 /* Update TLB entry */
=20
mfspr r10, SPRN_M_TW /* Restore registers */
+#if !CONFIG_PIN_TLB || CONFIG_MODULES
lwz r11, 0(r0)
mtcr r11
- lwz r11, 4(r0)
+#endif
+ mfspr r11, SPRN_SPRG2 /* Restore registers */
#ifdef CONFIG_8xx_CPU6
lwz r3, 8(r0)
#endif
rfi
+#if !CONFIG_PIN_TLB || CONFIG_MODULES
+3: mtcr r10
+ ba 2b
+#endif
=20
. =3D 0x1200
DataStoreTLBMiss:
^ permalink raw reply
* Xilinx_uartlite
From: Jaap de Jong @ 2005-11-30 14:24 UTC (permalink / raw)
To: linuxppc-embedded
Hi
I'm trying to get my avnet virtex4fx12 running with linux.
It boots, but ends with:=09
Warning: unable to open an initial console.
This means /dev/console was not opened; init is running.
Since my board has no 16550 uart I must use xilinx_uartlite
Part of my configuration:
+--Character devices
+--Xilinx UART Lite ON
+--Console on UART Lite port ON
Any ideas?
Thanks in advance!
Jaap de Jong
^ permalink raw reply
* Re: [RFC] add PHY support to AM79C874
From: Aristeu Sergio Rozanski Filho @ 2005-11-30 13:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <46ED525E-5C26-4311-87DE-FE55AE8DE0F0@kernel.crashing.org>
> I would suggest sending this to the netdev list for review and
> acceptance.
ok! sending it now, thanks Kumar
--
Aristeu
^ permalink raw reply
* ATI Radeon M6-C16H for PPC 440GX
From: Bashier Machmur @ 2005-11-30 12:55 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 334 bytes --]
Hello,
i'm using on my custom board (PPC 440GX) a ATI M6-C16H Mobility Radeon video
card. I work with U-boot and linux kernel 2.6.12 and installed the driver
"radeonfb". Now I don't have the BIOS of ATI for PPC to support it.
How can I configure the U-boot for ATI to initialize this video card?
Thanks for any help,
Bashier
[-- Attachment #2: Type: text/html, Size: 1440 bytes --]
^ permalink raw reply
* Require info regarding the flow of uart driver in linux for mpc8260
From: s.maiti @ 2005-11-30 8:30 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20051130010005.3E86868862@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 997 bytes --]
Hi,
I am a fresher in device driver development. Currently I am involve in
developing the uart driver in linux for a custom board of mpc8260. I am
confused about tty and console in the code uart.c . I will be very
grateful if any one can clear my confusion.
Thanks in advance,
Souvik Maiti
Tata Consultancy Sevices Limited
Bengal Intelligent Park
Bldg. - D, Plots - A2, M2 & N2
Block - GP, Sector - V
Saltlake Electronics Complex
Kolkata - 700091, West Bengal
India
Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you
[-- Attachment #2: Type: text/html, Size: 1300 bytes --]
^ permalink raw reply
* Re: PowerBook5,8 - TrackPad update
From: Johannes Berg @ 2005-11-30 11:17 UTC (permalink / raw)
To: Parag Warudkar; +Cc: linuxppc-dev, debian-powerpc, linux-kernel
In-Reply-To: <2100B419-3498-4BAF-8186-3EC06A917DF6@comcast.net>
Parag Warudkar wrote:
> Hopefully Johannes will have a PowerBook with either of the 0x0214 or
> 0x0215 touchpads and we will make some headway!
If anyone is in the area of Paderborn (Germany) who has such a touchpad,
it may be faster if I just look at that one :) If not, well, we can sort
of hope that the one my brother's ordering will have that touchpad.
johannes
^ permalink raw reply
* Re: Is there some articles discussing how to change bare-board code to linux driver?
From: Andrei Konovalov @ 2005-11-30 10:04 UTC (permalink / raw)
To: David H. Lynch Jr; +Cc: T Ziomek, linuxppc-embedded
In-Reply-To: <438D0878.30503@comcast.net>
David H. Lynch Jr wrote:
> Where can I find the ./drivers/net/xilinx_enet, ... etc files.
> I can not find them in the 2.6.14.2 tree
They are in the linuxppc-2.4 tree. Try
rsync -avz --delete source.mvista.com::linuxppc-2.4 <directory>
-- Andrei
> T Ziomek wrote:
>
>>> Where can i find them?thanks.
>>
>>
>> In addition to LDD3 (for 2.6 kernels, or the freely available LDD2 for
>> 2.4 kernels), you might want to look at some existing Linux drivers
>> that are
>> based on "bare metal" / "no OS" drivers. The ones I know of are for
>> Xilinx
>> peripherals, for example (within the Linux kernel tree),
>> - ./drivers/net/xilinx_enet
>> - ./drivers/char/xilinx_uartlite
>> - ./drivers/char/xilinx_gpio
>>
>> Tom
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Setting IDE mode to PIO for compact flash
From: Gregg Nemas @ 2005-11-30 10:12 UTC (permalink / raw)
To: linuxppc-embedded
I have a compact flash connected to a PPC440GP processor in "true IDE"
mode. The DMA signals are not connected, so the device must be used in
PIO mode.
However, when I issue hdparm -i, it indicates that the current mode is
DMA mode mdma2, and I think this must be why I am getting "lost
interrupt" messages. Unfortunately, when I try to set the mode to PIO
using "hdparm -p1" or "hdparm -X9", it seems to have no effect.
What do I need to do to get the drive to be set to use PIO?
I amusing linux 2.6.12.3.
Thanks.
Gregg
^ permalink raw reply
* RE: linuxppc-embedded help needed:kernel access of bad area
From: Fillod Stephane @ 2005-11-30 9:33 UTC (permalink / raw)
To: zengshuai, ppc
Dear zengshuai,
zengshuai@sogou.com wrote:
> i writed a led driver for PQ2FADS(a ppc board).
> but i can't read/write 0x04500000 where led register addr locate in.
> i tested two ways to do that.
> first,
> p=3D0x04500000;
> *p=3D0x12;
> ....
> second,
> outb(0x12,0x04500000);
> ...
> two ways both didn't work.they had a some wrong:kernel access of bad
area.
> how can i know which area is bad area or good area?
> and what can i do next? thanks.
Do yourself a favor, read a book about Linux device driver development,
for example one listed[1] in the excellent Denx's DLUG FAQ[2].
Getting some training on PowerPC development is a good idea too.
[1] http://www.denx.de/wiki/view/DULG/MoreInformationBooks
[2] http://www.denx.de/wiki/DULG/Manual
Peruse also your chip data-sheet, and you will see that outb() is
non-sense.
If you are accessing the led register from kernel space, you'll find
a solution using ioremap(). Otherwise, if you are accessing the led
register
from user space, this link[3] will help you, or this shorter one[4].
You can follow this thread[5] for more information.
[3]
http://www.denx.de/twiki/bin/view/PPCEmbedded/DeviceDrivers#Section_Acce
ssingPeripheralsFromUserSpace
[4] http://tinyurl.com/6c7th
[5] http://lists.linuxppc.org/linuxppc-embedded/200403/msg00059.html
Please next time, do ourselves a favor, try some searching first
(google,=20
whatever). Your question is a FAQ.
Regards,
--=20
Stephane
^ permalink raw reply
* Re:linuxppc-embedded help needed:kernel access of bad area
From: zengshuai @ 2005-11-30 9:01 UTC (permalink / raw)
To: Linuxppc-embedded
detail:
---------------------------------------------------------------------------------
# ls
led-app.exe led-module.o
# ./led-app.exe
open led-app.exe...OK!
Oops: kernel access of bad area, sig: 11
NIP: C30B11B4 XER: 00000000 LR: C003A310 SP: C06B1F00 REGS: c06b1e50 TRAP: 0300
Not tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 04500000, DSISR: 20000000
TASK = c06b0000[201] 'led-app.exe' Last syscall: 3
last math c06b0000 last altivec 00000000
GPR00: C003A310 C06B1F00 C06B0000 C01A5AA0 7FFFFDE0 00000014 C01A5AC0 00000000
GPR08: 00000000 04500000 0000000C C01A0000 30025CE8 10018B5C 00000000 00000000
GPR16: 00000000 00000000 00000000 00000000 00009032 006B1F40 00000000 C0003E88
GPR24: C0003BE0 00000001 10000500 7FFFFEA4 7FFFFDE0 FFFFFFEA C01A5AA0 00000014
Call backtrace:
10000A1C C003A310 C0003C3C 100004AC 0FEC6D74 00000000
Segmentation fault
#
----------------------------------------------------------------------------------
> -------------------
> From: zengshuai@sogou.com
> To: ppc
> Subject: linuxppc-embedded help needed:kernel access of bad area
> Sent: Wed Nov 30 16:18:06 CST 2005
>
> > i writed a led driver for PQ2FADS(a ppc board).
> > but i can't read/write 0x04500000 where led register addr locate in.
> > i tested two ways to do that.
> > first,
> > p=0x04500000;
> > *p=0x12;
> > ....
> > second,
> > outb(0x12,0x04500000);
> > ...
> > two ways both didn't work.they had a some wrong:kernel access of bad area.
> > how can i know which area is bad area or good area?
> > and what can i do next? thanks.
> >
> > ------------------------------
> > 我现在使用Sogou.com的2G邮箱了，你也来试试吧!
> > http://mail.sogou.com/recommend/sogoumail_invite_reg1.jsp?from=sogouinvitation&s_EMAIL=zengshuai%40sogou.com&username=linuxppc-embedded&FullName=linuxppc-embedded&Email=linuxppc-embedded%40ozlabs.org&verify=755eff4e640bdcfc57d93cbd8b0a9cb7
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
> ------------------------------
> 我现在使用Sogou.com的2G邮箱了，你也来试试吧!
> http://mail.sogou.com/recommend/sogoumail_invite_reg1.jsp?from=sogouinvitation&s_EMAIL=zengshuai%40sogou.com&username=zengshuai&FullName=zengshuai&Email=zengshuai%40sogou.com&verify=9cab69a60842dbdbc5ad49cbd78e2e11
------------------------------
我现在使用Sogou.com的2G邮箱了，你也来试试吧!
http://mail.sogou.com/recommend/sogoumail_invite_reg1.jsp?from=sogouinvitation&s_EMAIL=zengshuai%40sogou.com&username=Linuxppc-embedded&FullName=Linuxppc-embedded&Email=Linuxppc-embedded%40ozlabs.org&verify=777667b18eda2b5dd1bbd47542afad9b
^ permalink raw reply
* linuxppc-embedded help needed:kernel access of bad area
From: zengshuai @ 2005-11-30 8:18 UTC (permalink / raw)
To: ppc
i writed a led driver for PQ2FADS(a ppc board).
but i can't read/write 0x04500000 where led register addr locate in.
i tested two ways to do that.
first,
p=0x04500000;
*p=0x12;
....
second,
outb(0x12,0x04500000);
...
two ways both didn't work.they had a some wrong:kernel access of bad area.
how can i know which area is bad area or good area?
and what can i do next? thanks.
------------------------------
我现在使用Sogou.com的2G邮箱了，你也来试试吧!
http://mail.sogou.com/recommend/sogoumail_invite_reg1.jsp?from=sogouinvitation&s_EMAIL=zengshuai%40sogou.com&username=linuxppc-embedded&FullName=linuxppc-embedded&Email=linuxppc-embedded%40ozlabs.org&verify=755eff4e640bdcfc57d93cbd8b0a9cb7
^ permalink raw reply
* Re: immap with 8xx.
From: Ingo Hornberger @ 2005-11-30 7:59 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-devel list
In-Reply-To: <f3e079332f2f66cb1898b288cf66e5c9@embeddededge.com>
Thanks Dan for your reply!
I mainly needed the immap stuff like 'immap_rp_t' and some 'defines'.
But I just started to reorder this. I thought that 'cpm1' and 'cpm2'
devices should follow the same unique scheme, shouldn't they? Even if we
only have one cpm1 device.
Otherwise the naming is very confusing.
For example:
(8xx) (cpm2)
commproc.h cpm2.h
8xx_immap.h immap_cpm2.h
immap_t cpm2_map_t
iop8xx_t iop_cpm2_t
... ...
And because the cpm2 scheme is newer and cleaner, I think we should use
that instead.
This change would mainly rename the following files (and their symbols):
8xx_immap.h -> immap_cpm1.h
commproc.h -> cpm1.h
(but likely affect others, too)
Then we would need three patches:
1. rename the files
2. patch only the 'include/asm' files
3. rename all "#include" directives and symbols in the rest.
Or do you see too much problems in renaming such symbols? Perhaps this
should be a topic for the development kernel, but I don't think so...
I think we should do this now, because it's only relevant for low-level
8xx code (and drivers like mine or the ide driver). The init code could
be converted by us, and as the 8xx port of 2.6 isn't such old and stable
I believe that there are not too much (if none) already ported drivers
around that are using low-level 8xx stuff.
But I'd like to here more opinions.
regards,
Ingo
On Tue, 2005-11-29 at 13:13 -0500, Dan Malek wrote:
> On Nov 29, 2005, at 9:39 AM, Ingo Hornberger wrote:
>
> > But it seems that there was some generalization work done, which didn't
> > reach the 8xx part. Particularly this means that some parts of
> > 'asm/commproc.h' as well as (at least) 'asm/immap_8260.h' built up a
> > new
> > header 'asm/immap_cpm2.h'.
>
> That's because the cpm2 is used in more parts than just the 82xx,
> so we carved up the files to make it more useful.
>
> > Actally I miss a file like 'asm/immap_cpm1.h'.
>
> The 8xx is the only processor to use the CPM1, so just update
> the immap or 8xx files to accommodate the differences you may
> need. There isn't a similar requirement to create a immap_cpm1.h
> file like there was for the CPM2. What kind of updates do you need?
>
> Thanks.
>
> -- Dan
>
^ permalink raw reply
* Re: Kernel 2.6 support for MVME5500?
From: Gerhard Jaeger @ 2005-11-30 7:22 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1133296311.8749.9.camel@kokopelli.npt.nuwc.navy.mil>
Hi,
On Tuesday 29 November 2005 21:31, Henry A. Leinhos wrote:
> Hi,
>
> Does anyone have any information regarding support for the Motorola
> MVME5500 SBC under kernel 2.6.x? Motorola has 2.4.x patches on their
> website, but I can't seem to find anything for 2.6.x.
>
I'm pretty sure, that Motorola has 2.6 patches available, the latest
one I saw was for 2.6.10 Kernel series. You might ask your local
Motorola representative.
Ciao,
Gerhard
--
Gerhard Jaeger <gjaeger@sysgo.com>
SYSGO AG Embedded and Real-Time Software
www.sysgo.com | www.elinos.com | www.pikeos.com | www.osek.de
^ permalink raw reply
* Re: MPC85xx i2c interface bug
From: Dan Wilson @ 2005-11-30 7:18 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.44.0511300013110.32230-100000@gate.crashing.org>
On 11/30/2005 at 12:14 AM Kumar Gala wrote:
> Dan,
>
> Did you see an issue this change fixed? If so can you provide more
> details. Also, can you provide your diff as a unified diff (diff -u) so
> its easier to see where the changes where.
>
> I'm trying to figure out if the same issue exists in the 2.6 driver (and
> if so, why we havent seen it)
>
> thanks
>
> - kumar
>
Yes, there was an issue that this change fixed. Our I2C bus has a number=
of devices on it. The first device is at address 0x2c, and is an Analog=
Device AD5173BRM50 software programmable 50K ohm resistor. We connected a=
logic analyzer to the device and watched the bus activity as linux booted=
and the i2c bus scan took place. During this scan, the 8541 attempts to=
address each device and then read a byte from the device. With the=
original code, the 8541 would reply to the byte read by sending a zero as=
the TXACK bit, which instructed the 5173 to send an additional byte, but=
the 8541 didn't attempt to retrieve that byte, since it was already moving=
on, trying to stop the bus and go on to the next device. The 5173=
appeared to not be able to see the stop command since it had received a=
command to transmit the next byte. The bus didn't seem to ever recover=
from this: if we allowed linux to complete it's boot and then told it to=
reboot, the u-boot code was no longer able to identify and configure the=
SDRAM, since it is also connected to the now non-functional I2C. With the=
new code, linux correctly identifies all of the devices on the I2C, boots=
quickly and cleanly, and after a reboot the u-boot code has no problem=
coming up again.
Here is the diff -u that you requested:
@@ -299,11 +299,11 @@
if(pm->flags & I2C_M_RD) {
/* Change to read mode */
- priv->write(®s->i2ccr, 0, MPC_I2CCR_MTX);
+ priv->write(®s->i2ccr, 0, MPC_I2CCR_MTX |=
MPC_I2CCR_TXAK);
/* If there is only one byte, we need to TXAK now */
if(len =3D=3D 1)
- priv->write(®s->i2ccr, 0, MPC_I2CCR_TXAK);
+ priv->write(®s->i2ccr, MPC_I2CCR_TXAK,=
MPC_I2CCR_TXAK);
/* Do a dummy read, to initiate the first read */
priv->read(®s->i2cdr);
@@ -321,7 +321,7 @@
/* If this is the 2nd to last byte, send
* the TXAK signal */
if(i =3D=3D len - 2) {
- priv->write(®s->i2ccr, 0,=
MPC_I2CCR_TXAK);
+ priv->write(®s->i2ccr, MPC_I2CCR_TXAK,=
MPC_I2CCR_TXAK);
}
/* If this is the last byte, send STOP */
@@ -383,7 +383,6 @@
priv->write(®s->i2csr, 0, MPC_I2CSR_MIF);
mpc_i2c_start(priv);
-
/* Send each message, chaining them together with repeat STARTs */
for(i =3D 0; i < num && !err; ++i) {
err =3D mpc_doAddress(priv, &msgs[i]);
Hope this helps,
Dan.
^ permalink raw reply
* Re: Support for S29GL512N in U-boot
From: Kumar Gala @ 2005-11-30 7:12 UTC (permalink / raw)
To: le tang; +Cc: linuxppc-embedded list
In-Reply-To: <20051130070059.28442.qmail@web50609.mail.yahoo.com>
On Nov 30, 2005, at 1:00 AM, le tang wrote:
> Hi all,
>
> My board has Flash memory type AMD, S29GL512N and
> CPU8541, and I found in the /include/flash.h in u-boot
> source, there is entry for flash memory S29GL064M-R6,
>
> How can I add the support for S29GL512N flash memory?
Please post such queries to the u-boot list.
- kumar
^ permalink raw reply
* Re: Trying to understand initsenses and pci_irq_table
From: Kumar Gala @ 2005-11-30 7:11 UTC (permalink / raw)
To: Richard Danter; +Cc: linuxppc-embedded
In-Reply-To: <438374FE.4040608@ntlworld.com>
On Nov 22, 2005, at 1:43 PM, Richard Danter wrote:
> Richard Danter wrote:
>> The kernel crashes after starting init. I see some random
>> characters on the serial and then nothing. Looking in the log
>> buffer via JTAG I can see that the init process exited with signal
>> 11. I assume this is unrelated to the above, but any suggestions
>> where I should look?
>
> I managed to fix this problem, so I am now booted and running
> busybox from NFS :)
>
> I'd still like a pointer to any docs explaining the PCI and
> interrupt stuff if possible.
Well the PCI SIG has specs. If your talking about the code, its a
simple lookup table. The key is realizing that PCI_IRQ_TABLE_LOOKUP
is a macro.
- kumar
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox