|
Prem Mallappa(deleted)
11/16/2007 2:09 PM
post2707
|
Hi,
I am trying to get my Nvidia NForce3 chipset's ethernet controller working. From NetBSD source it is confirmed that nfe
is the driver I am looking for.
I downloaded
if_nfe.c
if_nfereg.h
if_nfevar.h
(Also I downloaded the core_networking/trunk and built successfully, currently my QCONF_OVERRIDE is configured for the
newly built directory)
followed the guidelines to build bge driver and changed my nfe driver accordingly. After a bit of fight I finally able
to get the nfe driver compiling.
After that i did
slay io-net
io-pkt-v4-hc -dnfe
This command just loads without errors. when i look at 'sloginfo' I can see the printf i have put in nfe/init.c printing
but the pci_qnx_scan is returning no such device or address. What could be the problem.
How to debug the io-pkt* with my driver?
(On Linux I am using forcedeth driver)
|
|
|
|
|
|
Robert Craig
11/16/2007 2:19 PM
post2708
|
As a complete shot in the dark, are you sure that the PCI Vendor and Device
ID are in the list of IDs supported by the driver? You can get the card IDs
using the "pci" command.
-----Original Message-----
From: Prem Mallappa [mailto:prem.mallappa@gmail.com]
Sent: Friday, November 16, 2007 2:09 PM
To: drivers-networking
Subject: nfe driver
Hi,
I am trying to get my Nvidia NForce3 chipset's ethernet controller working.
From NetBSD source it is confirmed that nfe is the driver I am looking for.
I downloaded
if_nfe.c
if_nfereg.h
if_nfevar.h
(Also I downloaded the core_networking/trunk and built successfully,
currently my QCONF_OVERRIDE is configured for the newly built directory)
followed the guidelines to build bge driver and changed my nfe driver
accordingly. After a bit of fight I finally able to get the nfe driver
compiling.
After that i did
slay io-net
io-pkt-v4-hc -dnfe
This command just loads without errors. when i look at 'sloginfo' I can see
the printf i have put in nfe/init.c printing but the pci_qnx_scan is
returning no such device or address. What could be the problem.
How to debug the io-pkt* with my driver?
(On Linux I am using forcedeth driver)
_______________________________________________
Drivers
http://community.qnx.com/sf/go/post2707
|
|
|
|
|
|
Prem Mallappa(deleted)
11/16/2007 10:19 PM
post2726
|
Yes, infact my card id is 0x00df (which is in the pcidevs.h) and is supported by the driver
---------pcidevs.h-------------------
#define PCI_PRODUCT_NVIDIA_NFORCE3_LAN4 0x00df
--------driver------------
const struct nfe_product {
pci_vendor_id_t vendor;
pci_product_id_t product;
} nfe_devices[] = {
{ PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_NFORCE3_LAN4 },
...
};
and pci -vv command lists my network card and I can see the device id 0xdf
|
|
|
|
|
|
Sean Boudreau(deleted)
11/16/2007 2:24 PM
post2709
|
On Fri, Nov 16, 2007 at 02:09:12PM -0500, Prem Mallappa wrote:
> Hi,
> I am trying to get my Nvidia NForce3 chipset's ethernet controller
> working. From NetBSD source it is confirmed that nfe is the driver I am
> looking for.
> I downloaded
> if_nfe.c
> if_nfereg.h
> if_nfevar.h
>
> (Also I downloaded the core_networking/trunk and built successfully,
> currently my QCONF_OVERRIDE is configured for the newly built directory)
> followed the guidelines to build bge driver and changed my nfe driver
> accordingly. After a bit of fight I finally able to get the nfe driver
> compiling.
> After that i did
> slay io-net
> io-pkt-v4-hc -dnfe
>
> This command just loads without errors. when i look at 'sloginfo' I can
> see the printf i have put in nfe/init.c printing but the pci_qnx_scan is
> returning no such device or address. What could be the problem.
If there's nothing else in the sloginfo it's hard to tell
as that's the generic error when the driver initialization
fails. The next step is to fire up the debugger to see
where it's going off the rails.
>
> How to debug the io-pkt* with my driver?
Good old gdb. Compile the sys directory as follows
and run the stack in the debugger stepping through
your initialization:
# cd sys
# make CPULIST=x86 clean
# make CPULIST=x86 CCOPTS=-O0 DEBUG=-g install
-seanb
|
|
|
|
|
|
Prem Mallappa(deleted)
11/16/2007 10:14 PM
post2725
|
> > How to debug the io-pkt* with my driver?
>
> Good old gdb. Compile the sys directory as follows
> and run the stack in the debugger stepping through
> your initialization:
> # cd sys
> # make CPULIST=x86 clean
> # make CPULIST=x86 CCOPTS=-O0 DEBUG=-g install
I just wanted to debug the pci_qnx_scan, however this function is not available until the io-pkt-v4-hc loads the .so
image.
I'll try agian
|
|
|
|
|
|
Robert Craig
11/16/2007 10:44 PM
post2727
|
|
|
|
|
|
|
Prem Mallappa(deleted)
11/17/2007 6:41 AM
post2730
|
Hi Robert,
Thanks for the pointer.
Here is a gdb session with io-pkt-v4-hc
-------------------------------------------------------
# set | grep LD
LD_LIBRARY_PATH=/home/prem/corenet/stage-new/x86/lib:/home/prem/corenet/stage-new/x86/lib/dll:
OLDPWD=/home/prem
# gdb io-pkt-v4-hc (this is in $PATH)
GNU gdb 6.7
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-pc-nto-qnx6.3.0"...
(gdb) break main
Breakpoint 1 at 0x80f9414: file /home/prem/corenet/net/sys/main.c, line 144.
(gdb) break pci_qnx_scan
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (pci_qnx_scan) pending.
(gdb) r -dnfe
Starting program: /home/prem/corenet/stage-new/x86/sbin/io-pkt-v4-hc -dnfe
Setting Dynamic-Linker Breakpoint based on /usr/qnx632/target/qnx6/x86/usr/lib/ldqnx.so.2
Setting Dynamic-Linker Breakpoint based on /usr/qnx632/target/qnx6/x86/usr/lib/ldqnx.so.2
Breakpoint 1, main (argc=2, argv=0x8047af4) at /home/prem/corenet/net/sys/main.c:144
144 rcv_loop_args.sigev_type = SIGEV_PULSE;
(gdb) p argv
$1 = (char **) 0x8047af4
(gdb) p argv[1]
$2 = 0x8047bd5 "-dnfe"
(gdb) c
Continuing.
[tcsetpgrp failed in terminal_inferior: Operation not permitted]
Error while mapping shared library sections:
devnp-nfe.so: No such file or directory.
------------------------------------------------
devnp-nfe.so is in LD_LIBRARY_PATH but I still don't understand what is happening
|
|
|
|
|
|
Sean Boudreau(deleted)
11/17/2007 8:54 AM
post2732
|
On Sat, Nov 17, 2007 at 06:41:34AM -0500, Prem Mallappa wrote:
> Hi Robert,
> Thanks for the pointer.
>
>
> Here is a gdb session with io-pkt-v4-hc
> -------------------------------------------------------
> # set | grep LD
> LD_LIBRARY_PATH=/home/prem/corenet/stage-new/x86/lib:/home/prem/corenet/
> stage-new/x86/lib/dll:
> OLDPWD=/home/prem
>
> # gdb io-pkt-v4-hc (this is in $PATH)
> GNU gdb 6.7
> Copyright (C) 2007 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>;
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show
> copying"
> and "show warranty" for details.
> This GDB was configured as "i386-pc-nto-qnx6.3.0"...
> (gdb) break main
> Breakpoint 1 at 0x80f9414: file /home/prem/corenet/net/sys/main.c, line
> 144.
> (gdb) break pci_qnx_scan
> Make breakpoint pending on future shared library load? (y or [n]) y
> Breakpoint 2 (pci_qnx_scan) pending.
> (gdb) r -dnfe
> Starting program: /home/prem/corenet/stage-new/x86/sbin/io-pkt-v4-hc
> -dnfe
> Setting Dynamic-Linker Breakpoint based on
> /usr/qnx632/target/qnx6/x86/usr/lib/ldqnx.so.2
> Setting Dynamic-Linker Breakpoint based on
> /usr/qnx632/target/qnx6/x86/usr/lib/ldqnx.so.2
>
> Breakpoint 1, main (argc=2, argv=0x8047af4) at
> /home/prem/corenet/net/sys/main.c:144
> 144 rcv_loop_args.sigev_type = SIGEV_PULSE;
> (gdb) p argv
> $1 = (char **) 0x8047af4
> (gdb) p argv[1]
> $2 = 0x8047bd5 "-dnfe"
> (gdb) c
> Continuing.
> [tcsetpgrp failed in terminal_inferior: Operation not permitted]
> Error while mapping shared library sections:
> devnp-nfe.so: No such file or directory.
> ------------------------------------------------
> devnp-nfe.so is in LD_LIBRARY_PATH but I still don't understand what is
> happening
After hitting the breakpoint in main(), do a 'sharedlibrary'
command in gdb. You should see libc loaded in. Set a
breakpoint in dlsym(). When that's hit your driver should
be loaded in but io-pkt hasn't done the first callout into
it. Do a 'set solib-search-path' and add the path to your
driver and then do a 'sharedlibrary' again. The syms for
your driver should now load and you should be able to set a
breakpoint in pci_qnx_scan().
-seanb
|
|
|
|
|
|
Prem Mallappa(deleted)
11/18/2007 7:56 AM
post2735
|
Thanks that made the trick.
I could successfully debug the pci_qnx_scan part,
The problem was due to the following line in driver
return pci_qnx_scan(dll_hdl, ___STRING(DRVR), options, ca,
PCI_CLASS_NETWORK | PCI_SUBCLASS_NETWORK_ETHERNET);
This searches for NETWORK class drivers (the value defaults for this is 0x2000), but pci -vv command showed me that the
driver's class is 0x68000, using this value I am able to successfully get out of attach function. some more work needs
to be done inorder to get it working..
(I love qnx, debugging drivers was never so easy for me, on the other OS's)
/Prem
|
|
|
|
|
|
Xiaodan Tang(deleted)
11/18/2007 11:04 AM
post2736
|
> (I love qnx, debugging drivers was never so easy for me, on the other OS's)
Welcome to the world of Micro-Kernel :)
|
|
|
|
|
|
Xiaodan Tang(deleted)
11/21/2007 8:54 PM
post2840
|
Prem, just wondering how is the porting going? Do you still have some road block?
|
|
|
|
|
|
Prem Mallappa(deleted)
12/04/2007 11:10 PM
post3342
|
Hi,
sorry for the late response, i didn't get much time to investigate on this, as my build process stops every now and then
( make issues a gcc command and gcc stops for ever) I need to logout and login to build it, which again works for a
while
-----------source from netbsd tree-----------------
213 switch (memtype) {
214 case PCI_MAPREG_TYPE_MEM | PCI_MAPREG_MEM_TYPE_32BIT:
215 case PCI_MAPREG_TYPE_MEM | PCI_MAPREG_MEM_TYPE_64BIT:
216 if (pci_mapreg_map(pa, NFE_PCI_BA, memtype, 0, &sc->sc_memt,
217 &sc->sc_memh, NULL, &memsize) == 0)
218 break;
219 /* FALLTHROUGH */
220 default:
221 printf("%s: could not map mem space\n", sc->sc_dev.dv_xname);
222 return;
223 }
--------------------------------------
The driver fails to map the registers. I am not very familiar with x86 bus architectures, I am making changes with blind
guesses and quick search results.
time consuming issue is my working way
1. build
(if it stops here logout and login)
2. slay io-pkt-v4
3. io-pkt-v4 -d nfe
(some errors printed from driver )
4. edit driver source
5. goto step 1.
cool isnt' it? :(
|
|
|
|
|
|
Xiaodan Tang(deleted)
12/05/2007 2:21 PM
post3403
|
> Hi,
> sorry for the late response, i didn't get much time to investigate on this, as
> my build process stops every now and then ( make issues a gcc command and gcc
> stops for ever) I need to logout and login to build it, which again works for
> a while
I *think* I have seen this before. When you think gcc is "stopped", check "pidin" to see if there is a thread running "
READY" all the time. In the pass, there are some program would running READY on priority 10, which causing the compiler
(which is running at priority 9) stopped.
The one I remember is "XPhoton" process, but maybe it's different in your system.
> -----------source from netbsd tree-----------------
> 213 switch (memtype) {
> 214 case PCI_MAPREG_TYPE_MEM | PCI_MAPREG_MEM_TYPE_32BIT:
> 215 case PCI_MAPREG_TYPE_MEM | PCI_MAPREG_MEM_TYPE_64BIT:
> 216 if (pci_mapreg_map(pa, NFE_PCI_BA, memtype, 0, &sc->sc_memt,
> 217 &sc->sc_memh, NULL, &memsize) == 0)
> 218 break;
> 219 /* FALLTHROUGH */
> 220 default:
> 221 printf("%s: could not map mem space\n", sc->sc_dev.
> dv_xname);
> 222 return;
> 223 }
> --------------------------------------
> The driver fails to map the registers. I am not very familiar with x86 bus
> architectures, I am making changes with blind guesses and quick search results
> .
> time consuming issue is my working way
> 1. build
> (if it stops here logout and login)
> 2. slay io-pkt-v4
> 3. io-pkt-v4 -d nfe
> (some errors printed from driver )
> 4. edit driver source
> 5. goto step 1.
>
> cool isnt' it? :(
You are still unable to gdb and step through the code?
|
|
|
|
|
|
