Hi
I wrote a script that does the following before running my application
1. ./prcm_config_app s
2. insmod syslink.ko
3. ./firmware_loader 1 video..xem3 start
4. ./firmware_loader 2 vpss..xem3 start
I noticed that when i call these commands fast, the firmware loader fails to load the ducati code because the syslink didn't finish to load yet... i have errors because it cannot yet find the /dev/syslinkipc_xxx modules
Is that normal behaviour? How much time do I have to wait between loading the syslink and loading the ducaties? I can insert a 1 sec sleep and it work. But i am running a real time applicaton which sometimes needs to restart the chip, and 1 second is a lot of time...
Any suggestions?
many thanks!
Which version of SysLink are you using? Older syslink.ko's might not have automatically created the /dev/syslinkipc_xxx entries, in which case they need to be created manually (which was accomplished by way of mknod calls in a loadmodules.sh script). But this would not explain the fact that a 1 sec sleep allows it to work. Very strange, indeed.
I would doubt that the syslink.ko loading is performed in the background after your insmod command returns. I would expect that the module is fully loaded and initialized when the insmod command finishes and returns the shell to a prompt.
Regards,
- Rob
Hi Rob
I am using syslink-02.00.02.80. In this version it is not necessary to mknodS ..
A sleep of 1 sec is not the minimum, i can try playing with quants of 0.01 sec.. but it is very weired, as you mentioned, that insmod won't finish creating the /dev/modules...
why is that?
Thnx,
Jonathan
Jonathan Distler A sleep of 1 sec is not the minimum, i can try playing with quants of 0.01 sec.. but it is very weired, as you mentioned, that insmod won't finish creating the /dev/modules... why is that?
Hi Jonathan,
I think I found the answer. When a new device is created, the automatic creation of the /dev entry is handled by a user space process named udev. udev receives a notification (an event) from the kernel and creates the /dev entry accordingly. See here for a nice description of udev: http://www.gentoo.org/doc/en/udev-guide.xml.
Perhaps udev can be tweaked in some way to cause it to respond to the event sooner than it currently is, perhaps not, but at least there is an explanation of what you're observing. You will therefore need to account for this delay and not try to run the SysLink app too quickly after the 'insmod syslink.ko'.