Re: [U-Boot] [PATCH v3] arm926ejs: timer: Replace bss variable by gdr

2011-01-22 Thread Reinhard Meyer
Dear Albert ARIBAUD,
> However a general rework of ARM timer code is in order so that all SoCs
> and CPUs share the same set of gd variables with the same names and the
> same logic; and when we get that, this code shall move along.
>
> About this rework, as the saying goes... "Patches Welcome ©". :)

There were several suggestions about that in the past (including from me)
that involve rework everywhere HZ related timeouts are used. I still
prefer a method as follows (because it does not need repeated mul/div 
calculations
nor necessarily 64 bit arithmetic):

u32 timeout = timeout_init(100); /* 100ms timeout */

do {...} while (!timed_out(timeout));

Internally it would be like:

timeout_init(x):
  return fast_tick + (x * fast_tick_rate) / CONFIG_SYS_HZ;
  /* this might need 64 bit precision in some implementations */

time_out(x):
  return ((i32)(x - fast_tick)) < 0;

If the tick were really high speed (and then 64 bits),
fast_tick could be derived by shifting the tick some bits to the right.

But, as long as we cannot agree on something, there will be no time spent
to make patches...

Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [v4 patch 6/6] SMDK6400: Fix SMDK6400 SDRAM init

2011-01-22 Thread Minkyu Kang
Dear seedshope,

On 22 January 2011 00:34, seedshope  wrote:
> Since SDRAM init function have already change, So the SDRAM
> initial function must be change.
>
> Signed-off-by: seedshope 
> ---
>  board/samsung/smdk6400/smdk6400.c |   10 +-
>  1 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a/board/samsung/smdk6400/smdk6400.c 
> b/board/samsung/smdk6400/smdk6400.c
> index 35aa40b..1d03b7a 100644
> --- a/board/samsung/smdk6400/smdk6400.c
> +++ b/board/samsung/smdk6400/smdk6400.c
> @@ -78,10 +78,18 @@ int board_init(void)
>        return 0;
>  }
>
> -int dram_init(void)
> +void dram_init_banksize(void)
>  {
> +       DECLARE_GLOBAL_DATA_PTR;

Please remove it.

> +
>        gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
>        gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;

Thanks
Minkyu Kang
-- 
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [v4 patch 6/6] SMDK6400: Fix SMDK6400 SDRAM init

2011-01-22 Thread Thomas Langer
Hi seedshope,

seedshope  gmail.com> writes:

> -int dram_init(void)
> +void dram_init_banksize(void)
>  {
> + DECLARE_GLOBAL_DATA_PTR;

This declaration should be done on file scope, not in a function.

> +
>   gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
>   gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
> +}
> +

Best regards,
Thomas

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3] arm926ejs: timer: Replace bss variable by gdr

2011-01-22 Thread Alexander Holler
Am 22.01.2011 08:46, schrieb Albert ARIBAUD:
> Le 22/01/2011 06:39, Alexander Holler a écrit :
>> Hello,
>>
>> Am 21.01.2011 09:56, schrieb Heiko Schocher:
>>
>>> -static ulong timestamp;
>>> -static ulong lastdec;
>>> +DECLARE_GLOBAL_DATA_PTR;
>>> +
>>> +#define timestamp gd->tbl
>>> +#define lastdec gd->lastinc
>>
>> I'm the only one who doesn't like such defines? They might be handy for
>> quick fixes, but in regard to style and readablity I don't like them.
>> When looking at teh code where they will used, you won't see the actual
>> place where they are stored. And in more complex expression they might
>> become dangerous to use because they hide the operator "->".
>
> I accept the patch because it un-breaks support for ARM cpus, and I
> prefer a working fix to a perfect fix in this specific, transitional,
> situation.

My experience is that such quick fixes (or workarounds) usually 
manifests (because they become forgotten) and later on might even be 
copied to other places. ;)

Anyway, I'll have to thank for that patch, because it fixes at least one 
of the problems I have while trying to chainload a 2010.12 from a 
2010.12 on a kirkwood system.

Regards, and again, thanks for the patch, even if I found it ugly,

Alexander

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] Бог благословитl

2011-01-22 Thread azeeza.b
миссис Azeeza Basara, родом из Катара. Мой муж покойный д-р Омар Джалал Basara. 
Он работе посольства Катара в Судане и Марокко в течение двенадцати лет. И ушел 
в отставку в нефтяной торговый до его смерти. Я решил не получить себе участие 
в любой брак после его смерти или получить ребенка вне моего семейного дома. Я 
страдал от рака матки в течение четырех лет после умер мой муж. Вместе с с 
нарушениями слуха в связи с лекарственной реакции. У нас не было детей, после 
восемнадцати лет в мирное брака. Недавно мой врач сказал мне, что моя жизнь не 
будет превышать трех месяцев, в связи с болезнью рака моя. У меня есть депозит 
в размере $ 7.6Musd в банк в Англии. И поэтому, я искренне хочет распространять 
фонда для менее привилегированных в вашей стране (бывшего Советского Союза). Я 
очень хочу, чтобы использовать его для гуманитарной деятельности. Я не ребенок, 
который унаследует эти деньги от меня. А родственники моего мужа была плохо для 
меня, поскольку моя болезнь моя, больных раком. Я ни хочет, ни банку заполучить 
мои деньги после моей смерти.

Как только я получаю ваш ответ, я сообщу мой адвокат, чтобы помочь вам 
снять деньги из банка, который вы будете использовать в улучшение человечества 
в вашем регионе (стране). Пожалуйста, уверяют меня, что вы будете искренне 
помочь мне в этом. Я ожидает Вашего ответа в скором времени с этой электронной 
почтой (ab76...@hotmail.com)
Azeeza Basara.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] A question in lowlevel_init.S

2011-01-22 Thread Eric Bénard
Hi,

On 22/01/2011 08:39, Reinhard Meyer wrote:
> I am not aware of any AT91SAM9xxx systems right now that uses low-level init, 
> it
> would only make sense for those that boot directly from NOR, without
> AT91BOOTSTRAP involved.

cpu9260 (at91sam9260 / 9g20 based) is using low-level init as it boots from 
NOR and is not using at91bootstrap.

Eric
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [RFC] ARM timing code refactoring

2011-01-22 Thread Albert ARIBAUD
Hi All,

I am starting this thread to revive and, hopefully, come to a general 
agreement on how timers should be implemented and used in the ARM 
architecture, and get rid of current quick fixes. Let us start with 
Reinhard's proposal:

> There were several suggestions about that in the past (including from
> me) that involve rework everywhere HZ related timeouts are used. I
> still prefer a method as follows (because it does not need repeated
> mul/div calculations nor necessarily 64 bit arithmetic):

Agreed for unnecessary mult-div, but 64-bit we would not avoid, and 
should not IMO, when the HW has it.

> u32 timeout = timeout_init(100); /* 100ms timeout */
>
> do {...} while (!timed_out(timeout));
>
> Internally it would be like:
>
> timeout_init(x):
> return fast_tick + (x * fast_tick_rate) / CONFIG_SYS_HZ;
> /* this might need 64 bit precision in some implementations */
>
> time_out(x):
> return ((i32)(x - fast_tick)) < 0;
>
> If the tick were really high speed (and then 64 bits), fast_tick
> could be derived by shifting the tick some bits to the right.

The only thing I slightly dislike about the overall idea is the signed 
rather than unsigned comparison in the timeout function (I prefer using 
the full 32-bit range, even if only as an academic point) and the fact 
that the value of the timeout is encoded in advance in the loop control 
variable 'timeout'.

I'd rather have a single 'time(x)' (or 'ticks_elapsed(x)', names are 
negotiable) macro which subtract its argument from the current ticks, 
e.g. 'then = time(0)' would set 'then' to the number of ticks elapsed 
from boot, while 'now = time(then)' would set 'now' the ticks elapsed 
from 'then'; and a 'ms_to_ticks(x)' (again, or 'milliseconds(x)') :

#define time(x) (ticks - x)
#define ms_to_ticks(m) ( (m * fast_tick_rate) / CONFIG_SYS_HZ)

Note that time(x) assumes unsigned arguments and amounts to an unsigned 
compare, because we're always computing an difference time, i.e. even 
with x = 2 and ticks = 1, the result is correct -- that's assuming ticks 
is monotonous 32-bits (or 64-bits for the platforms that can support it 
as an atomic value)

Your example would then become

then = time(0);
do {...} while ( time(then) < ms_to_ticks(100) );

... moving the actual timeout value impact from the time sample before 
the 'while' to the 'while' condition at then end.

For expressiveness, added macros such as:

#define now() time(0)
#define ms_elapsed(then,ms) ( time(then) < ms_to_ticks(ms) )

... would allow writing the same example as:

