I'll play around with it, and see if I can figure out
what they're doing.
Interesting. I did some experiments with DSO.EXE renamed, so it would
not be automatically executed at startup. It appears that the OS driver
always detects the USB stick, from powerup, but it does not signal the
stick's presence, to DSO.EXE, until an insert event is observed. Once an
insert event is observed, DSO.exe will always detect the stick. DSO.EXE does
not need to be running, during the insert event, for the stick to be detected, the
next time it is run. The problem does not appear to be a race-condition. Delaying
the start of DSO.EXE does not help the problem. Also, accessing the device, from
the OS prompt, prior to starting DSO.EXE, does not help.
This leads to to believe that the problem can probably be fixed, by forcing a
refresh of the mount and/or interface status. Unfortunately, I am not as familiar with
driver/kernal level Linux, as I would like to be
![Smiley :)](https://www.eevblog.com/forum/Smileys/default/smiley.gif)
Perhaps one of the Linux guru's, on
the thread, can take a look, and see if they can figure out how to remount the drive, or
force a state refresh? Near as I can tell, the driver is not creating a standard /dev. Instead
they use SCSI emulation, and mount the flash stick directly to /mnt. I do not see anything
in the fstab, that described the device. There is an jffs2 entry, but I believe it is for the
onboard flash. One curious note, when DSO.EXE detects the stick, it automatically does a
directory listing of the drive, which is displayed on the console, along with a note "get udisk first".
I have not found any sign of udisk in the OS image, except for a file called "udisk-flag", which is
always zero bytes. One other interesting note, from powerup, the OS driver assigns the stick
"sda", but on most subsequent inserts, it assigns the device "sdb".
ECL -K