[U-Boot-Users] v1.1.0, omap boards and udelay()

[U-Boot-Users] v1.1.0, omap boards and udelay()

[Gupta, Kshitij]

Hi Nishant,
	The timers are working properly for both 1510 and 1610 innovator.
Only thing is that #if loop has to be removed with hardcoded spin.
warm regards
-kshitij

-----Original Message-----
From: u-boot-users-admin@lists.sourceforge.net
[mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of Kamat,
Nishant
Sent: Tuesday, April 20, 2004 10:00 PM
To: Dave Peverley; u-boot-users at lists.sourceforge.net
Subject: RE: [U-Boot-Users] v1.1.0, omap boards and udelay()


Dave,

In versions prior 1.1.0, there was a small bug in the omap1610 port, in
that the timer was not enabled. Obviously the udelay wouldn't function
normally and so there was this busy loop to make for it. In 1.1.0 this
is fixed by enabling the MPU timers, and there is no need for the loop.
See board/omap1610inn/platform.S where MPU Timer 1 is now enabled. You
might be missing similar code in the 730's port. 

That said, the same bug in 1510 is not yet fixed, and it still uses the
busy loop (in cpu/arm925t/interrupts.c). I'll send a little patch to fix
that soon.

Regards,
Nishant


-----Original Message-----
From: u-boot-users-admin@lists.sourceforge.net
[mailto:u-boot-users-admin at lists.sourceforge.net] On Behalf Of Dave
Peverley
Sent: Monday, April 19, 2004 7:00 AM
To: u-boot-users at lists.sourceforge.net
Subject: [U-Boot-Users] v1.1.0, omap boards and udelay()


Hi all,

  I'm just merging my omap730p2 port into the 1.1.0 codebase, and have
hit a snag that I would have thought would affect the omap1510 and 1610
code as well ; can anyone confirm this? The problem is as follows :
 
  in boards/omapXXXX/omapXXXX.c, the function ether__init() uses the 
udelay() call. Prior to version 1.1.0, this was implemented using :
  #if defined(CONFIG_INNOVATOROMAP1610) || defined(CONFIG_P2OMAP730)
  #define LOOPS_PER_MSEC 100		/* tuned on omap1610 */
      volatile int i, time_remaining = LOOPS_PER_MSEC * usec;
      for (i = time_remaining; i > 0; i--) {
  }
  #else
so that the omap's wouldn't use the MPU timer, as this does not work (at

least at that point in the startup) This means that u-boot hangs on my 
board during ether__init() now as the timer never gets incremented. 

  Can anyone tell me why this code was removed? Looking at it, I can't
see a reason why it shouldn't break the 1510/1610 omap support as well.
I've 
tested moving the code back as it was (using the 1.1.0 CONFIG_OMAP
instead) and this fixes the problem once more. 

Best Wishes,

Dave Peverley

------------------------------------------------------------------------
---
             Dave Peverley, Software Engineer, MPC Data Limited.
Phone : [+44] (0) 1225 868 228              Web :
http://www.mpc-data.co.uk



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&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] v1.1.0, omap boards and udelay()

[Wolfgang Denk]

In message <F509E6111989D311B63700805FA761DA0D82E0D3@dbde01.itg.ti.com> you wrote:
>
> 	The timers are working properly for both 1510 and 1610 innovator.
> Only thing is that #if loop has to be removed with hardcoded spin.

I implemented this fix - please check if I did it right,  and  if  it
works as expected.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"We don't have to protect the environment -- the Second Coming is  at
hand."                                                   - James Watt

[U-Boot-Users] v1.1.0, omap boards and udelay()

[Dave Peverley]

Wolfgang Denk wrote:
> I implemented this fix - please check if I did it right,  and  if  it
> works as expected.

Ok, I see whats going on - the udelay code relies on the MPU timer being 
set up and running. However, the code that relies on it is cpu-specific 
(interrupt.c) however the setup for the timer occurs in platform.S for 
the board. I would respectfully suggest if this is a prerequisite for the 
udelay() function this setup ought to be performed in the cpu's start.S 
rather than the boards platform.S? 

I'll get this fixed and implemented (in the current platform.S way) for 
the 730/P2 before submitting my patch back.

Best Wishes,

Dave Peverley


---------------------------------------------------------------------------
             Dave Peverley, Software Engineer, MPC Data Limited.
Phone : [+44] (0) 1225 868 228              Web : http://www.mpc-data.co.uk

[U-Boot-Users] v1.1.0, omap boards and udelay()

[Wolfgang Denk]

In message <408CD6F3.7030903@mpc-data.co.uk> you wrote:
>
> Ok, I see whats going on - the udelay code relies on the MPU timer being 
> set up and running. However, the code that relies on it is cpu-specific 
> (interrupt.c) however the setup for the timer occurs in platform.S for 
> the board. I would respectfully suggest if this is a prerequisite for the 
> udelay() function this setup ought to be performed in the cpu's start.S 
> rather than the boards platform.S? 

Agreed. Can you please submit a patch?

[Sorry, I don't have any such hardware here any  more,  so  I  cannot
test anything myself.]


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Anyone who doesn't believe in miracles is not a realist.
                                                   - David Ben Gurion

[U-Boot-Users] v1.1.0, omap boards and udelay()

