dynamic memory detection

dynamic memory detection

[alfred hitch]

Hi All,

I am working on a IXDP425 based plattform,

If I understand it correctly there is no bios on it, and so for
physical memory on the system, redboot has to depend on constant /
#defines at compile time.

What if one wants to dynamically detect these ?
Why cannot we read the memory registers, while we are in redboot and
set up things accordingly ??

( I remember doing something similar while playing around in netbsd, 
from smbus via open i/o ports it used to read the memory rows,
coloumns etc and find out the size)

I am sure there is some glitch in doing this, and I am missing
something basic here,
can someone please correct me here.

Cheers,
Alfred

Re: dynamic memory detection

[Robin Randhawa]

Hi.

While I do not have any hands on experience with the IXDP425, your post
reminded me of some work I had done for another board (one based on the
AMD Elan SC520 micro) to which I was porting the u-boot bootloader. I
used SDRAM sizing algorithms to determine stuff like :

1. The number of external SDRAM banks
2. The bank geometry
3. Column widths etc.

The net result was that the total amount of SDRAM was detectable at
runtime.

I do not have any devel experience with redboot, but being a bootloader
of certain pedigree (its always been a great help), I wonder why SDRAM
sizing and detection is not an option myself. 

A bootloader would be expected to configure a board in preparation for
either an OS to take over safely or a standalone application. Either
ways, memory detection would be an added advantage and would not be too
costly in terms of the added footprint, which incidentally, would be one
of the concerns. The only issue could be the need for per-architecture,
per-processor support since SDRAM detection is quite a specific
technique, but eCos' beautifully modular design should easily allow
that.

Maybe the maintainers/developers would like to opine on this ?

Cheers,
Robin

On Tue, 2005-05-10 at 03:36 -0400, alfred hitch wrote:
> Hi All,
> 
> I am working on a IXDP425 based plattform,
> 
> If I understand it correctly there is no bios on it, and so for
> physical memory on the system, redboot has to depend on constant /
> #defines at compile time.
> 
> What if one wants to dynamically detect these ?
> Why cannot we read the memory registers, while we are in redboot and
> set up things accordingly ??
> 
> ( I remember doing something similar while playing around in netbsd, 
> from smbus via open i/o ports it used to read the memory rows,
> coloumns etc and find out the size)
> 
> I am sure there is some glitch in doing this, and I am missing
> something basic here,
> can someone please correct me here.
> 
> Cheers,
> Alfred
> 

Re: dynamic memory detection

[alfred hitch]

Hi Robin,

thanks for your reply,

but could u please give more details on ur SDRAM sizing algo ?
how were u doing that ?

then I will see if I can do the same on IXDP or not .. 
My fear is that I cannot as I was discussing with someone who has
worked extensively on x86 plattforms.
In there on northbridge there is a device generally which can be read
to find the size etc of dram ,

as of now I dont see any such stuff on ixp data sheet.

May be this is the reason that redboot etc dont have this as it might
not be a portable feature, but come to think of it, on boards where
one can, it should be implemented ?

can u tell how u did the sdram sizing thing ? I can infact choose
u-boot also as my bootloader that isnt the issue presently.

Alfred

On 5/10/05, Robin Randhawa <robin.randhawa@gmail.com> wrote:
> Hi.
> 
> While I do not have any hands on experience with the IXDP425, your post
> reminded me of some work I had done for another board (one based on the
> AMD Elan SC520 micro) to which I was porting the u-boot bootloader. I
> used SDRAM sizing algorithms to determine stuff like :
> 
> 1. The number of external SDRAM banks
> 2. The bank geometry
> 3. Column widths etc.
> 
> The net result was that the total amount of SDRAM was detectable at
> runtime.
> 
> I do not have any devel experience with redboot, but being a bootloader
> of certain pedigree (its always been a great help), I wonder why SDRAM
> sizing and detection is not an option myself.
> 
> A bootloader would be expected to configure a board in preparation for
> either an OS to take over safely or a standalone application. Either
> ways, memory detection would be an added advantage and would not be too
> costly in terms of the added footprint, which incidentally, would be one
> of the concerns. The only issue could be the need for per-architecture,
> per-processor support since SDRAM detection is quite a specific
> technique, but eCos' beautifully modular design should easily allow
> that.
> 
> Maybe the maintainers/developers would like to opine on this ?
> 
> Cheers,
> Robin
> 
> On Tue, 2005-05-10 at 03:36 -0400, alfred hitch wrote:
> > Hi All,
> >
> > I am working on a IXDP425 based plattform,
> >
> > If I understand it correctly there is no bios on it, and so for
> > physical memory on the system, redboot has to depend on constant /
> > #defines at compile time.
> >
> > What if one wants to dynamically detect these ?
> > Why cannot we read the memory registers, while we are in redboot and
> > set up things accordingly ??
> >
> > ( I remember doing something similar while playing around in netbsd,
> > from smbus via open i/o ports it used to read the memory rows,
> > coloumns etc and find out the size)
> >
> > I am sure there is some glitch in doing this, and I am missing
> > something basic here,
> > can someone please correct me here.
> >
> > Cheers,
> > Alfred
> >
> 
>

