Dear Wolfgang,
Am Montag, 2. Mai 2011, 19:00:47 schrieb Wolfgang Denk:
In message 201105021640.27241.alexander.stein@systec-electronic.com you
wrote:
Ok, let me be more precise on this. We used U-Boot v2010.09 on a custom board running on an I.MX35 (ARM1136).
Let's summarize known facts:
- You are talking about an out-of-tree port, i. e. code which is completely unknown here, so it is basicly impossible to comment. We can barely speculate.
I'm aware of that. But on the other hand, cmd_nvedit.c and console.c are both generic parts. As Detlev have written, this is not the cause of the problem. Let's see if I find time again for this.
This is an ARM board.
This is an old version before cache support for ARM was added.
This specific version was selected due to relocation problems on ARM. But I expect the dcache doesn't have that big influence on the named code part as the environment is already in RAM.
We noticed the following code snippet took relatively long.
From common/console.c in console_init_r(void):
/* Setting environment variables */ for (i = 0; i < 3; i++) {
setenv(stdio_names[i], stdio_devices[i]->name);
}
We added PIN toggling around this part of code and measured something
100ms. A collegue said it was ~100ms, I remembered ~500ms. Dunno who is
right.
Both numbers are way off.
Let me speculate: (I) you have a _huge_ environment allocated for your board, probably > 100 KiB or more;
Environment size: 2098/131067 bytes
So, no.
(II) you are loading it from a slow storage device, probably NAND flash;
The environment is stored in NOR-Flash. So, no.
(III) you are running on a narrow system bus (16 bit) with non-optimal RAM timings;
It is using a 32-Bit RAM-Bus. So, no.
(IV) you do all this with caches turned off;
dcaches should be off, while icaches are on. So yes and no.
(V) you measure some numbers but you don;t understand what they mean.
These numbers show me that this part of code increases the start time of a considerable amount. The workaround resulted in a faster startup without notable side effect. I'm aware this is not the fix of the problem. So yes and no.
I bet some beer that at least 3 of these speculations hit the point.
You better not want to bet here :-)
Regards, Alexander