[ECOS] MPC860, hal_delay_us fails

[ECOS] MPC860, hal_delay_us fails

[nprasad3]

Hi,

I am trying to get eCos running on a custom board that has an MPC860 processor. Can someone please provide more insight into this routine and why it fails.

1. hal_delay_us - processor stays put in the following loop (*forever*). 

  do {
            asm volatile("mfdec  %0;" : "=r"(new_dec) : );        
        } while (old_dec == new_dec);

The register values for old_dec and new_dec do not change at all and hence cpu is spinning in it forever. I replaced the routine with a simple for loop to simulate delay ofcourse not at all accurately and redboot comes up fine. This routine is called in the early phases of redboot (before even redboot writes information so it was giving the false impression that there was something seriously wrong with the config).

2. Initialization of MMU in vector.S throws an exception. 

     # Initialize MMU.
        bl      hal_MMU_init

        # Enable MMU so we can safely enable caches.
        lwi     r3,CYG_MSR              # interrupts enabled later
        sync
        mtmsr   r3
        sync                <--- processor jumps to cyg_hal_default_exception_vsr

I've blocked out this code for now but would like to understand whats going wrong. Is there a way for me to prevent configtool from defining CYGHWR_HAL_POWERPC_ENABLE_MMU  (it is grayed out in my config). 

Thanks in advance and please let me know if these have been addressed somewhere as I am very new to eCos and this is the first time that I am trying to play with it as well as the MPC860!

Nirmal




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

Re: [ECOS] MPC860, hal_delay_us fails

[Eric Doenges]

nprasad3@gmu.edu wrote:
> Hi,
> 
> I am trying to get eCos running on a custom board that has an MPC860 processor. Can someone please provide more insight into this routine and why it fails.
> 
> 1. hal_delay_us - processor stays put in the following loop (*forever*). 
> 
>   do {
>             asm volatile("mfdec  %0;" : "=r"(new_dec) : );        
>         } while (old_dec == new_dec);
> 
> The register values for old_dec and new_dec do not change at all and hence
 > cpu is spinning in it forever. I replaced the routine with a simple 
for loop
 > to simulate delay ofcourse not at all accurately and redboot comes up 
fine.
 > This routine is called in the early phases of redboot (before even
 > redboot writes information so it was giving the false impression that 
there
 > was something seriously wrong with the config).

The way I read PPC documentation, the decrementor should always be
decrementing from the same clock source as the time base counter. Does
your time base counter increment on the 860 ? If it does, the other
possibility is that the compiler wrongly assumes that new_dec doesn't
change in the do ... while loop and falsely optimizes it into an endless
loop - however this seem rather unlikely as other people would have
encountered this problem as well. I think you should check how the time
base clock source is generated on the PPC 860 in general and your board
in particular.
-- 
--------------------------------------------------------------------
|     Eric Doenges              |     DynaPel Laboratories GmbH    |
|     Tel: +49 89 962428 23     |     Fraunhoferstrasse 9/2        |
|     Fax: +49 89 962428 90     |     D - 85737 Ismaning, Germany  |
--------------------------------------------------------------------


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