[Dave Peverley]

Wolfgang Denk wrote:
> Agreed. Can you please submit a patch?
Sure, I'll submit the 730/p2 patch first and get that in, then do this
patch as a secondary one after for all three omap platforms at once to 
make life simpler.

Am I right in assuming that for my P2 patch, one against the 1.1.0 tag 
is ok rather than trying to keep up with HEAD ? I couldn't find a 
reference in the README to which you prefer.

> [Sorry, I don't have any such hardware here any  more,  so  I  cannot
> test anything myself.]
Hey, I know that problem well :-)	

Best Wishes,

Dave Peverley

---------------------------------------------------------------------------
             Dave Peverley, Software Engineer, MPC Data Limited.
Phone : [+44] (0) 1225 868 228              Web : http://www.mpc-data.co.uk

[U-Boot-Users] v1.1.0, omap boards and udelay()

[Wolfgang Denk]

Dear Dave,

in message <408CEF4E.6040102@mpc-data.co.uk> you wrote:
>
> Am I right in assuming that for my P2 patch, one against the 1.1.0 tag 
> is ok rather than trying to keep up with HEAD ? I couldn't find a 
> reference in the README to which you prefer.

I prefer patches against top of tree, or against the latest  official
release. 1.1.0 is OK with me.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
I still miss my ex-wife, but my aim is getting better.

[U-Boot-Users] v1.1.0, omap boards and udelay()

[Kamat, Nishant]

Dave,

In versions prior 1.1.0, there was a small bug in the omap1610 port, in
that the timer was not enabled. Obviously the udelay wouldn't function
normally and so there was this busy loop to make for it. In 1.1.0 this
is fixed by enabling the MPU timers, and there is no need for the loop.
See board/omap1610inn/platform.S where MPU Timer 1 is now enabled. You
might be missing similar code in the 730's port. 

That said, the same bug in 1510 is not yet fixed, and it still uses the
busy loop (in cpu/arm925t/interrupts.c). I'll send a little patch to fix
that soon.

Regards,
Nishant


-----Original Message-----
From: u-boot-users-admin@lists.sourceforge.net
[mailto:u-boot-users-admin at lists.sourceforge.net] On Behalf Of Dave
Peverley
Sent: Monday, April 19, 2004 7:00 AM
To: u-boot-users at lists.sourceforge.net
Subject: [U-Boot-Users] v1.1.0, omap boards and udelay()


Hi all,

  I'm just merging my omap730p2 port into the 1.1.0 codebase, and have
hit a snag that I would have thought would affect the omap1510 and 1610
code as well ; can anyone confirm this? The problem is as follows :
 
  in boards/omapXXXX/omapXXXX.c, the function ether__init() uses the 
udelay() call. Prior to version 1.1.0, this was implemented using :
  #if defined(CONFIG_INNOVATOROMAP1610) || defined(CONFIG_P2OMAP730)
  #define LOOPS_PER_MSEC 100		/* tuned on omap1610 */
      volatile int i, time_remaining = LOOPS_PER_MSEC * usec;
      for (i = time_remaining; i > 0; i--) {
  }
  #else
so that the omap's wouldn't use the MPU timer, as this does not work (at

least at that point in the startup) This means that u-boot hangs on my 
board during ether__init() now as the timer never gets incremented. 

  Can anyone tell me why this code was removed? Looking at it, I can't
see a reason why it shouldn't break the 1510/1610 omap support as well.
I've 
tested moving the code back as it was (using the 1.1.0 CONFIG_OMAP
instead) and this fixes the problem once more. 

Best Wishes,

Dave Peverley

------------------------------------------------------------------------
---
             Dave Peverley, Software Engineer, MPC Data Limited.
Phone : [+44] (0) 1225 868 228              Web :
http://www.mpc-data.co.uk

[U-Boot-Users] v1.1.0, omap boards and udelay()

[Dave Peverley]

Hi all,

  I'm just merging my omap730p2 port into the 1.1.0 codebase, and have hit
a snag that I would have thought would affect the omap1510 and 1610 code as
well ; can anyone confirm this? The problem is as follows :
 
  in boards/omapXXXX/omapXXXX.c, the function ether__init() uses the 
udelay() call. Prior to version 1.1.0, this was implemented using :
  #if defined(CONFIG_INNOVATOROMAP1610) || defined(CONFIG_P2OMAP730)
  #define LOOPS_PER_MSEC 100		/* tuned on omap1610 */
      volatile int i, time_remaining = LOOPS_PER_MSEC * usec;
      for (i = time_remaining; i > 0; i--) {
  }
  #else
so that the omap's wouldn't use the MPU timer, as this does not work (at 
least at that point in the startup) This means that u-boot hangs on my 
board during ether__init() now as the timer never gets incremented. 

  Can anyone tell me why this code was removed? Looking at it, I can't see
a reason why it shouldn't break the 1510/1610 omap support as well. I've 
tested moving the code back as it was (using the 1.1.0 CONFIG_OMAP instead)
and this fixes the problem once more. 

Best Wishes,

Dave Peverley

---------------------------------------------------------------------------
             Dave Peverley, Software Engineer, MPC Data Limited.
Phone : [+44] (0) 1225 868 228              Web : http://www.mpc-data.co.uk