[U-Boot-Users] SMC driver problem
Hi,
I've just tried to track down the SMSC driver problem which was recently reported on this list. After the MMU allocates a block for a sent packet in smc_send_packet() there is a FIXME comment in the sourcecode:
- when I add puts("x"); after this comment it works. - when I remove it it hangs. - when I add the content of the putx() function (the register operations) to the same location it hangs. - when I add a function containing the register operation and call this function after the comment it hangs. - when I add a function which calls the function from the last step it works - this is the same constellation as with the puts() call.
All this looks like some kind of a memory management or stack problem for me; perhaps anybody else has an idea what might go on?
Robert
In message 20030331174409.GA17704@pengutronix.de you wrote:
I've just tried to track down the SMSC driver problem which was recently reported on this list. After the MMU allocates a block for a sent packet
Oops? I don't think the MMU allocates any blocks ???
All this looks like some kind of a memory management or stack problem for me; perhaps anybody else has an idea what might go on?
Which system is this? And what are you doing with the MMU on it?
Wolfgang Denk
On Mon, Mar 31, 2003 at 11:01:41PM +0200, Wolfgang Denk wrote:
In message 20030331174409.GA17704@pengutronix.de you wrote:
I've just tried to track down the SMSC driver problem which was recently reported on this list. After the MMU allocates a block for a sent packet
Oops? I don't think the MMU allocates any blocks ???
It _tries_ to allocate a block.
Which system is this? And what are you doing with the MMU on it?
PXA250, similar to Cogent's CSB226. It's not the processor's MMU but that one on the ethernet chip. The chip has some buffer memory and you can use it's MMU to allocate blocks for packets you want to send.
Robert
Am Montag, 31. März 2003 19:44 schrieb Robert Schwebel:
I've just tried to track down the SMSC driver problem which was recently reported on this list. After the MMU allocates a block for a sent packet in smc_send_packet() there is a FIXME comment in the sourcecode:
- when I add puts("x"); after this comment it works.
- when I remove it it hangs.
- when I add the content of the putx() function (the register operations) to the same location it hangs.
- when I add a function containing the register operation and call this function after the comment it hangs.
- when I add a function which calls the function from the last step it works - this is the same constellation as with the puts() call.
All this looks like some kind of a memory management or stack problem for me;..
Either that or timing.
Could you try to replace the puts("x") with a sufficiently long delay ?
Rob
---------------------------------------------------------------- Robert Kaiser email: rkaiser@sysgo.de SYSGO AG Am Pfaffenstein 14 phone: (49) 6136 9948-762 D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10
On Mon, 31 Mar 2003, Robert Schwebel wrote:
I've just tried to track down the SMSC driver problem which was recently reported on this list. After the MMU allocates a block for a sent packet in smc_send_packet() there is a FIXME comment in the sourcecode:
- when I add puts("x"); after this comment it works.
- when I remove it it hangs.
- when I add the content of the putx() function (the register operations) to the same location it hangs.
- when I add a function containing the register operation and call this function after the comment it hangs.
A few random thoughts:
Have you looked at the assembly code generated by the compiler? Maybe the subroutine call enforces some instruction ordering, that otherwise doesn't take place.
Guessing from your tests, timing doesn't seem to be the issue.
Hm, stack operations don't seem to relate to the problem either.
The D-Cache is still off, right?
Does the problem persist, if you turn off the I-Cache?
Are there any instructions to enforce pending IO operation, such as the eieio on the PPC?
Just for clarification: by "the putx() function", you mean the puts("x"); call, right? (probably slipped from s to x on your keyboard :-)
- when I add a function which calls the function from the last step it works - this is the same constellation as with the puts() call.
I don't really understand this sentence. Could you explain this again, please?
Regards, Marius
PS: in the English language, the word "constellation" only refers to stellar phenomena. The additional meaning of "configuration" does not exist.
----------------------------------------------------------------------------- Marius Groeger SYSGO Real-Time Solutions AG mgroeger@sysgo.de Software Engineering Embedded and Real-Time Software www.sysgo.de Voice: +49-6136-9948-0 Am Pfaffenstein 14 www.osek.de FAX: +49-6136-9948-10 55270 Klein-Winternheim, Germany www.elinos.com
On Tue, Apr 01, 2003 at 10:14:46AM +0200, Marius Groeger wrote:
Have you looked at the assembly code generated by the compiler? Maybe the subroutine call enforces some instruction ordering, that otherwise doesn't take place.
Guessing from your tests, timing doesn't seem to be the issue. Hm, stack operations don't seem to relate to the problem either.
Ack.
The D-Cache is still off, right?
Yep.
Does the problem persist, if you turn off the I-Cache?
No change; the icache enabling code in start.S is off anyway.
Are there any instructions to enforce pending IO operation, such as the eieio on the PPC?
I don't think so.
Just for clarification: by "the putx() function", you mean the puts("x"); call, right? (probably slipped from s to x on your keyboard :-)
Yep.
I don't really understand this sentence. Could you explain this again, please?
I've done some further tests, the scenario looks like this now:
----------8<---------- ... void test1(void) nops
void test2(char) output character to serial port
smc_send_packet(...) ... (the critical line with the FIXME) test2('x'); ... ----------8<----------
- if test1 and test2 are not present (commented out) it does not work. - adding test2() and calling it makes it work - adding test1() and _not_ alling it makes it break again when there are more than 4 nops present. With 4 nops and less it still works.
All this looks like the positon of the code seems to be the problem, but why?
Robert
On Tue, 1 Apr 2003, Robert Schwebel wrote:
All this looks like the positon of the code seems to be the problem, but why?
Perhaps the memory timing is wrong? Maybe the instruction fetch doesn't work correctly. (Althought then it probably wouldn't get this far.)
If you haven't done already, check these things:
- take a close look at the (non)working assembly code
- check addresses of the instruction pointer, data register pointers and (most important) the stack pointer. Maybe there is a weird address overlapping
- chip selects setups (address, size, timings)
Regards, Marius
----------------------------------------------------------------------------- Marius Groeger SYSGO Real-Time Solutions AG mgroeger@sysgo.de Software Engineering Embedded and Real-Time Software www.sysgo.de Voice: +49-6136-9948-0 Am Pfaffenstein 14 www.osek.de FAX: +49-6136-9948-10 55270 Klein-Winternheim, Germany www.elinos.com
On Tue, Apr 01, 2003 at 02:27:44PM +0200, Marius Groeger wrote:
Perhaps the memory timing is wrong? Maybe the instruction fetch doesn't work correctly. (Althought then it probably wouldn't get this far.)
Hmm, I don't think so but I'll recheck it. In Linux the driver does work, and AFAIK Linux doesn't touch the memory timing.
Robert
participants (5)
-
Marius Groeger -
Robert Kaiser -
Robert Schwebel -
Robert Schwebel -
Wolfgang Denk