[solved]whereabouts of FVID functions -as a wrapper on top of GIO class driver

This is a good question, and something that often proves confusing when trying to trace through BIOS drivers. The problem is that not all of the source code is available, particularly BIOS source code, so there is a gap that you cannot see between where GIO_create is called and the actual code within C:\dvsdk_1_01_00_15\psp_1_00_02_00\pspdrivers\drivers\vpbe\src is executed. I think the document that would help to explain this best is SPRU616, it goes into some detail on BIOS device drivers and what actually happens behind the scenes.

To answer your question on FVID_create more directly the calling sequence goes something like: FVID_create -> GIO_create (BIOS binary) -> VPBE_mdCreateChan -> subsequent driver specific init functions. You can find the source to VPBE_mdCreateChan within C:\dvsdk_1_01_00_15\psp_1_00_02_00\pspdrivers\drivers\vpbe\src\dda_vpbeIom.c. If you want to do some debugging and step through this driver code all you have to do is add the dda_vpbeIom.c file to your project (CCS will utilize C files in your project in place of the same symbols in a library). If you then set a breakpoint at the beginning of VPBE_mdCreateChan you should see it get hit as soon as you call FVID_create. You can follow this through with other FVID functions as well, any FVID function you call in your application maps to a function somewhere within the source code of C:\dvsdk_1_01_00_15\psp_1_00_02_00\pspdrivers\drivers\vpbe\src, SPRU616 describes how this mapping is made.

Thank you for answering.

I wonder if the BIOS source codes are permanently closed, or if they are just not included in dvsdk. Is it possible to retrieve these codes from TI? I am asking this because as I mentioned before, I am not permitted to use any not-open source code. Also I think it is possible to use mini-driver functions without using a wrapper class like GIO, hence GIO can be subtracted from the code, if there are no source codes that I can retrieve, am I right?

I am less familiar with SPRU616, though I intend to read at least related parts. (Some of them which I had already read.) Function mapping that you mentioned is, I think, related with the interface table of type IOM_Fxns,as an example:

IOM_Fxns DSK5402_MCBSP_AD50_FXNS = {
mdBindDev,
IOM_UNBINDDEVNOTIMPL,
mdControlChan,
mdCreateChan,
mdDeleteChan,
mdSubmitChan
};

A configuration is done in .tci file, table name given, and device name given as "\VPBE0". Although I don't understand how the interaction is done with IOM at my current level, with just giving table name and the device name. I mean, there is no visible code in the application that this device name is used, for example.

Unfortunately the BIOS code is not open source, usually this is only a problem for high saftey applications (aerospace and medical), in which cases an alternate OS or a third party like Validated Software would be involved. If you really do need the BIOS source this is the type of question you would want to take to your local TI contact, as BIOS is not typically available in source this would have to be a special exception. You could take the drivers and extract out the GIO portion but that would take significant effort, also note that you would have to do this for any other BIOS drivers and any BIOS structures you may be using, such as tasks.

There is a table in dda_vpbeIom.c that maps in the various mdXxxxChan functions (line 71) to GIO_xxx functions, and you should be able to map the FVID functions to GIO functions using the header file as you had found previously.

Bernie Thompson said:

You could take the drivers and extract out the GIO portion but that would take significant effort, also note that you would have to do this for any other BIOS drivers and any BIOS structures you may be using, such as tasks.

Actually what I had in mind by "subtracting GIO" is, that I may use direct calls to IOM, just without using the GIO API for VPBE IOM. But at this current level, I don't know if this would be possible.

It certainly was not designed to be used that way, and I have not tried it, but it may work. For the most part GIO should be a pass through my concern would be if some of the functions which may block the task utilize GIO level code.

Of course in the big picture the driver does make calls that block the task that the calls are made from for sure, which means it is making calls into BIOS code for which source is not available anyway, so to use the driver without using BIOS is a bigger project than just calling the internal driver functions directly.

Thanks Bernie. I will look and decide what I can do, maybe ask for the source codes; at least I have some info now that I can present to my primes.

By the way, this morning I got a response from TI knowledge base, from Mr. Giancarlo Parodi, telling the source codes for GIO API are not included, since it is a DSP BIOS API. He told me to look into "C:\CCStudio_v3.3\bios_5_31_07\packages\ti\bios\include" for header files of bios. But I discovered that "C:\CCStudio_v3.3\bios_5_31_07\packages\ti\bios\src" folder has the source codes I need. All the GIO API source code is included in this folder. Is this a normal thing? (that's a weird question I think :)...

You got me on that one, it does appear that the GIO API is in fact included in source, I apologize for the confusion. What you are seeing is normal, I checked back several releases of BIOS and this folder was still in there, I just had never come across it as the general rule for BIOS is that source is not included.

I can say for sure that much of BIOS is not provided in source though, so if you need source to the entire project than you still have a problem, for example if you do a search in the BIOS folder for files that contain the string SEM_pend, it shows up in several library files, documents, header files, and examples, but the actual source is not in there. Also note that the source to functions being called within the GIO API source is not all there, for example the call to MEM_calloc can be traced back a few function calls from MEM_calloc -> MEM_vallocJ -> MEM_vallocPtr within mem.h though the actual source to this does not appear to be present after searching the BIOS directory.