Are cam-disk.so, io-blk.so and fs-dos.so all available?

Hey Todd,

So I went and did some simple mounting of my sd driver and captured the attached screen shot.

Bottom line is that it should mount the root device as you specify, its just that if you try to read it it will complain
 about a corrupted file system.

It is possible that you may have a problem with reading from your device.  Getting all the SIM/CAM stuff right can be 
tricky.

I debugged my driver using the cat utility as I mentioned in my earlier post.  Once you get this right, then it should 
mount.

Kevin

Todd Peterson wrote:
> I have implemented an SD card driver for Phytec (NXP) LPC3180, starting with driver in Atmel AT91SAM BSP. Implemented 
low-level functions for read, write, get cid/csd, etc. and verify that they work. Hooked up to the sim system and 
initialization seems to complete ok. But, when I try to mount the device I get the message below, I can't locate 
mount_dos cmd, which it complains about. Any ideas? Thanks. Todd
> 
> when i start the driver:
> 
> Path=0 -
>  target=0 lun=0     Direct-Access(0) - SD:#3 SU01G Rev: 8.0
> 
> when i try to mount:
> 
> # mount -vvvvv -t dos /dev/hd0 /mnt/usb
> Parsed: mount from [/dev/hd0] mount on [/mnt/usb] type [dos]
> exec: mount_dos /dev/hd0 /mnt/usb
> Using internal mount (mount_dos not found)
> Type    [dos] Flags 0x00000000
> Device  [/dev/hd0] Directory [/mnt/usb]
> Options []
> mount: Can't mount /mnt/usb (type dos)
> mount: Possible reason: Resource busy

Don't worry about mount_dos, that is a mount extension that first tries
to launch a fs-specific mount helper function, in case processing is not
in the usual manner.  Failing that it will handle it internally via a
standard mount() libc call.

The EBUSY typically means you already have a fsys of type dos mounted
on the partition (or raw device in your case apparently).  This might
be from a previous try or an automount or an enumerator etc.  "df"
would probably indicate this (mountpt shown in brackets).

Because you most likely report your SD device as being removable, io-blk
will remember the mount even if it cannot be actioned, as it might
become possible to perform on media insertion/change.  This feature for
example allows always mounting of a CD/ISO fsys at boot even though you
would seldom have a CD installed at that point; user access to the
pathname will cause a soft-remount attempt using the remembered
parameters; it also allows you to eject/change media without having
to explicitly remount (internally it will notice a new media and
perform an automatic remount).  You can disable this using the 'normv'
parameter (eg 'mount -o normv', or 'blk normv' to apply permanently),
in which case a EIO/ENXIO/EBADFSYS error is reported immediately.
Or slaying your driver should drop the mounts, or umounting the raw
device ('umount /dev/hd0') will also.

Try enabling 'blk verbose' on the driver, and check in sloginfo that
the device is attached as expected, and partitions are enumerated
(or at least attempt to read blk 0).  Check reported size is correct
(eg 'ls -s' or 'fdisk info').  Perhaps "spatch -b" it to examine the raw
data and see it looks as expected.  Does it 'dcheck'?  I am presuming
you expect it to be DOS-formatted?  Are you expecting it to be
partitioned?  Note that some factory-formatted SD and USB devices are
actually invalid (too big for the partition), but recent io-blk should
allow this in the special case of DOS, just forced to read-only (will
be told in sloginfo).

Hello todd,
       I'm also porting SD card filesystem on QNX. I write low level driver for SDHC card and test read() write() etc. 
ok, and I want to kown how to hook on the sim system? Is there some document about that? Thank you.