[U-Boot-Users] dbau1550 patch

[U-Boot-Users] dbau1550 patch

[Andrew Dyer]

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=12898

I can't seem to find the patch he referred to and I would like to get
a hold of it.

-- 
Hardware, n.:
        The parts of a computer system that can be kicked.

[U-Boot-Users] dbau1550 patch

[Leif Lindholm]

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=12898

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

[U-Boot-Users] dbau1550 patch

[Andrew Dyer]

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=12898
> 
> 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.

-- 
Hardware, n.:
        The parts of a computer system that can be kicked.

[U-Boot-Users] dbau1550 patch

[Leif Lindholm]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: au1x00_eth.c.diff
Type: text/x-patch
Size: 568 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20041229/2533a9e8/attachment.bin 

[U-Boot-Users] dbau1550 patch

[Leif Lindholm]

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

[U-Boot-Users] dbau1550 patch

[Thomas Lange]

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.
<...>

[U-Boot-Users] dbau1550 patch

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Of all possible committee reactions to any  given  agenda  item,  the
reaction  that will occur is the one which will liberate the greatest
amount of hot air.                                -- Thomas L. Martin