[U-Boot] ARM POST Tests.
Hello ,
I am new to u-boot code. I had a requirement for running memory, cpu and cache tests as part of diagnostics, on an ARM based platform. After going through the code, I found that only PPC variants are available for cpu and cache post tests. 1) Is that a limitation, or Is it some sort of misunderstanding on my side? 2) If NO, Is there a branch or patch I can pickup which will have ARM POST tests for cache and cpu?
Your advice will be of great help.
Thanks, Sreekumar
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com
Hello sreekumar.sivakumar,
sreekumar.sivakumar@wipro.com wrote:
I am new to u-boot code. I had a requirement for running memory, cpu and cache tests as part of diagnostics, on an ARM based platform. After going through the code, I found that only PPC variants are available for cpu and cache post tests.
- Is that a limitation, or Is it some sort of misunderstanding on my
side?
Actually nobody used it on arm
- If NO, Is there a branch or patch I can pickup which will have ARM
POST tests for cache and cpu?
Try this patches (I actually worked on getting POST tests running on an davinci based board):
- get CONFIG_POST working for arm boards: [PATCH] post, memorytest: fix if vstart is not = 0x0 http://patchwork.ozlabs.org/patch/98127/ [PATCH v2] post, memorytest: add support for none powerpc archs http://patchwork.ozlabs.org/patch/98522/ [PATCH] post, memory test: add memory_post_test() to include file http://patchwork.ozlabs.org/patch/98126/ [PATCH 1/2] arm, lib/board.c: Coding Style cleanup http://patchwork.ozlabs.org/patch/98532/ update: http://patchwork.ozlabs.org/patch/104755/ [PATCH 2/2] arm, lib/board.c: use gd->ram_size instead of bd->bi_memsize http://patchwork.ozlabs.org/patch/98531/
bye, Heiko
Hi Heiko,
On 07/15/2011 10:13 AM, Heiko Schocher wrote:
sreekumar.sivakumar@wipro.com wrote:
Actually nobody used it on arm
- If NO, Is there a branch or patch I can pickup which will have ARM
POST tests for cache and cpu?
Try this patches (I actually worked on getting POST tests running on an davinci based board):
- get CONFIG_POST working for arm boards:
[PATCH] post, memorytest: fix if vstart is not = 0x0 http://patchwork.ozlabs.org/patch/98127/ [PATCH v2] post, memorytest: add support for none powerpc archs http://patchwork.ozlabs.org/patch/98522/ [PATCH] post, memory test: add memory_post_test() to include file http://patchwork.ozlabs.org/patch/98126/ [PATCH 1/2] arm, lib/board.c: Coding Style cleanup http://patchwork.ozlabs.org/patch/98532/ update: http://patchwork.ozlabs.org/patch/104755/ [PATCH 2/2] arm, lib/board.c: use gd->ram_size instead of bd->bi_memsize http://patchwork.ozlabs.org/patch/98531/
I am currently working on POST tests support for keymile boards, especially km_kirkwood (km_arm) boards.
I have taken your above patches (I had noticed them before) and I have POST tests running on km_arm. For the tests that take place after relocation of code, there is no problem, they work fine.
With the memory test, that takes place before the relocation, it is extremly slow (even if I reduce the size of the memory tested to a very small portion). Is it something you have noticed as well ?
Thank you
Valentin
Dear Valentin Longchamp,
In message 4E25A2D0.1090903@keymile.com you wrote:
With the memory test, that takes place before the relocation, it is extremly slow (even if I reduce the size of the memory tested to a very small portion). Is it something you have noticed as well ?
This might be due to caches not being turned on yet?
Best regards,
Wolfgang Denk
On 07/19/2011 08:45 PM, Wolfgang Denk wrote:
Dear Valentin Longchamp,
In message 4E25A2D0.1090903@keymile.com you wrote:
With the memory test, that takes place before the relocation, it is extremly slow (even if I reduce the size of the memory tested to a very small portion). Is it something you have noticed as well ?
This might be due to caches not being turned on yet?
This may explain one part of the issue.
I have done a little bit of profiling this morning, and the main culprit is the call to getenv_f in post_get_flags for the four environment variables:
"post_poweron", "post_normal", "post_slowtest" "post_critical"
This is extremly slow on my system (before relocation). The goal of these env variables is, I guess, to define the name of the tests that have to be run for each post level, right ? Is this the only way to define which tests are to be run ?
Dear Valentin Longchamp,
In message 4E26B523.3070609@keymile.com you wrote:
I have done a little bit of profiling this morning, and the main culprit is the call to getenv_f in post_get_flags for the four environment variables:
"post_poweron", "post_normal", "post_slowtest" "post_critical"
This is extremly slow on my system (before relocation). The goal of these env
Are you by chance reading the environment from I2C attached EEPROM or so? This is indeed a speed killer.
variables is, I guess, to define the name of the tests that have to be run for each post level, right ? Is this the only way to define which tests are to be run ?
To define the tests to be run, and the reaction that is needed if a test fails.
If your environment accesses are so slow, you should fix that anyway.
Best regards,
Wolfgang Denk
On 07/20/2011 02:20 PM, Wolfgang Denk wrote:
Dear Valentin Longchamp,
In message 4E26B523.3070609@keymile.com you wrote:
I have done a little bit of profiling this morning, and the main culprit is the call to getenv_f in post_get_flags for the four environment variables:
"post_poweron", "post_normal", "post_slowtest" "post_critical"
This is extremly slow on my system (before relocation). The goal of these env
Are you by chance reading the environment from I2C attached EEPROM or so? This is indeed a speed killer.
Yeah I had just figured that out by myself: our environement variables are in an I2C EEPROM, so every read is extremely slow at this poin in the boot process. For the second POST run (from RAM this time), the environment is then in RAM (thanks to env_relocate) and thus the calls to getenv_f much quicker.
variables is, I guess, to define the name of the tests that have to be run for each post level, right ? Is this the only way to define which tests are to be run ?
To define the tests to be run, and the reaction that is needed if a test fails.
If your environment accesses are so slow, you should fix that anyway.
We are currently planning to move away from I2C EEPROM for environment (for future hardware), but what would you advise me to do for our current hardware where the environment is in this EEPROM ?
Dear Valentin Longchamp,
In message 4E26CAD9.3090204@keymile.com you wrote:
We are currently planning to move away from I2C EEPROM for environment (for future hardware), but what would you advise me to do for our current hardware where the environment is in this EEPROM ?
This depends on the specific features of your hardware.2s
Eventually you can increase the I2C clock.
Or use a h/w I2C driver instead of the soft-I2C driver.
Eventually you have plenty of memory that is available early (say, several MB of L2 cache or so :-) and you can read the whole environment into "RAM" in one rush.
Except for that there is little we can do. I2C is a PITA, also reliability-wise.
Best regards,
Wolfgang Denk
On Fri, Jul 15, 2011 at 04:13, Heiko Schocher wrote:
sreekumar.sivakumar@wipro.com wrote:
- If NO, Is there a branch or patch I can pickup which will have ARM
POST tests for cache and cpu?
Try this patches (I actually worked on getting POST tests running on an davinci based board):
- get CONFIG_POST working for arm boards:
[PATCH] post, memorytest: fix if vstart is not = 0x0 http://patchwork.ozlabs.org/patch/98127/ [PATCH v2] post, memorytest: add support for none powerpc archs http://patchwork.ozlabs.org/patch/98522/ [PATCH] post, memory test: add memory_post_test() to include file http://patchwork.ozlabs.org/patch/98126/ [PATCH 1/2] arm, lib/board.c: Coding Style cleanup http://patchwork.ozlabs.org/patch/98532/ update: http://patchwork.ozlabs.org/patch/104755/ [PATCH 2/2] arm, lib/board.c: use gd->ram_size instead of bd->bi_memsize http://patchwork.ozlabs.org/patch/98531/
i wonder if i should suck these up into my post branch too so we at least have a central place for post ...
i dont think there is any "post" maintainer atm right ? -mike
participants (5)
-
Heiko Schocher -
Mike Frysinger -
sreekumar.sivakumar＠wipro.com -
Valentin Longchamp -
Wolfgang Denk