From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dave Peverley <dpeverley@mpc-data.co.uk>
Date: Mon, 19 Apr 2004 12:59:32 +0100
Subject: [U-Boot-Users] v1.1.0, omap boards and udelay()
Message-ID: <4083BF24.9030500@mpc-data.co.uk>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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