Frustrated question with insmod

Frustrated question with insmod

[Bruce_Leonard]

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

Re: Frustrated question with insmod

[Magnus Hjorth]

'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

Re: Frustrated question with insmod

[Bruce_Leonard]

> 
> '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?

> 
> //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
> 

Re: Frustrated question with insmod

[Magnus Hjorth]

On Sun, 2008-02-17 at 00:03 -0800, Bruce_Leonard@selinc.com wrote:
> > 
> > '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..

> 
> > 
> > //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
> > 

Re: Frustrated question with insmod

[Wolfgang Grandegger]

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.

Re: Frustrated question with insmod

[Bruce_Leonard]

> 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.
> 

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

Re: Frustrated question with insmod

[Wolfgang Grandegger]

Bruce_Leonard@selinc.com wrote:
>> 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.
>>
> 
> 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.

Re: Frustrated question with insmod

[Bruce_Leonard]

> 
> 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

RE: Frustrated question with insmod

[Sugathan, Rupesh]

> Bruce_Leonard@selinc.com wrote:
> > Sorry if this is the wrong place to post this question.  I'm
developing a=20
> > NAND flash driver and I need to do some detailed dubugging using GDB
with=20
> > a BDI2K.  According to the Denx web site, to find out the address=20
> > that
the=20
> > module is loading at you load it using the -m parameter to insmod
(i.e.,=20
> > "insmod -m mymodule").  However, every version of insmod I've tried=20
> > doesn't recognize ANY options much less -m.  Can anyone please point
me in=20
> > the right direction, or give me another way of knowing what the load

> > address of my module is?
>=20
> # cat /sys/module/<name>/sections/.text
>=20
> Do not forget to enable CONFIG_KALLSYMS.

Although this may not solve your problem, I once had to build insmod
with CONFIG_FEATURE_INSMOD_LOAD_MAP (this is not enabled by default)
option in its configuration to enable the -m option.

Thanks
..
Rupesh Sugathan