then = now();
do {...} while ( !ms_elapsed(then,100) );

> But, as long as we cannot agree on something, there will be no
> time spent to make patches...

Makes sense, hence this specific thread. :)

> Best Regards,
> Reinhard

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] A question in lowlevel_init.S

2011-01-22 Thread Reinhard Meyer
Dear Eric Bénard wrote:
> Hi,
>
> On 22/01/2011 08:39, Reinhard Meyer wrote:
>> I am not aware of any
ADD: working
>> AT91SAM9xxx systems right now that uses low-level init, it
>> would only make sense for those that boot directly from NOR, without
>> AT91BOOTSTRAP involved.
>
> cpu9260 (at91sam9260 / 9g20 based) is using low-level init as it boots from
> NOR and is not using at91bootstrap.

Those CPUs are broken since relocation was introduced. It would be nice to see
them demonstrated working out of NOR with low level init enabled...

Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [RFC] ARM timing code refactoring

2011-01-22 Thread Reinhard Meyer
Dear Albert ARIBAUD,
> Hi All,
>
> I am starting this thread to revive and, hopefully, come to a general
> agreement on how timers should be implemented and used in the ARM
> architecture, and get rid of current quick fixes. Let us start with
> Reinhard's proposal:
>
>> There were several suggestions about that in the past (including from
>> me) that involve rework everywhere HZ related timeouts are used. I
>> still prefer a method as follows (because it does not need repeated
>> mul/div calculations nor necessarily 64 bit arithmetic):
>
> Agreed for unnecessary mult-div, but 64-bit we would not avoid, and
> should not IMO, when the HW has it.
>
>> u32 timeout = timeout_init(100); /* 100ms timeout */
>>
>> do {...} while (!timed_out(timeout));
>>
>> Internally it would be like:
>>
>> timeout_init(x):
>> return fast_tick + (x * fast_tick_rate) / CONFIG_SYS_HZ;
>> /* this might need 64 bit precision in some implementations */
>>
>> time_out(x):
>> return ((i32)(x - fast_tick))<  0;
>>
>> If the tick were really high speed (and then 64 bits), fast_tick
>> could be derived by shifting the tick some bits to the right.
>
> The only thing I slightly dislike about the overall idea is the signed
> rather than unsigned comparison in the timeout function (I prefer using
> the full 32-bit range, even if only as an academic point) and the fact
> that the value of the timeout is encoded in advance in the loop control
> variable 'timeout'.

1. you always need signed compares there, unless you never anticipate a
rollover of your timer value to zero.
2. whats the problem with initializing the timeout value at the beginning?

>
> I'd rather have a single 'time(x)' (or 'ticks_elapsed(x)', names are
> negotiable) macro which subtract its argument from the current ticks,
> e.g. 'then = time(0)' would set 'then' to the number of ticks elapsed
> from boot, while 'now = time(then)' would set 'now' the ticks elapsed
> from 'then'; and a 'ms_to_ticks(x)' (again, or 'milliseconds(x)') :
>
>   #define time(x) (ticks - x)
>   #define ms_to_ticks(m) ( (m * fast_tick_rate) / CONFIG_SYS_HZ)

We have exactly an equivalent of this in use at AT91.
It works only as long as the ticks value does not roll back to zero -
which in the current 64 bit implementation I did is after the end of
the universe...

Note also that "fast_tick_rate" would not be a constant in AT91, it is
dynamically calculated from main xtal frequency measured against the 32kHz
xtal and PLL settings.

>
> Note that time(x) assumes unsigned arguments and amounts to an unsigned
> compare, because we're always computing an difference time, i.e. even
> with x = 2 and ticks = 1, the result is correct -- that's assuming ticks
> is monotonous 32-bits (or 64-bits for the platforms that can support it
> as an atomic value)

Assume: Monotonous AND never wrapping back to zero!

>
> Your example would then become
>
>   then = time(0);
>   do {...} while ( time(then)<  ms_to_ticks(100) );

That looks ugly to me. We don't want to see the high speed(64 bit) values
in the drivers - I think.

>
> ... moving the actual timeout value impact from the time sample before
> the 'while' to the 'while' condition at then end.

Which does a multiply and a divide in 64 bit each loop iteration...
(fast_tick_rate being a variable)

>
> For expressiveness, added macros such as:
>
>   #define now() time(0)
>   #define ms_elapsed(then,ms) ( time(then)<  ms_to_ticks(ms) )
>
> ... would allow writing the same example as:
>
>   then = now();
>   do {...} while ( !ms_elapsed(then,100) );
>

Why make everything so complicated???

>> But, as long as we cannot agree on something, there will be no
>> time spent to make patches...
>
> Makes sense, hence this specific thread. :)

The how-many-th thread about timers is this ? :)

Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [RFC] U-boot (was: ARM) timing code refactoring

2011-01-22 Thread Reinhard Meyer
Dear Albert ARIBAUD,

this is not an ARM local issue.

The timeouts are used in generic drivers all around u-boot.

Have a grep for get_timer, reset_timer...

The most ugly use is with reset_timer involved, where the internal
pseudo-tick is reset to zero, so all calls to get_timer are
relative to that moment.

We are looking at replacing all those occurrences of reset_timer
and get_timer with "better" methods.

Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [RFC] ARM timing code refactoring

2011-01-22 Thread Albert ARIBAUD
Le 22/01/2011 11:42, Reinhard Meyer a écrit :
> Dear Albert ARIBAUD,
>> Hi All,
>>
>> I am starting this thread to revive and, hopefully, come to a general
>> agreement on how timers should be implemented and used in the ARM
>> architecture, and get rid of current quick fixes. Let us start with
>> Reinhard's proposal:
>>
>>> There were several suggestions about that in the past (including from
>>> me) that involve rework everywhere HZ related timeouts are used. I
>>> still prefer a method as follows (because it does not need repeated
>>> mul/div calculations nor necessarily 64 bit arithmetic):
>>
>> Agreed for unnecessary mult-div, but 64-bit we would not avoid, and
>> should not IMO, when the HW has it.
>>
>>> u32 timeout = timeout_init(100); /* 100ms timeout */
>>>
>>> do {...} while (!timed_out(timeout));
>>>
>>> Internally it would be like:
>>>
>>> timeout_init(x):
>>> return fast_tick + (x * fast_tick_rate) / CONFIG_SYS_HZ;
>>> /* this might need 64 bit precision in some implementations */
>>>
>>> time_out(x):
>>> return ((i32)(x - fast_tick))< 0;
>>>
>>> If the tick were really high speed (and then 64 bits), fast_tick
>>> could be derived by shifting the tick some bits to the right.
>>
>> The only thing I slightly dislike about the overall idea is the signed
>> rather than unsigned comparison in the timeout function (I prefer using
>> the full 32-bit range, even if only as an academic point) and the fact
>> that the value of the timeout is encoded in advance in the loop control
>> variable 'timeout'.
>
> 1. you always need signed compares there, unless you never anticipate a
> rollover of your timer value to zero.

I don't think rollover to zero is an issue if the tick counter is 
free-running on 32 (or 64 bits); and if it is free-running on some other 
number of bits, the time() macro just needs anding to work.

> 2. whats the problem with initializing the timeout value at the beginning?

There isn't a problem as such; simply, as the timeout is not 
conceptually needed at the beginning of the timing loop, I would favor 
implementations which do not need it at the beginning either.

>> I'd rather have a single 'time(x)' (or 'ticks_elapsed(x)', names are
>> negotiable) macro which subtract its argument from the current ticks,
>> e.g. 'then = time(0)' would set 'then' to the number of ticks elapsed
>> from boot, while 'now = time(then)' would set 'now' the ticks elapsed
>> from 'then'; and a 'ms_to_ticks(x)' (again, or 'milliseconds(x)') :
>>
>> #define time(x) (ticks - x)
>> #define ms_to_ticks(m) ( (m * fast_tick_rate) / CONFIG_SYS_HZ)
>
> We have exactly an equivalent of this in use at AT91.
> It works only as long as the ticks value does not roll back to zero -
> which in the current 64 bit implementation I did is after the end of
> the universe...

