[ECOS] reboot is slow

[ECOS] reboot is slow

[linux.chips]

hi

i have rebuilt redboot successfully (RAM and ROM versions), every thing 
works fine but slow, very slow. the board is ap48 (a ubnt nanostation 5, 
which i like to customize), it has a stock redboot wich runs much faster 
than what i have built !!!
for example pinging the board (running stock redboot) replys in about 4 
ms average while pinging with my redboot is about 30 ms.
decompressing a lzma image takes forever (10+ minutes) !!! the stock 
redboot decompresses it under 5 seconds. running from ram or flash dose 
not make that deference. loading files from tftp also very slow about 10 
kBps

i took the code and patches from dd-wrt microredboot

more info about the broard:
cpu: mips 4kc 180 MHz
rom: 4 MB
ram: 16 MB

what can i do to figure out the root of the problem??? any help is 
appreciated.

thanks in advance
regards

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

RE: [ECOS] reboot is slow

[Kurt Siedenburg]

Likely some of your basic initialization is wrong or incomplete:
- Are cache(s) enabled?
- Is the memory system initialization correct (wait states)?
- Is the CPU clock tunable (and does it run at full speed)?

Also get the source code of the stock redboot for your board to see what
they have done.
Best,
  Kurt

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of linux.chips
Sent: Thursday, January 05, 2012 2:08 AM
To: ecos-discuss@ecos.sourceware.org
Subject: [ECOS] reboot is slow

hi

i have rebuilt redboot successfully (RAM and ROM versions), every thing
works fine but slow, very slow. the board is ap48 (a ubnt nanostation 5,
which i like to customize), it has a stock redboot wich runs much faster
than what i have built !!!
for example pinging the board (running stock redboot) replys in about 4
ms average while pinging with my redboot is about 30 ms.
decompressing a lzma image takes forever (10+ minutes) !!! the stock
redboot decompresses it under 5 seconds. running from ram or flash dose
not make that deference. loading files from tftp also very slow about 10
kBps

i took the code and patches from dd-wrt microredboot

more info about the broard:
cpu: mips 4kc 180 MHz
rom: 4 MB
ram: 16 MB

what can i do to figure out the root of the problem??? any help is
appreciated.

thanks in advance
regards

--
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

Re: [ECOS] reboot is slow

[linux.chips]

thanks for the reply

the caches are enabled (typing cache in the prompt tells me it on ). i 
am not sure where to find the memory initialization, currently looking 
for it. the cpu clock is tunable as far as i now, i can see options for 
cpu clock selections in the cdl files. how can i verify the 
initialization and cpu clock are correct??
unfortunately i could not get a source code of the stock redboot.


On 01/05/2012 01:18 PM, Kurt Siedenburg wrote:
> Likely some of your basic initialization is wrong or incomplete:
> - Are cache(s) enabled?
> - Is the memory system initialization correct (wait states)?
> - Is the CPU clock tunable (and does it run at full speed)?
>
> Also get the source code of the stock redboot for your board to see what
> they have done.
> Best,
>    Kurt
>
> -----Original Message-----
> From:ecos-discuss-owner@ecos.sourceware.org
> [mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of linux.chips
> Sent: Thursday, January 05, 2012 2:08 AM
> To:ecos-discuss@ecos.sourceware.org
> Subject: [ECOS] reboot is slow
>
> hi
>
> i have rebuilt redboot successfully (RAM and ROM versions), every thing
> works fine but slow, very slow. the board is ap48 (a ubnt nanostation 5,
> which i like to customize), it has a stock redboot wich runs much faster
> than what i have built !!!
> for example pinging the board (running stock redboot) replys in about 4
> ms average while pinging with my redboot is about 30 ms.
> decompressing a lzma image takes forever (10+ minutes) !!! the stock
> redboot decompresses it under 5 seconds. running from ram or flash dose
> not make that deference. loading files from tftp also very slow about 10
> kBps
>
> i took the code and patches from dd-wrt microredboot
>
> more info about the broard:
> cpu: mips 4kc 180 MHz
> rom: 4 MB
> ram: 16 MB
>
> what can i do to figure out the root of the problem??? any help is
> appreciated.
>
> thanks in advance
> regards
>
> --
> 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

[ECOS] Re: reboot is slow

[Grant Edwards]

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

Re: [ECOS] Re: reboot is slow

[Elad Yosef]

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


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
>

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

Re: [ECOS] Re: reboot is slow

[linux.chips]

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

Re: [ECOS] Re: reboot is slow

[Elad Yosef]

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

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

Re: [ECOS] Re: reboot is slow

[linux.chips]

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
>
the only RTC definitions i can find are these, what relation they should 
hold to the hw clock? btw i checked all the clock control registers and 
they seem fine compared the the stock ones, trying to get a scope to see 
if the clock is actually correct.

     cdl_component CYGNUM_HAL_RTC_CONSTANTS {
         display       "Real-time clock constants."
         flavor        none

         cdl_option CYGNUM_HAL_RTC_NUMERATOR {
             display       "Real-time clock numerator"
             flavor        data
             calculated    100000000
         }
         cdl_option CYGNUM_HAL_RTC_DENOMINATOR {
             display       "Real-time clock denominator"
             flavor        data
             calculated    100
         }
         cdl_option CYGNUM_HAL_RTC_PERIOD {
             display       "Real-time clock period"
             flavor        data
             calculated    { 110000000 / CYGNUM_HAL_RTC_DENOMINATOR }
             description   "
                 The count and compare registers of the AR5312 are used
                 to drive the eCos kernel RTC. The count register
                 increments at the CPU clock speed."
         }
     }

> 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

Re: [ECOS] Re: reboot is slow

[linux.chips]

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