Hi Elad,

okay, I see. I still think anything can be done by eCos. Use 0x91000000 as rom
memory address in your configuration (*.ldi file) and use the
CYGARC_START_FUNC_UNCACHED define. The system will start at 0xb1000000 and after
all the inits (including cache) it will jump to the cached base automatically.
You can enable all the caches in your cache init.

Bye...

On 05.01.2011 21:51, Elad Yosef wrote:
> Hi,
> That's was the situation until now, the Boot was running from 0xB100:0000
> My boot code is running actually running from serial flash (with 50Mhz
> clock, very slow!!!).
> But due to performance issue I trying to speed up the boot execution
> by using the cache.
> 
> I have removed the K0 setting in the hal_c_cache_init function:
>   asm volatile("mfc0 %0,$16;" : "=r"(val));
>   val &= ~3;
>   asm volatile("mtc0 %0,$16;" : : "r"(val));
> 
> And the system worked (KSEG0 is un-cached), once I set K0 to any of
> the cache options (by JTAG),
> the CPU goes away from the expected code order.
> 
> I don't what can I do to get my code running?
> What if I change CYGARC_KSEG_CACHED_BASE to 0x91000000?
> 
> Thanks
> 
> Elad
> 
> 
> On Wed, Jan 5, 2011 at 9:46 PM, Stefan Sommerfeld <sommerf...@mikrom.de> 
> wrote:
>> Hi Elad,
>>
>>> My Boot Code is in 0x91000000 in KSE0!!
>>> It is a flash device that appears to the CPU as memory mapped (small HW 
>>> trick)
>>>
>>> I have implemented the cache init with some help from MIPS tech.
>>> It is called by the macros:
>>> HAL_ICACHE_INVALIDATE_ALL and HAL_DCACHE_INVALIDATE_ALL
>>>
>>> This macros first called from hal_c_cache_init (called from
>>> hal_cache_init from the start function)
>>> After this It enables the cache for KSEG0.
>>>
>>> The issue that see is that the cache sync also uses the above macros.
>>> This is a problem since KSEG0 is now cached (the code must run from
>>> un-cached place) and the HAL_DCACHE_SYNC
>>> is called from many places in code.
>>>
>>> Is there any need for the "sync" operation?
>>> Does the invalidate is the correct operation do for "sync"?
>>
>> I use the macros already defined from eCos. You need to run the code from
>> Uncached segment, just OR 0x20000000 to your code address, so your bootcode 
>> is
>> then at 0xb1000000 (which is the uncached mirror of your code). There's a
>> CYGARC_START_FUNC_UNCACHED define which is the only thing you need to set
>> normally, eCos does the rest.
>>
>> Bye...
>>
>>>
>>> On Wed, Jan 5, 2011 at 11:50 AM, Stefan Sommerfeld <sommerf...@mikrom.de> 
>>> wrote:
>>>> Hi Elad,
>>>>
>>>> I've ported eCos to PMC-Sierra MSP8510 which is a MIPS64 based CPU. I would
>>>> suggest using a simple MMU setup to have the full control over the cached 
>>>> area.
>>>> Simply jumping to 0x8xxxxxxx will work, but you need to setup the cache 
>>>> flags in
>>>> the config register.
>>>>
>>>> I've been using eCos on that CPU for year's now and have added nice MMU 
>>>> stuff
>>>> like code write protection aso. I can help you with some setup files if 
>>>> you like.
>>>>
>>>> Bye...
>>>>
>>>> On 03.01.2011 16:41, Elad Yosef wrote:
>>>>> Hi,
>>>>> I have ported the RedBoot for MIPS32 4Kc from the Atlas to my platform.
>>>>> I have the peripherals working (UART + Ethernet).
>>>>> The memory layout changed to fit my target and now I want to start
>>>>> using the cache.
>>>>> My code runs from Kseg0 and KO in Config0 is 0.
>>>>>
>>>>> From I found in the code I see the cache initialization is not fully
>>>>> implemented for this CPU.
>>>>> The only think that is done on the cache is some invalidate action.
>>>>>
>>>>> for the i-cache:
>>>>> cache 0x8 (address)
>>>>> for the d-cache:
>>>>> cache 0x9 (address)
>>>>>
>>>>> address runs from 0x80000000 up to 0x80004000 in 0x10 steps.
>>>>>
>>>>> Is it enough to initialize the cache?
>>>>> Am I missing any configuration?
>>>>> I couldn't find any implementation for XCACHE_ENABLE
>>>>>
>>>>> Thank
>>>>> Elad
>>>>>
>>>>

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Reply via email to