Customizing devf-xxxx Questions

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

I’m not quite sure where to post this, so here it is :slight_smile:

I’ve got an Nto 2.0 developer’s seat, with what I think is the latest release,
and I’m trying to customize a FLASH filesystem driver for my embedded project.
I started with devf-explr2 and had to modify very little in order to get things
to work. I’m now revisiting the driver to ensure that I’m getting access to
all of my devices, which caused me to realize that even though the thing seems
to work I don’t understand the setup I’ve done.

Specifically in f3s_xxx_open.c, I have:

socket->name = “enc”;
socket->window_size = 0; // Docs say “0 for non-windowed”
socket->address = FLASHADDR;
socket->bus_width = 2;

The devices on my board are 4 Intel 28F160B3’s linearly and sequentially
mapped, and they’re identified (at least one of them is), and things are just
lovely if I set socket->window_size = 2. When I try to set it to zero, the
call to mmap_device_memory() references socket->window_size for the size of
memory to map in (which is zero) so needless to say the driver gets a segment
violation and dies. My main question is how do I go about describing a
non-windowed array that will be probed so as I can install either 2 or 4 of
these 28F160’s or 28F320’s and it’ll “just figure it out”? The 160’s are
2-megabyte parts, the 320’s are 4-megabyte parts. Let me know if you need more
details.

Regards,
-Warren

2

I must correct myself…


“Warren Peece” <warren@nospam.com> wrote in message
news:8v21lo$8qt$1@inn.qnx.com…

I’m not quite sure where to post this, so here it is > :slight_smile:

I’ve got an Nto 2.0 developer’s seat, with what I think is the latest
release,
and I’m trying to customize a FLASH filesystem driver for my embedded
project.
I started with devf-explr2 and had to modify very little in order to get
things
to work. I’m now revisiting the driver to ensure that I’m getting access
to
all of my devices, which caused me to realize that even though the thing
seems
to work I don’t understand the setup I’ve done.

Specifically in f3s_xxx_open.c, I have:

socket->name = “enc”;
socket->window_size = 0; // Docs say “0 for non-windowed”
socket->address = FLASHADDR;
socket->bus_width = 2;

The devices on my board are 4 Intel 28F160B3’s linearly and sequentially
mapped, and they’re identified (at least one of them is), and things are
just
lovely if I set socket->window_size = 2. When I try to set it to zero,
the

^
Should be 2 meg, not just “2” ----------|

call to mmap_device_memory() references socket->window_size for the size
of
memory to map in (which is zero) so needless to say the driver gets a
segment
violation and dies. My main question is how do I go about describing a
non-windowed array that will be probed so as I can install either 2 or 4
of
these 28F160’s or 28F320’s and it’ll “just figure it out”? The 160’s are
2-megabyte parts, the 320’s are 4-megabyte parts. Let me know if you need
more
details.

Regards,
-Warren

3

Warren Peece <warren@nospam.com> wrote:
: I’m not quite sure where to post this, so here it is :slight_smile:

: I’ve got an Nto 2.0 developer’s seat, with what I think is the latest release,
: and I’m trying to customize a FLASH filesystem driver for my embedded project.
: I started with devf-explr2 and had to modify very little in order to get things
: to work. I’m now revisiting the driver to ensure that I’m getting access to
: all of my devices, which caused me to realize that even though the thing seems
: to work I don’t understand the setup I’ve done.

: Specifically in f3s_xxx_open.c, I have:

: socket->name = “enc”;
: socket->window_size = 0; // Docs say “0 for non-windowed”
: socket->address = FLASHADDR;
: socket->bus_width = 2;

I’m not sure why the docs indicate zero for non-windowed; perhaps that was
documented early in the development of the ffs. As I see it, the flash
filesystem treats all flash as windowed, where linear flash is simply
treated as one big window, and uses the default paging function, which
in that case does nothing.

Any time I’ve done a flash driver, I’ve always set the window size to the
total size of the flash array. In your case, if you have four 28F160’s, for a
total of 8M, you should put the following in your open function:

#define FLASHSIZE 0x800000
…

socket->window_size=FLASHSIZE;

and change the constant when you switch to the 28F320 parts.

To have the driver automatically detect the size and number of the parts
that you have installed on the board, you’ll need to insert some code into
the open function to probe the flash; just read the jedec ID’s to determine
which flash part is installed, and if you know the offsets that each chip
would reside at if it were installed, probe at each address range where the
flash part would sit.

