Gurus out there please help -- compact flash

[Rita]

I'm having problem mounting DOS FS on my compact flash. When it was
fresh from
the factory, I was able to mount DOS FS, and did a "mkdir" on it. Then
windRiver
engineer told me that I was using the wrong usrAtaConfig.c. (The one I
used was pre-dos 2.0.) After using the "correct" usrAtaConfig.c, the
dosFs didn't mount, and was complaining about "No partition table
found, and malformed boot sector."
I then used "usrFdiskCreate()" as suggested to create a single
partition table. When trying to mount the dos fs, it again complaind
about "Malformed boot sector."

I found that the partition table sits in sector 0, and there was no
dos boot sector. Also, I found that the dosFsSecGet() was looking at
sector 0x20 for
the boot sector information. I think there is some serious screw up
here. I read somewhere in usrFdiskLib.c (I don't remember exactly
where), that
I don't need a partition table if I'm using the entire disk as a whole
drive.

Anyway, I formatted the disk under w2k, and dumped the first sector to
see what a dos boot sector looks like, and then tried to boot it up
from vxWorks. It didn't work. It still prints out error message,
"Malformed boot sector."

I think I might have started out from the wrong side of the road. I
got couple of other compact flashes, but none contains factory format.
They were all formatted under w2k. (I forgot to mention that I'm using
it with a mips board.)
Can someone suggest how to solve this problem?

My questions are,
1) do I need a partition table, if not, what should I do.
2) how does the dosFs calculate the location of the boot sector?
3) where can I get an image of a dos boot sector, or should I write my
own? (I have the FAT16 document for the boot sector.)
4) If I write my own dos boot sector, do I have to create a FAT root
directory?

Please help me out. I've never done anything like this before, and am
really stuck in mounting dos fs.

Thanks a lot in advance.
Rita

[Leonid Rosenboim]

Rita,

The WRS engineer was in a way right to suggest you use a newer initalization
code, but you need to look into this code and make sure it does everything
the way YOU need it done.

Generally, concerning CompactFlash, I recommend you first mount an duse it
with its detault factiry format, or after its been formatted by a PC.

So you do not need to use usrFdiskFormat(), but in the initialization code,
you need to use dpartLib, which handles partition tables for DosFs2.0.
Yu should find examples of using dpartLib with dosFs in the on-line and
manual
and DosFs component (or release) manual.

Only if you are building an appliance which MUST be able to format a CF card
(all my digital camreas do that), will you need to get your teeth into
usrFdiskFormat, which is delivered to you in source code, so you can make it
work the way you like it to.

Hope this helps,
Leonid Rosenboim

P.S. I wrote usrFdiskFormat() as wellas dcacheLib, so please be gentle.

"Rita" <rit...@comcast.net> wrote in message
news:d3a5605c.0209...@posting.google.com...

[Rita]

Hi leonid,

Thank you for your reply. The newer initialization code does use
dpartLib and dcacheLib as part of the initialization before calling
dosFsDevInit(). I looked into usrFdiskLib.c and did not see
usrFdiskFormat(). There are only 3 routines, one is to create a
partition table, one to read it, and one to parse it. I will check
with WRS engineer to see if I have the correct source code to work
with dosFs2.0.

I assume that usrFdiskFormat() calls usrFdiskCreate() to create a
partition table, as well as creating a dos boot sector. The appliance
I build needs a format tool, so I will need to include
usrFdiskFormat(). I just got hold of dosFs2.0 manual, and am getting
documentation on dcacheLib and dpartLib. I will give you a followup if
I have any breakthrough.

Thanks for your suggestion.
P.S. *ouch* didn't know you wrote usrFdiskFormat(), sorry, didn't mean
it bad.
I was getting frustrated at being stuck in mounting dosFs for a while.
Rita

"Leonid Rosenboim" <MY_FIR...@CONSULTANT.COM> wrote in message news:<newscache$eumt1h$3ne$1...@lnews.actcom.co.il>...

[Leonid Rosenboim]

Rita,

Here is an example intialization code from teh DosFs2.0 manual:

It assumes the disk is execpected to have at most three partitions,
and does not include the block device driver intialization.