Re: dynamic memory detection

[Robin Randhawa]

Hi again.

On Wed, 2005-05-11 at 03:37 -0400, alfred hitch wrote:

> thanks for your reply,
> 
> but could u please give more details on ur SDRAM sizing algo ?
> how were u doing that ?
I would, but this is highly dependent on the SDRAM controller present on your board.

In my case the Elan SC520 microcontroller had an on-chip SDRAM
controller whose configuration registers were all nicely memory mapped
so there was no SMBUS, I2C or what-have-you, needed to configure it.

What I'm getting at is that the SDRAM sizing code I used would be pretty
useless for your board straight off. Its too tied down to the
controller. If you wish to get an idea of how this is done, you would
need to consult with the SDRAM controller manual for your board.

> then I will see if I can do the same on IXDP or not .. 
> My fear is that I cannot as I was discussing with someone who has
> worked extensively on x86 plattforms.
BTW, the ElanSC520 is core-compatible with a 386 (its actually an AMD
486DX clone). No north-bridge etc here though. Was fun coding for this
one.

> In there on northbridge there is a device generally which can be read
> to find the size etc of dram ,
> 
> as of now I dont see any such stuff on ixp data sheet.
> 
> May be this is the reason that redboot etc dont have this as it might
> not be a portable feature, but come to think of it, on boards where
> one can, it should be implemented ?
I am pretty sure that the redboot maintainers would have a very good reason not to include a feature.

However, like I said earlier, owing to eCos' neat modular design,
introducing a per-processor/per-architecture feature is quite do-able.

> can u tell how u did the sdram sizing thing ? I can infact choose
> u-boot also as my bootloader that isnt the issue presently.
In that case, I would request you to take this discussion offline since
it is going to be u-boot centric. I'll try and send you some information
offline soon.

Cheers,
Robin

> Alfred
> 
> On 5/10/05, Robin Randhawa <robin.randhawa@gmail.com> wrote:
> > Hi.
> > 
> > While I do not have any hands on experience with the IXDP425, your post
> > reminded me of some work I had done for another board (one based on the
> > AMD Elan SC520 micro) to which I was porting the u-boot bootloader. I
> > used SDRAM sizing algorithms to determine stuff like :
> > 
> > 1. The number of external SDRAM banks
> > 2. The bank geometry
> > 3. Column widths etc.
> > 
> > The net result was that the total amount of SDRAM was detectable at
> > runtime.
> > 
> > I do not have any devel experience with redboot, but being a bootloader
> > of certain pedigree (its always been a great help), I wonder why SDRAM
> > sizing and detection is not an option myself.
> > 
> > A bootloader would be expected to configure a board in preparation for
> > either an OS to take over safely or a standalone application. Either
> > ways, memory detection would be an added advantage and would not be too
> > costly in terms of the added footprint, which incidentally, would be one
> > of the concerns. The only issue could be the need for per-architecture,
> > per-processor support since SDRAM detection is quite a specific
> > technique, but eCos' beautifully modular design should easily allow
> > that.
> > 
> > Maybe the maintainers/developers would like to opine on this ?
> > 
> > Cheers,
> > Robin
> > 
> > On Tue, 2005-05-10 at 03:36 -0400, alfred hitch wrote:
> > > Hi All,
> > >
> > > I am working on a IXDP425 based plattform,
> > >
> > > If I understand it correctly there is no bios on it, and so for
> > > physical memory on the system, redboot has to depend on constant /
> > > #defines at compile time.
> > >
> > > What if one wants to dynamically detect these ?
> > > Why cannot we read the memory registers, while we are in redboot and
> > > set up things accordingly ??
> > >
> > > ( I remember doing something similar while playing around in netbsd,
> > > from smbus via open i/o ports it used to read the memory rows,
> > > coloumns etc and find out the size)
> > >
> > > I am sure there is some glitch in doing this, and I am missing
> > > something basic here,
> > > can someone please correct me here.
> > >
> > > Cheers,
> > > Alfred
> > >
> > 
> >
> 

Re: dynamic memory detection

[Andrew Lunn]

> May be this is the reason that redboot etc dont have this as it might
> not be a portable feature, but come to think of it, on boards where
> one can, it should be implemented ?

Its not normally a feature you need in deeply embedded systems. The
hardware is pretty fixed when you make your product. Having a DIMM
connection is not that normal since its added cost, space etc.  

Also the implementation of the algorithms is not that easy. You are
playing around with the memory controller which means you generally
cannot use the memory. So you have to implement the code in assembly
language using only the processors registers. 

The eCos architecture is flexible enough to allow this though. The
EBSA285 actually does detect the amount of RAM it has using such an
algorithm. So if this is something you really need, you have the
sources so feel free to implement it.

        Andrew

RE: dynamic memory detection

[Zimman, Chris]

Alfred,

In general, you can find what you're looking for via the SPD (Serial
Presence Detect) EEPROM on the DIMMs.  You read them via I2C, and they
contain the row and column info as well as timing for the DIMM.  You can
use this information to calculate the size of the DIMMs.  AFAIK, this
has been on all DIMM modules since SDRAM became standard.

The IXP425 has some restrictions on the DDR configurations it can
support, so this probably isn't that big of an issue for people
designing systems around it.

Here's a link for some further info on SPD:

http://www.simmtester.com/page/news/showpubnews.asp?num=101

Hopefully whoever did the board design wired the I2C bus through to the
DIMMs.

--Chris

-----Original Message-----
From: ecos-devel-owner@sources.redhat.com
[mailto:ecos-devel-owner@sources.redhat.com] On Behalf Of alfred hitch
Sent: Wednesday, May 11, 2005 3:38 AM
To: Robin Randhawa
Cc: ecos-devel@ecos.sourceware.org
Subject: Re: dynamic memory detection

Hi Robin,

thanks for your reply,

but could u please give more details on ur SDRAM sizing algo ?
how were u doing that ?

then I will see if I can do the same on IXDP or not .. 
My fear is that I cannot as I was discussing with someone who has
worked extensively on x86 plattforms.
In there on northbridge there is a device generally which can be read
to find the size etc of dram ,

as of now I dont see any such stuff on ixp data sheet.

May be this is the reason that redboot etc dont have this as it might
not be a portable feature, but come to think of it, on boards where
one can, it should be implemented ?

can u tell how u did the sdram sizing thing ? I can infact choose
u-boot also as my bootloader that isnt the issue presently.

Alfred

RE: dynamic memory detection

[Daly, Jeffrey]

This type of thing is highly dependent on the SDRAM controller and
knowing the CPU address decoding of the controller (which bits of the
CPU's physical addresses become COL/ROW/Bnk bits).  Then by configuring
the controller such that you can detect address wraparound by writing to
address boundaries to figure out the geometry of that bank.

>-----Original Message-----
>From: ecos-devel-owner@sources.redhat.com [mailto:ecos-devel-
>owner@sources.redhat.com] On Behalf Of alfred hitch
>Sent: Wednesday, May 11, 2005 3:38 AM
>To: Robin Randhawa
>Cc: ecos-devel@ecos.sourceware.org
>Subject: Re: dynamic memory detection
>
>Hi Robin,
>
>thanks for your reply,
>
>but could u please give more details on ur SDRAM sizing algo ?
>how were u doing that ?
>
>then I will see if I can do the same on IXDP or not ..
>My fear is that I cannot as I was discussing with someone who has
>worked extensively on x86 plattforms.
>In there on northbridge there is a device generally which can be read
>to find the size etc of dram ,
>
>as of now I dont see any such stuff on ixp data sheet.
>
>May be this is the reason that redboot etc dont have this as it might
>not be a portable feature, but come to think of it, on boards where
>one can, it should be implemented ?
>
>can u tell how u did the sdram sizing thing ? I can infact choose
>u-boot also as my bootloader that isnt the issue presently.
>
>Alfred
>
>On 5/10/05, Robin Randhawa <robin.randhawa@gmail.com> wrote:
>> Hi.
>>
>> While I do not have any hands on experience with the IXDP425, your
post
>> reminded me of some work I had done for another board (one based on
the
>> AMD Elan SC520 micro) to which I was porting the u-boot bootloader. I
>> used SDRAM sizing algorithms to determine stuff like :
>>
>> 1. The number of external SDRAM banks
>> 2. The bank geometry
>> 3. Column widths etc.
>>
>> The net result was that the total amount of SDRAM was detectable at
>> runtime.
>>
>> I do not have any devel experience with redboot, but being a
bootloader
>> of certain pedigree (its always been a great help), I wonder why
SDRAM
>> sizing and detection is not an option myself.
>>
>> A bootloader would be expected to configure a board in preparation
for
>> either an OS to take over safely or a standalone application. Either
>> ways, memory detection would be an added advantage and would not be
too
>> costly in terms of the added footprint, which incidentally, would be
one
>> of the concerns. The only issue could be the need for
per-architecture,
>> per-processor support since SDRAM detection is quite a specific
>> technique, but eCos' beautifully modular design should easily allow
>> that.
>>
>> Maybe the maintainers/developers would like to opine on this ?
>>
>> Cheers,
>> Robin
>>
>> On Tue, 2005-05-10 at 03:36 -0400, alfred hitch wrote:
>> > Hi All,
>> >
>> > I am working on a IXDP425 based plattform,
>> >
>> > If I understand it correctly there is no bios on it, and so for
>> > physical memory on the system, redboot has to depend on constant /
>> > #defines at compile time.
>> >
>> > What if one wants to dynamically detect these ?
>> > Why cannot we read the memory registers, while we are in redboot
and
>> > set up things accordingly ??
>> >
>> > ( I remember doing something similar while playing around in
netbsd,
>> > from smbus via open i/o ports it used to read the memory rows,
>> > coloumns etc and find out the size)
>> >
>> > I am sure there is some glitch in doing this, and I am missing
>> > something basic here,
>> > can someone please correct me here.
>> >
>> > Cheers,
>> > Alfred
>> >
>>
>>