Help with hme Ethernet Driver

Question

Hello, I have the Solaris 7 source code (both for sparc and intel). My goal is to alter the hme ethernet driver to do something specific (why i ordered the source code). However, I'm running into a couple of problems. My first test was to just try and compile the source and insert the newly compiled driver to see if it will work (this is half the battle). I am wondering if I can do it with gcc, though. I don't have Sun's Forte cc compiler. Do you know if it's absolutely necessary to have cc to compile something like an ethernet driver for solaris? I have an Ultra-II sparcv9 (ultra 10 workstation) - which is what I am working with now. My first steps were as follows:
Got hme.c from the cd. Checked the header #includes in the file, and everything was fine.
Compiled as follows:
gcc -D_KERNEL -c hme.c
ld -r hme.o -o hme
This worked ok, except for a couple of function re-definition warnings.
Next thing I did was:
$ ifconfig hme0 unplumb
$ rem_drv hme
By default, the ultra 10 boots into 64-bit kernel mode, and i know the 64-bit kernel drivers are stored in /kernel/drv/sparcv9 and the 32-bit drivers are one dir up. So, I made a backup copy of /kernel/drv/sparcv9/hme to /kernel/drv/sparcv9/hme.BACKUP and then copied my fresh new binary into that directory:
$ cp /kernel/drv/sparcv9/hme /kernel/drv/sparcv9/hme.BACKUP
$ cp /home/dford/hme /kernel/drv/sparcv9/hme
Next :
$ add_drv hme
Here I get the message that the hme driver was loaded but failed to attach. I have seen this before when I did a loopback STREAMS driver, and the problem then was that the driver was compiled as a 32-bit driver, and I was in 64-bit mode. This was fixed by going to the boot prompt and typing:
ok> boot /platform/sun4u/kernel/unix
This boots the OS in 32-bit mode, and that fixed the problem with my Loopback STREAMS driver. However, I tried this with the hme driver I just built and it did not work. I get the same 'failed to attach' error, even after I copy the hme to /kernel/drv (make a backup of original first, though).
Now, I notice that I am missing the character special file that is supposed to exist in the /devices/pseudo directory for the hme driver. I can make one with mknod, but isn't it suppose to do this automatically? Incidentally, my problems get worse: trying to restore the original hme binary and run add_drv produces the same problem (failed to attach). Now I can't restore the system to it's initial working state. The only thing I did was make a backup copy of the hme binary, and after trying a newly compiled hme binary, restore the original hme binary. Rebooting the system - complains that it can't "find" the hme module! After the system comes up, modinfo indeed shows that hme did not load properly.
$ modload hme
-- reports that it can't find the hme module
$ modload /kernel/drv/sparcv9/hme
--works ok, now modinfo shows hme is loaded ok.  however, add_drv hme still reports failed to attach.
I don't know how the system's module load path got messed up. As i understand it, this is stored in /etc/system file. I never touched this file.
If you have any experience / ideas with this sort of thing, please let me know your opinions.
Thanks in advance,
Davis

Answer 1

Probelm Solved! The problem has to do with the fact that the kernel looks for a device with the same name as its driver module. In this case the driver module is 'hme', but the device name that is programmed into the card's FCode PROM is called SUNW,hme. Therefore add_drv would always fail. Therefore, to successfully load it, you have to alias the FCode PROM name as follows:
add_drv -m '* 0666 root root' -i 'SUNW,hme' hme
Hope this helps someone else in the future. This wasn't very clear, and took some digging to find out. In addition, the verbose option of add_drv should be changed to give more feedback, other than 'driver failed to attach'.
Incidentally, I found this info at:
http://soldc.sun.com/developer/support/driver/wps/pci/html/Device_Prop.doc.html
One note - they use quotation marks in their example, but add_drv needs apostrophe...trivial, but nonetheless, thought I would point it out.
davis