Memory map with "holes"...

Memory map with "holes"...

[David Jander]

Hi all,

We are designing a board based on the MPC852T (MPC866 serivate), and
I want to make sure there is the possibility to mount different-size
SDRAM chips on it, so I just connect the two bank-select pins to some
higher address lines, leaving some out in between, in order to acomodate
for bigger chips in the future. The bottom line is that I will get the
memory map split up into 4 segments with vast holes between each segment
that are undefined. What do I need to keep in mind regarding linux
about this? I suppose it isn't an issue, but I want to be sure I don't
get any trouble later. Any experience with memory holes? I suppose the
boot-loader should tell the kernel about the memory-map, in a way just
like lilo on an x86 machine, am I right? Does this work the same way on
linux-ppc ?

Greetings,

--
David Jander
Protonic Holland.
tel.: +31 (0) 229 212928
fax.: +31 (0) 229 210930
Factorij 36 / 1628 AL Zwaag

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Memory map with "holes"...

[Wolfgang Denk]

In message <200308121432.09782.david.jander@protonic.nl> you wrote:
>
> We are designing a board based on the MPC852T (MPC866 serivate), and
> I want to make sure there is the possibility to mount different-size
> SDRAM chips on it, so I just connect the two bank-select pins to some
> higher address lines, leaving some out in between, in order to acomodate
> for bigger chips in the future. The bottom line is that I will get the
> memory map split up into 4 segments with vast holes between each segment
> that are undefined. What do I need to keep in mind regarding linux
> about this? I suppose it isn't an issue, but I want to be sure I don't

This is not an issue, as Linux does not care about  the  organization
of  your  memory.  It  just  expects some amount of contiguous memory
stating at address 0.

> get any trouble later. Any experience with memory holes? I suppose the
> boot-loader should tell the kernel about the memory-map, in a way just
> like lilo on an x86 machine, am I right? Does this work the same way on

No. There will not be any "holes". It is up  to  your  bootloader  to
program  the  memory controller of the MPC8xx such that there is just
one contiguous piece of memory. See U-Boot for example code how to do
that (including auto-sizing routines and all the rest).

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Success in marriage is not so much finding the right person as it  is
being the right person.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Memory map with "holes"...

[David Jander]

On Tuesday 12 August 2003 16:13, Wolfgang Denk wrote:
> In message <200308121432.09782.david.jander@protonic.nl> you wrote:
> > We are designing a board based on the MPC852T (MPC866 serivate), and
> > I want to make sure there is the possibility to mount different-size
> > SDRAM chips on it, so I just connect the two bank-select pins to some
> > higher address lines, leaving some out in between, in order to acomodate
> > for bigger chips in the future. The bottom line is that I will get the
> > memory map split up into 4 segments with vast holes between each segment
> > that are undefined. What do I need to keep in mind regarding linux
> > about this? I suppose it isn't an issue, but I want to be sure I don't
>
> This is not an issue, as Linux does not care about  the  organization
> of  your  memory.  It  just  expects some amount of contiguous memory
> stating at address 0.

AFAIK this is exactly what I do _not_ get.
I wanted to connect the bank select lines BA0 and BA1 of the SDRAM chips to A6
and A5 respectively, and use only one CS (Chip-Select).

> > get any trouble later. Any experience with memory holes? I suppose the
> > boot-loader should tell the kernel about the memory-map, in a way just
> > like lilo on an x86 machine, am I right? Does this work the same way on
>
> No. There will not be any "holes". It is up  to  your  bootloader  to
> program  the  memory controller of the MPC8xx such that there is just
> one contiguous piece of memory. See U-Boot for example code how to do
> that (including auto-sizing routines and all the rest).

I saw different examples (tqm8xx.c for instance), but the only thing they seem
to do is program the memory controller in a way that all CS's map the whole
RAM on a contiguous block.
What I pretend to do is something like this:
Memory mapped on CS0:
Region                  What
--------------------------------
0x00000000-0x007fffff   RAM
0x00800000-0x01ffffff   invalid
0x02000000-0x027fffff   RAM
0x02800000-0x03ffffff   invalid
0x04000000-0x047fffff   RAM
0x04800000-0x05ffffff   invalid
0x06000000-0x067fffff   RAM

So it would not be possible to use the memory controller to make a contiguous
block out of this. But maybe the kernel could be told to declare the ranges
marked as "invalid" to be, well, invalid. With a MMU this should not matter,
only the kernel must know what to do.

For example I found in /arch/ppc/init.c, in the function set_phys_avail(),
this piece of code:

phys_avail.regions[0].address = PPC_MEMSTART;
phys_avail.regions[0].size = total_memory;
phys_avail.n_regions = 1;

