OK, I’ll wait for the new rev of hardware.
Thanks.
Chris,
Based on what the output shows, the driver has correctly
identified everything, but the 25 bit bus limitation
is causing grief:
devf: chip total = 1
devf: bus width = 4
devf: chip interleave = 2
devf: fs0 array CFI U: 100 S: 040000
The chip total of 1 means that logically, from the driver’s
perspective, there is only one flash chip (i.e. all flash is
controlled by a single chip select), even though physically,
there are two 16 bit wide chips, two-way interleaved, for a
total of 32 bits (or 4 bytes) bus width. the U: value (100)
represents the number of blocks (in hex), and the S: value
represents the block size, also in hex. 0x100 * 0x40000 == 256
blocks of 256k each, for a total of 64M.
So, the driver has correctly identified the flash, but when
it tries to access it, the 25 bit address bus limitation is
causing problems. If the same two flash parts were wired
differently, things might be OK. For example, if there was
a single 16 bit wide, 32M part, controlled by chip select x, mapped
to 0xfc000000, and a second 32M part, controlled by chip select y,
at 0xfe000000, you could specify 0xfe000000 as the start address,
and the first (lower) chip would be ignored completely. However,
as it stands now, you’re asking the driver to only recognize
half of what it sees logically as a single 64 Meg flash chip.
If command line overrides for arraysize, unitsize, etc. don’t do
it, then you might be able to hack up the mtd source to make this
work, but there could be lots of places where modifications
need to be made.
If you don’t desperately need flash storage right now,
I’d wait another month, until you have hardware that can
address all of the flash. The only other thing I can think
to try would be to temporarily disable the flash chip that’s
wired to D16 - D31, perhaps by pulling up the CS# pin…
Chris Fischer <> cfischer@harris.com> > wrote:
We have a hardware reason why we can only access half of flash.
The powerPC 5200 only drives 25 bits on the boot chip select (unless
you are in large flash mode, which we aren’t). So that means we can
only access 32MB. Hence my only telling it up half of flash. I’ve
tried telling it about 64MB starting at 0xfe000000, but that hangs, I
assume
something from wrapping past the top of memory.
With the hardware issue, Flash has 2 copies present, at 0xfc000000, and
at
0xfe000000.
I’m assuming with 2 copies, I might legitimately get 2 mountpoints. I
setup
the chip
selects to only start show us 0xfe000000.
We do have new hardware that will allow us to access all of flash in
another
month.
I’ve suspected part of the reason is that it is reading the flash size
from
the flash itself, like you said. Is this a place I can modify the code
to
tell
it it is a smaller flash until we get the new hardware?
More replies in-line:
“Dave Green” <> dgreen@qnx.com> > wrote in message
news:c1kuq2$gvo$> 1@inn.qnx.com> …
Chris,
The flash driver determines the correct size and partition
information based not only on the arguments that you pass to
it, but also on the information it gets from probing the flash
itself. If you try to “trick” the flash driver by giving it
incorrect information about the flash size and offset, then it
can’t be expected to determine the correct partition information,
etc. I’d suggest the following:
-rather than using flash drivers for other, specific boards,
like devf-artesyn, devf-mgt5200, etc., use devf-generic.
Board specific flash drivers are normally created when there
is ‘extra’ stuff that needs to be done to the flash (such as
toggling a board-specific GPIO line to enable flash writing).
These drivers are created only in the case where devf-generic
can’t be used, such as for the reason described above.
-tell devf-generic the correct flash offset and size. If you
don’t want to use a portion of the flash, you can use the flashctl
utility once you have correctly detected the flash, to create
your partitions wherever in flash you’d like, and to avoid
using the areas of flash that you don’t want to use.
Based on the contents of your last two posts, you have a total
of 64M of flash, from 0xfc000000 to 0xffffffff. Try the following:
devf-generic -s0xfc000000,64M -vvvvv
I ran this, devf_generic hasn’t worked (this is devf-artesyn with a
fix for unlocking intel flash blocks) - :
devf-jtrs -s 0xfe000000,32m -vvvv -fix > /tmp/y.y
once this is done, please post the output for:
chip total
bus width
chip interleave
devf: chip total = 1
devf: bus width = 4
devf: chip interleave = 2
U:
S:
For U: and S:, do you mean these?:
devf: fs0 array CFI U: 100 S: 040000
devf: fs0p2 boot P[20] U: 0C
devf: fs0p3 boot P[2C] U: 10
devf: fs0p4 raw U: 04
devf: fs0p5 boot P[40] U: 04
devf: fs0p6 raw U: 48
devf: fs0p7 boot P[8C] U: 14
devf: fs0p8 boot P[A0] U: 0C
devf: fs0p9 boot P[AC] U: 10
devf: fs0pA raw U: 04
devf: fs0pB boot P[C0] U: 04
devf: fs0pC raw U: 3C
and also, post the output for the following:
ls -ls /dev/fs*
ls /dev
console fs0p2 fs0p7 fs0pC profiler text
dbgmem fs0p3 fs0p8 io-net ser1 zero
fs0 fs0p4 fs0p9 mem shmem
fs0p0 fs0p5 fs0pA null slog
fs0p1 fs0p6 fs0pB pipe socket
If everything is correctly detected, then you can proceed to
create your partitions however you like, using flashctl. If
things aren’t detected correctly, further parameters can be
passed to devf-generic, to ‘force’ certain known parameters,
such as bus witdh, interleave, etc.
Chris Fischer <> cfischer@harris.com> > wrote:
I’m having a problem where I get multiple mountpoints from devf
when I only tell it about a fraction of flash (i.e. one half or one
quarter).
It looks like this:
df
/dev/fs0p9 7680 33 7646 1%
/
/dev/fs0p3 7680 33 7646 1%
/
/dev/fs0pB 1536 0 1535 0%
/test
/dev/fs0p5 1536 0 1535 0%
/test
/dev/fs0p8 5632 2672 2959 48%
/bin
/dev/fs0p2 5632 2672 2959 48%
/bin
/dev/fs0p7 10240 5283 4956 52%
/usr/lib
/dev/fs0p1 10240 5283 4956 52%
/usr/lib
At first I assumed it was a problem with our hardware, but today I
figured
out that it is a function of how much flash I don’t tell devf exists.
For
instance,
if I tell it about half of flash, I get 2 mountpoints per filesystem.
If I
tell it
about one quarter, I get 4. I’ve gone so far as to tell it about
only
1MB
of
my 64MB, and got 64 mountpoints! So it seems to be inversely
related,
1/n,
where n is the number of mountpoints.
For instance, with this:
devf-jtrs -s 0xfe000000,32M,0,32M,256k -fix -r -b5 -u2 -t1
I get 2 mountpoints per, and with this:
devf-jtrs -s 0xfe000000,16M,0,16M,256k -fix -r -b5 -u2 -t1
I get 4 mountpoints per.
After discovering this, I found I could do the same thing with my
Icecube
reference board:
df
/dev/fs0p3 4992 1052 3939 22% /
/dev/fs0p2 2432 1919 512 79% /bin
/dev/fs0p1 3072 2634 437 86% /usr/lib
flashctl -p /dev/fs0p3 -x
devf-mgt5200 -s 0xff980000,4m
df
/dev/fs0p5 2432 1919 512 79% /bin
/dev/fs0p2 2432 1919 512 79% /bin
/dev/fs0p1 3072 2634 437 86% /usr/lib
ls /dev
console fs0p2 fs0p7 pipe socket
dbgmem fs0p3 io-net profiler text
fs0 fs0p4 mem ser1 tty
fs0p0 fs0p5 null shmem zero
fs0p1 fs0p6 pci slog
And /bin appeared twice when I told the driver about 1/2 of the
flash.
I suspect /usr/lib didn’t because it wasn’t fully in the 4MB region.
Any ideas why this is happening? Can anyone else replicate this?
I am running 6.2.1B with a PowerPC 5200.
\
David Green (> dgreen@qnx.com> )
QNX Software Systems Ltd.
http://www.qnx.com