* w1-gpio oops
@ 2010-11-09 13:59 Alan Pearson
2010-11-09 14:29 ` Hemanth V
0 siblings, 1 reply; 8+ messages in thread
From: Alan Pearson @ 2010-11-09 13:59 UTC (permalink / raw)
To: linux-arm-kernel
Hi Guys,
First post to list, so be kind :)
I'm trying to get w1 (one wire) working over GPIO and despite my best efforts this results in a nasty oops.
Firstly, I'd like to say I'm no kernel hacker and my knowledge of Ooops and kernel debugging is limited, but I'm willing to learn:)
I'm using Kernel.org kernel 2.6.36 (also tried 2.6.37-rc1) on a Marvell based 'GuruPlug server' device.
I'm using the GPIO pins that are on the U-SNAP interface, namely MPP38.
Having compiled and deployed the kernel to the device and verifying that I can control the GPIO pins OK from userspace using /sys, I then proceed to try and get w1 working on GPIO (after first unexporting the pin I want).
There's sparse info on this, and most wisdom tells me to use the w1-gpio-custom module for openWRT to set the pin number before loading the module, which I've done.
sheevaplug-debian:~# modprobe wire
sheevaplug-debian:~# modprobe w1_gpio_custom bus0=0,38,0
sheevaplug-debian:~# modprobe w1_gpio
Internal error: Oops - undefined instruction: 0 [#1] PREEMPT
last sysfs file: /sys/devices/virtual/mtd/mtd2/mtdblock2/range
Modules linked in: w1_gpio(+) w1_gpio_custom wire xt_tcpudp iptable_filter ip_tables x_tables ipv6 libertas_sdio libertas sata_mv mv_c]
CPU: 0 Not tainted (2.6.37-rc1 #3)
PC is at 0xbf0d40d8
LR is at w1_gpio_probe+0x14c/0x194 [w1_gpio]
pc : [<bf0d40d8>] lr : [<bf0da160>] psr: a0000013
sp : deb6be98 ip : 00000000 fp : beca8984
r10: 00000040 r9 : deb6a000 r8 : bf0da040
r7 : deb27f00 r6 : 00000000 r5 : df2fd420 r4 : deb36b80
r3 : bf0d40d4 r2 : 00000000 r1 : deb6be64 r0 : 00000001
Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 0005397f Table: 1eb44000 DAC: 00000015
Process modprobe (pid: 2813, stack limit = 0xdeb6a270)
Stack: (0xdeb6be98 to 0xdeb6c000)
be80: deb27f00 000022cc
bea0: deb6be90 deb27f08 deb27f08 bf0d7190 bf0d7190 c02895dc 00000060 c028b630
bec0: c028b61c c028a5ec 00000000 deb27f08 deb27f3c bf0d7190 00000000 c028a704
bee0: bf0d7190 c028a6a4 00000000 c0289d94 df8240b8 deb18570 bf0d7190 deb18780
bf00: c058d5f0 c02896f0 bf0d714f bf0d714f deb6bf10 bf0d7190 00000001 00024418
bf20: 00000000 c002fbe4 00000000 c028a9d8 bf0d717c 00000001 00024418 00000000
bf40: c002fbe4 c028ba1c bf0d71c8 bf0da000 00024418 c002f42c 00000000 00000001
bf60: bf0d71c8 00000000 00024418 bf0d71c8 00000000 00024418 000014ed c002fbe4
bf80: 00000000 c0077ba0 400c3000 000014ed 00024418 00009064 00000000 00008edc
bfa0: 00000080 c002fa60 00009064 00000000 400c3000 000014ed 00024418 000014ed
bfc0: 00009064 00000000 00008edc 00000080 00000000 00000000 40102000 beca8984
bfe0: 00000000 beca88fc 0000b6b0 402af0c4 60000010 400c3000 ffffefff fffffcff
[<bf0da160>] (w1_gpio_probe+0x14c/0x194 [w1_gpio]) from [<c028b630>] (platform_drv_probe+0x14/0x18)
[<c028b630>] (platform_drv_probe+0x14/0x18) from [<c028a5ec>] (driver_probe_device+0xb0/0x168)
[<c028a5ec>] (driver_probe_device+0xb0/0x168) from [<c028a704>] (__driver_attach+0x60/0x84)
[<c028a704>] (__driver_attach+0x60/0x84) from [<c0289d94>] (bus_for_each_dev+0x48/0x74)
[<c0289d94>] (bus_for_each_dev+0x48/0x74) from [<c02896f0>] (bus_add_driver+0x144/0x2c0)
[<c02896f0>] (bus_add_driver+0x144/0x2c0) from [<c028a9d8>] (driver_register+0xa8/0x138)
[<c028a9d8>] (driver_register+0xa8/0x138) from [<c028ba1c>] (platform_driver_probe+0x18/0x98)
[<c028ba1c>] (platform_driver_probe+0x18/0x98) from [<c002f42c>] (do_one_initcall+0xcc/0x1a8)
[<c002f42c>] (do_one_initcall+0xcc/0x1a8) from [<c0077ba0>] (sys_init_module+0x90/0x1a4)
[<c0077ba0>] (sys_init_module+0x90/0x1a4) from [<c002fa60>] (ret_fast_syscall+0x0/0x2c)
Code: debcffc0 debcd0f0 deb4e120 00000000 (deb92ca0)
As I said, this doesn't mean a lot to me, and I'm not sure it's an ARM problem, but I don't have other hardware to test on.
Any help greatly appreciated.
^ permalink raw reply [flat|nested] 8+ messages in thread
* w1-gpio oops
2010-11-09 13:59 w1-gpio oops Alan Pearson
@ 2010-11-09 14:29 ` Hemanth V
2010-11-09 14:44 ` Alan Pearson
0 siblings, 1 reply; 8+ messages in thread
From: Hemanth V @ 2010-11-09 14:29 UTC (permalink / raw)
To: linux-arm-kernel
----- Original Message -----
From: "Alan Pearson" <alandpearson@gmail.com>
To: <linux-arm-kernel@lists.infradead.org>
Sent: Tuesday, November 09, 2010 7:29 PM
Subject: w1-gpio oops
> Hi Guys,
>
> First post to list, so be kind :)
>
> I'm trying to get w1 (one wire) working over GPIO and despite my best
> efforts this results in a nasty oops.
> Firstly, I'd like to say I'm no kernel hacker and my knowledge of Ooops
> and kernel debugging is limited, but I'm willing to learn:)
Common cause for these errors could be nonexistent or incorrect platform
data. Might be worth checking if w1_gpio_platform_data
is proper in your board file. You could look for examples in other board
files like arch/arm/mach-pxa/raumfeld.c
>
> I'm using Kernel.org kernel 2.6.36 (also tried 2.6.37-rc1) on a Marvell
> based 'GuruPlug server' device.
> I'm using the GPIO pins that are on the U-SNAP interface, namely MPP38.
>
> Having compiled and deployed the kernel to the device and verifying that I
> can control the GPIO pins OK from userspace using /sys, I then proceed to
> try and get w1 working on GPIO (after first unexporting the pin I want).
>
> There's sparse info on this, and most wisdom tells me to use the
> w1-gpio-custom module for openWRT to set the pin number before loading the
> module, which I've done.
>
> sheevaplug-debian:~# modprobe wire
> sheevaplug-debian:~# modprobe w1_gpio_custom bus0=0,38,0
> sheevaplug-debian:~# modprobe w1_gpio
> Internal error: Oops - undefined instruction: 0 [#1] PREEMPT
> last sysfs file: /sys/devices/virtual/mtd/mtd2/mtdblock2/range
> Modules linked in: w1_gpio(+) w1_gpio_custom wire xt_tcpudp iptable_filter
> ip_tables x_tables ipv6 libertas_sdio libertas sata_mv mv_c]
> CPU: 0 Not tainted (2.6.37-rc1 #3)
> PC is at 0xbf0d40d8
> LR is at w1_gpio_probe+0x14c/0x194 [w1_gpio]
> pc : [<bf0d40d8>] lr : [<bf0da160>] psr: a0000013
> sp : deb6be98 ip : 00000000 fp : beca8984
> r10: 00000040 r9 : deb6a000 r8 : bf0da040
> r7 : deb27f00 r6 : 00000000 r5 : df2fd420 r4 : deb36b80
> r3 : bf0d40d4 r2 : 00000000 r1 : deb6be64 r0 : 00000001
> Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
> Control: 0005397f Table: 1eb44000 DAC: 00000015
> Process modprobe (pid: 2813, stack limit = 0xdeb6a270)
> Stack: (0xdeb6be98 to 0xdeb6c000)
> be80: deb27f00
> 000022cc
> bea0: deb6be90 deb27f08 deb27f08 bf0d7190 bf0d7190 c02895dc 00000060
> c028b630
> bec0: c028b61c c028a5ec 00000000 deb27f08 deb27f3c bf0d7190 00000000
> c028a704
> bee0: bf0d7190 c028a6a4 00000000 c0289d94 df8240b8 deb18570 bf0d7190
> deb18780
> bf00: c058d5f0 c02896f0 bf0d714f bf0d714f deb6bf10 bf0d7190 00000001
> 00024418
> bf20: 00000000 c002fbe4 00000000 c028a9d8 bf0d717c 00000001 00024418
> 00000000
> bf40: c002fbe4 c028ba1c bf0d71c8 bf0da000 00024418 c002f42c 00000000
> 00000001
> bf60: bf0d71c8 00000000 00024418 bf0d71c8 00000000 00024418 000014ed
> c002fbe4
> bf80: 00000000 c0077ba0 400c3000 000014ed 00024418 00009064 00000000
> 00008edc
> bfa0: 00000080 c002fa60 00009064 00000000 400c3000 000014ed 00024418
> 000014ed
> bfc0: 00009064 00000000 00008edc 00000080 00000000 00000000 40102000
> beca8984
> bfe0: 00000000 beca88fc 0000b6b0 402af0c4 60000010 400c3000 ffffefff
> fffffcff
> [<bf0da160>] (w1_gpio_probe+0x14c/0x194 [w1_gpio]) from [<c028b630>]
> (platform_drv_probe+0x14/0x18)
> [<c028b630>] (platform_drv_probe+0x14/0x18) from [<c028a5ec>]
> (driver_probe_device+0xb0/0x168)
> [<c028a5ec>] (driver_probe_device+0xb0/0x168) from [<c028a704>]
> (__driver_attach+0x60/0x84)
> [<c028a704>] (__driver_attach+0x60/0x84) from [<c0289d94>]
> (bus_for_each_dev+0x48/0x74)
> [<c0289d94>] (bus_for_each_dev+0x48/0x74) from [<c02896f0>]
> (bus_add_driver+0x144/0x2c0)
> [<c02896f0>] (bus_add_driver+0x144/0x2c0) from [<c028a9d8>]
> (driver_register+0xa8/0x138)
> [<c028a9d8>] (driver_register+0xa8/0x138) from [<c028ba1c>]
> (platform_driver_probe+0x18/0x98)
> [<c028ba1c>] (platform_driver_probe+0x18/0x98) from [<c002f42c>]
> (do_one_initcall+0xcc/0x1a8)
> [<c002f42c>] (do_one_initcall+0xcc/0x1a8) from [<c0077ba0>]
> (sys_init_module+0x90/0x1a4)
> [<c0077ba0>] (sys_init_module+0x90/0x1a4) from [<c002fa60>]
> (ret_fast_syscall+0x0/0x2c)
> Code: debcffc0 debcd0f0 deb4e120 00000000 (deb92ca0)
>
>
> As I said, this doesn't mean a lot to me, and I'm not sure it's an ARM
> problem, but I don't have other hardware to test on.
>
>
> Any help greatly appreciated.
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* w1-gpio oops
2010-11-09 14:29 ` Hemanth V
@ 2010-11-09 14:44 ` Alan Pearson
2010-11-09 14:53 ` Hemanth V
0 siblings, 1 reply; 8+ messages in thread
From: Alan Pearson @ 2010-11-09 14:44 UTC (permalink / raw)
To: linux-arm-kernel
On 9 Nov 2010, at 14:29, Hemanth V wrote:
> ----- Original Message ----- From: "Alan Pearson" <alandpearson@gmail.com>
> To: <linux-arm-kernel@lists.infradead.org>
> Sent: Tuesday, November 09, 2010 7:29 PM
> Subject: w1-gpio oops
>
>
>> Hi Guys,
>>
>> First post to list, so be kind :)
>>
>> I'm trying to get w1 (one wire) working over GPIO and despite my best efforts this results in a nasty oops.
>> Firstly, I'd like to say I'm no kernel hacker and my knowledge of Ooops and kernel debugging is limited, but I'm willing to learn:)
>
> Common cause for these errors could be nonexistent or incorrect platform data. Might be worth checking if w1_gpio_platform_data
> is proper in your board file. You could look for examples in other board files like arch/arm/mach-pxa/raumfeld.c
>
<CHOP>
Ok, I had understood the platform data was being set in the w1_gpio_custom module by the loadable options.
Is this not the case, or does it also need defined in the board file, which I presume is guruplug_setup.c ?
It's currently not defined there. But as I said I expected the other module to do this, am I wrong ?
Thanks again,
Alan
^ permalink raw reply [flat|nested] 8+ messages in thread
* w1-gpio oops
2010-11-09 14:44 ` Alan Pearson
@ 2010-11-09 14:53 ` Hemanth V
2010-11-09 14:56 ` Alan Pearson
2010-11-09 15:40 ` Alan Pearson
0 siblings, 2 replies; 8+ messages in thread
From: Hemanth V @ 2010-11-09 14:53 UTC (permalink / raw)
To: linux-arm-kernel
----- Original Message -----
From: "Alan Pearson" <alandpearson@gmail.com>
To: "Hemanth V" <hemanthv@ti.com>
Cc: <linux-arm-kernel@lists.infradead.org>
Sent: Tuesday, November 09, 2010 8:14 PM
Subject: Re: w1-gpio oops
On 9 Nov 2010, at 14:29, Hemanth V wrote:
> ----- Original Message ----- From: "Alan Pearson" <alandpearson@gmail.com>
> To: <linux-arm-kernel@lists.infradead.org>
> Sent: Tuesday, November 09, 2010 7:29 PM
> Subject: w1-gpio oops
>
>
>> Hi Guys,
>>
>> First post to list, so be kind :)
>>
>> I'm trying to get w1 (one wire) working over GPIO and despite my best
>> efforts this results in a nasty oops.
>> Firstly, I'd like to say I'm no kernel hacker and my knowledge of Ooops
>> and kernel debugging is limited, but I'm willing to learn:)
>
> Common cause for these errors could be nonexistent or incorrect platform
> data. Might be worth checking if w1_gpio_platform_data
> is proper in your board file. You could look for examples in other board
> files like arch/arm/mach-pxa/raumfeld.c
>
<CHOP>
Ok, I had understood the platform data was being set in the w1_gpio_custom
module by the loadable options.
Is this not the case, or does it also need defined in the board file, which
I presume is guruplug_setup.c ?
It's currently not defined there. But as I said I expected the other module
to do this, am I wrong ?
Looking at the function w1_gpio_probe, it doesnot seem to be using module
params. So u might need to define those
in your board file.
^ permalink raw reply [flat|nested] 8+ messages in thread
* w1-gpio oops
2010-11-09 14:53 ` Hemanth V
@ 2010-11-09 14:56 ` Alan Pearson
2010-11-09 15:40 ` Alan Pearson
1 sibling, 0 replies; 8+ messages in thread
From: Alan Pearson @ 2010-11-09 14:56 UTC (permalink / raw)
To: linux-arm-kernel
>>
>
> <CHOP>
>
> Ok, I had understood the platform data was being set in the w1_gpio_custom module by the loadable options.
> Is this not the case, or does it also need defined in the board file, which I presume is guruplug_setup.c ?
> It's currently not defined there. But as I said I expected the other module to do this, am I wrong ?
>
>
> Looking at the function w1_gpio_probe, it doesnot seem to be using module params. So u might need to define those
> in your board file.
>
But the w1_gpio_custom module does. Anyhow, I'm trying it out in the board file now.
I'll post back shortly.
Tnx
Alan
^ permalink raw reply [flat|nested] 8+ messages in thread
* w1-gpio oops
2010-11-09 14:53 ` Hemanth V
2010-11-09 14:56 ` Alan Pearson
@ 2010-11-09 15:40 ` Alan Pearson
2010-11-09 15:51 ` Arnaud Patard (Rtp)
1 sibling, 1 reply; 8+ messages in thread
From: Alan Pearson @ 2010-11-09 15:40 UTC (permalink / raw)
To: linux-arm-kernel
>> ----- Original Message ----- From: "Alan Pearson" <alandpearson@gmail.com>
>> To: <linux-arm-kernel@lists.infradead.org>
>> Sent: Tuesday, November 09, 2010 7:29 PM
>> Subject: w1-gpio oops
>>
>>
>>> Hi Guys,
>>>
>>> First post to list, so be kind :)
>>>
>>> I'm trying to get w1 (one wire) working over GPIO and despite my best efforts this results in a nasty oops.
>>> Firstly, I'd like to say I'm no kernel hacker and my knowledge of Ooops and kernel debugging is limited, but I'm willing to learn:)
>>
>> Common cause for these errors could be nonexistent or incorrect platform data. Might be worth checking if w1_gpio_platform_data
>> is proper in your board file. You could look for examples in other board files like arch/arm/mach-pxa/raumfeld.c
>>
>
> <CHOP>
>
> Ok, I had understood the platform data was being set in the w1_gpio_custom module by the loadable options.
> Is this not the case, or does it also need defined in the board file, which I presume is guruplug_setup.c ?
> It's currently not defined there. But as I said I expected the other module to do this, am I wrong ?
>
>
> Looking at the function w1_gpio_probe, it doesnot seem to be using module params. So u might need to define those
> in your board file.
>
OK, I've modified my board file like so (guruplug-setup.c) :
static struct w1_gpio_platform_data guru_gpio_platform_data = {
.pin = MPP38_GPIO,
.is_open_drain = 0,
};
struct platform_device guru_w1_gpio_device = {
.name = "w1-gpio",
.id = -1,
.dev = {
.platform_data = &guru_gpio_platform_data
}
};
static void __init guru_w1_init(void)
{
platform_device_register(&guru_w1_gpio_device);
}
and called guru_w1_init from it's main init function.
Loading w1-gpio without the custom module produces :
FATAL: Error inserting w1_gpio (/lib/modules/2.6.37-rc1/kernel/drivers/w1/masters/w1-gpio.ko): No such device
And loading the w1_gpio_custom with the correct parameters produces the same oops.
So I think somehow I haven't correctly defined the platform data in my board file, and the w1_gpio_custom module allows me to specify this with parameters.
You can see w1-gpio-custom here : https://dev.openwrt.org/browser/branches/8.09/package/w1-gpio-custom/src/w1-gpio-custom.c
So any clues as to what I've done wrong with the platform data, or does it not matter as w1-gpio-custom is doing this for me ?
Again,
Thanks
Alan
^ permalink raw reply [flat|nested] 8+ messages in thread
* w1-gpio oops
2010-11-09 15:40 ` Alan Pearson
@ 2010-11-09 15:51 ` Arnaud Patard (Rtp)
2010-11-09 16:52 ` Alan Pearson
0 siblings, 1 reply; 8+ messages in thread
From: Arnaud Patard (Rtp) @ 2010-11-09 15:51 UTC (permalink / raw)
To: linux-arm-kernel
Alan Pearson <alandpearson@gmail.com> writes:
Hi,
>>> ----- Original Message ----- From: "Alan Pearson" <alandpearson@gmail.com>
>>> To: <linux-arm-kernel@lists.infradead.org>
>>> Sent: Tuesday, November 09, 2010 7:29 PM
>>> Subject: w1-gpio oops
>>>
>>>
>>>> Hi Guys,
>>>>
>>>> First post to list, so be kind :)
>>>>
>>>> I'm trying to get w1 (one wire) working over GPIO and despite my best efforts this results in a nasty oops.
>>>> Firstly, I'd like to say I'm no kernel hacker and my knowledge of Ooops and kernel debugging is limited, but I'm willing to learn:)
>>>
>>> Common cause for these errors could be nonexistent or incorrect platform data. Might be worth checking if w1_gpio_platform_data
>>> is proper in your board file. You could look for examples in other board files like arch/arm/mach-pxa/raumfeld.c
>>>
>>
>> <CHOP>
>>
>> Ok, I had understood the platform data was being set in the w1_gpio_custom module by the loadable options.
>> Is this not the case, or does it also need defined in the board file, which I presume is guruplug_setup.c ?
>> It's currently not defined there. But as I said I expected the other module to do this, am I wrong ?
>>
>>
>> Looking at the function w1_gpio_probe, it doesnot seem to be using module params. So u might need to define those
>> in your board file.
>>
>
> OK, I've modified my board file like so (guruplug-setup.c) :
>
>
> static struct w1_gpio_platform_data guru_gpio_platform_data = {
> .pin = MPP38_GPIO,
It's 38 not MPP38_GPIO. MPP38_GPIO is for the guruplug_mpp_config[]
stuff (looks at how the leds are configured for instance)
Arnaud
^ permalink raw reply [flat|nested] 8+ messages in thread
* w1-gpio oops
2010-11-09 15:51 ` Arnaud Patard (Rtp)
@ 2010-11-09 16:52 ` Alan Pearson
0 siblings, 0 replies; 8+ messages in thread
From: Alan Pearson @ 2010-11-09 16:52 UTC (permalink / raw)
To: linux-arm-kernel
>>> P. So u might need to define those
>>> in your board file.
>>>
>>
>> OK, I've modified my board file like so (guruplug-setup.c) :
>>
>>
>> static struct w1_gpio_platform_data guru_gpio_platform_data = {
>> .pin = MPP38_GPIO,
>
> It's 38 not MPP38_GPIO. MPP38_GPIO is for the guruplug_mpp_config[]
> stuff (looks at how the leds are configured for instance)
>
>
> Arnaud
>
>
Guys, thanks. I've now got the module loading and utilising the GPIO pin.
I know it is, because I cannot now grab the GPIO pin for normal GPIO as the w1_gpio driver has claimed ownership.
I can't get it to see my device yet, but I'll get that figured out soon I hope.
Many thanks for all your help, it is really appreciated here.
Alan
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2010-11-09 16:52 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-11-09 13:59 w1-gpio oops Alan Pearson
2010-11-09 14:29 ` Hemanth V
2010-11-09 14:44 ` Alan Pearson
2010-11-09 14:53 ` Hemanth V
2010-11-09 14:56 ` Alan Pearson
2010-11-09 15:40 ` Alan Pearson
2010-11-09 15:51 ` Arnaud Patard (Rtp)
2010-11-09 16:52 ` Alan Pearson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).