usrPartDiskFsInit( void * blkDevId )
{
const char * devNames[] = { "/sd0a", "/sd0b", "/sd0c" };
int dcacheSize = 0x30000 ;
void * cbio, * cbio1 ;
/* create disk cache */
if( (cbio = dcacheDevCreate(blkDevId, NULL, dcacheSize, "/sd0"))
== NULL )
return ERROR ;
/* create partition manager with FDISK style decoder, up to 3 parts */
cbio1 = dpartDevCreate( cbio, 3, usrFdiskPartRead );
/* create the 1st file system, 8 simult. open files, with CHKDSK */
dosFsDevCreate( devNames[0], dpartPartGet(cbio1,0), 8, 0 );
/* create the 2nd file system, 6 simult. open files, with CHKDSK */
dosFsDevCreate( devNames[1], dpartPartGet(cbio1,1), 6, 0 );
/* create the 3rd file system, 4 simultaneously open files, no CHKDSK */
dosFsDevCreate( devNames[2], dpartPartGet(cbio1,2), 4, NONE );
}

Do note that old ATA intialization code had some partition handling code of
its own (because DosFs 1.0 did not handle partitions) and you need to make
sure that the ATA driver intialization code does not do anything like that,
and that the block device "sees" the entire CF card, starting from block 0.

As to formatting, you are right, useFdiskPartCreate() creates the partition
table,
then you need to call dosFsVolFormat() to actually initialize the dosFs.
I fyou do not plan on booting from the CF (even PCs dont use CF or PCMCIA
for booting normally), the code in usrFdiskLib should satisfy your needs.

"Rita" <rit...@comcast.net> wrote in message

news:d3a5605c.02090...@posting.google.com...

[Rita]

Leonid,

Thanks for your help. I think I miss out a step.
--> dosFsVolFormat() after dosFsDevCreate(). I used dosFsDevInit(),
and
passed in NULL for DOS_VOL_CONFIG *. That might have been a problem.
Currently, I'm not booting up from the compact flash, and hopefully, I
won't need to do that.

This is what I have right now (printf results from initialization.)
->ataDevCreate:
usrAtaconfig: cbio=0x8efb6050 /* my printf */
usrFdiskPartCraete(0x8efb6050, 1, 0, 0, 0) /* my printf */
usrAtaConfig: dpartDevCreate((FUNCPTR)usrFdiskPartRead) /* my printf
*/
usrFdiskPartLib warning: disk partition table is not intiialized /*
vxWorks */
usrFdiskPartLib warning: use usrFdiskPartCreate(0x8efb6050, 1) to
initialize the disk as a single partition

Retrieved old volume params with %63 confidence:
Volume Prameters: FAT type: FAT16, sectors per cluster 114
116 FAT copies, 0, clusters, 18798 sectors per FAT
Sectors reserved 21369, hidden 0, FAT sectors 2180568
Root dir entries 28019, sysId (null), serial numbger 74727450
Label:" "...

Diskwith 503808 sectors of 512 bytes will be formatted with:
Volume Parameters: FAT type: FAT16, sectors per cluster 8
2 FAT copies, 62910 clusters, 246 sectors per FAT
Sectors reserved 1, hidden 0, FAT sectors 492
Root dir entries 512, sysId VXDOS16, serial number 74727450
Label:" "...

This is the dump of sector 0:
[0x0000] 3eeb 5690 4458 534f 3631 0000 0802 0001
*>.V.DXSO61'.'.'.*
[0x0010] 0002 0002 f800 00f6 0020 0010 0000 0000 *'.'.'.'.'
'.'.'.*
[0x0020] b000 0007 0080 5029 7274 0074 0000 0000
*'.'.'.P)rt't'.'.*
[0x0030] 0000 0000 0000 4146 3154 2036 2020 0000 *'.'.'.AF1T 6
'.*
[0x0040] 0000 0000 0000 0000 0000 0000 0000 0000
*'.'.'.'.'.'.'.'.*
...... .... same as 0x0040 all the way til 0x1e0...
[0x01f0] 0000 0000 0000 0000 0000 0000 0000 aa55
*'.'.'.'.'.'.'.'U*

