[U-Boot] ARM POST Tests.

[U-Boot] ARM POST Tests.

[sreekumar.sivakumar at wipro.com]

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

[U-Boot] ARM POST Tests.

[Heiko Schocher]

Hello sreekumar.sivakumar,

sreekumar.sivakumar at 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.
> 1) Is that a limitation, or Is it some sort of misunderstanding on my
> side?

Actually nobody used it on arm

> 2) 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
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] ARM POST Tests.

[Valentin Longchamp]

Hi Heiko,

On 07/15/2011 10:13 AM, Heiko Schocher wrote:
> sreekumar.sivakumar at wipro.com wrote:
> 
> Actually nobody used it on arm
> 
>> 2) 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

[U-Boot] ARM POST Tests.

[Wolfgang Denk]

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

-- 
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
I usually tell my classes "if you are using @ and [] together in this
class, you will almost certainly NOT get what you want. That's  going
down  the wrong tunnel. There's no cheese at the end of that tunnel."
         -- Randal L. Schwartz in <8czptuomey.fsf@gadget.cscaper.com>

[U-Boot] ARM POST Tests.

[Valentin Longchamp]

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 ?

-- 
Valentin Longchamp
Embedded Software Engineer
Hardware and Chip Integration
______________________________________
KEYMILE AG
Schwarzenburgstr. 73
CH-3097 Liebefeld
Phone +41 31 377 1318
Fax   +41 31 377 1212
valentin.longchamp at keymile.com
www.keymile.com
______________________________________
KEYMILE: A Specialist as a Partner

[U-Boot] ARM POST Tests.

[Wolfgang Denk]

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

-- 
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
You don't need a weatherman to know which way the wind blows.
                                                          - Bob Dylan

[U-Boot] ARM POST Tests.

[Valentin Longchamp]

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 ?

-- 
Valentin Longchamp
Embedded Software Engineer
Hardware and Chip Integration
______________________________________
KEYMILE AG
Schwarzenburgstr. 73
CH-3097 Liebefeld
Phone +41 31 377 1318
Fax   +41 31 377 1212
valentin.longchamp at keymile.com
www.keymile.com
______________________________________
KEYMILE: A Specialist as a Partner

[U-Boot] ARM POST Tests.

[Wolfgang Denk]

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

-- 
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
I'm a soldier, not a diplomat.  I can only tell the truth.
	-- Kirk, "Errand of Mercy", stardate 3198.9

[U-Boot] ARM POST Tests.

[Mike Frysinger]

On Fri, Jul 15, 2011 at 04:13, Heiko Schocher wrote:
> sreekumar.sivakumar at wipro.com wrote:
>> 2) 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

[U-Boot] arm post tests

[shobin b]

Hi ,

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.

Please help me...



Thanks,

shobin.b