Re: Problems with Marvell PXA320 using CS0 and CS1

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Hi Paul,

thank you for your thoughts here. We will be looking into this together with
the OEM (as I said we need some help from the hardware guys here) and I'll
post the results.

Thanks for the meantime.

DB

"Paul G. Tobey [eMVP]" wrote:

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









.

Relevant Pages

  • Re: NeHe oddity
    ... access a big chunk of memory with all the caching issues that might ... And this memory being "hardware" makes this approach fast. ...
    (comp.graphics.api.opengl)
  • Re: High memory
    ... memory and then copy it up above 1MB...but if you want to put ... outside the CPU, memory is seen in a completely different light...this ... 1MB with "real mode memory" labelled on it or anything...the actual memory ... the system bus to actual hardware devices...hence, ...
    (alt.lang.asm)
  • Re: Crashes and the Blue Screen of Death!
    ... but the most common cause is hardware failure. ... The most common cause of this is hardware memory corruption. ... are listed on the Windows 2000 Hardware Compatibility List. ... recommended that all users install them as they become available. ...
    (microsoft.public.win2000.general)
  • Re: The variable bit cpu
    ... > However looking at the big picture the effort to scale fixed bit hardware ... those bits are kept in the opcode rather than in each memory ... And while a *few* applications might need to scale beyond 256 bits, ... And one *big* thing you're missing here is that have a variable-bit ...
    (alt.lang.asm)
  • SUMMARY: V880 crashes
    ... Almost all suggested it is hardware problem. ... Next day I got a call from SUN and SUN's engineer ... came and replaced two memory DIMMs. ... Second, call support. ...
    (SunManagers)