Read out reversed:
[0x0000] eb3e 9056 5844 4f53 3136 0000 0208 0100
*'>'VXDOS16'.'.'.*
[0x0010] 0200 0200 00f8 f600 2000 1000 0000 0000 *'.'.'.'.'
'.'.'.*
[0x0020] 00b0 0700 8000 2950 7472 7400 0000 0000
*'.'.'.)Ptrt.'.'.*
[0x0030] 0000 0000 0000 4641 5431 3620 2020 0000 *'.'.'.FAT16
'.*
[0x0040] 0000 0000 0000 0000 0000 0000 0000 0000
*'.'.'.'.'.'.'.'.*
...... .... same as 0x0040 all the way til 0x1e0...
[0x01f0] 0000 0000 0000 0000 0000 0000 0000 55aa
*'.'.'.'.'.'.'.'U*

I think the byte order is wrong. Please let me know which one is the
correct one. Since I'll be the only one writing and reading out from
the compact flash, I didn't think I need to do byte swapping. I could
be wrong.

Thanks so much for all your help.
Rita

"Leonid Rosenboim" <MY_FIR...@CONSULTANT.COM> wrote in message news:<newscache$45uu1h$3uh$1...@lnews.actcom.co.il>...

[Leonid Rosenboim]

Tell you what -
put in a CF formatted on a PC, and dump its memory in a byte width:
-> d address,1

But from this stuff it seems there is indeed a btre swapping issue !

Your CompactFlash socket (sometimes its actual PCMCIA) has a 16 bit bus,
and if connected to the MIPS (Big Enian) bus naively, you will get every two
bytes
order reversed, because the standard PCMCIA (and CF) bus layout is Little
Endian.

run a swab() function over each sector at the driver level, and see what
happens.

- Leonid

"Rita" <rit...@comcast.net> wrote in message
news:d3a5605c.02090...@posting.google.com...

[Rita]

Hi Leonid,

Thanks! It works! I still got some questions though. If I don't call
usrFdiskPartCreate(), usrFdiskPartLib prints out warning "disk
partition table is not intiialized". When calling format,
dosFsVolFormat() writes to sector 0, and dosFs gets mounted correctly,
and I'm able to read and write files.

If I call usrFdiskPartCreate() before dpartDevCreate(), the partition
table is written to sector 0, and dosFsVolFormat() writes to other
sectors, that it later complains cannot be found.

Can you explain what I'm doing wrong?
Thanks.
Rita

"Leonid Rosenboim" <MY_FIR...@CONSULTANT.COM> wrote in message news:<newscache$45uu1h$3uh$1...@lnews.actcom.co.il>...

[Leonid Rosenboim]

Let me try to sort out some confusion:

WHen you initialize the Dosfs "stack", there needs not be a disk in the
slot, or there could be an unformatted disk or whatever. Intialization
itself does not cause disk access, and therefore disk needs not be legal.

Initialization is when you call ataDevCreate, then dcacheDevCreate,
dpartDevCreate, and { dosFsDevCreate with dpartPartGet ).

When you attempt to access a file (or do "ll"), dosFs will send a RESET
ioctl all the way down the stack to the driver, at that point the driver
needs to reinitialize (this is a removable so it needs to do some init if a
new card was inserted), and then dcache reinits, and dpartLib will re-read
the partition table, and dosFs will re-read its first block.

Now, suppose you done that initialization, and a card is inserted with an
illegal partition table, there will be a warning, and you can ignore it if
you intend to later create the partition table and format the partition.

Before you go into formatting, I strongly recommend you get comfortable with
using CF cards that where formatted on a PC, and make sure everyting works
to your satisfaction.

When you want to reformat the CF, do it AFTER the normail initialization
procedure, and after all is formatted, the stack will be RESET again (as if
a card was cahnged) so everything will be reinitialized as if a card was
changed.

Hope this helps.
- Leonid

"Rita" <rit...@comcast.net> wrote in message
news:d3a5605c.02090...@posting.google.com...

[Rita]

Thanks, Leonid. That explains a lot. I checked the byte swap, and
found where I made the mistake. When formatted under PC, I have to
read it out in *reverse* order to get it out right. When writing using
vxWorks, I assume if I don't do byte-swap while writing it, I can read
it without byte-swapping later. So after couple of testing and
rearranging byte order, I ended up having straight write, and
byte-swap read. Thanks for pointing that out.

Thanks for the suggestion. I'll get a CF and play with it a bit with
PC before
I dip into CF formatting.

Again, many thanks to your help. I can finally see some daylight.
Rita

"Leonid Rosenboim" <MY_FIR...@CONSULTANT.COM> wrote in message news:<newscache$8igv1h$icj$1...@lnews.actcom.co.il>...