On Tuesday 19 July 2011 02:28 PM, David Jander wrote:
>
> Dear Aneesh,
>
> Thanks a lot for your replies.
>
> On Tue, 19 Jul 2011 14:13:34 +0530
> Aneesh V<ane...@ti.com> wrote:
>> On Tuesday 19 July 2011 02:07 PM, David Jander wrote:
>>> On Tue, 19 Jul 2011 10:21:12 +0200
>>> Albert ARIBAUD<albert.u.b...@aribaud.net> wrote:
>>>
>>>> Hi David,
>>>>
>>>> Le 19/07/2011 09:44, David Jander a écrit :
>>>>>
>>>>> Hi Stefano,
>>>>>
>>>>> On Mon, 18 Jul 2011 18:55:05 +0200
>>>>> Stefano Babic<sba...@denx.de> wrote:
>>>>>
>>>>>> On 07/18/2011 05:18 PM, David Jander wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>>> What is going on here? Why did this work with caches enabled before??
>>>>>>
>>>>>> I think cache was always disabled..
>>>>>
>>>>> I had even L2-caches enabled in u-boot (copied/adapted some code from
>>>>> OMAP cache.S), and called i/dcache_enable() from board code like this:
>>>>>
>>>>> int board_late_init(void)
>>>>> {
>>>>> power_init();
>>>>> probe_board_type();
>>>>> icache_enable();
>>>>> dcache_enable();
>>>>>
>>>>> return 0;
>>>>> }
>>>>>
>>>>> Is there a reason this wouldn't have worked before?
>>>>>
>>>>> Suppose it didn't. Does that mean we need to use the MMU to properly mark
>>>>> regions of register space and specially FEC BD's as not-cached? Or do we
>>>>> need to flash caches manually each time such a memory region is accessed?
>>>>> I am kind of a CPU-speed-junkie, so I am not sure I want to live without
>>>>> caches enabled in u-boot ;-)
>>
>> Are you talking about some memory-mapped IO region(register space). If
>> that is the case, that region won't be cached. ARM mmu implementation
>> makes only the SDRAM region cached. Rest is non-cached non-buffered.
>
> Ah, thanks for pointing out. I already suspected something like that...
>
>>>> You would have to flush (before sending packets / starting external
>>>> memory-to-device DMA) and invalidate (before reading received packets /
>>>> after external device-to-memory DMA is done); using MMU and mapping
>>>> cached/non-cached areas is IMO overkill, and will hurt CPU accesses to
>>>> the xmit/receive buffers and descriptors.
>>>
>>> So, you say actually what I did while exploring the problem would have
>>> been a correct way of solving this problem?
>>>
>>> Like this:
>>>
>>> 587 flush_cache(&fec->tbd_base[fec->tbd_index], 4);
>>
>> This is what is needed assuming the below is initiating a memory to
>> peripheral DMA. Is your buffer only 4 bytes long?
>
> No it isn't. I know, I should flush the whole buffer area, but this was just
> enough to get the status field flushed, so the FEC started transmitting, and
> the while loop ended eventually. The result was still not correct, but at
> least it won't hang.
> What would be more expensive, flushing just the buffer area, or
> flush_dcache_all()?
That depends on the buffer size. If the buffer size is really big
(comparable to L2$ size) flush_dcache_all() may turn out to be better.
>
>> Also, please check if flush_cache() is correctly supported for your
>> CPU. The default implementation in in arch/arm/lib/cache.c has support
>> for only a handful of cpus. AFAIK, only armv7 is over-riding this
>> default implementation at the moment.
>
> There is cache_v7.c which implements these... they are supposed to work
> correctly I guess?
Oops! I didn't notice that your CPU is armv7.
Yes, it's supposed to work correctly.
best regards,
Aneesh
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
