LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 3/5] Tsi108_eth: remove not needed code
From: Alexandre Bounine @ 2008-02-08 19:17 UTC (permalink / raw)
  To: jgarzik, netdev; +Cc: linuxppc-dev

Code clean-up for tsi108_eth network driver.
This patch removes not needed dummy read and the corresponding comment.
The PHY logic requires two reads from the status register to get=20
current link status. This is done correctly inside mii_check_media().=20=20
=20=20=20
Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
---

diff -pNur linux-2.6.24/drivers/net/tsi108_eth.c
linux-2.6.24-fix/drivers/net/tsi108_eth.c
--- linux-2.6.24/drivers/net/tsi108_eth.c	2008-02-06
15:47:35.000000000 -0500
+++ linux-2.6.24-fix/drivers/net/tsi108_eth.c	2008-02-06
15:54:14.000000000 -0500
@@ -297,18 +297,11 @@ static void tsi108_check_phy(struct net_
 	u32 speed;
 	unsigned long flags;
=20
-	/* Do a dummy read, as for some reason the first read
-	 * after a link becomes up returns link down, even if
-	 * it's been a while since the link came up.
-	 */
-
 	spin_lock_irqsave(&phy_lock, flags);
=20
 	if (!data->phy_ok)
 		goto out;
=20
-	tsi108_read_mii(data, MII_BMSR);
-
 	duplex =3D mii_check_media(&data->mii_if, netif_msg_link(data),
data->init_media);
 	data->init_media =3D 0;
=20



---=0D
=0D
Important Notice: This message is intended for the use of the individual to=
 whom it is addressed and may contain information which is privileged, conf=
idential and/or exempt from disclosure under applicable law. If the reader =
of this message is not the intended recipient, or is not the employee or ag=
ent responsible for delivering the message to the intended recipient, you a=
re hereby notified that any dissemination, distribution, or copying of this=
 communication is strictly prohibited. If you have received this communicat=
ion in error, please notify the sender immediately by telephone or return e=
-mail and delete the original message from your systems. Thank you. =0D

^ permalink raw reply

* [PATCH] powerpc: fix DEBUG_PREEMPT warning when warning
From: Hugh Dickins @ 2008-02-08 18:25 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-dev, linux-kernel

The powerpc show_regs prints CPU using smp_processor_id: change that to
raw_smp_processor_id, so that when it's showing a WARN_ON backtrace without
preemption disabled, DEBUG_PREEMPT doesn't mess up that warning with its own.

Signed-off-by: Hugh Dickins <hugh@veritas.com>
---

 powerpc/kernel/process.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- 2.6.24-git18/arch/powerpc/kernel/process.c	2008-01-24 22:58:37.000000000 +0000
+++ linux/arch/powerpc/kernel/process.c	2008-02-08 12:01:31.000000000 +0000
@@ -462,7 +462,7 @@ void show_regs(struct pt_regs * regs)
 	       current, task_pid_nr(current), current->comm, task_thread_info(current));
 
 #ifdef CONFIG_SMP
-	printk(" CPU: %d", smp_processor_id());
+	printk(" CPU: %d", raw_smp_processor_id());
 #endif /* CONFIG_SMP */
 
 	for (i = 0;  i < 32;  i++) {

^ permalink raw reply

* Re: APU FPU in Virtex ppc405
From: Grant Likely @ 2008-02-08 19:32 UTC (permalink / raw)
  To: A. Nolson; +Cc: linuxppc-embedded
In-Reply-To: <47ACA4BB.6010903@gmail.com>

On Feb 8, 2008 11:51 AM, A. Nolson <alohanono@gmail.com> wrote:
> Hi,
>
>  I have just heard that Xilinx has freed the FPU module for the PPC
> architecture in EDK9.2i. WIll I be able to make it work with my
> Secretlab Linux 2.6.24rc3? Will the eldk toolchain for PPC_4xxfp work?
> Will it be just a matter of integrating it with the XPS BSP?I make an
> extensive use of floating point in my applications and this will be
> really useful.

It's been 2 years since I last played with the FPU core.  At the time
it wasn't a complete FPU so the eldk 4xxfp toolchain would not work.
I had to build my own.  I don't know if the new core is a complete
implementation.

Cheers,
g.


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply

* Re: Leds
From: Grant Likely @ 2008-02-08 19:43 UTC (permalink / raw)
  To: Simon Kagstrom; +Cc: Marco Stornelli, LinuxPPC-Embedded
In-Reply-To: <20080208112002.42a15c0d@seasc0532.dyn.rnd.as.sw.ericsson.se>

On Feb 8, 2008 3:20 AM, Simon Kagstrom <simon.kagstrom@ericsson.com> wrote:
> Hi Marco,
>
> On Fri, 08 Feb 2008 11:02:16 +0100
> Marco Stornelli <marco.stornelli@coritel.it> wrote:
>
> > how can specify a led device in a dts file? These leds are connected
> > with gpio to the microprocessor. I can't find anything like a led node
> > in the dts files of the other boards. Have you got any suggestions?
>
> Although I'm not sure if it's the "standard" way, we just added a
> "home-made" node like this:
>
>         resetLED@c0018000 {
>                 device_type = "leds";
>                 compatible = "reset-leds";
>                 reg = <c0018000 00008000>;
>         };

I've been thinking about this a bit over the last couple of months,
and I think that there is a better way.  Since many LEDs are simply
hooked up to GPIO blocks and we're moving towards a common GPIO api
(and device tree binding), I think it would be better to use two
nodes; a node for the gpio block and a node for all the LEDs in the
system.  For example (the GPIO dt bindings may differ from my example
here, but you get the gist):

GPIO0: gpio-controller@1418 {
        #gpio-cells = <2>;
        compatible = "fsl,qe-pario-bank";
        reg = <0x1418 0x18>;
        gpio-controller;
};
GPIO1: gpio-controller@1460 {
        #gpio-cells = <2>;
        compatible = "fsl,qe-pario-bank";
        reg = <0x1460 0x18>;
        gpio-controller;
};

leds@0 {
        compatible = "gpio-leds";
        led-labels = "led1", "led2", "led3", "led4";
        gpios = <&GPIO0  2 0 /* LED1 */
                 &GPIO0  3 0 /* LED2 */
                 &GPIO1  8 0 /* LED3 */
                 &GPIO1  9 0 /* LED4 */
                 >;
        /* More properties are probably needed here to correctly setup
the output levels */
};

Doing it this way means the GPIO block will be usable for more than
just LEDs.  Plus once the 'gpio-leds' driver is written leds can be
hooked up almost trivially on new boards.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply

* [patch 0/6] PS3 fixups for 2.6.25
From: Geoff Levand @ 2008-02-08 22:52 UTC (permalink / raw)
  To: paulus; +Cc: linuxppc-dev

Paul,

Here are a few PS3 fixups to apply for 2.6.25.

  [patch 1/6] PS3: Fix lpm set bookmark
  [patch 2/6] PS3: Fix lpm read pm interval
  [patch 3/6] PS3: Fix bootwrapper hang bug
  [patch 4/6] PS3: Use system reboot on restart
  [patch 5/6] PS3: Sys-manager code cleanup
  [patch 6/6] PS3: Update sys-manager button events

-Geoff




-- 

^ permalink raw reply

* [patch 1/6] PS3: Fix lpm set bookmark
From: Geoff Levand @ 2008-02-08 22:52 UTC (permalink / raw)
  To: paulus; +Cc: linuxppc-dev, Takashi Yamamoto
In-Reply-To: <20080208224723.029462363@am.sony.com>

From: Takashi Yamamoto <TakashiA.Yamamoto@jp.sony.com>

Fix the ps3_set_bookmark() routine of the PS3 logical performance
monitor driver.

To properly set a performance monitor bookmark the Cell processor
requires no instruction branches near the setting of the bookmark
SPR.  Testing showed that the use of the db10cyc instruction did
not work correctly.  This change replaces the db10cyc instruction
with 10 nop instructions.

Signed-off-by: Takashi Yamamoto <TakashiA.Yamamoto@jp.sony.com>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
 drivers/ps3/ps3-lpm.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/ps3/ps3-lpm.c
+++ b/drivers/ps3/ps3-lpm.c
@@ -181,9 +181,9 @@ void ps3_set_bookmark(u64 bookmark)
 	 * includes cycles before the call.
 	 */
 
-	asm volatile("or 29, 29, 29;"); /* db10cyc */
+	asm volatile("nop;nop;nop;nop;nop;nop;nop;nop;nop;");
 	mtspr(SPRN_BKMK, bookmark);
-	asm volatile("or 29, 29, 29;"); /* db10cyc */
+	asm volatile("nop;nop;nop;nop;nop;nop;nop;nop;nop;");
 }
 EXPORT_SYMBOL_GPL(ps3_set_bookmark);
 

