Re: [U-Boot-Users] post memory test
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
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
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
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
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
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
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
participants (4)
-
Detlev Zundel -
Dongying_Xu＠us.alphanetworks.com -
Jens Gehrlein -
Wolfgang Denk