[U-Boot-Users] post memory test

[U-Boot-Users] post memory test

[Dongying_Xu at us.alphanetworks.com]

Hi,

I have a question about post memory test. According to the following code, 
even if memory size is greater than 256M, only 256M memory will be tested. 
 Is it true or I missed something.  Thanks a lot. 

In U-BOOT-1.2.0 
u-boot\post\drivers\memory.c,

int memory_post_test (int flags)
{
        int ret = 0;
        DECLARE_GLOBAL_DATA_PTR;
        bd_t *bd = gd->bd;
        unsigned long memsize = (bd->bi_memsize >= 256 << 20 ?
                                 256 << 20 : bd->bi_memsize) - (1 << 20);

        if (flags & POST_SLOWTEST) {
                ret = memory_post_tests (CFG_SDRAM_BASE, memsize);
        } else {                        /* POST_NORMAL */

                unsigned long i;

                for (i = 0; i < (memsize >> 20) && ret == 0; i++) {
                        if (ret == 0)
                                ret = memory_post_tests (i << 20, 0x800);
                        if (ret == 0)
                                ret = memory_post_tests ((i << 20) + 
0xff800, 0x800);
                }
        }

        return ret;
}

Best Regards
dongy



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20071112/8adf4bab/attachment.htm 

[U-Boot-Users] post memory test

[Detlev Zundel]

Hi Dongy,

> I have a question about post memory test. According to the following code, even
> if memory size is greater than 256M, only 256M memory will be tested.  Is it
> true or I missed something.  Thanks a lot.

No, this is true.  As I did not write that code, my interpretation
uses some speculation, but what is very likely the case here is that
U-Boot potentially does not map all physical available memory and thus
we cannot even access it.  As we do not have explicit variables
representing those facts, I guess the 256MB are kind of a least
common denominator.

As an example look at initdram() in board/Marvell/db64460/sdram_init.c
where the platform uses Block Address Translations (BATs) to map RAM
but exhausts these pretty scarce ressources and limits itself to
mapping only the first 256MB (a usual limit for a BAT).

> In U-BOOT-1.2.0
> u-boot\post\drivers\memory.c,

A word to version 1.2.0, if you have a platform with 256MB+ memory,
please be sure to check the fix from Aug 25 by Yuri Tikhonov "POST:
limit memory test area to not touch global data anymore" (9c02defc) in
the current code as the code in 1.2.0 caused problems on such systems.

Cheers
  Detlev

-- 
When you  loosen yourself from  all the obvious delusions  - religion,
ideology,  Communism - you're  still left  with the  myth of  your own
goodness. Which is the final delusion.
                                          -- Philip Roth
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot-Users] post memory test

[Jens Gehrlein]

Detlev Zundel wrote:
> Hi Dongy,
> 
>> I have a question about post memory test. According to the following code, even
>> if memory size is greater than 256M, only 256M memory will be tested.  Is it
>> true or I missed something.  Thanks a lot.
> 
> No, this is true.  As I did not write that code, my interpretation
> uses some speculation, but what is very likely the case here is that
> U-Boot potentially does not map all physical available memory and thus
> we cannot even access it.  As we do not have explicit variables
> representing those facts, I guess the 256MB are kind of a least
> common denominator.
> 
> As an example look at initdram() in board/Marvell/db64460/sdram_init.c
> where the platform uses Block Address Translations (BATs) to map RAM
> but exhausts these pretty scarce ressources and limits itself to
> mapping only the first 256MB (a usual limit for a BAT).

So it is possible to overlay the function memory_post_test() by a
board specific routine, which may cover almost all RAM?

BTW, is it possible to overlay _all_ POST routines by board specific
routines?

Kind regards
    Jens

[U-Boot-Users] post memory test

[Wolfgang Denk]

In message <473D9B54.1010304@tqs.de> you wrote:
>
> > As an example look at initdram() in board/Marvell/db64460/sdram_init.c
> > where the platform uses Block Address Translations (BATs) to map RAM
> > but exhausts these pretty scarce ressources and limits itself to
> > mapping only the first 256MB (a usual limit for a BAT).
> 
> So it is possible to overlay the function memory_post_test() by a
> board specific routine, which may cover almost all RAM?

Everything is possible - this is software, so anything can be done.
You can even make pigs fly. But not everything does make sense.

> BTW, is it possible to overlay _all_ POST routines by board specific
> routines?

It could be done, but I consider it a very, very bad idea.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
When all else fails, read the instructions.