Let us take a case where the tick value rolls over 0. Say, ticks is 
equal to 2^32 - 100, and we should delay for 200 ticks. At the beginning 
of the loop, 'then' becomes equal to 2^32 - 100. While the loop runs, 
time(then) equals 'ticks - then', or, '2^32 - 100 + n - (2^32 - 100)', 
or '2^32 - 100 - 2^32 + 100 +n', or (since we're computing modulo 2^32) 
'-100 + 100 +n', or 'n', where n is the number of ticks elapsed since 
'now' was caculated. When n is 200 or more, the loop end condition is 
met. Crossing the 0 value did not affect the computation -- or did it?

> Note also that "fast_tick_rate" would not be a constant in AT91, it is
> dynamically calculated from main xtal frequency measured against the 32kHz
> xtal and PLL settings.

That's another issue entirely, with two consequences, but they don't 
really differ with respect to which proposal, yours or mine, is considered.

1. This makes the compiler unable to optimize ms to tick conversions at 
compile time. Not a really big deal, and unavoidable as soon as the 
decision is taken to calibrate the fast tick at run time.

2. If calibration is done continuously, then ticks *may* not be 
monotonous. If it is done once at startup, a la bogomips calculation, 
then we should be safe.

>> Note that time(x) assumes unsigned arguments and amounts to an unsigned
>> compare, because we're always computing an difference time, i.e. even
>> with x = 2 and ticks = 1, the result is correct -- that's assuming ticks
>> is monotonous 32-bits (or 64-bits for the platforms that can support it
>> as an atomic value)
>
> Assume: Monotonous AND never wrapping back to zero!

I think zero wraparound is not an issue if the ticks are on N (ideally, 
32 or 64) bits, which is most probably the case for a free-running 
counter. We need to assume monotonous at least during delay loops; since 
we have little or no parallel execution, we should be able to avoid 
recalibration while a delay loop is running, right?

>> Your example would then become
>>
>> then = time(0);
>> do {...} while ( time(then)< ms_to_ticks(100) );
>
> That looks ugly to me. We don't want to see the high speed(64 bit) values
> in the drivers - I think.

We

Re: [U-Boot] [RFC] U-boot

2011-01-22 Thread Albert ARIBAUD
Hi Reinhard,

Le 22/01/2011 12:00, Reinhard Meyer a écrit :
> Dear Albert ARIBAUD,
>
> this is not an ARM local issue.

Well, there *is* an ARM specific side of it (use of gd variables during 
relocation), and that is what prompted me to start the RFC, but 
generalization to U-boot is welcome if it leads to a satisfactory 
solution. If not, at least I'll adopt a solution for ARM.

> The timeouts are used in generic drivers all around u-boot.
>
> Have a grep for get_timer, reset_timer...
>
> The most ugly use is with reset_timer involved, where the internal
> pseudo-tick is reset to zero, so all calls to get_timer are
> relative to that moment.
>
> We are looking at replacing all those occurrences of reset_timer
> and get_timer with "better" methods.

Seems to me this replacement is quite straightforward, as most uses of 
reset_timer() and subsequent get_timer are actually loops, functionally 
the same as our proposals, only instead of using a local to store the 
start or end time, they reset ticks to zero -- which, I concur, is a Bad 
Thing.

But 'reset_timer()' calls just need to be replaced with your 'timeout = 
timeout_init(N)' or my 'then = now()' and 'get_timer() > N' or 
'get_timer_masked() > N' by your 'time_out(timeout)' or my 
'ms_elapsed(N)'. Seems to me like a tedious effort, possibly involving 
occasional time-out value conversions, but not a difficulty.

What do I miss?

> Best Regards,
> Reinhard

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] WARNING: in gcc 4.5.0 and 4.5.1 volatile is ignored

2011-01-22 Thread Alexander Holler
Hello,

because I've recently seen some other places where volatile is used to 
access registers without using read?() or write?() and many people seem 
to start using 4.5.1, I want to post this warning using a descriptive 
subject.

The keyword volatile might not have any effect when reading when gcc 
4.5.0 or 4.5.1 is used.

The appropriate bug seems to be that one:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45052

You might either change such code to use readb(), readw() or readl(), or 
you have to use either an older version of gcc or a version >= 4.5.2 (it 
is fixed in 4.5.2).

A patch for write?() and read?() is currently in the 
u-boot-arm-repository (but not in the master and not in 2010.12):

http://lists.denx.de/pipermail/u-boot/2011-January/084885.html

Regards,

Alexander
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] WARNING: in gcc 4.5.0 and 4.5.1 volatile is ignored

2011-01-22 Thread Wolfgang Denk
Dear Alexander Holler,

In message <4d3ad19b.6030...@ahsoftware.de> you wrote:
> 
> because I've recently seen some other places where volatile is used to 
> access registers without using read?() or write?() and many people seem 
> to start using 4.5.1, I want to post this warning using a descriptive 
> subject.
> 
> The keyword volatile might not have any effect when reading when gcc 
> 4.5.0 or 4.5.1 is used.

Actuelly this warning should eventually be extended to carefully check
results when using any of the currently available 4.5.x versions of
GCC.

> The appropriate bug seems to be that one:
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45052

This is probably only one part of the problem.  Thereare a number of
other bugs in thes ecompiler versions, for example this one:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44392

Unfortunately there appears to be little interest within the GCC folks
to fix porolems that affect only such lunatic fringe groups as the
embedded folks, so I don't expect to see fixes any time soon.  Even
bigger projects like the Linux Foundation driven Poky (resp. Yocto
project) capitulated and stopped using -Os, see for example here:
http://thread.gmane.org/gmane.linux.embedded.poky/2311/focus=2565

Yes, "-Os" is default setting for U-Boot - changing it to (for example)
-O2 will generate significantly larger code and even break a number of
boards.


It appears there are a number of other issues with GCC 4.5.x that
affect us.  If you are using any such tool chain, and see strange
results or unexpected breakages, it is probably a very good idea to
try another (older, working) tool chain first, before spending any tme
on debugging.


> You might either change such code to use readb(), readw() or readl(), or 
> you have to use either an older version of gcc or a version >= 4.5.2 (it 
> is fixed in 4.5.2).

We will take care to provide working (at least with most of the
compiler versions) I/O accessors (including sufficient memory
barriers), and all code that uses the old volatile pointer approach
to access device registers should be converted to use proper I/O
acessors.

> A patch for write?() and read?() is currently in the 
> u-boot-arm-repository (but not in the master and not in 2010.12):
> 
> http://lists.denx.de/pipermail/u-boot/2011-January/084885.html


Thanks for raising this issue again.

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: w...@denx.de
The ideal situation is to have massive computing power right at home.
Something that dims the streetlights and shrinks the picture  on  the
neighbours' TVs when you boot it up.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] A question in lowlevel_init.S

2011-01-22 Thread krrish53

Sorry for not mentioning the file name. its here
uboot/arch/arm/cpu/arm920t/at91rm9200/lowlevel_init.S and also in
uboot/board/samsung/smdk2410/lowlevel_init.S 
Thanks for all your responses so far people.


Reinhard Meyer wrote:
> 
> Dear Eric Bénard wrote:
>> Hi,
>>
>> On 22/01/2011 08:39, Reinhard Meyer wrote:
>>> I am not aware of any
> ADD: working
>>> AT91SAM9xxx systems right now that uses low-level init, it
>>> would only make sense for those that boot directly from NOR, without
>>> AT91BOOTSTRAP involved.
>>
>> cpu9260 (at91sam9260 / 9g20 based) is using low-level init as it boots
>> from
>> NOR and is not using at91bootstrap.
> 
> Those CPUs are broken since relocation was introduced. It would be nice to
> see
> them demonstrated working out of NOR with low level init enabled...
> 
> Best Regards,
> Reinhard
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 
> 

-- 
View this message in context: 
http://old.nabble.com/A-question-in-lowlevel_init.S-tp30734554p30737145.html
Sent from the Uboot - Users mailing list archive at Nabble.com.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] Cannot access memory at address 0xd8013fa8 when using gdb/BDI3000 to debug u-boot

2011-01-22 Thread davis mcpherson

I'm trying to get u-boot version 1.3.4 working a custom MPC8548 based 
board (version 1.1.4 currently works fine on this board so the hardware 
is known to be good).  I'm encountering the following problem during the 
early stages of the u-boot initialization and any insights as to what 
the problem may be would be greatly appreciated:

I have a BDI3000 and i'm using gdb for debug sessions.  I started with 
the MPC8548CDS.h as my template for the build configuration file for 
this board.

1) in the start.S file the L1 DCache is configured to be used for 
initial RAM, this occurs in the code at the 'switch_as:' label.  I set 
the CFG_INIT_RAM_ADDR to the value 0xd801 and this value is used to 
configure the L1CFG0 register.
2) execution soon jumps to the '_start_cont:' label and the stack is set 
up in this initial RAM area
3) I set a breakpoint at '_start_cont' and tried to examine the initial 
RAM memory with the gdb 'x' command:
(gdb) x/16x 0xd801
0xd801:Cannot access memory at address 0xd801

So at this point should gdb be able to examine this memory area?

I compared the code in start.S for 1.3.4 with the code from 1.1.4 and 
although not identical the instructions to setup the L1 cache and use it 
for initial RAM end up using the same values and doing the same 
operations...

I can continue to execute code and soon we jump into the c routines 
where the global data pointer is initialized,  attempts to display this 
gd_t structure give the same error message (no surprise there), so I'm 
guessing this structure does not get initialized properly and function 
using it read bogus values...

