[ECOS] problem about interrupt end

[ECOS] problem about interrupt end

[jiang jet]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb2312; format=flowed, Size: 778 bytes --]

hello everyone:
    When I am transplating ecos to a board based on mips r3k , I met an 
interrupt problem: when rtc interrupt is enabled, and isr is called, then 
go through to interrupt end, here when unlock, the lock number is changed, 
now it's a very big number:80000730,sometimes it can change to other number 
such as 800007ec... before the interrupt,the number looks correct which is 
1..and suddenly changed to such a big number ,what's reason?
   thanks in advance!
best regards
  jet

_________________________________________________________________
Ãâ·ÑÏÂÔØ MSN Explorer:   http://explorer.msn.com/lccn/  


-- 
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] problem about interrupt end

[Nick Garnett]

"jiang jet" <jetjiang@hotmail.com> writes:

> hello everyone:
>     When I am transplating ecos to a board based on mips r3k , I met
> an interrupt problem: when rtc interrupt is enabled, and isr is
> called, then go through to interrupt end, here when unlock, the lock
> number is changed, now it's a very big number:80000730,sometimes it
> can change to other number such as 800007ec... before the
> interrupt,the number looks correct which is 1..and suddenly changed to
> such a big number ,what's reason?

This looks like memory corruption. 0x80000730 would be a resonable
data or code address on MIPS.

Perhaps you are not cancelling the interrupt properly and getting
interrupt stack overflow.


-- 
Nick Garnett                                     eCos Kernel Architect
http://www.ecoscentric.com                The eCos and RedBoot experts


-- 
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] problem about interrupt end

[jiang jet]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb2312; format=flowed, Size: 2095 bytes --]

thank you for answering my question...
I trace the interrupt progress, and I found the number is changed when the 
code is going from assembly code to c code£¨call isr through 
hal_interrupt_handlers)..
it's the first time for timer to interrupt and then the program breaks 
down..
do you mean there are some other interrupts or the same intererupts 
happened during this period(from system bootup to the time of the first 
timer interrupt happening)?
and I adjust the stack size ,but it seems it doesn't work :(

thank you again


>From: Nick Garnett <nickg@ecoscentric.com>
>To: "jiang jet" <jetjiang@hotmail.com>
>CC: ecos-discuss@ecos.sourceware.org
>Subject: Re: [ECOS] problem about interrupt end
>Date: 22 Nov 2006 10:50:29 +0000
>
>"jiang jet" <jetjiang@hotmail.com> writes:
>
> > hello everyone:
> >     When I am transplating ecos to a board based on mips r3k , I met
> > an interrupt problem: when rtc interrupt is enabled, and isr is
> > called, then go through to interrupt end, here when unlock, the lock
> > number is changed, now it's a very big number:80000730,sometimes it
> > can change to other number such as 800007ec... before the
> > interrupt,the number looks correct which is 1..and suddenly changed to
> > such a big number ,what's reason?
>
>This looks like memory corruption. 0x80000730 would be a resonable
>data or code address on MIPS.
>
>Perhaps you are not cancelling the interrupt properly and getting
>interrupt stack overflow.
>
>
>--
>Nick Garnett                                     eCos Kernel Architect
>http://www.ecoscentric.com                The eCos and RedBoot experts
>
>
>--
>Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
>and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>

_________________________________________________________________
ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£  http://www.hotmail.com  


-- 
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] problem about interrupt end

[Nick Garnett]

"jiang jet" <jetjiang@hotmail.com> writes:

> thank you for answering my question...
> I trace the interrupt progress, and I found the number is changed when
> the code is going from assembly code to c code（call isr through
> hal_interrupt_handlers)..
> it's the first time for timer to interrupt and then the program breaks
> down..
> do you mean there are some other interrupts or the same intererupts
> happened during this period(from system bootup to the time of the
> first timer interrupt happening)?

It may be the same interrupt happening again. If the interrupt
condition has not been cancelled, it is possible for the interrupt to
be re-delivered as soon as interrupts are re-enabled. If this is
before the stack has been totally unwound, then it will chew its way
down the stack and on into other data.

Note that this is only a suggestion, I have no idea whether this is
what is actually happening in your case.


> and I adjust the stack size ,but it seems it doesn't work :(

It is unlikely that this will have any effect, the stack corruption
will chew up any size of stack very quickly.

-- 
Nick Garnett                                     eCos Kernel Architect
http://www.ecoscentric.com                The eCos and RedBoot experts


