* Re: [PATCH/RFC?] usb/input: Add support for fn key on Apple PowerBooks
From: Michael Hanselmann @ 2006-01-11 21:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-kernel, dtor_core, linux-kernel, linuxppc-dev,
Vojtech Pavlik, linux-input
In-Reply-To: <1137015006.5138.18.camel@localhost.localdomain>
On Thu, Jan 12, 2006 at 08:30:06AM +1100, Benjamin Herrenschmidt wrote:
> I personally think one parameter is plenty enough (on/off) . Michael,
> can you send Dimitri the latest version of that patch please ?
Here it is, CC to Dmitry.
This patch implements support for the fn key on PowerBooks using USB
based keyboards.
Signed-off-by: Michael Hanselmann <linux-kernel@hansmi.ch>
Acked-by: Rene Nussbaumer <linux-kernel@killerfox.forkbomb.ch>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
diff -rNup linux-2.6.15-rc7.orig/drivers/usb/input/Kconfig linux-2.6.15-rc7/drivers/usb/input/Kconfig
--- linux-2.6.15-rc7.orig/drivers/usb/input/Kconfig 2006-01-01 00:41:15.000000000 +0100
+++ linux-2.6.15-rc7/drivers/usb/input/Kconfig 2006-01-02 20:26:21.000000000 +0100
@@ -37,6 +37,16 @@ config USB_HIDINPUT
If unsure, say Y.
+config USB_HIDINPUT_POWERBOOK
+ bool "Enable support for iBook/PowerBook special keys"
+ default n
+ depends on USB_HIDINPUT
+ help
+ Say Y here if you want support for the special keys (Fn, Numlock) on
+ Apple iBooks and PowerBooks.
+
+ If unsure, say N.
+
config HID_FF
bool "Force feedback support (EXPERIMENTAL)"
depends on USB_HIDINPUT && EXPERIMENTAL
diff -rNup linux-2.6.15-rc7.orig/drivers/usb/input/hid-core.c linux-2.6.15-rc7/drivers/usb/input/hid-core.c
--- linux-2.6.15-rc7.orig/drivers/usb/input/hid-core.c 2006-01-01 00:41:15.000000000 +0100
+++ linux-2.6.15-rc7/drivers/usb/input/hid-core.c 2006-01-02 13:52:59.000000000 +0100
@@ -1580,6 +1580,14 @@ static struct hid_blacklist {
{ USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_RUMBLEPAD, HID_QUIRK_BADPAD },
{ USB_VENDOR_ID_TOPMAX, USB_DEVICE_ID_TOPMAX_COBRAPAD, HID_QUIRK_BADPAD },
+ { USB_VENDOR_ID_APPLE, 0x020E, HID_QUIRK_POWERBOOK_HAS_FN },
+ { USB_VENDOR_ID_APPLE, 0x020F, HID_QUIRK_POWERBOOK_HAS_FN },
+ { USB_VENDOR_ID_APPLE, 0x0214, HID_QUIRK_POWERBOOK_HAS_FN },
+ { USB_VENDOR_ID_APPLE, 0x0215, HID_QUIRK_POWERBOOK_HAS_FN },
+ { USB_VENDOR_ID_APPLE, 0x0216, HID_QUIRK_POWERBOOK_HAS_FN },
+ { USB_VENDOR_ID_APPLE, 0x030A, HID_QUIRK_POWERBOOK_HAS_FN },
+ { USB_VENDOR_ID_APPLE, 0x030B, HID_QUIRK_POWERBOOK_HAS_FN },
+
{ 0, 0 }
};
diff -rNup linux-2.6.15-rc7.orig/drivers/usb/input/hid-input.c linux-2.6.15-rc7/drivers/usb/input/hid-input.c
--- linux-2.6.15-rc7.orig/drivers/usb/input/hid-input.c 2006-01-01 00:41:15.000000000 +0100
+++ linux-2.6.15-rc7/drivers/usb/input/hid-input.c 2006-01-03 20:21:00.000000000 +0100
@@ -63,6 +63,71 @@ static struct {
__s32 y;
} hid_hat_to_axis[] = {{ 0, 0}, { 0,-1}, { 1,-1}, { 1, 0}, { 1, 1}, { 0, 1}, {-1, 1}, {-1, 0}, {-1,-1}};
+struct hidinput_key_translation {
+ u16 from;
+ u16 to;
+ u8 flags;
+};
+
+#ifdef CONFIG_USB_HIDINPUT_POWERBOOK
+
+#define POWERBOOK_FLAG_FKEY 0x01
+
+static struct hidinput_key_translation powerbook_fn_keys[] = {
+ { KEY_BACKSPACE, KEY_DELETE },
+ { KEY_F1, KEY_BRIGHTNESSDOWN, POWERBOOK_FLAG_FKEY },
+ { KEY_F2, KEY_BRIGHTNESSUP, POWERBOOK_FLAG_FKEY },
+ { KEY_F3, KEY_MUTE, POWERBOOK_FLAG_FKEY },
+ { KEY_F4, KEY_VOLUMEDOWN, POWERBOOK_FLAG_FKEY },
+ { KEY_F5, KEY_VOLUMEUP, POWERBOOK_FLAG_FKEY },
+ { KEY_F6, KEY_NUMLOCK, POWERBOOK_FLAG_FKEY },
+ { KEY_F7, KEY_SWITCHVIDEOMODE, POWERBOOK_FLAG_FKEY },
+ { KEY_F8, KEY_KBDILLUMTOGGLE, POWERBOOK_FLAG_FKEY },
+ { KEY_F9, KEY_KBDILLUMDOWN, POWERBOOK_FLAG_FKEY },
+ { KEY_F10, KEY_KBDILLUMUP, POWERBOOK_FLAG_FKEY },
+ { KEY_UP, KEY_PAGEUP },
+ { KEY_DOWN, KEY_PAGEDOWN },
+ { KEY_LEFT, KEY_HOME },
+ { KEY_RIGHT, KEY_END },
+ { }
+};
+
+static struct hidinput_key_translation powerbook_numlock_keys[] = {
+ { KEY_J, KEY_KP1 },
+ { KEY_K, KEY_KP2 },
+ { KEY_L, KEY_KP3 },
+ { KEY_U, KEY_KP4 },
+ { KEY_I, KEY_KP5 },
+ { KEY_O, KEY_KP6 },
+ { KEY_7, KEY_KP7 },
+ { KEY_8, KEY_KP8 },
+ { KEY_9, KEY_KP9 },
+ { KEY_M, KEY_KP0 },
+ { KEY_DOT, KEY_KPDOT },
+ { KEY_SLASH, KEY_KPPLUS },
+ { KEY_SEMICOLON, KEY_KPMINUS },
+ { KEY_P, KEY_KPASTERISK },
+ { KEY_MINUS, KEY_KPEQUAL },
+ { KEY_0, KEY_KPSLASH },
+ { KEY_F6, KEY_NUMLOCK },
+ { KEY_KPENTER, KEY_KPENTER },
+ { KEY_BACKSPACE, KEY_BACKSPACE },
+ { }
+};
+
+static int usbhid_pb_fkeyslast;
+module_param_named(pb_fkeyslast, usbhid_pb_fkeyslast, bool, 0644);
+MODULE_PARM_DESC(usbhid_pb_fkeyslast, "Use F keys only while pressing fn on PowerBooks");
+
+static int usbhid_pb_disablefnkeys;
+module_param_named(pb_disablefnkeys, usbhid_pb_disablefnkeys, bool, 0644);
+MODULE_PARM_DESC(usbhid_pb_disablefnkeys, "Disable fn special keys on PowerBooks");
+
+static int usbhid_pb_disablekeypad;
+module_param_named(pb_disablekeypad, usbhid_pb_disablekeypad, bool, 0644);
+MODULE_PARM_DESC(usbhid_pb_disablekeypad, "Disable keypad keys on PowerBooks");
+#endif
+
#define map_abs(c) do { usage->code = c; usage->type = EV_ABS; bit = input->absbit; max = ABS_MAX; } while (0)
#define map_rel(c) do { usage->code = c; usage->type = EV_REL; bit = input->relbit; max = REL_MAX; } while (0)
#define map_key(c) do { usage->code = c; usage->type = EV_KEY; bit = input->keybit; max = KEY_MAX; } while (0)
@@ -73,6 +138,85 @@ static struct {
#define map_key_clear(c) do { map_key(c); clear_bit(c, bit); } while (0)
#define map_ff_effect(c) do { set_bit(c, input->ffbit); } while (0)
+static inline struct hidinput_key_translation *find_translation(
+ struct hidinput_key_translation *table, u16 from)
+{
+ struct hidinput_key_translation *trans;
+
+ /* Look for the translation */
+ for(trans = table; trans->from && (trans->from != from); trans++);
+
+ return (trans->from?trans:NULL);
+}
+
+static int hidinput_pb_event(struct hid_device *hid, struct input_dev *input,
+ struct hid_usage *usage, __s32 value)
+{
+#ifdef CONFIG_USB_HIDINPUT_POWERBOOK
+ struct hidinput_key_translation *trans;
+
+ if (usage->code == KEY_FN) {
+ if (value) hid->quirks |= HID_QUIRK_POWERBOOK_FN_ON;
+ else hid->quirks &= ~HID_QUIRK_POWERBOOK_FN_ON;
+
+ input_event(input, usage->type, usage->code, value);
+
+ return 1;
+ }
+
+ if (!usbhid_pb_disablefnkeys) {
+ trans = find_translation(powerbook_fn_keys, usage->code);
+
+ if (trans) {
+ int do_translate;
+
+ if (test_bit(usage->code, hid->pb_fn))
+ do_translate = 1;
+ else if (trans->flags & POWERBOOK_FLAG_FKEY)
+ do_translate =
+ (!usbhid_pb_fkeyslast && (hid->quirks & HID_QUIRK_POWERBOOK_FN_ON)) ||
+ ( usbhid_pb_fkeyslast && !(hid->quirks & HID_QUIRK_POWERBOOK_FN_ON));
+ else
+ do_translate = (hid->quirks & HID_QUIRK_POWERBOOK_FN_ON);
+
+ if (do_translate) {
+ if (value)
+ set_bit(usage->code, hid->pb_fn);
+ else
+ clear_bit(usage->code, hid->pb_fn);
+
+ input_event(input, usage->type, trans->to, value);
+
+ return 1;
+ }
+ }
+ }
+
+ if (!usbhid_pb_disablekeypad) {
+ int try_translate =
+ test_bit(usage->code, hid->pb_numlock)?1:
+ test_bit(LED_NUML, input->led);
+
+ if (try_translate) {
+ trans = find_translation(powerbook_numlock_keys, usage->code);
+
+ if (trans) {
+ if (value)
+ set_bit(usage->code, hid->pb_numlock);
+ else
+ clear_bit(usage->code, hid->pb_numlock);
+
+ input_event(input, usage->type, trans->to, value);
+ }
+
+ return 1;
+ }
+ }
+#endif
+
+ return 0;
+}
+
static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_field *field,
struct hid_usage *usage)
{
@@ -325,7 +469,27 @@ static void hidinput_configure_usage(str
set_bit(EV_REP, input->evbit);
switch(usage->hid & HID_USAGE) {
- case 0x003: map_key_clear(KEY_FN); break;
+#ifdef CONFIG_USB_HIDINPUT_POWERBOOK
+ /* The fn key on Apple PowerBooks */
+ case 0x0003: {
+ struct hidinput_key_translation *trans;
+
+ map_key_clear(KEY_FN);
+
+ set_bit(KEY_FN, input->keybit);
+ set_bit(KEY_NUMLOCK, input->keybit);
+
+ /* Enable all needed keys */
+ for(trans = powerbook_fn_keys; trans->from; trans++)
+ set_bit(trans->to, input->keybit);
+
+ for(trans = powerbook_numlock_keys; trans->from; trans++)
+ set_bit(trans->to, input->keybit);
+
+ goto ignore;
+ }
+#endif
+
default: goto ignore;
}
break;
@@ -482,6 +646,11 @@ void hidinput_hid_event(struct hid_devic
return;
}
+ if ((hid->quirks & HID_QUIRK_POWERBOOK_HAS_FN) &&
+ hidinput_pb_event(hid, input, usage, value)) {
+ return;
+ }
+
if (usage->hat_min < usage->hat_max || usage->hat_dir) {
int hat_dir = usage->hat_dir;
if (!hat_dir)
diff -rNup linux-2.6.15-rc7.orig/drivers/usb/input/hid.h linux-2.6.15-rc7/drivers/usb/input/hid.h
--- linux-2.6.15-rc7.orig/drivers/usb/input/hid.h 2006-01-01 00:41:15.000000000 +0100
+++ linux-2.6.15-rc7/drivers/usb/input/hid.h 2006-01-03 00:45:13.000000000 +0100
@@ -246,6 +246,8 @@ struct hid_item {
#define HID_QUIRK_2WHEEL_MOUSE_HACK_5 0x100
#define HID_QUIRK_2WHEEL_MOUSE_HACK_ON 0x200
#define HID_QUIRK_2WHEEL_POWERMOUSE 0x400
+#define HID_QUIRK_POWERBOOK_HAS_FN 0x00000800
+#define HID_QUIRK_POWERBOOK_FN_ON 0x00001000
/*
* This is the global environment of the parser. This information is
@@ -431,6 +433,14 @@ struct hid_device { /* device repo
void (*ff_exit)(struct hid_device*); /* Called by hid_exit_ff(hid) */
int (*ff_event)(struct hid_device *hid, struct input_dev *input,
unsigned int type, unsigned int code, int value);
+
+#ifdef CONFIG_USB_HIDINPUT_POWERBOOK
+ /* We do this here because it's only relevant for the
+ * USB devices, not for all input_dev's.
+ */
+ unsigned long pb_fn[NBITS(KEY_MAX)];
+ unsigned long pb_numlock[NBITS(KEY_MAX)];
+#endif
};
#define HID_GLOBAL_STACK_SIZE 4
^ permalink raw reply
* Re: [PATCH/RFC?] usb/input: Add support for fn key on Apple PowerBooks
From: Michael Hanselmann @ 2006-01-11 21:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-kernel, dtor_core, linux-kernel, linuxppc-dev,
Vojtech Pavlik, linux-input
In-Reply-To: <1137015669.5138.22.camel@localhost.localdomain>
On Thu, Jan 12, 2006 at 08:41:08AM +1100, Benjamin Herrenschmidt wrote:
> > Johannes Berg told me he wants to use the fn key alone to switch the
> > keyboard layout or something. For such uses, the pb_enablefn is there.
Sorry, actually it's called pb_disablefn now.
> What does it do ? Just send a keycode ? That should be unconditionnal.
> The Fn key should change a keycode always. I don't see why you would
> that to be off.
No, if that parameter is disabled, it translates key combinations like
Fn+F1 to KEY_BRIGHTNESSUP. If it's enabled, it only sends KEY_FN.
Greets,
Michael
^ permalink raw reply
* Re: [PATCH/RFC?] usb/input: Add support for fn key on Apple PowerBooks
From: Benjamin Herrenschmidt @ 2006-01-11 21:41 UTC (permalink / raw)
To: Michael Hanselmann
Cc: linux-kernel, dtor_core, linux-kernel, linuxppc-dev,
Vojtech Pavlik, linux-input
In-Reply-To: <20060111213805.GE6617@hansmi.ch>
On Wed, 2006-01-11 at 22:38 +0100, Michael Hanselmann wrote:
> On Thu, Jan 12, 2006 at 08:34:17AM +1100, Benjamin Herrenschmidt wrote:
> > Yeah, but the question is why 3 ? I think one (on/off) is enough. Do you
> > have any case where people actually change the other ones ?
>
> Johannes Berg told me he wants to use the fn key alone to switch the
> keyboard layout or something. For such uses, the pb_enablefn is there.
What does it do ? Just send a keycode ? That should be unconditionnal.
The Fn key should change a keycode always. I don't see why you would
that to be off.
> pb_fkeyslast is to emulate the behaviour of KBDMode from pbbuttonsd.
> The last one, pb_disablekeypad could left out. It doesn't add much code
> and might be used by some people, too.
The ony one we need is the one enabling/disabing the old behaviour.
Ben.
^ permalink raw reply
* Re: [PATCH/RFC?] usb/input: Add support for fn key on Apple PowerBooks
From: Michael Hanselmann @ 2006-01-11 21:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-kernel, dtor_core, linux-kernel, linuxppc-dev,
Vojtech Pavlik, linux-input
In-Reply-To: <1137015258.5138.20.camel@localhost.localdomain>
On Thu, Jan 12, 2006 at 08:34:17AM +1100, Benjamin Herrenschmidt wrote:
> Yeah, but the question is why 3 ? I think one (on/off) is enough. Do you
> have any case where people actually change the other ones ?
Johannes Berg told me he wants to use the fn key alone to switch the
keyboard layout or something. For such uses, the pb_enablefn is there.
pb_fkeyslast is to emulate the behaviour of KBDMode from pbbuttonsd.
The last one, pb_disablekeypad could left out. It doesn't add much code
and might be used by some people, too.
Greets,
Michael
^ permalink raw reply
* Re: [PATCH/RFC?] usb/input: Add support for fn key on Apple PowerBooks
From: Benjamin Herrenschmidt @ 2006-01-11 21:34 UTC (permalink / raw)
To: Michael Hanselmann
Cc: linux-kernel, dtor_core, linux-kernel, linuxppc-dev,
Vojtech Pavlik, linux-input
In-Reply-To: <20060111212056.GC6617@hansmi.ch>
On Wed, 2006-01-11 at 22:20 +0100, Michael Hanselmann wrote:
> On Wed, Jan 11, 2006 at 04:07:37PM -0500, Dmitry Torokhov wrote:
> > Ok, I am looking at the patch again, and I have a question - do we
> > really need these 3 module parameters? If the goal is to be compatible
> > with older keyboards then shouldn't we stick to one behavior?
>
> The old keyboard was controlled by ADB (Apple Desktop Bus) commands sent
> by pbbuttonsd. That doesn't work for the USB keyboard because the
> conversion is not done in hardware like with the old ones. ioctl's would
> also be possible, but I'm not sure wether they would be easy to do for
> USB devices. Module parameters can be changed using sysfs.
Yeah, but the question is why 3 ? I think one (on/off) is enough. Do you
have any case where people actually change the other ones ?
Ben.
^ permalink raw reply
* Re: [PATCH/RFC?] usb/input: Add support for fn key on Apple PowerBooks
From: Benjamin Herrenschmidt @ 2006-01-11 21:30 UTC (permalink / raw)
To: dtor_core
Cc: linux-kernel, linux-kernel, linuxppc-dev, Vojtech Pavlik,
linux-input
In-Reply-To: <d120d5000601111307x451db79aqf88725e7ecec79d2@mail.gmail.com>
> Ok, I am looking at the patch again, and I have a question - do we
> really need these 3 module parameters? If the goal is to be compatible
> with older keyboards then shouldn't we stick to one behavior?
I personally think one parameter is plenty enough (on/off) . Michael,
can you send Dimitri the latest version of that patch please ?
Ben.
^ permalink raw reply
* Re: [PATCH/RFC?] usb/input: Add support for fn key on Apple PowerBooks
From: Michael Hanselmann @ 2006-01-11 21:20 UTC (permalink / raw)
To: dtor_core
Cc: linux-kernel, linux-kernel, linuxppc-dev, Vojtech Pavlik,
linux-input
In-Reply-To: <d120d5000601111307x451db79aqf88725e7ecec79d2@mail.gmail.com>
On Wed, Jan 11, 2006 at 04:07:37PM -0500, Dmitry Torokhov wrote:
> Ok, I am looking at the patch again, and I have a question - do we
> really need these 3 module parameters? If the goal is to be compatible
> with older keyboards then shouldn't we stick to one behavior?
The old keyboard was controlled by ADB (Apple Desktop Bus) commands sent
by pbbuttonsd. That doesn't work for the USB keyboard because the
conversion is not done in hardware like with the old ones. ioctl's would
also be possible, but I'm not sure wether they would be easy to do for
USB devices. Module parameters can be changed using sysfs.
Greets,
Michael
^ permalink raw reply
* Re: [PATCH/RFC?] usb/input: Add support for fn key on Apple PowerBooks
From: Dmitry Torokhov @ 2006-01-11 21:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-kernel, linux-kernel, linuxppc-dev, Vojtech Pavlik,
linux-input
In-Reply-To: <1135575997.14160.4.camel@localhost.localdomain>
On 12/26/05, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Sun, 2005-12-25 at 23:04 -0500, Dmitry Torokhov wrote:
>
> > As far as the hook itself - i have that feeling that it should not be
> > done in kernel but via a keymap.
>
> While I understand your feeling, it's a bit annoying in this specific
> case because previous models did this in hardware and all mac keymaps
> already account for that. Knowing how nasty it has been to get mac
> keymaps updated and in a good shape, and to get distros to properly get
> them, it makes a lot of sense to have this small hook in the kernel that
> makes the USB keyboard behave exactly like the older ADB couterparts.
>
Ok, I am looking at the patch again, and I have a question - do we
really need these 3 module parameters? If the goal is to be compatible
with older keyboards then shouldn't we stick to one behavior?
--
Dmitry
^ permalink raw reply
* AGPGART driver for ArticiaS - ioremap() problem
From: Gerhard Pircher @ 2006-01-11 21:00 UTC (permalink / raw)
To: linuxppc-dev, debian-powerpc
Hi,
David Bentam and I are trying to get a AGPGART driver working for the
AmigaOne and the Pegasos1. The driver detects the aperture size of the
ArticiaS AGP bridge, but fails at the ioremap() function in the generic GATT
table create function. Does the PowerPC platform behaves differently for the
mapping of address location for AGP operation than the x86 platform? Is it
possible to use a mask to relocate the AGP address space to a specific
location?
regards,
Gerhard Pircher
--
Telefonieren Sie schon oder sparen Sie noch?
NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie
^ permalink raw reply
* Re: Can ELDK 3.1.1 compile Linux 2.6 Kernel?
From: Wolfgang Denk @ 2006-01-11 20:37 UTC (permalink / raw)
To: Lo Chun Chung; +Cc: linuxppc-embedded
In-Reply-To: <20060111083657.77699.qmail@web53707.mail.yahoo.com>
In message <20060111083657.77699.qmail@web53707.mail.yahoo.com> you wrote:
>
> I just downloaded ELDK 3.1.1 (from denx) and LINUX kernel 2.6 (from kernel.org), and I compile the kernel for powerpc arch.
>
> but during I compile to the file under the directory vdso32, the following compile errors occur:
>
> arch/powerpc/kernel/vdso32/gettimeofday.S: Assembler messages:
> arch/powerpc/kernel/vdso32/gettimeofday.S:28: Error: unknown pseudo-op: `.cfi_startproc'
...
Yes, they changed the Linux kernel such that it cannot be compiled
any more using binutils version 2.14 which is used in ELDK 3.x
> What's wrong with my compiler? Or ELDK cannot compile 2.6 kernel? What I can do now?
Please wait until the end of the week, then download ELDK 4.0, then
be happy ;-)
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"To IBM, 'open' means there is a modicum of interoperability among
some of their equipment." - Harv Masterson
^ permalink raw reply
* Re: Ethernet not initialized: Help req
From: Wolfgang Denk @ 2006-01-11 20:34 UTC (permalink / raw)
To: batsayan.das; +Cc: Linuxppc-embedded
In-Reply-To: <OFDC66830E.1EDE14C4-ON652570F3.00265CDF-652570F3.00297A66@tcs.com>
In message <OFDC66830E.1EDE14C4-ON652570F3.00265CDF-652570F3.00297A66@tcs.com> you wrote:
>
> In our MPC8260 based customs board the CLK9 is for transmit and CLK10 is
> for receive. The ELDK tree uses CLK12 is receive, CLK11 is transmit and
This is not correct. The ELDK does not do this. The ELDK is not a
Linux source tree.
Also, this setting is hardware dependent and differs from board to
board.
> We got CLK9 and CLK10 from U-Boot tree and set those varables, but
> ethernet does not work.
Then probably other changes / initializations (port pin
configurations) are needed as well.
> My question is what value shall I use for CLK9 and CLK10?
This idepends on your hardware. Study the schematics.
> What else setting we need to change to make Ethernet work?
Compare U-Boot code and other board definitions.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
A secure program has to be robust: it must be able to deal with
conditions that "can't happen", whether user input, program error or
library/etc. This is basic damage control. Buffer overflow errors
have nothing to do with security, but everything with stupidity.
-- Wietse Venema in <5cnqm3$8r9@spike.porcupine.org>
^ permalink raw reply
* Linux question
From: mcnernbm @ 2006-01-11 19:12 UTC (permalink / raw)
To: Andrei Konovalov; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 1407 bytes --]
[-- Attachment #2: my_adder.cpp --]
[-- Type: application/octet-stream, Size: 4302 bytes --]
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/mman.h>
#include "my_io.h"
#include "AlgorithmTestTimeStamp/NativeTimeStamp.h"
volatile unsigned long * ioremap(unsigned long physaddr, unsigned size)
{
static int axs_mem_fd = -1;
unsigned long page_addr, ofs_addr, reg, pgmask;
void* reg_mem = NULL;
/*
* looks like mmap wants aligned addresses?
*/
pgmask = getpagesize()-1;
page_addr = physaddr & ~pgmask;
ofs_addr = physaddr & pgmask;
/*
* Don't forget O_SYNC, esp. if address is in RAM region.
* Note: if you do know you'll access in Read Only mode,
* pass O_RDONLY to open, and PROT_READ only to mmap
*/
if (axs_mem_fd == -1) {
axs_mem_fd = open("/dev/mem", O_RDWR|O_SYNC);
if (axs_mem_fd < 0) {
perror("AXS: can't open /dev/mem");
return NULL;
}
}
/* memory map */
reg_mem = mmap(
(caddr_t)reg_mem,
size+ofs_addr,
PROT_READ|PROT_WRITE,
MAP_SHARED,
axs_mem_fd,
page_addr
);
if (reg_mem == MAP_FAILED) {
perror("AXS: mmap error");
close(axs_mem_fd);
return NULL;
}
reg = (unsigned long )reg_mem + ofs_addr;
return (volatile unsigned long *)reg;
}
int iounmap(volatile void *start, size_t length)
{
unsigned long ofs_addr;
ofs_addr = (unsigned long)start & (getpagesize()-1);
/* do some cleanup when you're done with it */
return munmap((long*)start-ofs_addr, length+ofs_addr);
}
int main(void) {
unsigned a;
unsigned b;
unsigned sd_a;
unsigned sd_b;
unsigned a1;
unsigned b1;
unsigned sum;
unsigned sum2;
unsigned flag;
unsigned flag_after;
unsigned long reg0_lower;
unsigned long reg0_upper;
unsigned long reg1_lower;
unsigned long reg1_upper;
unsigned long reg2_lower;
unsigned long reg2_upper;
unsigned long *r0_lower;
unsigned long *r0_upper;
unsigned long *r1_lower;
unsigned long *r1_upper;
unsigned long *r2_lower;
unsigned long *r2_upper;
unsigned long temp_t;
unsigned long a_point;
unsigned long b_point;
unsigned long *a_pointer;
unsigned long *b_pointer;
NativeTimeStamp TS;
printf("input number 1: ");
scanf("%u", &sd_a);
printf("input number 2: ");
scanf("%u", &sd_b);
volatile unsigned long *t = ioremap(0x00000000, 67108864);
if(!t)
exit(1);
temp_t = reinterpret_cast <unsigned long> (t);
a_point = temp_t + 200;
b_point = temp_t + 400;
a_pointer = reinterpret_cast <unsigned long *> (a_point);
b_pointer = reinterpret_cast <unsigned long *> (b_point);
out_le32(a_pointer,sd_a);
printf("Writing Reg 0 Lower\n");
out_le32(b_pointer,sd_b );
printf("Writing Reg 0 Upper\n");
a = in_le32(a_pointer);
printf("A: %u\n" , a);
b = in_le32(b_pointer);
printf("B: %u\n", b);
iounmap(t,67108864);
TS.Init(1,5.0);
TS.RecordTime(1);
\r volatile unsigned long *p = ioremap(0xC9C00000, 256);
if(!p)
exit(1);
reg0_lower = reinterpret_cast <unsigned long> (p);
r0_lower = reinterpret_cast <unsigned long *> (reg0_lower);
reg0_upper = reg0_lower + 4;
r0_upper = reinterpret_cast <unsigned long *> (reg0_upper);
reg1_lower = reg0_lower + 8;
r1_lower = reinterpret_cast <unsigned long *> (reg1_lower);
reg1_upper = reg0_lower + 12;
r1_upper = reinterpret_cast <unsigned long *> (reg1_upper);
reg2_lower = reg0_lower + 16;
r2_lower = reinterpret_cast <unsigned long *> (reg2_lower);
reg2_upper = reg0_lower + 20;
r2_upper = reinterpret_cast <unsigned long *> (reg2_upper);
out_le32(r0_lower,a);
printf("Writing Reg 0 Lower\n");
out_le32(r0_upper,b );
printf("Writing Reg 0 Upper\n");
a1 = in_le32(r0_lower);
printf("Reg1: %u\n" , a1);
b1 = in_le32(r0_upper);
printf("Reg2: %u\n", b1);
out_le32(r2_lower,1);
while (flag != 1)
{flag = in_le32(r2_lower);}
sum = in_le32(r1_lower);
printf("Sum = %u\n", sum);
out_le32(r2_lower,0);
flag_after= in_le32(r1_upper);
printf("Flag After= %u\n", flag_after);
iounmap(p,256);
TS.RecordTime(1);
TS.RecordTime(1);
sum2 = a + b;
printf("Sum Using No Hardware: %u\n", sum2);
TS.RecordTime(1);
printf("End");
TS.OutputLogRecords();
return 0;
}
[-- Attachment #3: my_io.h --]
[-- Type: application/octet-stream, Size: 2385 bytes --]
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/mman.h>
typedef unsigned char my8;
typedef unsigned short my16;
typedef unsigned long my32;
#define readb(addr) in_8((volatile my8 *)(addr))
#define writeb(b,addr) out_8((volatile my8 *)(addr), (b))
#define readw(addr) in_le16((volatile myu16 *)(addr))
#define readl(addr) in_le32((volatile my32 *)(addr))
#define writew(b,addr) out_le16((volatile my16 *)(addr),(b))
#define writel(b,addr) out_le32((volatile my32 *)(addr),(b))
extern inline int in_8(volatile unsigned char *addr)
{
int ret;
__asm__ __volatile__(
"lbz%U1%X1 %0,%1;\n"
"twi 0,%0,0;\n"
"isync" : "=r" (ret) : "m" (*addr));
return ret;
}
extern inline void out_8(volatile unsigned char *addr, int val)
{
__asm__ __volatile__("stb%U0%X0 %1,%0; eieio" : "=m" (*addr) : "r" (val));
}
extern inline int in_le16(volatile unsigned short *addr)
{
int ret;
__asm__ __volatile__("lhbrx %0,0,%1;\n"
"twi 0,%0,0;\n"
"isync" : "=r" (ret) :
"r" (addr), "m" (*addr));
return ret;
}
extern inline int in_be16(volatile unsigned short *addr)
{
int ret;
__asm__ __volatile__("lhz%U1%X1 %0,%1;\n"
"twi 0,%0,0;\n"
"isync" : "=r" (ret) : "m" (*addr));
return ret;
}
extern inline void out_le16(volatile unsigned short *addr, int val)
{
__asm__ __volatile__("sthbrx %1,0,%2; eieio" : "=m" (*addr) :
"r" (val), "r" (addr));
}
extern inline void out_be16(volatile unsigned short *addr, int val)
{
__asm__ __volatile__("sth%U0%X0 %1,%0; eieio" : "=m" (*addr) : "r" (val));
}
extern inline unsigned in_le32(volatile unsigned long *addr)
{
unsigned ret;
__asm__ __volatile__("lwbrx %0,0,%1;\n"
"twi 0,%0,0;\n"
"isync" : "=r" (ret) :
"r" (addr), "m" (*addr));
return ret;
}
extern inline unsigned in_be32(volatile unsigned long *addr)
{
unsigned ret;
__asm__ __volatile__("lwz%U1%X1 %0,%1;\n"
"twi 0,%0,0;\n"
"isync" : "=r" (ret) : "m" (*addr));
return ret;
}
extern inline void out_le32(volatile unsigned long *addr, int val)
{
__asm__ __volatile__("stwbrx %1,0,%2; eieio" : "=m" (*addr) :
"r" (val), "r" (addr));
}
extern inline void out_be32(volatile unsigned long *addr, int val)
{
__asm__ __volatile__("stw%U0%X0 %1,%0; eieio" : "=m" (*addr) : "r" (val));
}
^ permalink raw reply
* Re: powerpc.git tree
From: will schmidt @ 2006-01-11 19:11 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <17348.60119.801379.127209@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
>
> That means that anyone who is following the powerpc.git tree by doing
> pulls periodically will need to reset their tree too. Otherwise each
> pull will do an unnecessary merge.
Hi Paul,
By reset, do you mean to delete the local tree and pull a fresh one, or something fancier?
-Will
>
> Comments?
>
> Paul.
> _______________________________________________
> Linuxppc64-dev mailing list
> Linuxppc64-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc64-dev
^ permalink raw reply
* Re: About MMU setting in MPC8245
From: Mark A. Greer @ 2006-01-11 16:07 UTC (permalink / raw)
To: happa; +Cc: linuxppc-embedded
In-Reply-To: <20060111102618.0F9251100F2@wmlab.csie.ncu.edu.tw>
On Wed, Jan 11, 2006 at 06:26:18PM +0800, happa@wmlab.csie.ncu.edu.tw wrote:
> Hi,
> Sorry, I have very basic question about PPC MMU setting.
>
> In "http://www.denx.de/wiki/PPCEmbedded/Kernel#BOOTLOADER",
> chapter 10.2. Memory Map, I get the following information.
>
> "The bootloader is responsible for configuring the memory map before jumping to the Linux kernel."
>
> Is anyone know what memory map should be done in bootloader?
Are you in PCI host mode? If so, the first sentence of chapter 3--
Address Maps of the 8245 manual states:
"The MPC8245 in PCI host mode supports an address mapping
configuration that is designated as address map B."
Map B == CHRP mapping.
> If I'm using ICE to load linux kernel, what kind of CPU registers need be configured first?
> Is IBAT/DBAT and Segment register need be set?
Why don't you just use U-boot or look at the U-Boot code to see how its
done?
Mark
^ permalink raw reply
* Re: powerpc.git tree
From: Jon Loeliger @ 2006-01-11 15:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev@ozlabs.org, linuxppc64-dev
In-Reply-To: <17348.60119.801379.127209@cargo.ozlabs.ibm.com>
On Wed, 2006-01-11 at 05:24, Paul Mackerras wrote:
> All of the patches in the powerpc.git tree have now been either sent
> upstream to Linus' tree, or reverted.
Yeah!
> In future I'd like to be able to ask Linus to pull the powerpc.git
> tree, without cluttering up his tree with those superseded commits.
Can you give us a work-flow statement that covers
the powerpc.git and powerpc-merge.git trees? When do
patches hit on-or-the-other tree? What is the purpose
of the two trees, especially given that "merge" work
is also "development" work. When will the two trees
be slated for upstream Linus pullage?
That sort of thing. :-)
> That means I need to reset the powerpc.git tree to be the same as
> Linus' tree now.
Oh boy! One shoe...
> That means that anyone who is following the powerpc.git tree by doing
> pulls periodically will need to reset their tree too. Otherwise each
> pull will do an unnecessary merge.
Two shoe...
> If that would cause people serious heartburn, I can instead abandon
> the powerpc.git tree and start a new development tree
> (powerpc-devel.git perhaps).
'S ok with me either way. Just give us a "I did this, you
now need to do that" statement as needed!
Now, what we really need is a U-Boot tree in which we can
dump the corresponding OF bits. Any chance we could get
one set up at kernel.org that might later be pulled into
WD's tree and simplify his life too?
Thanks!
jdl
^ permalink raw reply
* Re: powerpc.git tree
From: Dan Malek @ 2006-01-11 15:24 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <17348.60119.801379.127209@cargo.ozlabs.ibm.com>
On Jan 11, 2006, at 6:24 AM, Paul Mackerras wrote:
> If that would cause people serious heartburn, I can instead abandon
> the powerpc.git tree and start a new development tree
> (powerpc-devel.git perhaps).
From past experience, creating another tree, especially something
called "devel" only caused more problems :-) Please, just do what
you think is best for the powerpc.git tree and we'll just move forward.
Thanks.
-- Dan
^ permalink raw reply
* Compilation error on Linux PPC
From: Kriti Dutta @ 2006-01-11 15:02 UTC (permalink / raw)
To: linuxppc
[-- Attachment #1: Type: text/plain, Size: 2087 bytes --]
> While building one of our library,the following error was reported:
>
> /usr/lib/gcc-lib/powerpc-suse-linux/3.3.3/../../../../lib/crti.o(.text+0x1
> 0): In function `call_gmon_start':
> /usr/src/packages/BUILD/glibc-2.3/cc/csu/crti.S:16: relocation truncated
> to fit: R_PPC_LOCAL24PC _GLOBAL_OFFSET_TABLE_+fffffffffffffffc
> /usr/lib/gcc-lib/powerpc-suse-linux/3.3.3/crtbeginS.o(.text+0xa4): In
> function `__do_global_dtors_aux':
> : relocation truncated to fit: R_PPC_PLTREL24 __cxa_finalize@@GLIBC_2.1.3
> /usr/lib/gcc-lib/powerpc-suse-linux/3.3.3/crtbeginS.o(.fini+0x0):
> relocation truncated to fit: R_PPC_LOCAL24PC .text+4
> /usr/lib/gcc-lib/powerpc-suse-linux/3.3.3/crtendS.o(.init+0x0): relocation
> truncated to fit: R_PPC_LOCAL24PC .text+4
> obj/opt/dcbagg.o(.text+0x10): In function `__sinit65535()':
> : relocation truncated to fit: R_PPC_LOCAL24PC
> _GLOBAL_OFFSET_TABLE_+fffffffffffffffc
> obj/opt/dcbagg.o(.text+0x28): In function `__sinit65535()':
> : relocation truncated to fit: R_PPC_PLTREL24
> _ZNSt8ios_base4InitC1Ev@@GLIBCPP_3.2
> obj/opt/dcbagg.o(.text+0x34): In function `__sinit65535()':
> : relocation truncated to fit: R_PPC_PLTREL24 atexit
> obj/opt/dcbagg.o(.text+0x3c): In function `__sinit65535()':
> : relocation truncated to fit: R_PPC_PLTREL24
> OLLogger_Dest::OLLogger_Dest()
> obj/opt/dcbagg.o(.text+0x48): In function `__sinit65535()':
> : relocation truncated to fit: R_PPC_PLTREL24 atexit
> obj/opt/dcbagg.o(.text+0x7c): In function `__srterm__0()':
> : relocation truncated to fit: R_PPC_LOCAL24PC
> _GLOBAL_OFFSET_TABLE_+fffffffffffffffc
> obj/opt/dcbagg.o(.text+0x90): In function `__srterm__0()':
> : additional relocation overflows omitted from the output
>
> Its worth mentioning here that we didn't face any such issue while
> building our other libraries and our .o's .
>
> M/C Details:
> uname -a : -
> Linux staxj05 2.6.5-7.139-pseries64 #1 SMP Fri Jan 14 15:41:33 UTC 2005
> ppc64 ppc64 ppc64 GNU/Linux
>
> xlC Version : -
> xlC 7.0
>
> gcc -v : -
> gcc version 3.3.3 (SuSE Linux)
>
>
>
> With regards
> Kriti.
[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2624 bytes --]
^ permalink raw reply
* Re: [PATCH] implement AT_PLATFORM for powerpc
From: Kumar Gala @ 2006-01-11 14:43 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, linuxppc64-dev, Steve Munroe
In-Reply-To: <17348.50913.414568.263736@cargo.ozlabs.ibm.com>
Paul,
This reminds me do we have a bit for having/not having the load/store
string instructions. If memory serves me there were some discussions
of looking at "depreciating" the instructions from the architecture.
Freescale Book-E implementations already do NOT implement them. I
doubt that Freescale will over implement these instructions ever again.
-k
On Jan 11, 2006, at 2:50 AM, Paul Mackerras wrote:
> Eugene Surovegin writes:
>
>> I checked 44x user manuals I have:
>>
>> 440GP doesn't have isel
>> 440GX, 440EP, 440SP, 440SPe, 440GR have it.
>
> Thanks, that's helpful. Do you know if 440{GX,EP,SP,SPe,GR} implement
> all of the 32-bit user-mode instructions in Book E?
>
> How do mbar and msync work on those processors? As mbar and msync (as
> defined in Book E) or as eieio and sync?
>
> Do the 440* processors in fact claim Book E compliance?
>
> Thanks,
> Paul.
> _______________________________________________
> Linuxppc64-dev mailing list
> Linuxppc64-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc64-dev
^ permalink raw reply
* Memory and register adresses on PCI graphic chip.
From: powerpc440 @ 2006-01-11 13:43 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I have custom board based on Ocotea - PPC440GX with Graphic chip (Radeon
M6) on it. I need to initialise the registers and the memory of the chip
upon booting. Now I comunicate with the board thru serial interface, and
u-boot 1.1.2 + linux 2.6.12 both working wery well up to the video.
The PCI memory is mapped on 0x80000000 in u-boot configuration. How can
I understand where are the memory and register base adresses of the
graphic chip?
This is part from u-boot splash screen:
Board: HIMA 440GX Board
VCO: 1000 MHz
CPU: 500 MHz
PLB: 166 MHz
OPB: 83 MHz
EPB: 83 MHz
I2C: ready
DRAM: 512 MB
FLASH: portwidth=4 chipwidth=2
found 1 erase regions
64 MB
*** Warning - bad CRC, using default environment
PCI: Bus Dev VenId DevId Class Int
00 01 1131 1561 0c03 00
00 01 1131 1561 0c03 00
00 01 1131 1562 0c03 00
00 02 1002 4c59 0300 ff < --------------
The Radeon M6 chip
00 03 1013 6005 0401 00
00 04 1095 3114 0180 00
In: serial
Out: serial
Err: serial
Net: pfc1: 4
Konfiguration 4
---------------------------------------------
This information i can obtain from the /proc after linux loading: :
#lspci -vv
............................
00:02.0 Class 0300: 1002:4c59
Subsystem: 1002:4c59
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping+ SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 128 (2000ns min), cache line size 08
Interrupt: pin A routed to IRQ 25
Region 0: Memory at f0000000 (32-bit, prefetchable) [size=128M]
Region 1: I/O ports at ff00 [size=256]
Region 2: Memory at efff0000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Thanks a lot!
Zhivko
^ permalink raw reply
* Re: [PATCH] powerpc: fix large nvram access
From: Olaf Hering @ 2006-01-11 12:20 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <20060111102540.GA11688@suse.de>
On Wed, Jan 11, Olaf Hering wrote:
> > I think this has uncovered a bug that has been in nvsetenv for a long time.
I made this change.
Index: pmac-utils-2.1/nvsetenv.c
===================================================================
--- pmac-utils-2.1.orig/nvsetenv.c
+++ pmac-utils-2.1/nvsetenv.c
@@ -110,12 +110,21 @@ int nvcsum( void )
static void nvload( int nvfd )
{
int s;
+ ssize_t r, toread = 0;
+ char *buf = (char *)&nvbuf;
- if (lseek(nvfd, NVSTART, 0) < 0
- || read(nvfd, &nvbuf, NVSIZE) != NVSIZE) {
- perror("Error reading /dev/nvram");
+ if ((off_t)-1 == lseek(nvfd, NVSTART, 0)) {
+ perror("Error seeking /dev/nvram");
exit(EXIT_FAILURE);
}
+ do {
+ r = read(nvfd, buf + toread, NVSIZE - toread);
+ if (r < 0) {
+ perror("Error reading /dev/nvram");
+ exit(EXIT_FAILURE);
+ }
+ toread += r;
+ } while (toread < NVSIZE && r);
if (nvbuf.nv.magic != NVMAGIC)
(void) fprintf(stderr, "Warning: Bad magic number %x\n",
nvbuf.nv.magic);
@@ -127,11 +136,21 @@ static void nvload( int nvfd )
static void nvstore(int nvfd)
{
- if (lseek(nvfd, NVSTART, 0) < 0
- || write(nvfd, &nvbuf, NVSIZE) != NVSIZE) {
- perror("Error writing /dev/nvram");
+ char *p = (char *)&nvbuf;
+ size_t count = 0;
+ off_t w;
+ if (lseek(nvfd, NVSTART, 0) < 0) {
+ perror("Error seeking /dev/nvram");
exit(EXIT_FAILURE);
}
+ do {
+ w = write(nvfd, p + count, NVSIZE - count);
+ if (w < 0) {
+ perror("Error writing /dev/nvram");
+ exit(EXIT_FAILURE);
+ }
+ count += w;
+ } while (count < NVSIZE);
}
void nvunpack( void )
Index: pmac-utils-2.1/nwnvsetenv.c
===================================================================
--- pmac-utils-2.1.orig/nwnvsetenv.c
+++ pmac-utils-2.1/nwnvsetenv.c
@@ -88,15 +88,20 @@ int nvscan(int nvfd, chrp_header* chrph,
static char* nvload( int nvfd , int nvsize)
{
char* nvbuf = malloc(nvsize);
+ ssize_t r, toread = 0;
if (!nvbuf) {
perror("Error allocating buffer");
exit(EXIT_FAILURE);
}
- if (read(nvfd, nvbuf, nvsize) != nvsize) {
- perror("Error reading /dev/nvram");
- exit(EXIT_FAILURE);
- }
+ do {
+ r = read(nvfd, nvbuf + toread, nvsize - toread);
+ if (r < 0) {
+ perror("Error reading /dev/nvram");
+ exit(EXIT_FAILURE);
+ }
+ toread += r;
+ } while (toread < nvsize && r);
return nvbuf;
}
@@ -182,6 +187,7 @@ print_var(char* nvbuf, int nvsize, char*
printf("%s\n",buf);
}
+#if 0
/* This fucntion is not used here, it is left
her for the curious */
@@ -197,26 +203,28 @@ unsigned short chrp_checksum(chrp_header
sum = (sum & 0xFF) + (sum>>8);
return sum;
}
+#endif
static void
nvstore(int nvfd, chrp_header* chrph, char* nvbuf, int nvstart, int nvsize)
{
// mmh, the checksum is calculated for the header only
// since we did not modify the header we can just ignore it.
- ssize_t written;
- ssize_t seek = nvstart + sizeof(chrp_header);
- written = lseek(nvfd, seek, SEEK_SET);
- if (written != seek)
- {
+ size_t count = 0;
+ off_t w, seek = nvstart + sizeof(chrp_header);
+ w = lseek(nvfd, seek, SEEK_SET);
+ if (w != seek) {
fprintf(stderr,"Error seeking /dev/nvram\n");
exit(EXIT_FAILURE);
}
- written = write(nvfd, nvbuf, nvsize);
- if (written != nvsize)
- {
- fprintf(stderr,"Error writing /dev/nvram %x %x\n", nvsize, seek);
- exit(EXIT_FAILURE);
- }
+ do {
+ w = write(nvfd, nvbuf + count, nvsize - count);
+ if (w < 0) {
+ perror("Error writing /dev/nvram");
+ exit(EXIT_FAILURE);
+ }
+ count += w;
+ } while (count < (size_t)nvsize);
}
/* print / set the New World NVRAM */
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* powerpc.git tree
From: Paul Mackerras @ 2006-01-11 11:24 UTC (permalink / raw)
To: linuxppc-dev, linuxppc64-dev
All of the patches in the powerpc.git tree have now been either sent
upstream to Linus' tree, or reverted.
For various reasons I didn't just ask Linus to pull the powerpc.git
tree, but instead cherry-picked the commits into the powerpc-merge.git
tree and asked Linus to pull that. That means that there are now
commits in the powerpc.git tree that are superseded by commits in
Linus' tree.
In future I'd like to be able to ask Linus to pull the powerpc.git
tree, without cluttering up his tree with those superseded commits.
That means I need to reset the powerpc.git tree to be the same as
Linus' tree now.
That means that anyone who is following the powerpc.git tree by doing
pulls periodically will need to reset their tree too. Otherwise each
pull will do an unnecessary merge.
If that would cause people serious heartburn, I can instead abandon
the powerpc.git tree and start a new development tree
(powerpc-devel.git perhaps).
Comments?
Paul.
^ permalink raw reply
* Re: restore_user_regs and fpu
From: Paul Mackerras @ 2006-01-11 11:11 UTC (permalink / raw)
To: Heikki Lindholm; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <43BC15A9.7010009@cs.helsinki.fi>
Heikki Lindholm writes:
> I haven't really confirmed this can happen, but I was wondering whether
> the following would be possible. Looking at restore_user_regs in
> ppc/kernel/signal_32.c and assuming:
> * last_task_used_math == current, eg. a signal handler used fpu
> * fpu state is still what the sig handler left there
> If after the fpu state is restored to current->thread.fpr (copy_user)
> somebody preempts this task and uses fpu, wouldn't it cause the fpu
> state (of the sig handler) to be saved to
> last_task_used_math->thread.fpr overwriting the just restored state.
> Should the last_task_used_math nullifying, etc. be moved to the front of
> the function instead, or am I overlooking something?
I think you are correct, and that the same problem exists for 64-bit
processes. This patch should fix it. Can anyone see any problem with
this patch?
Paul.
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 105d560..913f906 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -201,13 +201,13 @@ int dump_spe(struct pt_regs *regs, elf_v
}
#endif /* CONFIG_SPE */
+#ifndef CONFIG_SMP
/*
* If we are doing lazy switching of CPU state (FP, altivec or SPE),
* and the current task has some state, discard it.
*/
-static inline void discard_lazy_cpu_state(void)
+void discard_lazy_cpu_state(void)
{
-#ifndef CONFIG_SMP
preempt_disable();
if (last_task_used_math == current)
last_task_used_math = NULL;
@@ -220,8 +220,8 @@ static inline void discard_lazy_cpu_stat
last_task_used_spe = NULL;
#endif
preempt_enable();
-#endif /* CONFIG_SMP */
}
+#endif /* CONFIG_SMP */
int set_dabr(unsigned long dabr)
{
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
index d3f0b6d..177bba7 100644
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -497,6 +497,15 @@ static long restore_user_regs(struct pt_
if (err)
return 1;
+ /*
+ * Do this before updating the thread state in
+ * current->thread.fpr/vr/evr. That way, if we get preempted
+ * and another task grabs the FPU/Altivec/SPE, it won't be
+ * tempted to save the current CPU state into the thread_struct
+ * and corrupt what we are writing there.
+ */
+ discard_lazy_cpu_state();
+
/* force the process to reload the FP registers from
current->thread when it next does FP instructions */
regs->msr &= ~(MSR_FP | MSR_FE0 | MSR_FE1);
@@ -538,18 +547,6 @@ static long restore_user_regs(struct pt_
return 1;
#endif /* CONFIG_SPE */
-#ifndef CONFIG_SMP
- preempt_disable();
- if (last_task_used_math == current)
- last_task_used_math = NULL;
- if (last_task_used_altivec == current)
- last_task_used_altivec = NULL;
-#ifdef CONFIG_SPE
- if (last_task_used_spe == current)
- last_task_used_spe = NULL;
-#endif
- preempt_enable();
-#endif
return 0;
}
diff --git a/arch/powerpc/kernel/signal_64.c b/arch/powerpc/kernel/signal_64.c
index 5462bef..7b9d999 100644
--- a/arch/powerpc/kernel/signal_64.c
+++ b/arch/powerpc/kernel/signal_64.c
@@ -207,10 +207,20 @@ static long restore_sigcontext(struct pt
if (!sig)
regs->gpr[13] = save_r13;
- err |= __copy_from_user(¤t->thread.fpr, &sc->fp_regs, FP_REGS_SIZE);
if (set != NULL)
err |= __get_user(set->sig[0], &sc->oldmask);
+ /*
+ * Do this before updating the thread state in
+ * current->thread.fpr/vr. That way, if we get preempted
+ * and another task grabs the FPU/Altivec, it won't be
+ * tempted to save the current CPU state into the thread_struct
+ * and corrupt what we are writing there.
+ */
+ discard_lazy_cpu_state();
+
+ err |= __copy_from_user(¤t->thread.fpr, &sc->fp_regs, FP_REGS_SIZE);
+
#ifdef CONFIG_ALTIVEC
err |= __get_user(v_regs, &sc->v_regs);
err |= __get_user(msr, &sc->gp_regs[PT_MSR]);
@@ -229,14 +239,6 @@ static long restore_sigcontext(struct pt
current->thread.vrsave = 0;
#endif /* CONFIG_ALTIVEC */
-#ifndef CONFIG_SMP
- preempt_disable();
- if (last_task_used_math == current)
- last_task_used_math = NULL;
- if (last_task_used_altivec == current)
- last_task_used_altivec = NULL;
- preempt_enable();
-#endif
/* Force reload of FP/VEC */
regs->msr &= ~(MSR_FP | MSR_FE0 | MSR_FE1 | MSR_VEC);
diff --git a/include/asm-powerpc/system.h b/include/asm-powerpc/system.h
index 0c58e32..4c88830 100644
--- a/include/asm-powerpc/system.h
+++ b/include/asm-powerpc/system.h
@@ -133,6 +133,14 @@ extern int fix_alignment(struct pt_regs
extern void cvt_fd(float *from, double *to, struct thread_struct *thread);
extern void cvt_df(double *from, float *to, struct thread_struct *thread);
+#ifndef CONFIG_SMP
+extern void discard_lazy_cpu_state(void);
+#else
+static inline void discard_lazy_cpu_state(void)
+{
+}
+#endif
+
#ifdef CONFIG_ALTIVEC
extern void flush_altivec_to_thread(struct task_struct *);
#else
^ permalink raw reply related
* About MMU setting in MPC8245
From: happa @ 2006-01-11 10:26 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]
Hi,
Sorry, I have very basic question about PPC MMU setting.
In "http://www.denx.de/wiki/PPCEmbedded/Kernel#BOOTLOADER",
chapter 10.2. Memory Map, I get the following information.
"The bootloader is responsible for configuring the memory map before jumping to the Linux kernel."
Is anyone know what memory map should be done in bootloader?
If I'm using ICE to load linux kernel, what kind of CPU registers need be configured first?
Is IBAT/DBAT and Segment register need be set?
I have set the following registers before loading kernel via ICE.
Did I miss something else?
(The target CPU is MPC8245)
offset register
------- -----------------------------------
0x0C Cache Line Size
0x04 PCI Command Register
0xA8 Processor interface configuration 1
0xAC Processor interface configuration 2
0x80 Memory starting address register1
0x84 Memory starting address register2
0x88 Extended memory starting addressregister1
0x8C Extended memory starting addressregister2
0x90 Memory ending address register1
0x94 Memory ending address register2
0x98 Extended memory ending address register1
0x9C Extended memory ending address register2
0xA0 Memory bank enable register
0xD0 Extended ROM configuration register 1
0xD4 Extended ROM configuration register 2
0xD8 Extended ROM configuration register 3
0xDC Extended ROM configuration register 4
0xF0 MCCR1
0xF4 MCCR2
0xF8 MCCR3
0xFC MCCR4
Would anyone give me some references about MMU setting?
^ permalink raw reply
* Re: [PATCH] powerpc: fix large nvram access
From: Olaf Hering @ 2006-01-11 10:25 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200601110034.58911.arnd@arndb.de>
On Wed, Jan 11, Arnd Bergmann wrote:
> Am Dienstag, 10. Januar 2006 23:13 schrieb Olaf Hering:
> > On Mon, Jan 09, Linux Kernel Mailing List wrote:
> > > tree da8f883f72d08f9534e9eca3bba662413b9bd865
> > > parent d52771fce4e774fa786097d34412a057d487c697
> > > author Arnd Bergmann <arnd@arndb.de> Fri, 09 Dec 2005 19:21:44 +0100
> > > committer Paul Mackerras <paulus@samba.org> Mon, 09 Jan 2006 14:53:31
> > > +1100
> > >
> > > [PATCH] powerpc: fix large nvram access
> > >
> > > /dev/nvram uses the user-provided read/write size
> > > for kmalloc, which fails, if a large number is passed.
> > > This will always use a single page at most, which
> > > can be expected to succeed.
> > >
> > > Signed-off-by: Arnd Bergmann <arndb@de.ibm.com>
> > > Signed-off-by: Paul Mackerras <paulus@samba.org>
> > >
> > > arch/powerpc/kernel/nvram_64.c | 114
> > > +++++++++++++++++++----------------------
> >
> > this change breaks my nvsetenv binary on JS20.
> >
>
> I think this has uncovered a bug that has been in nvsetenv for a long time.
Yeah. Dont bother, I will fix that tool.
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: [PATCH] implement AT_PLATFORM for powerpc
From: Eugene Surovegin @ 2006-01-11 9:19 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc64-dev, Kumar Gala, sjmunroe, linuxppc-dev
In-Reply-To: <17348.50913.414568.263736@cargo.ozlabs.ibm.com>
On Wed, Jan 11, 2006 at 07:50:41PM +1100, Paul Mackerras wrote:
> Eugene Surovegin writes:
>
> > I checked 44x user manuals I have:
> >
> > 440GP doesn't have isel
> > 440GX, 440EP, 440SP, 440SPe, 440GR have it.
>
> Thanks, that's helpful. Do you know if 440{GX,EP,SP,SPe,GR} implement
> all of the 32-bit user-mode instructions in Book E?
Manuals claim that the following processors implement "... the full,
32-bit fixed-point subset of the Book-E Enhanced PowerPC Architecture":
440GP, 440GX, 440EP, 440GR, 440SP.
I failed to find similar claim in 440SPe manual, though.
> How do mbar and msync work on those processors? As mbar and msync (as
> defined in Book E) or as eieio and sync?
Here is an excerpt from user manual (I checked 440GP, 440GX, 440SP,
440SPe, 440EP, 440GR manuals and they all contain the same text):
Programming Notes
The msync instruction is execution synchronizing, and guarantees that
all storage accesses initiated by instructions executed prior to the
msync have completed before any instructions after the msync begin
execution. On the other hand, architecturally the mbar instruction
merely orders storage accesses, and does not perform execution
synchronization. Therefore, non-storage access instructions after mbar
could complete before the storage access instructions which were
executed prior to mbar have actually completed their storage accesses.
However, the PPC440xx implements the mbar instruction identically to
the msync instruction, and thus both are execution synchronizing.
Architecture Note
mbar replaces the PowerPC eieio instruction. mbar uses the same opcode
as eieio; PowerPC applications which used eieio will get the function
of mbar when executed on a PowerPC Book-E implementation. mbar is
architecturally "stronger" than eieio, in that eieio forced separate
ordering amongst different categories of storage accesses, while mbar
forces such ordering amongst all storage accesses as a single category.
msync replaces the PowerPC sync instruction. msync uses the same
opcode as sync; PowerPC applications which used sync get the function
of msync when executed on a PowerPC Book-E implementation. msync is
architecturally identical to the version of sync specified by an
earlier version of the PowerPC architecture.
> Do the 440* processors in fact claim Book E compliance?
Hmm, cannot tell :).
--
Eugene
^ 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