[U-Boot-Users] post memory test

[Jens Gehrlein]

Wolfgang Denk schrieb:
> In message <473D9B54.1010304@tqs.de> you wrote:
>>> As an example look at initdram() in board/Marvell/db64460/sdram_init.c
>>> where the platform uses Block Address Translations (BATs) to map RAM
>>> but exhausts these pretty scarce ressources and limits itself to
>>> mapping only the first 256MB (a usual limit for a BAT).
>> So it is possible to overlay the function memory_post_test() by a
>> board specific routine, which may cover almost all RAM?
> 
> Everything is possible - this is software, so anything can be done.
> You can even make pigs fly. But not everything does make sense.
> 
>> BTW, is it possible to overlay _all_ POST routines by board specific
>> routines?
> 
> It could be done, but I consider it a very, very bad idea.
> 
> Best regards,
> 
> Wolfgang Denk
> 
And what if the tests wouldn't meet certain requirements of the
developer or customer or if it had to be adapted to CPU- or
board-specific conditions?
I suppose, you wouldn't like much "#ifdef <CPU>"s or "#ifdef <board>"s
in common code.
Could you please make a proposal to solve this and to get such code
into the official U-Boot tree?

Kind regards
    Jens

[U-Boot-Users] post memory test

[Wolfgang Denk]

In message <4741416E.1040707@tqs.de> you wrote:
>
> And what if the tests wouldn't meet certain requirements of the
> developer or customer or if it had to be adapted to CPU- or
> board-specific conditions?

U-Boot provides ways for CPU and board specific code, also in the POST
impelmentation, but that should be used only where really necessary.

> I suppose, you wouldn't like much "#ifdef <CPU>"s or "#ifdef <board>"s
> in common code.

Definitely not.

> Could you please make a proposal to solve this and to get such code
> into the official U-Boot tree?

So what exactly is it what you would like to see changed in the  POST
memory test?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
All easy problems have already been solved.

[U-Boot-Users] post memory test

[Detlev Zundel]

Hi,

> Wolfgang Denk schrieb:
>> In message <473D9B54.1010304@tqs.de> you wrote:
>>>> As an example look at initdram() in board/Marvell/db64460/sdram_init.c
>>>> where the platform uses Block Address Translations (BATs) to map RAM
>>>> but exhausts these pretty scarce ressources and limits itself to
>>>> mapping only the first 256MB (a usual limit for a BAT).
>>> So it is possible to overlay the function memory_post_test() by a
>>> board specific routine, which may cover almost all RAM?
>> 
>> Everything is possible - this is software, so anything can be done.
>> You can even make pigs fly. But not everything does make sense.
>> 
>>> BTW, is it possible to overlay _all_ POST routines by board specific
>>> routines?
>> 
>> It could be done, but I consider it a very, very bad idea.
>> 
>> Best regards,
>> 
>> Wolfgang Denk
>> 
> And what if the tests wouldn't meet certain requirements of the
> developer or customer or if it had to be adapted to CPU- or
> board-specific conditions?
> I suppose, you wouldn't like much "#ifdef <CPU>"s or "#ifdef <board>"s
> in common code.
> Could you please make a proposal to solve this and to get such code
> into the official U-Boot tree?

Let me restate, that for me U-Boot gets its power from the shared
source code, not from the "every board uses its own code".  On the
contrary, non-shared source is a constant source of trouble in this
project that surely picked up speed in the last few months.

Code sharing is a _central_ point of the whole U-Boot design and
especially _test_ routines surely should fall into this category.  So
we should always strive to solve the problem in common code, probably
using board specific data structures to cope with the differences.

Instead of discussing the general "why shouldn't we override test xy"
which I believe cannot be answered in a more general way than I tried
in the previous paragraph, let's think about the post memory test.

What we really need is (as I already hinted at in my first reply) a
data structure that allows the post test to know how much memory is
mapped where.  At first I thought of a single scalar mem_mapped
variable but discussion with Wolfgang showed me that we really
need a list of mapped segments for the general case.

So to answer your question, if you come up with an implementation of
this idea (or something comparable) then I don't see why this could
not go mainline.

Cheers
  Detlev

-- 
LISP is the most powerful programming language, and if you want an inter-
preter, LISP is the best.  None of the other languages come anywhere near
LISP in their power.  The most exciting things about LISP are read, eval,
and print.  If you look at other languages,  they have no equivalent for
any of those.                             -- Richard Stallman
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de