but I can continue stepping thru the initialzation functions, and for 
example when the console is initialized a long string of garbage shows 
up in the console terminal window, the baudrate comes from the gd_t 
struct so its not what I configured...

so i think this is close to working but something seems broken with 
using the L1 Dcache for initial ram...

thanks in advance for any ideas and suggestion and please let me know if 
there is additional info that might be useful for you to understand the 
problem...

davis mcpherson



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Cannot access memory at address 0xd8013fa8 when using gdb/BDI3000 to debug u-boot

2011-01-22 Thread Wolfgang Denk
Dear davis mcpherson,

In message <4d3b0525.4080...@gmail.com> you wrote:
> 
> I'm trying to get u-boot version 1.3.4 working a custom MPC8548 based 
> board (version 1.1.4 currently works fine on this board so the hardware 
> is known to be good).  I'm encountering the following problem during the 

Sorry, but I don't even continue reading. v1.3.4 is 2.5 years old,
i. e. hopelessly obsolete.  Any efforts on this old stuff are only a
waste of time.

Do yourself (and us) a favour and use current code instead (at least
v2010.12, or bettter current top of tree from the git repository).

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: w...@denx.de
"No problem is so formidable that you can't walk away from it."
- C. Schulz
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] WARNING: in gcc 4.5.0 and 4.5.1 volatile is ignored

2011-01-22 Thread Dirk Behme
On 22.01.2011 13:46, Alexander Holler wrote:
> A patch for write?() and read?() is currently in the
> u-boot-arm-repository (but not in the master and not in 2010.12):
>
> http://lists.denx.de/pipermail/u-boot/2011-January/084885.html

What's about pulling it sooner than later into master, then?

And would it be worth to think about applying this to 2010.12 and 
creating a 2010.12.1?

Best regards

Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] WARNING: in gcc 4.5.0 and 4.5.1 volatile is ignored

2011-01-22 Thread Albert ARIBAUD
Hi Dirk,

Le 22/01/2011 18:40, Dirk Behme a écrit :
> On 22.01.2011 13:46, Alexander Holler wrote:
>> A patch for write?() and read?() is currently in the
>> u-boot-arm-repository (but not in the master and not in 2010.12):
>>
>> http://lists.denx.de/pipermail/u-boot/2011-January/084885.html
>
> What's about pulling it sooner than later into master, then?

I will send out a pull request for u-boot-arm once I have applied all 
outstanding ARM patches from jan 17 or before and all outstanding ARM 
bug fixes regardless of their date, and pulled other ARM repos whose 
custodian requests pulling.

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [RFC] ARM timing code refactoring

2011-01-22 Thread Wolfgang Denk
Dear Albert ARIBAUD,

In message <4d3aaf63.1030...@free.fr> you wrote:
> 
> Agreed for unnecessary mult-div, but 64-bit we would not avoid, and 
> should not IMO, when the HW has it.

When attempting to come up with true generic code, we should probably
_always_ use a (virtual) unsigned 64 bit counter.

> > u32 timeout = timeout_init(100); /* 100ms timeout */
> >
> > do {...} while (!timed_out(timeout));
> >
> > Internally it would be like:
> >
> > timeout_init(x):
> > return fast_tick + (x * fast_tick_rate) / CONFIG_SYS_HZ;
> > /* this might need 64 bit precision in some implementations */
> >
> > time_out(x):
> > return ((i32)(x - fast_tick)) < 0;
> >
> > If the tick were really high speed (and then 64 bits), fast_tick
> > could be derived by shifting the tick some bits to the right.
> 
> The only thing I slightly dislike about the overall idea is the signed 
> rather than unsigned comparison in the timeout function (I prefer using 
> the full 32-bit range, even if only as an academic point) and the fact 
> that the value of the timeout is encoded in advance in the loop control 
> variable 'timeout'.

Please don't.  Use an unsigned counter and allow it to roll over.
Anything else causes additional (and unnecessary) restrictions and
makes the code more complicated.

> I'd rather have a single 'time(x)' (or 'ticks_elapsed(x)', names are 
> negotiable) macro which subtract its argument from the current ticks, 

I'm not sure what you have in mind with "substract".  I strongly
recommend to avoid problems with wrap-around etc. right from the
beginning, and let unsigned arithmentcs handle this for us.

> e.g. 'then = time(0)' would set 'then' to the number of ticks elapsed 
> from boot, while 'now = time(then)' would set 'now' the ticks elapsed 
> from 'then'; and a 'ms_to_ticks(x)' (again, or 'milliseconds(x)') :

Do we really need such a function?  As far as I can tell we don't
really have any time (in the sense of wallclock time) related
requirements, we only need delta times, and nobody really cares about
the starting point.

We should _always_ be able to use the standard approach of

start = get_timer()

while ((get_timer() - start) < timeout) {
... wait ...
}

> Your example would then become
> 
>   then = time(0);
>   do {...} while ( time(then) < ms_to_ticks(100) );

We should NOT do this.  It is bound to break as soon as the code 
in the loop (the "..." part) needs to implement a timeout, too.

>   #define now() time(0)
>   #define ms_elapsed(then,ms) ( time(then) < ms_to_ticks(ms) )

This is not a good isea for the same reason.

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: w...@denx.de
There has been an alarming increase in the number of things you  know
nothing about.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [v4 patch 6/6] SMDK6400: Fix SMDK6400 SDRAM init

2011-01-22 Thread seedshope
On 01/22/2011 03:31 PM, Albert ARIBAUD wrote:
> Hi seedshope,
>
> Le 22/01/2011 02:56, seedshope a écrit :
>
 My patch is ok, I just two tabs in my e-mail, But I sent the mail,
 It is change.
>>> Do you send the patch through git format-patch and git send-email?
>
>> Yes, I use the git format-patch and git send-email
>
>>> Many e-mail softwares have weird issues when posting git patches,
>>> which is why git has its own tools for sending patches via e-mail.
>
>> ok
>
> Since you're using git format-patch and git send-email, then your 
> original change is not correctly aligned. I suggest you check your 
> code editor's settings on indentation and use of tabulations, notably 
> the "tab size": tabs should align on 8-space multiples; also check 
> that your editor uses a fixed font -- you never know.
Hi Amicalement

I check my patch 6 on the 
http://news.gmane.org/gmane.comp.boot-loaders.u-boot, It look fine.
I have a bit despondent. Why do you think it has a format problem.

Thanks
seedshope
>
> Amicalement,

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [v4 patch 6/6] SMDK6400: Fix SMDK6400 SDRAM init

2011-01-22 Thread seedshope
On 01/22/2011 01:52 AM, Sergei Shtylyov wrote:
> Hello.
>
> seedshope wrote:
>
>> Since SDRAM init function have already change, So the SDRAM
>> initial function must be change.
>
> This description sounds somewhat tautological...
>
>> Signed-off-by: seedshope 
>
> Your real name is required in the signoff.
>
>> ---
>> board/samsung/smdk6400/smdk6400.c | 10 +-
>> 1 files changed, 9 insertions(+), 1 deletions(-)
>
>> diff --git a/board/samsung/smdk6400/smdk6400.c 
>> b/board/samsung/smdk6400/smdk6400.c
>> index 35aa40b..1d03b7a 100644
>> --- a/board/samsung/smdk6400/smdk6400.c
>> +++ b/board/samsung/smdk6400/smdk6400.c
>> @@ -78,10 +78,18 @@ int board_init(void)
>> return 0;
>> }
>>
>> -int dram_init(void)
>> +void dram_init_banksize(void)
>> {
>> + DECLARE_GLOBAL_DATA_PTR;
>> +
>> gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
>> gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
>> +}
>> +
>> +int dram_init(void)
>> +{
>> + gd->ram_size = get_ram_size((long *)CONFIG_SYS_SDRAM_BASE,
>> + PHYS_SDRAM_1_SIZE);
You can look at the web 
site(http://news.gmane.org/gmane.comp.boot-loaders.u-boot) for the patch,
It is inconsistent with your description.

Thanks
seedshope
>
> Could you move this last line more to the right?
>
> WBR, Sergei

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] WARNING: in gcc 4.5.0 and 4.5.1 volatile is ignored

2011-01-22 Thread Wolfgang Denk
Dear Albert ARIBAUD,

In message <4d3b1c0c.4040...@free.fr> you wrote:
> 
> Le 22/01/2011 18:40, Dirk Behme a =E9crit :
> > On 22.01.2011 13:46, Alexander Holler wrote:
> >> A patch for write?() and read?() is currently in the
> >> u-boot-arm-repository (but not in the master and not in 2010.12):
> >>
> >> http://lists.denx.de/pipermail/u-boot/2011-January/084885.html
> >
> > What's about pulling it sooner than later into master, then?
> 
> I will send out a pull request for u-boot-arm once I have applied all
> outstanding ARM patches from jan 17 or before and all outstanding ARM
> bug fixes regardless of their date, and pulled other ARM repos whose
> custodian requests pulling.

Thanks - but I also think that Dirk's proposal to create a v2010.12.1
bug fix release makes sense.  What do you think?

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: w...@denx.de
Star Trek Lives!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] U-boot Config Parameters on Compact Flash

