Sorry if this is the wrong place to post this question. I'm developing a
NAND flash driver and I need to do some detailed dubugging using GDB with
a BDI2K. According to the Denx web site, to find out the address that the
module is loading at you load it using the -m parameter to insmod (i.e.,
"insmod -m mymodule"). However, every version of insmod I've tried
doesn't recognize ANY options much less -m. Can anyone please point me in
the right direction, or give me another way of knowing what the load
address of my module is?
Thanks.
Bruce
From: Magnus Hjorth <hidden> Date: 2008-02-16 04:57:38
'cat /proc/modules' perhaps?
//Magnus
On Fri, 2008-02-15 at 17:06 -0800, Bruce_Leonard@selinc.com wrote:
Sorry if this is the wrong place to post this question. I'm developing a
NAND flash driver and I need to do some detailed dubugging using GDB with
a BDI2K. According to the Denx web site, to find out the address that the
module is loading at you load it using the -m parameter to insmod (i.e.,
"insmod -m mymodule"). However, every version of insmod I've tried
doesn't recognize ANY options much less -m. Can anyone please point me in
the right direction, or give me another way of knowing what the load
address of my module is?
Thanks.
Bruce
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
I tried that, but it gives me an odd address (at least I think it's an odd
address): 0xE1188000. I use that address in GDB for adding the symbol
table (i.e., add-symbol-file mymodule 0xE1188000), but then the BDI
reports "*** MMU: address translation for 0xE118822C failed" when I try to
set a breakpoint in the probe function. Admittedly I'm new to driver
writing, but shouldn't the address be somewhere in the 0xC0xxxxxx range?
//Magnus
On Fri, 2008-02-15 at 17:06 -0800, Bruce_Leonard@selinc.com wrote:
quoted
Sorry if this is the wrong place to post this question. I'm
developing a
quoted
NAND flash driver and I need to do some detailed dubugging using GDB
with
quoted
a BDI2K. According to the Denx web site, to find out the address that
the
quoted
module is loading at you load it using the -m parameter to insmod
(i.e.,
quoted
"insmod -m mymodule"). However, every version of insmod I've tried
doesn't recognize ANY options much less -m. Can anyone please point
me in
quoted
the right direction, or give me another way of knowing what the load
address of my module is?
Thanks.
Bruce
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
From: Magnus Hjorth <hidden> Date: 2008-02-17 12:04:36
On Sun, 2008-02-17 at 00:03 -0800, Bruce_Leonard@selinc.com wrote:
quoted
'cat /proc/modules' perhaps?
I tried that, but it gives me an odd address (at least I think it's an odd
address): 0xE1188000. I use that address in GDB for adding the symbol
table (i.e., add-symbol-file mymodule 0xE1188000), but then the BDI
reports "*** MMU: address translation for 0xE118822C failed" when I try to
set a breakpoint in the probe function. Admittedly I'm new to driver
writing, but shouldn't the address be somewhere in the 0xC0xxxxxx range?
I believe the modules live in the kernel's dynamically allocated memory
area in the 0xExxxxxxx range..
Can you set breakpoints anywhere in the kernel? Try picking a function address from System.map and set a breakpoint there.
I have little experience with what you're doing, but my guess is that you're setting the breakpoint in the wrong context, probably standing in userspace..
quoted
//Magnus
On Fri, 2008-02-15 at 17:06 -0800, Bruce_Leonard@selinc.com wrote:
quoted
Sorry if this is the wrong place to post this question. I'm
developing a
quoted
quoted
NAND flash driver and I need to do some detailed dubugging using GDB
with
quoted
quoted
a BDI2K. According to the Denx web site, to find out the address that
the
quoted
quoted
module is loading at you load it using the -m parameter to insmod
(i.e.,
quoted
quoted
"insmod -m mymodule"). However, every version of insmod I've tried
doesn't recognize ANY options much less -m. Can anyone please point
me in
quoted
quoted
the right direction, or give me another way of knowing what the load
address of my module is?
Thanks.
Bruce
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
From: Wolfgang Grandegger <hidden> Date: 2008-02-17 12:28:17
Bruce_Leonard@selinc.com wrote:
Sorry if this is the wrong place to post this question. I'm developing a
NAND flash driver and I need to do some detailed dubugging using GDB with
a BDI2K. According to the Denx web site, to find out the address that the
module is loading at you load it using the -m parameter to insmod (i.e.,
"insmod -m mymodule"). However, every version of insmod I've tried
doesn't recognize ANY options much less -m. Can anyone please point me in
the right direction, or give me another way of knowing what the load
address of my module is?
# cat /sys/module/<name>/sections/.text
Do not forget to enable CONFIG_KALLSYMS.
Wolfgang.
Sorry if this is the wrong place to post this question. I'm
developing a
quoted
NAND flash driver and I need to do some detailed dubugging using GDB
with
quoted
a BDI2K. According to the Denx web site, to find out the address that
the
quoted
module is loading at you load it using the -m parameter to insmod
(i.e.,
quoted
"insmod -m mymodule"). However, every version of insmod I've tried
doesn't recognize ANY options much less -m. Can anyone please point
me in
quoted
the right direction, or give me another way of knowing what the load
address of my module is?
# cat /sys/module/<name>/sections/.text
Do not forget to enable CONFIG_KALLSYMS.
Well, okay I guess the address I'm getting is the right one because both
the above cat and 'cat /proc/modules' gives me the same thing, 0xe1188000.
I've got CONFIG_KALLSYMS and CONFIG_KALLSYMS_ALL set, though
CONFIG_KALLSYMS_EXTRA_PASS is not set, don't know if that makes a
difference.
So it would seem that there's something wrong with my BDI setup that isn't
allowing address translation in the kernel's dynamically allocated memory
area. I've got PTBASE set to 0xf0 in the BDI config file so it should be
finding the virtual address of the page tables just fine. I've also got
CONFIG_BDI_SWITCH set in .config and I know that works with the BDI,
because I can set breakpoints at places in the kernel code that are called
by my module (like nand_scan_ident() ) and everything works just fine.
It's just when I try to access memory in the dynamic area where my module
is located that the BDI can't do an address translation. At least I
assume it's the BDI, because I can load the module and use it with out
GDB/BDI, so the processor and kernel must be able to handle the addresses
okay. Can anyone think of where I should go dig? I've had this working
exactly once in the past, but I don't know what I've changed to cause it
to stop working.
Thanks.
Bruce
From: Wolfgang Grandegger <hidden> Date: 2008-02-20 14:04:55
Bruce_Leonard@selinc.com wrote:
quoted
Bruce_Leonard@selinc.com wrote:
quoted
Sorry if this is the wrong place to post this question. I'm
developing a
quoted
quoted
NAND flash driver and I need to do some detailed dubugging using GDB
with
quoted
quoted
a BDI2K. According to the Denx web site, to find out the address that
the
quoted
quoted
module is loading at you load it using the -m parameter to insmod
(i.e.,
quoted
quoted
"insmod -m mymodule"). However, every version of insmod I've tried
doesn't recognize ANY options much less -m. Can anyone please point
me in
quoted
quoted
the right direction, or give me another way of knowing what the load
address of my module is?
# cat /sys/module/<name>/sections/.text
Do not forget to enable CONFIG_KALLSYMS.
Well, okay I guess the address I'm getting is the right one because both
the above cat and 'cat /proc/modules' gives me the same thing, 0xe1188000.
I've got CONFIG_KALLSYMS and CONFIG_KALLSYMS_ALL set, though
CONFIG_KALLSYMS_EXTRA_PASS is not set, don't know if that makes a
difference.
So it would seem that there's something wrong with my BDI setup that isn't
allowing address translation in the kernel's dynamically allocated memory
area. I've got PTBASE set to 0xf0 in the BDI config file so it should be
finding the virtual address of the page tables just fine. I've also got
CONFIG_BDI_SWITCH set in .config and I know that works with the BDI,
because I can set breakpoints at places in the kernel code that are called
by my module (like nand_scan_ident() ) and everything works just fine.
It's just when I try to access memory in the dynamic area where my module
is located that the BDI can't do an address translation. At least I
assume it's the BDI, because I can load the module and use it with out
GDB/BDI, so the processor and kernel must be able to handle the addresses
okay. Can anyone think of where I should go dig? I've had this working
exactly once in the past, but I don't know what I've changed to cause it
to stop working.
Try to specify the addresses of the other sections listed by "cat
/sys/module/my-mod/sections/:
add-symbol-file my-mod.o 0xcf030060\
-s .rodata 0xcf030354\
-s .data 0xcf030488\
-s .sdata 0xcf030488\
-s .bss 0xcf030519\
-s .sbss 0xcf03051c
Wolfgang.
Try to specify the addresses of the other sections listed by "cat
/sys/module/my-mod/sections/:
add-symbol-file my-mod.o 0xcf030060\
-s .rodata 0xcf030354\
-s .data 0xcf030488\
-s .sdata 0xcf030488\
-s .bss 0xcf030519\
-s .sbss 0xcf03051c
Wolfgang.
Thanks to all for the help. What I've finally figured out is this: even
though I know in advance what address my module is going to be loaded at,
until the module is actually loaded the memory "doesn't exist", i.e.,
there's no entry in the page tables. So I set the breakpoint at an
address that doesn't have a translation and when I tell GDB to go it tries
to access that memory, which doesn't exist, so I get the MMU error. So
I've figured out the problem is, but I'm not sure of the solution. I
think if I tell the BDI to use HW breakpoints rather than SW breakpoints
it will probably work.
Again, thanks for all the suggestions, especially about how to get the -m
option working for insmod.
Bruce