[U-Boot-Users] PXA270 support

[U-Boot-Users] PXA270 support

[Detlef Vollmann]

Hello,

has anybody tried to port u-boot to a PXA270 based board?
I just started with lifting the startup code from Intel's blob
into u-boot, and with a little work made it compile and link.
But (of course) it is not that easy: it doesn't work :-(

Before I now start the long debugging sessions I just thought
I'd try the list.  Maybe somebody has something working for
a PXA27x.

Any hints welcome
Detlef

-- 
Detlef Vollmann   vollmann engineering gmbh
Linux and C++ for Embedded Systems    http://www.vollmann.ch/

[U-Boot-Users] PXA270 support

[Robert Whaley]

Detlef Vollmann wrote:
> Hello,
> 
> has anybody tried to port u-boot to a PXA270 based board?
> I just started with lifting the startup code from Intel's blob
> into u-boot, and with a little work made it compile and link.
> But (of course) it is not that easy: it doesn't work :-(
> 
> Before I now start the long debugging sessions I just thought
> I'd try the list.  Maybe somebody has something working for
> a PXA27x.
> 
> Any hints welcome
> Detlef
> 

Attached is a patch from

http://sourceforge.net/mailarchive/message.php?msg_id=10171505

Also see this prerequisite:

http://sourceforge.net/mailarchive/message.php?msg_id=10171504

And this if you need MMC to work with the PXA27x.

http://sourceforge.net/mailarchive/message.php?msg_id=10171504
-------------- next part --------------
A non-text attachment was scrubbed...
Name: adsvix.diff.gz
Type: application/gzip
Size: 9915 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20050311/f5836f5e/attachment.bin 

[U-Boot-Users] PXA270 support

[Detlef Vollmann]

Robert Whaley wrote:
> Detlef Vollmann wrote:
> > has anybody tried to port u-boot to a PXA270 based board?
> 
> Attached is a patch from
> 
> http://sourceforge.net/mailarchive/message.php?msg_id=10171505
Great.  Thanks, having this it was quite easy to port to my
board.

But I have one question left: in your config file adsvix.h,
you have
#define CFG_HZ                  3686400
but the external clock for a PXA27x should be 13MHz.
I used the same value as you, and it works fine, but what
clock is that (or is it ignored)?

Detlef

-- 
Detlef Vollmann   vollmann engineering gmbh
Linux and C++ for Embedded Systems    http://www.vollmann.ch/

[U-Boot-Users] PXA270 support

[Robert Whaley]

Hi Detlef,

Try timing the sleep command.  Is it accurate?  Take a look at 
cpu/pxa/interrupts.c.

I believe the CFG is correct in the patch (but I haven't looked at this 
for a while).  If you think it needs to be changed after checking sleep 
and udelay, please let me know!

Robert

Detlef Vollmann wrote:
> Robert Whaley wrote:
> 
>>Detlef Vollmann wrote:
>>
>>>has anybody tried to port u-boot to a PXA270 based board?
>>
>>Attached is a patch from
>>
>>http://sourceforge.net/mailarchive/message.php?msg_id=10171505
> 
> Great.  Thanks, having this it was quite easy to port to my
> board.
> 
> But I have one question left: in your config file adsvix.h,
> you have
> #define CFG_HZ                  3686400
> but the external clock for a PXA27x should be 13MHz.
> I used the same value as you, and it works fine, but what
> clock is that (or is it ignored)?
> 
> Detlef
> 

[U-Boot-Users] PXA270 support

[Wolfgang Denk]

In message <4235F2BE.33D9091A@vollmann.ch> you wrote:
>
> But I have one question left: in your config file adsvix.h,
> you have
> #define CFG_HZ                  3686400
> but the external clock for a PXA27x should be 13MHz.

Note: this is BROKEN.

CFG_HZ should be 1000 on all boards. it has NOTHING to  do  with  any
clock  frequencies of your baord or processor (yes, I know that quite
a lot of boards are broken this way).

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Why is an average signature file longer than an average Perl script??

[U-Boot-Users] PXA270 support

[Woodruff, Richard]

Wolfgang,

> Note: this is BROKEN.
> 
> CFG_HZ should be 1000 on all boards. it has NOTHING to  do  with  any
> clock  frequencies of your baord or processor (yes, I know that quite
> a lot of boards are broken this way).

Why is this?  The common use seems to be many flash drivers may get a
time source directly and need to normalize the number of ticks to a
second's value.  I know I set up my timer with the CFG_HZ value in mind
to gauge udelays.

