Conference turris::digital_unix

Ooops - sorry, I somehow missed this. 

No, my .2 was not correct and it does not work as I showed. 

Thanks Mark for correcting and clarifying my note. I knew I 
should have waited for you or Karl to reply! ;-)

Anyway, I started to reply with a VMEbus example and changed
horses in the middle of the stream (to PCI) - getting all wet! 

This gives me a good opportunity to plug the new VMEbus example
driver that Bruce Hansen (Realtime Engineering) & I developed 
for 4.0B. (Bruce and others ? did most of the work and testing!). 
Maybe I'll post a seperate note since the example somehow got 
left off of the 4.0B distribution. It should be on 4.0C, I think.  

Of course, the edpseudo is a fairly good pseudo-driver example.

The VMEbus example driver has been updated to support dynamic as 
well as static loading and it uses the single binary module model. 
It's the same driver that's in the "Writing VMEbus Device Drivers" 
manual starting w/ 4.0B.  

If you know someone who needs it, please let us know. I do not 
recommend using the lh100 example anymore since it has not been
updated for at least 2 years! 

Using the new dmaex example, the steps required to build a single 
binary module and load it, statically and dynamically, are listed 
below. 

dmaex:
	Subsystem_Description =DMAEX device driver
	Module_Config_Name = dmaex
	Device_Char_Major = Any
	Device_Char_Minor = 0
	Device_Char_Files = dmaex0
	Device_Major_Req = Same
	CMA_Option = Size - 0x20000, Alignment - 0x10000, Addrlimit - 0, Type - 0x1D, Flag - 2
        VBA_Option = Manufact_Name - 'Digital', Product_Name - 'DMAEX Driver', Bus_Instance - 0, Driver_Name - dmaex, Driver_Instance - 0, Csr1 - 0x00800000, Csr2 - 0x0, Vector - 0xF0, Bus_Priority - 1, Type - C, Adpt_Config - N

For PCI, the above would be PCI_Option instead of VBA_Option...

files file fragment:

MODULE/STATIC/dmaex            standard Binary
/usr/examples/devdriver/dm100/dmaex.c        module dmaex

Perform the following tasks:

    # cd /usr/sys/conf

    If a /usr/sys/conf/BINARY.list file is not in this directory, create
    the BINARY.list. Edit the /usr/sys/conf/BINARY.list file and
    add the following line:

    /usr/examples/devdriver/dm100:  

    Run the sourceconfig program

    # ./sourceconfig BINARY

   # cd /usr/examples/devdriver/dm100

    Add the sysconfigtab files file fragment to /etc/sysconfigtab

    # sysconfigdb -a -f /usr/examples/devdriver/dm100/sysconfigtab dmaex

    # cd /usr/sys/BINARY

    Run the make program to generate the single binary module of the
    /dev/dmaex device driver in /usr/sys/BINARY directory.

    # make dmaex.mod

    # cd /subsys

    # ln -s /subsys/device.mth dmaex.mth

    # ln -s /usr/sys/BINARY/dmaex.mod dmaex.mod

    Once the system has been rebooted, the driver can be loaded
    and unloaded with the following commands:

    # sysconfig -c dmaex
    # sysconfig -u dmaex


Or, for linking statically into the kernel: 

    # cd /usr/sys/conf

    Copy the product registration file to /usr/sys/conf directory

    # cp /usr/examples/devdriver/DM100.list DM100.list

    Build a customized kernel with the dmaex driver statically installed.
    An example of building the customized kernel follows:

    # doconfig -c DM100

    
    Best Regards,
    
    Lee Parker                       [email protected]
    Digital UNIX Device Driver & Realtime Support
    Realtime Expertise Center        1-800-354-9000
    

When I boot the system, I see the following message during the startup:

Sysconfigtab PCI_Option entry 28 invalid

and I subsequently cannot load my driver. In the spirit of fixing known bugs
first, any ideas what might be wrong with the following entry (which is indeed
the 28th one in the /etc/sysconfigtab file):

tlink:
        Subsystem_Description = T-Link device driver
        Module_Config_Name = tlink
        Module_Config1 = controller tlink0 at pci? slot ?
        Module_Type = Dynamic
        Module_Path = /subsys/tlink.mod
        Device_Char_Major = Any
        PCI_Option = PCI_SE_Rev - 0x210, Vendor_Id - 0x5555, Device_Id - 0x0080,
 Rev - 0x10, Base - 0 , Sub - 0, Pif - 0, Sub_Vid - 0, Sub_Did - 0, Vid_Mo_Flag
- 1, Did_Mo_Flag - 1, Rev_Mo_Flag - 1, Base_Mo_Flag - 0, Sub_Mo_Flag - 0, Pif_Mo
_Flag - 0, Sub_Vid_Mo_ Flag - 0, Sub_Did_Mo_Flag - 0, Driver_Name - tlink, Type
- C, Adpt_Config - N

I generated the PCI_Option by taking an existing entry from /etc/sysconfigtab
and updating it with the values from my V3.2C option snippet.

	Thanks, Shaheed

BTW: Is the Module_Config1 entry likely to cause any problems? I seem to recall
reading in the docs that this was not needed, but I cannot find the reference at
the moment to confirm this.

    
    Hi Shaheed,
    
    When you say you took an existing PCI_Option line and modified
    and must not have any carriage returns until the end.  A cut-and-paste
    will add carriage returns where you do not want them.
    
    			Just a quick thought, Tim
    
    

Hi Shaheed,

   It would appear from looking at you PCI_Option entry that you may have
mangled the "Sub_Vid_Mo_ Flag - 0," field. Spaces are not allowed as part
of tag names so you might try "Sub_Vid_Mo_Flag - 0,". This does have to be
one (continuous) line as Tim has pointed out in the previous note.

>
>BTW: Is the Module_Config1 entry likely to cause any problems? I seem to
recall
>reading in the docs that this was not needed, but I cannot find the reference
at
>the moment to confirm this.
>

   The 4.0 device driver documentation documents how to write a 4.0 device
device. It also has a section, I believe chapter 4 that details what has to be
done in order to port a 3.x device driver to the 4.0 model. This mechanism
Module_Config1 was retired in 4.x. You should not be be picking from the
4.0 driver functionality to enhance your driver but rather referenceing the
4.x documentation. Otherwise you may end up with a driver that incorrectly
mixes the 3.x and the 4.0 single binary driver support models.

Thanks,
Karl

[Posted by WWW Notes gateway]

>   It would appear from looking at you PCI_Option entry that you may have
>mangled the "Sub_Vid_Mo_ Flag - 0," field. Spaces are not allowed as part
>of tag names so you might try "Sub_Vid_Mo_Flag - 0,".

Blush...that space was it! As I mentioned, the kernel was smart enough to tell
me that something was wrong with the entry at boot time, but my glasses must
need changing 'cos I certainly couln't see it.

Is it worth a QAR that the extra space causes a system hang in
configure_driver(), rather than an error return?

>... Otherwise you may end up with a driver that incorrectly
>mixes the 3.x and the 4.0 single binary driver support models.

Thanks for the warning - I'm trying to for a single source stream (with minimal
#ifdef'd code) if I can. For now, I have something that works with the
V3.2C/V4.0A combination - I understand that this may not work reliably in all
cases.

	Thanks, Shaheed