[U-Boot-Users] PXA270 support
wd at denx.de
Tue Mar 15 01:00:53 CET 2005
In message <71555548814716479478431542AA5F8A01B1B6D9 at dlee2k04.ent.ti.com> you wrote:
> Ok. The kernel's HZ value is variable on many architectures, so by the
> same token I would say u-boots could be also. It should never be
Yes, it is variable, and this is why you can configure it through
> assumed that CFG_HZ is 1000. Perhaps by convention it's a good rate for
> the few PPC systems which actually use the clock interrupt to do
This is your interpretation.
Sorry, but it is not up to you to redefine the meaning of a variable
at your liking.
> For ARM, it turns out to be convenient to assign the tick generator to
> be CFG_HZ value. This saves on a little math.
Maybe. Feel free to use any other definition then, but please do NOT
use CFG_HZ for this which serves a different purpose.
Also be aware that assinging arbitray values may cause lots of problems
like integer overflows:
Configuring for dbau1x00 board...
net.c: In function `NetStartAgain':
net.c:565: warning: integer overflow in expression
nfs.c: In function `NfsHandler':
nfs.c:671: warning: integer overflow in expression
nfs.c: In function `NfsStart':
nfs.c:760: warning: integer overflow in expression
This comes from simple statements like setting up a 10 seconds
timeout using "10 * CFG_HZ".
*DO NOT MISUSE CFG_HZ*. Period.
> I can see where it might be better to assign it to match the rate your
> target kernel would use, but it is probably not necessary as the kernel
> should re-init it anyway.
The kernel can do whatever it likes.
Nevertheless, please do not continue to misuse CFG_HZ for other
purposes than it was intended for. I will reject any patches which
continue to contain such code (sorry it took me that long to even
become aware of such misuse).
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
In C we had to code our own bugs, in C++ we can inherit them.
More information about the U-Boot