* Re: [BUG] Linux 2.6.25-rc2 - Regression from 2.6.24-rc1-git1 softlockup while bootup on powerpc
From: Andrew Morton @ 2008-02-22 7:24 UTC (permalink / raw)
To: Jens Axboe
Cc: Giani, Srivatsa Vaddagiri, Linux Kernel Mailing List,
linuxppc-dev, Ingo Molnar, Kamalesh Babulal, Dhaval,
KAMEZAWA Hiroyuki, Balbir Singh
In-Reply-To: <20080219083633.GN23197@kernel.dk>
On Tue, 19 Feb 2008 09:36:34 +0100 Jens Axboe <jens.axboe@oracle.com> wrote:
> But I think the radix 'scan over entire tree' is a bit fragile.
eek, it had better not be. Was this an error in the caller? Hope so.
> This
> patch adds a parallel hlist for ease of properly browsing the members,
Even though io_contexts are fairly uncommon, adding more stuff to a data
structure was a pretty sad alternative to fixing a bug in
radix_tree_gang_lookup(), or to fixing a bug in a caller of it.
IOW: what exactly went wrong here??
^ permalink raw reply
* Re: [BUG] Linux 2.6.25-rc2 - Regression from 2.6.24-rc1-git1 softlockup while bootup on powerpc
From: Jens Axboe @ 2008-02-22 7:40 UTC (permalink / raw)
To: Andrew Morton
Cc: Dhaval Giani, Srivatsa Vaddagiri, Linux Kernel Mailing List,
linuxppc-dev, Ingo Molnar, Kamalesh Babulal, KAMEZAWA Hiroyuki,
Balbir Singh
In-Reply-To: <20080221232418.b93db8d9.akpm@linux-foundation.org>
On Thu, Feb 21 2008, Andrew Morton wrote:
> On Tue, 19 Feb 2008 09:36:34 +0100 Jens Axboe <jens.axboe@oracle.com> wrote:
>
> > But I think the radix 'scan over entire tree' is a bit fragile.
>
> eek, it had better not be. Was this an error in the caller? Hope so.
The cfq use of it, not the radix tree code! It juggled the keys and
wants to make sure that we see all users, modulo raced added ones (ok if
we see them, doesn't matter if we don't).
> > This
> > patch adds a parallel hlist for ease of properly browsing the members,
>
> Even though io_contexts are fairly uncommon, adding more stuff to a data
> structure was a pretty sad alternative to fixing a bug in
> radix_tree_gang_lookup(), or to fixing a bug in a caller of it.
>
> IOW: what exactly went wrong here??
I could not convince myself that the current code would always do the
right thing. We should not have been seeing ->key == NULL entries in
there, it implied a double exit of that process. So I decided to fix it
by making the code a lot more readable (the patch in question deleted a
lot more than it added), at the cost of that hlist head + node.
--
Jens Axboe
^ permalink raw reply
* [PATCH] [POWERPC] AMCC Kilauea (405EX): Disable EMAC loopback mode
From: Stefan Roese @ 2008-02-22 8:32 UTC (permalink / raw)
To: linuxppc-dev
405EX(r) has SDR0_MFR[E0CS/E1CS] set after reset. This selects
the internal loopback mode. Clear these bits so that both EMACs
don't use loopback mode as default.
Signed-off-by: Stefan Roese <sr@denx.de>
---
I'm not sure if this should be done here in the board platform code,
or in the newemac driver or perhaps in some code common for 405EX.
Any thoughts on this welcome.
Thanks.
arch/powerpc/platforms/40x/kilauea.c | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/40x/kilauea.c b/arch/powerpc/platforms/40x/kilauea.c
index f9206a7..b5456cc 100644
--- a/arch/powerpc/platforms/40x/kilauea.c
+++ b/arch/powerpc/platforms/40x/kilauea.c
@@ -1,7 +1,7 @@
/*
* Kilauea board specific routines
*
- * Copyright 2007 DENX Software Engineering, Stefan Roese <sr@denx.de>
+ * Copyright 2007-2008 DENX Software Engineering, Stefan Roese <sr@denx.de>
*
* Based on the Walnut code by
* Josh Boyer <jwboyer@linux.vnet.ibm.com>
@@ -20,6 +20,8 @@
#include <asm/time.h>
#include <asm/uic.h>
#include <asm/pci-bridge.h>
+#include <asm/dcr.h>
+#include <asm/dcr-regs.h>
static __initdata struct of_device_id kilauea_of_bus[] = {
{ .compatible = "ibm,plb4", },
@@ -45,6 +47,13 @@ static int __init kilauea_probe(void)
ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
+ /*
+ * 405EX(r) has SDR0_MFR[E0CS/E1CS] set after reset. This selects
+ * the internal loopback mode. Clear these bits so that both EMACs
+ * don't use loopback mode as deafult.
+ */
+ mtdcri(SDR0, SDR0_MFR, mfdcri(SDR0, SDR0_MFR) & ~0x0c000000);
+
return 1;
}
--
1.5.4.2
^ permalink raw reply related
* Re: [PATCH] Add support for binary includes.
From: David Woodhouse @ 2008-02-22 9:02 UTC (permalink / raw)
To: Grant Likely; +Cc: Scott Wood, linuxppc-dev, jdl
In-Reply-To: <fa686aa40802212205p38c3793bg8793740955b1e91@mail.gmail.com>
On Thu, 2008-02-21 at 23:05 -0700, Grant Likely wrote:
> Can I ask; what is the intended usage of such a thing? How large
> would a typical binary blob be?
Device firmware?
--
dwmw2
^ permalink raw reply
* Re: [PATCH] Add support for binary includes.
From: Bartlomiej Sieka @ 2008-02-22 8:34 UTC (permalink / raw)
To: Grant Likely; +Cc: Scott Wood, linuxppc-dev, jdl
In-Reply-To: <fa686aa40802212205p38c3793bg8793740955b1e91@mail.gmail.com>
Grant Likely wrote:
> On Wed, Feb 20, 2008 at 12:19 PM, Scott Wood <scottwood@freescale.com> wrote:
>> A property's data can be populated with a file's contents
>> as follows:
>>
>> node {
>> prop = /incbin/("path/to/data");
>> };
>>
>> A subset of a file can be included by passing start and size parameters.
>> For example, to include bytes 8 through 23:
>>
>> node {
>> prop = /incbin/("path/to/data", 8, 16);
>> };
>
>
> Can I ask; what is the intended usage of such a thing? How large
> would a typical binary blob be?
Binary includes are a critical feature of the new image format for
U-Boot. In short: we're describing image's content and other data
(architecture, os, image type, etc) in dts format, and then use dtc to
generate the file that is transferred to the target and booted by
U-Boot. Excerpt from an actual file describing an image:
/{
images {
kernel@1 {
data = /incbin/("./vmlinux.bin.gz");
type = "kernel";
arch = "ppc";
os = "linux";
compression = "gzip";
load = <00000000>;
entry = <00000000>;
};
};
};
As to the size of the final blob in our case, it depends. It seems that
in case of a powerpc Linux booting scenario, most of the times the size
will be roughly the size of a compressed kernel + the size of the FDT
blob, eventually plus the size of a ramdisk. Note however, that the new
image format has provisions for handling multiple components of the same
type in one image, so for example you could have three kernels, two
ramdisks and a couple of fdt blobs in one image, and the actual booting
configuration could be selected in U-Boot. In such a case, the final
blob can be arbitrarily large.
Regards,
Bartlomiej
^ permalink raw reply
* MPC8540 : What's "SPE used in kernel" ?
From: Philippe De Muyter @ 2008-02-22 9:50 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080221123534.GA17716@ingate.macqel>
Dear list,
I have just compiled linux-2.6.24 for a MPC8540 target using a MPC8540
specific gcc.
I then got tan infinity of "SPE used in kernel" messages. Looking at the
sources I ifdeffed out the printk call in KernelSPE, and I now have a
silent kernel, that seems to work fine.
Is there something wrong in my setting and should I look further to
debug this problem or is this perfectly normal ?
I wonder why a kernel configured for E500 and compiled by a E500-specific gcc
triggers this message. Is it invalid to use SPE instructions in the kernel
or do I misunderstand the message ?
Philippe
^ permalink raw reply
* Re: [PATCHv4 2.6.25] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers
From: Jochen Friedrich @ 2008-02-22 11:16 UTC (permalink / raw)
To: Jean Delvare; +Cc: linux-kernel, linuxppc-dev list, i2c, Scott Wood
In-Reply-To: <20080221130520.12b01553@hyperion.delvare>
Hi Jean,
>> +/*
>> + * Wait for patch from Jon Smirl
>> + * #include "powerpc-common.h"
>> + */
>
> It doesn't make sense to merge this comment upstream.
I know you don't like the patch from Jon Smirl and you also explained your reasons.
Fortunately, I2c no longer uses numeric device IDs but names. So what are the alternatives?
1. modify the I2c subsystem to accept OF names additionally to I2c names (proposed by Jon smirl).
2. record the I2c name in the dts tree, either as seperate tag (like linux,i2c-name="<i2c-name>")
or as additional compatible entry (like compatible="...", "linux,<i2c-name>").
3. use a glue layer with a translation map.
What is the preferred way to do this?
Thanks,
Jochen
^ permalink raw reply
* TQM5200 2.6-denx SM501 voyager enabling problem.
From: Pedro Luis D. L. @ 2008-02-22 11:29 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I'm working right now with a TQM5200 microcontroller on a STX5200 board.
I'm having problems to enable SM501 video output using 2.6-denx kernel. The=
system is working properly using 2.4 kernel and I can have graphical outpu=
t, so I can be sure that there's no hardware problem.
With 2.6 I have used the tqm5200_defconfig configuration file and then I ha=
ve enabled the following features in the kernel:
- Device Drivers -> Multifunction Device Drivers -> Support forSilicon Mot=
ion SM501.
- Device Drivers -> Graphic Support -> Support for frame buffer devices.
- Device Drivers -> Graphic Support -> Support for frame buffer devices -=
> Silicon Motion SM501 framebuffer support.
- Device Drivers -> Character devices -> Virtual Terminal.
- Device Drivers -> Character devices -> Support for console on virtual te=
rminal.
But I still can't make the SM501 driver initialized at booting time and the=
re's no framebuffer video device available. /dev/fb and /dev/fb0 nodes are =
already created.
I'm using 1.3.1 u-boot from denx repository compiled with CONFIG_STK52XX=
=3Dy and CONFIG_MINIFAP=3Dy options, and video=3Dvoyager:fp options is pass=
ed to the kernel at booting.
I'm sure there's something I'm missing to enable in the kernel. Maybe someo=
ne can sent me a hint. I would appreciate any!
Pedro L.
_________________________________________________________________
MSN Noticias
http://noticias.msn.es/comunidad.aspx=
^ permalink raw reply
* Re: [PATCH] [POWERPC] 8xx: timebase frequency should not depend on bus-frequency
From: Bryan O'Donoghue @ 2008-02-22 13:01 UTC (permalink / raw)
To: cbouatmailru; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20080221234136.GA3545@zarina>
On Fri, 22 Feb 2008 02:41:36 +0300
Anton Vorontsov <cbouatmailru@gmail.com> wrote:
> On Thu, Feb 21, 2008 at 03:20:10PM -0600, Scott Wood wrote:
> > Anton Vorontsov wrote:
> > > On Thu, Feb 21, 2008 at 02:06:58PM -0600, Scott Wood wrote:
> > >> Current u-boots don't support device trees at all on 8xx.
> > >
> > > Yes, vanilla u-boots. I assume many of us use some u-boot hacks to
> > > actually boot with the device tree (no, not cuboots)... ;-)
> >
> > Fine, but don't expect misbehavior from out-of-tree u-boots to be used
> > as justification for the kernel ignoring device tree content. :-)
>
> You got me wrong, maybe I wasn't clear enough: it wasn't justification of
> any kind. It's was just a remark regarding u-boot still not supporting
> fdt for 8xx (20 lines of code we're lazy to cleanup, write annotation
> to the patch and send it ;-).
Hey Anton.
I won't make any comment on what Linux should do with an older version of
u-boot.
However, just to let you know, there are a couple of patches to do a more modern
fdt on 8xx- sent to the u-boot list in the last <= ~ 10 days.
Using those patches - which incorporate the changes suggested by Scott re:
get_tbclk()- the timebase-frequency field is indeed stuffed with u-boot's
get_tbclk(); - see below.
u-boot/cpu/mpc8xx/fdt.c
void ft_cpu_setup(void *blob, bd_t *bd)
{
do_fixup_by_prop_u32(blob, "device_type", "cpu", 4,
"timebase-frequency", get_tbclk(), 1);
do_fixup_by_prop_u32(blob, "device_type", "cpu", 4,
"bus-frequency", bd->bi_busfreq, 1);
do_fixup_by_prop_u32(blob, "device_type", "cpu", 4,
"clock-frequency", bd->bi_intfreq, 1);
do_fixup_by_compat_u32(blob, "fsl,cpm-brg", "clock-frequency",
gd->brg_clk, 1);
/* Fixup ethernet MAC addresses */
fdt_fixup_ethernet(blob, bd);
fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
}
Adding fdt support to an 8xx board is then as simple as defining
/* pass open firmware flat tree */
#define CONFIG_OF_LIBFDT 1
#define CONFIG_OF_BOARD_SETUP 1
In your u-boot/include/configs/MySuperBoard.h
Best,
Bryan
^ permalink raw reply
* Doubt in Device tree entry for USB on Powerpc based board
From: mahendra varman @ 2008-02-22 13:33 UTC (permalink / raw)
To: linuxppc-embedded, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 6986 bytes --]
Hello All
Iam using Powerpc 7448 processor along with TSI 109 system controller.
On PCI interface of TSI 109 a PCI to PCI bridge(6520) is connected in which
an usb controller(Philips ISP1562) and PMC site is connected.
Iam following the Open Firmware Powerpc architecture and using Linux 2.6.23.
I have framed the device tree for the above architecture with usb entry. But
even though i enable the ohci ppc of in menuconfig the the functions
probe,etc inside ohci ppc of.c are not called when i insert the device in
usb port and hence it is not detecting ohci low/full speed devices.
Please help me in the device tree where to give the device type
compatibility address_cells size cells for the USB (since usb controller is
in pci bridge i have some confusion in where to give the entry for usb)
I have attached the device tree below
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
{ model = "CTP7448";
compatible = "mpc74xx";
#address-cells = <1>;
#size-cells = <1>;
cpus {
#address-cells = <1>;
#size-cells =<0>;
PowerPC,7448@0 {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <20>; // 32 bytes
i-cache-line-size = <20>; // 32 bytes
d-cache-size = <8000>; // L1, 32K bytes
i-cache-size = <8000>; // L1, 32K bytes
timebase-frequency = <0>; // 33 MHz, from uboot
clock-frequency = <0>; // From U-Boot
bus-frequency = <0>; // From U-Boot
32-bit;
};
};
memory{
device_type = "memory";
reg = <00000000 10000000>; // DDR2 512M at 0
};
tsi108@c0000000 {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
device_type = "tsi-bridge";
ranges = <00000000 c0000000 00010000
00000000 f0000000 00008000
00000000 f1000000 01000000
00000000 f8000000 01000000>;
reg = <c0000000 00010000>;
bus-frequency = <0>;
rtc@f0000000 {
device_type = "rtc";
compatible = "st,m48t59";
reg = <f0000000 8000>;
};
i2c@7000 {
interrupt-parent = <&mpic>;
interrupts = <E 0>;
reg = <7000 400>;
device_type = "i2c";
compatible = "tsi108-i2c";
};
MDIO: mdio@6000 {
device_type = "mdio";
compatible = "tsi108-mdio";
reg = <6000 50>;
#address-cells = <1>;
#size-cells = <0>;
phy1: ethernet-phy@1 {
interrupt-parent = <&mpic>;
interrupts = <0 0>;
reg = <1>;
device_type = "ethernet-phy";
};
phy8: ethernet-phy@8 {
interrupt-parent = <&mpic>;
interrupts = <1 0>;
reg = <8>;
device_type = "ethernet-phy";
};
};
ethernet@6200 {
#size-cells = <0>;
device_type = "network";
compatible = "tsi108-ethernet";
reg = <6000 200>;
address = [ 00 03 23 00 00 01 ];
interrupts = <10 0>;
interrupt-parent = <&mpic>;
mdio-handle = <&MDIO>;
phy-handle = <&phy1>;
};
ethernet@6600 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
compatible = "tsi108-ethernet";
reg = <6400 200>;
address = [ 00 03 23 00 00 02 ];
interrupts = <11 2>;
interrupt-parent = <&mpic>;
mdio-handle = <&MDIO>;
phy-handle = <&phy8>;
};
serial@7808 {
device_type = "serial";
compatible = "ns16550";
reg = <7808 200>;
clock-frequency = <3f6b5a00>;
interrupts = <c 0>;
interrupt-parent = <&mpic>;
};
serial@7c08 {
device_type = "serial";
compatible = "ns16550";
reg = <7c08 200>;
clock-frequency = <3f6b5a00>;
interrupts = <d 0>;
interrupt-parent = <&mpic>;
};
mpic: pic@7400 {
clock-frequency = <0>;
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <7400 400>;
built-in;
compatible = "chrp,open-pic";
device_type = "open-pic";
big-endian;
};
pci@1000 {
compatible = "tsi108-pci";
device_type = "pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <1000 1000>;
bus-range = <0 0>;
ranges = <02000000 0 e0000000 e0000000 0 10000000
01000000 0 00000000 f2000000 0 01000000>;
clock-frequency = <3ef1480>;
interrupt-parent = <&mpic>;
interrupts = <17 2>;
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x10 */
00000 0 0 1 &RT0 24 0
/* IDSEL 0x11 */
00800 0 0 1 &RT0 25 0
/* IDSEL 0x12 */
1000 0 0 1 &RT0 24 0
1000 0 0 2 &RT0 25 0
1000 0 0 3 &RT0 26 0
1000 0 0 4 &RT0 27 0 >;
pci_bridge@12 {
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x13 (PMC Site) */
1800 0 0 1 &RT0 24 0
1800 0 0 2 &RT0 25 0
1800 0 0 3 &RT0 26 0
1800 0 0 4 &RT0 27 0
/* IDSEL 0x14 (USB chip) */
2000 0 0 1 &RT0 27 0
2000 0 0 2 &RT0 27 0
2000 0 0 3 &RT0 27 0
2000 0 0 4 &RT0 27 0
>;
reg = <1000 0 0 0 0>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
ranges = <02000000 0 e0000000 e0000000 0 10000000 01000000 0
00000000 fa000000 0 00010000>;
clock-frequency = <1f78a40>;
RT0: router@1180 {
clock-frequency = <0>;
interrupt-controller;
device_type = "pic-router";
#address-cells = <0>;
#interrupt-cells = <2>;
built-in;
big-endian;
interrupts = <17 2>;
interrupt-parent = <&mpic>;
};
};
};
};
};
[-- Attachment #2: Type: text/html, Size: 17996 bytes --]
^ permalink raw reply
* Re: MPC8641D PCI-Express error
From: Marco Stornelli @ 2008-02-22 13:52 UTC (permalink / raw)
To: LinuxPPC-Embedded; +Cc: s.balamurugan
In-Reply-To: <47BD9FA9.1000904@freescale.com>
Jon Loeliger ha scritto:
> Marco Stornelli wrote:
>> When I try to read some register from my FPGA (virtex5) I have this bus
>> error:
>
>
> Hmmm.... OK, so if we've eliminated PCI-E as a source
> for this issue, it really must be in the Virtex support
> somewhere then. Unfortunately, I know nothing about those,
> and am not going to be much direct help there.
>
> Sorry.
>
> jdl
>
>
>> Machine check in kernel mode.
>> Caused by (from SRR1=149030): Transfer error ack signal
>> Oops: Machine check, sig: 7 [#1]
>> PREEMPT SMP NR_CPUS=2
>> Modules linked in: virtex5
>> LTT NESTING LEVEL : 0
>> NIP: F108019C LR: F1080198 CTR: 00000001
>> REGS: c044dd60 TRAP: 0200 Not tainted (2.6.18-mpc8641d_hpcn)
>> MSR: 00149030 <EE,ME,IR,DR> CR: 22000222 XER: 00000000
>> TASK = c20e9990[568] 'insmod' THREAD: c044c000 CPU: 0
>> GPR00: F1080198 C044DE10 C20E9990 0000002E 80000000 FFFFFFFF 00008000
>> 00002EA3
>> GPR08: C20E9990 00000000 C04C0220 C044C000 22000222 1001956C 00000000
>> 00000000
>> GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> 00000000
>> GPR24: 3000EAA0 7FD6FDC0 00000000 C045FCC0 F107E594 F10A0000 00000000
>> C2036000
>> NIP [F108019C] virtex5_probe+0x130/0x1c4 [virtex5]
>> LR [F1080198] virtex5_probe+0x12c/0x1c4 [virtex5]
>> Call Trace:
>> [C044DE10] [F1080198] virtex5_probe+0x12c/0x1c4 [virtex5] (unreliable)
>> [C044DE30] [C01D2A58] pci_device_probe+0x84/0xbc
>> [C044DE50] [C0213754] driver_probe_device+0x60/0x118
>> [C044DE70] [C0213890] __driver_attach+0x84/0x88
>> [C044DE90] [C02130F4] bus_for_each_dev+0x58/0x94
>> [C044DEC0] [C02135D4] driver_attach+0x24/0x34
>> [C044DED0] [C0212AC8] bus_add_driver+0x88/0x164
>> [C044DEF0] [C021397C] driver_register+0x70/0xb8
>> [C044DF00] [C01D284C] __pci_register_driver+0x64/0x98
>> [C044DF10] [F1080030] init_module+0x30/0x6c [virtex5]
>> [C044DF20] [C004CBFC] sys_init_module+0xc8/0x25c
>> [C044DF40] [C0011358] ret_from_syscall+0x0/0x38
>> --- Exception: c00 at 0xff6de0c
>> LR = 0x10000de4
>> Instruction dump:
>> 40820060 3c60f108 3863cea0 48000311 807f0238 3c800001 48000395 7c7d1b78
>> 3c60f108 3863ced4 480002f5 809d0000 <3c60f108> 3863cf04 480002e5 3c60f108
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
I tried to use 2.6.24 but I have the same error. It looks like this
problem happens when I try to read something in my ML555 board (Virtex5
evaluation board), but if try to write everything works fine. I tried to
change the settings about inbound/outbound PCI-E windows but I have the
same problem. Have you got any suggestions?
Thanks.
Marco
^ permalink raw reply
* Re: compile quirk linux-2.6.24 (with workaround)
From: Bernhard Reiter @ 2008-02-22 14:50 UTC (permalink / raw)
To: debian-powerpc; +Cc: linuxppc-dev, paulus
In-Reply-To: <20080218205248.1af469d4@zod.rchland.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]
On Tuesday 19 February 2008 03:52, Josh Boyer wrote:
> My apologies for taking so long on this. Digging through gcc history
> isn't exactly fun :)
No problem. Thanks for tackling the issue.
> Ok, so it seems -mcpu=440 was added in gcc 3.4. The -mcpu=405 option
> has been around since 2001. Seeing as how there really isn't anything
> 440 specific in the files effected, we should be able to pass -mcpu=405
> for everything and have it still work.
>
> Bernhard, can you try the patch below?
I will test it in the next days.
The short test for my sarge compiler makes me optimistic:
dpkg -l gcc | grep gcc
ii gcc 3.3.5-3 The GNU C compiler
bernhard@burn:~/tmp$ gcc -mcpu=440 x.c
cc1: error: bad value (440) for -mcpu= switch
bernhard@burn:~/tmp$ gcc -mcpu=405 x.c
bernhard@burn:~/tmp$
> -$(obj)/cuboot-katmai.o: BOOTCFLAGS += -mcpu=440
> +$(obj)/4xx.o: BOOTCFLAGS += -mcpu=405
--
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: MPC8540 : What's "SPE used in kernel" ?
From: Johannes Berg @ 2008-02-22 15:29 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: linuxppc-dev
In-Reply-To: <20080222095022.GA635@ingate.macqel>
[-- Attachment #1: Type: text/plain, Size: 502 bytes --]
> I wonder why a kernel configured for E500 and compiled by a E500-specific gcc
> triggers this message. Is it invalid to use SPE instructions in the kernel
> or do I misunderstand the message ?
I think it's like floating point/altivec, we don't always save the FP
registers on kernel/userspace transitions and so have to explicitly save
them to use them in the kernel, otherwise we'd clobber the userspace
register state.
I guess there's something like kernel_enter_spe()?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Marvell PHY driver fix
From: Alexandr Smirnov @ 2008-02-22 14:34 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, vbordug
Marvell PHY m88e1111 (not sure about other models, but think they too) works in
two modes: fiber and copper. In Marvell PHY driver (that we have in current
community kernels) code supported only copper mode, and this is not configurable,
bits for copper mode are simply written in registers during PHY
initialization. This patch adds support for both modes.
Signed-off-by: Alexandr Smirnov <asmirnov@ru.mvista.com>
diff -pruN powerpc.orig/drivers/net/phy/marvell.c powerpc/drivers/net/phy/marvell.c
--- powerpc.orig/drivers/net/phy/marvell.c 2008-02-07 14:59:32.000000000 +0300
+++ powerpc/drivers/net/phy/marvell.c 2008-02-19 21:47:34.000000000 +0300
@@ -58,9 +58,28 @@
#define MII_M1111_RX_DELAY 0x80
#define MII_M1111_TX_DELAY 0x2
#define MII_M1111_PHY_EXT_SR 0x1b
-#define MII_M1111_HWCFG_MODE_MASK 0xf
-#define MII_M1111_HWCFG_MODE_RGMII 0xb
+
+#define MII_M1111_HWCFG_MODE_MASK 0xf
+#define MII_M1111_HWCFG_MODE_COPPER_RGMII 0xb
+#define MII_M1111_HWCFG_MODE_FIBER_RGMII 0x3
#define MII_M1111_HWCFG_MODE_SGMII_NO_CLK 0x4
+#define MII_M1111_HWCFG_FIBER_COPPER_AUTO 0x8000
+#define MII_M1111_HWCFG_FIBER_COPPER_RES 0x2000
+
+#define MII_M1111_PHY_CR 0
+#define MII_M1111_SOFTWARE_RESET 0x8000
+
+#define MII_M1111_COPPER 0
+#define MII_M1111_FIBER 1
+
+#define MII_M1011_PHY_STATUS 0x11
+#define MII_M1011_PHY_STATUS_1000 0x8000
+#define MII_M1011_PHY_STATUS_100 0x4000
+#define MII_M1011_PHY_STATUS_SPD_MASK 0xc000
+#define MII_M1011_PHY_STATUS_FULLDUPLEX 0x2000
+#define MII_M1011_PHY_STATUS_RESOLVED 0x0800
+#define MII_M1011_PHY_STATUS_LINK 0x0400
+
MODULE_DESCRIPTION("Marvell PHY driver");
MODULE_AUTHOR("Andy Fleming");
@@ -141,12 +160,22 @@ static int marvell_config_aneg(struct ph
static int m88e1111_config_init(struct phy_device *phydev)
{
int err;
+ int temp;
+ int mode;
+
+ /* Enable Fiber/Copper auto selection */
+ temp = phy_read(phydev, MII_M1111_PHY_EXT_SR);
+ temp |= MII_M1111_HWCFG_FIBER_COPPER_AUTO;
+ phy_write(phydev, MII_M1111_PHY_EXT_SR, temp);
+
+ temp = phy_read(phydev, MII_M1111_PHY_CR);
+ temp |= MII_M1111_SOFTWARE_RESET;
+ phy_write(phydev, MII_M1111_PHY_CR, temp);
if ((phydev->interface == PHY_INTERFACE_MODE_RGMII) ||
(phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) ||
(phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) ||
(phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID)) {
- int temp;
temp = phy_read(phydev, MII_M1111_PHY_EXT_CR);
if (temp < 0)
@@ -171,7 +200,17 @@ static int m88e1111_config_init(struct p
return temp;
temp &= ~(MII_M1111_HWCFG_MODE_MASK);
- temp |= MII_M1111_HWCFG_MODE_RGMII;
+
+ mode = phy_read(phydev, MII_M1111_PHY_EXT_CR);
+ mode = (mode & MII_M1111_HWCFG_FIBER_COPPER_RES) >> 13;
+
+ switch (mode) {
+ case MII_M1111_COPPER:
+ temp |= MII_M1111_HWCFG_MODE_COPPER_RGMII;
+ break;
+ case MII_M1111_FIBER:
+ temp |= MII_M1111_HWCFG_MODE_FIBER_RGMII;
+ }
err = phy_write(phydev, MII_M1111_PHY_EXT_SR, temp);
if (err < 0)
@@ -262,6 +301,93 @@ static int m88e1145_config_init(struct p
return 0;
}
+/* marvell_read_status
+ *
+ * Generic status code does not detect Fiber correctly!
+ * Description:
+ * Check the link, then figure out the current state
+ * by comparing what we advertise with what the link partner
+ * advertises. Start by checking the gigabit possibilities,
+ * then move on to 10/100.
+ */
+static int marvell_read_status(struct phy_device *phydev)
+{
+ int adv;
+ int err;
+ int lpa;
+ int status = 0;
+
+ /* Update the link, but return if there
+ * was an error */
+ err = genphy_update_link(phydev);
+ if (err)
+ return err;
+
+ if (AUTONEG_ENABLE == phydev->autoneg) {
+ status = phy_read(phydev, MII_M1011_PHY_STATUS);
+ if (status < 0)
+ return status;
+
+ lpa = phy_read(phydev, MII_LPA);
+ if (lpa < 0)
+ return lpa;
+
+ adv = phy_read(phydev, MII_ADVERTISE);
+ if (adv < 0)
+ return adv;
+
+ lpa &= adv;
+
+ if (status & MII_M1011_PHY_STATUS_FULLDUPLEX)
+ phydev->duplex = DUPLEX_FULL;
+ else
+ phydev->duplex = DUPLEX_HALF;
+
+ status = status & MII_M1011_PHY_STATUS_SPD_MASK;
+ phydev->pause = phydev->asym_pause = 0;
+
+ switch (status) {
+ case MII_M1011_PHY_STATUS_1000:
+ phydev->speed = SPEED_1000;
+ break;
+
+ case MII_M1011_PHY_STATUS_100:
+ phydev->speed = SPEED_100;
+ break;
+
+ default:
+ phydev->speed = SPEED_10;
+ break;
+ }
+
+ if (phydev->duplex == DUPLEX_FULL) {
+ phydev->pause = lpa & LPA_PAUSE_CAP ? 1 : 0;
+ phydev->asym_pause = lpa & LPA_PAUSE_ASYM ? 1 : 0;
+ }
+ } else {
+ int bmcr = phy_read(phydev, MII_BMCR);
+
+ if (bmcr < 0)
+ return bmcr;
+
+ if (bmcr & BMCR_FULLDPLX)
+ phydev->duplex = DUPLEX_FULL;
+ else
+ phydev->duplex = DUPLEX_HALF;
+
+ if (bmcr & BMCR_SPEED1000)
+ phydev->speed = SPEED_1000;
+ else if (bmcr & BMCR_SPEED100)
+ phydev->speed = SPEED_100;
+ else
+ phydev->speed = SPEED_10;
+
+ phydev->pause = phydev->asym_pause = 0;
+ }
+
+ return 0;
+}
+
static struct phy_driver marvell_drivers[] = {
{
.phy_id = 0x01410c60,
@@ -296,7 +422,7 @@ static struct phy_driver marvell_drivers
.flags = PHY_HAS_INTERRUPT,
.config_init = &m88e1111_config_init,
.config_aneg = &marvell_config_aneg,
- .read_status = &genphy_read_status,
+ .read_status = &marvell_read_status,
.ack_interrupt = &marvell_ack_interrupt,
.config_intr = &marvell_config_intr,
.driver = { .owner = THIS_MODULE },
^ permalink raw reply
* Re: [PATCH] Add support for binary includes.
From: Grant Likely @ 2008-02-22 15:50 UTC (permalink / raw)
To: David Woodhouse; +Cc: Scott Wood, linuxppc-dev, jdl
In-Reply-To: <1203670971.5771.41.camel@shinybook.infradead.org>
On Fri, Feb 22, 2008 at 2:02 AM, David Woodhouse <dwmw2@infradead.org> wrote:
>
> On Thu, 2008-02-21 at 23:05 -0700, Grant Likely wrote:
> > Can I ask; what is the intended usage of such a thing? How large
> > would a typical binary blob be?
>
> Device firmware?
That's what I was wondering about. Is this really a good idea?
Effectively, in the Linux kernel the device tree is being used as a
big blob of initdata, except that it cannot free the memory allocated
by the device tree when it is complete. As it is right now, device
trees seem to weigh in between 4-8kB, a pretty insignificant size for
memory that cannot be reclaimed. However, if firmware blobs start
getting added to the tree that size could balloon pretty quickly.
I'm not actually opposed to the feature, and I understand that it is
needed for the new u-boot image format, but I think we need some usage
guidelines in place when this feature is merged. As much as possible
I think we should be directing developers to use the existing firmware
loading facilities in the Linux kernel.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] Add support for binary includes.
From: Scott Wood @ 2008-02-22 16:08 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, jdl
In-Reply-To: <fa686aa40802212205p38c3793bg8793740955b1e91@mail.gmail.com>
On Thu, Feb 21, 2008 at 11:05:58PM -0700, Grant Likely wrote:
> On Wed, Feb 20, 2008 at 12:19 PM, Scott Wood <scottwood@freescale.com> wrote:
> > A property's data can be populated with a file's contents
> > as follows:
> >
> > node {
> > prop = /incbin/("path/to/data");
> > };
> >
> > A subset of a file can be included by passing start and size parameters.
> > For example, to include bytes 8 through 23:
> >
> > node {
> > prop = /incbin/("path/to/data", 8, 16);
> > };
>
>
> Can I ask; what is the intended usage of such a thing? How large
> would a typical binary blob be?
I use it for embedding guest device trees in a hypervisor's device tree.
-Scott
^ permalink raw reply
* Re: [PATCH] Add support for binary includes.
From: Scott Wood @ 2008-02-22 16:28 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1JSahk-0003ub-Eh@jdl.com>
On Fri, Feb 22, 2008 at 10:24:56AM -0600, Jon Loeliger wrote:
> So, like, the other day Scott Wood mumbled:
> > >
> > > Can I ask; what is the intended usage of such a thing? How large
> > > would a typical binary blob be?
> >
> > I use it for embedding guest device trees in a hypervisor's device tree.
>
> Why wouldn't we instead, say, extend the source sytax
> to allow a sub-tree or an embedded tree, rather than
> obscuring an opaque form of that guest device tree?
That was what I tried initially, but the implementation was much more
complicated, and path references are problematic.
-Scott
^ permalink raw reply
* Re: MODPOST section mismatches
From: Steve Heflin @ 2008-02-22 16:12 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20080221213313.97814DDF55@ozlabs.org>
To reproduce the problem and see the details on section mismatches:
make ARCH=powerpc sequoia_defconfig
make ARCH=powerpc CONFIG_DEBUG_SECTION_MISMATCH=y
At 04:33 PM 2/21/2008, Steve Heflin wrote:
>while building vmlinux.o the MODPOST warns about 8 section mismatches.
>WARNING: modpost: Found 8 section mismatch(es).
>To see full details build your kernel with:
>'make CONFIG_DEBUG_SECTION_MISMATCH=y'
>
>After modifying the make launch to include the recommended option
>shown above, I see that the section mismatch warning is due to data
>structures containing the address of initialization modules which
>have the __init attribute. Since the memory model is FLAT, is this a problem?
>
>thanks,
>Steve
>
>
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Doubt in Device tree entry for USB on Powerpc based board
From: Scott Wood @ 2008-02-22 16:50 UTC (permalink / raw)
To: mahendra varman; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <4ac2955e0802220533o3eba0e58ybb72326ab0e1a376@mail.gmail.com>
On Fri, Feb 22, 2008 at 07:03:07PM +0530, mahendra varman wrote:
> Please help me in the device tree where to give the device type
> compatibility address_cells size cells for the USB (since usb controller is
> in pci bridge i have some confusion in where to give the entry for usb)
You don't need to describe PCI devices in the device tree; they are
probed at runtime.
-Scott
^ permalink raw reply
* [PATCH] sata_fsl: fix build with ATA_VERBOSE_DEBUG
From: Anton Vorontsov @ 2008-02-22 16:54 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-ide, linuxppc-dev
This patch fixes build and few warnings when ATA_VERBOSE_DEBUG
is defined:
CC drivers/ata/sata_fsl.o
drivers/ata/sata_fsl.c: In function ‘sata_fsl_fill_sg’:
drivers/ata/sata_fsl.c:338: warning: format ‘%x’ expects type ‘unsigned int’, but argument 3 has type ‘void *’
drivers/ata/sata_fsl.c:338: warning: format ‘%x’ expects type ‘unsigned int’, but argument 4 has type ‘struct prde *’
drivers/ata/sata_fsl.c: In function ‘sata_fsl_qc_issue’:
drivers/ata/sata_fsl.c:459: error: ‘csr_base’ undeclared (first use in this function)
drivers/ata/sata_fsl.c:459: error: (Each undeclared identifier is reported only once
drivers/ata/sata_fsl.c:459: error: for each function it appears in.)
drivers/ata/sata_fsl.c: In function ‘sata_fsl_freeze’:
drivers/ata/sata_fsl.c:525: error: ‘csr_base’ undeclared (first use in this function)
make[2]: *** [drivers/ata/sata_fsl.o] Error 1
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/ata/sata_fsl.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index 9ac36df..93789bf 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -335,7 +335,7 @@ static unsigned int sata_fsl_fill_sg(struct ata_queued_cmd *qc, void *cmd_desc,
dma_addr_t indirect_ext_segment_paddr;
unsigned int si;
- VPRINTK("SATA FSL : cd = 0x%x, prd = 0x%x\n", cmd_desc, prd);
+ VPRINTK("SATA FSL : cd = 0x%p, prd = 0x%p\n", cmd_desc, prd);
indirect_ext_segment_paddr = cmd_desc_paddr +
SATA_FSL_CMD_DESC_OFFSET_TO_PRDT + SATA_FSL_MAX_PRD_DIRECT * 16;
@@ -459,7 +459,8 @@ static unsigned int sata_fsl_qc_issue(struct ata_queued_cmd *qc)
VPRINTK("CE=0x%x, DE=0x%x, CC=0x%x, CmdStat = 0x%x\n",
ioread32(CE + hcr_base),
ioread32(DE + hcr_base),
- ioread32(CC + hcr_base), ioread32(COMMANDSTAT + csr_base));
+ ioread32(CC + hcr_base),
+ ioread32(COMMANDSTAT + host_priv->csr_base));
return 0;
}
@@ -522,7 +523,8 @@ static void sata_fsl_freeze(struct ata_port *ap)
ioread32(CQ + hcr_base),
ioread32(CA + hcr_base),
ioread32(CE + hcr_base), ioread32(DE + hcr_base));
- VPRINTK("CmdStat = 0x%x\n", ioread32(csr_base + COMMANDSTAT));
+ VPRINTK("CmdStat = 0x%x\n",
+ ioread32(host_priv->csr_base + COMMANDSTAT));
/* disable interrupts on the controller/port */
temp = ioread32(hcr_base + HCONTROL);
--
1.5.2.2
^ permalink raw reply related
* Re: [PATCH] Add support for binary includes.
From: Jon Loeliger @ 2008-02-22 16:24 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080222160820.GA19571@ld0162-tx32.am.freescale.net>
So, like, the other day Scott Wood mumbled:
> >
> > Can I ask; what is the intended usage of such a thing? How large
> > would a typical binary blob be?
>
> I use it for embedding guest device trees in a hypervisor's device tree.
Why wouldn't we instead, say, extend the source sytax
to allow a sub-tree or an embedded tree, rather than
obscuring an opaque form of that guest device tree?
Thanks,
jdl
^ permalink raw reply
* Re: How to dynamically disable/enable CPU features?
From: Milton Miller @ 2008-02-22 17:24 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: ppcdev
In-Reply-To: <20080221200758.62940@gmx.net>
At Fri Feb 22 07:07:58 EST 2008, Gerhard Pircher wrote:
> I'm wondering how to disable or enable CPU features based on the board
> the
> kernel is running on. In my case I want to disable the
> CPU_FTR_NEED_COHERENT flag for 74xx CPUs, because it locks up the
> machine.
> I tried to clear the flag in the platform's *_probe() function with the
> following code:
>
> cur_cpu_spec->cpu_features &= ~CPU_FTR_NEED_COHERENT;
>
> First I thought that this works fine, because the kernel booted once
> till
> the console login prompt (and died afterwards). Therefore I suspected
> that
> another change or bug in the kernel conflicts with my hardware (usually
> the machine died much earlier on older kernels, if the flag wasn't
> cleared).
> Now I removed all CPU_FTR_NEED_COHERENT entries from the cputable.h
> file
> and the kernel boots just fine without any lockups (reproducable).
> I don't quite understand the difference between dynamically clearing
> the
> flag in the platform setup code and removing the flag for all CPU
> defines in cputable.h. I can only suspect that clearing the flag in the
> platform probe function is too late, as the MMU and BATs may already be
> set up.
>
> Can anybody confirm my suspicion or give me a hint how to implement it
> correctly? (I don't want to tinker with cputable.h)
We handle cpu features in a couple of ways:
(1) we replace assembly instructions with nop early in the kernel boot
(2) we test the feature flags in c code
In (2), we form two expressions for features that are
(a) always set
(b) never set
so that the compiler can eliminate the test based on the config.
To change a flag, you must make sure its in POSSIBLE but not ALWAYS,
and also set it before it is used, either to nop out instructions (see
early_init in setup-32.c for 32 bit), or tested by c code (in this
case, maybe the initial_mmu setup is testing NEED_COHERENT, which is
between early_init and probe). The code path is a bit
different for 64 bit.
milton
^ permalink raw reply
* Re: Xilinx PowerPC
From: Alan Casey @ 2008-02-22 17:23 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40802211102i7f636447hfca0f8e1673042a5@mail.gmail.com>
>-- Original Message --
>Date: Thu, 21 Feb 2008 12:02:21 -0700
>From: "Grant Likely" <grant.likely@secretlab.ca>
>To: "Stephen Neuendorffer" <stephen.neuendorffer@xilinx.com>
>Subject: Re: Xilinx PowerPC
>Cc: linuxppc-embedded <linuxppc-embedded@ozlabs.org>
>
>
>On Thu, Feb 21, 2008 at 10:50 AM, Stephen Neuendorffer
><stephen.neuendorffer@xilinx.com> wrote:
>> > Step 2).
>> > the code in arch/powerpc/???? is the devicetree equval=
ent
>> to
>> > arch/ppc/platforms/4xx/xilinx_ml410.c
>> http://git.xilinx.com/linux-2.6-xlnx.git contains a preliminary stab
at
>> the bootcode for Virtex. I've been using this for a while with
>> ARCH=3Dpowerpc. There isn't really much need for board specific plat=
form
>> code: This should (I think) be handled by the device tree. All of th=
is
>> is still pretty preliminary at the moment however. The big problem w=
ith
>> the boot code in the Xilinx tree is that you need to be able to alloc=
ate
>> memory in order to parse the device tree in order to figure out how m=
uch
>> memory you have. I just haven't rewritten the code to use libfdt, wh=
ich
>> can query the device tree without memory allocation yet. Grant has a=
>> slightly different scheme in his tree, but it works as well. General=
ly
>> I've been more focused on avoiding u-boot, whereas Grant has been usi=
ng
>> u-boot exclusively, I think.
>
>Actually, I'm not using u-boot at all. I've reworked the 'raw' image
>target to use libfdt and properly initialize the cache and stuff.
>I'll be merging it in the .26 merge window.
>
Hi,
Just wondering - is it possible to use U-Boot on the Xilinx XUPV2PRO
board or any similar tools (such as libfdt?) to copy a Linux kernel and=
ramdisk filesystem from a SystemACE card to memory, uncompress them and=
boot the Linux kernel etc?? If so is there any notes/docs about how to
do
this or similar online anywhere?
Any info. appreciated,
Regards&Thanks,
Alan.
^ permalink raw reply
* RE: Xilinx PowerPC
From: Stephen Neuendorffer @ 2008-02-22 18:11 UTC (permalink / raw)
To: alan.casey5, Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <4726E9350007F0D6@hawk.dcu.ie>
>=20
> Hi,
>=20
> Just wondering - is it possible to use U-Boot on the Xilinx XUPV2PRO
> board or any similar tools (such as libfdt?) to copy a Linux kernel
and
>=20
> ramdisk filesystem from a SystemACE card to memory, uncompress them
and
>=20
> boot the Linux kernel etc?? If so is there any notes/docs about how
to
> do
> this or similar online anywhere?
>=20
> Any info. appreciated,
> Regards&Thanks,
> Alan.
In theory, yes... All the infrastructure to do this exists, but I don't
know of anyone who as actually tried it yet with ARCH=3Dpowerpc kernels.
There=20
Steve
^ permalink raw reply
* Re: MPC8540 : What's "SPE used in kernel" ?
From: Andy Fleming @ 2008-02-22 18:33 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: linuxppc-dev
In-Reply-To: <20080222095022.GA635@ingate.macqel>
On Feb 22, 2008, at 03:50, Philippe De Muyter wrote:
> Dear list,
>
> I have just compiled linux-2.6.24 for a MPC8540 target using a MPC8540
> specific gcc.
>
> I then got tan infinity of "SPE used in kernel" messages. Looking
> at the
> sources I ifdeffed out the printk call in KernelSPE, and I now have a
> silent kernel, that seems to work fine.
>
> Is there something wrong in my setting and should I look further to
> debug this problem or is this perfectly normal ?
>
> I wonder why a kernel configured for E500 and compiled by a E500-
> specific gcc
> triggers this message. Is it invalid to use SPE instructions in
> the kernel
> or do I misunderstand the message ?
We don't currently support using SPE in the kernel. Are you using
SPE in the kernel for some reason? Do you think that the compiler is
automatically generating SPE code in the kernel? I've never seen
that before.
Andy
^ 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