headers
anoop r | 6 Mar 2007 11:27
Picon
Favicon

-- MPC8248 port


Hi,
    i'm trying to port ecos to the MPC8248 based EP8248e board. it had linux
on-board previously. i used the variant hal from the rattler port. i'm stuck
at a point where the SMC is initialised and the control has reached
cyg_start. now diag_printf goes into an inifinite loop waiting for the
transmit buffer to get ready. it is happening in the function
"cyg_hal_plf_serial_putc".

thanks
anoop.
--

-- 
View this message in context: http://www.nabble.com/---MPC8248-port-tf3354409.html#a9328881
Sent from the Sourceware - ecos-devel mailing list archive at Nabble.com.
Permalink | Reply | 0 comments |
headers
khoffmann | 14 Mar 2007 09:06

Scheduler problem with MPC855T port

Hello everybody,

I've got a problem with my attempts to port eCos to our MPC855T board:

I started with the FADS template (which I now know, was not the best idea) 
and got so far that I can access my RAM, my FLASH, the UARTs and the FEC 
(at least I can see the DHCP requests on the net).

When I compile the 'twothreads' example, I can find a bunch of threads in 
the internal threadlist, obviously everything fine, some 'SLEEPING', some 
'RUNNING'.

But after each thread has  run once, the processor is only looping  throug 
the main_idle_thread() and it's doing nothing else. The trace issues the 
following a short time before the endless 'loop' (where the 'loop' is 
probably triggered by an external interrupt).

TRACE: <2>[447]void Cyg_Mutex::unlock() return void
TRACE: <2>[709]void Cyg_Alarm::initialize() enter
TRACE: <2>[277]void Cyg_Counter::add_alarm() enter
TRACE: <2>[277]void Cyg_Counter::add_alarm() RETURNING UNSET!
TRACE: <2>[709]void Cyg_Alarm::initialize() RETURNING UNSET!
TRACE: <2>[351]static void Cyg_Thread::sleep() enter
TRACE: <2>[271]void Cyg_Scheduler_Implementation::rem_thread() enter
TRACE: <2>[271]void Cyg_Scheduler_Implementation::rem_thread() 
thread=0045de10
TRACE: <2>[325]void Cyg_Scheduler_Implementation::rem_thread() return void
TRACE: <2>[372]static void Cyg_Thread::sleep() return void
TRACE: <2>[741]void Cyg_ThreadQueue_Implementation::enqueue() enter
TRACE: <2>[741]void Cyg_ThreadQueue_Implementation::enqueue()
(Continue reading)

Permalink | Reply | 4 comments |
headers
Andrew Lunn | 14 Mar 2007 09:55
Picon

Re: Scheduler problem with MPC855T port

On Wed, Mar 14, 2007 at 09:06:06AM +0100, khoffmann <at> mmm.com wrote:
> Hello everybody,
> 
> I've got a problem with my attempts to port eCos to our MPC855T board:
> 
> I started with the FADS template (which I now know, was not the best idea) 
> and got so far that I can access my RAM, my FLASH, the UARTs and the FEC 
> (at least I can see the DHCP requests on the net).
> 
> When I compile the 'twothreads' example, I can find a bunch of threads in 
> the internal threadlist, obviously everything fine, some 'SLEEPING', some 
> 'RUNNING'.
> 
> But after each thread has  run once, the processor is only looping  throug 
> the main_idle_thread() and it's doing nothing else. The trace issues the 
> following a short time before the endless 'loop' (where the 'loop' is 
> probably triggered by an external interrupt).
> 
> TRACE: <2>[447]void Cyg_Mutex::unlock() return void
> TRACE: <2>[709]void Cyg_Alarm::initialize() enter
> TRACE: <2>[277]void Cyg_Counter::add_alarm() enter
> TRACE: <2>[277]void Cyg_Counter::add_alarm() RETURNING UNSET!
> TRACE: <2>[709]void Cyg_Alarm::initialize() RETURNING UNSET!
> TRACE: <2>[351]static void Cyg_Thread::sleep() enter
> TRACE: <2>[271]void Cyg_Scheduler_Implementation::rem_thread() enter
> TRACE: <2>[271]void Cyg_Scheduler_Implementation::rem_thread() 
> thread=0045de10
> TRACE: <2>[325]void Cyg_Scheduler_Implementation::rem_thread() return void
> TRACE: <2>[372]static void Cyg_Thread::sleep() return void
> TRACE: <2>[741]void Cyg_ThreadQueue_Implementation::enqueue() enter
(Continue reading)

