[ECOS] eCos invalidating JTAG on ARM architecture ?

[ECOS] eCos invalidating JTAG on ARM architecture ?

[Alexandre]

Hi everyone,

I finally manage to run eCos on my eval board (yipee!) thanks to all
of you guys but i have a slight debugging problem (again i know, I'm a
problem maker -.-).

After I upload my eCos code to my board via JTAG (code which is fully
functioning by the way), I can't by any mean reach it again via JTAG.
OpenOCD just says it can't communicate with my board. Seems like eCos
just disable my JTAG. The only way I can access my micro controller
again is by UART, erasing the flash using ISP, and then reflashing it
by JTAG works anew. So it works, but I can't debug the thing.

I lurked through the mailing list to see if anything like that
happened to someone and couldn't find anything so my first guess is I
did something wrong (I'm a pessimistic person).

There are two JTAGs available on my micro controller, one is supposed
to be always enabled when a definite input is pulled to LOW by
hardware means (which I've done, this is the way I manage to upload
the eCos code in the first ways). The second JTAG is enabled by
registry means.

I tried to upload a dummy code without ecos and the first JTAG (the
hardware enabled) works perfectly without any init. The second one
(the software enabled) works also if I input the correct init (which I
did, I mean I managed to make it work ^^).

But with eCos, neither works :(
I tried to put my init code from the dummy software in the eCos init
but I can't make the second JTAG work and the first one isn't working
either.

I was guessing maybe eCos init for ARM (or maybe the olimex lpc2106
port) may have a thing which disable JTAG. Is it possible or did I do
something wrong and JTAG should work with eCos ?

For reference I use an LPC2106 ARM7 micro controller.

-- 
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: eCos invalidating JTAG on ARM architecture ?

[Alexandre]

A little update on that, the problem does not occur if i use
cyg_usr_start instead of main as an entry point.

On 7/5/07, Alexandre <thekyz@gmail.com> wrote:
> Hi everyone,
>
> I finally manage to run eCos on my eval board (yipee!) thanks to all
> of you guys but i have a slight debugging problem (again i know, I'm a
> problem maker -.-).
>
> After I upload my eCos code to my board via JTAG (code which is fully
> functioning by the way), I can't by any mean reach it again via JTAG.
> OpenOCD just says it can't communicate with my board. Seems like eCos
> just disable my JTAG. The only way I can access my micro controller
> again is by UART, erasing the flash using ISP, and then reflashing it
> by JTAG works anew. So it works, but I can't debug the thing.
>
> I lurked through the mailing list to see if anything like that
> happened to someone and couldn't find anything so my first guess is I
> did something wrong (I'm a pessimistic person).
>
> There are two JTAGs available on my micro controller, one is supposed
> to be always enabled when a definite input is pulled to LOW by
> hardware means (which I've done, this is the way I manage to upload
> the eCos code in the first ways). The second JTAG is enabled by
> registry means.
>
> I tried to upload a dummy code without ecos and the first JTAG (the
> hardware enabled) works perfectly without any init. The second one
> (the software enabled) works also if I input the correct init (which I
> did, I mean I managed to make it work ^^).
>
> But with eCos, neither works :(
> I tried to put my init code from the dummy software in the eCos init
> but I can't make the second JTAG work and the first one isn't working
> either.
>
> I was guessing maybe eCos init for ARM (or maybe the olimex lpc2106
> port) may have a thing which disable JTAG. Is it possible or did I do
> something wrong and JTAG should work with eCos ?
>
> For reference I use an LPC2106 ARM7 micro controller.
>

-- 
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: eCos invalidating JTAG on ARM architecture ?

[Sergei Gavrikov]

On Thu, Jul 05, 2007 at 04:33:48PM +0200, Alexandre wrote:
> A little update on that, the problem does not occur if i use
> cyg_usr_start instead of main as an entry point.
> 

Hm, this your notice quite blocked all my suggestions for you :). Has
your evaluation board something like an ISP/RUN DIP switch? If it has,
try to connect to the board in ISP mode (so, the LPC bootloader isn't
eCos application) using OpenOCD/GDB and then set halt at 0 address or
just return that switch in RUN mode and do a reset. Do you use the
latest OpenOCD SVN build? Do you use the latest eCos CVS? Since 2007/02
hal/arm/arch/current/src/vectors.S had been fixed, that was a LPC
related fix (hal/arm/arch/current/ChangeLog). If you use any faked
binaries of OpenOCD for Windows, it's possible that stuff is obsolete.
Check it.  With 64K RAM you are needed in the JTAG so much. Try to look
through out the OpenOCD discuss lists: ask OpenOCD guys about your
issue. It looks like your problem isn't eCos related problem.

Happy eCosing,

	Sergei


> On 7/5/07, Alexandre <thekyz@gmail.com> wrote:
> >Hi everyone,
> >
> >I finally manage to run eCos on my eval board (yipee!) thanks to all
> >of you guys but i have a slight debugging problem (again i know, I'm a
> >problem maker -.-).
> >
> >After I upload my eCos code to my board via JTAG (code which is fully
> >functioning by the way), I can't by any mean reach it again via JTAG.
> >OpenOCD just says it can't communicate with my board. Seems like eCos
> >just disable my JTAG. The only way I can access my micro controller
> >again is by UART, erasing the flash using ISP, and then reflashing it
> >by JTAG works anew. So it works, but I can't debug the thing.
> >
> >I lurked through the mailing list to see if anything like that
> >happened to someone and couldn't find anything so my first guess is I
> >did something wrong (I'm a pessimistic person).
> >
> >There are two JTAGs available on my micro controller, one is supposed
> >to be always enabled when a definite input is pulled to LOW by
> >hardware means (which I've done, this is the way I manage to upload
> >the eCos code in the first ways). The second JTAG is enabled by
> >registry means.
> >
> >I tried to upload a dummy code without ecos and the first JTAG (the
> >hardware enabled) works perfectly without any init. The second one
> >(the software enabled) works also if I input the correct init (which I
> >did, I mean I managed to make it work ^^).
> >
> >But with eCos, neither works :(
> >I tried to put my init code from the dummy software in the eCos init
> >but I can't make the second JTAG work and the first one isn't working
> >either.
> >
> >I was guessing maybe eCos init for ARM (or maybe the olimex lpc2106
> >port) may have a thing which disable JTAG. Is it possible or did I do
> >something wrong and JTAG should work with eCos ?
> >
> >For reference I use an LPC2106 ARM7 micro controller.
> >
> 
> -- 
> 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: eCos invalidating JTAG on ARM architecture ?

[Alexandre]

Well the problem came back earlier this evening :(
I don't know how it is related to eCos but it is in some way because I
do not have any problem when I run the same code without eCos (that is
when I do the setup and vector init myself).

I'll check to see if I have the post patch version but i downloaded my
sources a week ago from the anonymous CVS.
I indeed have a binary of openocd i found on the net, you think i
should try and build it myself ?

-- 
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: eCos invalidating JTAG on ARM architecture ?

[Sergei Gavrikov]

Alexandre writes:
> Well the problem came back earlier this evening :(
> I don't know how it is related to eCos but it is in some way because I
> do not have any problem when I run the same code without eCos (that is
> when I do the setup and vector init myself).

Well, and what about your own eCos startup file (hal_platform_setup.h)?
Did you manage the LPC PINSEL registers correctly? I see that Jani
Monoses, for example, didn't overload his own startup files by any extra
lines ;) Observe arm/lpc2xxx/*/current/hal/include/hal_platform_setup.h
files, for example. It's possible you have to force Debug/Trace pinouts
assignment in your own eCos platform startup file.

> I'll check to see if I have the post patch version but i downloaded my
> sources a week ago from the anonymous CVS.
         ^^^^^^^^^^^^^^^^
That already has contained that February fix.

> I indeed have a binary of openocd i found on the net, you think i
> should try and build it myself ?

At first, I would suggest to check your eCos startup code (platform
startup, certainly).

Sergei



-- 
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: eCos invalidating JTAG on ARM architecture ?

[Sergei Gavrikov]

On Fri, Jul 06, 2007 at 01:46:40PM +0200, Alexandre wrote:
> >Well, and what about your own eCos startup file (hal_platform_setup.h)?
> >Did you manage the LPC PINSEL registers correctly? I see that Jani
> >Monoses, for example, didn't overload his own startup files by any extra
> >lines ;) Observe arm/lpc2xxx/*/current/hal/include/hal_platform_setup.h
> >files, for example. It's possible you have to force Debug/Trace pinouts
> >assignment in your own eCos platform startup file.
> 
> I thought about that yesterday (maybe i've got the shinning !), but
> thanks for asking, seems like i'm finally heading the right way :)
> Well that's what I wrote:
> 
> .macro _gpio_init
>        // enable  RX and TX on UART0 and the button
> 	ldr r0,=CYGARC_HAL_LPC2XXX_REG_PIN_BASE	
> 	ldr r1,=0x80000005
> 	str r1,[r0,#CYGARC_HAL_LPC2XXX_REG_PINSEL0]
> 	// added PINSEL1 config to enable JTAG1 & EINT0
> 	ldr r1,=0x55400001
> 	str r1,[r0,#CYGARC_HAL_LPC2XXX_REG_PINSEL1]
> 	.endm
> 
> The last part is my code, yet it's still not working. Is there any
> other place where any init could occur ?
> 
> For reference this register assignment (0x55400001) works in a non
> eCos environment, that is JTAG & External Interrupt 0 both work fine.

Well, I haven't LPC2106 board to dig deeper, but I remember that two
years ago I downloaded a trial version of CW 1.X for ARM from Rowley
Associates Ltd. I'm still keeping that stuff on my Slackware box,
because they used GNU tool chain.  My friend told me in those days that
CW works very smoothly with parallel JTAG wiggler. He has got one
LPC2106 board and played with it using CW. Greping through out their
samples directory, I found a startup.s file for IAR LPC210X Kickstart
board (secondary_jdag dir.). It contains such a trap

#define PINSEL1 0xE002C004

reset_handler:
  /* Set P0.27-P0.31 alternative function 1 (secondary JTAG pins). */
  ldr r0, =PINSEL1
  ldr r1, =0x55400000
  str r1, [r0]

  /* Loop forever */
1:
  b 1b

Look at the eCos vectors.S for ARM arch., please. It contains

reset_vector:
        PLATFORM_SETUP1         // Early stage platform initialization
                                // which can set DRAM size at 0x40
                                // see <cyg/hal/hal_platform_setup.h>

        // Come here to reset board
warm_reset:                 

As you can see PLATFORM_SETUP1 is just an inclusion your platform setup
code (that is your own hal_platform_setup.h file). So, try to apply that
CW's trap for the second jtag. And then jump at warm_reset point. Well,
that is a trick, but it's possible, it will be work for you.

I'm sorry, but I don't use any JTAG for my target. Like Paul I use GDB
stubs (RedBoot) for debugging. My LPC CPUs has EMC (external memory
controller) and I can load and debug code in RAM. I understand what that
isn't your path. So, I would suggest you to get stable results with your
JTAG using minimalist eCos template at first (to save a time).

regards,

	Sergei


> >That already has contained that February fix.
> 
> Cool, i had nightmare thinking about patching my sources -.-

-- 
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: eCos invalidating JTAG on ARM architecture ?

[Sergei Gavrikov]

If the trap will be work for you, here is a small notice about the eCos
path. Enter in your HAL platform startup (hal_platform_startup.h) a
conditional inclusion, something like this

#ifdef CYGHWR_HAL_ARM_LPC2XXX_USE_SECONDARY_JTAG
        // put that trap code here
        ...
#endif

and add in your platform cdl file a CDL rule, well, something like this

cdl_option CYGHWR_HAL_ARM_LPC2XXX_USE_SECONDARY_JTAG {
    display       "Second JTAG workaround"
    flavor        bool
    default_value 0
    description   "Short story about"

}

That gives you a choice or to build executables for debugging either to
build executables for a release, configuring an ecos.ecc stuff.

Sergei


On Fri, Jul 06, 2007 at 07:48:44PM +0300, Sergei Gavrikov wrote:
> On Fri, Jul 06, 2007 at 01:46:40PM +0200, Alexandre wrote:
> > >Well, and what about your own eCos startup file (hal_platform_setup.h)?
> > >Did you manage the LPC PINSEL registers correctly? I see that Jani
> > >Monoses, for example, didn't overload his own startup files by any extra
> > >lines ;) Observe arm/lpc2xxx/*/current/hal/include/hal_platform_setup.h
> > >files, for example. It's possible you have to force Debug/Trace pinouts
> > >assignment in your own eCos platform startup file.
> >
> > I thought about that yesterday (maybe i've got the shinning !), but
> > thanks for asking, seems like i'm finally heading the right way :)
> > Well that's what I wrote:
> >
> > .macro _gpio_init
> >        // enable  RX and TX on UART0 and the button
> >     ldr r0,=CYGARC_HAL_LPC2XXX_REG_PIN_BASE
> >     ldr r1,=0x80000005
> >     str r1,[r0,#CYGARC_HAL_LPC2XXX_REG_PINSEL0]
> >     // added PINSEL1 config to enable JTAG1 & EINT0
> >     ldr r1,=0x55400001
> >     str r1,[r0,#CYGARC_HAL_LPC2XXX_REG_PINSEL1]
> >     .endm
> >
> > The last part is my code, yet it's still not working. Is there any
> > other place where any init could occur ?
> >
> > For reference this register assignment (0x55400001) works in a non
> > eCos environment, that is JTAG & External Interrupt 0 both work fine.
>
> Well, I haven't LPC2106 board to dig deeper, but I remember that two
> years ago I downloaded a trial version of CW 1.X for ARM from Rowley
> Associates Ltd. I'm still keeping that stuff on my Slackware box,
> because they used GNU tool chain.  My friend told me in those days that
> CW works very smoothly with parallel JTAG wiggler. He has got one
> LPC2106 board and played with it using CW. Greping through out their
> samples directory, I found a startup.s file for IAR LPC210X Kickstart
> board (secondary_jdag dir.). It contains such a trap
>
> #define PINSEL1 0xE002C004
>
> reset_handler:
>   /* Set P0.27-P0.31 alternative function 1 (secondary JTAG pins). */
>   ldr r0, =PINSEL1
>   ldr r1, =0x55400000
>   str r1, [r0]
>
>   /* Loop forever */
> 1:
>   b 1b
>
> Look at the eCos vectors.S for ARM arch., please. It contains
>
> reset_vector:
>         PLATFORM_SETUP1         // Early stage platform initialization
>                                 // which can set DRAM size at 0x40
>                                 // see <cyg/hal/hal_platform_setup.h>
>
>         // Come here to reset board
> warm_reset:
>
> As you can see PLATFORM_SETUP1 is just an inclusion your platform setup
> code (that is your own hal_platform_setup.h file). So, try to apply that
> CW's trap for the second jtag. And then jump at warm_reset point. Well,
> that is a trick, but it's possible, it will be work for you.
>
> I'm sorry, but I don't use any JTAG for my target. Like Paul I use GDB
> stubs (RedBoot) for debugging. My LPC CPUs has EMC (external memory
> controller) and I can load and debug code in RAM. I understand what that
> isn't your path. So, I would suggest you to get stable results with your
> JTAG using minimalist eCos template at first (to save a time).
>
> regards,
>
>       Sergei
>
>
> > >That already has contained that February fix.
> >
> > Cool, i had nightmare thinking about patching my sources -.-
>
> --
> 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: eCos invalidating JTAG on ARM architecture ?

[Alexandre]

Ok I implemented that and it enabled me to know what in vectors.S was
disabling JTAG. Ironically, i shortened it to the "bl cyg_start"
instruction at the end of the "start:" label (last instruction for
this label i think).

I find it weird because it would mean the launch of the actual kernel
software is what makes it impossible for me to debug further.

Do you know where i can find that "cyg_start" label vectors.S is
referring to and is it worth it lurking that way ?

I can totally watch my board run before that instruction, and lose the
JTAG connection after that, openOCD telling me that my CPSR contains
invalid data.

-- 
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: eCos invalidating JTAG on ARM architecture ?

[Andrew Lunn]

On Tue, Jul 10, 2007 at 11:56:12AM +0200, Alexandre wrote:
> Ok I implemented that and it enabled me to know what in vectors.S was
> disabling JTAG. Ironically, i shortened it to the "bl cyg_start"
> instruction at the end of the "start:" label (last instruction for
> this label i think).
>
> I find it weird because it would mean the launch of the actual kernel
> software is what makes it impossible for me to debug further.
>
> Do you know where i can find that "cyg_start" label vectors.S is
> referring to and is it worth it lurking that way ?

cyg_start is one of the entry points into the application code. So it
may be coming from the application. If not, eCos provides a cyg_start
in packages/infra/current/src/startup.cxx

You say that the CSPR is invalid? Does the branch to cyg_start jump to
a valid address? It could be that the address is invalid and causes an
exception? Seems unlikely, but i cannot think of anything else.

        Andrew


-- 
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: eCos invalidating JTAG on ARM architecture ?

[Alexandre]

Okay i seem to have identified the problem and narrowed it down again.
The modification on the PINSEL1 register init now enables me to debug
eCos properly IF i don't use the function cyg_thread_delay().
For some obscure reason this particular function seems to deactivate
the JTAG definitely (JTAG1 and 2) on my controller.

Should it be expected ?

Ps: I'd like to thank you all for i would never have gotten that far
if it wasn't for your help throughout my whole ecos learning process,
so THANK YOU, very very much :)

-- 
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: eCos invalidating JTAG on ARM architecture ?

[Andrew Lunn]

On Tue, Jul 10, 2007 at 05:02:12PM +0200, Alexandre wrote:
> Okay i seem to have identified the problem and narrowed it down again.
> The modification on the PINSEL1 register init now enables me to debug
> eCos properly IF i don't use the function cyg_thread_delay().
> For some obscure reason this particular function seems to deactivate
> the JTAG definitely (JTAG1 and 2) on my controller.
>
> Should it be expected ?

No.

cyg_thread_delay() does nothing with hardware. It just waits until the
correct number of timer ticks have gone off and then brings sleeping
process back to running state.

Does the system continue to run even though JTAG has stopped? 

Im just wondering if JTAG stops working with the system crashes?  It
could be your stack is too small, which sometimes causes crashes in
cyg_thread_delay().

What test programs are you using? All the standard tests should work
without problems, so i would use them for the moment until you get a
stable system.

    Andrew

-- 
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: eCos invalidating JTAG on ARM architecture ?

[Andy Jackson]

Have you tried the CDL option

CYGHWR_HAL_ARM_LPC2XXX_IDLE_PWRSAVE

Here is the description. I put it in when I was having problems with the 
JTAG dropping out.

           Select this option when it is desired to save power by
           stoping the processor clock in the idle loop. This is
           controlled by the PCON register. Generally this is a good
           thing, but it may be necessary to disable this when
           debugging via JTAG, as stopping the clock can prevent the
           debugger getting control of the system."

Hope that helps,

    Andy..

----- Original Message ----- 
From: "Andrew Lunn" <andrew@lunn.ch>
To: "Alexandre" <thekyz@gmail.com>
Cc: "Sergei Gavrikov" <w3sg@softhome.net>; 
<ecos-discuss@ecos.sourceware.org>
Sent: Tuesday, July 10, 2007 4:14 PM
Subject: Re: [ECOS] Re: eCos invalidating JTAG on ARM architecture ?


> On Tue, Jul 10, 2007 at 05:02:12PM +0200, Alexandre wrote:
>> Okay i seem to have identified the problem and narrowed it down again.
>> The modification on the PINSEL1 register init now enables me to debug
>> eCos properly IF i don't use the function cyg_thread_delay().
>> For some obscure reason this particular function seems to deactivate
>> the JTAG definitely (JTAG1 and 2) on my controller.
>>
>> Should it be expected ?
>
> No.
>
> cyg_thread_delay() does nothing with hardware. It just waits until the
> correct number of timer ticks have gone off and then brings sleeping
> process back to running state.
>
> Does the system continue to run even though JTAG has stopped?
>
> Im just wondering if JTAG stops working with the system crashes?  It
> could be your stack is too small, which sometimes causes crashes in
> cyg_thread_delay().
>
> What test programs are you using? All the standard tests should work
> without problems, so i would use them for the moment until you get a
> stable system.
>
>    Andrew
>
> -- 
> 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: eCos invalidating JTAG on ARM architecture ?

[Alexandre]

> Have you tried the CDL option
>
> CYGHWR_HAL_ARM_LPC2XXX_IDLE_PWRSAVE
>
> Here is the description. I put it in when I was having problems with the
> JTAG dropping out.
>
>            Select this option when it is desired to save power by
>            stoping the processor clock in the idle loop. This is
>            controlled by the PCON register. Generally this is a good
>            thing, but it may be necessary to disable this when
>            debugging via JTAG, as stopping the clock can prevent the
>            debugger getting control of the system."
>
> Hope that helps,
>
>     Andy..

A lot in fact, that was it -.-
Thank you all 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

[ECOS] IPMI driver for KCS interface

[jerzy dyrda]

Hello Folks,

My current task is create (maybe port from Linux) IPMI KCS driver for eCos. I 
have as always few doubts regarding new driver i.e. :
How should I construct driver whether it can be "authentic" eCos driver? (I 
mean how this device should be accessible from user application side - 
"direct" by special function or by io function e.g. read/write )

If someone from eCos comunity has some advice/tip/demand regarding IPMI it 
will be very helpful and of course appreciate.

thanks, 
jerzy

-- 
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] IPMI driver for KCS interface

[Laurie Gellatly]

Hi Jerzy,
I've also got some interest in IPMI.
The way I expected it would be handled is as a set of library routines that
could be layered on top of a hardware transport layer (serial or IP for
instance).
I'm not an IPMI expert, but it appears to me that IPMI is basically a
communications protocol rather than a hardware driver.
Is that how you view it?

Cheers			...Laurie:{)

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org]On Behalf Of jerzy dyrda
Sent: Wednesday, 11 July 2007 9:13 PM
To: ecos-discuss@ecos.sourceware.org
Subject: [ECOS] IPMI driver for KCS interface


Hello Folks,

My current task is create (maybe port from Linux) IPMI KCS driver for eCos.
I
have as always few doubts regarding new driver i.e. :
How should I construct driver whether it can be "authentic" eCos driver? (I
mean how this device should be accessible from user application side -
"direct" by special function or by io function e.g. read/write )

If someone from eCos comunity has some advice/tip/demand regarding IPMI it
will be very helpful and of course appreciate.

thanks,
jerzy

--
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] IPMI driver for KCS interface

[jerzy dyrda]

Hello Laurie,

> I'm not an IPMI expert, but it appears to me that IPMI is basically a
> communications protocol rather than a hardware driver.
> Is that how you view it?

Yes, IPMI as I suppose is in general method of comunication with Baseboard 
Management Controller - BMC ( from side of System Management Software - SMS ) 
but KCS is kind of interface beetwen BMC and SMS (sorry for this stupid 
shortcut but this is a part of IPMI terminology) and my doubts are connected 
with method of comunication from user application to BMD through KCS driver. 
IPMI specification defined other interfaces what force on developer 
implementing universal interface to IPMI.

Best regards,
jezry 

-- 
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] IPMI driver for KCS interface

[David Fernandez]

> -----Original Message-----
> From: jerzy dyrda [mailto:jerzy.dyrda@kontron.pl]
> Sent: 11 July 2007 13:34
> To: ecos-discuss@ecos.sourceware.org
> Cc: Laurie Gellatly
> Subject: Re: [ECOS] IPMI driver for KCS interface
> 
> Hello Laurie,
> 
> > I'm not an IPMI expert, but it appears to me that IPMI is basically
a
> > communications protocol rather than a hardware driver.
> > Is that how you view it?
> 
> Yes, IPMI as I suppose is in general method of comunication with
Baseboard
> Management Controller - BMC ( from side of System Management Software
-
> SMS )
> but KCS is kind of interface beetwen BMC and SMS (sorry for this
stupid
> shortcut but this is a part of IPMI terminology) and my doubts are
> connected
> with method of comunication from user application to BMD through KCS
> driver.
> IPMI specification defined other interfaces what force on developer
> implementing universal interface to IPMI.
> 
> Best regards,
> jezry

Hi there,

I've ported the Linux IPMI driver to Solaris some time ago.

I think you can just base your IPMI driver in the I2C driver if you were
going to use SMIC interface, I'm not so familiar with KCS, as it is very
slow interface and because of that is normally discarded in most
systems, in addition, most Intel chipsets have a BMC based on the SMIC
interface anyway.

Anyway, it is not very difficult to do the driver from scratch by just
looking at the standard if you intent to support just one interface and
don't have any intentions of offering very differentiated kernel and
user mode APIs.

Regards

 Trafficmaster, Plc.
David Fernandez
Wireless Comms. Specialist
 

----V-V-V-V----DISCARD-THE-FOLLOWING-DISCLAIMER----V-V-V-V----



--
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] IPMI driver for KCS interface

[Andrew Lunn]

On Wed, Jul 11, 2007 at 01:12:49PM +0200, jerzy dyrda wrote:
> Hello Folks,
> 
> My current task is create (maybe port from Linux) IPMI KCS driver for eCos.

Be careful of the license. You don't want to port any GPL code since
it will "infect" the whole of eCos and the application with GPL. You
will then be required to license your application code with the GPL
license and have to provide sources to your customer etc....

You might want to see if any of the *BSD systems have the necessary
components using more friendly licenses.

        Andrew

-- 
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: eCos invalidating JTAG on ARM architecture ?

[Alexandre]

> cyg_thread_delay() does nothing with hardware. It just waits until the
> correct number of timer ticks have gone off and then brings sleeping
> process back to running state.
>
> Does the system continue to run even though JTAG has stopped?

Yep it does :(

> What test programs are you using? All the standard tests should work
> without problems, so i would use them for the moment until you get a
> stable system.

I've compiled my own code which is just a simple thread program
launched by cyg_user_start()

> Have you tried the CDL option
>
> CYGHWR_HAL_ARM_LPC2XXX_IDLE_PWRSAVE

I'm trying it right now to see what happens, thx for that

-- 
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] eCos invalidating JTAG on ARM architecture ?

[Paul D. DeRocco]

> From: Alexandre
> 
> After I upload my eCos code to my board via JTAG (code which 
> is fully functioning by the way), I can't by any mean reach 
> it again via JTAG. OpenOCD just says it can't communicate 
> with my board. Seems like eCos just disable my JTAG. The only 
> way I can access my micro controller again is by UART, 
> erasing the flash using ISP, and then reflashing it by JTAG 
> works anew. So it works, but I can't debug the thing.

In general, JTAG debugging is best for getting your startup code working.
Once you've done that, you're better off debugging over serial, or if you
have it, Ethernet. As far as I know, OpenOCD doesn't have any particular
support for eCos threads (correct me if I'm wrong). To do that, the debugger
must be able to execute some eCos code, invoked through the virtual vector
table. I don't think any JTAG debugger can do that.

I suggest configuring a full-featured version of Redboot, and getting that
into the flash. Then debug your application in RAM over serial or Ethernet.
You can ultimately get Redboot to boot your application from an image stored
in flash.

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.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] eCos invalidating JTAG on ARM architecture ?

[Andrew Lunn]

> I suggest configuring a full-featured version of Redboot, and getting that
> into the flash. Then debug your application in RAM over serial or Ethernet.
> You can ultimately get Redboot to boot your application from an image stored
> in flash.

A lot depends on the type of microprocessor you have. With devices
like the AT91SAM7 you have 64KByte RAM and 256KByte flash on
chip. They are designed to run the application from flash. Redboot is
not really an option for these devices since it cannot do hardware
breakpoints. You have to use JTAG and live without full thread
support.

        Andrew

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