mkdir function not implemented when booting from USB

QNX USERS QNX6 - OS
1

I am attempting to boot QNX 6.6.0 from a USB memory stick plugged into an Adlink ReadyBoard 910 single board computer.
First thing I did was get the generic x86 BSP and followed the instructions in the BSP user’s guide. i.e. I created a system builder project (using Momentics on a Windows 7 development computer), fiddled around a bit with the x86-generic.build file, built the project without errors, used mkxfs to create a partition image, used diskimage to make a USB disk image, and then used Win32 disk imager to copy the image onto a USB memory stick. If I plug the stick into the ReadyBoard 910, set the BIOS to boot from the memory stick, and power up, it does indeed boot to the command line.

If I set the IP addresses correctly and plug both my development machine and the ReadyBoard into a network I can also navigate around the file system using the target file system navigator view from Momentics.

Great stuff. Now I want to get my software onto the target system, so I thought I would create a directory (named “/SIL”) to put it in. However if I try:
mkdir SIL

I get the response:
mkdir: SIL: Function not implemented

Can anyone tell me how to get mkdir (and also cp) to work?

Is the error message misleading? Is the USB memory stick being treated as a read-only device?

2

Here’s the problem. You probably have an image file system, but it’s not writeable. here’s something you could do. Partition your stick into two part and after you boot, mount and initialize the 2nd partition with a QNX file system. Now you will be able to write to it. You will need a few utilities in your boot image to do this, eg. dinit or mkqnx6fs (I don’t think that’s the right name) and mkdir. You might also need the QNX fdisk to create the 2nd partition.

An alternative might be to create a ram disk, but you would need to recreate it each time you boot.

3

OK. I managed to partition my 16GB stick into two partitions. The first partition is 8GB and I made this the active partition. The second partition occupies the remaining space (somewhat less than 8GB). I used the Paragon Hard Disk Manager 15 program to do this and I’m not completely sure what format it used to format the partitions. Probably DOS.

Previously, after the system booted I was unable to see anything in the /dev directory that looked anything like a USB memory stick, but after modifying my build file from this:

display_msg "Starting USB services..."
io-usb -duhci -dohci -dehci -v &
waitfor /dev/io-usb/io-usb 4
waitfor /dev/io-usb/devu-uhci.so 4
waitfor /dev/io-usb/devu-ohci.so 4
waitfor /dev/io-usb/devu-ehci.so 4

to this:

display_msg "Starting USB services..."
io-usb -duhci -dohci -dehci -dxhci -v &
waitfor /dev/io-usb/io-usb 4
waitfor /dev/io-usb/devu-uhci.so 4
waitfor /dev/io-usb/devu-ohci.so 4
waitfor /dev/io-usb/devu-ehci.so 4
waitfor /dev/io-usb/devu-xhci.so 4

I was able to see two new entries in the /dev directory:

/dev/hd0t177
/dev/hd0

I think these represent the two partitions on the USB stick, but which is which? The df command gives unexpected results:

df -P -h

Filesystem Size Used Available Capacity Mounted on
/dev/hd0 256M 256M 0 100% /dev/hd0t177
/dev/hd0 14G 14G 0 100%

Not sure what this is saying. Does hd0 consists of two partitions, one of 256M and one of 14G? That isn’t the way I partitioned it.

Next problem is with fdisk (I thought it might give me some hints as to what is going on). If I do:

fdisk /dev/hd0

I get the response “Error opening terminal: qansi.”.

So I modified my build file to include this:

/usr/lib/terminfo = /usr/lib/terminfo

which I thought would copy the entire terminfo directory (and contents) onto the target’s /usr/lib directory but it doesn’t seem to have worked. Anyone know why?

Any help appreciated.

=============

Bit of an update. It seems df is indeed telling the truth. The problem was that after having partitioned the USB stick I then went and used the Win32DiskImager program to stick a new image onto the USB stick. This overwrites all the existing partitions so you end up with a 256MB partition with the image on it and the rest of the space is unused.

However, if use Paragon Hard Disk Manager 15 to look at the partitions after I have used Win32DiskImager I can then turn the unused space into a DOS formatted partition and give it a volume label of “B”. If I then boot from the USB memory stick I can now see three USB stick related things in /dev:

/dev/hd0
/dev/hd0t12
/dev/hd0t177

If I then do “df -h” I can see that:
/dev/hd0t12 is the 14G partition (which was formatted as DOS using Paragon)
/dev/hd0t177 is the 256M partition (active partition written using Win32DiskManager)

After a bit of fiddling about I find I can mount the 14G partition with “mount -v -t dos /dev/hd0t12 /B” and access it through the “/B” directory.

4

I think you’ve figured it out.

/dev/hd0
/dev/hd0t77

indicates 1 partition.
/dev/hd0 is the whole device
/dev/hd0t77 is the partition

If you run fdisk with just the device as one parameter, you do need the terminal, however fdisk has command line options. You should not need fdisk unless you want to change something.

You can use the partition as DOS however you may run into a small problem. A dos partition has no permission bits. You need executables to have executable permission. There is a way to tell QNX to fake all files on the dos partition to have execute turned on. I don’t recall how to do this, but I think it is a driver option.

Instead you can initialize the partition with either dinit or mkqnx6fs

qnx.com/developers/docs/6.5. … nx6fs.html

and mounting it as such. dinit creates a qnx4 partition, which was the default for qnx6 for many years. The qnx6 file system has some advantages but comes with a hardware requirement that a stick might not fulfill.

5

Looks like I got it to work. If I do the following:

on -w /dev/hd0t12
mount -v -t dos -o exe=all /dev/hd0t12 /B

then I end up with a DOS partition which I can access via the /B directory. I can read and write files and I can also execute them.

Thanks for the information regarding the lack of an executable permission bit in a DOS filesystem. Saved me a lot of time.

6

Yes the exe=all is the key.