Hi Oliver,
On Sun, Sep 15, 2013 at 3:12 PM, Oliver Metz wrote:
> I can confirm that this patch fixes the issue for me on the mx28 board.
> Before the patch transmitting a linux kernel archive failed many times. With
> the patch applied the file was transfered successfully with the first try.
>
Dear Fabio,
>Hi Robert and Hector,
>
>On Fri, Sep 13, 2013 at 2:46 PM, Wolfgang Denk <[hidden email]> wrote:
>
>> That's ALLOC_CACHE_ALIGN_BUFFER. Thanks.
>
>Could you please let us know wthether the change below fix the problem?
>
>Thanks,
>
>Fabio Estevam
>
>--- a/drivers/net/fec_mxc.c
Hi Robert and Hector,
On Fri, Sep 13, 2013 at 2:46 PM, Wolfgang Denk wrote:
> That's ALLOC_CACHE_ALIGN_BUFFER. Thanks.
Could you please let us know wthether the change below fix the problem?
Thanks,
Fabio Estevam
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -794,7 +794,7 @@ s
Dear Marek Vasut,
In message <201309131824.52506.ma...@denx.de> you wrote:
>
> > > - uchar buff[FEC_MAX_PKT_SIZE] __aligned(ARCH_DMA_MINALIGN);
> > > + /* Align the receive buffer */
> > > + uchar buff_unaligned[FEC_MAX_PKT_SIZE + (ARCH_DMA_MINALIGN - 1)];
> > > + uchar *b
Dear Robert Hodaszi,
In message <5232f2e7.4050...@digi.com> you wrote:
>
> Ok. Then what about if I would use the stack, but align the buffer manually.
Has this been tested? Does it work?
> - uchar buff[FEC_MAX_PKT_SIZE] __aligned(ARCH_DMA_MINALIGN);
> + /* Align the receive buffer
Dear Wolfgang Denk,
> Dear Robert Hodaszi,
>
> In message <5232f2e7.4050...@digi.com> you wrote:
> > Ok. Then what about if I would use the stack, but align the buffer
> > manually.
>
> Has this been tested? Does it work?
>
> > - uchar buff[FEC_MAX_PKT_SIZE] __aligned(ARCH_DMA_MINALIGN);
OK, but as Wolfgang already pointed out, can you tell use what compiler exposes
this behavior and show us the details WD requested please ?
Best regards,
Marek Vasut
You can find the informations below.
Please, use my patch or don't use it, or feel free to modify it as you
wish, but sorry, I
Dear Robert Hodaszi,
> On 2013-09-13 13:11, Robert Hodaszi wrote:
> > On 2013-09-12 21:37, Fabio Estevam wrote:
> >> On Thu, Sep 12, 2013 at 3:53 PM, Wolfgang Denk wrote:
> >>> Dear Fabio Estevam,
> >>>
> >>> In message
> >>>
> >>>
> >>> you wrote:
> > It makes perfect sense to allocate va
On 2013-09-13 13:11, Robert Hodaszi wrote:
On 2013-09-12 21:37, Fabio Estevam wrote:
On Thu, Sep 12, 2013 at 3:53 PM, Wolfgang Denk wrote:
Dear Fabio Estevam,
In message
you wrote:
It makes perfect sense to allocate variable with function scope only
on the stack. That's what the stack
On 2013-09-12 21:37, Fabio Estevam wrote:
On Thu, Sep 12, 2013 at 3:53 PM, Wolfgang Denk wrote:
Dear Fabio Estevam,
In message
you wrote:
It makes perfect sense to allocate variable with function scope only
on the stack. That's what the stack has been invented for.
This buffer in the fec
Dear Robert Hodaszi,
> On 2013-09-12 16:31, Marek Vasut wrote:
> > Dear Robert Hodaszi,
> >
> > Please do not top-post.
> >
> > Memalign should do here with proper rounding. Can you prepare another
> > patch please?
> >
> > Best regards,
> > Marek Vasut
>
> Ok. I will try to do that tomorrow.
On Thu, Sep 12, 2013 at 3:17 PM, Wolfgang Denk wrote:
> Dear Marek Vasut,
>
> In message <201309121605.04824.ma...@denx.de> you wrote:
>>
>> Looking at the code one more time, it'd make most sense to simply allocate
>> the
>> buffer NOT on stack, but with some memalign-kind-of call to avoid this
Dear Hector Palacios,
In message <523195ca.3010...@digi.com> you wrote:
>
> Here is a patch:
>
> From: Robert Hodaszi
> Date: Fri, 6 Sep 2013 09:50:52 +0200
> Subject: [PATCH] net: fec: fix invalid temporary RX buffer alignment because
> of GCC bug
>
> Older GCC versions don't handle well al
Dear Fabio Estevam,
In message
you wrote:
>
> > It makes perfect sense to allocate variable with function scope only
> > on the stack. That's what the stack has been invented for.
>
> This buffer in the fec driver will be used in DMA transfer, so maybe
> that's the reason we should use malloc
I just brought up two samples, that it was a long-term problem. Now it
is fixed. But if somebody is trying to compile the U-Boot with an older
toolchain, it could cause problems. I had problems with 4.4.6.
Yes, 2k is a lot, and I would not put it on the stack. That was just a
quick fix. It wou
Dear Robert Hodaszi,
In message <5231a0c0.8070...@digi.com> you wrote:
>
> Sorry, hopefully that will be a plain-text.
>
> There are a lot of bug announcement, just make a search:
> gcc.gnu.org/bugzilla/show_bug.cgi?id=33721
> gcc.gnu.org/bugzilla/show_bug.cgi?id=16660
Hm... what exactly are th
Dear Marek Vasut,
In message <201309121605.04824.ma...@denx.de> you wrote:
>
> Looking at the code one more time, it'd make most sense to simply allocate
> the
> buffer NOT on stack, but with some memalign-kind-of call to avoid this abuse
> of
> stack. You see, the max packet size is around 2
On Thu, Sep 12, 2013 at 3:53 PM, Wolfgang Denk wrote:
> Dear Fabio Estevam,
>
> In message
> you
> wrote:
>>
>> > It makes perfect sense to allocate variable with function scope only
>> > on the stack. That's what the stack has been invented for.
>>
>> This buffer in the fec driver will be use
On 2013-09-12 16:31, Marek Vasut wrote:
Dear Robert Hodaszi,
Please do not top-post.
Memalign should do here with proper rounding. Can you prepare another patch
please?
Best regards,
Marek Vasut
Ok. I will try to do that tomorrow.
Best regards,
Robert Hodaszi
_
Dear Robert Hodaszi,
> I just brought up two samples, that it was a long-term problem. Now it
> is fixed. But if somebody is trying to compile the U-Boot with an older
> toolchain, it could cause problems. I had problems with 4.4.6.
>
> Yes, 2k is a lot, and I would not put it on the stack. That
Dear Robert Hodaszi,
> Hi,
>
> Sorry, hopefully that will be a plain-text.
>
> There are a lot of bug announcement, just make a search:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33721
This was apparently fixed three years ago.
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16660
And this o
Hi,
Sorry, hopefully that will be a plain-text.
There are a lot of bug announcement, just make a search:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33721
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16660
Also, I printed out the buffer addresses, and that temporary RX buffer
was not aligned. S
Hi,
Sorry, hopefully that will be a plain-text.
There are a lot of bug announcement, just make a search:
gcc.gnu.org/bugzilla/show_bug.cgi?id=33721
gcc.gnu.org/bugzilla/show_bug.cgi?id=16660
Also, I printed out the buffer addresses, and that temporary RX buffer
was not aligned. So the transmit
Dear Robert Hodaszi,
>
>
>http-equiv="Content-Type">
>
>
> Hi,
>
> There are a lot of bug announcement, just make a search:
>
>href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33721";>http://gcc.gnu.or
> g/bugzilla/show_bug.cgi?id=33721 conte
Dear Hector Palacios,
> Hello,
>
> Going back to this old thread I have some news regarding the problem with
> TFTP transmissions blocking (timed out) after 10 seconds on the FEC of the
> MX28. See below:
>
> On 07/17/2013 05:55 PM, Hector Palacios wrote:
> > Dear Marek,
> >
> > On 07/16/2013 0
Hello,
Going back to this old thread I have some news regarding the problem with TFTP
transmissions blocking (timed out) after 10 seconds on the FEC of the MX28.
See below:
On 07/17/2013 05:55 PM, Hector Palacios wrote:
Dear Marek,
On 07/16/2013 06:44 AM, Marek Vasut wrote:
Dear Fabio Estev
Dear Hector Palacios,
> Dear Marek,
>
> On 07/16/2013 06:44 AM, Marek Vasut wrote:
> > Dear Fabio Estevam,
> >
> >> On Tue, Jul 16, 2013 at 12:51 AM, Fabio Estevam wrote:
> >>> On Mon, Jul 15, 2013 at 12:09 PM, Hector Palacios
> >>>
> >>> wrote:
> @Fabio: could you manually run the comma
Dear Marek,
On 07/16/2013 06:44 AM, Marek Vasut wrote:
Dear Fabio Estevam,
On Tue, Jul 16, 2013 at 12:51 AM, Fabio Estevam wrote:
On Mon, Jul 15, 2013 at 12:09 PM, Hector Palacios
wrote:
@Fabio: could you manually run the command 'tftp ${loadaddr} file100M'
in your EVK?
Yes, this is wha
Dear Fabio Estevam,
> On Tue, Jul 16, 2013 at 12:51 AM, Fabio Estevam wrote:
> > On Mon, Jul 15, 2013 at 12:09 PM, Hector Palacios
> >
> > wrote:
> >> @Fabio: could you manually run the command 'tftp ${loadaddr} file100M'
> >> in your EVK?
> >
> > Yes, this is what I have been running since th
On Tue, Jul 16, 2013 at 12:51 AM, Fabio Estevam wrote:
> On Mon, Jul 15, 2013 at 12:09 PM, Hector Palacios
> wrote:
>
>> @Fabio: could you manually run the command 'tftp ${loadaddr} file100M' in
>> your EVK?
>
> Yes, this is what I have been running since the beginning.
>
>> If it doesn't fail, c
On Mon, Jul 15, 2013 at 12:09 PM, Hector Palacios
wrote:
> @Fabio: could you manually run the command 'tftp ${loadaddr} file100M' in
> your EVK?
Yes, this is what I have been running since the beginning.
> If it doesn't fail, could you try running it again after playing with the
> environment (
On 7/15/2013 1:20 PM, Albert ARIBAUD wrote:
Hi Troy,
On Mon, 15 Jul 2013 10:39:54 -0700, Troy Kisky
wrote:
Besides, Marek and I had in fact investigated barriers, adding some as
I did in times past in mvgbe.c, and fiddling with the one already in
dcache_flush_range(). None of this had any eff
Hi Troy,
On Mon, 15 Jul 2013 12:59:56 -0700, Troy Kisky
wrote:
> On 7/15/2013 10:39 AM, Troy Kisky wrote:
> > On 7/15/2013 6:41 AM, Albert ARIBAUD wrote:
> >> Hi Troy,
> >>
> >> On Fri, 12 Jul 2013 19:43:07 -0700, Troy Kisky
> >> wrote:
> >>
> >>> On 7/11/2013 4:18 PM, Fabio Estevam wrote:
> >>
Hi Troy,
On Mon, 15 Jul 2013 10:39:54 -0700, Troy Kisky
wrote:
> > Besides, Marek and I had in fact investigated barriers, adding some as
> > I did in times past in mvgbe.c, and fiddling with the one already in
> > dcache_flush_range(). None of this had any effect.
>
> You tried adding a dsb()
On 7/15/2013 10:39 AM, Troy Kisky wrote:
On 7/15/2013 6:41 AM, Albert ARIBAUD wrote:
Hi Troy,
On Fri, 12 Jul 2013 19:43:07 -0700, Troy Kisky
wrote:
On 7/11/2013 4:18 PM, Fabio Estevam wrote:
On Thu, Jul 11, 2013 at 8:03 PM, Marek Vasut wrote:
The MX28 multi-layer AHB bus can be too slow a
On 7/15/2013 6:41 AM, Albert ARIBAUD wrote:
Hi Troy,
On Fri, 12 Jul 2013 19:43:07 -0700, Troy Kisky
wrote:
On 7/11/2013 4:18 PM, Fabio Estevam wrote:
On Thu, Jul 11, 2013 at 8:03 PM, Marek Vasut wrote:
The MX28 multi-layer AHB bus can be too slow and trigger the
FEC DMA too early, before a
On 07/15/2013 05:12 PM, Marek Vasut wrote:
Hi Hector,
Hi Marek,
On 07/15/2013 02:30 PM, Marek Vasut wrote:
Dear Hector Palacios,
Hi Marek,
On 07/12/2013 06:48 PM, Marek Vasut wrote:
[...]
but I found something:
It is very strange that the timeouts appear always after transferring
betw
Hi Hector,
> Hi Marek,
>
> On 07/15/2013 02:30 PM, Marek Vasut wrote:
> > Dear Hector Palacios,
> >
> >> Hi Marek,
> >>
> >> On 07/12/2013 06:48 PM, Marek Vasut wrote:
> [...]
>
> but I found something:
> It is very strange that the timeouts appear always after transferri
Hi Marek,
On 07/15/2013 02:30 PM, Marek Vasut wrote:
Dear Hector Palacios,
Hi Marek,
On 07/12/2013 06:48 PM, Marek Vasut wrote:
[...]
but I found something:
It is very strange that the timeouts appear always after transferring
between 20 and 24 MiB. So I thought maybe it was not an issue
Hi Troy,
On Fri, 12 Jul 2013 19:43:07 -0700, Troy Kisky
wrote:
> On 7/11/2013 4:18 PM, Fabio Estevam wrote:
> > On Thu, Jul 11, 2013 at 8:03 PM, Marek Vasut wrote:
> >> The MX28 multi-layer AHB bus can be too slow and trigger the
> >> FEC DMA too early, before all the data hit the DRAM. This pa
Dear Hector Palacios,
> Hi Marek,
>
> On 07/12/2013 06:48 PM, Marek Vasut wrote:
> >> [...]
> >>
> >> but I found something:
> >> It is very strange that the timeouts appear always after transferring
> >> between 20 and 24 MiB. So I thought maybe it was not an issue with the
> >> size of the fi
Hi Marek,
On 07/12/2013 06:48 PM, Marek Vasut wrote:
[...]
>>
but I found something:
It is very strange that the timeouts appear always after transferring
between 20 and 24 MiB. So I thought maybe it was not an issue with the
size of the file or the number of packets received, but instead a t
On 7/11/2013 4:18 PM, Fabio Estevam wrote:
On Thu, Jul 11, 2013 at 8:03 PM, Marek Vasut wrote:
The MX28 multi-layer AHB bus can be too slow and trigger the
FEC DMA too early, before all the data hit the DRAM. This patch
ensures the data are written in the RAM before the DMA starts.
Please see t
Hi Hector,
[...]
> > Try Stefano's tree as Fabio suggested. I think it's already pushed and
> > includes the fixes.
>
> I just tried, but it didn't help.
OK, then it's something else.
> >> Considering the other guys seem to work without problems I guess this
> >> scenario is specific to my boa
Hi Hector,
On Fri, 12 Jul 2013 17:08:59 +0200, Hector Palacios
wrote:
> Hi Marek,
>
> On 07/12/2013 02:01 PM, Marek Vasut wrote:
> > Hi Hector,
> >
> >> Dear Marek,
> >>
> >> On 07/12/2013 05:51 AM, Marek Vasut wrote:
> >>> Hi,
> >>>
> On Thu, Jul 11, 2013 at 8:18 PM, Fabio Estevam
> >>>
Hi Marek,
On 07/12/2013 02:01 PM, Marek Vasut wrote:
Hi Hector,
Dear Marek,
On 07/12/2013 05:51 AM, Marek Vasut wrote:
Hi,
On Thu, Jul 11, 2013 at 8:18 PM, Fabio Estevam wrote:
On Thu, Jul 11, 2013 at 8:03 PM, Marek Vasut wrote:
The MX28 multi-layer AHB bus can be too slow and trigger
Hi Hector,
> Dear Marek,
>
> On 07/12/2013 05:51 AM, Marek Vasut wrote:
> > Hi,
> >
> >> On Thu, Jul 11, 2013 at 8:18 PM, Fabio Estevam wrote:
> >>> On Thu, Jul 11, 2013 at 8:03 PM, Marek Vasut wrote:
> The MX28 multi-layer AHB bus can be too slow and trigger the
> FEC DMA too early,
Hi Albert,
> Afterthought:
>
> On Fri, 12 Jul 2013 07:57:18 +0200, Albert ARIBAUD
>
> wrote:
> > except it tends to minimize Marek's own contribution to the fix, which
> > is by far the most important.
>
> 'The most important' 'by far' being of course Marek's contribution, not
> minimizing it.
Dear Marek,
On 07/12/2013 05:51 AM, Marek Vasut wrote:
Hi,
On Thu, Jul 11, 2013 at 8:18 PM, Fabio Estevam wrote:
On Thu, Jul 11, 2013 at 8:03 PM, Marek Vasut wrote:
The MX28 multi-layer AHB bus can be too slow and trigger the
FEC DMA too early, before all the data hit the DRAM. This patch
Hi Hector,
On Fri, Jul 12, 2013 at 8:37 AM, Hector Palacios
wrote:
> Thanks for sharing.
>
> Unfortunately I'm still seeing non-recoverable timeouts when doing tftp
> transfers.
> Nevertheless, with this patch sometimes I'm able to transfer big files
> (100MiB) without problems (I was never able
On 12/07/2013 01:03, Marek Vasut wrote:
> The MX28 multi-layer AHB bus can be too slow and trigger the
> FEC DMA too early, before all the data hit the DRAM. This patch
> ensures the data are written in the RAM before the DMA starts.
> Please see the comment in the patch for full details.
>
> This
Hi Marek, hi Albert,
On 12/07/2013 07:57, Albert ARIBAUD wrote:
>
> This being a bugfix patch, and having been tested twice, I suggest that
> it go in 2013.07, maybe with the commit message reduced to its first
> paragraph above -- although of course I do appreciate the second one,
> except it t
Afterthought:
On Fri, 12 Jul 2013 07:57:18 +0200, Albert ARIBAUD
wrote:
> except it tends to minimize Marek's own contribution to the fix, which
> is by far the most important.
'The most important' 'by far' being of course Marek's contribution, not
minimizing it. :)
Amicalement,
--
Albert.
__
Hi Marek,
On Fri, 12 Jul 2013 01:03:04 +0200, Marek Vasut wrote:
> The MX28 multi-layer AHB bus can be too slow and trigger the
> FEC DMA too early, before all the data hit the DRAM. This patch
> ensures the data are written in the RAM before the DMA starts.
> Please see the comment in the patch
On Thu, Jul 11, 2013 at 8:18 PM, Fabio Estevam wrote:
> On Thu, Jul 11, 2013 at 8:03 PM, Marek Vasut wrote:
>> The MX28 multi-layer AHB bus can be too slow and trigger the
>> FEC DMA too early, before all the data hit the DRAM. This patch
>> ensures the data are written in the RAM before the DMA
Hi,
> On Thu, Jul 11, 2013 at 8:18 PM, Fabio Estevam wrote:
> > On Thu, Jul 11, 2013 at 8:03 PM, Marek Vasut wrote:
> >> The MX28 multi-layer AHB bus can be too slow and trigger the
> >> FEC DMA too early, before all the data hit the DRAM. This patch
> >> ensures the data are written in the RAM
On Thu, Jul 11, 2013 at 8:03 PM, Marek Vasut wrote:
> The MX28 multi-layer AHB bus can be too slow and trigger the
> FEC DMA too early, before all the data hit the DRAM. This patch
> ensures the data are written in the RAM before the DMA starts.
> Please see the comment in the patch for full detai
The MX28 multi-layer AHB bus can be too slow and trigger the
FEC DMA too early, before all the data hit the DRAM. This patch
ensures the data are written in the RAM before the DMA starts.
Please see the comment in the patch for full details.
This patch was produced with an amazing help from Albert
58 matches
Mail list logo
