Subject: Accessing DRAM on the EBSA-285 from PCI

From: Jonathan Foster Kliegman <[email-masked]>
Date: Tue, 19 Jan 1999 01:52:46 -0500 (EST)

Running a 2.1.131 on a EBSA-285 I recently ran into trouble when I
upgraded the DRAM to a 128 MB DIMM from the default 16 MB one.  I was
crashing on boot constantly when the Tulip driver reported a fatal bus
error (I was using NFS for the root).  Several printk's later, it ends
up that in:
   arch/arm/kernel/hw-ebsa285.c
there is a line:
   *(unsigned long *)0xfe000100 = 0x01fc0000;
which causes the 21285 core logic chip (acts as a memory controller for
the SA-110 and as a PCI-SA110_bus bridge) to only allow access to the
lower 32 MB of DRAM from the PCI bus.  The kernel was assigning buffers
from the top of DRAM for the tulip to use and it would get a master
abort attempting to access them.  For those with EBSA-285's, memory
address 0xfe000100 is the DRAM Base Address Mask Register in the 21285.

  I see two possible fixes for this problem:  

1)  Change the line to set it as high as possible.  The 21285 data sheet
has 256 MB (value = 0x0ffc0000) as the highest value listed.  This would
create a huge window but shold allow most anything.

2)  A more general solution would be to set this value dependant on the
actual memory installed.  This could be done either through a table
lookup or (I believe) bit-twiddling.

If neither fix is done, then I think a warning or documentation should
be included which mentions this problem.  It shouldn't be hard to add
into the boot sequence a 
  if ( (params->u1.s.nr_pages * params->u1.s.page_size) > (32*1024*1024) ) {
        printk("WARNING: The PCI bus will be unable to access the full " \
               "DRAM memory space.  Look in arch/arm/lib/hw-ebsa285.c  " \
               "for details!\n");
  }

Also, I have checked pre-patch 6 with the patch from Russel's site and
this line is unchanged.  

Finally, the bug-report form on the web page,
http://www.arm.uk.linux.org/~rmk/forms/solution.html
does not let you send the report you've filled out.

-Jon 
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Tue, 19 Jan 1999 10:20:48 +0100

>create a huge window but shold allow most anything.

I think that should be fine.  We ought to check the value of PCI_CFN in there 
and so long as it's set, we can pile in and set whatever values we like.  If 
it's clear then we shouldn't muck with any of the BARs at all.  The SDRAM 
window is actually 512MB aligned at the moment.

p.

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Tue, 19 Jan 1999 21:29:10 +0000 (GMT)

> window is actually 512MB aligned at the moment.

Correction: it would be better to tell the 21285 how much SDRAM you have so
that you can use it's features to catch out of bounds accesses which could
trample over the kernel.  The SDRAM window is actually at a fixed address
in PCI space and I don't see what 'at the moment' needs to be there. ;)
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Dave Baukus <[email-masked]>
Date: Mon, 25 Jan 1999 17:11:23 -0600

Who, where, what initializes the region of memory referenced by
PARAMS_BASE.

In arch/arm/kernel/setup.c we have:
	static struct params_struct *params = (struct params_struct *)PARAMS_BASE;

And for ebsa285 (my target platform platform) PARAMS_BASE is defined in
linux/include/asm-arm/arch-ebas285.h/hardware.h as
	#define PARAMS_OFFSET	0x100
	#define PARAMS_BASE 	(PAGE_OFFSET + PARAMS_OFFSET)

Why should I care ?
Because, I'm attempting to boot the ebsa285 from flash using the ebsa's boot
loader.
I get about as far as setup_pagetables() before things go south. 
It appears that my start_mem and  end_end are not initialized correctly.
It also appears that these variables are initialized via the 
params_struct which appears to be uninitialized.

Does the boot loader initialize this region of memory ?
If so can somebody send me the appropriate initial values ?

--
Dave Baukus
	Inet Inc. - R & D
	[email-masked]
	(972) 578 - 3930

---

From: Philip Blundell <[email-masked]>
Date: Tue, 26 Jan 1999 09:32:45 +0100

>Who, where, what initializes the region of memory referenced by

The bootloader is expected to do it.  If you don't have a bootloader or it 
doesn't understand the Linux params system, you need to tell setup.c not to
use the params structure.

>params_struct which appears to be uninitialized.

That sounds very likely.

>If so can somebody send me the appropriate initial values ?

You should be able to guess them for yourself.  The memory size is the most 
important one.

p.

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Tue, 26 Jan 1999 20:44:44 +0000 (GMT)

> use the params structure.

Which would not be a good idea since then you'd have to have your own
patch that required to be applied to my kernels.

> >params_struct which appears to be uninitialized.

start_mem is set up by the kernel internally.  It does not refer to the start
of memory, but to the start of free memory, typically located directly after
the running kernel.  You therefore only have to worry about end_mem.

You want to set up page_size to be 4096 and nr_pages to be
(your memory size)/4096.  Note, however, that the EBSA285 firmware does *not*
as far as I know (my firmware) detect the memory size and configure the 21285
to match the installed memory.

I do have a boot loader for Linux on the EBSA285 platform, but it's rather
limited at the moment - it supports 3com 3c59x, DEC Tulip (forgotten which
one(s)) and Promise UDMA33 (with UDMA configuration).

I'm still hoping to find some time (between Linux 2.2.0, work, sleep and hitting
Multitech over the head about their modems) to clean up the Promise UDMA driver
such that I can release the source code, but alas, something has always got in
the way over the last month.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]