RE: [U-Boot-Users] v1.1.0, omap boards and udelay()
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@lists.sourceforge.net]On Behalf Of Kamat, Nishant Sent: Tuesday, April 20, 2004 10:00 PM To: Dave Peverley; u-boot-users@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@lists.sourceforge.net] On Behalf Of Dave Peverley Sent: Monday, April 19, 2004 7:00 AM To: u-boot-users@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%1470&alloc_id638&op=click _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
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
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
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
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
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
participants (3)
-
Dave Peverley -
Gupta, Kshitij -
Wolfgang Denk