[U-Boot] Question about Netconsole
Hi All-
I have been having troubles getting Netconsole to work on eTSEC2 of a MPC8548 chip. I was hoping that maybe someone here might be able to help me.
I'm currently using U-Boot v2009.01. Using the bash script code located in the README.Netconsole file, I have been able to successfully transmit data from the 8548 to my host machine over netcat (using v0.7.1 on Fedora Core 11). I've tested that this path works consistently by only piping stdout to 'nc'.
My problem comes when I try to send data from the host machine to the 8548 (piping stdin to 'nc'). It seems like the data is getting transmitted by Netconsole (verified using wireshark), but it isn't getting consistently received by U-Boot. I set the ET_DEBUG flag to 1 so that I could get extra debug information. On rare occasions I have seen that packets are getting received, but this is very rarely. I do know that the connection is OK. I am able to transfer files using tftp without any problems. On one occasion I was able to print out an environment variable (a small victory), but it happened randomly.
Does anyone have any idea why this might be happening? Any help would be greatly appreciated.
Regards, Jared
Hi Jared,
I have been having troubles getting Netconsole to work on eTSEC2 of a MPC8548 chip. I was hoping that maybe someone here might be able to help me.
I'm currently using U-Boot v2009.01. Using the bash script code located in the README.Netconsole file, I have been able to successfully transmit data from the 8548 to my host machine over netcat (using v0.7.1 on Fedora Core 11). I've tested that this path works consistently by only piping stdout to 'nc'.
My problem comes when I try to send data from the host machine to the 8548 (piping stdin to 'nc'). It seems like the data is getting transmitted by Netconsole (verified using wireshark), but it isn't getting consistently received by U-Boot. I set the ET_DEBUG flag to 1 so that I could get extra debug information. On rare occasions I have seen that packets are getting received, but this is very rarely. I do know that the connection is OK. I am able to transfer files using tftp without any problems. On one occasion I was able to print out an environment variable (a small victory), but it happened randomly.
Does anyone have any idea why this might be happening? Any help would be greatly appreciated.
You should check what your actual network driver is doing. As U-Boot is not interrupt driven, the big question is if and how packets on the network interface are buffered when U-Boot is not currently idle waiting.
Unfortunately I have to admit that I do not know the exact control flow of netconsole coupled to the tsec driver, but what you could do is to trace tsec_halt and startup_tsec. Maybe they are called too often and/or take too long...
Cheers Detlev
Hi Detlev-
Thank you for the response. I will give your recommendation a try and see how it goes.
Thanks again, Jared
-----Original Message----- From: Detlev Zundel [mailto:dzu@denx.de] Sent: Friday, August 21, 2009 5:58 AM To: Jared Lewis Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Question about Netconsole
Hi Jared,
I have been having troubles getting Netconsole to work on eTSEC2 of a MPC8548 chip. I was hoping that maybe someone here might be able to help me.
I'm currently using U-Boot v2009.01. Using the bash script code
located
in the README.Netconsole file, I have been able to successfully
transmit
data from the 8548 to my host machine over netcat (using v0.7.1 on Fedora Core 11). I've tested that this path works consistently by
only
piping stdout to 'nc'.
My problem comes when I try to send data from the host machine to the 8548 (piping stdin to 'nc'). It seems like the data is getting transmitted by Netconsole (verified using wireshark), but it isn't getting consistently received by U-Boot. I set the ET_DEBUG flag to 1 so that I could get extra debug information. On rare occasions I have seen that packets are getting received, but this is very rarely. I do know that the connection is OK. I am able to transfer files using
tftp
without any problems. On one occasion I was able to print out an environment variable (a small victory), but it happened randomly.
Does anyone have any idea why this might be happening? Any help would be greatly appreciated.
You should check what your actual network driver is doing. As U-Boot is not interrupt driven, the big question is if and how packets on the network interface are buffered when U-Boot is not currently idle waiting.
Unfortunately I have to admit that I do not know the exact control flow of netconsole coupled to the tsec driver, but what you could do is to trace tsec_halt and startup_tsec. Maybe they are called too often and/or take too long...
Cheers Detlev
Hi Detlev-
I just wanted to let you know that I got Netconsole to work on my board. It turned out that the NetLoop routine was halting and initialing the TSEC driver over and over as part of the packet reception process. This was causing the interface to go up and down over and over and the packets were getting missed. My temporary workaround has been to update the tsec init and halt routines so that they don't do anything if stdin is configured to "nc" (I figure that the interface is already in use so it doesn't need to be updated). This seems to solve my problem for the time being and lets me continue on.
Thank you for your suggestion. I really appreciate your help.
Jared
-----Original Message----- From: Detlev Zundel [mailto:dzu@denx.de] Sent: Friday, August 21, 2009 5:58 AM To: Jared Lewis Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Question about Netconsole
Hi Jared,
I have been having troubles getting Netconsole to work on eTSEC2 of a MPC8548 chip. I was hoping that maybe someone here might be able to help me.
I'm currently using U-Boot v2009.01. Using the bash script code
located
in the README.Netconsole file, I have been able to successfully
transmit
data from the 8548 to my host machine over netcat (using v0.7.1 on Fedora Core 11). I've tested that this path works consistently by
only
piping stdout to 'nc'.
My problem comes when I try to send data from the host machine to the 8548 (piping stdin to 'nc'). It seems like the data is getting transmitted by Netconsole (verified using wireshark), but it isn't getting consistently received by U-Boot. I set the ET_DEBUG flag to 1 so that I could get extra debug information. On rare occasions I have seen that packets are getting received, but this is very rarely. I do know that the connection is OK. I am able to transfer files using
tftp
without any problems. On one occasion I was able to print out an environment variable (a small victory), but it happened randomly.
Does anyone have any idea why this might be happening? Any help would be greatly appreciated.
You should check what your actual network driver is doing. As U-Boot is not interrupt driven, the big question is if and how packets on the network interface are buffered when U-Boot is not currently idle waiting.
Unfortunately I have to admit that I do not know the exact control flow of netconsole coupled to the tsec driver, but what you could do is to trace tsec_halt and startup_tsec. Maybe they are called too often and/or take too long...
Cheers Detlev
Hi Jared,
I just wanted to let you know that I got Netconsole to work on my board. It turned out that the NetLoop routine was halting and initialing the TSEC driver over and over as part of the packet reception process. This was causing the interface to go up and down over and over and the packets were getting missed.
Ok, so I was actually head on :)
My temporary workaround has been to update the tsec init and halt routines so that they don't do anything if stdin is configured to "nc" (I figure that the interface is already in use so it doesn't need to be updated). This seems to solve my problem for the time being and lets me continue on.
Why not post your changes and let others share your improvement? Even if it is of hackish nature, I'm sure that when you CC Ben Warren (network custodian) he will also share his opinion on how to do it "the right way".
Thank you for your suggestion. I really appreciate your help.
Glad that I could help.
Cheers Detlev
On Fri, Aug 28, 2009 at 2:51 AM, Detlev Zundel dzu@denx.de wrote:
Hi Jared,
I just wanted to let you know that I got Netconsole to work on my board. It turned out that the NetLoop routine was halting and initialing the TSEC driver over and over as part of the packet reception process. This was causing the interface to go up and down over and over and the packets were getting missed.
Ok, so I was actually head on :)
My temporary workaround has been to update the tsec init and halt routines so that they don't do anything if stdin is configured to "nc" (I figure that the interface is already in use so it doesn't need to be updated). This seems to solve my problem for the time being and lets me continue on.
Why not post your changes and let others share your improvement? Even if it is of hackish nature, I'm sure that when you CC Ben Warren (network custodian) he will also share his opinion on how to do it "the right way".
Yes, please do.
regards, Ben
participants (3)
-
Ben Warren -
Detlev Zundel -
Jared Lewis