Re: IPSM & P30
- From: "Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
- Date: Thu, 9 Feb 2006 09:29:22 -0700
Sure, you can set those parameters however you like. I see nothing wrong
with the changes that you made there, as long as they work right for you.
Now you just need to find a use for those small blocks (store your Easter
eggs there or something) ;-)
Paul T.
"turnsek" <turnsek@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:016BF819-F2D2-4603-90F1-E4877926BF3E@xxxxxxxxxxxxxxxx
Hi!
I have solved the problem regarding the IDs. Intel confirmed that some of
their oldest chips are having wrong IDs 8922 and they have corrected the
problem with the new flashes. This is not a big deal, we only had to
change
filename Flash_891C_2_32.dat to the Flash_8922_2_32.dat and chips are now
working with Jflashmm. Our hardware is OK, I just have one more question
about oem_info structure in PSM. You said that parameter blocks must not
be
in managed area in order of IPSM to work. This I understand, but what
about
physical start address and of course virtual start address. I have changed
the first 6 entries in oem_info to offset of one block (for the P30B
flash)
to exclude the paramter blocks and my boards are now working with
filesystem
area extended to the end of flash. Previous I had to take the last block
out
in order to work. Is this OK? Is that what you meant when you wrote that
parameter blocks should not be in managed area? See may tables bellow:
My flash chips are beggining with the address 0x98300000.
static const PSM_OEMInfo oem_info =
{
/* PhysicalReadStartAddress */ (VOID_PTR)0x00000000,
/* PhysicalWriteStartAddress */ (VOID_PTR)0x00000000,
/* PhysicalBurstReadStartAddress */ (VOID_PTR)0x00000000,
/* VirtualReadStartAddress */ (VOID_PTR)0x98300000,
/* VirtualWriteStartAddress */ (VOID_PTR)0xB8300000,
/* VirtualBurstReadStartAddress */ (VOID_PTR)0x98300000,
/* MaximumArrayLength */ 0x04000000,
/* MaximumRegistrySize */ 0x00080000,
/* ManagedAreaStart */ 0x01000000,
/* ManagedAreaLength */ 0x03000000, /* 48MB at our
disposal. */
/* ReadBusWidth */ 32,
/* WriteBusWidth */ 32,
/* BurstReadBusWidth */ 0
};
I chaged it to:
static const PSM_OEMInfo oem_info =
{
/* PhysicalReadStartAddress */ (VOID_PTR)0x00040000, /* 256KB
of offset */
/* PhysicalWriteStartAddress */ (VOID_PTR)0x00040000, /* 256KB
of offset */
/* PhysicalBurstReadStartAddress */ (VOID_PTR)0x00040000, /* 256KB
of offset */
/* VirtualReadStartAddress */ (VOID_PTR)0x98340000, /* 256KB
of offset */
/* VirtualWriteStartAddress */ (VOID_PTR)0xB8340000, /* 256KB
of offset */
/* VirtualBurstReadStartAddress */ (VOID_PTR)0x98340000, /* 256KB
of offset */
/* MaximumArrayLength */ 0x03FC0000, /* First 256KB
reserved for the bootloader. Otherwise PSM doesn't work with P30B. */
/* MaximumRegistrySize */ 0x00080000,
/* ManagedAreaStart */ 0x00FC0000,
/* ManagedAreaLength */ 0x03000000, /* 48MB at our
disposal. */
/* ReadBusWidth */ 32,
/* WriteBusWidth */ 32,
/* BurstReadBusWidth */ 0
};
to exclude paramter blocks.
Thanks, Jernej
"Paul G. Tobey [eMVP]" wrote:
You'll have to ask Intel about that, if you can confirm that the IDs are
really those being returned by the chips and not just caused by some
problem
with your boards. Those markings on the chips look like date codes to me
(when the chip was produced). The ID shouldn't change with the date
code,
but that doesn't mean that there isn't some problem with your assembly of
the boards. An open on a couple of the data lines, for example, might
cause
you to think that the ID is wrong...
Paul T.
"turnsek" <turnsek@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:84C2E329-EF9C-42E9-877A-6608B092A047@xxxxxxxxxxxxxxxx
I will post the question regarding last block failure to the Intel
premium
support, but meanwhile I am wondering about my other problem regarding
the
P30B flash chips.
We got 8 computer plates with PXA255 and P30B chips equiped and first
three
are working as I wrote earlier in my posts, but other five seems
returnig
different flash id as the first three. In the documentation is written
that
id should be 0x891C for the P30B, but I am getting 0x8922. I have
examined
all chips and found out that working three chips have different numbers
on
it
than not working ones. See bellow:
28F256P30B85 ESQDS0 Z5242060A -> OK
28F256P30B85 ESQDS0 Z5122039A -> NOT OK
What seems to be an issue here? Why do this chips have different ID's?
I have managed to change the name of Jflashmm flash file to support
this
chips and everything looks OK now, but the questions are still
standing. I
couldn't find anywhere specs about this ID codes.
Thanks, Jernej
"Paul G. Tobey [eMVP]" wrote:
I've given up trying to explain why PSM does anything (why was the
error
code list confidential for two years?, why isn't there a documented
interface to doing things like clearing the stored registry?, etc.)
You
*can* use the P30B chips and use their *total* length (I'm doing it),
as
long as the small block area isn't in the managed area. I don't know
what's
going on with your last-block thing, but my design doesn't have that
problem
(since I got rid of the P30T chips). Could be that you aren't adding
things
up right to total 64MB or something.
I'm sure it could be written better!
Paul T.
"turnsek" <turnsek@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:FC07379D-B47A-4A53-AD79-F154E311CE7C@xxxxxxxxxxxxxxxx
I have menaged to start the IPSM on P30B flash. The problem was that
I
had
managed area length set to 48MB which is the end of my flash chips.
This
works with J3C chips, but with P30B apparently not. I have shortened
the
length by one block size (ie 256KB) and the filesystem came alive.:)
I
tryed
P30T flash chips with the same settings (minus 256KB) and the
filesystem
worked too. So, what might be the case here? I think that IPSM is
checking
P30 inner geometry (written in flash) and finds two erase regions.
After
deciding which is the larger, it read out the number of blocks (for
28F256P30B number is 0xFE) and compares it with the user defined
settings
in
oem_info. Because in oem_info we had 0xFF blocks of length it must
return
error. I think IPSM code could be written better than it is.
Is there any logic in my findings? Please reashure me.
Thanks, Jernej
"Paul G. Tobey [eMVP]" wrote:
No, it works fine with the blocks in the reset state on Windows CE
entry.
What error code is reported by FD_Init? There's a document listing
the
error codes available from Intel Premier Support, which you should
have
access to because of your PSM purchase.
I'm using the same configuration: 4.2, 32-bit wide configuration,
PXA255.
The P30T chips don't work because of the smaller block sizes of the
last
four blocks (which PSM apparently doesn't understand), but the P30B
chips
in
the same configuration work fine, as long as the small blocks
aren't
in
the
managed area. You aren't using the *whole* flash for PSM, by any
chance,
are you?
Paul T.
"turnsek" <turnsek@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:4BC3E81D-8F6E-4167-B1ED-793891B37861@xxxxxxxxxxxxxxxx
Hi!
I am trying to migrate from 28F256J3C flash to the 28F256P30B
flash
and
I
have problems with the IPSM. It fails in FD_Init function after
boot. I
know
that P30 blocks are all in a locked state after power up and I
would
like
to
know if IPSM is doing unlock by itself or must I unlock it for
him
(e.g.
in
bootloader).
Has anybody migrate successfully?
PS: we have IPSM3.8 and Wince4.2, PXA255, two P30 chips in
parallel.
Thanks, Jernej
.
- References:
- Re: IPSM & P30
- From: Paul G. Tobey [eMVP]
- Re: IPSM & P30
- From: Paul G. Tobey [eMVP]
- Re: IPSM & P30
- From: turnsek
- Re: IPSM & P30
- From: Paul G. Tobey [eMVP]
- Re: IPSM & P30
- From: turnsek
- Re: IPSM & P30
- Prev by Date: Problem with break point
- Next by Date: Rename workspace?
- Previous by thread: Re: IPSM & P30
- Next by thread: Re: Support RTTI
- Index(es):
Relevant Pages
|