2011-01-22 Thread Wolfgang Denk
Dear "Dach Miroslaw",

In message <1b4f8000449511488d1a640dd6deca350392a...@mailbox0a.psi.ch> you 
wrote:
> 
> Could you please direct me to some manual/"how to" to find out how to
> configure IDE 
> access by means of the CONFIG_IDE_* . I have examined several header
> files in u-boot/include/configs
> and it seems to be that CONFIG_ATA_* could be/should be used in
> conjunction with CONFIG_IDE_*?

I'm not an expert with Xilinx FPGAs and have no idea what needs to be
done to enable the ACE in them.  A "grep SYS_ACE" in include/configs/*
turns up only the icon and katmai boards that appearently enable a
Xilinx ACE controll, but these are PPC440SPe boards, i. e. no Xilinx
FPGA based solutions.

You will have to read the respective user manuals yourself.

Or hire an expert.

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: w...@denx.de
Any sufficiently advanced technology is indistinguishable from magic.
Clarke's Third Law   - _Profiles of the Future_ (1962; rev. 1973)
  ``Hazards of Prophecy: The Failure of Imagination''
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] RR v5 PATCH: SMDK6400 Fix some build bug

2011-01-22 Thread seedshope
Change from V1:
patch 1: 
patch 2: Delete some compile information from commit.
patch 3: Add LED modify information and Delete some compile information from 
commit.
patch 4: Add new patch for SDRAM init.

Change from v2:
patch2: Modify Makefile for arch/arm/cpu/arm1176/s3c64xx/cpu_init.s in build 
error.
It will generat redefine information for "mem_ctrl_asm_init" before the Modify.
patch4: Modify the Sergei Shtylyov comments and change the SDRAM size variable
for PHYS_SDRAM_SIZE_1.

Change from v3:
Add new patch 3: I discuss with Amicalement, I find the mutiple-link issue:
The first, the cpu_init.o have already been link for cmd_link_o_target
atfer compile. But, The link script re-link the point file. So the link
machine will generate multiple definition error information.

The second, Since the first 4kB of nand boot featue code move to nand_spl,
So It is not necessary to force the cpu_init.o in non-nand boot.

Delete the cpu_init.o from u-boot-nand.lds is safe.

patch 4: patch 4 and patch 5 is split from v2 patch4.
patch 6: Modify according Minkyu Kang comment

Change from v4
1. Modify Signed-off-by for all the patch
2. Modify patch6 for the Sergei, Minkyu and Thomas comments.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [v5 patch 1/6] SMDK6400: Fix CONFIG_SYS_INIT_SP_ADDR undefined

2011-01-22 Thread seedshope
Fix CONFIG_SYS_INIT_SP_ADDR undefined issue.

Signed-off-by: Zhong Hongbo 

diff --git a/include/configs/smdk6400.h b/include/configs/smdk6400.h
index 671f2c7..c9acf58 100644
--- a/include/configs/smdk6400.h
+++ b/include/configs/smdk6400.h
@@ -44,6 +44,11 @@
 #define CONFIG_PERIPORT_BASE   0x7000
 #define CONFIG_PERIPORT_SIZE   0x13
 
+#define CONFIG_SYS_IRAM_BASE0x0c00  /* Internal SRAM base address */
+#define CONFIG_SYS_IRAM_SIZE0x2000  /* 8 KB of internal SRAM memory */
+#define CONFIG_SYS_IRAM_END (CONFIG_SYS_IRAM_BASE + CONFIG_SYS_IRAM_SIZE)
+#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_IRAM_END - GENERATED_GBL_DATA_SIZE)
+
 #define CONFIG_SYS_SDRAM_BASE  0x5000
 
 /* input clock of PLL: SMDK6400 has 12MHz input clock */
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [v5 patch 2/6] SMDK6400: Fix some label undefined in build error

2011-01-22 Thread seedshope
Modify Makefile for cpu_init.c and Start.s use some label,this defined
u-boot.lds of arch/arm/cpu/arm1176. But SMDK6400 use the link script
board/samsung/smdk6400/u-boot-nand.lds. So add some label form u-boot.lds
to u-boot-nand.lds

Signed-off-by: Zhong Hongbo 

diff --git a/board/samsung/smdk6400/u-boot-nand.lds 
b/board/samsung/smdk6400/u-boot-nand.lds
index 29a4f61..6771981 100644
--- a/board/samsung/smdk6400/u-boot-nand.lds
+++ b/board/samsung/smdk6400/u-boot-nand.lds
@@ -56,7 +56,28 @@ SECTIONS
.mmudata : { *(.mmudata) }
 
. = ALIGN(4);
-   __bss_start = .;
-   .bss : { *(.bss) . = ALIGN(4); }
-   _end = .;
+
+   .rel.dyn : {
+   __rel_dyn_start = .;
+   *(.rel*)
+   __rel_dyn_end = .;
+   }
+
+   .dynsym : {
+   __dynsym_start = .;
+   *(.dynsym)
+   }
+
+   .bss __rel_dyn_start (OVERLAY) : {
+   __bss_start = .;
+   *(.bss)
+   . = ALIGN(4);
+   _end = .;
+   }
+
+   /DISCARD/ : { *(.dynstr*) }
+   /DISCARD/ : { *(.dynamic*) }
+   /DISCARD/ : { *(.plt*) }
+   /DISCARD/ : { *(.interp*) }
+   /DISCARD/ : { *(.gnu*) }
 }
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [v5 patch 3/6] SMDK6400: Fix the mutiple link error

2011-01-22 Thread seedshope
The first, the cpu_init.o have already been link for cmd_link_o_target
atfer compile, But, The link script re-link the point file. So the link
machine will generate multiple definition error information.

The second, Since the first 4kB of nand boot featue code move to nand_spl,
So It is not necessary to force the cpu_init.o in non-nand boot.

Signed-off-by: Zhong Hongbo 

diff --git a/board/samsung/smdk6400/u-boot-nand.lds 
b/board/samsung/smdk6400/u-boot-nand.lds
index 6771981..6bf4971 100644
--- a/board/samsung/smdk6400/u-boot-nand.lds
+++ b/board/samsung/smdk6400/u-boot-nand.lds
@@ -35,7 +35,6 @@ SECTIONS
.text  :
{
  arch/arm/cpu/arm1176/start.o  (.text)
- arch/arm/cpu/arm1176/s3c64xx/cpu_init.o   (.text)
  *(.text)
}
 
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [v5 patch 4/6] SMDK6400: Add some labels to u-boot.lds to support nand_spl

2011-01-22 Thread seedshope
In the nand_spl feature of SMDK6400. Add some relocation symbols to
nand_spl/board/samsung/smdk6400/u-boot.lds to fix the compile error.

Signed-off-by: Zhong Hongbo 

diff --git a/nand_spl/board/samsung/smdk6400/u-boot.lds 
b/nand_spl/board/samsung/smdk6400/u-boot.lds
index 3ac6aa1..30b1573 100644
--- a/nand_spl/board/samsung/smdk6400/u-boot.lds
+++ b/nand_spl/board/samsung/smdk6400/u-boot.lds
@@ -55,7 +55,22 @@ SECTIONS
__u_boot_cmd_end = .;
 
. = ALIGN(4);
+
+   .rel.dyn : {
+   __rel_dyn_start = .;
+   *(.rel*)
+   __rel_dyn_end = .;
+   }
+
+   .dynsym : {
+   __dynsym_start = .;
+   *(.dynsym)
+   }
+
+   .bss __rel_dyn_start (OVERLAY) : {
__bss_start = .;
-   .bss : { *(.bss) . = ALIGN(4); }
+   *(.bss)
+   . = ALIGN(4);
_end = .;
+   }
 }
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [v5 patch 5/6] SMDK6400: Disable LED function in start.s on the nand booting

2011-01-22 Thread seedshope
Since nand boot have some limit for the first 4KB, We only
disable the LED function to reduce the code space. At the
same time, Fix the compile error for LED function undefined
in the compile time of nand_spl.

Signed-off-by: Zhong Hongbo 

diff --git a/arch/arm/cpu/arm1176/start.S b/arch/arm/cpu/arm1176/start.S
index 237dcfe..ae3706a 100644
--- a/arch/arm/cpu/arm1176/start.S
+++ b/arch/arm/cpu/arm1176/start.S
@@ -354,9 +354,11 @@ clbss_l:strr2, [r0]/* clear 
loop...*/
cmp r0, r1
bne clbss_l
 
