Re: Problems with Marvell PXA320 using CS0 and CS1
- From: "Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT com>
- Date: Mon, 3 Aug 2009 09:08:42 -0700
Yes, I was guessing that there might be a bug in the FPGA code. For
example, the sort of problem that might cause this is decoding an address in
the FPGA without qualifying that address with a chip-select signal from the
processor. For example, let's say that somewhere in the range of memory
that is now RAM, you used to have some hardware device (maybe just registers
implemented inside the FPGA, for example). If the decode for that device
was done just using a few of the bus address bits, it's quite possible that
you are now decoding all accesses to the second RAM area as accesses to
those registers. Further, since it's pretty common to not take all of the
address bits into account, those registers might be aliased all over the RAM
range now.
Paul T.
"DBarnett" <DBarnett@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:23378147-C372-405C-B1E6-A2A868A0C175@xxxxxxxxxxxxxxxx
Hi Paul,
appreciate your thoughts and help!
I will check with the hardware guys to find out if any other external
device
is pulling the RDY line.
When you talk about bug in the code, do you mean CE 6.0 kernel code or
FPGA/CPLD code?
Thanks
DB
"Paul G. Tobey [eMVP]" wrote:
I don't see how it could be anything other than data being sent to the
wrong
place, which sure seems like CS0's area being set to a size that doesn't
match the actual amount of memory, or CS1's base address being set to a
location too high or too low in memory. The caching clue would seem to
point to this. When caching is on, you get something back, presumably
the
something from the cache. When caching is off, the processor is trying to
access the data, but nothing is coming back from the bus.
You don't have some other external device besides memory that might be
pulling the READY (RDY), line to halt the processor, but never release it
because there's no real device at the location, do you? Maybe a
programmable device, FPGA or CPLD, from which RDY is an output? We do
this
for some slower peripherals. You'd expect it to eventually release the
bus,
but a bug in the code might cause something like this, I guess.
Paul T.
"DBarnett" <DBarnett@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:F400A2D7-0080-4907-A77C-24EF91E8BCDE@xxxxxxxxxxxxxxxx
Hi Paul,
Sorry, I should have been more precise there. We do have 256MB
connected
to
CS1 however we can only use 128MB (128MB are reserved for hardware)
hence
the
entry in the OEMAddressTable.
We have had several people check the configuration settings and we are
quite
sure that they are not the problem. Having said that, if something
doesn't
make sense please let us know.
Cheers
DB
"Paul G. Tobey [eMVP]" wrote:
Check the configuration registers for CS0 and CS1 and make sure that
things
like the length of the address space used are correct. Your
OEMAddressTable
there doesn't match what you told us about how much memory is
connected
to
CS1, too. Aren't both CS0 and CS1 supposed to point to 256MB
segments?
Paul T.
"DBarnett" <DBarnett@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:75D0CC3A-C10D-43EC-A575-4759579F51B2@xxxxxxxxxxxxxxxx
Hi,
we are currently developing a BSP for Marvell's PXA320.
One of the requirements is to support 512MB RAM. Due to temperature
constraints however this has to be split up into 256MB via CS0 and
256MB
via
CS1.
Our problem is, that we cannot correctly access the SDRAM via CS1,
neither
from Bootloader nor from the image (corrupt data).
- The first bank via CS0 works fine. With and without caching.
- If we have caching turned on we can write to the second bank (CS1)
but
we
get wrong values when reading from the second bank (CS1).
- If have caching turned off we can also write to the second bank
(CS1)
but
the target freezes when reading from the second bank (CS1).
We have double checked the configuration files and they are all
sound.
So my question is: Does anybody have experience using both chip
selects
CS0
and CS1 on the PXA320?
Following is some additional information:
OS: Windows Embedded CE 6.0 R2, latest QFE
Marvell PXA 320 with 512 MB noncontiguous RAM (128 reserved for
hardware)
Memory Controller has been set up for CS1
Configuration:
OEMAddressTable
DCD 0x80000000, 0x80000000, 256 ; X320.10 DDR SDRAM
/CS0(256
MB).
DCD 0x90000000, 0xC0000000, 128 ; X320.10 DDR SDRAM
/CS1(128
MB).
CONFIG.BIB
ARGS 80000000 00001000 RESERVED
NK 80001000 039ff000 RAMIMAGE
RAM_LOW_BANK 83A00000 0c600000 RAM ;256 MB CS 0
RAM_HIGH_BANK 90000000 08000000 RESERVED ;128 MB CS 1
OEMGetExtensionDRAM()
*lpMemStart = 0x90000000;
*lpMemLen = 0x08000000;
Thanks in advance for any assistance / hints or tips.
DB
.
- Follow-Ups:
- Re: Problems with Marvell PXA320 using CS0 and CS1
- From: DBarnett
- Re: Problems with Marvell PXA320 using CS0 and CS1
- References:
- Re: Problems with Marvell PXA320 using CS0 and CS1
- From: DBarnett
- Re: Problems with Marvell PXA320 using CS0 and CS1
- Prev by Date: Re: wince6.0 acess NTFS file system in a External HardDrive (or portable hard disk )
- Next by Date: Re: Trully unique variable in a driver
- Previous by thread: Re: Problems with Marvell PXA320 using CS0 and CS1
- Next by thread: Re: Problems with Marvell PXA320 using CS0 and CS1
- Index(es):
Relevant Pages
|