--
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] problem about interrupt end

[jiang jet]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb2312; format=flowed, Size: 2414 bytes --]

I think i have excluded the reason of repeating interrupt causing this 
problem...
I prolong the timer to a very big number..so I can see for the first timer 
interrput the breakdown occurs...
since the board and cpu is designed by ourself, I doubt if the assembly 
code for processing the interrupt needed to be modified(I refer to the code 
process :__defualt_intterrupt_vsr-->hal_interrupt_handlers-->isr--here code 
crashed))???is it possible?

thanks a lot

jet jiang

>From: Nick Garnett <nickg@ecoscentric.com>
>To: "jiang jet" <jetjiang@hotmail.com>
>CC: ecos-discuss@ecos.sourceware.org
>Subject: Re: [ECOS] problem about interrupt end
>Date: 23 Nov 2006 09:43:34 +0000
>
>"jiang jet" <jetjiang@hotmail.com> writes:
>
> > thank you for answering my question...
> > I trace the interrupt progress, and I found the number is changed when
> > the code is going from assembly code to c code£¨call isr through
> > hal_interrupt_handlers)..
> > it's the first time for timer to interrupt and then the program breaks
> > down..
> > do you mean there are some other interrupts or the same intererupts
> > happened during this period(from system bootup to the time of the
> > first timer interrupt happening)?
>
>It may be the same interrupt happening again. If the interrupt
>condition has not been cancelled, it is possible for the interrupt to
>be re-delivered as soon as interrupts are re-enabled. If this is
>before the stack has been totally unwound, then it will chew its way
>down the stack and on into other data.
>
>Note that this is only a suggestion, I have no idea whether this is
>what is actually happening in your case.
>
>
> > and I adjust the stack size ,but it seems it doesn't work :(
>
>It is unlikely that this will have any effect, the stack corruption
>will chew up any size of stack very quickly.
>
>--
>Nick Garnett                                     eCos Kernel Architect
>http://www.ecoscentric.com                The eCos and RedBoot experts
>
>
>--
>Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
>and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>

_________________________________________________________________
Ãâ·ÑÏÂÔØ MSN Explorer:   http://explorer.msn.com/lccn/  


-- 
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] problem about interrupt end

[Nick Garnett]

"jiang jet" <jetjiang@hotmail.com> writes:

> I think i have excluded the reason of repeating interrupt causing this
> problem...
> I prolong the timer to a very big number..so I can see for the first
> timer interrput the breakdown occurs...
> since the board and cpu is designed by ourself, I doubt if the
> assembly code for processing the interrupt needed to be modified(I
> refer to the code process
> :__defualt_intterrupt_vsr-->hal_interrupt_handlers-->isr--here code
> crashed))???is it possible?

In that case it looks like memory corruption from some other
source. Perhaps thread stack overflow. If the board is your own design
then check that RAM address decode is being handled correctly and not
wrapping unexpectedly.

-- 
Nick Garnett                                     eCos Kernel Architect
http://www.ecoscentric.com                The eCos and RedBoot experts


-- 
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] problem about interrupt end

[jiang jet]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb2312; format=flowed, Size: 2884 bytes --]

I have resolved the problem,but met another problem. 
1)resolved methed: I don't know if it's a bug of ecos source code, in   
  packages/hal/mips/arch/v2_0/src/vector.S
      #ifdef CYGFUN_HAL_COMMON_KERNEL_SUPPORT
             la   vo,cyg_scheduler_sched_lock
             nop                    //added by me, maybe this one is not 
necessary
             lw   a0,0(v0)
             nop                      //added by me,here it's delay 
slot,but original code 
             add a0,a0,1              //just put add a0,a0,1 there, I dobut 
if it's a bug
             sw a0,0(v0)               //but it resolved my problem...
             .........
       #endif
2)the new problem I met
  in unlock_inner, the process is like this:
  
unlock_inner---->Cyg_interupt::call_pending_DSRs()--->hal_interrupt_stack_pending_DSRs-->

interrupt_call_pending_DSRs--->Cyg_interrupt::call_pending_DSRs_inner()-->intr->dsr--->..

  the problem is When I enter the intr->dsr(here is realtime clock dsr),the 
