On Mon, 18 Jul 2011 21:46:28 +0530
Aneesh V <ane...@ti.com> wrote:
> Hi David,
>
> On Monday 18 July 2011 08:48 PM, David Jander wrote:
> >
> > Hi all,
> >
> > I am busy debugging a problem with the i.MX51 FEC ethernet driver, that
> > stopped working after upgrading u-boot. Before the upgrade I used
> > v2010.06-rc3, which worked fine.
> > I gave up on trying to find the difference beween the old version and this
> > one that broke it.... due to BSP issues, git bisecting seems a monumental
> > task I am not considering yet.
> > The funny part is that it seems to work fine if I disable data-caches!
> > With data caches enabled, it hangs in the following while loop in
> > fec_send(), at line 592:
> >
> > ...
> > 584 /*
> > 585 * Enable SmartDMA transmit task
> > 586 */
> > 587 fec_tx_task_enable(fec);
> > 588
> > 589 /*
> > 590 * wait until frame is sent .
> > 591 */
> > 592 while (readw(&fec->tbd_base[fec->tbd_index].status)&
> > FEC_TBD_READY) { 593 udelay(1);
> > 594 }
> > ...
> >
> > If I change this code in the following way, the while loop exits
> > successfully:
> >
> > ...
> > 584 /*
> > 585 * Enable SmartDMA transmit task
> > 586 */
> > 587 flush_cache(&fec->tbd_base[fec->tbd_index], 4);
> > 588 fec_tx_task_enable(fec);
> > 589 flash_dcache_all();
> > 590
> > 591 /*
> > 592 * wait until frame is sent .
> > 593 */
> > 594 while (readw(&fec->tbd_base[fec->tbd_index].status)&
> > FEC_TBD_READY) { 595 udelay(1);
> > 596 }
> > ...
> >
> > Notice the cache flush calls at line 587 and 589. With these, sending
> > succeeds. The driver still hangs in receiving afterwards, but at least this
> > part seems to work. If I remove either of the two added lines, it stops
> > working again.
> >
> > What is going on here? Why did this work with caches enabled before??
>
> Are you sure caches were enabled before? Until recently absence of
> CONFIG_SYS_DCACHE_OFF did not mean that your D-cache is enabled because
> you also had to call the function dcache_enable(). Some platforms were
> calling this from board file or some drivers but not all.
We did. I am always calling dcache_enable(), icache_enable() and
l2_cache_enable() from board code. The latter function I implemented myself,
because nor u-boot nor the kernel does otherwise activate l2-cache, which has a
big performance impact.
Just in case, at the moment I am testing with only the L1 caches enabled.
> The following patch changed this for ARM:
>
> commit c2dd0d45540397704de9b13287417d21049d34c6
> armv7: integrate cache maintenance support
>
> In this patch I added a call to dcache_enable() at the beginning of
> board_init_r() for ARM(i.e. as soon as relocation is over). As a result
> D-cache will be enabled for all ARM platforms now unless
> CONFIG_SYS_DCACHE_OFF is set.
Yes, I noticed that.
> Looks like this is a real coherency issue that is brought out because
> d-cache is really enabled for you now.
AFAICS, it was always enabled for our board. At least I did always call
i/dcache_enable() in board setup code.... was it broken before? Are the L1
caches enabled by (mainline) linux code?
Best regards,
--
David Jander
Protonic Holland.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