+#ifndef CONFIG_NAND_SPL
bl coloured_LED_init
bl red_LED_on
 #endif
+#endif
 
 /*
  * We are done. Do not return, instead branch to second part of board
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [v5 patch 6/6] SMDK6400: Fixup dram_init for relocation support

2011-01-22 Thread seedshope
Signed-off-by: Zhong Hongbo 

diff --git a/board/samsung/smdk6400/smdk6400.c 
b/board/samsung/smdk6400/smdk6400.c
index 35aa40b..13c7ed5 100644
--- a/board/samsung/smdk6400/smdk6400.c
+++ b/board/samsung/smdk6400/smdk6400.c
@@ -78,10 +78,16 @@ int board_init(void)
return 0;
 }
 
-int dram_init(void)
+void dram_init_banksize(void)
 {
gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
+}
+
+int dram_init(void)
+{
+   gd->ram_size = get_ram_size((long *)CONFIG_SYS_SDRAM_BASE,
+   PHYS_SDRAM_1_SIZE);
 
return 0;
 }
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] U-boot Config Parameters on Compact Flash

2011-01-22 Thread Dach Miroslaw
Dear Wolfgang,

Thank you very much for your hints. This is a good staring point for me to 
continue with u-boot and Compact Flash.

Best Regards

Miroslaw Dach



-Original Message-
From: Wolfgang Denk [mailto:w...@denx.de]
Sent: Sat 1/22/2011 8:39 PM
To: Dach Miroslaw
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] U-boot Config Parameters on Compact Flash
 
Dear "Dach Miroslaw",

In message <1b4f8000449511488d1a640dd6deca350392a...@mailbox0a.psi.ch> you 
wrote:
> 
> Could you please direct me to some manual/"how to" to find out how to
> configure IDE 
> access by means of the CONFIG_IDE_* . I have examined several header
> files in u-boot/include/configs
> and it seems to be that CONFIG_ATA_* could be/should be used in
> conjunction with CONFIG_IDE_*?

I'm not an expert with Xilinx FPGAs and have no idea what needs to be
done to enable the ACE in them.  A "grep SYS_ACE" in include/configs/*
turns up only the icon and katmai boards that appearently enable a
Xilinx ACE controll, but these are PPC440SPe boards, i. e. no Xilinx
FPGA based solutions.

You will have to read the respective user manuals yourself.

Or hire an expert.

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: w...@denx.de
Any sufficiently advanced technology is indistinguishable from magic.
Clarke's Third Law   - _Profiles of the Future_ (1962; rev. 1973)
  ``Hazards of Prophecy: The Failure of Imagination''

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [RFC] ARM timing code refactoring

2011-01-22 Thread Albert ARIBAUD
Hi Wolfgang,

Le 22/01/2011 20:19, Wolfgang Denk a écrit :

> Dear Albert ARIBAUD,

>> Agreed for unnecessary mult-div, but 64-bit we would not avoid, and
>> should not IMO, when the HW has it.
>
> When attempting to come up with true generic code, we should probably
> _always_ use a (virtual) unsigned 64 bit counter.

That's fine with me. We'll just have to keep in mind that with a 32-bit 
HW counter, the upper 32 bits of the 64-bit virtual counter must be 
managed by SW -- which should not prove to be too much of a problem, but 
will force us to handle HW-to-SW rollovers in get_timer() on each 
virtual timer reads.

>>> If the tick were really high speed (and then 64 bits), fast_tick
>>> could be derived by shifting the tick some bits to the right.
>>
>> The only thing I slightly dislike about the overall idea is the signed
>> rather than unsigned comparison in the timeout function (I prefer using
>> the full 32-bit range, even if only as an academic point) and the fact
>> that the value of the timeout is encoded in advance in the loop control
>> variable 'timeout'.
>
> Please don't.  Use an unsigned counter and allow it to roll over.
> Anything else causes additional (and unnecessary) restrictions and
> makes the code more complicated.

Hmm... don't we actually agree here? I was also expressing my preference 
for unsigned.

>> I'd rather have a single 'time(x)' (or 'ticks_elapsed(x)', names are
>> negotiable) macro which subtract its argument from the current ticks,
>
> I'm not sure what you have in mind with "substract".  I strongly
> recommend to avoid problems with wrap-around etc. right from the
> beginning, and let unsigned arithmentcs handle this for us.

That's what I meant with my comment about subtracting: the difference of 
two unsigned integers is always correct.

>> e.g. 'then = time(0)' would set 'then' to the number of ticks elapsed
>> from boot, while 'now = time(then)' would set 'now' the ticks elapsed
>> from 'then'; and a 'ms_to_ticks(x)' (again, or 'milliseconds(x)') :
>
> Do we really need such a function?  As far as I can tell we don't
> really have any time (in the sense of wallclock time) related
> requirements, we only need delta times, and nobody really cares about
> the starting point.

Hmm... My idea with providing time() with an argument was that precisely 
since we are interested only in elapsed time, not absolute time, our 
basic time function should be able to tell us relative times.

> We should _always_ be able to use the standard approach of
>
>   start = get_timer()
>
>   while ((get_timer() - start)<  timeout) {
> suall ... wait ...
>   }

Functionally this is the same as what I suggested, minus the absolute 
get_timer() vs relative time(x) call. Either way works, I'm not going to 
try and make a point that we use "my" time(x).

We still need ms-to-tick and us-to-tick conversions, though, because 
usually timing constraints will be expressed in us or ms, not in ticks.

Just one thing, however:

>> Your example would then become
>>
>>  then = time(0);
>>  do {...} while ( time(then)<  ms_to_ticks(100) );
>
> We should NOT do this.  It is bound to break as soon as the code
> in the loop (the "..." part) needs to implement a timeout, too.

I'm not sure to understand why. Can you develop how you think this would 
break with an inner timeout?

>>  #define now() time(0)
>>  #define ms_elapsed(then,ms) ( time(then)<  ms_to_ticks(ms) )
>
> This is not a good isea for the same reason.

Those two were just syntactic sugaring anyway; if you don't like them, 
no worries.

> Best regards,
>
> Wolfgang Denk

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] WARNING: in gcc 4.5.0 and 4.5.1 volatile is ignored

2011-01-22 Thread Albert ARIBAUD
Le 22/01/2011 20:30, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4d3b1c0c.4040...@free.fr>  you wrote:
>>
>> Le 22/01/2011 18:40, Dirk Behme a =E9crit :
>>> On 22.01.2011 13:46, Alexander Holler wrote:
 A patch for write?() and read?() is currently in the
 u-boot-arm-repository (but not in the master and not in 2010.12):

 http://lists.denx.de/pipermail/u-boot/2011-January/084885.html
>>>
>>> What's about pulling it sooner than later into master, then?
>>
>> I will send out a pull request for u-boot-arm once I have applied all
>> outstanding ARM patches from jan 17 or before and all outstanding ARM
>> bug fixes regardless of their date, and pulled other ARM repos whose
>> custodian requests pulling.
>
> Thanks - but I also think that Dirk's proposal to create a v2010.12.1
> bug fix release makes sense.  What do you think?

I didn't comment on this point as it was not for me to decide upon 
releasing an interim U-boot version :) but I'm fine with it if you do. 
When I rebase on u-boot/master before sending my pull request, I'll 
simply skip the corresponding patch in my tree as it will already be on 
yours.

> Best regards,
>
> Wolfgang Denk

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [v4 patch 6/6] SMDK6400: Fix SMDK6400 SDRAM init

2011-01-22 Thread Albert ARIBAUD
Hi seedshope,

Le 22/01/2011 20:23, seedshope a écrit :

> Hi Amicalement

That's Albert, actually. :)

> I check my patch 6 on the
> http://news.gmane.org/gmane.comp.boot-loaders.u-boot, It look fine.
> I have a bit despondent. Why do you think it has a format problem.

V5 of your patch has one more tab on as V4 had on the line we're 
discussion. It is a bit better ; Sergei will tell if that's enough for him.

> Thanks
> seedshope

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V5 0/5] Add Pantheon soc and dkb board support

2011-01-22 Thread Prafulla Wadaskar


> -Original Message-
> From: Lei Wen [mailto:lei...@marvell.com]
> Sent: Wednesday, January 19, 2011 12:13 AM
> To: Wolfgang Denk; u-boot@lists.denx.de; Prafulla Wadaskar; Yu Tang;
> Ashish Karkare; Prabhanjan Sarnaik; Lei Wen
> Subject: [PATCH V5 0/5] Add Pantheon soc and dkb board support
> 
> This patch set add the Pantheon soc and dkb board support.
> 
> V2:
> This patch seris update the seperate mv_common part as suggested.
> 
> V3:
> Fix config.h include place and copyright claim year.
> 
> V4:
> Add change log to each patch.
> 
> V5:
> Add doc in Readme for new CONFIG_SYS_MVFS.
> code style fix.
> 
> Lei Wen (5):
>   mv: seperate kirkwood and armada from common setting
>   ARM: Add Support for Marvell Pantheon Familiy SoCs
>   serial: add pantheon soc support
>   mvmfp: add MFP configuration support for PANTHEON
>   Pantheon: Add Board Support for Marvell dkb board
> 
>  MAINTAINERS   |4 +
>  README|5 +
>  arch/arm/cpu/arm926ejs/pantheon/Makefile  |   46 ++
>  arch/arm/cpu/arm926ejs/pantheon/cpu.c |   78 +
>  arch/arm/cpu/arm926ejs/pantheon/dram.c|  132 
>  arch/arm/cpu/arm926ejs/pantheon/timer.c   |  207
> +
>  arch/arm/include/asm/arch-armada100/config.h  |   50 ++
>  arch/arm/include/asm/arch-kirkwood/config.h   |  145 +
>  arch/arm/include/asm/arch-pantheon/config.h   |   44 ++
>  arch/arm/include/asm/arch-pantheon/cpu.h  |   79 ++
>  arch/arm/include/asm/arch-pantheon/mfp.h  |   41 +
>  arch/arm/include/asm/arch-pantheon/pantheon.h |   54 +++
>  board/Marvell/dkb/Makefile|   51 ++
>  board/Marvell/dkb/dkb.c   |   53 +++
>  boards.cfg|1 +
>  drivers/gpio/mvmfp.c  |2 +
>  drivers/serial/serial.c   |2 +
>  include/configs/aspenite.h|1 +
>  include/configs/dkb.h |   62 
>  include/configs/mv-common.h   |  147 +++---
>  20 files changed, 1078 insertions(+), 126 deletions(-)
>  create mode 100644 arch/arm/cpu/arm926ejs/pantheon/Makefile
>  create mode 100644 arch/arm/cpu/arm926ejs/pantheon/cpu.c
>  create mode 100644 arch/arm/cpu/arm926ejs/pantheon/dram.c
>  create mode 100644 arch/arm/cpu/arm926ejs/pantheon/timer.c
>  create mode 100644 arch/arm/include/asm/arch-armada100/config.h
>  create mode 100644 arch/arm/include/asm/arch-kirkwood/config.h
>  create mode 100644 arch/arm/include/asm/arch-pantheon/config.h
>  create mode 100644 arch/arm/include/asm/arch-pantheon/cpu.h
>  create mode 100644 arch/arm/include/asm/arch-pantheon/mfp.h
>  create mode 100644 arch/arm/include/asm/arch-pantheon/pantheon.h
>  create mode 100644 board/Marvell/dkb/Makefile
>  create mode 100644 board/Marvell/dkb/dkb.c
>  create mode 100644 include/configs/dkb.h

This patch series looks okay to me.

Acked-by: Prafulla Wadaskar 

Regards..
Prafulla . . .

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [v4 patch 6/6] SMDK6400: Fix SMDK6400 SDRAM init

2011-01-22 Thread seedshope
On 01/23/2011 04:28 AM, Albert ARIBAUD wrote:
> Hi seedshope,
>
> Le 22/01/2011 20:23, seedshope a écrit :
>
>> Hi Amicalement
>
> That's Albert, actually. :)
>
>> I check my patch 6 on the
>> http://news.gmane.org/gmane.comp.boot-loaders.u-boot, It look fine.
>> I have a bit despondent. Why do you think it has a format problem.
>
> V5 of your patch has one more tab on as V4 had on the line we're 
> discussion. It is a bit better ; Sergei will tell if that's enough for 
> him.
yes,  I just found the error in web site. I miss something in my 
thunderbird. such as tab convert space, So the format is change.
Here, I beg you to forgot my miss.

BR
seedshope
>> Thanks
>> seedshope
>
> Amicalement,

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [RFC] ARM timing code refactoring

2011-01-22 Thread Wolfgang Denk
Dear Albert ARIBAUD,

In message <4d3b3b5c.2060...@free.fr> you wrote:
> 
> > When attempting to come up with true generic code, we should probably
> > _always_ use a (virtual) unsigned 64 bit counter.
> 
> That's fine with me. We'll just have to keep in mind that with a 32-bit 
> HW counter, the upper 32 bits of the 64-bit virtual counter must be 
> managed by SW -- which should not prove to be too much of a problem, but 
> will force us to handle HW-to-SW rollovers in get_timer() on each 
> virtual timer reads.

Yes.

> >> The only thing I slightly dislike about the overall idea is the signed
> >> rather than unsigned comparison in the timeout function (I prefer using
> >> the full 32-bit range, even if only as an academic point) and the fact
> >> that the value of the timeout is encoded in advance in the loop control
> >> variable 'timeout'.
> >
> > Please don't.  Use an unsigned counter and allow it to roll over.
> > Anything else causes additional (and unnecessary) restrictions and
> > makes the code more complicated.
> 
> Hmm... don't we actually agree here? I was also expressing my preference 
> for unsigned.

I'm happy if we agree. I just wan't sure.

> > I'm not sure what you have in mind with "substract".  I strongly
> > recommend to avoid problems with wrap-around etc. right from the
> > beginning, and let unsigned arithmentcs handle this for us.
> 
> That's what I meant with my comment about subtracting: the difference of 
> two unsigned integers is always correct.

Good.

> >> e.g. 'then = time(0)' would set 'then' to the number of ticks elapsed
> >> from boot, while 'now = time(then)' would set 'now' the ticks elapsed
> >> from 'then'; and a 'ms_to_ticks(x)' (again, or 'milliseconds(x)') :
> >
> > Do we really need such a function?  As far as I can tell we don't
> > really have any time (in the sense of wallclock time) related
> > requirements, we only need delta times, and nobody really cares about
> > the starting point.
> 
> Hmm... My idea with providing time() with an argument was that precisely 
> since we are interested only in elapsed time, not absolute time, our 
> basic time function should be able to tell us relative times.

The disadvantage of this approach is that such calls cannot be nested,
i. e. you must always make sure that the code run within the timeout
loop does not attempt to set up a timeout on it's own.  From my point
of view, this is a killing point.

> Functionally this is the same as what I suggested, minus the absolute 
> get_timer() vs relative time(x) call. Either way works, I'm not going to 
> try and make a point that we use "my" time(x).

See above for the fundamental difference - not in the implementation
for a single timeout, but from a system-wide point of view.

> >>then = time(0);
> >>do {...} while ( time(then)<  ms_to_ticks(100) );
> >
> > We should NOT do this.  It is bound to break as soon as the code
> > in the loop (the "..." part) needs to implement a timeout, too.
> 
> I'm not sure to understand why. Can you develop how you think this would 
> break with an inner timeout?

Sure:

/* implement something which needs a 100 ms timeout */
then = time(0);