stack is destoried. Before enter DSR,the return address is saved 
in,say,0x80004704(now correct), after enter DSR, the content is changed!!I 
have checked: after enter the dsr ,sp is 0x80004738,and then changed to 
0x80004718, so it is IMPOSSIBLE for dsr procedure to destory the stack 
content(0x800004704),but during this period( inner to DSR), there is no 
other opreations..I wonder what changes this value?? 
   btw: I am using the clocktruth.cxx to have a test...

thanks a lot

jet

>From: Nick Garnett <nickg@ecoscentric.com>
>To: "jiang jet" <jetjiang@hotmail.com>
>CC: ecos-discuss@ecos.sourceware.org
>Subject: Re: [ECOS] problem about interrupt end
>Date: 29 Nov 2006 11:24:34 +0000
>
>"jiang jet" <jetjiang@hotmail.com> writes:
>
> > I think i have excluded the reason of repeating interrupt causing this
> > problem...
> > I prolong the timer to a very big number..so I can see for the first
> > timer interrput the breakdown occurs...
> > since the board and cpu is designed by ourself, I doubt if the
> > assembly code for processing the interrupt needed to be modified(I
> > refer to the code process
> > :__defualt_intterrupt_vsr-->hal_interrupt_handlers-->isr--here code
> > crashed))???is it possible?
>
>In that case it looks like memory corruption from some other
>source. Perhaps thread stack overflow. If the board is your own design
>then check that RAM address decode is being handled correctly and not
>wrapping unexpectedly.
>
>--
>Nick Garnett                                     eCos Kernel Architect
>http://www.ecoscentric.com                The eCos and RedBoot experts
>

_________________________________________________________________
Ãâ·ÑÏÂÔØ MSN Explorer:   http://explorer.msn.com/lccn/  


-- 
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] problem about interrupt end

[jiang jet]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb2312; format=flowed, Size: 1636 bytes --]


hi, I have resolved that problem:)
it's caused by diag_printf:)
thanks again
jet

>From: Nick Garnett <nickg@ecoscentric.com>
>To: "jiang jet" <jetjiang@hotmail.com>
>CC: ecos-discuss@ecos.sourceware.org
>Subject: Re: [ECOS] problem about interrupt end
>Date: 29 Nov 2006 11:24:34 +0000
>
>"jiang jet" <jetjiang@hotmail.com> writes:
>
> > I think i have excluded the reason of repeating interrupt causing this
> > problem...
> > I prolong the timer to a very big number..so I can see for the first
> > timer interrput the breakdown occurs...
> > since the board and cpu is designed by ourself, I doubt if the
> > assembly code for processing the interrupt needed to be modified(I
> > refer to the code process
> > :__defualt_intterrupt_vsr-->hal_interrupt_handlers-->isr--here code
> > crashed))???is it possible?
>
>In that case it looks like memory corruption from some other
>source. Perhaps thread stack overflow. If the board is your own design
>then check that RAM address decode is being handled correctly and not
>wrapping unexpectedly.
>
>--
>Nick Garnett                                     eCos Kernel Architect
>http://www.ecoscentric.com                The eCos and RedBoot experts
>
>
>--
>Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
>and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>

_________________________________________________________________
Ãâ·ÑÏÂÔØ MSN Explorer:   http://explorer.msn.com/lccn/  


-- 
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] problem about interrupt end

[Michael Pederson]

Jiang, I would be most appreciative if you could elaborate for me the
problem you were seeing with diag_printf.  I have also been seeing some
stack corruption that only appears when it is used.

jiang jet wrote:
> 
> hi, I have resolved that problem:)
> it's caused by diag_printf:)
> thanks again
> jet
> 
>> From: Nick Garnett <nickg@ecoscentric.com>
>> To: "jiang jet" <jetjiang@hotmail.com>
>> CC: ecos-discuss@ecos.sourceware.org
>> Subject: Re: [ECOS] problem about interrupt end
>> Date: 29 Nov 2006 11:24:34 +0000
>>
>> "jiang jet" <jetjiang@hotmail.com> writes:
>>
>> > I think i have excluded the reason of repeating interrupt causing this
>> > problem...
>> > I prolong the timer to a very big number..so I can see for the first
>> > timer interrput the breakdown occurs...
>> > since the board and cpu is designed by ourself, I doubt if the
>> > assembly code for processing the interrupt needed to be modified(I
>> > refer to the code process
>> > :__defualt_intterrupt_vsr-->hal_interrupt_handlers-->isr--here code
>> > crashed))???is it possible?
>>
>> In that case it looks like memory corruption from some other
>> source. Perhaps thread stack overflow. If the board is your own design
>> then check that RAM address decode is being handled correctly and not
>> wrapping unexpectedly.
>>
>> -- 
>> Nick Garnett                                     eCos Kernel Architect
>> http://www.ecoscentric.com                The eCos and RedBoot experts

