[U-Boot-Users] dbau1550 patch

A while back (Sep 23, 2004) someone named Leif posted a note about a patch to add support for the AMD DbAU1550 board to u-boot here https://sourceforge.net/mailarchive/forum.php?thread_id=5624545&forum_id...
I can't seem to find the patch he referred to and I would like to get a hold of it.

On Mon, 2004-12-06 at 14:05 -0600, Andrew Dyer wrote:
A while back (Sep 23, 2004) someone named Leif posted a note about a patch to add support for the AMD DbAU1550 board to u-boot here https://sourceforge.net/mailarchive/forum.php?thread_id=5624545&forum_id...
That would be me.
I can't seem to find the patch he referred to and I would like to get a hold of it.
Will send this to you privately, and later try to clean it up a bit and fix a few bugs this caused with the db1000 board, so Wolfgang might accept it into the CVS.
regards / Leif

On Tue, 07 Dec 2004 13:45:44 +0100, Leif Lindholm leif.lindholm@i3micro.com wrote:
On Mon, 2004-12-06 at 14:05 -0600, Andrew Dyer wrote:
A while back (Sep 23, 2004) someone named Leif posted a note about a patch to add support for the AMD DbAU1550 board to u-boot here https://sourceforge.net/mailarchive/forum.php?thread_id=5624545&forum_id...
Will send this to you privately, and later try to clean it up a bit and fix a few bugs this caused with the db1000 board, so Wolfgang might accept it into the CVS.
I've been working with your patch and expanding it a bit for stuff we wanted to use on our custom au1550 boards.
I noticed a problem with the cpu/mips/au1x00_ether.c net driver - it certainly causes problems for me on the au1550.
next_tx and next_rx are set to zero in the init routine - the au1550 docs (section 9.4.3.2 of au1550 databook) says the dmas may not start at buffer 0 coming out of reset, so those values are not guaranteed to be zero. The correct value can be init'd based on the dma address register CB field.
I changed the lines setting these up in au1x00_init() to:
next_tx = TX_GET_DMA_BUFFER(fifo_tx[0].addr); next_rx = RX_GET_DMA_BUFFER(fifo_rx[0].addr);
this issue was causing me problems with rx and tx timeouts, and changing these values fixes my problem (at least in limited testing). Can someone else try out this change on au1000/1100/1500 based systems?
Also, what is txbuf in au1x00_ether.c used for? It doesn't look like that storage ever gets used - every time through the au1x00_send routine the buffer gets passed in from the net code.

On Wed, 2004-12-29 at 00:17 -0600, Andrew Dyer wrote:
On Tue, 07 Dec 2004 13:45:44 +0100, Leif Lindholm leif.lindholm@i3micro.com wrote:
Will send this to you privately, and later try to clean it up a bit and fix a few bugs this caused with the db1000 board, so Wolfgang might accept it into the CVS.
I changed the lines setting these up in au1x00_init() to:
next_tx = TX_GET_DMA_BUFFER(fifo_tx[0].addr); next_rx = RX_GET_DMA_BUFFER(fifo_rx[0].addr);
this issue was causing me problems with rx and tx timeouts, and changing these values fixes my problem (at least in limited testing). Can someone else try out this change on au1000/1100/1500 based systems?
This seems to clear up a similar/identical problem we had on our hardware, but haven't had time to investigate. Good work, thanks!
I'm attaching a patch against CVS (last synced on the 10:th of December, since the sourceforge server seems to be down as usual - but I don't think that file has been modified) for others testing on other boards/chips, since I only have 1550 hardware here.
/ Leif

On Wed, 2004-12-29 at 11:44 +0100, Leif Lindholm wrote:
I'm attaching a patch against CVS (last synced on the 10:th of December, since the sourceforge server seems to be down as usual - but I don't
My sincerest apologies to any sourceforge people out there - it seems our BOFH got a bit trigger happy during the holidays and tightened up the firewall rules a bit :]
Updated u-boot tree just now, and as I suspected there were no updates to the file since last sync.
Sorry about the line noise.
/ Leif

The patch seems to work fine on au1000 also.
/Thomas
Leif Lindholm wrote: <...>
I'm attaching a patch against CVS (last synced on the 10:th of December, since the sourceforge server seems to be down as usual - but I don't think that file has been modified) for others testing on other boards/chips, since I only have 1550 hardware here.
<...>

In message 1104317088.1002.19.camel@localhost you wrote:
I changed the lines setting these up in au1x00_init() to:
next_tx = TX_GET_DMA_BUFFER(fifo_tx[0].addr); next_rx = RX_GET_DMA_BUFFER(fifo_rx[0].addr);
this issue was causing me problems with rx and tx timeouts, and changing these values fixes my problem (at least in limited testing). Can someone else try out this change on au1000/1100/1500 based systems?
This seems to clear up a similar/identical problem we had on our hardware, but haven't had time to investigate. Good work, thanks!
I'm attaching a patch against CVS (last synced on the 10:th of December, since the sourceforge server seems to be down as usual - but I don't think that file has been modified) for others testing on other boards/chips, since I only have 1550 hardware here.
Added, thanks. But please don't forget to provide a CHANGELOG entry!
Best regards,
Wolfgang Denk
participants (4)
-
Andrew Dyer
-
Leif Lindholm
-
Thomas Lange
-
Wolfgang Denk