-- 

^ permalink raw reply

* [patch 2/6] PS3: Fix lpm read pm interval
From: Geoff Levand @ 2008-02-08 22:52 UTC (permalink / raw)
  To: paulus; +Cc: linuxppc-dev, Takashi Yamamoto
In-Reply-To: <20080208224723.029462363@am.sony.com>

From: Takashi Yamamoto <TakashiA.Yamamoto@jp.sony.com>

ps3_read_pm (pm_interval) should return an actual HW register value
because the pm_interval register is a counter register.
This patch removes the shadow pm_interval register.

Signed-off-by: Takashi Yamamoto <TakashiA.Yamamoto@jp.sony.com>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
 drivers/ps3/ps3-lpm.c |   18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)

--- a/drivers/ps3/ps3-lpm.c
+++ b/drivers/ps3/ps3-lpm.c
@@ -76,7 +76,6 @@
  *
  * @pm_control: Shadow of the processor's pm_control register.
  * @pm_start_stop: Shadow of the processor's pm_start_stop register.
- * @pm_interval: Shadow of the processor's pm_interval register.
  * @group_control: Shadow of the processor's group_control register.
  * @debug_bus_control: Shadow of the processor's debug_bus_control register.
  *
@@ -91,7 +90,6 @@
 struct ps3_lpm_shadow_regs {
 	u64 pm_control;
 	u64 pm_start_stop;
-	u64 pm_interval;
 	u64 group_control;
 	u64 debug_bus_control;
 };