do {
int then_nested;
... do something...
... do more...
/* now do something which needs a 5 ms timeout */
then_nested = time(0);
do {
...
} while (time(then_nested) < ms_to_ticks(5));

} while (time(then) < ms_to_ticks(100));

You see the problem?


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: w...@denx.de
Remember, there's a big difference between kneeling down and  bending
over.   - Frank Zappa
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [v4 patch 6/6] SMDK6400: Fix SMDK6400 SDRAM init

2011-01-22 Thread Wolfgang Denk
Dear seedshope,

In message <4d3b40ac.8090...@gmail.com> you wrote:
>
> yes,  I just found the error in web site. I miss something in my
> thunderbird. such as tab convert space, So the format is change.
> Here, I beg you to forgot my miss.

It is usually helpful to search for and read the available documentation.

See file Documentation/email-clients.txt in your Linux source tree, or:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/email-clients.txt

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: w...@denx.de
In a business, marketroids, salespukes, and  lawyers  have  different
goals from those who actually do work and produce something. Usually,
is  is the former who triumph over the latter, due to the simple rule
that those who print the money make the rules.
 -- Tom Christiansen in <5jdcls$b04$2...@csnews.cs.colorado.edu>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [RFC] ARM timing code refactoring

2011-01-22 Thread Reinhard Meyer
Dear Wolfgang Denk,
> Dear Albert ARIBAUD,

With all this half quoting and deleting of important parts,
my original proposal was lost again.

If you really care to look at it, it

1. does not have issues with rollover
2. does not have problems with nested timeouts
3. does 64 bit mul/div calculations only once at the begin of a timeout
4. is easy and straightforward to use
5. needs very few lines of code to implement