-- 
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] question about twothreads.c

[jiang jet]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb2312; format=flowed, Size: 1149 bytes --]

hi,all
   I am porting ecos to one mips board, and it seems to be working now( I 
use some testcase to test it,work correctly).
   and then I use /example/twothreads.c to have a test, the program doesn't 
work:(, 
  I see the source code in twothreads.c ,the entry code is 
"cyg_user_start", and I modified it to be "cyg_start", then the program can 
go on,but it seems that the threads don't work at all...
   question 1) I wonder what's the difference between "cyg_user_start" and 
"cyg_start", or between "cyg_start" and "main",or between "cyg_user_start" 
and "main"???
   question 2) In other test case such as clocktruth.cxx, i see after the 
thread is resumed, then use Cyg_scheduler::start() to make the threads 
become schedled, but in twothreads.c there is no this rutine, how are these 
thread scheduled??

thanks in advance for any answer and insight
jet

_________________________________________________________________
Ãâ·ÑÏÂÔØ MSN Explorer:   http://explorer.msn.com/lccn  


-- 
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] question about twothreads.c

[jiang jet]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb2312; format=flowed, Size: 1925 bytes --]

I have found the answer of my question :)
anyway, thank you for viewing my question..

still one question..how does ecos jump to "main" function??
defualt cyg_start just jump to cyg_user_start, but have no clue telling me 
how it jumps to main?? 

thanks
jet


>From: "jiang jet" <jetjiang@hotmail.com>
>To: ecos-discuss@ecos.sourceware.org
>Subject: [ECOS] question about twothreads.c
>Date: Thu, 14 Dec 2006 16:12:11 +0800
>
>hi,all
>   I am porting ecos to one mips board, and it seems to be working 
>now( I use some testcase to test it,work correctly).
>   and then I use /example/twothreads.c to have a test, the program 
>doesn't work:(,  I see the source code in twothreads.c ,the entry 
>code is "cyg_user_start", and I modified it to be "cyg_start", then 
>the program can go on,but it seems that the threads don't work at 
>all...
>   question 1) I wonder what's the difference between 
>"cyg_user_start" and "cyg_start", or between "cyg_start" and 
>"main",or between "cyg_user_start" and "main"???
>   question 2) In other test case such as clocktruth.cxx, i see 
>after the thread is resumed, then use Cyg_scheduler::start() to make 
>the threads become schedled, but in twothreads.c there is no this 
>rutine, how are these thread scheduled??
>
>thanks in advance for any answer and insight
>jet
>
>_________________________________________________________________
>Ãâ·ÑÏÂÔØ MSN Explorer:   http://explorer.msn.com/lccn
>
>
>--
>Before posting, please read the FAQ: 
>http://ecos.sourceware.org/fom/ecos
>and search the list archive: 
>http://ecos.sourceware.org/ml/ecos-discuss
>

_________________________________________________________________
ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger:  http://messenger.msn.com/cn  


-- 
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] question about twothreads.c

[Jürgen Lambrecht]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=GB2312, Size: 2272 bytes --]

jiang jet wrote:

> I have found the answer of my question :)
> anyway, thank you for viewing my question..
> 
> still one question..how does ecos jump to "main" function??
> defualt cyg_start just jump to cyg_user_start, but have no clue telling 
> me how it jumps to main??
The main function is started by a C-library thread, see the ecos documentation:
http://ecos.sourceware.org/docs-latest/ref/c-library-startup.html
> thanks
> jet
> 
> 
>> From: "jiang jet" <jetjiang@hotmail.com>
>> To: ecos-discuss@ecos.sourceware.org
>> Subject: [ECOS] question about twothreads.c
>> Date: Thu, 14 Dec 2006 16:12:11 +0800
>>
>> hi,all
>>   I am porting ecos to one mips board, and it seems to be working now( 
>> I use some testcase to test it,work correctly).
>>   and then I use /example/twothreads.c to have a test, the program 
>> doesn't work:(,  I see the source code in twothreads.c ,the entry code 
>> is "cyg_user_start", and I modified it to be "cyg_start", then the 
>> program can go on,but it seems that the threads don't work at all...
>>   question 1) I wonder what's the difference between "cyg_user_start" 
>> and "cyg_start", or between "cyg_start" and "main",or between 
>> "cyg_user_start" and "main"???
>>   question 2) In other test case such as clocktruth.cxx, i see after 
>> the thread is resumed, then use Cyg_scheduler::start() to make the 
>> threads become schedled, but in twothreads.c there is no this rutine, 
>> how are these thread scheduled??
>>
>> thanks in advance for any answer and insight
>> jet
>>
>> _________________________________________________________________
>> Ãâ·ÑÏÂÔØ MSN Explorer:   http://explorer.msn.com/lccn
>>
>>
>> -- 
>> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
>> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>>
> 
> _________________________________________________________________
> ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger:  http://messenger.msn.com/cn 
> 