This looks fairly easy to modify, but I wonder why nobody seems to use more
than one region in linux-ppc??
What's the policy? To not use this?
Am I the only one who wants something like this?
Should I start implementing this myself on u-boot and linux-ppc ('cause I
believe in this case you'd have to give linux a map from the boot-loader), or
should I better restrict my design to contiguous blocks of RAM only (this
would make me waste 4 CS lines, and unnecessarily complex hardware)?

Sincerely,

--
David Jander
Protonic Holland.
tel.: +31 (0) 229 212928
fax.: +31 (0) 229 210930
Factorij 36 / 1628 AL Zwaag

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Memory map with "holes"...

[Wolfgang Denk]

In message <200308121700.11708.david.jander@protonic.nl> you wrote:
>
> I wanted to connect the bank select lines BA0 and BA1 of the SDRAM
> chips to A6 and A5 respectively, and use only one CS (Chip-Select).

Arghhhh... don't do that.

> What I pretend to do is something like this:
> Memory mapped on CS0:
> Region                  What
> --------------------------------
> 0x00000000-0x007fffff   RAM
> 0x00800000-0x01ffffff   invalid
> 0x02000000-0x027fffff   RAM
> 0x02800000-0x03ffffff   invalid
> 0x04000000-0x047fffff   RAM
> 0x04800000-0x05ffffff   invalid
> 0x06000000-0x067fffff   RAM

You will not get lucky with such a design, for several reasons.

CS0 is the boot device. RAM will not work on CS0.

Second, you make your design unecessarily  complicated.  Attach  each
bank  of  RAM  to  nother CS, and let the memory controller map it as
needed.

> marked as "invalid" to be, well, invalid. With a MMU this should not
> matter, only the kernel must know what to do.
>
> For example I found in /arch/ppc/init.c, in the function
> set_phys_avail(), this piece of code:
>
> phys_avail.regions[0].address = PPC_MEMSTART; regions[0].size =
> phys_avail.total_memory; n_regions = 1;
>
> This looks fairly easy to modify, but I wonder why nobody seems to use
> more than one region in linux-ppc??

Why make a design more complicated than necessary?

> What's the policy? To not use this?
> Am I the only one who wants something like this?

>From what I've seen so far: yes. All boards I've seen allowed to  map
the system RAM as one contiguous area.

> Should I start implementing this myself on u-boot and linux-ppc ('cause I

Note that U-Boot does not use the MMU.

> should I better restrict my design to contiguous blocks of RAM only
> (this would make me waste 4 CS lines, and unnecessarily complex
> hardware)?

I would prefer such a design, but hey, I'm a software  developer  and
I'm  supposed  to  bring  up  requirements  that  make  life  it more
difficult to the hardware guys :-)

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"It is easier to port a shell than a shell script."      - Larry Wall

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Memory map with "holes"... (slightly off-topic)

[David Jander]

Hi Conn,

Thank you for the tip. AFAICS, you plan on using the only two 32-bit wide
chips available in the same package from Micron. Fortunately, these have the
same size of columns, and that makes things easy.
At first we thought this trick wouldn't work with our design, since we plan on
designing for 4 different 16-bit wide chips in TSOP-54 housing, using always
2 of them to get a 32-bit bus. The reason: TSOP-54, 16-bit wide chips seem to
be one of the most popular formats out there, used by most important SDRAM
manufacturers, and for us it is vital to ensure we always get second sources
for several years to come. The Micron types are MT48LC4M16A2 for the
smallest, and 8M16, 16M16 up to 32M16 types. The problem is, that for these 4
types you get 3 different column sizes and 2 different row sizes. Dealing
with 3 different column sizes makes things a little tricky, but it is
possible, and after playing around a little bit, we got to the following
solution:
SDRAM A[9:0] are connected straight to CPU A[20:29] and are muxed.
SDRAM A10 connected to GPL0 that will be programmed to work as either A11 (for
the 4M16 types), A10 (for the 8M16 and 16M16) or A5 (for the 32M16).
SDRAM A11 connected to either A10 (for 4M16) or A7 (for the rest) selectable
via two 0-Ohm resistors (place one or the other).
Finally SDRAM A12 connects to CPU A6 and the bank select lines BA0 and BA1 go
to CPU A9 and A8 respectively.
You'll get half crazy checking this, but I believe it must work, it uses only
one CS line (certainly not CS0, sorry for the mistake, Wolfgang ;-), and
makes linux happy with one contiguous block of RAM always.

Sincerely,

--
David Jander
Protonic Holland.
tel.: +31 (0) 229 212928
fax.: +31 (0) 229 210930
Factorij 36 / 1628 AL Zwaag

On Tuesday 12 August 2003 19:02, you wrote:
>
>  It is possible to design a system to accomidate larger ram chips for
> future expansion with out leaving holes in your memory map. We did
> this on our ESTeem 192E. What you need to do is design your memory
> system around the samllest chip in the memory family you intend
> to use. connect the bank selects lines to the address immediately
> following the highest address line used by the smallest memory part.
> Then following the bank selects place the other address lines to the
> larger memory parts
>
> This is how we did ours ( and it works with the larger parts )
>
> We designed our board using a Micron part MT48LC2M32B2. But we
> decieded to include an extra clock cycle so we could use other
> manufacturers parts, Such as Toshiba TC59S6432CFT and Samsung
> K4S643232C(not tested)
>
> Micron has said that they will make a bigger parts in the same foot
> print.
>
> This is how we hooked up our ram to make provisions for the larger
> parts. (Note that the two additional address lines have an * next to
> them)
>
> MPC850                    SDRAM
> =============================
> A29                        A0
> A28                        A1
> A27                        A2
> A26                        A3
> A25                        A4
> A24                        A5
> A23                        A6
> A22                        A7
> A13                        A8
> A12                        A9
> GPL_A0                     A10
> *A8                        A11 (pin 71)
> *A7                        A12 (pin 69)
> A10                        BA0
> A9                         BA1
> OE_GPL_A1                  RAS
> GPL_A2                     CAS
> GPL_A3                     WE
>
> This design will probably work with little modification on all of the
> MPC860 family.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Shall I use which IRQ as input parameter of this function?

[John Zhou]

Dear all,

I have a device with interrupt pin connecting to MPC8250's IRQ0( nonmaskable interrupter ),  when I use function " request_8xxirq( IRQx, tem_interrupt, 0, "temp", dev) " to register IRQ, but I only find SIU_INT_IRQ1-SIU_INT_IRQ7 in file <asm/irq.h> and can't find SIU_INT_IRQ0.  Shall I use which IRQ as input parameter of this function?

Thanks in advance!
John Zhou

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Memory map with "holes"... (slightly off-topic)

[Conn Clark]

Hi David,

	I'm glad to see you get the general principal behind the trick. I was
afraid I was going to get mailed data sheets and asked to design it for
you (Note: this has happened). I didn't know you pland on using chips
with differing column sizes, however you have seem to found a solution
to make it work. My hat off to you.

	Now the real challenge begins trying to program the UPM and figuring
out how to detect which memory config you have. I pretty sure that
variable columns will require different UPM programmings. Figguring out
the UPM was the toughest part of the design for us. A good BDM/JTAG
debugger is worth its weight in gold for this. A nice logic analyzer
wouldn't hurt either.

Good Luck,

	Conn
PS.

	Actauly in our design we planned on using different three chips sizes,
its just the largest isn't being built yet. We also found 4 other
manufacturers that made drop in replacements for the MT48LC2M32B2. The
only difference is they just had a higher CS latency and a slightly
diffent but compatible mode register programing sequence.

David Jander wrote:
>
> Thank you for the tip. AFAICS, you plan on using the only two 32-bit
> wide chips available in the same package from Micron. Fortunately,
> these have the same size of columns, and that makes things easy. At
> first we thought this trick wouldn't work with our design, since
> we plan on designing for 4 different 16-bit wide chips in TSOP-54
> housing, using always 2 of them to get a 32-bit bus. The reason:
> TSOP-54, 16-bit wide chips seem to be one of the most popular formats
> out there, used by most important SDRAM manufacturers, and for us it
> is vital to ensure we always get second sources for several years
> to come. The Micron types are MT48LC4M16A2 for the smallest, and
> 8M16, 16M16 up to 32M16 types. The problem is, that for these 4
> types you get 3 different column sizes and 2 different row sizes.
> Dealing with 3 different column sizes makes things a little tricky,
> but it is possible, and after playing around a little bit, we got
> to the following solution: SDRAM A[9:0] are connected straight to
> CPU A[20:29] and are muxed. SDRAM A10 connected to GPL0 that will be
> programmed to work as either A11 (for the 4M16 types), A10 (for the
> 8M16 and 16M16) or A5 (for the 32M16). SDRAM A11 connected to either
> A10 (for 4M16) or A7 (for the rest) selectable via two 0-Ohm resistors
> (place one or the other). Finally SDRAM A12 connects to CPU A6 and the
> bank select lines BA0 and BA1 go to CPU A9 and A8 respectively. You'll
> get half crazy checking this, but I believe it must work, it uses only
> one CS line (certainly not CS0, sorry for the mistake, Wolfgang ;-),
> and makes linux happy with one contiguous block of RAM always.

--

*****************************************************************
   If you live at home long enough, your parents will move out.
  (Warning they may try to sell their house out from under you.)
*****************************************************************

Conn Clark
Engineering Stooge				clark@esteem.com
Electronic Systems Technology Inc.		www.esteem.com

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/