Calculating the end time at the begin of a loop is not a problem,
I am not aware of any timeout loops where the timeout value needs to be changed
inside the loop.

Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 3/8 v2] Introduce the Tertiary Program loader

2011-01-22 Thread Wolfgang Denk
Dear haiying.w...@freescale.com,

In message <1291217737-3870-4-git-send-email-haiying.w...@freescale.com> you 
wrote:
> From: Haiying Wang 
> 
> TPL is introduced to enable a loader stub that boots out of some type of RAM,
> after being loaded by an SPL or similar platform-specific mechanism.
> 
> One example of using this tpl loader is to initialize the ddr through spd code
> in case the L2 SRAM size is not big enough to hold the final uboot image and
> the nand spl code needs to be limitated to 4K byte, then tpl code will load 
> the
> final uboot image after ddr is initialized.
> 
> Signed-off-by: Haiying Wang 
> ---
> Incorporate Mike's comment to use new variable NAND_SPL_OBJS-y
>  Makefile |   17 +++--
>  README   |   27 +++
>  2 files changed, 42 insertions(+), 2 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index 87a383d..94af465 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -290,6 +290,10 @@ LDPPFLAGS += \
>   $(shell $(LD) --version | \
> sed -ne 's/GNU ld version 
> \([0-9][0-9]*\)\.\([0-9][0-9]*\).*/-DLD_MAJOR=\1 -DLD_MINOR=\2/p')
>  
> +ifeq ($(CONFIG_TPL_U_BOOT),y)
> +TPL_BOOT = tpl
> +endif

I don't understand what the "TPL_BOOT" is good for, or how it's
supposed to work.

>  ifeq ($(CONFIG_NAND_U_BOOT),y)
>  NAND_SPL = nand_spl
>  U_BOOT_NAND = $(obj)u-boot-nand.bin
> @@ -407,8 +411,15 @@ $(obj)u-boot.lds: $(LDSCRIPT)
>  $(NAND_SPL): $(TIMESTAMP_FILE) $(VERSION_FILE) depend
>   $(MAKE) -C nand_spl/board/$(BOARDDIR) all
>  
> -$(U_BOOT_NAND):  $(NAND_SPL) $(obj)u-boot.bin
> - cat $(obj)nand_spl/u-boot-spl-16k.bin $(obj)u-boot.bin > 
> $(obj)u-boot-nand.bin
> +$(TPL_BOOT): $(TIMESTAMP_FILE) $(VERSION_FILE) depend
> + $(MAKE) -C tpl/board/$(BOARDDIR) all

Assume CONFIG_TPL_U_BOOT is not defined, then TPL_BOOT is not defined,
and this rule will probably cause a build error, doesn't it?

Has this code ever been tested?


And if we use a variable for the "tlp" string, should this not be

...
$(MAKE) -C $(TPL_BOOT)/board/$(BOARDDIR) all

??

> +NAND_SPL_OBJS-y += $(obj)nand_spl/u-boot-spl-16k.bin
> +NAND_SPL_OBJS-$(CONFIG_TPL_U_BOOT) += $(obj)tpl/u-boot-tpl.bin
> +NAND_SPL_OBJS-y += $(obj)u-boot.bin

Ditto here and in the following - but how is NAND_SPL related to TPL
building? These should be completely independent?

> +- TPL Boot Support
> + CONFIG_TPL_U_BOOT
> +
> + Builds a U-Boot image that contains a loader stub (tertiary
> + program loader -- TPL) that boots out of some type of RAM,
> + after being loaded by an SPL or similar platform-specific
> + mechanism.  This symbol will be set in all build phases.
> +
> + CONFIG_TPL_BOOT
> +
> + This is set by the build system when compiling code to go into
> + the TPL.  It is not set when building the code that the TPL
> + loads, or when building the SPL.

Can we not do with a single variable definition?

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: w...@denx.de
Things that try to look like things often do look  more  like  things
than things. Well-known fact.   - Terry Pratchett, _Wyrd Sisters_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 3/8 v2] Introduce the Tertiary Program loader

2011-01-22 Thread Wolfgang Denk
Dear Kumar Gala,

In message  you wrote:
> 
> Did you plan on review this patch?

Just done - I wonder if this code has ever been tested at all?

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: w...@denx.de
You can observe a lot just by watchin'.  - Yogi Berra
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 4/8 v2] powerpc/85xx: add TPL_BOOT support

2011-01-22 Thread Wolfgang Denk
Dear haiying.w...@freescale.com,

In message <1291218463-4211-1-git-send-email-haiying.w...@freescale.com> you 
wrote:
> From: Haiying Wang 
> 
> Signed-off-by: Haiying Wang 
> ---
> Splitted from TPL patch to only address 85xx changes
>  arch/powerpc/cpu/mpc85xx/cpu_init_nand.c |   34 ++-
>  arch/powerpc/cpu/mpc85xx/start.S |   12 ++--
>  arch/powerpc/cpu/mpc85xx/u-boot-tpl.lds  |   99 
> ++
>  3 files changed, 137 insertions(+), 8 deletions(-)
>  create mode 100644 arch/powerpc/cpu/mpc85xx/u-boot-tpl.lds
...
> - * Copyright 2009 Freescale Semiconductor, Inc.
> + * Copyright 2010 Freescale Semiconductor, Inc.

You should not undo a previous copyright.  I guess you mean:

  Copyright 2009-2010 Freescale Semiconductor, Inc.

?

> +DECLARE_GLOBAL_DATA_PTR;

Please move this up to top of file.

> +unsigned long get_tbclk(void)
> +{
> +#ifdef CONFIG_FSL_CORENET
> + return (gd->bus_clk + 8) / 16;
> +#else
> + return (gd->bus_clk + 4UL)/8UL;
> +#endif

This looks inconsistent. Either this should be "... +8UL) / 16UL" or
"... + 4) / 8;"

> -#ifndef CONFIG_NAND_SPL
> +#if !defined(CONFIG_NAND_SPL) && !defined(CONFIG_TPL_BOOT)
>   GOT_ENTRY(_start)
>   GOT_ENTRY(_start_of_vectors)
>   GOT_ENTRY(_end_of_vectors)
>   GOT_ENTRY(transfer_to_handler)
> -#endif
> +#endif /* !CONFIG_TPL_BOOT || !CONFIG_NAND_SPL*/

Should that be

   #endif /* !CONFIG_TPL_BOOT && !CONFIG_NAND_SPL*/

instead?

And can we please make this consistent, i. e. as you do in the
following:

> +#endif  /* !CONFIG_NAND_SPL && !CONFIG_TPL_BOOT */

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: w...@denx.de
The price of curiosity is a terminal experience.
 - Terry Pratchett, _The Dark Side of the Sun_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [RFC] ARM timing code refactoring

2011-01-22 Thread Albert ARIBAUD
Le 22/01/2011 22:26, Wolfgang Denk a écrit :

>> Hmm... My idea with providing time() with an argument was that precisely
>> since we are interested only in elapsed time, not absolute time, our
>> basic time function should be able to tell us relative times.
>
> The disadvantage of this approach is that such calls cannot be nested,
> i. e. you must always make sure that the code run within the timeout
> loop does not attempt to set up a timeout on it's own.  From my point
> of view, this is a killing point.
>
>> Functionally this is the same as what I suggested, minus the absolute
>> get_timer() vs relative time(x) call. Either way works, I'm not going to
>> try and make a point that we use "my" time(x).
>
> See above for the fundamental difference - not in the implementation
> for a single timeout, but from a system-wide point of view.
>
then = time(0);
do {...} while ( time(then)<   ms_to_ticks(100) );
>>>
>>> We should NOT do this.  It is bound to break as soon as the code
>>> in the loop (the "..." part) needs to implement a timeout, too.
>>
>> I'm not sure to understand why. Can you develop how you think this would
>> break with an inner timeout?
>
> Sure:
>
>   /* implement something which needs a 100 ms timeout */
>   then = time(0);
>
>   do {
>   int then_nested;
>   ... do something...
>   ... do more...
>   /* now do something which needs a 5 ms timeout */
>   then_nested = time(0);
>   do {
>   ...
>   } while (time(then_nested)<  ms_to_ticks(5));
>
>   } while (time(then)<  ms_to_ticks(100));
>
> You see the problem?

Actually no, I don't. As a reminder, I am considering the following 
definitions:

#define time(n) (ticks-n)
#define ms_to_ticks(ms) (ms * fast_tick_rate) / CONFIG_SYS_HZ

Neither of these has any side effect, so I am at loss as to why that 
would break when used in nested loops; each loop has its own reference 
start time by assigning time(0) to its own variable (then and 
then_nested), and each has its own elapsed time computation by passing 
its own variable to time() and comparing with its own constant timeout 
value. Can you point the exact instruction that would break in the code 
above, and why it would?

> Best regards,
>
> Wolfgang Denk

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot