[ECOS] Re: reboot is slow

linux.chips linux.chips@gmail.com
Fri Jan 13 17:58:00 GMT 2012


On 01/08/2012 10:04 AM, Elad Yosef wrote:
> Check the RTC definitions in the ecc file. compare them to the CPU clock in HW.
> these const have effect on the delay in the system
>
would this effect redboot in the first place? is not that for ecos kernel?
> On Fri, Jan 6, 2012 at 10:06 PM, linux.chips<linux.chips@gmail.com>  wrote:
>> On 01/06/2012 08:52 AM, Elad Yosef wrote:
>>> Hi,
>>> In vectors.S you have call to hal_cache_init()
>>> which in turn calls hal_c_cache_init
>>> The last one calls to dcache init and icache init and only after it
>>> enables the caches by setting KO in config register.
>>> Check that your clear Taglo/Taghi and tagd1/tagd2 (mtc0 %zero %28/29
>>> 2) before the invalidate loop, check your MIPS SUM doc to find the
>>> exact registers you have.
>>> What is the the address mapping? can it be that you are running from
>>> KSEG1?
>>>
>>> Elad
>>>
>> indeed i am running from KSEG1 (i am running from flash at 0xBE000000) but
>> running from ram is nut much faster.. i checked the code it is setting the
>> registers correctly for the KSEG0 which is in ram... beside, i just had a
>> look on the stock redboot startup script, and it starts by disabling the
>> cache (cache off) then decompressing and still way faster. this is how
>> hal_c_cache_init looks:
>>
>> void hal_c_cache_init(unsigned long config1_val)
>> {
>>   volatile unsigned val;
>>
>>   if (hal_init_icache(config1_val) == -1)
>>     {
>>         /* Error */
>>         ;
>>     }
>>
>>   if (hal_init_dcache(config1_val) == -1)
>>     {
>>         /* Error */
>>         ;
>>     }
>>
>>   // enable cached KSEG0
>>   asm volatile("mfc0 %0,$16;" : "=r"(val));
>>   val&= ~3;
>>   asm volatile("mtc0 %0,$16;" : : "r"(val));
>> }
>>
>> it is only setting the cache for KSEG0  and not touching any thing else
>>
>>> On Fri, Jan 6, 2012 at 12:20 AM, Grant Edwards
>>> <grant.b.edwards@gmail.com>    wrote:
>>>> On 2012-01-05, linux.chips<linux.chips@gmail.com>    wrote:
>>>>
>>>>> the caches are enabled (typing cache in the prompt tells me it on).
>>>> If the HAL code is broken somehow, it might not be telling the truth.
>>>>
>>>>> i am not sure where to find the memory initialization, currently
>>>>> looking for it. the cpu clock is tunable as far as i know, i can see
>>>>> options for cpu clock selections in the cdl files. how can i verify
>>>>> the initialization and cpu clock are correct?
>>>> On all the parts I've ever used, there has been a way to configure the
>>>> hardware to output a clock signal on one of the peripheral pins (if
>>>> not the CPU clock then at least something with a known ratio to the
>>>> CPU clock).  I enable that feature, then use a 'scope to verify the
>>>> clock frequency.
>>>>
>>>> --
>>>> Grant Edwards               grant.b.edwards        Yow! LOOK!!  Sullen
>>>>                                   at               American teens wearing
>>>>                               gmail.com            MADRAS shorts and
>>>> "Flock of
>>>>                                                    Seagulls" HAIRCUTS!
>>>>
>>>>
>>>> --
>>>> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
>>>> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>>>>
>> did not have much time to search for the memory initialization and cpu
>> tuning code, any clues of where to search :)
>>
>> thanks again
>>
>>
>> --
>> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
>> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>>


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



More information about the Ecos-discuss mailing list