-- 
J¨¹rgen Lambrecht
Diksmuidse Heerweg 338
8200 Sint-Andries
Tel: +32 (0)50 842901
GSM: +32 (0)476 313389

-- 
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] question about twothreads.c

[jiang jet]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb2312; format=flowed, Size: 2743 bytes --]


thank you so much^_^

jet

>From: J¨¹rgen Lambrecht <Jurgen.Lambrecht@tiscali.be>
>To: jiang jet <jetjiang@hotmail.com>
>CC: ecos-discuss@ecos.sourceware.org
>Subject: Re: [ECOS] question about twothreads.c
>Date: Thu, 14 Dec 2006 11:03:10 +0100
>
>jiang jet wrote:
>
> > I have found the answer of my question :)
> > anyway, thank you for viewing my question..
> >
> > still one question..how does ecos jump to "main" function??
> > defualt cyg_start just jump to cyg_user_start, but have no clue telling
> > me how it jumps to main??
>The main function is started by a C-library thread, see the ecos 
documentation:
>http://ecos.sourceware.org/docs-latest/ref/c-library-startup.html
> > thanks
> > jet
> >
> >
> >> From: "jiang jet" <jetjiang@hotmail.com>
> >> To: ecos-discuss@ecos.sourceware.org
> >> Subject: [ECOS] question about twothreads.c
> >> Date: Thu, 14 Dec 2006 16:12:11 +0800
> >>
> >> hi,all
> >>   I am porting ecos to one mips board, and it seems to be working now(
> >> I use some testcase to test it,work correctly).
> >>   and then I use /example/twothreads.c to have a test, the program
> >> doesn't work:(,  I see the source code in twothreads.c ,the entry code
> >> is "cyg_user_start", and I modified it to be "cyg_start", then the
> >> program can go on,but it seems that the threads don't work at all...
> >>   question 1) I wonder what's the difference between "cyg_user_start"
> >> and "cyg_start", or between "cyg_start" and "main",or between
> >> "cyg_user_start" and "main"???
> >>   question 2) In other test case such as clocktruth.cxx, i see after
> >> the thread is resumed, then use Cyg_scheduler::start() to make the
> >> threads become schedled, but in twothreads.c there is no this rutine,
> >> how are these thread scheduled??
> >>
> >> thanks in advance for any answer and insight
> >> jet
> >>
> >> _________________________________________________________________
> >> Ãâ·ÑÏÂÔØ MSN Explorer:   http://explorer.msn.com/lccn
> >>
> >>
> >> --
> >> Before posting, please read the FAQ: 
http://ecos.sourceware.org/fom/ecos
> >> and search the list archive: 
http://ecos.sourceware.org/ml/ecos-discuss
> >>
> >
> > _________________________________________________________________
> > ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger:  
http://messenger.msn.com/cn
> >
>
>--
>J¨¹rgen Lambrecht
>Diksmuidse Heerweg 338
>8200 Sint-Andries
>Tel: +32 (0)50 842901
>GSM: +32 (0)476 313389

_________________________________________________________________
Ãâ·ÑÏÂÔØ MSN Explorer:   http://explorer.msn.com/lccn/  


-- 
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] SMSC 9215 driver in eCos.

[Kulkarni, Ganapatrao P. IN BLR SISL]

Hi All,
I am working on embedded board (based on SoC S3c2410(ARM9 TDMI core)).
We are using eCos based bootloader(redboot) for booting the Linux
kernel. Our board has a on board Ethernet controller from SMSC (SMSC
9215). Can anybody have info/code about SMSC9215 driver in eCos.


Thanks in advance
Best Regards
Ganapat

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