For example, if you know the flash array would start at address 0x1000000
regardless, read the jedec ID at that address. Now that you know the size
of the parts installed, probe at the next address (0x1200000) accordingly.
Once you probe and don’t get back a jedec ID, you’ll know how many of the
parts are installed.

: The devices on my board are 4 Intel 28F160B3’s linearly and sequentially
: mapped, and they’re identified (at least one of them is), and things are just
: lovely if I set socket->window_size = 2. When I try to set it to zero, the
: call to mmap_device_memory() references socket->window_size for the size of
: memory to map in (which is zero) so needless to say the driver gets a segment
: violation and dies. My main question is how do I go about describing a
: non-windowed array that will be probed so as I can install either 2 or 4 of
: these 28F160’s or 28F320’s and it’ll “just figure it out”? The 160’s are
: 2-megabyte parts, the 320’s are 4-megabyte parts. Let me know if you need more
: details.

: Regards,
: -Warren

Dave Green (dgreen@qnx.com)

Custom Engineering Services
QNX Software Systems Ltd.
http://www.qnx.com

4

Warren Peece <warren@nospam.com> wrote:
: I’m not quite sure where to post this, so here it is :slight_smile:

: I’ve got an Nto 2.0 developer’s seat, with what I think is the latest release,
: and I’m trying to customize a FLASH filesystem driver for my embedded project.
: I started with devf-explr2 and had to modify very little in order to get things
: to work. I’m now revisiting the driver to ensure that I’m getting access to
: all of my devices, which caused me to realize that even though the thing seems
: to work I don’t understand the setup I’ve done.

: Specifically in f3s_xxx_open.c, I have:

: socket->name = “enc”;
: socket->window_size = 0; // Docs say “0 for non-windowed”
: socket->address = FLASHADDR;
: socket->bus_width = 2;


Ummm, from looking at our drivers I would suggest that socket->window_size
should be set to the maximum size of the linear flash array. i.e. in your
case it should be 8M (below I assume you mean 2M).

: The devices on my board are 4 Intel 28F160B3’s linearly and sequentially
: mapped, and they’re identified (at least one of them is), and things are just
: lovely if I set socket->window_size = 2. When I try to set it to zero, the
: call to mmap_device_memory() references socket->window_size for the size of
: memory to map in (which is zero) so needless to say the driver gets a segment
: violation and dies. My main question is how do I go about describing a
: non-windowed array that will be probed so as I can install either 2 or 4 of
: these 28F160’s or 28F320’s and it’ll “just figure it out”? The 160’s are
: 2-megabyte parts, the 320’s are 4-megabyte parts. Let me know if you need more
: details.


I believe you should be able to set the socket->window_size to the maximum size,
say 16M, and let the flash probing routines find the correct size if it happens
to be smaller (4 * 160 parts).

By the way, I could not find the reference to setting window_size to 0.

–
John

5

John Wall <jwall@qnx.com> wrote:

Warren Peece <> warren@nospam.com> > wrote:
: I’m not quite sure where to post this, so here it is > :slight_smile:

: I’ve got an Nto 2.0 developer’s seat, with what I think is the latest release,
: and I’m trying to customize a FLASH filesystem driver for my embedded project.

: Specifically in f3s_xxx_open.c, I have:

: socket->name = “enc”;
: socket->window_size = 0; // Docs say “0 for non-windowed”
: socket->address = FLASHADDR;
: socket->bus_width = 2;

By the way, I could not find the reference to setting window_size to 0.

I found a reference in the online docs:

Building Embedded Systems - Customizing the Flash Filesystem - Building
you flash filesystem driver - The main function - Socket services
interface

scroll down to the definition of f3s_socket_t. It’s in the comment.

–
John

6

“John Wall” <jwall@qnx.com> wrote in message news:8v3l86$53q$1@nntp.qnx.com…

| Ummm, from looking at our drivers I would suggest that socket->window_size
| should be set to the maximum size of the linear flash array. i.e. in your
| case it should be 8M (below I assume you mean 2M).
|
| I believe you should be able to set the socket->window_size to the maximum
size,
| say 16M, and let the flash probing routines find the correct size if it
happens
| to be smaller (4 * 160 parts).

When I set the FLASH_SIZE (and subsequently the window_size) to 16M, the drive
dies. If I restart it as “devf-enc &” I see: [1] + Memory fault devf-enc
This same behavior exists for any FLASH_SIZE value other than 2M. The
interesting part, is that when I start the driver as “devf-enc -vvvvv &” it
works. It produces a lot of output, but it appears to work fine. Is there any
way I can find out what the driver thinks it’s got for the number, type and
size of devices? I don’t believe the entire source code for f3s ships, I wish
I could see what all was being called when (good ol’ printf() debugging!). My
target is pretty limited on what it can do right now, until I get further along
on being able to install software on the FLASH drive. Suggestions?