void udelay (unsigned long usec)
{
  ulong tmo, tmp;

  if (usec >= 1000) {/* if "big" number, spread	normalization to seconds
*/
    tmo = usec / 1000;/* start to normalize for usec to ticks per sec */
    tmo *= CFG_HZ;/* find number of "ticks" to wait to achieve target */
    tmo /= 1000;/* finish normalize. */
  } else {/* else small number, don't kill it prior to HZ multiply */
    tmo = usec * CFG_HZ;
    tmo /= (1000*1000);
  }
  ...

How is 1000 correct?  That doesn't seem to follow.

Regards,
Richard W.

[U-Boot-Users] PXA270 support

[Wolfgang Denk]

In message <71555548814716479478431542AA5F8A01B1B6D7@dlee2k04.ent.ti.com> you wrote:
>
> > CFG_HZ should be 1000 on all boards. it has NOTHING to  do  with  any
> > clock  frequencies of your baord or processor (yes, I know that quite
> > a lot of boards are broken this way).
> 
> Why is this?  The common use seems to be many flash drivers may get a
> time source directly and need to normalize the number of ticks to a

Mind the term "ticks" here. This is the "system tick", but not any of
the clocks applied to any of the CPU pins.

> second's value.  I know I set up my timer with the CFG_HZ value in mind
> to gauge udelays.

CFG_HZ is the number of "clock ticks" per second; it has exactly  the
same meaning as the HZ variable in the Linux kernel.

Like in current Linux kernels, U-Boot  normally  uses  a  1  millisec
system tick, thus CFG_HZ should be 1000.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
1st Old Man:  Gee, its windy today.
2nd Old Man:  No it's not... it's Thursday.
3rd Old Man:  Yeh, me too.  Let's go for a beer.

[U-Boot-Users] PXA270 support

[Woodruff, Richard]

> Mind the term "ticks" here. This is the "system tick", but not any of
> the clocks applied to any of the CPU pins.
> 
> > second's value.  I know I set up my timer with the CFG_HZ value in
mind
> > to gauge udelays.
> 
> CFG_HZ is the number of "clock ticks" per second; it has exactly  the
> same meaning as the HZ variable in the Linux kernel.
> 
> Like in current Linux kernels, U-Boot  normally  uses  a  1  millisec
> system tick, thus CFG_HZ should be 1000.

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
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
something.

For ARM, it turns out to be convenient to assign the tick generator to
be CFG_HZ value.  This saves on a little math.

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.

Regards,
Richard W.

[U-Boot-Users] PXA270 support

[Wolfgang Denk]

In message <71555548814716479478431542AA5F8A01B1B6D9@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
CFG_HZ.

> 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
> something.

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).

Best regards,

Wolfgang Denk

-- 
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.

[U-Boot-Users] PXA270 support

[Detlef Vollmann]

Wolfgang Denk wrote:
> CFG_HZ is the number of "clock ticks" per second; it has exactly  the
> same meaning as the HZ variable in the Linux kernel.
> 
> Like in current Linux kernels, U-Boot  normally  uses  a  1  millisec
> system tick, thus CFG_HZ should be 1000.
And get_timer() should deliver that system tick?
If so, at least all ARM based CPU ports are "broken"....

Detlef

-- 
Detlef Vollmann   vollmann engineering gmbh
Linux and C++ for Embedded Systems    http://www.vollmann.ch/

[U-Boot-Users] PXA270 support

[Wolfgang Denk]

In message <4236263E.5393DA14@vollmann.ch> you wrote:
> 
> > system tick, thus CFG_HZ should be 1000.
> And get_timer() should deliver that system tick?

get_timer() returns the time since the last call  to  set_timer()  in
milliseconds.

> If so, at least all ARM based CPU ports are "broken"....

Nearly all of them, yes. One of the many problems we  inherited  from
the ARMBoot code.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
What about WRITING it first and rationalizing it afterwords?  :-)
                       - Larry Wall in <8162@jpl-devvax.JPL.NASA.GOV>

[U-Boot-Users] PXA270 support

[Woodruff, Richard]

That was Wolfgang's assertion.

A quick grep of the code seems to indicate that as long as CFG_HZ
represents the number of ticks in a second usage is ok.

HOWEVER, there is a strong chance of overflow depending on the value in
use.  Thus 1000 is probably a very save value.

I know for ARM ports I've worked on so far I have always applied almost
the max presaler as I did encounter overflow when validating timing
operations.  At that time I just assumed people need to be careful about
assigning CFG_HZ to as small a value as possible, Wolfgang appears to be
taking even a stronger stance.

Regards,
Richard W.

> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net [mailto:u-boot-users-
> admin at lists.sourceforge.net] On Behalf Of Detlef Vollmann
> Sent: Monday, March 14, 2005 6:03 PM
> To: Wolfgang Denk
> Cc: Woodruff, Richard; u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] PXA270 support
> 
> Wolfgang Denk wrote:
> > CFG_HZ is the number of "clock ticks" per second; it has exactly
the
> > same meaning as the HZ variable in the Linux kernel.
> >
> > Like in current Linux kernels, U-Boot  normally  uses  a  1
millisec
> > system tick, thus CFG_HZ should be 1000.
> And get_timer() should deliver that system tick?
> If so, at least all ARM based CPU ports are "broken"....
> 
> Detlef
> 
> --
> Detlef Vollmann   vollmann engineering gmbh
> Linux and C++ for Embedded Systems    http://www.vollmann.ch/
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real
users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] PXA270 support

[Detlef Vollmann]

Sorry that this reply took so long...

Robert Whaley wrote:
> Try timing the sleep command.  Is it accurate?  Take a look at
> cpu/pxa/interrupts.c.
> 
> I believe the CFG is correct in the patch (but I haven't looked at this
> for a while).
Yes, you're correct.  I tested it and checked it against the
specification.

As for the high value of CFG_HZ: yes, while testing I also
had overflow troubles.  But as the relevant function is in CPU
support and not in board support, it's not possible to change
it without breaking all the boards based on this CPU.
To avoid the overflow problem, it might help to add a
mdelay() and maybe even sleep() function.

Detlef

-- 
Detlef Vollmann   vollmann engineering gmbh
Linux and C++ for Embedded Systems    http://www.vollmann.ch/

[U-Boot-Users] PXA270 support

[Wolfgang Denk]

In message <424A6D64.7384108F@vollmann.ch> you wrote:
> 
> As for the high value of CFG_HZ: yes, while testing I also
> had overflow troubles.  But as the relevant function is in CPU
> support and not in board support, it's not possible to change
> it without breaking all the boards based on this CPU.

Ummm... changing it means _fixing_ it for all boards.

> To avoid the overflow problem, it might help to add a
> mdelay() and maybe even sleep() function.

No, this is completely unacceptable.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Forty two.