Permalink | Reply | 3 comments |
headers
khoffmann | 15 Mar 2007 08:53

Re: Scheduler problem with MPC855T port

Hello Andrew, thanks for your quick reply!

Andrew Lunn <andrew <at> lunn.ch> wrote on 14.03.2007 09:55:36:
> 
> Timer tick. Run some of the kernel timer tests. I expect they will all
> fail because your timer is not ticking.

Is there a function, that I have to hook on a special interrupt? 

I tried to compile the tests, but the compiler always aborts with a 
SEGVFAULT when compiling the test for 'ctime' :-(

> /opt/ecos/ecos-2.0/packages/language/c/libc/time/v2_0/tests/ctime.c: In 
function `test':
> /opt/ecos/ecos-2.0/packages/language/c/libc/time/v2_0/tests/ctime.c:124: 
internal error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.

Mit freundlichen Grüßen
Karsten Hoffmann

--

-- 
3M Deutschland GmbH
Telecommunications
Carl-Schurz-Straße 1
D-41453 Neuss
Tel:   +49-2131-14 58 73 
Fax:  +49-2131-14 12 58 73
(Continue reading)

Permalink | Reply | 2 comments |
headers
Andrew Lunn | 15 Mar 2007 09:28
Picon

Re: Scheduler problem with MPC855T port

On Thu, Mar 15, 2007 at 08:53:02AM +0100, khoffmann <at> mmm.com wrote:
> Hello Andrew, thanks for your quick reply!
> 
> Andrew Lunn <andrew <at> lunn.ch> wrote on 14.03.2007 09:55:36:
> > 
> > Timer tick. Run some of the kernel timer tests. I expect they will all
> > fail because your timer is not ticking.
> 
> Is there a function, that I have to hook on a special interrupt? 

Yes, look at the HAL. It will initialize the timer. eg normally
hal_clock_initialize, and the macro CYGNUM_HAL_INTERRUPT_RTC should be
the timer interrupt.

    Andrew
Permalink | Reply | 1 comment |
headers
Gary Thomas | 15 Mar 2007 12:15
Favicon

Re: Scheduler problem with MPC855T port

Andrew Lunn wrote:
> On Thu, Mar 15, 2007 at 08:53:02AM +0100, khoffmann <at> mmm.com wrote:
>> Hello Andrew, thanks for your quick reply!
>>
>> Andrew Lunn <andrew <at> lunn.ch> wrote on 14.03.2007 09:55:36:
>>> Timer tick. Run some of the kernel timer tests. I expect they will all
>>> fail because your timer is not ticking.
>> Is there a function, that I have to hook on a special interrupt? 
> 
> Yes, look at the HAL. It will initialize the timer. eg normally
> hal_clock_initialize, and the macro CYGNUM_HAL_INTERRUPT_RTC should be
> the timer interrupt.

On the PowerPC, this is almost always the decrementer interrupt.
On some cores, the decrementer has to be enabled - check your
hardware manual.

--

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Guennadi Liakhovetski | 23 Mar 2007 16:05
Picon
Favicon

Configuring RedBoot from under Linux

Hi

I'd like to be able to configure redboot from under Linux. Which means, 
creating a redboot configuration partition image according to a new 
configuration. I could imagine a tool similar to lilo that reads 
redboot.conf and creates a redboot configuration and flash partition table 
image, optionally supplying it with a CRC. Does anything like this exist?

Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
Permalink | Reply | 1 comment |
headers
Jon Ringle | 23 Mar 2007 17:54
Gravatar

Re: Configuring RedBoot from under Linux

Guennadi Liakhovetski wrote:
> Hi
>
> I'd like to be able to configure redboot from under Linux. Which 
> means, creating a redboot configuration partition image according to a 
> new configuration. I could imagine a tool similar to lilo that reads 
> redboot.conf and creates a redboot configuration and flash partition 
> table image, optionally supplying it with a CRC. Does anything like 
> this exist?
>
I have found the following useful which gives an fconfig interface from 
Linux:
http://andrzejekiert.ovh.org/software.html.en

Jon
Permalink | Reply | 0 comments |

Gmane