Re: Intel PSM (IPSM) issue
- From: "Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
- Date: Mon, 23 Jan 2006 09:25:19 -0700
I think that the problem is likely to be the smaller blocks that are either
at the bottom, P30B, or the top, P30T, of the flash chips. Look at the
datasheet to see how some portions of the flash work differently in this
way. I know that, if you are using a 2x16 configuration to get 32-bit-wide
flash and if you are using P30T chips and the top small-block area is in the
IPSM managed area, PSM *will not work*. You can either arrange things so
that you leave out the are that has the smaller blocks in it, or switch to a
P30B chip where, presumably, the small blocks won't be in the PSM area.
Paul T.
<jollygreenfat@xxxxxxxxx> wrote in message
news:1138030344.190634.235800@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> I'm having troubles with integrating Intel PSM to use the P30 family of
> flash chips (2 32MB parts). Our platform previously used IPSM with
> J3/K3 parts (4 16MB chips), but due to supply issues, we've had to move
> to the P30s.
> The problem is that now IPSM seems to be crashing... following is a
> runthrough of our old setup, the new setup, and what the result it:
>
> ===============
>
> Original version:
> 4 16MB J(orK)3 chips, arranged in 2 banks (2x16 each) w/ 32-bit access
> Bank 1 (CS0): started at physical address 0x00000000, containing boot &
> nk.bin image code
> Bank 2 (CS1): started at physical address 0x04000000, used for PSM
> storage
> Therefore, there was a gap between the end address of Bank 1 & start of
> Bank 2, to allow for the potential of larger chips in the future
> PSM_OEMInfo values:
> /* PhysicalReadStartAddress */ (VOID_PTR)(0x04000000),
> /* PhysicalWriteStartAddress */ (VOID_PTR)(0x04000000),
> /* PhysicalBurstReadStartAddress */ (VOID_PTR)(0x04000000),
> /* VirtualReadStartAddress */ (VOID_PTR)(0xBC300000), //
> uncached virt. addr
> /* VirtualWriteStartAddress */ (VOID_PTR)(0xBC300000),
> /* VirtualBurstReadStartAddress */ (VOID_PTR)(0xBC300000),
>
> /* MaximumArrayLength */ 0x02000000, // 32M
>
> /* MaximumRegistrySize */ 0x00080000, // 512K registry
> size
> /* ManagedAreaStart */ 0x00800000, // beginning of
> the Application flash
>
> /* ManagedAreaLength */ 0x01800000,
>
> /* ReadBusWidth */ 32,
> /* WriteBusWidth */ 32,
> /* BurstReadBusWidth */ 0
>
> New version:
> 2 32MB P30 chips, arranged in one bank w/ 32-bit access
> To maintain the same memory map as the original, CS1 is redirected to
> the upper half of the bank's address range. Therefore, to the executing
> code, there is a still a gap between the lower 32MB and the upper 32MB,
> even though they are on the same bank.
> The usage of the memory addresses remain the same, as does the
> PSM_OEMInfo structure. The following is the error seen in PB4.1's KITL
> connection:
> 0 PID:0 TID:0 OEM Init: Initializing the Registry library...
> 0 PID:0 TID:0 OEM Init: Registry library initialized.
> 9 PID:0 TID:0 Sp=ffffc7d0
> 1039 PID:3c26002 TID:c3c20a62 OEMInterruptEnable:
> 1094 PID:83c1923e TID:83c1dfde Data Abort: Thread=83c19000
> Proc=809c5634 'filesys.exe'
> 1095 PID:83c1923e TID:83c1dfde AKY=00000003 PC=03fb12ec RA=0001e158
> BVA=04000000 FSR=00000007
>
> =================
>
> FWIW, I've done testing via the bootloader code & am able to
> erase/read/write both 32MB "halves" without issue, so it's not a matter
> of the physical connection, so to speak. My hunch is that artifically
> creating the gap between the bottom & top half of the bank is throwing
> IPSM for a loop, but not sure why. Any ideas are greatly appreciated...
>
.
- Follow-Ups:
- Re: Intel PSM (IPSM) issue
- From: jollygreenfat
- Re: Intel PSM (IPSM) issue
- References:
- Intel PSM (IPSM) issue
- From: jollygreenfat
- Intel PSM (IPSM) issue
- Prev by Date: Re: Managed c# code debug in PB/Ce5
- Next by Date: Re: generate eboot.nb0 problem
- Previous by thread: Intel PSM (IPSM) issue
- Next by thread: Re: Intel PSM (IPSM) issue
- Index(es):
Relevant Pages
|
