efs - Partion couldn't be found...

After I’ve reprogrammed the devf-generic driver for my flash-rom everything works fine I think. I can create a flash-partition with the flashctl-utility and write some files into it. Reading is also no problem.
Now I’m searching for a solution to get the following:
I programmed a bootloader that writes the QNX OS Image to the Flash-ROM via Srecords. Now I want that I’m able to do the same with a Flash-Partition. So I created a efs-Project an created an efs-file. I converted it to srec and wrote it on the flash-rom. The data seems to be correct, but when I start the devf-generic it doesn’t find a partition.
Is it possible to get the complete Filesystem from the Momentics IDE, so I don’t have do dump my entire Flash-ROM an write the important section to a file. I thougth the efs gives me exactly this.

Not sure I entirely understand.

First, EFS will not create a partition for you. The flash-ctl utility will create a partition. You can write an EFS image into a partition, but it must be a binary image (not srecords).

So, in general, you need to:

  1. Create a partition to hold the EFS filesystem using flash-ctl
  2. Create a binary EFS image (i.e. raw)
  3. Get this image onto the QNX system
  4. Write it to the partition using the “cp” utility (for example)

Then you can use flash-ctl to mount the partition to a prefix, and you’ll have the EFS filesystem available.

Now, if you want to write the EFS outside of QNX, then you need to calculate the offsets of the partition, and drop the binary image there. If this external utility reads srecords that’s fine, but when it is finished, the result needs to be binary identical to copying a raw image to a devf-* partition using the cp command under QNX.

Ok now I tried it.
I created a 1MB partition with flashctl. Then I generated the efs file and converted it to srec with an offset of 0x100, because the partition table is from 0x00 to 0x50.
So before flashing it looks like this (see Attachment ffs3_empty.gif)
After putting the efs on offset it looks (see Attachment ffs3_full.gif)
I think thats what you mean.
But when I load the devf the partion is empty. I think it’s because qnx doesn’t recognize a efs in an ffs because efs (embedded file system) is an filesystem itself, maybe a partion for each file or so?! I think so because the efs-header looks very similar (compare the files at 0x00-0x50 and 0x100-0x150)

When I write a simple file in the partition using the command

It looks in the filesystem like this (see Attachment ffs3_simple.gif)
I think this is much less overhead than an efs file. Why is almost the same header in the efs file like in the ffs3 partition header? Isn’t there a possibility to create the “normal” file header for a file? (like the header of simple.txt)? What is this efs header thing of the efs for, when I don’t need it apparently?

Hmmm, let me see if I can be clearer.

When I said “use cp to copy the efs to a partition”, what I meant was “use cp to copy the efs to the raw mountpoint”.

The procedure for doing this is documented clearly in the IDE docs.

The following is lifted verbatim from the docs:

Let's make a dummy flash filesystem for the purpose of this example (the ^D means Ctrl-D): 

$ mkefs -v - flash_image
[block_size=128k spare_blocks=1 min_size=384k]
/bin/ls
/bin/cat
^D
writing directory entry ->
writing file entry      -> ls **
writing file entry      -> cat *
Filesystem size = 384K
block size = 128K
1 spare block(s)This flash filesystem actually works (unlike the IPL). Now, the flash partition images can be transfered to the flash using any file-transfer utility (such as cp or ftp). We have an IPL image created with mkrec (and properly padded to an erase block boundary) and a flash image created with mkefs, so we can use cat to combine and transfer both images to the flash: 

$ cat ipl_image flash_image > /dev/fs0

You don’t need the “ipl_image” part, because you are only concerned with the EFS. so “cat flash_image >/dev/fsX” is what you want.

Huh? If this worked, then your EFS is mounted, why do you say it isn’t? (devf-generic won’t mount to /fs0p1 unless the filesystem is recognized).

Again, I don’t understand what you are getting at. If the /fs0p1 prefix shows up, then devf-generic recognized a EFS and mounted it.

Maybe I need to know what your definition of an EFS is?

As I said, my goal is to update the partition NOT over QNX but over the bootloader. cat ipl_image flash_image > /dev/fs0 did the same like writing directly into the flash via bootloader but the “cat” writes it to the beginning of the flash-rom, but at 0x00 there is the QNX and my application partition is at 0x500000 (after the QNX System)

Sorry I forgot to say that this was the partition which I created with flashctl for testing. This isn’t the flash with the efs in it.
Again: QNX doesn’t recognize the efs in flash but it does recognize the partition which was created via flashctl.

As I said, my goal is to update the partition NOT over QNX but over the bootloader. cat ipl_image flash_image > /dev/fs0 did the same like writing directly into the flash via bootloader but the “cat” writes it to the beginning of the flash-rom, but at 0x00 there is the QNX and my application partition is at 0x500000 (after the QNX System)
[/quote]

Does devf-generic see the whole flash?

(i.e. what is the output of “flashctl -i”)

Yes, it does.The Flash ROM is 32 MB. The partition itslf is 1MB (5 to 6MB)

So then you should see :

/dev/fs0
/dev/fs0p0 < QNX
/dev/fs0p1 < Stuff between QNX and the EFS
/dev/fs0p2 < EFS
/dev/fs0p3 < remainder

Right?

…Or are you saying that “QNX” goes from 0->5MB and the EFS goes from 5-6MB?

…in which case you’d have:

/dev/fs0
/dev/fs0p0 < QNX
/dev/fs0p1 < EFS
/dev/fs0p2 < remainder

Either way, in order to update the EFS, you need to open /dev/fs0, SEEK to 5MB and write the efs image (dd can do this), then re-start devf-generic. If that works from QNX, and it doesn’t work from your ROMMON update function, then there is a bug in your ROMMON update function.

So what I am saying is this:

Update the EFS with QNX. If that works, then figure out what the ROMMON update function is doing differently…

Before formating I only have
/dev/fs0
/dev/fs0p0
After formating @5-6MB I have
/dev/fs0
/dev/fs0p0
/dev/fs0p2
And the fs0p1 is in root.
When I “copy” the efs with “dd” @5MB I have exactly the same in the Flash-ROM as I program it with my Bootloader. This is because with dd @fs0 I do a raw write. The created partition table from flashctl will also be overwritten.