* Re: Oops with TQM5200 on TQM5200
From: Grant Likely @ 2008-03-20 23:50 UTC (permalink / raw)
To: Anatolij Gustschin, Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <47E281B6.20702@denx.de>
Paul, my git server is down at the moment. Can you please pick this
one up for .25? It is needed to boot the tqm5200 board.
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Cheers,
g.
On Thu, Mar 20, 2008 at 9:24 AM, Anatolij Gustschin <agust@denx.de> wrote:
> Hello Wolfgang,
>
>
> Wolfgang Grandegger wrote:
>
> > I just tried Linux 2.6.25-rc6 on my TQM5200 module and got the attached
> > oops. Are there any known patches fixing the problems?
>
> try the patch below for tqm5200.dts, rebuild dtb and boot
> again. Not sure if it works for Linux 2.6.25-rc6, but for
> 2.6.25-rc3 it does.
>
> Anatolij
> --
> diff --git a/arch/powerpc/boot/dts/tqm5200.dts b/arch/powerpc/boot/dts/tqm5200.dts
> index c86464f..7c23bb3 100644
> --- a/arch/powerpc/boot/dts/tqm5200.dts
> +++ b/arch/powerpc/boot/dts/tqm5200.dts
> @@ -83,6 +83,7 @@
> };
>
> dma-controller@1200 {
> + device_type = "dma-controller";
> compatible = "fsl,mpc5200-bestcomm";
> reg = <1200 80>;
> interrupts = <3 0 0 3 1 0 3 2 0 3 3 0
> @@ -127,10 +128,25 @@
> ethernet@3000 {
> device_type = "network";
> compatible = "fsl,mpc5200-fec";
> - reg = <3000 800>;
> + reg = <3000 400>;
> local-mac-address = [ 00 00 00 00 00 00 ];
> interrupts = <2 5 0>;
> interrupt-parent = <&mpc5200_pic>;
> + phy-handle = <&phy0>;
> + };
> +
> + mdio@3000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,mpc5200b-mdio";
> + reg = <3000 400>; // fec range, since we need to setup fec interrupts
> + interrupts = <2 5 0>; // these are for "mii command finished", not link changes & co.
> + interrupt-parent = <&mpc5200_pic>;
> +
> + phy0:ethernet-phy@0 {
> + device_type = "ethernet-phy";
> + reg = <0>;
> + };
> };
>
> ata@3a00 {
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/3] [POWERPC] of_serial: Fix possible null dereference.
From: Grant Likely @ 2008-03-20 23:58 UTC (permalink / raw)
To: John Linn, Josh Boyer, Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <20080320144402.6A0E3518070@mail63-sin.bigfish.com>
On Thu, Mar 20, 2008 at 8:43 AM, John Linn <john.linn@xilinx.com> wrote:
> From: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
>
> The of_serial driver queries the current-speed property and attempts
> to use it to register the custom_divisor property of the uart_port.
> However, if current-speed is not set, then this code will dereference
> a bad pointer. The fix is to only set custom_divisor when a
> current-speed property appears in the device tree.
>
> Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
> Signed-off-by: John Linn <john.linn@xilinx.com>
This looks correct and appropriate to me.
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Josh/Arnd, could either of you pick this up?
Cheers,
g.
> ---
> drivers/serial/of_serial.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
> index a64d858..2efb892 100644
> --- a/drivers/serial/of_serial.c
> +++ b/drivers/serial/of_serial.c
> @@ -56,7 +56,9 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
> port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
> | UPF_FIXED_PORT;
> port->dev = &ofdev->dev;
> - port->custom_divisor = *clk / (16 * (*spd));
> + /* If current-speed was set, then try not to change it. */
> + if (spd)
> + port->custom_divisor = *clk / (16 * (*spd));
>
> return 0;
> }
> --
> 1.5.2.1
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH v2] Make 83xx perfmon support selectable
From: Jerry Van Baren @ 2008-03-20 23:59 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev list, Phillips Kim, Paul Mackerras
In-Reply-To: <E3C4695C-A2A9-4657-B771-97DFDD3F6ACE@kernel.crashing.org>
Kumar Gala wrote:
>
> On Mar 18, 2008, at 12:05 PM, Scott Wood wrote:
>
>> On Fri, Mar 07, 2008 at 05:59:03PM -0600, Andy Fleming wrote:
>>> Not all e300 cores support the performance monitors, and the ones
>>> that don't will be confused by the mf/mtpmr instructions. This
>>> allows the support to be optional, so the 8349 can turn it off
>>> while the 8379 can turn it on. Sadly, those aren't config options,
>>> so it will be left to the defconfigs and the users to make that
>>> determination.
>>
>> So does this mean we can't do multiplatform of something with perfmon and
>> something without perfmon? Seems like this should come from the device
>> tree, or PVR, or some other runtime check.
>
> It possible if your binutils supports generating the instructions. I
> believe Kim was going to look at doing a patch to use a #define
> MFPMR(x)/#define MTPMR() so we don't have to worry about toolchain
> versions.
>
> - k
Hi Kumar, Scott,
Per Andy (and my limited reading of the UMs), some 83xx have the PMR
registers and some don't. The compiler either supports the PMR register
or it doesn't. If you make it runtime configurable, people running CPUs
that don't support the specific PMR will have to change compiler
configurations in order to compile with the PMR register in there (could
have unintended consequences).
Also, if you look at the code (arch/powerpc/kernel/pmc.c), there are
several different types of PMR registers, based on the core and flavor
of the core. Finding or making a compiler setup that supports all of
the possible PMR registers could be a problem.
You would still have to make the PMR read/write runtime selectable
because the CPUs that don't support that register will raise an
exception IIRC (an Really Bad Thing[tm]).
It crossed my mind /very briefly/ to use the FDT to select this but was
not willing to put that much effort into it.
* Toolchain issues (first & second objection, above) - non-trivial
* Would have to read the enable/disable into a static (global?) variable
to minimize the time impact for the runtime decision - ugh
* Need to add yet another definition to the booting-without-of.txt
(bwoof) and appropriate .dts files - OK, I'm lazy
Best regards,
gvb
^ permalink raw reply
* Re: Oops with TQM5200 on TQM5200
From: Bartlomiej Sieka @ 2008-03-21 0:07 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Anatolij Gustschin
In-Reply-To: <fa686aa40803201650t289cd800gfda389b192c1834c@mail.gmail.com>
Grant Likely wrote:
> Paul, my git server is down at the moment. Can you please pick this
> one up for .25? It is needed to boot the tqm5200 board.
Could we also have similar fixes for cm5200.dts and motionpro.dts picked
up? I could provide the patches within a day -- will this be OK?
Regards,
Bartlomiej
>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
>
> Cheers,
> g.
>
> On Thu, Mar 20, 2008 at 9:24 AM, Anatolij Gustschin <agust@denx.de> wrote:
>> Hello Wolfgang,
>>
>>
>> Wolfgang Grandegger wrote:
>>
>> > I just tried Linux 2.6.25-rc6 on my TQM5200 module and got the attached
>> > oops. Are there any known patches fixing the problems?
>>
>> try the patch below for tqm5200.dts, rebuild dtb and boot
>> again. Not sure if it works for Linux 2.6.25-rc6, but for
>> 2.6.25-rc3 it does.
>>
>> Anatolij
>> --
>> diff --git a/arch/powerpc/boot/dts/tqm5200.dts b/arch/powerpc/boot/dts/tqm5200.dts
>> index c86464f..7c23bb3 100644
>> --- a/arch/powerpc/boot/dts/tqm5200.dts
>> +++ b/arch/powerpc/boot/dts/tqm5200.dts
>> @@ -83,6 +83,7 @@
>> };
>>
>> dma-controller@1200 {
>> + device_type = "dma-controller";
>> compatible = "fsl,mpc5200-bestcomm";
>> reg = <1200 80>;
>> interrupts = <3 0 0 3 1 0 3 2 0 3 3 0
>> @@ -127,10 +128,25 @@
>> ethernet@3000 {
>> device_type = "network";
>> compatible = "fsl,mpc5200-fec";
>> - reg = <3000 800>;
>> + reg = <3000 400>;
>> local-mac-address = [ 00 00 00 00 00 00 ];
>> interrupts = <2 5 0>;
>> interrupt-parent = <&mpc5200_pic>;
>> + phy-handle = <&phy0>;
>> + };
>> +
>> + mdio@3000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "fsl,mpc5200b-mdio";
>> + reg = <3000 400>; // fec range, since we need to setup fec interrupts
>> + interrupts = <2 5 0>; // these are for "mii command finished", not link changes & co.
>> + interrupt-parent = <&mpc5200_pic>;
>> +
>> + phy0:ethernet-phy@0 {
>> + device_type = "ethernet-phy";
>> + reg = <0>;
>> + };
>> };
>>
>> ata@3a00 {
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] Xilinx: of_serial support for Xilinx uart 16550.
From: Grant Likely @ 2008-03-21 0:19 UTC (permalink / raw)
To: John Linn; +Cc: linuxppc-dev
In-Reply-To: <20080320144402.3063517C005D@mail148-sin.bigfish.com>
On Thu, Mar 20, 2008 at 8:43 AM, John Linn <john.linn@xilinx.com> wrote:
> The Xilinx 16550 uart core is not a standard 16550, because it uses
> word-based addressing rather than byte-based addressing. As a result,
> it is not compatible with the open firmware 'ns16550' compatible
> binding. This code introduces new bindings, which pass the correct
> register base and regshift properties to the uart driver to enable
> this core to be used. Doing this cleanly required some refactoring of
> the existing code.
Personally, I'm not fond of this approach. There is already some
traction to using the reg-shift property to specify spacing, and I
think it would be appropriate to also define a reg-offset property to
handle the +3 offset and then let the xilinx 16550 nodes use those.
More comments below.
>
> Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
> Signed-off-by: John Linn <john.linn@xilinx.com>
> ---
> drivers/serial/of_serial.c | 47 ++++++++++++++++++++++++++++++-------------
> 1 files changed, 33 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
> index 2efb892..910c94f 100644
> --- a/drivers/serial/of_serial.c
> +++ b/drivers/serial/of_serial.c
> @@ -20,13 +20,15 @@
> struct of_serial_info {
> int type;
> int line;
> + int regshift;
> + int regoffset;
> };
>
> /*
> * Fill a struct uart_port for a given device node
> */
> static int __devinit of_platform_serial_setup(struct of_device *ofdev,
> - int type, struct uart_port *port)
> + struct of_serial_info *info, struct uart_port *port)
> {
> struct resource resource;
> struct device_node *np = ofdev->node;
> @@ -48,17 +50,16 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
> }
>
> spin_lock_init(&port->lock);
> - port->mapbase = resource.start;
> + port->mapbase = resource.start + info->regoffset;
> port->irq = irq_of_parse_and_map(np, 0);
> port->iotype = UPIO_MEM;
> - port->type = type;
> + port->type = info->type;
> + port->regshift = info->regshift;
> port->uartclk = *clk;
> port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
> | UPF_FIXED_PORT;
> port->dev = &ofdev->dev;
> - /* If current-speed was set, then try not to change it. */
> - if (spd)
> - port->custom_divisor = *clk / (16 * (*spd));
> + port->custom_divisor = *clk / (16 * (*spd));
Oops, looks like you're undoing your previous patch here.
>
> return 0;
> }
> @@ -81,8 +82,9 @@ static int __devinit of_platform_serial_probe(struct of_device *ofdev,
> if (info == NULL)
> return -ENOMEM;
>
> - port_type = (unsigned long)id->data;
> - ret = of_platform_serial_setup(ofdev, port_type, &port);
> + memcpy(info, id->data, sizeof(struct of_serial_info));
> + port_type = info->type;
> + ret = of_platform_serial_setup(ofdev, info, &port);
> if (ret)
> goto out;
>
> @@ -100,7 +102,6 @@ static int __devinit of_platform_serial_probe(struct of_device *ofdev,
> if (ret < 0)
> goto out;
>
> - info->type = port_type;
> info->line = ret;
> ofdev->dev.driver_data = info;
> return 0;
> @@ -128,15 +129,33 @@ static int of_platform_serial_remove(struct of_device *ofdev)
> return 0;
> }
>
> +static struct of_serial_info __devinitdata ns8250_info = { .type = PORT_8250 };
> +static struct of_serial_info __devinitdata ns16450_info = { .type = PORT_16450 };
> +static struct of_serial_info __devinitdata ns16550_info = { .type = PORT_16550 };
> +static struct of_serial_info __devinitdata ns16750_info = { .type = PORT_16750 };
> +static struct of_serial_info __devinitdata xilinx_16550_info = {
> + .type = PORT_16550,
> + .regshift = 2,
> + .regoffset = 3,
> +};
> +static struct of_serial_info __devinitdata unknown_info = { .type = PORT_UNKNOWN };
In support of my argument; the fact that you need a table of data says
to me that this data should really be encoded in the device tree. :-)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Oops with TQM5200 on TQM5200
From: Grant Likely @ 2008-03-21 0:20 UTC (permalink / raw)
To: Bartlomiej Sieka; +Cc: linuxppc-dev, Anatolij Gustschin, Paul Mackerras
In-Reply-To: <47E2FC3E.1020705@semihalf.com>
On Thu, Mar 20, 2008 at 6:07 PM, Bartlomiej Sieka <tur@semihalf.com> wrote:
> Grant Likely wrote:
> > Paul, my git server is down at the moment. Can you please pick this
> > one up for .25? It is needed to boot the tqm5200 board.
>
> Could we also have similar fixes for cm5200.dts and motionpro.dts picked
> up? I could provide the patches within a day -- will this be OK?
Yes, please do; heck put them all into one patch if you like; and I'll ack them.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: crash in init_ipic_sysfs on efika
From: Paul Mackerras @ 2008-03-21 1:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Olaf Hering
In-Reply-To: <63858171-157B-4726-94F2-E64B85A0D8D5@kernel.crashing.org>
Kumar Gala writes:
> We should look and see if we can change init_ipic_sysfs() from a
> subsys_initcall() to just getting called at the end of ipic_init().
If init_ipic is called from init_IRQ then I would expect that's way
too early to be calling sysfs stuff.
Paul.
^ permalink raw reply
* Re: [PATCH 1/3] [POWERPC] of_serial: Fix possible null dereference.
From: Josh Boyer @ 2008-03-21 1:41 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, John Linn, Arnd Bergmann
In-Reply-To: <fa686aa40803201658g6fbdcab0he06dd1e3c83ca900@mail.gmail.com>
On Thu, 20 Mar 2008 17:58:07 -0600
"Grant Likely" <grant.likely@secretlab.ca> wrote:
> On Thu, Mar 20, 2008 at 8:43 AM, John Linn <john.linn@xilinx.com> wrote:
> > From: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
> >
> > The of_serial driver queries the current-speed property and attempts
> > to use it to register the custom_divisor property of the uart_port.
> > However, if current-speed is not set, then this code will dereference
> > a bad pointer. The fix is to only set custom_divisor when a
> > current-speed property appears in the device tree.
> >
> > Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
> > Signed-off-by: John Linn <john.linn@xilinx.com>
>
> This looks correct and appropriate to me.
>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
Agreed.
Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> Josh/Arnd, could either of you pick this up?
Arnd, can you send this on to Andrew? Or if you are busy I can.
josh
> > ---
> > drivers/serial/of_serial.c | 4 +++-
> > 1 files changed, 3 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
> > index a64d858..2efb892 100644
> > --- a/drivers/serial/of_serial.c
> > +++ b/drivers/serial/of_serial.c
> > @@ -56,7 +56,9 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
> > port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
> > | UPF_FIXED_PORT;
> > port->dev = &ofdev->dev;
> > - port->custom_divisor = *clk / (16 * (*spd));
> > + /* If current-speed was set, then try not to change it. */
> > + if (spd)
> > + port->custom_divisor = *clk / (16 * (*spd));
> >
> > return 0;
> > }
> > --
> > 1.5.2.1
> >
> >
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
>
>
>
^ permalink raw reply
* Re: DTS question
From: Sean MacLennan @ 2008-03-21 4:12 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <47E2E4A2.9000801@freescale.com>
On Thu, 20 Mar 2008 17:26:42 -0500
"Scott Wood" <scottwood@freescale.com> wrote:
> > ad7414 {
> > compatible = "ad7414";
>
> This should proabably have a manufacturer prefix.
I wondered about this. Since the AD from Analog Devices is built into
the part number, I didn't know if it was needed. And analog-devices is
pretty long ;)
But I am willing to put it in if it is necessary.
Cheers,
Sean
^ permalink raw reply
* Re: DTS question
From: Grant Likely @ 2008-03-21 4:34 UTC (permalink / raw)
To: Sean MacLennan; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20080321001236.4e37bba4@lappy.seanm.ca>
On Thu, Mar 20, 2008 at 10:12 PM, Sean MacLennan
<smaclennan@pikatech.com> wrote:
> On Thu, 20 Mar 2008 17:26:42 -0500
> "Scott Wood" <scottwood@freescale.com> wrote:
>
> > > ad7414 {
> > > compatible = "ad7414";
> >
> > This should proabably have a manufacturer prefix.
>
> I wondered about this. Since the AD from Analog Devices is built into
> the part number, I didn't know if it was needed. And analog-devices is
> pretty long ;)
>
> But I am willing to put it in if it is necessary.
Convention is to use the stock ticker symbol. If the company is
private and has no stock ticker symbol, then the company name should
be used.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: DTS question
From: Sean MacLennan @ 2008-03-21 5:09 UTC (permalink / raw)
To: Grant Likely; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <fa686aa40803202134p7db6a106n8487aa0040b5990c@mail.gmail.com>
On Thu, 20 Mar 2008 22:34:21 -0600
"Grant Likely" <grant.likely@secretlab.ca> wrote:
> Convention is to use the stock ticker symbol. If the company is
> private and has no stock ticker symbol, then the company name should
> be used.
I didn't know that. ADI it is then.
IIC0: i2c@ef600700 {
compatible = "ibm,iic-440ep", "ibm,iic-440gp", "ibm,iic";
reg = <ef600700 14>;
interrupt-parent = <&UIC0>;
interrupts = <2 4>;
index = <0>;
#address-cells = <1>;
#size-cells = <0>;
ad7414@4a {
compatible = "adi,ad7414";
reg = <4a>;
interrupts = <19 8>;
interrupt-parent = <&UIC0>;
};
};
Cheers,
Sean
^ permalink raw reply
* Re: crash in init_ipic_sysfs on efika
From: Grant Likely @ 2008-03-21 5:14 UTC (permalink / raw)
To: Olaf Hering, Paul Mackerras, Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <20080317195305.GA13298@aepfle.de>
On Mon, Mar 17, 2008 at 1:53 PM, Olaf Hering <olaf@aepfle.de> wrote:
>
> I cant reproduce this bug on my board, but:
>
> The global primary_ipic in arch/powerpc/sysdev/ipic.c can remain NULL if
> ipic_init() fails. init_ipic_sysfs() will crash in that case.
>
> Something like this may fix it:
>
> Index: linux-2.6.25-rc6/arch/powerpc/sysdev/ipic.c
> ===================================================================
> --- linux-2.6.25-rc6.orig/arch/powerpc/sysdev/ipic.c
> +++ linux-2.6.25-rc6/arch/powerpc/sysdev/ipic.c
> @@ -906,7 +906,7 @@ static int __init init_ipic_sysfs(void)
> {
> int rc;
>
> - if (!primary_ipic->regs)
> + if (!primary_ipic || !primary_ipic->regs)
> return -ENODEV;
> printk(KERN_DEBUG "Registering ipic with sysfs...\n");
Confirmed, this patch fixes the problem. Paulus or Kumar, can you
please pick it up for .25?
Thanks,
g.
>
>
>
> ok boot eth:192.168.2.52,inst32 inst32 console=ttyPSC0,115200
>
> SuSE Linux zImage starting: loaded at 00040000-00d24cbc (0/0/01003ed8;
> sp: 017ffe80)
> uncompressing ELF header done. (00000100 bytes)
> Allocated 008584d4 bytes for kernel @ 02000000
> Allocated 00a963a2 bytes for initrd @ 02859000
> uncompressing kernel done. (004faeb8 bytes)
> entering kernel at 02010000(2859000/a963a2/01003ed8)
> OF stdout device is: /failsafe
> command line: console=ttyPSC0,115200
> memory layout at init:
> alloc_bottom : 032f0000
> alloc_top : 30000000
> alloc_top_hi : f000c000
> rmo_top : 30000000
> ram_top : f000c000
> Looking for displays
> instantiating rtas at 0x07ffb000 ... done
> Applying EFIKA device tree fixups
> Fixing bestcomm interrupts property
> Adding Ethernet MDIO node
> Adding Ethernet PHY node
> copying OF device tree ...
> Building dt strings...
> Building dt structure...
> Device tree strings 0x032f1000 -> 0x032f17e0
> Device tree struct 0x032f2000 -> 0x03315000
> Calling quiesce ...
> returning from prom_init
> Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
> Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
> Memory: 113264k/131072k available (4808k kernel code, 17648k reserved,
> 164k data, 461k bss, 228k init)
> Security Framework initialized
> AppArmor: AppArmor initialized
> AppArmor: Unable to log event (1505) to audit subsys
> AppArmor: Registered secondary security module name="capability"
> AppArmor: Unable to log event (1505) to audit subsys
> Capability LSM initialized as secondary
> Failure registering Root Plug module with the kernel
> AppArmor: Unable to register %s as a secondary security module
> name="root_plug"
> AppArmor: Unable to log event (1505) to audit subsys
> Failure registering Root Plug module with primary security module.
> Mount-cache hash table entries: 512
> net_namespace: 544 bytes
> NET: Registered protocol family 16
> PCI: Probing PCI hardware
> DMA: MPC52xx BestComm driver
> DMA: MPC52xx BestComm engine @f0001200 ok !
> Unable to handle kernel paging request for data at address 0x00000000
> Faulting instruction address: 0xc0486aac
> Oops: Kernel access of bad area, sig: 11 [#1]
> Efika
> Modules linked in:
> NIP: c0486aac LR: c0479200 CTR: c0486a90
> REGS: c782bea0 TRAP: 0300 Not tainted (2.6.25-rc5-git2-5-default)
> MSR: 00009032 <EE,ME,IR,DR> CR: 44002082 XER: 20000000
> DAR: 00000000, DSISR: 20000000
> TASK = c78237c0[1] 'swapper' THREAD: c782a000
> GPR00: c0479200 c782bf50 c78237c0 ffffffed 00000003 00000000 00000000
> 00000000
> GPR08: fffffffc 00000000 c7800780 000f06a0 22002022 dffffff7 c0405540
> c0405558
> GPR16: c0405568 c040558c c0405594 c04055a4 c04055d0 c0400000 024184a4
> ffffffff
> GPR24: 00000000 c04a6468 c0405550 c782a000 c04e0000 00000000 00000000
> c04af198
> NIP [c0486aac] init_ipic_sysfs+0x1c/0x90
> LR [c0479200] kernel_init+0xf8/0x2a0
> Call Trace:
> [c782bf50] [c04869fc] mpc52xx_bcom_init+0x24/0x34 (unreliable)
> [c782bf60] [c0479200] kernel_init+0xf8/0x2a0
> [c782bff0] [c001330c] kernel_thread+0x44/0x60
> Instruction dump:
> 80010024 bb61000c 38210020 7c0803a6 4e800020 9421fff0 7c0802a6 3d20c04f
> 3860ffed 90010014 93e1000c 81299730 <80090000> 2f800000 41be0058 3c60c041
> ---[ end trace 8640abe69a316dee ]---
> Kernel panic - not syncing: Attempted to kill init!
> Rebooting in 180 seconds..
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Oops with TQM5200 on TQM5200
From: Wolfgang Grandegger @ 2008-03-21 6:30 UTC (permalink / raw)
To: Bartlomiej Sieka; +Cc: linuxppc-dev, Anatolij Gustschin, Paul Mackerras
In-Reply-To: <47E2FC3E.1020705@semihalf.com>
Bartlomiej Sieka wrote:
> Grant Likely wrote:
>> Paul, my git server is down at the moment. Can you please pick this
>> one up for .25? It is needed to boot the tqm5200 board.
>
> Could we also have similar fixes for cm5200.dts and motionpro.dts picked
> up? I could provide the patches within a day -- will this be OK?
At that occasion, could you please also add two CAN nodes to tqm5200.dts
as shown:
s$ diff -u tqm5200.dts tqm5200.dts.CAN
--- tqm5200.dts 2008-03-20 18:44:40.000000000 +0100
+++ tqm5200.dts.CAN 2008-03-21 07:27:49.000000000 +0100
@@ -68,6 +68,22 @@
fsl,has-wdt;
};
+ can@900 {
+ compatible = "fsl,mpc5200-mscan";
+ cell-index = <0>;
+ interrupts = <2 11 0>;
+ interrupt-parent = <&mpc5200_pic>;
+ reg = <900 80>;
+ };
+
+ can@980 {
+ compatible = "fsl,mpc5200-mscan";
+ cell-index = <1>;
+ interrupts = <2 12 0>;
+ interrupt-parent = <&mpc5200_pic>;
+ reg = <980 80>;
+ };
+
gpio@b00 {
compatible = "fsl,mpc5200-gpio";
reg = <b00 40>;
Thanks a lot.
Wolfgang.
^ permalink raw reply
* Re: DTS question
From: David Gibson @ 2008-03-21 7:05 UTC (permalink / raw)
To: Sean MacLennan; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20080321010941.5e4bf9d4@lappy.seanm.ca>
On Fri, Mar 21, 2008 at 01:09:41AM -0400, Sean MacLennan wrote:
> On Thu, 20 Mar 2008 22:34:21 -0600
> "Grant Likely" <grant.likely@secretlab.ca> wrote:
>
> > Convention is to use the stock ticker symbol. If the company is
> > private and has no stock ticker symbol, then the company name should
> > be used.
>
> I didn't know that. ADI it is then.
Well.. stock ticker is the new convention. IEEE1275 used IEEE
assigned OUI strings (Organization Unique Identifiers). Often those
are the same as the stock ticker, but not always.
Stock ticker is a good choice for new things, but for anything from a
vendor which has existing 1275 bindings for its products, I think we
should keep the original assigned OUI, even if it differs from the
stock ticker.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* RE: [PATCH] Add Fixed PHY support for ucc_geth
From: Li Yang @ 2008-03-21 8:51 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Netdev, Joakim Tjernlund, Linuxppc-Embedded@Ozlabs.Org
In-Reply-To: <1205833615-15833-1-git-send-email-Joakim.Tjernlund@transmode.se>
> -----Original Message-----
> From: Joakim Tjernlund [mailto:Joakim.Tjernlund@transmode.se]=20
> Sent: Tuesday, March 18, 2008 5:47 PM
> To: Netdev; Li Yang; Linuxppc-Embedded@Ozlabs.Org
> Cc: Joakim Tjernlund
> Subject: [PATCH] Add Fixed PHY support for ucc_geth
>=20
> The new Fixed PHY method, fixed-link property, isn't
> impl. for ucc_geth which makes fixed PHYs non functional.
> Add support for the new method to restore the Fixed PHY
> functionality.
>=20
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Signed-off-by: Li Yang <leoli@freescale.com>
---
Ps: This patch depends on the patch "ucc_geth: use correct thread number
for 10/100Mbps link" to apply, which hasn't made to Linus' tree for now
but has already been in Jeff and David's trees.
> ---
>=20
> This is a regression as fixed PHYs works in 2.6.23 and I am
> using it.
>=20
> drivers/net/ucc_geth.c | 53=20
> +++++++++++++++++++++++++++--------------------
> 1 files changed, 30 insertions(+), 23 deletions(-)
>=20
> diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
> index ecc5712..18c8b39 100644
> --- a/drivers/net/ucc_geth.c
> +++ b/drivers/net/ucc_geth.c
> @@ -3836,6 +3836,7 @@ static int ucc_geth_probe(struct=20
> of_device* ofdev, const struct of_device_id *ma
> struct device_node *phy;
> int err, ucc_num, max_speed =3D 0;
> const phandle *ph;
> + const u32 *fixed_link;
> const unsigned int *prop;
> const char *sprop;
> const void *mac_addr;
> @@ -3926,18 +3927,38 @@ static int ucc_geth_probe(struct=20
> of_device* ofdev, const struct of_device_id *ma
> =20
> ug_info->uf_info.regs =3D res.start;
> ug_info->uf_info.irq =3D irq_of_parse_and_map(np, 0);
> + fixed_link =3D of_get_property(np, "fixed-link", NULL);
> + if (fixed_link) {
> + ug_info->mdio_bus =3D 0;
> + ug_info->phy_address =3D fixed_link[0];
> + phy =3D NULL;
> + } else {
> + ph =3D of_get_property(np, "phy-handle", NULL);
> + phy =3D of_find_node_by_phandle(*ph);
> =20
> - ph =3D of_get_property(np, "phy-handle", NULL);
> - phy =3D of_find_node_by_phandle(*ph);
> + if (phy =3D=3D NULL)
> + return -ENODEV;
> =20
> - if (phy =3D=3D NULL)
> - return -ENODEV;
> + /* set the PHY address */
> + prop =3D of_get_property(phy, "reg", NULL);
> + if (prop =3D=3D NULL)
> + return -1;
> + ug_info->phy_address =3D *prop;
> +
> + /* Set the bus id */
> + mdio =3D of_get_parent(phy);
> +
> + if (mdio =3D=3D NULL)
> + return -1;
> =20
> - /* set the PHY address */
> - prop =3D of_get_property(phy, "reg", NULL);
> - if (prop =3D=3D NULL)
> - return -1;
> - ug_info->phy_address =3D *prop;
> + err =3D of_address_to_resource(mdio, 0, &res);
> + of_node_put(mdio);
> +
> + if (err)
> + return -1;
> +
> + ug_info->mdio_bus =3D res.start;
> + }
> =20
> /* get the phy interface type, or default to MII */
> prop =3D of_get_property(np, "phy-connection-type", NULL);
> @@ -3982,20 +4003,6 @@ static int ucc_geth_probe(struct=20
> of_device* ofdev, const struct of_device_id *ma
> ug_info->numThreadsRx =3D UCC_GETH_NUM_OF_THREADS_4;
> }
> =20
> - /* Set the bus id */
> - mdio =3D of_get_parent(phy);
> -
> - if (mdio =3D=3D NULL)
> - return -1;
> -
> - err =3D of_address_to_resource(mdio, 0, &res);
> - of_node_put(mdio);
> -
> - if (err)
> - return -1;
> -
> - ug_info->mdio_bus =3D res.start;
> -
> if (netif_msg_probe(&debug))
> printk(KERN_INFO "ucc_geth: UCC%1d at 0x%8x=20
> (irq =3D %d) \n",
> ug_info->uf_info.ucc_num + 1,=20
> ug_info->uf_info.regs,
> --=20
> 1.5.4.3
>=20
>=20
^ permalink raw reply
* Re: [PATCH] [POWERPC] Add AMCC Glacier 460GT eval board dts
From: Benjamin Herrenschmidt @ 2008-03-21 9:00 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1205943310-26323-1-git-send-email-sr@denx.de>
On Wed, 2008-03-19 at 17:15 +0100, Stefan Roese wrote:
> + cpu@0 {
> + device_type = "cpu";
> + model = "PowerPC,460GT";
> + reg = <0>;
>
I wonder if we should do something here to differenciate the SoC chip
from the core. After all, all those 4xx mostly have the same core (there
are 2 or 3 revisions of the core maybe ...) but they tend to have all
different PVR which is a pain and won't scale...
Maybe AMCC could do something in HW (splitting the PVR from whatever
indicates what "chip" it is, and keeping the PVR purely for the core
rev) but I'm wondering if we should also do something in the DTS..
Stefan can you talk to your AMCC contacts about this ?
As for the DTS, maybe a "compatible" property in the CPU might make some
sense with a content along the lines of "ppc440x6" or whatever rev of
the 440 core it is.
What do you think ?
Cheers,
Ben.
^ permalink raw reply
* Re: crash in init_ipic_sysfs on efika
From: Paul Mackerras @ 2008-03-21 9:03 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Olaf Hering
In-Reply-To: <fa686aa40803202214k7d8596a5y922a34f33d33dca2@mail.gmail.com>
Grant Likely writes:
> Confirmed, this patch fixes the problem. Paulus or Kumar, can you
> please pick it up for .25?
Sure, will do. I thought about putting it in the last batch but I
wanted an ack from you.
Anyone else got any last-minute things for 2.6.25?
Paul.
^ permalink raw reply
* Re: [BUG]2.6.25-rc6:Unable to handle kernel paging request
From: Paul Mackerras @ 2008-03-21 9:07 UTC (permalink / raw)
To: skumar; +Cc: Poornima Nayak, linuxppc-dev, akpm, linux-kernel
In-Reply-To: <20080320184216.GB32259@in.ibm.com>
Sudhir Kumar writes:
> > I suggest you turn off CONFIG_SENSORS_F71805F.
> It was a new feature so I turned it on while compiling.
> I have tried by turning off CONFIG_SENSORS_F71805F but the bug
> is still present.
Do you mean that you still saw a crash in f71805f_find? If so, then
you have some problem with the way you rebuilt the kernel, or you
didn't boot the kernel you thought you did, or possibly that
CONFIG_SENSORS_F71805F is getting turned back on by a select statement
somewhere in some Kconfig file.
If you really turned CONFIG_SENSORS_F71805F off then there would be no
f71805f_find function in the kernel.
Paul.
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] Xilinx: of_serial support for Xilinx uart 16550.
From: Paul Mackerras @ 2008-03-21 9:21 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, John Linn
In-Reply-To: <fa686aa40803201719i7bf02ba2qd259f1a36a24d943@mail.gmail.com>
Grant Likely writes:
> Personally, I'm not fond of this approach. There is already some
> traction to using the reg-shift property to specify spacing, and I
> think it would be appropriate to also define a reg-offset property to
> handle the +3 offset and then let the xilinx 16550 nodes use those.
Why do we need a reg-offset property when we can just add the offset
to the appropriate word(s) in the reg property?
Paul.
^ permalink raw reply
* Re: crash in init_ipic_sysfs on efika
From: Kumar Gala @ 2008-03-21 9:18 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Olaf Hering
In-Reply-To: <18403.31214.826941.838442@cargo.ozlabs.ibm.com>
On Fri, 21 Mar 2008, Paul Mackerras wrote:
> Grant Likely writes:
>
> > Confirmed, this patch fixes the problem. Paulus or Kumar, can you
> > please pick it up for .25?
>
> Sure, will do. I thought about putting it in the last batch but I
> wanted an ack from you.
>
> Anyone else got any last-minute things for 2.6.25?
since you are going to send something to linus let me update the fsl
defconfigs and send you a pull request.
- k
^ permalink raw reply
* RFC - use of _stext vs PAGE_OFFSET?
From: Kumar Gala @ 2008-03-21 9:27 UTC (permalink / raw)
To: linuxppc-dev
Is there any reason not use use _stext?
- k
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index cd870a8..b0989ca 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -277,7 +277,7 @@ void __init setup_arch(char **cmdline_p)
if (ppc_md.panic)
setup_panic();
- init_mm.start_code = PAGE_OFFSET;
+ init_mm.start_code = (unsigned long)_stext;
init_mm.end_code = (unsigned long) _etext;
init_mm.end_data = (unsigned long) _edata;
init_mm.brk = klimit;
^ permalink raw reply related
* [PATCH] [POWERPC] Provide access to arch/powerpc include path on ppc64
From: Kumar Gala @ 2008-03-21 9:32 UTC (permalink / raw)
To: linuxppc-dev
There does not appear to be any reason that we shouldn't just have
-Iarch/$(ARCH) on both ppc32 and ppc64 builds.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/Makefile | 10 ++++------
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index ab5cfe8..43ee815 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -71,13 +71,11 @@ endif
LDFLAGS_vmlinux := -Bstatic
-CPPFLAGS-$(CONFIG_PPC32) := -Iarch/$(ARCH)
-AFLAGS-$(CONFIG_PPC32) := -Iarch/$(ARCH)
CFLAGS-$(CONFIG_PPC64) := -mminimal-toc -mtraceback=none -mcall-aixdesc
-CFLAGS-$(CONFIG_PPC32) := -Iarch/$(ARCH) -ffixed-r2 -mmultiple
-KBUILD_CPPFLAGS += $(CPPFLAGS-y)
-KBUILD_AFLAGS += $(AFLAGS-y)
-KBUILD_CFLAGS += -msoft-float -pipe $(CFLAGS-y)
+CFLAGS-$(CONFIG_PPC32) := -ffixed-r2 -mmultiple
+KBUILD_CPPFLAGS += -Iarch/$(ARCH)
+KBUILD_AFLAGS += -Iarch/$(ARCH)
+KBUILD_CFLAGS += -msoft-float -pipe -Iarch/$(ARCH) $(CFLAGS-y)
CPP = $(CC) -E $(KBUILD_CFLAGS)
CHECKFLAGS += -m$(CONFIG_WORD_SIZE) -D__powerpc__ -D__powerpc$(CONFIG_WORD_SIZE)__
--
1.5.4.1
^ permalink raw reply related
* Re: [PATCH] [POWERPC] Add AMCC Glacier 460GT eval board dts
From: Stefan Roese @ 2008-03-21 10:54 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1206090031.8420.67.camel@pasglop>
On Friday 21 March 2008, Benjamin Herrenschmidt wrote:
> On Wed, 2008-03-19 at 17:15 +0100, Stefan Roese wrote:
> > + cpu@0 {
> > + device_type = "cpu";
> > + model = "PowerPC,460GT";
> > + reg = <0>;
>
> I wonder if we should do something here to differenciate the SoC chip
> from the core. After all, all those 4xx mostly have the same core (there
> are 2 or 3 revisions of the core maybe ...) but they tend to have all
> different PVR which is a pain and won't scale...
>
> Maybe AMCC could do something in HW (splitting the PVR from whatever
> indicates what "chip" it is, and keeping the PVR purely for the core
> rev) but I'm wondering if we should also do something in the DTS..
> Stefan can you talk to your AMCC contacts about this ?
Yes, I'll do that. Not sure about the outcome though.
> As for the DTS, maybe a "compatible" property in the CPU might make some
> sense with a content along the lines of "ppc440x6" or whatever rev of
> the 440 core it is.
>
> What do you think ?
Good idea. I'll try to come up with a list for all existing 4xx SoC's and it's
core versions.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* Re: crash in init_ipic_sysfs on efika
From: Benjamin Herrenschmidt @ 2008-03-21 11:18 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, Olaf Hering
In-Reply-To: <47E24B69.2080607@genesi-usa.com>
On Thu, 2008-03-20 at 11:32 +0000, Matt Sealey wrote:
> subsys_initcall(init_ipic_sysfs); <-- this, in my eyes, is the culprit. If
> init_ipic() runs, init_ipic_sysfs should be called from that, not left for
> some further subsystem to blindly try and register sysfs nodes for devices
> which may not even be present..
>
> I'd love someone to explain to me how this works and why, and why it isn't
> braindead? :D
init_ipic() is called way too early to be able to manpipulate sysfs.
Ben.
^ permalink raw reply
* Re: DTS question
From: Segher Boessenkool @ 2008-03-21 11:31 UTC (permalink / raw)
To: Grant Likely; +Cc: Scott Wood, linuxppc-dev, Sean MacLennan
In-Reply-To: <fa686aa40803202134p7db6a106n8487aa0040b5990c@mail.gmail.com>
>> I wondered about this. Since the AD from Analog Devices is built into
>> the part number, I didn't know if it was needed. And analog-devices
>> is
>> pretty long ;)
>>
>> But I am willing to put it in if it is necessary.
>
> Convention is to use the stock ticker symbol. If the company is
> private and has no stock ticker symbol, then the company name should
> be used.
The three forms are, in order of preference:
0NNNNNN with NNNNNN the (hexadecimal) OUI;
ABCDE (uppercase stock symbol);
abcde (any name that cannot be confused for the other two forms;
usually by making it lowercase).
The preference is in this order because OUI _is_ unique, stock ticker
will likely be unique (but not always!), and for random names there
is no guarantee or assurance at all.
I've never actually seen the OUI used, it's not very user-friendly ;-)
Segher
^ 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