-Warren

7

Warren Peece <warren@nospam.com> wrote:
: “John Wall” <jwall@qnx.com> wrote in message news:8v3l86$53q$1@nntp.qnx.com…

: | Ummm, from looking at our drivers I would suggest that socket->window_size
: | should be set to the maximum size of the linear flash array. i.e. in your
: | case it should be 8M (below I assume you mean 2M).
: |
: | I believe you should be able to set the socket->window_size to the maximum
: size,
: | say 16M, and let the flash probing routines find the correct size if it
: happens
: | to be smaller (4 * 160 parts).

: When I set the FLASH_SIZE (and subsequently the window_size) to 16M, the drive
: dies. If I restart it as “devf-enc &” I see: [1] + Memory fault devf-enc
: This same behavior exists for any FLASH_SIZE value other than 2M. The
: interesting part, is that when I start the driver as “devf-enc -vvvvv &” it
: works. It produces a lot of output, but it appears to work fine. Is there any


Does that mean it sees all 8 megs? Can you e-mail me the output?

: way I can find out what the driver thinks it’s got for the number, type and
: size of devices? I don’t believe the entire source code for f3s ships, I wish
: I could see what all was being called when (good ol’ printf() debugging!). My
: target is pretty limited on what it can do right now, until I get further along
: on being able to install software on the FLASH drive. Suggestions?


Actually you should have access to some interesting functions such as:

…/lib/f3s_flash_probe.c
…/mtd/flash-xxx/f3s_xxx_ident.c


\

John Wall

8

“John Wall” <jwall@qnx.com> wrote in message news:8v41bd$bib$1@nntp.qnx.com…

| Does that mean it sees all 8 megs? Can you e-mail me the output?

I don’t know how to determine if it sees all 8 meg or not.

| Actually you should have access to some interesting functions such as:
|
| ./lib/f3s_flash_probe.c
| ./mtd/flash-xxx/f3s_xxx_ident.c

I figured that the exit point of the probe routine would be a great place to
dump out what was found. Unfortunately things seem to be dying in the probe
routine itsself according to the trail of breadcrumbs (printfs) I’ve been
leaving. The disturbing thing, is that when I do the -vvvvv thing, it says
unto me: “–> chip_count = 32” Scary. I can send you the output, perhaps it
will mean something to you. Just looks like a lot of calloc/free debug lines
is all, although there are some cryptic lines here and there that you may be
interested in.

-Warren

9

Warren Peece <warren@nospam.com> wrote:

: “John Wall” <jwall@qnx.com> wrote in message news:8v41bd$bib$1@nntp.qnx.com…

: | Does that mean it sees all 8 megs? Can you e-mail me the output?

: I don’t know how to determine if it sees all 8 meg or not.


Ok, let’s break this down:

does it create a /dev/fs1 entry?
can you create a partition (i.e. flashctl -p/dev/fs1 -e -f)?
can you successfully copy files to the partition?

–
John Wall

10

Heh. It was already broken down, which is why I was trying to fix it. :wink:

It was bombing somewhere in f3s_flash_probe.c, I don’t know exactly where
because I gave up trying to decipher what was going on and wrote a replacement
function more specific for my hardware. That solved the fault problem and
uncovered a couple of other issues in the ident function (there are some dbase
entries that are incorrect). Plus I discovered that these 28F160C3 devices
power up in a locked state, so I added unlock code in the probe routine. If
the default ident dbase entries are fixed, the default probe routine will still
yield a read-only file system for these devices. I’m not sure where else one
would put the unlock code…

At any rate, it appears to be running well at this point. Thanks for the
help…

-Warren


“John Wall” <jwall@qnx.com> wrote in message news:8v44dm$d3m$1@nntp.qnx.com…
| Warren Peece <warren@nospam.com> wrote:
|
| : “John Wall” <jwall@qnx.com> wrote in message
news:8v41bd$bib$1@nntp.qnx.com…
|
| : | Does that mean it sees all 8 megs? Can you e-mail me the output?
|
| : I don’t know how to determine if it sees all 8 meg or not.
|
|
| Ok, let’s break this down:
|
| does it create a /dev/fs1 entry?
| can you create a partition (i.e. flashctl -p/dev/fs1 -e -f)?
| can you successfully copy files to the partition?
John Wall