@@ -408,7 +406,14 @@ u32 ps3_read_pm(u32 cpu, enum pm_reg_nam
 	case pm_start_stop:
 		return lpm_priv->shadow.pm_start_stop;
 	case pm_interval:
-		return lpm_priv->shadow.pm_interval;
+		result = lv1_set_lpm_interval(lpm_priv->lpm_id, 0, 0, &val);
+		if (result) {
+			val = 0;
+			dev_dbg(sbd_core(), "%s:%u: lv1 set_inteval failed: "
+				"reg %u, %s\n", __func__, __LINE__, reg,
+				ps3_result(result));
+		}
+		return (u32)val;
 	case group_control:
 		return lpm_priv->shadow.group_control;
 	case debug_bus_control:
@@ -475,10 +480,8 @@ void ps3_write_pm(u32 cpu, enum pm_reg_n
 		lpm_priv->shadow.pm_control = val;
 		break;
 	case pm_interval:
-		if (val != lpm_priv->shadow.pm_interval)
-			result = lv1_set_lpm_interval(lpm_priv->lpm_id, val,
-						   PS3_WRITE_PM_MASK, &dummy);
-		lpm_priv->shadow.pm_interval = val;
+		result = lv1_set_lpm_interval(lpm_priv->lpm_id, val,
+					      PS3_WRITE_PM_MASK, &dummy);
 		break;
 	case pm_start_stop:
 		if (val != lpm_priv->shadow.pm_start_stop)
@@ -1140,7 +1143,6 @@ int ps3_lpm_open(enum ps3_lpm_tb_type tb
 
 	lpm_priv->shadow.pm_control = PS3_LPM_SHADOW_REG_INIT;
 	lpm_priv->shadow.pm_start_stop = PS3_LPM_SHADOW_REG_INIT;
-	lpm_priv->shadow.pm_interval = PS3_LPM_SHADOW_REG_INIT;
 	lpm_priv->shadow.group_control = PS3_LPM_SHADOW_REG_INIT;
 	lpm_priv->shadow.debug_bus_control = PS3_LPM_SHADOW_REG_INIT;
 

-- 

^ permalink raw reply

* [patch 3/6] PS3: Fix bootwrapper hang bug
From: Geoff Levand @ 2008-02-08 22:52 UTC (permalink / raw)
  To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20080208224723.029462363@am.sony.com>

Fix a bug in the lv1_get_repository_node_value() routine of the PS3
bootwrapper.  Changes in the PS3 system firmware 2.20 cause this bug
to hang the system when branching from the bootwrapper to the kernel
_start.

Since the video system has not yet been enabled at the time
the bug is hit, the system hangs with a blank screen.  Earlier
firmwares don't cause such a catastrophic failure, and so this
bug went undetected.

Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
 arch/powerpc/boot/ps3-hvcall.S |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/powerpc/boot/ps3-hvcall.S
+++ b/arch/powerpc/boot/ps3-hvcall.S
@@ -145,7 +145,7 @@
 .macro STORE_REGS_5_2
 	lwz r11, 16(r1)
 	std r4, 0(r11)
-	lwz r11, 24(r1)
+	lwz r11, 20(r1)
 	std r5, 0(r11)
 .endm
 

-- 

^ permalink raw reply

* [patch 4/6] PS3: Use system reboot on restart
From: Geoff Levand @ 2008-02-08 22:52 UTC (permalink / raw)
  To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20080208224723.029462363@am.sony.com>

The PS3 Other OS boot flag is not checked when an LPAR reboot is done,
so the ps3-boot-game-os utility fails to reboot the system into the
Game OS.  This fix changes the PS3 restart handler from requesting an
PS3_SM_NEXT_OP_LPAR_REBOOT to requesting an PS3_SM_NEXT_OP_SYS_REBOOT.

Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
 drivers/ps3/ps3-sys-manager.c |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/ps3/ps3-sys-manager.c
+++ b/drivers/ps3/ps3-sys-manager.c
@@ -622,7 +622,7 @@ static void ps3_sys_manager_final_restar
 	ps3_vuart_cancel_async(dev);
 
 	ps3_sys_manager_send_attr(dev, 0);
-	ps3_sys_manager_send_next_op(dev, PS3_SM_NEXT_OP_LPAR_REBOOT,
+	ps3_sys_manager_send_next_op(dev, PS3_SM_NEXT_OP_SYS_REBOOT,
 		PS3_SM_WAKE_DEFAULT);
 	ps3_sys_manager_send_request_shutdown(dev);
 

-- 

^ permalink raw reply

* [patch 6/6] PS3: Update sys-manager button events
From: Geoff Levand @ 2008-02-08 22:53 UTC (permalink / raw)
  To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20080208224723.029462363@am.sony.com>

PS3 firmware 1.94 added the source of power and reset events to the
payload of the system manager POWER_PRESSED and RESET_PRESSED events.

Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
 drivers/ps3/ps3-sys-manager.c |   29 +++++++++++++++++++++++------
 1 file changed, 23 insertions(+), 6 deletions(-)

--- a/drivers/ps3/ps3-sys-manager.c
+++ b/drivers/ps3/ps3-sys-manager.c
@@ -138,9 +138,11 @@ enum ps3_sys_manager_attr {
 
 /**
  * enum ps3_sys_manager_event - External event type, reported by system manager.
- * @PS3_SM_EVENT_POWER_PRESSED: payload.value not used.
+ * @PS3_SM_EVENT_POWER_PRESSED: payload.value =
+ *  enum ps3_sys_manager_button_event.
  * @PS3_SM_EVENT_POWER_RELEASED: payload.value = time pressed in millisec.
- * @PS3_SM_EVENT_RESET_PRESSED: payload.value not used.
+ * @PS3_SM_EVENT_RESET_PRESSED: payload.value =
+ *  enum ps3_sys_manager_button_event.
  * @PS3_SM_EVENT_RESET_RELEASED: payload.value = time pressed in millisec.
  * @PS3_SM_EVENT_THERMAL_ALERT: payload.value = thermal zone id.
  * @PS3_SM_EVENT_THERMAL_CLEARED: payload.value = thermal zone id.
@@ -158,6 +160,17 @@ enum ps3_sys_manager_event {
 };
 
 /**
+ * enum ps3_sys_manager_button_event - Button event payload values.
+ * @PS3_SM_BUTTON_EVENT_HARD: Hardware generated event.
+ * @PS3_SM_BUTTON_EVENT_SOFT: Software generated event.
+ */
+
+enum ps3_sys_manager_button_event {
+	PS3_SM_BUTTON_EVENT_HARD = 0,
+	PS3_SM_BUTTON_EVENT_SOFT = 1,
+};
+
+/**
  * enum ps3_sys_manager_next_op - Operation to perform after lpar is destroyed.
  */
 
@@ -416,8 +429,10 @@ static int ps3_sys_manager_handle_event(
 
 	switch (event.type) {
 	case PS3_SM_EVENT_POWER_PRESSED:
-		dev_dbg(&dev->core, "%s:%d: POWER_PRESSED\n",
-			__func__, __LINE__);
+		dev_dbg(&dev->core, "%s:%d: POWER_PRESSED (%s)\n",
+			__func__, __LINE__,
+			(event.value == PS3_SM_BUTTON_EVENT_SOFT ? "soft"
+			: "hard"));
 		ps3_sm_force_power_off = 1;
 		/*
 		 * A memory barrier is use here to sync memory since
@@ -432,8 +447,10 @@ static int ps3_sys_manager_handle_event(
 			__func__, __LINE__, event.value);
 		break;
 	case PS3_SM_EVENT_RESET_PRESSED:
-		dev_dbg(&dev->core, "%s:%d: RESET_PRESSED\n",
-			__func__, __LINE__);
+		dev_dbg(&dev->core, "%s:%d: RESET_PRESSED (%s)\n",
+			__func__, __LINE__,
+			(event.value == PS3_SM_BUTTON_EVENT_SOFT ? "soft"
+			: "hard"));
 		ps3_sm_force_power_off = 0;
 		/*
 		 * A memory barrier is use here to sync memory since

-- 

^ permalink raw reply

* Could the DTS experts look at this?
From: Sean MacLennan @ 2008-02-08 23:30 UTC (permalink / raw)
  To: LinuxPPC-dev

The Rev B warp is moving to a 4M NOR / 256M NAND flash setup from the 
current 64M NOR / 64M NAND. I would like to keep support for the 64M NOR 
so I modified the boot code to be a bit more dynamic. Here is the new 
NOR parition layout in the DTS:

nor_flash@0,0 {
	compatible = "amd,s29gl512n", "cfi-flash";
	bank-width = <2>;
	reg = <0 0 4000000>;
	#address-cells = <1>;
	#size-cells = <1>;
	partition@300000 {
		label = "fpga";
		reg = <300000 40000>;
	};
	partition@340000 {
		label = "env";
		reg = <340000 40000>;
	};
	partition@380000 {
		label = "u-boot";
		reg = <380000 80000>;
	};
};

Yes, the top of the NOR will be empty. Here is the code from 
cuboot-warp.c to handle fixups for the 64M flash:

static void warp_fixup_one_nor(u32 from, u32 to)
{
	void *devp;
	char name[40];
	u32 v[2];

	sprintf(name, "/plb/opb/ebc/nor_flash@0,0/partition@%x", from);

	devp = finddevice(name);
	if (!devp) return;

	if (getprop(devp, "reg", v, sizeof(v)) == sizeof(v)) {
		v[0] = to;
		setprop(devp, "reg", v, sizeof(v));

		printf("NOR 64M fixup %x -> %x\n", from, to);
	}
}


static void warp_fixups(void)
{
	unsigned long sysclk = 66000000;

	ibm440ep_fixup_clocks(sysclk, 11059200, 50000000);
	ibm4xx_sdram_fixup_memsize();
	ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
	dt_fixup_mac_addresses(&bd.bi_enetaddr);

	/* Fixup for 64M flash on Rev A boards. */
	if(bd.bi_flashsize == 0x4000000) {
		warp_fixup_one_nor(0x300000, 0x3f00000);
		warp_fixup_one_nor(0x340000, 0x3f40000);
		warp_fixup_one_nor(0x380000, 0x3f80000);
	}
}

I have tested this with the 64M NOR, and it seems to work. However, are 
there going to be problems with the partition name not matching the reg 
address entry?

If anybody has suggestions on better ways to do this, fire away.

And looking at this code, and other board ports, why is sysclk a local 
variable and all the other numbers hardcoded in the args? I left it the 
same way as the others but it does look a bit strange.

Cheers,
   Sean

^ permalink raw reply

* [patch 5/6] PS3: Sys-manager code cleanup
From: Geoff Levand @ 2008-02-08 22:53 UTC (permalink / raw)
  To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20080208224723.029462363@am.sony.com>

General code cleanups for PS3 system-manager:
 o Move all MODULE_ macros to bottom.
 o Correct PS3_SM_WAKE_P_O_R value.
 o Enhance comment on wakeup source values.

Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
 drivers/ps3/ps3-sys-manager.c |   13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

--- a/drivers/ps3/ps3-sys-manager.c
+++ b/drivers/ps3/ps3-sys-manager.c
@@ -28,10 +28,6 @@
 
 #include "vuart.h"
 
-MODULE_AUTHOR("Sony Corporation");
-MODULE_LICENSE("GPL v2");
-MODULE_DESCRIPTION("PS3 System Manager");
-
 /**
  * ps3_sys_manager - PS3 system manager driver.
  *
@@ -181,7 +177,9 @@ enum ps3_sys_manager_next_op {
  * @PS3_SM_WAKE_P_O_R: Power on reset.
  *
  * Additional wakeup sources when specifying PS3_SM_NEXT_OP_SYS_SHUTDOWN.
- * System will always wake from the PS3_SM_WAKE_DEFAULT sources.
+ * The system will always wake from the PS3_SM_WAKE_DEFAULT sources.
+ * Sources listed here are the only ones available to guests in the
+ * other-os lpar.
  */
 
 enum ps3_sys_manager_wake_source {
@@ -189,7 +187,7 @@ enum ps3_sys_manager_wake_source {
 	PS3_SM_WAKE_DEFAULT   = 0,
 	PS3_SM_WAKE_RTC       = 0x00000040,
 	PS3_SM_WAKE_RTC_ERROR = 0x00000080,
-	PS3_SM_WAKE_P_O_R     = 0x10000000,
+	PS3_SM_WAKE_P_O_R     = 0x80000000,
 };
 
 /**
@@ -699,4 +697,7 @@ static int __init ps3_sys_manager_init(v
 module_init(ps3_sys_manager_init);
 /* Module remove not supported. */
 
+MODULE_AUTHOR("Sony Corporation");
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("PS3 System Manager");
 MODULE_ALIAS(PS3_MODULE_ALIAS_SYSTEM_MANAGER);

-- 

^ permalink raw reply

* Re: porting xenomaii for power pc 750Cxe based SBC
From: Wolfgang Grandegger @ 2008-02-09 16:11 UTC (permalink / raw)
  To: rakesh bk; +Cc: linuxppc-embedded
In-Reply-To: <43455a600802070411w42b6745aqf87fa3ae88dcaf8c@mail.gmail.com>

rakesh bk wrote:
> Hello Everyone,
> 
> Iam Trying to port the xenomai-2.2.0 using the
> "adeos-ipipe-2.6.14-ppc-1.3-05.patch"  to linux-kernel 2.6.14( Vanilla)
> to our custom based SBC, After applying patches as i get Enough printk's
> on my console , I get Stucked after UNMASKING of Ethernet Irq The
> following are the printk messages after i tried to boot the image. can i
> know what the actual problem is ...........

This mail is off topic. Please repost on the Xenomai-help mailing list
(https://gna.org/mail/?group=xenomai). As you can see from your boot
log, already the Xenomai initialization fails.

Wolfgang.

^ permalink raw reply

* [PATCH] Fix for Freescale ppc cores: major revision detection
From: Martin Langer @ 2008-02-09 17:47 UTC (permalink / raw)
  To: linuxppc-dev

Ppc cores by Freescale are using the configuration field instead of the 
major revision field for their major revision number. Those field 
definitions come from include/asm-powerpc/reg.h.

Look at the pdf below and you will see that PVR_MAJ() does a wrong shift 
for ppc cores by Freescale. This patch fixes it.

http://www.freescale.com/files/archives/doc/support_info/PPCPVR.pdf


Signed-Off-By: Martin Langer <martin-langer@gmx.de>


--- arch/powerpc/kernel/setup-common.c.ORIGINAL	2008-02-08 22:22:56.000000000 +0100
+++ arch/powerpc/kernel/setup-common.c	2008-02-09 18:18:36.000000000 +0100
@@ -241,7 +241,7 @@
 	/* If we are a Freescale core do a simple check so
 	 * we dont have to keep adding cases in the future */
 	if (PVR_VER(pvr) & 0x8000) {
-		maj = PVR_MAJ(pvr);
+		maj = (pvr >> 8) & 0xF;
 		min = PVR_MIN(pvr);
 	} else {
 		switch (PVR_VER(pvr)) {

^ permalink raw reply

* Re: [PATCH 06/18] ide: factor out code unregistering devices from ide_unregister()
From: Sergei Shtylyov @ 2008-02-09 18:07 UTC (permalink / raw)
  To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <20080208004502.17746.73284.sendpatchset@localhost.localdomain>

Bartlomiej Zolnierkiewicz wrote:

> Factor out code unregistering devices from ide_unregister() to
> ide_port_unregister_devices().

> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>

MBR, Sergei

^ permalink raw reply

* Re: [PATCH 07/18] ide: factor out devices init from ide_init_port_data()
From: Sergei Shtylyov @ 2008-02-09 18:10 UTC (permalink / raw)
  To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <20080208004509.17746.70379.sendpatchset@localhost.localdomain>

Bartlomiej Zolnierkiewicz wrote:

> * Factor out devices init from ide_init_port_data() to
>   ide_port_init_devices_data().

> While at it:

> * Add explicit clearing of IDE device structure.

> There should be no functionality changes caused by this patch.

> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>

MBR, Sergei

^ permalink raw reply

* Ebony development board
From: Zoltan HERPAI @ 2008-02-09 19:37 UTC (permalink / raw)
  To: linuxppc-embedded

Hi,

I've recently got an Ebony board (440GP) with the original bootloader 
(440GP 1.18 ROM Monitor) which I would like to replace with U-boot. Is 
there a way to boot an U-boot image via TFTP to replace the bootloader, 
or is it possible only with using a JTAG? I've googled through the 
mailing list, but most of the related hits are dated back in 2004-2005, 
they say no, one have to use JTAG, but some time passed since then, and 
I would like to know if there is a way for this.

Thanks in advance,
Zoltan HERPAI

^ permalink raw reply

* HDLC driver - dev_free_skb_irq causes Segfault
From: Russell McGuire @ 2008-02-10  2:32 UTC (permalink / raw)
  To: linuxppc-embedded

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

All,

So I am in the process of debugging my newly established HDLC driver.
More or less modeled after a simplified gianfar / ucc_geth idea.

However, after loading, etc. and using the following commands

-> insmod hdlc-8360.ko
-> sethdlc hdlc0 hdlc-eth
-> ifconfig hdlc0 up 192.168.1.100

All is well, and I am seeing IDL interrupts. Great.

Now I go to ping an address like, 
ping 192.168.1.101

I can see that I get the start_xmit function, the IRQ from the QE comes back
and reports the TXBD as successfully sent.

Here is the problem, when I goto free the skb in the tx_handler, I get a 
'Unable to Handle Kernel Paging Request for data at address 0x00000000'
Even though for the life of me, I can't see any pointers that are at address
zero.

I have checked the pointer value I am passing in, and indeed it is the exact
same pointer I am receiving from the original 
start-xmit call..

Are we supposed to copy the skb? And free it immediately in the start_xmit?
Some special way to store the pointer? 

I have tried
txbd->buf = skb->data;
txbd->buf = virt_to_phys(skb->data);
etc.. and various other ways to save that I have seen in  the gianfar and
ucc_geth drivers.

My tx_sk_buff** is identical as alloced the same way. 

Anyone have any ideas?

-Russ




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

^ permalink raw reply

* of_iomap and request_mem_region
From: Jon Smirl @ 2008-02-10  2:38 UTC (permalink / raw)
  To: Linux/PPC Development

of_iomap doesn't implicitly do a request_mem_region().  How should
request_mem_region() be handled? When using of_iomap you don't get the
length of the region back so it isn't easy to call request_mem_region.

What about adding a third param to of_iomap for the driver name? If it
is non-null also do the request region. If it is null check to make
sure the region has already be requested.

-- 
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply

* Re: of_iomap and request_mem_region
From: Arnd Bergmann @ 2008-02-10  2:45 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <9e4733910802091838x3e596debj113089faef08c1c8@mail.gmail.com>

On Sunday 10 February 2008, Jon Smirl wrote:
> of_iomap doesn't implicitly do a request_mem_region(). =A0How should
> request_mem_region() be handled? When using of_iomap you don't get the
> length of the region back so it isn't easy to call request_mem_region.
>=20
> What about adding a third param to of_iomap for the driver name? If it
> is non-null also do the request region. If it is null check to make
> sure the region has already be requested.

I'd prefer changing of_iomap so that it gets the of_device instead of
the device_node. That would help us do two changes at once:

1. call request_mem_region using dev->driver->name, as you mentioned.
2. use managed registrations, as lib/devres.c does e.g. in pcim_iomap,
so that we can kill all the calls to iounmap in the cleanup path
of OF drivers.

maybe we can do a new ofm_iomap interface first, and then move
drivers over to use that one.

	Arnd <><

^ permalink raw reply

* Re: of_iomap and request_mem_region
From: Jon Smirl @ 2008-02-10  2:59 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200802100345.54580.arnd@arndb.de>

On 2/9/08, Arnd Bergmann <arnd@arndb.de> wrote:
> On Sunday 10 February 2008, Jon Smirl wrote:
> > of_iomap doesn't implicitly do a request_mem_region().  How should
> > request_mem_region() be handled? When using of_iomap you don't get the
> > length of the region back so it isn't easy to call request_mem_region.
> >
> > What about adding a third param to of_iomap for the driver name? If it
> > is non-null also do the request region. If it is null check to make
> > sure the region has already be requested.
>
> I'd prefer changing of_iomap so that it gets the of_device instead of
> the device_node. That would help us do two changes at once:
>
> 1. call request_mem_region using dev->driver->name, as you mentioned.
> 2. use managed registrations, as lib/devres.c does e.g. in pcim_iomap,
> so that we can kill all the calls to iounmap in the cleanup path
> of OF drivers.
>
> maybe we can do a new ofm_iomap interface first, and then move
> drivers over to use that one.

There are only four drivers using of_iomap. It is not much work to
change them. Looking at them I don't see any that request the
resource. That's probably because they don't have the length needed to
make the call.

There are a lot of drivers using of_address_to_resource. They could
probably be converted to of_iomap if it gets changed. All of the ones
I checked follow the of_address_to_resource with a request_resource
call.

>
>         Arnd <><
>
>


-- 
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply

* Re: of_iomap and request_mem_region
From: Arnd Bergmann @ 2008-02-10  3:14 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <9e4733910802091859o3e91b6f6y4b0e6b31f722d8e6@mail.gmail.com>

On Sunday 10 February 2008, Jon Smirl wrote:
> On 2/9/08, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Sunday 10 February 2008, Jon Smirl wrote:
> > > of_iomap doesn't implicitly do a request_mem_region().  How should
> > > request_mem_region() be handled? When using of_iomap you don't get the
> > > length of the region back so it isn't easy to call request_mem_region.
> > >
> > > What about adding a third param to of_iomap for the driver name? If it
> > > is non-null also do the request region. If it is null check to make
> > > sure the region has already be requested.
> >
> > I'd prefer changing of_iomap so that it gets the of_device instead of
> > the device_node. That would help us do two changes at once:
> >
> > 1. call request_mem_region using dev->driver->name, as you mentioned.
> > 2. use managed registrations, as lib/devres.c does e.g. in pcim_iomap,
> > so that we can kill all the calls to iounmap in the cleanup path
> > of OF drivers.
> >
> > maybe we can do a new ofm_iomap interface first, and then move
> > drivers over to use that one.
> 
> There are only four drivers using of_iomap.

$ git-ls-files | xargs grep of_iomap | cut -f 1 -d: | uniq | wc -l
19

Unfortunately, many of them don't even use an of_device, so the
conversion is not trivial.

> There are a lot of drivers using of_address_to_resource. They could
> probably be converted to of_iomap if it gets changed. All of the ones
> I checked follow the of_address_to_resource with a request_resource
> call.

Right, but again, we are still in the progress of converting drivers
from using of_find_node_by_type() and similar to of_platform_driver.
If we don't have an of_device, the interface as I would prefer
it doesn't work.

	Arnd <><

^ permalink raw reply

* Re: Could the DTS experts look at this?
From: Arnd Bergmann @ 2008-02-10  5:47 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <47ACE630.8090101@pikatech.com>

On Saturday 09 February 2008, Sean MacLennan wrote:
> If anybody has suggestions on better ways to do this, fire away.

I guess the cleanest solution would be to include two complete device trees
for this platform, and then choose the correct one in cuboot-warp.c based
on the board revision.

The obvious disadvantage of this is that you'd get two device trees
that you need to keep in sync with every change, so it might not
be very practical.

Maybe we can introduce a more generic way of having conditional
device nodes in the tree that get knocked out in the boot wrapper.

	Arnd <><

^ permalink raw reply

* Re: Could the DTS experts look at this?
From: Sean MacLennan @ 2008-02-10  6:05 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: LinuxPPC-dev
In-Reply-To: <200802100647.56590.arnd@arndb.de>

Arnd Bergmann wrote:
> I guess the cleanest solution would be to include two complete device trees
> for this platform, and then choose the correct one in cuboot-warp.c based
> on the board revision.
>
> The obvious disadvantage of this is that you'd get two device trees
> that you need to keep in sync with every change, so it might not
> be very practical.
>
>   
Keeping two device trees would be awkward. My final solution will 
probably be to just have
the 4M flash partition layout. Since we really only use the partition 
information to write to the partitions from a user mode program, I can 
live with having to flash the images from u-boot.

But if we where planning on moving forward with two configurations, 
which we where planning to do, this would not be an option. We would 
need to auto configure *and* possibly add partitions based on size.

> Maybe we can introduce a more generic way of having conditional
> device nodes in the tree that get knocked out in the boot wrapper.
>   
Of even a way to have ifdefs in the dts. In this case, we have to build 
a specific version of u-boot for each nor size (WARNING: This may not be 
*technically* true, but this is how we are handling it). Having to set a 
config and build a specific kernel, while not ideal, would also be a 
reasonable solution.

Just throwing out ideas. In the short term this is not a problem, but in 
the long term?

Cheers,
   Sean

^ permalink raw reply

* pci_proc_init: proc_dir_entry '00' already registered
From: Olaf Hering @ 2008-02-10 10:07 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev

Current Linus tree gives this new warning during bootup:

+proc_dir_entry '00' already registered
+Call Trace:
+[c00000007b0dfba0] [c00000000000e4b0] .show_stack+0x70/0x1bc (unreliable)
+[c00000007b0dfc50] [c0000000000f2714] .proc_register+0x130/0x210
+[c00000007b0dfd00] [c0000000000f299c] .proc_mkdir_mode+0x40/0x70
+[c00000007b0dfd80] [c000000000276ed8] .pci_proc_attach_device+0xac/0x144
+[c00000007b0dfe20] [c0000000005bdb3c] .pci_proc_init+0x74/0xac
+[c00000007b0dfea0] [c0000000005a27ac] .kernel_init+0x1d0/0x394
+[c00000007b0dff90] [c00000000001e258] .kernel_thread+0x4c/0x68

Its a dualcore G5.


DART table allocated at: c00000007f000000
Using PowerMac machine description
Page orders: linear mapping = 24, virtual = 12, io = 12
Found initrd at 0xc000000001300000:0xc000000001559c00
Found U4 memory controller & host bridge @ 0xf8000000 revision: 0x42
Mapped at 0xd000080080000000
Found a Shasta mac-io controller, rev: 0, mapped at 0xd000080080041000
PowerMac motherboard: PowerMac G5 Dual Core
DART IOMMU initialized for U4 type chipset
console [udbg0] enabled
CPU maps initialized for 1 thread per core
 (thread shift is 0)
Starting Linux PPC64 #221 SMP Sun Feb 10 10:50:00 CET 2008
-----------------------------------------------------
ppc64_pft_size                = 0x0
physicalMemorySize            = 0x80000000
htab_address                  = 0xc00000007c000000
htab_hash_mask                = 0x3ffff
-----------------------------------------------------
Linux version 2.6.24-g5-00000-g25f6663 (olaf@g5) (gcc version 4.1.0 (SUSE Linux)) #221 SMP Sun Feb 10 10:50:00 CET 2008
[boot]0012 Setup Arch
Entering add_active_range(0, 0, 524288) 0 entries of 256 used
Found U4-PCIE PCI host bridge.  Firmware bus number: 0->255
PCI host bridge /pci@0,f0000000  ranges:
 MEM 0x00000000f1000000..0x00000000f1ffffff -> 0x00000000f1000000 
  IO 0x00000000f0000000..0x00000000f07fffff -> 0x0000000000000000
 MEM 0x0000000090000000..0x00000000afffffff -> 0x0000000090000000 
Can't get bus-range for /ht@0,f2000000, assume bus 0
Found U3-HT PCI host bridge.  Firmware bus number: 0->239
PCI host bridge /ht@0,f2000000 (primary) ranges:
SMU: Driver 0.7 (c) 2005 Benjamin Herrenschmidt, IBM Corp.
nvram: Checking bank 0...
nvram: gen0=208, gen1=209
nvram: Active bank is: 1
nvram: OF partition at 0x410
nvram: XP partition at 0x1020
nvram: NR partition at 0x1120
Top of RAM: 0x80000000, Total RAM: 0x80000000
Memory hole size: 0MB
Zone PFN ranges:
  DMA             0 ->   524288
  Normal     524288 ->   524288
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:        0 ->   524288
On node 0 totalpages: 524288
  DMA zone: 7168 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 517120 pages, LIFO batch:31
  Normal zone: 0 pages used for memmap
  Movable zone: 0 pages used for memmap
[boot]0015 Setup Done
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 517120
Kernel command line: root=UUID=a77c3a2a-dd4a-4cf6-8c74-287c49897b10 sysrq=1 quiet video=nvidiafb:1024x768@85,bpp:16 panic=12 
mpic: Setting up MPIC " MPIC 1   " version 1.2 at f8040000, max 4 CPUs
mpic: ISU size: 124, shift: 7, mask: 7f
mpic: Initializing for 124 sources
mpic: Setting up HT PICs workarounds for U3/U4
mpic:   - HT:07.0 [0x90] vendor 106b device 0053 has 86 irqs
PID hash table entries: 4096 (order: 12, 32768 bytes)
time_init: decrementer frequency = 33.333333 MHz
time_init: processor frequency   = 2300.000000 MHz
clocksource: timebase mult[7800001] shift[22] registered
clockevent: decrementer mult[888] shift[16] cpu[0]
Console: colour dummy device 80x25
console handover: boot [udbg0] -> real [tty0]
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Memory: 2005248k/2097152k available (5984k kernel code, 91208k reserved, 940k data, 489k bss, 216k init)
Calibrating delay loop... 66.56 BogoMIPS (lpj=332800)
Mount-cache hash table entries: 256
device-tree: Duplicate name in /ht@0,f2000000/pci@8/mac-io@7/i2c@18000, renamed to "i2c-bus@0#1"
PowerMac SMP probe found 2 cpus
KeyWest i2c @0xf8001003 irq 16 /u4@0,f8000000/i2c@f8001000
 channel 1 bus /u4@0,f8000000/i2c@f8001000/i2c-bus@1
KeyWest i2c @0x80018000 irq 27 /ht@0,f2000000/pci@8/mac-io@7/i2c@18000
 channel 0 bus /ht@0,f2000000/pci@8/mac-io@7/i2c@18000/i2c-bus@0
 channel 0 bus /ht@0,f2000000/pci@8/mac-io@7/i2c@18000/i2c-bus@0
SMU i2c /smu@0,0/smu-i2c-control@0
 channel b bus /smu@0,0/smu-i2c-control@0/i2c-bus@b
 channel e bus /smu@0,0/smu-i2c-control@0/i2c-bus@e
Processor timebase sync using platform function
mpic: requesting IPIs ... 
Processor 1 found.
clockevent: decrementer mult[888] shift[16] cpu[1]
Brought up 2 CPUs
net_namespace: 304 bytes
NET: Registered protocol family 16
PCI: Probing PCI hardware
IOMMU table initialized, virtual merging enabled
PCI: Closing bogus Apple Firmware region 2 on bus 0x0a
PCI: Closing bogus Apple Firmware region 2 on bus 0x02
PCI: Closing bogus Apple Firmware region 2 on bus 0x01
PCI: Closing bogus Apple Firmware region 2 on bus 0x03
PCI: Cannot allocate resource region 0 of device 0000:0a:00.0, will remap
PCI: Cannot allocate resource region 1 of device 0000:0a:00.0, will remap
PCI: Cannot allocate resource region 3 of device 0000:0a:00.0, will remap
PCI: Bridge: 0000:00:0b.0
  IO window: 0000-ffff
  MEM window: 0xa8000000-0xa9ffffff
  PREFETCH window: 0x0000000090000000-0x00000000a7ffffff
PCI: Bridge: 0001:00:01.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0001:00:02.0
  IO window: disabled.
  MEM window: 0xfa500000-0xfa5fffff
  PREFETCH window: disabled.
PCI: Bridge: 0001:00:03.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0001:00:04.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0001:00:05.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0001:00:06.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0001:00:07.0
  IO window: disabled.
  MEM window: 0xfa000000-0xfa3fffff
  PREFETCH window: disabled.
PCI: Bridge: 0001:00:08.0
  IO window: disabled.
  MEM window: 0x80000000-0x800fffff
  PREFETCH window: disabled.
PCI: Bridge: 0001:00:09.0
  IO window: disabled.
  MEM window: 0xfa400000-0xfa4fffff
  PREFETCH window: disabled.
PCI: Probing PCI hardware done
Registering pmac pic with sysfs...
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
Time: timebase clocksource has been installed.
Switched to high resolution mode on CPU 0
Switched to high resolution mode on CPU 1
IP route cache hash table entries: 65536 (order: 7, 524288 bytes)
TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
Unpacking initramfs... done
Freeing initrd memory: 2407k freed
nvram_init: Could not find nvram partition for nvram buffered error logging.
Registering G5 CPU frequency driver
Frequency method: SCOM, Voltage method: GPIO
Low: 1150 Mhz, High: 2300 Mhz, Cur: 2300 MHz
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
SGI XFS with large block/inode numbers, no debug enabled
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
proc_dir_entry '00' already registered
Call Trace:
[c00000007b0dfba0] [c00000000000e4b0] .show_stack+0x70/0x1bc (unreliable)
[c00000007b0dfc50] [c0000000000f2714] .proc_register+0x130/0x210
[c00000007b0dfd00] [c0000000000f299c] .proc_mkdir_mode+0x40/0x70
[c00000007b0dfd80] [c000000000276ed8] .pci_proc_attach_device+0xac/0x144
[c00000007b0dfe20] [c0000000005bdb3c] .pci_proc_init+0x74/0xac
[c00000007b0dfea0] [c0000000005a27ac] .kernel_init+0x1d0/0x394
[c00000007b0dff90] [c00000000001e258] .kernel_thread+0x4c/0x68
nvidiafb: Device ID: 10de0141 
nvidiafb: CRTC0 analog found
nvidiafb: CRTC1 analog found
i2c-adapter i2c-0: unable to read EDID block.
i2c-adapter i2c-0: unable to read EDID block.
i2c-adapter i2c-0: unable to read EDID block.
nvidiafb: Found OF EDID for head 1
nvidiafb: EDID found from BUS1
nvidiafb: EDID found from BUS2
nvidiafb: CRTC 0 appears to have a CRT attached
nvidiafb: Using CRT on CRTC 0
Console: switching to colour frame buffer device 128x48
nvidiafb: PCI nVidia NV14 framebuffer (64MB @ 0x90000000)
Generic RTC Driver v1.07
loop: module loaded
tg3.c:v3.87 (December 20, 2007)
eth0: Tigon3 [partno(BCM95780) rev 8003 PHY(5780)] (PCIX:133MHz:64-bit) 10/100/1000Base-T Ethernet 00:14:51:68:b7:00
eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[1] TSOcap[1]
eth0: dma_rwctrl[76144000] dma_mask[40-bit]
eth1: Tigon3 [partno(BCM95780) rev 8003 PHY(5780)] (PCIX:133MHz:64-bit) 10/100/1000Base-T Ethernet 00:14:51:68:b7:01
eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[1] TSOcap[1]
eth1: dma_rwctrl[76144000] dma_mask[40-bit]
usbcore: registered new interface driver asix
Linux video capture interface: v2.00
usbcore: registered new interface driver zr364xx
/home/olaf/kernel/linux-2.6/drivers/media/video/zr364xx.c: Zoran 364xx module loaded
MacIO PCI driver attached to Shasta chipset
windfarm: initializing for dual-core desktop G5
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PCI: Enabling device 0001:03:0d.0 (0004 -> 0006)
ide0: Found Apple Shasta ATA-6 controller, bus ID 3, irq 38
Probing IDE interface ide0...
hda: HL-DT-ST DVD-RW GWA-4165B, ATAPI CD/DVD-ROM drive
hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
hda: UDMA/66 mode selected
ide0 at 0xd0000800822fa000-0xd0000800822fa007,0xd0000800822fa160 on irq 38
hda: ATAPI 32X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache
Uniform CD-ROM driver Revision: 3.20
Driver 'sd' needs updating - please use bus_type methods
Driver 'sr' needs updating - please use bus_type methods
sata_svw 0001:03:0c.0: version 2.3
scsi0 : sata_svw
scsi1 : sata_svw
scsi2 : sata_svw
scsi3 : sata_svw
ata1: SATA max UDMA/133 mmio m8192@0xfa402000 port 0xfa402000 irq 18
ata2: SATA max UDMA/133 mmio m8192@0xfa402000 port 0xfa402100 irq 18
ata3: SATA max UDMA/133 mmio m8192@0xfa402000 port 0xfa402200 irq 18
ata4: SATA max UDMA/133 mmio m8192@0xfa402000 port 0xfa402300 irq 18
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-7: WDC WD2500JS-41MVB1, 10.02E01, max UDMA/133
ata1.00: 488397168 sectors, multi 0: LBA48 
ata1.00: configured for UDMA/133
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata2.00: ATA-7: Maxtor 6V250F0, VA111630, max UDMA/133
ata2.00: 490234752 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata2.00: configured for UDMA/133
ata3: SATA link down (SStatus 0 SControl 0)
ata4: SATA link down (SStatus 0 SControl 0)
scsi 0:0:0:0: Direct-Access     ATA      WDC WD2500JS-41M 10.0 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda: [mac] sda1 sda2 sda3 sda4 sda5 sda6 sda7
sd 0:0:0:0: [sda] Attached SCSI disk
sd 0:0:0:0: Attached scsi generic sg0 type 0
scsi 1:0:0:0: Direct-Access     ATA      Maxtor 6V250F0   VA11 PQ: 0 ANSI: 5
sd 1:0:0:0: [sdb] 490234752 512-byte hardware sectors (251000 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 1:0:0:0: [sdb] 490234752 512-byte hardware sectors (251000 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sdb: [mac] sdb1 sdb2 sdb3 sdb4 sdb5 sdb6 sdb7 sdb8 sdb9 sdb10 sdb11 sdb12
sd 1:0:0:0: [sdb] Attached SCSI disk
sd 1:0:0:0: Attached scsi generic sg1 type 0
PCI: Enabling device 0001:03:0e.0 (0000 -> 0002)
firewire_ohci: Added fw-ohci device 0001:03:0e.0, OHCI version 1.0
video1394: Installed video1394 module
ieee1394: raw1394: /dev/raw1394 device initialized
PCI: Enabling device 0001:01:0b.2 (0004 -> 0006)
ehci_hcd 0001:01:0b.2: EHCI Host Controller
ehci_hcd 0001:01:0b.2: new USB bus registered, assigned bus number 1
ehci_hcd 0001:01:0b.2: irq 70, io mem 0x80080000
ehci_hcd 0001:01:0b.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 5 ports detected
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.24-g5-00000-g25f6663 ehci_hcd
usb usb1: SerialNumber: 0001:01:0b.2
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
PCI: Enabling device 0001:01:0b.0 (0000 -> 0002)
ohci_hcd 0001:01:0b.0: OHCI Host Controller
ohci_hcd 0001:01:0b.0: new USB bus registered, assigned bus number 2
ohci_hcd 0001:01:0b.0: irq 70, io mem 0x80082000
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: OHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.24-g5-00000-g25f6663 ohci_hcd
usb usb2: SerialNumber: 0001:01:0b.0
PCI: Enabling device 0001:01:0b.1 (0000 -> 0002)
ohci_hcd 0001:01:0b.1: OHCI Host Controller
ohci_hcd 0001:01:0b.1: new USB bus registered, assigned bus number 3
ohci_hcd 0001:01:0b.1: irq 70, io mem 0x80081000
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
firewire_core: created new fw device fw0 (0 config rom retries, S800)
firewire_core: phy config: card 0, new root=ffc1, gap_count=5
usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb3: Product: OHCI Host Controller
usb usb3: Manufacturer: Linux 2.6.24-g5-00000-g25f6663 ohci_hcd
usb usb3: SerialNumber: 0001:01:0b.1
usb 2-1: new full speed USB device using ohci_hcd and address 2
usb 2-1: configuration #1 chosen from 2 choices
usb 2-1: New USB device found, idVendor=06cd, idProduct=0110
usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 2-1: Product: Keyspan USB Serial Adapter
usb 2-1: Manufacturer: Keyspan, a division of InnoSys Inc.
usb 3-2: new full speed USB device using ohci_hcd and address 2
usb 3-2: configuration #1 chosen from 1 choice
hub 3-2:1.0: USB hub found
hub 3-2:1.0: 3 ports detected
usb 3-2: New USB device found, idVendor=05ac, idProduct=1003
usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 3-2: Product: Hub in Apple Extended USB Keyboard
usb 3-2: Manufacturer: Mitsumi Electric
usbcore: registered new interface driver usblp
Initializing USB Mass Storage driver...
usb 3-2.1: new low speed USB device using ohci_hcd and address 3
usb 3-2.1: configuration #1 chosen from 1 choice
usb 3-2.1: New USB device found, idVendor=05ac, idProduct=0304
usb 3-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 3-2.1: Product: Apple Optical USB Mouse
usb 3-2.1: Manufacturer: Mitsumi Electric
usb 3-2.3: new full speed USB device using ohci_hcd and address 4
usb 3-2.3: configuration #1 chosen from 1 choice
usb 3-2.3: New USB device found, idVendor=05ac, idProduct=020b
usb 3-2.3: New USB device strings: Mfr=1, Product=3, SerialNumber=0
usb 3-2.3: Product: Apple Extended USB Keyboard
usb 3-2.3: Manufacturer: Mitsumi Electric
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver libusual
usbcore: registered new interface driver usbserial
/home/olaf/kernel/linux-2.6/drivers/usb/serial/usb-serial.c: USB Serial Driver core
/home/olaf/kernel/linux-2.6/drivers/usb/serial/usb-serial.c: USB Serial support registered for Keyspan - (without firmware)
/home/olaf/kernel/linux-2.6/drivers/usb/serial/usb-serial.c: USB Serial support registered for Keyspan 1 port adapter
/home/olaf/kernel/linux-2.6/drivers/usb/serial/usb-serial.c: USB Serial support registered for Keyspan 2 port adapter
/home/olaf/kernel/linux-2.6/drivers/usb/serial/usb-serial.c: USB Serial support registered for Keyspan 4 port adapter
keyspan 2-1:1.0: Keyspan 2 port adapter converter detected
usb 2-1: Keyspan 2 port adapter converter now attached to ttyUSB0
usb 2-1: Keyspan 2 port adapter converter now attached to ttyUSB1
usbcore: registered new interface driver keyspan
/home/olaf/kernel/linux-2.6/drivers/usb/serial/keyspan.c: v1.1.5:Keyspan USB to Serial Converter Driver
mice: PS/2 mouse device common for all mice
PowerMac i2c bus smu 14 registered
wf_sat: creating sat at address b0
PowerMac i2c bus smu 11 registered
PowerMac i2c bus mac-io 0 registered
PowerMac i2c bus mac-io 0 registered
found max6690, loc=BACKSIDE addr=0x98
found max6690, loc=TUNNEL addr=0x9c
PowerMac i2c bus u4 1 registered
usbcore: registered new interface driver hiddev
input: Mitsumi Electric Apple Optical USB Mouse as /class/input/input0
input: USB HID v1.10 Mouse [Mitsumi Electric Apple Optical USB Mouse] on usb-0001:01:0b.1-2.1
input: Mitsumi Electric Apple Extended USB Keyboard as /class/input/input1
input: USB HID v1.10 Keyboard [Mitsumi Electric Apple Extended USB Keyboard] on usb-0001:01:0b.1-2.3
input: Mitsumi Electric Apple Extended USB Keyboard as /class/input/input2
input: USB HID v1.10 Device [Mitsumi Electric Apple Extended USB Keyboard] on usb-0001:01:0b.1-2.3
usbcore: registered new interface driver usbhid
/home/olaf/kernel/linux-2.6/drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
Advanced Linux Sound Architecture Driver Version 1.0.16rc2 (Thu Jan 31 16:40:16 2008 UTC).
usbcore: registered new interface driver snd-usb-audio
usbcore: registered new interface driver snd-usb-usx2y
snd-aoa-fabric-layout: found bus with layout 68
snd-aoa-fabric-layout: Using PMF GPIOs
snd-aoa-codec-onyx: found pcm3052
snd-aoa-fabric-layout: platform-onyx-codec-ref doesn't match!
snd-aoa: fabric didn't like codec onyx
snd-aoa-codec-onyx: found pcm3052
snd-aoa-fabric-layout: can use this codec
snd-aoa-codec-onyx: attached to onyx codec via i2c
snd-aoa-codec-onyx: created and attached onyx instance
ALSA device list:
  #0: SoundByLayout
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
Freeing unused kernel memory: 216k freed
ioctl32(showconsole:476): Unknown cmd fd(0) cmd(40045432){t:'T';sz:4} arg(ffcd8bb8) on /dev/console
ioctl32(showconsole:479): Unknown cmd fd(0) cmd(40045432){t:'T';sz:4} arg(ffdafbb8) on /dev/console
windfarm: CPUs control loops started.
sat 0 partition c8: c8 6 2 7f ff 2 ff 1 fb bf 0 41 0 20 0 0 0 7 89 37 0 a0 0 0
ioctl32(showconsole:838): Unknown cmd fd(0) cmd(40045432){t:'T';sz:4} arg(ffefbbb8) on /dev/console
sat 0 partition c4: c4 4 1 7f 22 11 e0 e6 ff 55 7b 12 ec 11 0 0
ioctl32(showconsole:870): Unknown cmd fd(0) cmd(40045432){t:'T';sz:4} arg(ffc87b18) on /dev/console
Adding 1048568k swap on /dev/sdb3.  Priority:-1 extents:1 across:1048568k
ioctl32(showconsole:897): Unknown cmd fd(0) cmd(40045432){t:'T';sz:4} arg(ffb73aa8) on /dev/console (deleted)
sat 0 partition c9: c9 6 2 7f ff 2 ff 1 fb bf 0 41 0 20 0 0 0 7 89 37 0 a0 0 0
sat 0 partition c5: c5 4 1 7f 22 11 e0 e6 ff 55 7b 12 ec 11 0 0
windfarm: Backside control loop started.
windfarm: Slots control loop started.
windfarm: Drive bay control loop started.
ioctl32(showconsole:1781): Unknown cmd fd(0) cmd(40045432){t:'T';sz:4} arg(ffbf2aa8) on /dev/console (deleted)
XFS mounting filesystem sdb11
Ending clean XFS mount for filesystem: sdb11
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
ioctl32(showconsole:1953): Unknown cmd fd(0) cmd(40045432){t:'T';sz:4} arg(ff976ab8) on /dev/console (deleted)
ioctl32(showconsole:2058): Unknown cmd fd(0) cmd(40045432){t:'T';sz:4} arg(ffa39af8) on /dev/console
tg3: eth0: Link is up at 100 Mbps, full duplex.
tg3: eth0: Flow control is on for TX and on for RX.
ioctl32(showconsole:2641): Unknown cmd fd(0) cmd(40045432){t:'T';sz:4} arg(fff16a88) on /dev/tty0
ioctl32(showconsole:3052): Unknown cmd fd(0) cmd(40045432){t:'T';sz:4} arg(ffedaac8) on /dev/tty0

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox